Smoking-related cancer is mostly due to nitrosamines. Nicotine can have adverse effects on heart, pancreas, and blood vessels, but replacing sooty nicotine inhaling with non-sooty is less cancer-risky.
So author offers to replace PGP for sending files with a piece of software which requires to send/say a password to your recipient? Oh yeah, that's smart, and very modern!
It is indeed. Magic Wormhole implements a PAKE to individually encrypt and authenticate a secure channel without requiring any other root of trust. It's exceptionally easy to use and secure.
This. If you share a temporary password through another secure channel, you can probably just share a symmetric key and then you don't need PAKE anymore. In some cases though, you might want to send yourself something from one device to the other, or you are talking to someone who's not really technical on the phone.
About being online at the same time, I was under the impression that this wasn't a requirememt.
To transfer a file, both parties do need to be online at the same time. The server (which I run) does not store the file's data: it stores tiny key-exchange messages until both sides manage to make a direct connection, but then the encrypted file data is sent from sender to recipient without being stored in the middle. So it doesn't replace email or an FTP server or some other asynchronous file-transfer service.
You're absolutely right that if you already have a secure channel, you can send a full-strength symmetric key that way (e.g. send a PGP key, or one of the alternatives in gtank's post). But PAKE enables using a low-bandwidth secure channel. I can easily read a magic-wormhole code like "4-purple-sausages" to someone over the phone or to the person sitting next to me, but I'd be hard pressed to dictate an entire 256-bit secret key correctly.
Also, if you're sending an encryption key you have to make sure it's a good key, ie generate it from a reliable source of random and with a sufficient length, whereas magic wormhole's password is automatically generated for you.
Yes, that's what I'm saying: GP's point is that if you have a secure channel you might as well send the encryption key, but in order to do that you have to be careful about generating it correctly, whereas PAKE give you the possibility to exchange something far simpler.
Well, it's nice when phone is considered secure channel. It's not so for many serious applications, however. PGP invented to deal with situations when you communication channels are untrusted. See, no one says your software is bad, but when it is marketed as a better alternative to PGP it's not true, and worse, it's absolutely irresponsible thing to do.
According to parents nice talk[1] you can add a verify switch that lets you compare the signature of the actual key. So a public authenticated channel is enough.
I'm not sure we are on the same page here. Having control over a channel you use to pass your code, I can receive your secret file, I just need to be quicker than a legitimate recipient. How this '--verify' flag will help you then?
The assumption is that Alice recognizes the voice of Bob. If Eve manages to evasdrop on the call and sits in the middle or beats Bob to connect to the wormhole server then Alice will still see that the fingerprint that Bob dictates over the phone does not match the fingerprint of the key that her computer proposes to use for the file transfer. Alice will therefore abort the transmission.
With deep learning the voice may be not good enough nowadays. Still, you only need an authenticated - possibly public - channel, similar to pgp key exchange, where you can read the fingerprint over the phone.
I'm not sure any of us has a right to speak for every consumer. I live in a country were majority would likely prefer cheaper devices w/o any security guarantees. Forcing producers to provide 5(?)-years updates will make prices rise, and it could be against interests of a large segment of consumers. The only regulation which I believe would be beneficial for all is obligatory transparency. There should be clear warnings like "The producer expects you to replace this device in 2 years, and will not support it after that", or "This producer doesn't promise anything in regard of this device - use at your own risk"
You wrote: "Forcing producers to provide 5(?)-years updates will make prices rise"...
I don't think so: it will oblige makers to standardize processes and software across phones... i.e. very basic specific drivers, then same OS and libs on all phones (with just different themes).
Then the Android security updates can be uploaded directly from Google at no cost. Just like for computers, and phones are computers with very few different features (input device, GSM chip).
My HP or Dell computer is not more expensive when Microsoft or Debian is pushing security updates.
In the end, unifying processes and software brings costs down.
I almost loved this idea on the first sight, but on the second I'm not sure I see how it can work. Will you mandate Apple to make iOS installable on Huawei's devices? If not, why? If yes, how? Who will bear responsibility if SailfishOS won't run on Samsung's hardware? Do you really think API standard can be enshrined in the law, and how you plan to make it safe from corporate abuse?
Btw, if Microsoft is pushing security updates you did pay additional cost for license. If it's Debian then quite possibly you still paid something to MS (if your computer was bought with OEM version), or in better case other corporations, and individuals pay for it (mostly to reduce Microsoft's power).
>I'm not sure any of us has a right to speak for every consumer.
Yet almost every civilization on Earth has already decided that we, the masses, _do_ have a right to speak for everyone when it constitutes a common good. In the US, you have to wear a seatbelt in most states. Your food is regulated by the FDA. Your cars must meet certain safety standards, as does your home. This list goes on and on.
You are referring to undefined terms to define undefined terms: "common good" is not something obvious in this particular situation. Food is poor example here because toxicity is more, or less the common denominator here, while safety of a smartphone has a very different value for someone whose life is immersed in digital services, and whose income allows to see a +/-50 dollars as a small variation, and one who uses only whatsapp, and weather service, and needs to save every penny. In fact majority of Android phones in the world right now are somewhat vulnerable, and it doesn't seem that people who use all these cheap stuff are eager for change. You already can be safer if you it's your priority by using more expensive brands (Apple, Samsung) which offer longer-term updates.
P.S. My food is not regulated by FDA, not everybody registered in HN are from States.
>Just because a lot of people do it doesn't mean it's the right choice though
Who said that it was?
The FDA, as it is known today, came into being in response to the public outrage at the shockingly unhygienic conditions in the Chicago stockyards that were described in Upton Sinclair’s book “The Jungle." Building codes exist to protect public health and welfare.
These weren't arbitrary decisions; they were made in response to real issues. Laws in general limit personal freedoms to protect society and the public. Also, some personal freedoms infringe on the freedoms of others. If murder were legal you would gain personal freedom, but your victims would lose theirs. I may want to have cows in my backyard, but my neighbors may have a few legitimate issues with that.
The fact is that the world has decided you are wrong, and for good reason. I don't need to prove why; you need to prove why everyone else is apparently incorrect.
>Most Republicans seem to disagree from what I can tell.
Uh huh, until we start talking about what you do with your body or who you want to marry. Many conservatives do believe in personal freedom over government rule, yes, but the best conditions are always brought about by balancing those, never in favoring one completely over the other.
Softpedia ironically proves their story doesn't make any sense.
Microsoft’s Security Response Center revealed that most of the cyber-attacks aimed at Windows computers aren’t based on patched exploits, but on zero days.
Apparently it's hard to base your attack on an exploit which no longer works because relevant vulnerability is addressed by an installed patch. Journo behind the story believes it means patches are useless. This is, to put mildly, a very unorthodox logic.
The study explores the possible way to sustain a bigger brain well before invention of tools, and controlled fire. It's also absolutely not about hunting.
It's always hit or miss when one tries to comment after reading just a headline ;-)
Using "title:" you meaninglessly narrowed your search. There are postings like "Software engineer" with body saying "Developing with JS, and Clojure" which won't appear in your results.
Number of "Clojure" results is 109, compared with 98 for "Haskell", for instance (in London, according to indeed.co.uk). So both are not scoring big, certainly, but those numbers are nevertheless better than 3-4 years ago.
In my experience (in Sweden), most of those results are "false positives". Companies/recruiters like to look for passionate programmers, so they put smaller languages like Clojure in their ads, even though the job itself has nothing to do with it.
True, except they don't include languages just for being smaller (we don't see Befunge, or Unlambda there), but those associated with smartness, and passion for learning. In context of the discussion (dead/alive state), I wouldn't count this as a bad thing. There's no arguing that finding FP job is hundreds (or thousands, depending on city/country) times harder than OOP job. It doesn't mean all functional langs are dead.
I agree with what you're saying, my post was mainly trying to point out that there might appear to be more Clojure jobs than there actually are. For the past couple of months, I've been looking for Clojure jobs (after my company in one fell swoop decided that Clojure was out, and we were no longer allowed to use it for new projects), and though there are quite a few matches when searching just for "Clojure" on job boards, most of those have nothing to do with Clojure. Out of 50-100 matches, maybe 2-4 of those were actual Clojure jobs. Granted, this is in Stockholm, but the situation was pretty much the same a couple of years ago, and things don't seem to have improved. I love Clojure, it's probably my favorite programming language, but I finally decided on a more normal C#/Java/JS position for my new job.
Well, I have already agreed FP jobs aren't plenty :-) Business executives mostly prefer to stick to beaten paths, and it's understandable. I just don't see a tragedy here. OCaml was born in 1996, if I'm not mistaken, so it's a decade older than Clojure. Despite never reaching the industry mainstream, it never stopped being developed, it is used in real projects, so I guess we can agree it's very much alive. Clojure in my very subjective opinion is doing a bit better than that due to ability to augment software written in Java. So while I don't believe it will conquer the world anytime soon, I also believe it's not going to disappear anytime soon.
>Clojure in my very subjective opinion is doing a bit better than that due to ability to augment software written in Java.
OCaml can embed or be embedded in native applications, but that's not the point.
I think that the main problem with Clojure is the lack of types.
Just look at how much Scala is more popular than Clojure, although it's also a strange functional language derived from OCaml/SML.
There is a common opinion that types are a necessity, even ruby, racket and python are adding them. Clojure people are just trying to substitute types with a runtime evaluated contracts/Hoare triplets, which is not an adequate substitution.
What had kept happening was that services written by my team (mostly doing Clojure for backend development) were taken over by other teams that either weren't interested in learning Clojure, or weren't allowed by management to do Clojure development (for whatever reason), so each time this happened our original service would be rewritten in Java or Node.
...of course, for the other team to be able to do this, they still needed to learn some Clojure in order to understand our code, but even in the cases where they actually liked doing Clojure, they were still forced to do the rewrite. The company was/is expanding very rapidly, so part of me can understand the decision to narrow it down to fewer "allowed" languages, to allow services/responsibilities/teams to move around more freely.
But it was one of the main reasons I decided to leave the company. I had joined after years hoping for Clojure to be my main professional programming language (for a substantial part of my career, at least), and I left a somewhat more bitter developer, but at the same time feeling a bit more free and relaxed - there are sooo many opportunities to pick from, now what I'm a bit more open when it comes to the tech!
It's very believable that language plays a role. However, such arguments happen between people with the same mother tongue. So those color axioms could be defined on a community, or even a family level. Within a population speaking one language (and having a uniform education likely plays a big role) a particular axiom probably has better chances to become more or less dominant, but still differences are apparently more complex than language -> color.
You're totally right, this was a formative anecdotal experience for me but honestly there's absolutely no control for the experiment. I'm sure I've had the blue vs. green disagreement with non Russian speakers and discarded it. If it weren't already topical (I'm sure we were exploring синий versus голубой) I may not have considered the blue/green towel memorable.
I actually heard a lot of silly arguments between people who all have the same native language about orange vs red vs pink, or where is the border between blue and green. So not so sure it's about language, or culture.
