Think You're Operating on Free Will? Think Again - <AUTHOR> http://www.time.com/time/health/article/0,8599,2000994,00.html <comment><USER3> Here's a re-framing of "free will" that I find very useful - it's more like "free won't." The technical term is Inhibition. Our physical and mental processes may make us _inclined_ to act in a certain way, but we have a limited ability to inhibit that initial response long enough to do something different by using willpower.

Think of a lion in the brush, ready to pounce on an unsuspecting antelope. The lion _wants_ to pounce, but inhibits the response for a little while, waiting for the antelope to come a little closer.

Since willpower is depleted with use (a process called Ego Depletion), inhibition is a very limited power - it's difficult, requires a lot of energy, and can't be maintained indefinitely. Our natural inclinations and environment are extremely powerful forces, and we can't hold out for long.

That's why, if you're experiencing some form of temptation (wanting to do what you know you shouldn't), it's better to inhibit and remove yourself from the situation as quickly as possible vs. rely on your "free will" to save you. Otherwise, you'll progressively find it more and more difficult to resist until you act.

I find this definition very useful because it maintains human agency (the ability to choose your behavior), while respecting the undeniable power that environment and circumstances have on our behavior.

<comment><USER4> I agree on the power of inhibition, but I think the second point you alluded to is the larger one -- the ability to remove the stimulus.

Certainly it's hubris to believe that one can exercise "free will" to remain completely uninfluenced by one's environment. But what we can do is exercise a measure of intelligence and free will to anticipate the relationship between stimulus and response, and alter our environment accordingly.

I.e. if you're trying to lose weight, don't allow yourself to be exposed to fast food advertising.

Our brains may be heavily influenced by our environment in ways that we are not normally aware, but the existence of studies like these shows that we can begin to understand the dynamic of influence. Once we have understanding we can take appropriate measures.

As I see it, that's the true power of intelligence and human agency.

After all, as you point out, animals also have certain powers of inhibition. But none have the ability to comprehend their own minds and alter their environment accordingly.

<comment><USER4> By pure coincidence, this ties in well with something Nassim Taleb just tweeted:

"Unless we manipulate our surroundings,we have as little control over what & whom we think about as we do over the muscles of our hearts."

<comment><USER4> <http://twitter.com/nntaleb/status/17647441068>

</comment></comment></comment></comment><comment><USER5> I've long believed that free will is illusory. Empirical evidence includes studies that suggest that we may make decisions before we're actually aware of them (See Benjamin Libet: <http://en.wikipedia.org/wiki/Benjamin_Libet>) Your conscious mind is like a 6 year in the back seat with the toy steering wheel, pretending he's driving and making up stories about where he's taking us.

Despite that, I can't actually live my life as though I really have no free will. I tried it (briefly) as an experiment, and I merely sank into a sort of post hoc analysis of everything I did. "I was supposed to do that. That's what my unconscious made me do. Etc..." Indeed, I believe that free will is inseparable from identity to such an extent that even if we find unassailable proof that it's merely an illusion, we'll continue about our lives, "choosing," as if nothing ever happened.

<comment><USER6> There is a fascinating book by Julian Jaynes called The Origin of Consciousness in the Breakdown of the Bicameral Mind that goes even deeper into this area.

Basically, he says, our two minds were previously split and "you" would "hear" your other mind issuing instructions about what to do. (Much like Snow Crash and the nam-shubs of Enki).

Over time the two merged, and we ended up with a single stream of consciousness. Among other things, he says, we can see the remnants in people experiencing "the voice of God", and the way we are extremely susceptible to commands spoken closely into our right ears.

To be clear: modern theories of consciousness and psychology have v. little time for Jaynes, but as a philosophical curio/thought game it's great fun.

<comment><USER7> Interesting right ear findings:

<http://www.google.com/search?q=spoken++right+ear>.

</comment></comment></comment><comment><USER8> On actually reading the article: this title is a bad summary. (Makes me think of Slashdot.) What the article covers is the point, which I hope is uncontroversial, that stimuli give rise to responses, and influence the course of cognition: holding a warm cup of coffee makes you think more, well, warmly of someone you're interviewing; seeing a framed picture of a library causes you to speak more quietly; the smell of cleaning agents inspires you to keep your cubicle clean; long dint of repetition encourages you to decide that yes, in fact, you are having a Big Mac attack.

None of this is controversial, unless you're thinking in terms of Descartes -- the body and mind as purely separate and the mind as purely master of the body. There's a Catholic saying that "body and soul are one" -- what the soul (or mind, if you prefer) does, affects the body, and what the body does, affects the soul.

Another thing I'd mention: like evolutionary psychology, this article's research is highly culture-bound. They don't seem to be interested in determining whether pictures of libraries mean the same thing to Indonesian hill tribes, or whether the scent of Febreeze means the same thing to Moroccans (or red mages).

Also, as the article points out, this kind of unconscious encouragement can be overcome; you have only to be aware of it.

<comment><USER9> Perceptual Control Theorists would argue that you don't understand behavior if you think that we, or other animals, respond to stimuli.

 _"The illusion of stimulus and response [..] What we see from outside the system is that the crosswind pushes sideways on the car and the front wheels of the car immediately cock into the wind, preventing any important change in the car's path. It looks just as if the car is being stimulated by the wind, and is responding by turning its front wheels into the wind. Of course we know that neither the car nor the driver can sense the crosswind; this appearance of stimulus and response is an illusion. The true explanation is a little more complicated than the stimulus-response explanation would be, but not much more complicated.

But we can see now how the impression that stimuli cause responses could arise, even if the system in question is really a control system that works as just described."_

\-- William T. Powers, A Brief Introduction to Perceptual Control Theory: <http://www.benchpress.com/aboutPCT.htm>

</comment></comment><comment><USER10> The law as it has stood for centuries has imposed different degrees of liability based on one's mental state and this is often tied to moral standards.

Just a sampling: (a) it takes "malice aforethought" or premeditation to support higher degrees of a murder conviction; (b) one must act with "scienter" (intent or knowledge of wrongdoing) to be held liable for various intentional torts such as fraud; (c) punitive damages may be awarded to punish a wrongdoer for conduct that is outrageous or wanton or done in reckless disregard of the rights of others.

When I read reports such as this piece, I always wonder how the science can be real and yet have such a disconnect with real-world application, i.e., if it is true that we fundamentally don't control our actions, why should we be held responsible for them depending on varying states of mind? Why should we incur larger penalties if we "intended" to take a wrong action if our intention is ultimately based on unconscious stimuli over which we have no control? Why should it be wrong to steal something if an uncontrollable impulse made us do it?

Given these sorts of disconnects, I wonder if society doesn't treat science of this type effectively as if it were really more like philosophy - <USER2> to contemplate but often having no real-world application. Certainly, if it is true science (verifiable, repeatable, etc.), the law should change to follow suit. Yet how would that happen without chaos ensuing in the areas of crimes, torts, etc. where people are supposed to be held responsible for their wrongs and particularly if they intended to commit them?

<comment><USER11> One reason that legal punishment can still work in the absence of free will, is that absence of legal punishment might make more of the moist robots do societally damaging things. Essentially, it is not about a moral decision, it is about preventive damage control.

</comment></comment><comment><USER12> I think it's important to remember not to make free will vs determinism a binary argument. As I look at it, the truth is both and neither.

For various reasons certain people will be influenced and coerced down the path of least resistance by their environment more so than others. Free will is essentially something you must claim for yourself (of course I mean relatively, no one can ever be <i>fully</i> in control of the developments of their life).

</comment><comment><USER13> In addition to the up and down vote there should be a button to nominate the article for the "HN Classics" section, a new list dedicated to all those topics that seem to surface every other week

</comment><comment><USER14> Is it possible to have a sincere discussion about this? If I falsely believe in free will then surely I don't have a choice in the matter.

<comment><USER11> Even if you have no free will, that doesn't mean that your mind can't be changed by arguments.

<comment><USER8> But, he can only be persuaded by the arguments that will necessarily persuade him, not necessarily those which correspond to reality. What merit is it to simply find the right button to push?

<comment><USER11> Lots of merit, because pushing that button will give an enjoyment feedback of being right.

Compare with adventure games that more or less consists of finding the right buttons to push in some order :)

<comment><USER8> You experience adventure games pretty differently from how I do.

Also note that "merit" and "enjoyment" are different things.

<comment><USER15> Of course they are. "Enjoyment" is something that can objectively defined, "merit" means whatever you want it to.

</comment></comment></comment></comment></comment></comment><comment><USER16> I have always wondered how well you can actually control psychological studies about why someone is thinking something.

<comment><USER17> In any case this area of research seems to open up a lot of opportunities for snake oil consultants.

</comment></comment><comment><USER18> OMG guys, let's get over this free will thing ok?

Free Will is an oxymoron. Will is supposed to be determined by you. Free Will points at our desire to think that our actions aren't determined by our universe, i.e. the desire to separate oneself from the observed determinism of our own universe.

It ain't gonna happen so long as you are capable of thinking. If you are thinking, you are determining your will.

Can't live a happy life without Free Will? I'm perfectly happy knowing that my thoughts, actions, and wants are a timeless pseudo-determined reality of this Universe. I feel at one with everything around me including people and inanimate objects. Why can't you?

Probably because some of us are conditioned to reject authority, and what bigger authority than the big U? Guess what... the way the universe appears to you is determined by the way you think. For example, just about everyone sees time as always moving forward. Why is thermodynamics and entropy the way it is? Because that is how we think, in terms of time/causality/consequences. If you reject the observed determinism of your universe, you are really just rejecting the process of your mind.

Which is fine, reject your brain if you want. Just know, that you're not rejecting some higher authority, rather you're just rejecting yourself.

</comment><comment><USER19> The article doesn't seem to be much about free will but rather about which choices are conscious and which are not.

Free will means that, out of all life's choices, I _can_ choose whichever I want.

It doesn't mean I'm always conscious about my choices.

It doesn't mean I would _not_ want to limit my choices consciously or unconsciously: suicide is very well within the free will of each person but few choose to exercise their free will that way.

It means there are no "don't"s or "can't"s. For example, if you think you _can't_ act in some controversial way in some social situation, you're wrong. You surely could, if you wanted to. You might have internal limitations such as that you fear too much. It still doesn't rule out that you absolutely could.

As long as there's no gun pointing at you, you can choose whatever you want. In fact, if there is a gun pointing at you, you can still choose your own way, even if you end up dead.

</comment><comment><USER20> I've noticed a similar phenomenon in certain business situations: Ever worked at a tradeshow booth or done product demos? One thing you'll surely notice is that over the course of interacting with hundreds (or thousands) of people, strong patterns will emerge. Different people will say the _exact_ same thing in certain situations, and they'll all think they're being super funny or super original and clearly the first person to think of that.

We may have "free will" in the conscious sense, but our brains are still, for the most part, wired the same way, and what we think is an original or free- response is likely part of a very common, very non-original pattern.

<comment><USER21> <http://en.wikipedia.org/wiki/Apophenia>

I believe it is better to form a hypothesis about a pattern first and then go about trying to prove or disprove it, even if empirically, rather than to observe an apparent pattern and then consider the same observation as proof that it is real.

</comment></comment><comment><USER22> I would argue that for practical purposes, free will should be redefined as the ability to face a choice, and the capability to choose. Our reasoning is irrelevant, the predetermined interactions of our particles is irrelevant.

The interactions of all atoms follow physical laws. Yes, in this regard the entire future is as set in stone as the past. The whole universe is like a burned CD playing until it ends.

Free will, for practical purposes is a higher level concept, that exists as a mental shortcut/concept in our brains to deal with what to eat for lunch, irregardless of the underlying atomic interactions which run this simulation we call life.

</comment><comment><USER23> I believe very strongly that free will is tied to the existence of randomness. Without randomness there can be no free will.

From the little I've read it appears that true randomness does exist, in that there are experiments where all causally relevant variables are controlled and yet the outcome is still uncertain.

I'm not convinced that there is true randomness in the universe however, and I guess that means I subscribe to some sort of hidden variable theory with regards to the aforementioned experiments.

<comment><USER18> I don't think free will has anything to do with randomness. Rather, if you assume that free will exists, then you are cornered into looking for it in randomness.

And you say yourself, that you don't believe in randomness in the universe. Even if there were randomness, it wouldn't explain much more than determinism because there is plenty of chaos without it.

Read my other posting here and try to figure out why you want to believe in free will.

</comment></comment><comment><USER24> Lousy title: the article doesn't seem to contradict free will at all. If people are more likely to keep a clean desk with the smell of cleaning fluid in the air, that still means that some people were not affected. Obviously those guys have free will. Nothing in the studies they referenced said "whenever this stimulus is introduced, people always do X"; that would demonstrate lack of free will. The cited studies demonstrate the opposite of the title.

</comment><comment><USER25> I'm digging the fact that scientists are finally catching up with the meta- humanity thinkers & tinkerers (philosophers, artists, writers, etc) i.e. unconscious will can be & has been extrapolated from first principles, i.e. this is old news. Still, exciting!

1) Rigors-of-academic-inquiry(oldnews) = new data = new model = new algorithms

2) Makes moving my research forward that much easier. Similar case: I went from getting an orders of magnitude brush-off from a theoretical physicist on the topic of string configurations and cellular-level biochemical reactions. A few years later, I see he is working with David Albert on Subjective Experience as a Window on Foundational Physics <http://www.ctnsstars.org/enews/news_team5.html>

\+ the recent the quantum entanglement in DNA paper on arxiv <http://www.technologyreview.com/blog/arxiv/25375/..>.

Embodied cognition, ghosts in biological machines, feels a bit like racing toward god. I can see how it can make some people feel uncomfortable. Still, it's what we're made to do, what the amalgam of our biology+experience gifts us with.

</comment><comment><USER26> I honestly don't understand how anyone can question that we lack free will unless one believes in a soul or some other kind of "magic". If all of our actions are governed by our brains, and our brains are simply a collection of particles obeying the laws of physics, where is the room for free will?

<comment><USER24> Physics may not be entirely deterministic. At the quantum level physics starts being about probability. (In fact, quantum physics is all about probability, something my grades wish I had understood while taking the course...) Maybe particles have free will: do I tunnel now or not? Not now, maybe later. Maybe the Heisenberg uncertainty principle is a reflection of the free will: you can determine either a particle's position or velocity as much as you want, but you give the particle an equal amount of free will to choose the other one.

</comment></comment><comment><USER27> We only get to choose how to respond or not respond.

</comment><comment><USER28> but if I decide to think again, am I then doing it because it was my decision?</comment>


Nano-nonsense (2010) - <AUTHOR> https://scottlocklin.wordpress.com/2010/08/24/nano-nonsense-25-years-of-charlatanry/ <comment><USER2> > This is an honest summary of Drexler's Ph.D. thesis/book

It is not. I'm disappointed to see such lazy dishonest rhetoric on the front page of a site for the intellectually curious. The thesis in question: [https://e-drexler.com/d/09/00/Drexler_MIT_dissertation.pdf](https://e-drexler.com/d/09/00/Drexler_MIT_dissertation.pdf)

I think the bright spot in all this is that people learned from what happened to Drexler's program for responsibly developing advanced nanotech and so far have kept the AI safety program from the same fate. Drexler wrote a recent book on that subject, btw: [https://www.fhi.ox.ac.uk/reframing/](https://www.fhi.ox.ac.uk/reframing/)

<comment><USER3> Worse, my quantitative, rigorous comment about yogurt-making is currently voted down to zero points: [https://news.ycombinator.com/item?id=21669311](https://news.ycombinator.com/item?id=21669311)

We need to clean this place up.

<comment><USER4> Kragen, those bacteria multiply, which I assume the nanobots do not? Then we would have a real problem ...

<comment><USER3> At first I thought it was unjustifiably unkind of you to refer to the ignorant downvoters as _bacteria_ , but now I see that wasn't what was meant.

The alternative to constructing atomically precise manipulators with other atomically precise manipulators is to construct them with macroscopic machinery such as scanning tunneling microscopes. Like writing a compiler in machine code with front-panel switches or copying an operating-system kernel with a handheld hole punch and paper tape, this may be feasible, but it will be extremely difficult; once we have a working atomically precise manipulator, it will be an enormously easier way to build more of them with it.

That's the reason for Drexler's prudent concern for safety protocols in advance of the actual development of the machinery.

Of course, there's no reason that the constructor itself need be a micron- scale device; the convergent-assembly proposals from Zyvex and Nanorex instead use macroscopic machines with a large number of nanometer-scale atomically- precise parts.

</comment></comment></comment></comment><comment><USER5> How can one stay on top of and get involved in the latest work in MEMS? Can someone elaborate on the difference between licensed software for MEMS multiphysics simulation like Comsol vs open source software simulated collaboration? Have open fab tool projects been helpful in creating equipment that could help amateurs do more scientific research at this scale? How could one attempt to experimentally validate Drexler's latest proposed 3d printer design with x-y-z axis photosteppers? [1] (Slide 14)

Silicon atom mechanosynthesis experiments have succeeded, but it seems there is not enough funding for direct to DMS experiments with pico-stabilized tooltips. Would it not be a good use of a billion dollar fund to experimentally research the DFT-simulated diamondoid minimal tooltip set? [2]

\---

[1] [https://www.energy.gov/sites/prod/files/2016/06/f33/Keynote%...](https://www.energy.gov/sites/prod/files/2016/06/f33/Keynote%20presentation%20-%20Drexler.pdf) [2] [http://www.molecularassembler.com/Papers/MinToolset.pdf](http://www.molecularassembler.com/Papers/MinToolset.pdf)

</comment><comment><USER6> It's a 2010 article. Not knowing anything about nano tech, the frustration sounds so similar to blockchain or any other fad.

<comment><USER7> Wow, it has been that long. I met Drexler when he was first saying that stuff. My big question was "how do you power this stuff". Even if you had nanomachines, building something big with a chemically powered system might take as long as growing a tree. Maybe you could hook in external electrical power somehow. But the "clouds of nanomachines floating around" concept seemed to have a serious power problem.

"Nanotechnology" today is mostly surface chemistry. Surface chemistry is important, but boring. IC technology, modern battery technology, and membranes for separating things like salt and water are all based on clever tricks in surface chemistry. It's called "nanotechnology" to make it sound cool.

Amusingly, the IC fab people, who really do put atoms almost exactly where they want them, don't use the term.

<comment><USER8> Today's paperclip monster is yesterday's gray goo. Today's AGI is yesterday's nanoscale economy. All run into obvious mundane practical challenges like power, resources, scaleability, stability, error correction, and so on.

Of course if you _assume_ those problems are easily solvable implementation details you can produce all kinds of dramatic speculations - which (IMO) are mostly nonsense.

</comment></comment></comment><comment><USER9> Discussed at the time: [https://news.ycombinator.com/item?id=1629525](https://news.ycombinator.com/item?id=1629525)

</comment><comment><USER10> Perhaps it was true when this was written, but it's certainly not true now that "mechanical objects on microscales do not exist". The whole field of MEMS is about them, which includes such prosaic things as smartphone gyros/accelerometers.

<comment><USER11> Even then it was not true, however nanoscale manufacturing as envisioned by Drexler definitely does not exist.

MEMS objects are made by lithography not pushing atoms around, and are extremely simple, usually just single chemical compound. (Sometimes a doped semiconductor.) Said simple structures are often very dissimilar to complexity envisioned by Drexler.

By the way, first M in MEMS is micro. It's not NEMS. NEMS also exists, but again, it's made with lithography and chemistry, not any level of direct molecular manipulation.

Heck, pharmacy chemists make nanostructures. (Liposomes and other vesicles specifically, for mechanical purposes. Peptides. Even protein assemblies.)

</comment></comment><comment><USER12> "Maxwell-Demon"? :)

<comment><USER13> I took it as a reference to [https://en.m.wikipedia.org/wiki/Maxwell's_demon](https://en.m.wikipedia.org/wiki/Maxwell's_demon)</comment></comment>


Single mother-to-be supports herself by building websites, needs help - <AUTHOR> http://imgur.com/gallery/mTRtiun

<comment><USER2> Thank you for posting this! I really appreciate the support and have had so many positive responses. I believe I'm going to be able to cover rent and the electric now, thanks to all the purple requesting services and offering their support and encouragement. I also have new projects lining up for the next two months, which will help me maintain a steady income and continue to provide for my pending baby girl. Thank you for everything, and I will keep everyone posted.</comment>


February 28th DDoS Incident Report - <AUTHOR> https://githubengineering.com/ddos-incident-report/ <comment><USER2> Very cool that they are able to change BGP advertisements from ChatOps, achieve convergence and mitigate the attack in all of 4 minutes, that is some insane engineering.

<comment><USER3> Meh, or just block UDP to your networks that have no reason to run UDP. Every carrier will do upstream ACL's these days. 5 years ago that wasn't the case. These days, they all do. Some free, some charge.

re: chat ops vs a web page. It's just a single BGP advertisement -- big whoop. Chatops is just hipster famous right now.

<comment><USER4> A snarky reply like this comes up every time there's discussion of a DDOS, but it ignores the fact that there is some point that has to filter that UDP traffic, and if that point is saturated, the DDOS still worked. Mitigating attacks of this size isn't a firewall rule or a support ticket with your ISP.

<comment><USER3> Snark or not, the traffic is filtered upstream before your handoff. If you pick your carriers well, there's not a problem. Many carriers have turned upstream filters into a product. NTT's DPS Lite springs to mind.

This just comes down to experience and knowing how to build a network. I'd think that Github would have people knowing how to architect this. They've been through a few DDoS before.

Edit: It looks like Github uses NTT for traffic. Hello Github Netops person, you need to call your sales rep and turn on DPS Lite. It's like $100 per 10gig port and you get full ACLs. Telia, another one of your carriers, will do this too. At least they have for me. Level3 though? Lol kick that sorry network to the curb

Also, get another /22 allocation so you can at least separate out your DC- origin traffic from your customer traffic.

<comment><USER5> It's interesting that on HN, some experience doesn't get rewarded, just because there's some rather opinionated language. The majority of voters are barely exposed to these kinds of overwhelming attacks, leaving practical analysis to be buried unless it's got some big company name drop to legitimize it.

<comment><USER6> Maybe the experience isn't rewarded because of said opinionated language?

I mean someone can be right, but that doesn't give that person the right to be dismissive. Treating ignorance with disdain isn't going to make anyone smarter.

</comment></comment></comment></comment></comment></comment><comment><USER7> Am I old-fashioned to raise an eyebrow when I discover that Memcached servers are running visible to the public Internet? This strikes me as approximately as bizarre as having a database server that accepts connections from the public Internet.

In my day, such back-end services were either simply not connected to the Internet (connected via a private network to the application services), firewalled, or at the very least, configured to listen for and respond exclusively to connections from known front-end or application services.

Is this sort of deployment architecture falling out of favor? My casual observation is that cloud architectures—at least the ones I've seen employed by small organizations—are more comfortable than I am with services running with public IPs. What is going on? Am I misunderstanding this in some way?

<comment><USER8> A bit off-topic, but I had the same thought when I read about Jenkins servers on the public Internet in this piece.[0]

But when I read that he had found a public facing Jenkins server owned by Google, I figured I must be missing something.

I run a 2 man shop, but I still keep things like Jenkins behind OpenVPN. Why would anyone leave Jenkins open? There must be a reason, right?

[https://emtunc.org/blog/01/2018/research-misconfigured- jenki...](https://emtunc.org/blog/01/2018/research-misconfigured-jenkins- servers/) [0]

<comment><USER9> Google's "Beyond Corp" initiative [1] discourages trusted networks and VPNs in favor of secure services on public networks. By trusting the network to provide a level of security, you are more likely to be vulnerable to escalation attacks by bad actors that are able to access your private networks. You're also more likely to encourage legitimate users to set up workarounds that result in secure network breaches. Typically they use an Identity aware proxy in front of the service, but services can have a public view as well.

To answer your second question, I work for an open source non-profit software company, and we run some of our jenkins servers, which do continuous integration builds, publicly available so that community contributors and users can see build failures. Google has a number of open source projects that probably have similar goals.

1\. [https://cloud.google.com/beyondcorp/](https://cloud.google.com/beyondcorp/)

</comment></comment></comment><comment><USER10> This is a great example of why it's important to pick secure defaults when writing software, especially software that is often deployed on high bandwidth servers or cloud instances. If no listening interfaces are specified then the default should be to exit with an error, not listen on everything!

I also wonder if you can store something in a memcached cache that looks like a valid request, then reflect that with the source IP of another memcached server and let them burn each other out...

<comment><USER11> Shortly after Cloudflare's blog post, memcached pushed a commit that disabled UDP by default:

[https://github.com/memcached/memcached/commit/dbb7a8af90054b...](https://github.com/memcached/memcached/commit/dbb7a8af90054bf4ef51f5814ef7ceb17d83d974)

<comment><USER12> That's good, but they should go a step further and stop listening on all addresses by default.

<comment><USER13> And it's going to take a while for the new version to propagate to a released version, then to distributions, then to customer images and scripts, etc.

</comment></comment></comment></comment><comment><USER14> Is there any legitimate reason to spoof a source IP? I don't think there is, why don't ISPs block any traffic with a source IP that isn't in their network. And then the rest of us block any ISPs that don't do that.

<comment><USER15> Yes, absolutely - there are plenty of scenarios like, ironically, DDoS mitigation where you use source IP spoofing/asymmetric routing.

It's still possible to restrict it, but simple RPF checks don't always cut it.

<comment><USER14> How could source IP spoofing help with DDoS mitigation?

<comment><USER16> This particular case relied on botnets being able to spoof their their source IP to match github's so the memcached responses would go to github.

Google 'DRDoS attacks' to learn more. They are responsible for most of the largest volume attacks IIUC.

<comment><USER14> I understand the attack, I dont understand how it could be mitigated using the same technique.

</comment></comment></comment></comment></comment><comment><USER17> DDoS is a reminder of how broken the internet is.

How many times are we going to see the HN comment that says "lol why do so many people use Cloudflare? I don't need it for my blog!"

Naive decentralization (naive trust) doesn't work.

<comment><USER18> Now that we are moving away from net neutrality, can we not get ISPs to do DDOS protection so that we don't need specialised services like Cloudflare to be layered on top of simple sites?

<comment><USER19> ISPs absolutely could, but having worked near this space previously, it really isn't as easy as it sounds, both the detection and the mitigation, and ISPs are not particularly equipped to handle it themselves right now. There's a lot of money to be made there, though.

<comment><USER20> OVH do, though i've never used it as I ceased being a customer a while ago.

There are still a zillion low-end bottom feeding web hosts who wouldn't do anything about this, though.

<comment><USER17> OVH only employs some heuristics. Which are next to useless because a percentage of a volumetric attack is still a volumetric attack.

</comment></comment></comment></comment></comment><comment><USER21> Wow, 1.35Tbps? That's a lot for a DoS attack, right?

<comment><USER22> According to [0] that is around 1/400th of total internet traffic per second. This begs the question: who has that kind of botnet at their disposal and why are they targeting Github?

Edit: The attacker didn't need nearly that kind of bandwidth to execute this attack. See [1]

Edit: 1/50th -> 1/400th (bits vs bytes)

[0] [http://www.internetlivestats.com/one-second/#traffic- band](http://www.internetlivestats.com/one-second/#traffic-band)

[1] [https://news.ycombinator.com/item?id=16493497](https://news.ycombinator.com/item?id=16493497)

<comment><USER23> memcached reflection: [https://blogs.akamai.com/2018/03/memcached- fueled-13-tbps-at...](https://blogs.akamai.com/2018/03/memcached- fueled-13-tbps-attacks.html)

<comment><USER24> Who is exposing their memcached instances on the public internet? Who is not filtering outbound UDP traffic from their memcached instances?

Rhetorical of course. Akamai should have logs of their offenders. Off to scan for offenders and notify their providers!

<comment><USER25> During some analysis we did notice that at least some cloud providers default to having instances with public IPs (with no network-level ACLs) by default, and some Linux distributions default to having memcached listening for UDP traffic and binding to `0.0.0.0` by default as soon as it's installed. The unfortunate combination of these result in the machine being vulnerable to being used as an amplification vector in these attacks.

<comment><USER26> This is one area where I really disagree with Debian and derivatives default behavior of starting a service immediately after installation and not having a firewall enabled by default.

If I install a service on CentOS/RHEL/Fedora it is disabled by default, if I start the service firewalld will block traffic until I have explicitly enabled a rule to allow it (or explicitly stopped and disabled the firewalld service).

Does this prevent people from making poor decisions, like just blindly starting the service without reading the configuration file, or disabling firewalld/enabling a rule without checking the configuration first? No, it doesn't - but that small hurdle at least prevents people from inadvertently turning on a service and opening it up to the world just by installing a package.

<comment><USER27> As a compromise, Debian also comes with a secure-by-default configuration. In the case of memcached, the service is configured to listen on 127.0.0.1.

<comment><USER26> Thankfully that is one thing they do pretty well in most cases, though there are some (apache2, for example) that do listen on all interfaces by default. While even services like Apache may have secure configurations by default, it can often be installed by other programs that link or copy their own configuration files into the apache config directory - and then all you need is a PHP vulnerability or whatever.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER28> BGP Sim during the changes [https://stat.ripe.net/widget/bgplay#w.ignoreReannouncements=...](https://stat.ripe.net/widget/bgplay#w.ignoreReannouncements=false&w.resource=AS36459&w.starttime=1519838365&w.endtime=1519839625&w.rrcs=0%2C13%2C16&w.instant=null&w.type=bgp)

</comment><comment><USER29> Side observation: kudos to Sam Kottler for level-headed acknowledgement of the business impact of an incident like this to Github's clientele, and appearing to own it. Well done, sir

</comment><comment><USER30> What's the point of a DDoS on GitHub anyway? Extortion or pure malice? I don't see them paying a ransom to stop it so why bother?

<comment><USER31> As another comment points out: If you are trying to sell your DDoS services "Hey watch me bring down github" is a pretty powerful sales tool.

</comment></comment><comment><USER32> Here is the commit to disable UDP by default [https://github.com/memcached/memcached/commit/dbb7a8af90054b...](https://github.com/memcached/memcached/commit/dbb7a8af90054bf4ef51f5814ef7ceb17d83d974) The default should also be changed to only listen on the loopback device.

</comment><comment><USER33> These attacks are often described as denial of service attacks, but I wonder if many of them aren't employed as cover for an intrusion attempt. Is it possible that intrusive traffic could be mixed in with such an attack?

<comment><USER34> A DoS attack is, by literal definition, an attempt to overwhelm a host until it is forced to _deny service_ to valid user requests. Are there intrusion techniques that both bring down the server and break into it at the same time? I'm not a security expert, but that doesn't seem like it makes a whole lot of sense to me.

<comment><USER33> Maybe in the milliseconds between packet swarms, or immediately before or after? Just seems like a lot of resources to pour into an attack that was defeated in a few minutes. To what end?

<comment> w0rd-driven There's validity to the approach of sending packet swarms to cover intrusion attempts but the traffic levels were more than a small amount of cover. It is possible that it was designed as a smokescreen and someone's calculations were wildly incorrect. No one's safe from off by one errors :>

</comment></comment></comment></comment><comment><USER35> What does an incident like this cost to Github in terms of the extra capacity added? I guess the potential loss of business is way higher, but still very curious about the magnitude.

</comment><comment><USER36> Awesome engineering work (y)</comment>


Ask HN: Does your partner/spouse work? If not, how is your life together? - <AUTHOR> Hi there. I'm an IT guy, with a reasonable salary. My wife has been under a lot of stress for the last three jobs (over a 5 year timeframe) and recently we've been discussing the possibility for her to simply stop working, and dedicate her time to raising kids, taking care of our home, etc., for the long term.
At first it sounded a bit scary to me. I used to believe that both people in a marriage should be both financially indipendent, and both should  feel fulfilled by an occupation (or later on, by some type of activity). However, on second thought, I am more open to the idea.
I am wondering if any of you has experienced something like this, and if you can help me by sharing your thoughts, comments, opinions, etc. It will be greatly appreciated.
Thanks! <comment><USER2> My wife used to work but has spent the last 7 years as a stay at home mom.

There is nothing easy about being a stay at home parent, it is a full time job. We had some adjustment when it changed but there are some awesome benefits to it if you treat both of each other fairly.

You have to remember if she does stay home that she will have a full time job. Your jobs will differ but neither is more valuable then the other and neither of you have a lock on having it easy. My wife takes her "job" of managing the house and raising the kids seriously and I have tons of respect that she can do it and that I don't have to worry about dinners and tons of little details of managing a household.

At the same time, she needs a break from time to time no different then you need a day or two off every so often. Different then a vacation just a break.

Honestly it will take some adjustment but it has been one of our best moves for a whole host of reasons. If you have specific questions let me know, not that I have all the answers but happy to share any experience I have.

<comment><AUTHOR> Hey Davis, thanks for sharing your experience. It is helpful (and promising!).

I guess at this point my questions are semi-specific, given that we are only considering the switch. The first couple that come to mind:

1) How did you deal with the financial side of it? Besides the fact that I guess you pay for every household expense, I guess she has a small stipend from you to buy her own stuff?

2) How is this seen from your respective parents? Did they raise concerns, doubts, or were they cool with it?

3) What's the single biggest issue that you had because of this switch?

Thanks!

<comment><USER2> 1\. Joint account. What money is made is for the family we don't have a concept of mine or hers. What we agree to is a budget for misc expenses for both of us. If either of us wants to buy something over a certain dollar amount then we talk about it and make it happen. As for presents we generally use a credit card and pay the bill when it comes due but this keeps the gift "hidden" until the special occasion.

2\. We are both in our 40's and on second marriage so honestly probably not as relevant. But I'll tell you we both learned from our prior relationships that finding what works for us is more important then what anyone else thinks or what anyone's opinion is but our own. Easier said I know but it is very true.

3\. Finding balance. Agreeing what the split of responsibility was and working through it. To complicate our situation a little I started working from home about 2 years after we made the switch. Which then meant I basically invaded her "space" all day and through off her schedule. So that was honestly the single biggest issue we have had to figure out. It took probably 2 years, no shit, to figure it all out.

Question you didn't ask. She has to feel in equal control like a solid partnership over things like the finances etc. one of you might be better at day to day management of finances so let that person do it but never should she have to ask you for money just cause you have the income producing job. That is a receipt for divorce, resentment and overall leads to control issues. Also make sure she keeps active credit in her name only too. Don't let her credit suffer just cause she isn't actively working. Keep a credit card in her name and keep it current of course. This is really important for both of you.

Last point, communication about everything and each of your expectations will make it way easier. You don't have to initially agree but you have to come to an understanding about all the big stuff. Like division of responsibility, finance etc.

Good luck! We love how our situation works but it takes some effort to keep everything good, no different then if you were both working just some different issues.

<comment><AUTHOR> Wow, this is gold for me. I really thank you for sharing it. I hope you realize how difficult it is for me/us to think about this "topic" and be able to start planning for some version of it, without much data or friends in similar situations to rely on.

Luckily, most of your advice is very close to what we have already implemented (she has worked for only 3 years over the last seven, primarily because of visa requirements etc - we moved from Europe to Singapore, then US), and I never had her ask for money. She also has her own bank account which I make sure never gets too low, and where she usually collects most of her work income. She's also very good at spending money only on good things, and not wasting it (which otherwise would have made me nervous - e.g. "I work hard to make money, and you spend it on a Gucci bag?").

I also agree that communication between us is important - it has been helpful so far, and I hope it will continue to be in the future.

</comment></comment></comment></comment><comment><USER3> We're 23 years into the solo working parent life. Our sons are now college age and I'm certain they benefitted tremendously by having the constant presence my wife has provided. We're doubly lucky in that I've worked from home all that time. This has afforded us the opportunity to be fully engaged in our children's lives and we've milked the parent experience for all it's worth. It's a luxury that highly recommend to anyone who can swing it. I wouldn't change a thing but it has required that we be much more careful (aka frugal) with our finances.

My Harvard MBA wife would tell you that she wishes she'd done some job-sharing or another more engaged professional work (beyond the odd consulting job here and there). It's very hard to find an employer who'll let her back into the workforce after such a long hiatus.

<comment><AUTHOR> Hey, good to hear it was a blast for you.

And yes, unfortunately there seem to be little flexibility for people that are out of work environments for such a long time.

Thanks for sharing your experience. Very useful.

</comment></comment><comment><USER4> Here in The Netherlands, it's common to get a part time job after having kids. We roughly divided tasks as follows; I take care of the household, and she takes care of the little one. So I work 4 days per week, and my girlfriend works 2,5 days. The kid is three years old.

However, that was a conscious decision related to having a baby. It does sound like due to the stress your wife experiences, she simply quits working. Couldn't she find a better/nicer job with a more relaxed work pace?

<comment><AUTHOR> Thanks for your input. I forgot to mention that we've been considering having kids for some time now.

And yes, she might eventually look for a reduction in hours worked, or (long term) for a different type of job altogether.

<comment><USER4> > she might eventually look for ...

Just a warning here. I see you say "eventually". However if she does want to go back to work after pregnancy, her job should be the right one. As a woman, you do _not_ want to go back to a stressful job after having a baby. This happened to us and almost cost us our relationship.

Thus she might want to shift priorities and look for a better job on the short term.

<comment><AUTHOR> That's a good point! I agree with you, that's not what I meant in the previous comment :)

</comment></comment></comment></comment><comment><USER5> My wife and I have done this for a few years, for reasons that sound similar. Works great for us.

In our case, she has always done the books and we have always been able to have enough carrying around money.

Budget carefully and make sure you set aside time for each other.

</comment><comment><USER6> I was a fulltime wife and mom for two decades. AMA. :-)</comment>


Show HN: Trendeca – Radically Simple Data Acquisition for Hardware Engineers - <AUTHOR> https://trendeca.com/ <comment><AUTHOR> Hello everyone - I'm a hardware / software engineer and I mostly work on IOT medical devices for small companies / startups.

When testing my prototype devices, I found I spent too much time setting up test equipment to acquire basic data. I made my own data acquisition device – totally focusing on ease of use – to fix this.

I made a small batch of Beta devices to share with my fellow engineers. Contact me at firstname.lastname@example.com if you would like one. We will find a price that works for you.</comment>


12 Factor CLI Apps - <AUTHOR> https://medium.com/@jdxcode/12-factor-cli-apps-dd3c227a0e46 <comment><USER2> Don't get me wrong! I love command line apps. But I wonder if we all have a bit of an Stockholm syndrome... there are several things that suck about them...

While writing this I'm thinking on my experience trying to do anything with ffmpeg or imagemagick... or even find.

* For any sufficiently complicated cmd line app, the list of arguments can be huge and the --help so terse as to be become useless. For man pages, the problem is the opposite... the forest hides the tree! I'm sure we all end up using google to look for example invocations.

* Very often completion doesn't work, since custom per-app machinery is needed. For instance: git-completion for with bash-completion.

* Sometimes I end up passing the help output through grep, then copy-pasting the flags from the output, and then hoping I got the right flag.

* ...how about things like regular expressions parameters... always so hard to remember the escaping rules! (and the regex flavor accepted by each different app).

* Not to talk about more complicated setups involved -print0 parameters or anything involving xargs, tee, and formatting with sed and cut, etc.

Is there a better way? Not sure. I like powershell a bit but some of the things I mention above still apply.

I think we may be able to get a workflow that is a bit closer to the tooling we use for writing programs while not being perceived as verbose and heavy (I'm thinking, the kind of workflow I get with a Clojure repl).

<comment><USER3> At this point I'm not really sure what makes command-line so great. We should have something like it in the GUI sapce that works much better but, like you said, "stolkholm syndrome".

Why can't a pipeline be a more complicated multi-io workflow? In a 2D GUI this would be trivial to construct and read, but in a 1D command line it would get confusing in a hurry. And the concept works much better with AV, I can easily construct and reason about complicated arrangements of audio and video inputs and outputs, with mixers, compositors, filters, shaders, splitters, etc. between them.

Instead we worship text. Is that because manipulating text is actually more useful, or because our tools are only good for working with text?

<comment><USER4> Text is exact, programmable, repeatable and transmissible.

exact: in many GUI tools, you can have non-default settings that you changed via menus. Where are they stored? Which ones are currently active? Does it matter that you selected four objects first, then a transform tool, then another object?

programmable: > find /var/spool/program/data -name foop* -mtime +3d -print

vs "open the file manager, go to /var/spool/program/data, sort by name, secondary-sort by last modification time, find the ones that are more than 3 days old, make sure you don't slip"

repeatable: OK, do that again but in a different directory.

transmissible: here's the one-liner that does that.

Now, your specific requests are about audio and video toolchains, where I will admit that reasoning about flows is easier with spatial cues -- but I'd really like the output of that GUI to be an editable text file.

<comment><USER5> Command line is not the only HCI that can use text. Also, no one (except immense mental inertia) stops developers from producing serializable graphical interfaces.

<comment><USER6> I think the macro language of WordPerfect 5.1 was one of the most awesome serializable interfaces ever.

And they scrapped it in WP6 for some shitty object oriented version that lacked all the "serializable workflow" of the previous one.

</comment></comment></comment></comment></comment><comment><USER7> > Error: EPERM - Invalid permissions on myfile.out

> Cannot write to myfile.out, file does not have write permissions

> Fix with: chmod +w myfile.out

I actually much prefer:

"can't write myfile.out: Permission denied"

This shows the same information as the first 2 lines combined from the example, and the 3rd line is not necessarily the correct way to fix the problem anyway (e.g. you might be running it as your user when it should be root, chmod +w would not help).

If you are so convinced that chmod +w is the way to fix the problem, why not just do that and carry on without bugging the user?

And having each error confined to one line also means it's much less likely that some of the lines are missed, e.g. when grepping a log.

EDIT: And to add to this: it's sometimes useful to prefix the error messages with the name of the program that generated them, so that when you're looking at a combined log from different places, you know which of the programs actually wrote the error, e.g. "mycli: can't write myfile.out: Permission denied".

<comment><USER8> So, I understand the basis of your comment. You have the knowledge to know that there are other things that may be "the right way" given your situation. I think what the author is getting at is that there are users who don't have that knowledge. Giving them a hint that is verbose and non arcane can make a world of difference. Speaking from personal experience, there are many developers that I have met who don't have basic *nix knowledge, much less knowledge of a terminal. The reality of the situation is that a business is going to hire people regardless of that ability. They want someone who can move the features out the door. Whether this is good or bad is probably beyond this conversation. I think, for those users, these sorts of helpful hints are extremely important because it makes them feel like they aren't stuck and helpless. I think that, to your point, it may be useful to have the CLI offer a "pro" mode in which you could set a config to not give you as verbose error messages. Annoying? Yes. However, it would strike a balance and serve both needs.

<comment><USER9> Then again, on a recent linux system, the non-ability to write to the file might be permissions. Or an immutable attr, or selinux, or apparmor, or setfacl flags or a RO mount where it lies. As soon as you decide to print out the solution to "can't write to: X" you are in for a page full of advice on what to look for. Perhaps the disk was full, perhaps uid was wrong, perhaps the 5% reserved-for-root-only kicked in. You'd end up writing a unix sysadmin guide, and then perhaps the parent dir had too strict perms to allow you to write to a file in it...

<comment><USER10> Also, on an unrelated note, I would never ever suggest novice users to blindly just give `chmod +w` to random locations. This is only marginally better than the `chmod 777 <root-folder-name>` that used to be so spread out in many (e.g. PHP-related) tutorials a decade or two ago.

<comment><USER11> Agreed, though perhaps it is just a bad example. I could imagine a situation where a single line of advice could be useful outside the realm of filesystem security or disk usage.

</comment></comment></comment></comment></comment><comment><USER12> > 7\. Prompt if you can

Please don't. There is nothing wrong with interactive tools, but by default, they should not be. So instead of making non-interactive session possible via flags, the default should be to be non-interactive. If there is an option to start an interactive session, everything is fine.

Otherwise, you would never know when your script could run into some kind of interactive session (and therefore break; possibly after an update).

<comment><USER13> My interpretation was that the prompt is for required information. In the example graphic, "run demo" really does require that "stage" be specified. This is considered more user-friendly than simply crashing. If you don't want to see the prompt, provide that information as a flag or in a config file or whatever.

<comment><USER14> User friendly until the user decides to invoke that command in a cron job and ends up with a headless process waiting for additional input.

<comment><USER13> Anyone who doesn't test cron jobs before saving them deserves whatever she gets. There are scores of ways for cronjobs to fail. b^)

<comment><USER14> Well, this is not a cronjob that failed, it's just waiting for input.

Let's say that I did test the cronjob but that it starts "failing" after an update to the tool. My fault, I know, but at least I get mail when it fails while I won't if it's just waiting for input.

<comment><AUTHOR> This scenario would only happen if a flag became required. Prompting or not it would still be an issue. (And it wouldn't prompt as this is a non-tty environment)

<comment><USER14> _> Prompting or not it would still be an issue._

Yes, but in one case the issue would result in a mail because the cron job failed, and in the other case the issue would just cause the the process to hang indefinitely without notice

<comment><AUTHOR> NO IT WON'T HANG. I give up. I don't know how else to try to explain this to you.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15>
        Unless you already know your users will want man pages, I wouldn't bother also outputting them as they just aren't used often enough anymore.

I don't know where this is coming from, me and my colleagues are reading man pages every day. I would be interested how much others read them.

<comment><USER16> I strongly disagree on this one too.

That's the first place I look for help and it annoys me to no end when a CLI program that doesn't come with one.

I stopped taking seriously the article at that point and quickly skimmed through the rest of it.

Man pages are a great unix culture heritage, please new developers don't give up on them!

<comment><USER17> I myself also love reading man pages, but speaking of compatibility, I have to say that "--help" is a more universal way of showing help pages. Of course it's better to have both of them though.

<comment><USER18> \--help is fine, but almost never a substitute for a full man page, except for the most trivial of applications (unless your --help is as complete as a man page, in which case... good on you for providing full documentation, but I'll hate you a bit every time I unthinkingly drop two hundred lines of text in my terminal.)

<comment><USER10> Unless it just opens the man page if it is so long. Like git.

</comment></comment></comment></comment></comment><comment><USER19> > I would skip man pages are they just aren't used that often anymore.

I understand that man pages might represent a minority, but I cannot express enough how wonderful it is to get the full manual of a program without interfacing with the web. Not to mention how powerful that is, since most apps have short names that are difficult to search for, but how accessible that makes the application.

<comment><AUTHOR> For people that like man pages (there appears to be lots of you) do you think that man pages are _more_ important than web or in-cli docs? Or just that they should be written in addition to and not missed out on?

My (current) position is that they're useful, but not worth the extra effort for most CLIs. It's a cost-benefit thing.

I'm genuinely curious as I've never had anyone request man pages in our CLI.

<comment><USER20> > do you think that man pages are more important than web or in-cli docs?

Yes.

* Web docs are a problem because I don't always have access to the internet when trying to do something on my computer, and usually there are so many kinds of web doc generators that you have to figure out how the information you want is laid out. Web docs are useful as a quick-start guide or a very lengthy reference guide -- but not for the common usecase of "is there a flag to do X?"

* In-CLI docs are a cheaper version of man pages. In most cases, the output is larger than the current terminal size so you end up piping to a pager (where you can search as well), and now you have a more terse version of a man page. Why not just have a man page?

Man pages are useful because they have a standard format and layout, provide both short and long-form information, and are universally understood by almost anyone who has used a Linux machine in the past. "foo --help" requires the program to know what that means (I once managed to bootloop a router by doing "some_mgmt_cmt --help" and it didn't support "\--help" \-- I always use man pages now). One of the first things I teach students I tutor (when they're learning how to use Linux) is how to read man pages. Because they are the most useful form of information on Linux, and it's quite sad that so many new tools decide that they aren't worth the effort -- because you're now causing a previously unified source of information (man pages) to be fractured for no obvious gain.

I still add support for "\--help" for my projects (because it is handy, I will admit) but I always include manpages for those projects as well so that users can actually get proper explanations of what the program does.

> I'm genuinely curious as I've never had anyone request man pages in our CLI.

Honestly, I would consider not using a project if an alternative had man pages (though in this case it would be somewhat more out of principle -- and I would submit a bug report to bring it to the maintainers' attention).

<comment><USER21> > I still add support for "\--help" for my projects (because it is handy, I > will admit)

Some applications (e.g. Git) make "\--help" redirect to man. What do you think of that?

<comment><USER22> Personally, I still pull up "man git-pull" or similar. I'm actively annoyed that I have to remember that the AWS CLI is different in this regard.

Not to mention that using "\--help" for man pages requires I open up a separate window when I typically just want a quick reference to the most used flags.

Moving man pages to a different command is like coming up with an alternative icon to the hamburger menu for your regular UI. Sure, all the functionality is still there, but it requires a full stop and search to remember where to find it.

</comment></comment></comment></comment></comment><comment><USER23> I almost stopped reading at "I would skip man pages", but the rest of the article was mostly great advice.

I disagree about 11 (using "main_command sub_command:sub-sub_command" rather than "main sub sub-sub" syntax), but it's mostly a matter of taste.

Seriously, though, if you've already taken the time to write documentation, then there's no reason not to also generate a manpage. Just using pandoc to convert your, say, README.md gives good-enough results:

pandoc -s -f markdown_github -t man -o your_cli.1 README.md

(There probably are other good conversion methods.)

Why I like man:

Advantage over online docs:

It's offline and available directly in the terminal, without having to open a browser and it has a distraction-free, clean look. The only slight disadvantage is the lack of support for images, which are occasionally helpful, but in a pinch, for some use-cases, you can have ascii diagrams.

Advantages over "\--help":

1\. Conventionally, "\--help" just provides a brief rundown/reminder of the options, so having full documentation is valuable.

2\. If "\--help" provides the full docs then:

a) You lose the option of having the brief rundown, which is also very valuable.

b) "man command" is slightly faster than "command --help" :p (yes, it is a slight pity that accessing the full docs is faster than accessing the brief version, if you use convention).

c) man deals with things like having nice output, with proper margins, at different terminal widths.

d) man deals with the formatting for you, providing consistency with all other applications.

FWIW I think that texinfo is (mostly) even better than man, as it considerably improves on the navigation, but it's been crippled by the FSF-Debian GFDL feud, which meant that the info pages weren't actually installed on many systems, and it's mostly a lost cause now.

<comment><USER24> > Advantages of man over "\--help":

You can have the best both worlds if the manpages are built automatically from the "\--help" output (e.g., using help2man). Then you can have "-h" give a brief rundown and "\--help" give the full docs.

> FWIW I think that texinfo is (mostly) even better than man, as it > considerably improves on the navigation

I am curious about that. Do you really like texinfo navigation? I find it completely unusable, to the point of prefering to download and print a pdf from the web instead of opening (gasp!) the dreaded "info" program.

<comment><USER25> I use info browser from Emacs and like it very much. The best benefit is that you can stuff a whole book into info pages - and projects using info usually drop their _full_ manual in there, to be perused off-line and distraction- free.

<comment><USER24> How do you search for a word inside the whole info documentation of a program (say, gcc), and cycle through all appearances of that word? I never managed to do that (which is trivial for manpages).

<comment><USER25> Don't know how it works in regular info browser; in Emacs's info browser, incremental search can cover the entire manual (or even all info pages) if it fails to find a phrase on the page you're currently viewing.

<comment><USER26> It does, see `info '(info) Search Text'`.

</comment></comment></comment></comment></comment></comment><comment><USER27> > 12\. Follow XDG-spec

I'm so glad to see this included. I don't like $HOME being cluttered with .<app> config directories, but worse than that, far too many when releasing on macOS say Oh Library/Application\ Support/<app>/vom/something is the standard config location on Mac, so I'll respect XDG on Linux but on Mac it should go there. No! Such an unfriendly location for editable config files.

<comment><USER28> I agree that seeing a bunch of ~/.<app> directories is annoying, but at the same time I do think that it makes sense for each application to manage its own hierarchy, rooted under e.g. ~/.apps/<app> instead of splitting it into ~/.config/<app>, ~/.local/share/<app>, etc.

Regardless, I think it probably makes sense to have a uniform interface for getting said directories, so that however the OS decides things should be laid out, the developer just needs to `local_config_dir(app_name)`. If the user (or at least administrator) can decide between <app>/<function> and <function>/<app>, all the better.

<comment><USER29> The reason ~/.config/app is superior, is that then you can e.g. backup all your configs, or remove your cache, or store ~/.local and ~/.cache on a local fs and the rest of ~ on NFS.

Do you have to use ~/.config/app/ or could you just use ~/.config/app.conf?

</comment></comment></comment><comment><USER30> This is all great advice.

The one thing this does miss is distribution, which is a HUGE part of offering a great CLI app. Specifically, I'd say:

1\. Make your OFFICIAL distribution channel the primary package manager on each platform (ex: on Mac, homebrew. Ubuntu, apt/snap). Beyond that, support as many as you have capacity to.

2\. Also offer an official docker image which fully encapsulates the CLI tool and all of its dependencies. This can be a great way to get a CLI tool loaded into a bespoke CI environment.

<comment><USER31> Homebrew is NOT the primary package manager on Mac and I wish people would stop perpetuating that falsehood. Apple includes pkgutil/pkgbuild in the OS and that official package management strategy plays much better with corporate IT control of managed machines.

In my experience, Homebrew always eventually results in pain and complex debugging and it's almost impossible to audit software it installs to prevent the installation of prohibited or dangerous software.

It's really not that hard to build a .pkg file and developers that want to properly support the Mac platform should go down that path before offering Homebrew support.

<comment><USER32> The best part is that some people think 'brew' is a solid package manager and then show up in Linux and try to make 'linuxbrew' happen (no really, it is a thing).

I just wish everyone would take a day and read an intro to nix/nixpkgs and the world would really be a better place. There are so many "popular" hyped tools these days that can barely do a fraction of what is going on in the Nix ecosystem, but it doesn't seem to get the hype that brew, buildkit, linuxkit, etc all seem to get.

<comment><USER33> Say what you will about Homebrew, but we need more package managers that can easily install without root. Not everyone has the time and energy to compile from source, and often it's a circular problem - I need to compile and install Python 3.7, which needs openssl, which needs to be compiled from source, which has even more dependencies... ad nauseam.

<comment><USER32> Why do we need more of them when we already have a number that are capable of deploying into a home directory? As someone who has worked on software that has needed packaging, and someone who tries to help out with packaging for a distribution, I can't imagine why we need more for the sake of having more.

Per my original comment, nix can do this, for example and already has an enormous number of packages packed, pre-built/cached, ready to go.

</comment></comment></comment></comment></comment><comment><USER34> I disagree on the 2nd point. Flags prevent globbing by the shell and make the help text less clear.

Consider a usage line like this:

        prog <user> [password]

This tells you which argument is mandatory and which argument is optional in a second, without searching for the help text of --user and --password.

Also, an example like this:

      git add <pathspec>...

Tells you that git add accepts multiple paths and you can invoke it with:

      git add src/*

What's more important in my opinion is making sure your argument parser can handle values that start with a dash and respects a double dash to stop the option parser.

Consider an interface like this:

      prog [--rm] [--name <name>] [args...]

And you invoke it like this:

      prog --name --rm -- --name foo

This should result in:

      {
        "name": "--rm",
        "args: ["--name", "foo"]
      }

Getting things like this wrong can result in security issues.

<comment><AUTHOR> I may try to expand on this in the article, but it's in there if you read between the lines. There is a difference between something that takes in multiple args of the same type and multiple TYPES of args. I'm arguing against multiple args of different types, not the same.

By definition any CLI that accepts variable args is fine here as it's all the same type.

The -- is a great point as well. It solves a lot of problems users have but a lot of time people don't even know about it. It solves issues with `heroku run` for example.

EDIT: updated to clarify my point

</comment></comment><comment><USER35> > The user may have reasons for just not wanting this fancy output. Respect > this if TERM=dumb or if they specify --no-color.

Or if they specify `NO_COLOR`[1]!

[1]: [https://no-color.org/](https://no-color.org/)

<comment><AUTHOR> yes, adding this

</comment></comment><comment><USER36> I'm probably being picky, but I would also include that the CLI be a self- contained binary. I'm tired of managing Python / Ruby / Node versions.

<comment><USER37> Its bad both ways. The advantage to python/ruby for example is you can simply pip/gem install, or update. With a binary, you have to download, move, and change permissions every update. For experienced linux users, the binary is fine, but for newer users, its much more "friction"

<comment><USER38> IMO using a language's package manager to install applications is a massive anti-pattern, that should be handled by your OS package manager.

<comment><USER36> This is what I prefer as well. Let me use my OS's package manager for managing my packages.

<comment><USER11> That would still be the case if the packages weren't 1-3 years out of date.

<comment><USER39> That is true. But there are ways around that. Including documentation on how to build it locally is pretty standard. And hosting prebuilt binaries with package installation for targeted platforms is also pretty common as well.

With interpreted languages with language-specific package managers, you have to:

1) Install the language

1a) Possibly have to install a language version manager (rbenv, pyenv, etc)

2) Install the language's package manager

3) Install the CLI utility via the language's package manager

Here's the order I think CLI maintainers should strive to making their utilities available:

1) Install via OS package manager

2) Install via prebuilt release with OS-specific package, from hosting site (GitHub, etc).

3) Install from source

4) Install via language-specific package manager

5) Install via curl | sh :)

</comment></comment></comment></comment></comment></comment><comment><USER40> Only a web programmer could believe that man pages "just aren't used that often". It drives me nuts when compiled cli programs don't have a man page. It says to me that the author of the program doesn't know Unix conventions or doesn't care enough to put the effort into meeting his or her users where they are, and so I'm gonna have to be careful about how I use the program lest it do something unexpected. Use man pages.

The awscli is just terrible in this respect. There's no man page for 'aws' so I say "aws --help". It then literally tells me "To see help text, you can run: aws help". OpenShift's 'oc' sucks at this only a little less, with no man pages and for some inexplicable reason you can only get a list of global options in a dedicated global options help subcommand instead of at the bottom of every help page. The documentation system for 'git' on the other hand is a work of art. Pure beauty.

</comment><comment><USER41> I don't agree with 7 and 8. I like silent apps while working, and actually I'm used to applications saying nothing if everything is correct. Also, "outputting something to stdout just because I can" kills scriptability a lot.

Using tables, colors and other stuff requires a lot of terminal support. MacOS terminal, iTerm, Linux terminals supports a lot of stuff, but not always (our team is generally using XTerm for example). Implementing these are acceptable if there's a robust code detecting terminal capabilities and falling back gracefully and without treating these more streamlined terminals as lesser citizens, and this requires a lot of development, head banging and maintenance. If you're accepting the challenge, then go on.

BTW, That unicode spinner is nice. Very nice.

<comment><USER42> You can just have a "quiet" mode for scripting. Or even better, detect if you're connected to a TTY.

<comment><USER43> I run scripts from a tty all the time...

</comment></comment></comment><comment> ISO-morphism These are all good points, and I wish more clis were like this. My own pet peeve is un-disablable stdout logging.

> It's important that each row of your output is a single 'entry' of data.

It felt weird to me to use `ls` as an example as it's not immediately obvious it adheres to the advice from the printed output. I suppose they were also trying to highlight the earlier point of differing output format depending on whether output is a tty/pipe.

Unrelated, but I didn't know `ls` was that smart about isatty. Once upon a time I read the '-1' option to print one name per line in the man page and assumed it was necessary for that functionality. Thanks!

<comment><AUTHOR> I just picked `ls` as it's a common utility everyone understands and isn't some contrived example using `cat`.

I am going to add a note about `ls`'s behavior with isatty. It's sort of conflating a couple of things, but I think it's interesting enough to leave it in.

<comment> ISO-morphism I agree, it is a good example, and hey I learned something.

I really appreciate that you're taking the time to respond to all the feedback in this thread and wade through everyone's nitpicks. Looking forward to more articles.

<comment><AUTHOR> Thank _you_ for the great feedback!

</comment></comment></comment></comment><comment><USER44> Man I wish OpenVMS was still a thing. All the commands worked the same due to the DCL enforcing it. [https://en.m.wikipedia.org/wiki/DIGITAL_Command_Language](https://en.m.wikipedia.org/wiki/DIGITAL_Command_Language)

<comment><USER45> A) PowerShell was inspired by OpenVMS DCL. B) OpenVMS on x86 is due to be released in 2019 (it's in private beta right now).

</comment></comment><comment><USER46> Also on Color. Don't got go all pschadelic. I've found that some programs using 256-color is unreadable with my terminal colors.

Also unix commands tend to have illegible colors in Powershell on Windows. (Ripgrep for example). Powershell defaults to a blue background.

<comment><USER47> Can you suggest a better default color configuration for ripgrep? We actually already have different default colors for Windows as opposed to unix.[1]

[1] - [https://github.com/BurntSushi/ripgrep/blob/acf226c39d7926425...](https://github.com/BurntSushi/ripgrep/blob/acf226c39d79264256c0295b8381f8c7f0d74d59/grep- printer/src/color.rs#L7-L24)

<comment><USER46> After some time of experimenting with this. I probably can't recommend any colors.

The issue I've found is that of the 16 build in colors. cmd defaults to trivial colors. (eg Blue is 000080 and Bright blue is 0000FF.)

Which give terrible contrast. MS seems to be working on improving things on their end. Then I'll be able to make it readable. (Eg: [https://github.com/Microsoft/console/tree/master/tools/Color...](https://github.com/Microsoft/console/tree/master/tools/ColorTool))

</comment></comment></comment><comment><USER48> #6 is great, except if it causes performance issues: [https://github.com/npm/npm/issues/11283](https://github.com/npm/npm/issues/11283)

Speed is the ultimate fancy enhancement ;)

<comment><USER49> Even if it does not cause any performance issues, I dislike it. If the thing runs in terminal, it should be expect to be used in a script thus it would be better to make no assumptions of terminal capabilities and leave the fancy part to external tools, if one is interested. I always hate systemctl's piping to a pager by default. "Do one thing, do it well", don't try to surprise users with fanciness because at work we don't like surprises.

<comment><AUTHOR> In practice I've had overwhelming feedback praising our use of spinners in the Heroku CLI and not a single complaint I can think of. In fact, I've had more praise for adding spinners and color than any other change we've put in over 4+ years of development.

That said, you need to be careful. Don't use a spinner if it's not a tty or TERM=dumb. Do use it in some CI environments that support it (Travis, CircleCI) That handles all the issues we've seen and everyone seems to be happy.

</comment></comment></comment><comment><USER50> Really great advice here. But missing one key area:

 __Continuous Delivery / Change Management __. I believe any policy without change management principles isn 't really complete, especially when its about 12factor which is considered a gold standard for production.

* CLIs are notoriously difficult to update because you have to convince every single consumer to update it manually, otherwise you just have scattered logic everywhere. Having an update workflow is essential before releasing the first version in production.

* Closely tied, a clear Backwards compatibility policy.

Apart from those two major items, I have also found one optionally nice pattern to reason about CLIs:

Design CLIs like APIs wherever possible. Treat subcommands as paths, arguments as identifiers, and flags as query/post parameters. It's not always applicable, but doing that for large internal tools helps against the "kitchen sink" syndrome.

</comment><comment><USER13> _...all of these must show help._

      $ mycli

Some commands have an unambiguous meaning and don't need arguments. For example, it would be weird if a bare "make" command returned help information. Great post, though. I'm looking forward to digging into oclif.

</comment><comment><USER51> In regards to 7, prompts are great for teaching new users how the program should be used.

Instead of failing then spitting out --help or manpage style info, the program just ask the user enter the needed argument or flag to continue. Having more ways to learn usage is always good IMO.

<comment><AUTHOR> yep +1. A lot of times users are only ever going to run a command once. Better to ask for the right information than bailing out because it's not perfect syntax.

</comment></comment><comment><USER52> While a bit quirky, I really like powershells approach where you aren't limited to text streams. All the same advice applies.

</comment><comment><USER53> Just the help factor alone is a big one.

</comment><comment><USER54> I'm a huge admirer or well crafted cli apps, they can massively boost the effectiveness of a team.

An oldie but goodie here: [https://eng.localytics.com/exploring-cli-best- practices/](https://eng.localytics.com/exploring-cli-best-practices/)

</comment><comment><USER55> > Follow XDG-spec Oh, please guys. Some apps even put visible (non .) folders > in my home.

</comment><comment><USER56> I have recently created single CLI program to put in all actions I need to automate. It's so fast to make new action, that I make anything that saves me just few seconds a day. Even stuff like "invoice" will open me timescheduling app, invoicing app and creates canned email to clipboard. "Clockout" will open timescheduling app and copy expected date and times to clipboard just to paste to app.

I've of course spent some time on automating Help, flags parsing etc, so I essentially just say what data I need and then what to perform.

It was best idea in a long time. I'm thinking that I'll publish framework for this as opensource (it's C# project).

</comment><comment><USER57> > 8\. Use tables

> By keeping each row to a single entry, you can do things like pipe to wc to > get the count of lines, or grep to filter each line

> Allow output in csv or json.

Yes please. Default to readable-but-shellable tabular output, and support other formats.

libxo from the BSD world is a really smart idea - it provides an API that programs can use to emit data, with implementations for text, XML, JSON, and HTML:

[http://juniper.github.io/libxo/libxo- manual.html](http://juniper.github.io/libxo/libxo-manual.html)

I personally love CSV output. Something like libxo means that CSV output could be added to every program in the system in one fell swoop.

</comment><comment><USER58> >Still, you need to be able to fall back and know when to fall back to more basic behavior. If the user's stdout isn't connected to a tty (usually this means their piping to a file), then don't display colors on stdout. (likewise with stderr)

GCC does this, leading to no colour output where it would be useful if you're building with Google's Ninja-build. Maybe there are some people who do pipe GCC output to a file - I've never had to. If you do this with your app, I'd appreciate being able to re-enable the colour.

</comment><comment><USER59> Does these CLI features like tables, OS notifications etc work cross-platform (Linux, Windows, OSX)? IS there any good library to develop such CLI apps?

<comment><AUTHOR> we use [https://github.com/mikaelbr/node- notifier](https://github.com/mikaelbr/node-notifier)

</comment></comment><comment><USER60> > 1\. Great help is essential

I like how this is their #1. In my opinion the best way to do this is with tldr.

[https://github.com/tldr-pages/tldr](https://github.com/tldr-pages/tldr)

I'd highly recommend folks create a tldr page for their CLI app. Add 4-8 examples to cover 80%+ of the most common use cases. -h flags, readmes & man pages can cover the other 20%.

<comment><AUTHOR> I almost want to rewrite the help section to encourage examples even more. They're incredibly valuable.

I hadn't considered this before you mentioned it, but oclif CLIs could integrate to tldr pretty well. It already supports arrays of strings for examples.

<comment><USER61> Yup. On CPAN, it is encouraged that the first part of your documentation after the table of contents is the synopsis[1]. The synopsis should clearly show how to do the common tricks with the library. From there you can link and refer to the more detailed documentation.

We're doing that for our internal CLI applications and it's great to be able to just copy-paste the common use case from the top of the documentation without searching much.

1: [https://metacpan.org/pod/Carp](https://metacpan.org/pod/Carp)

<comment><AUTHOR> I feel the synopsis section of man pages often just becomes a bunch of useless garbage above the fold (for instance, look at `man git`).

Using it less as a complete docopts kind of thing and more of multiple common usages (like `man tar` and what you linked) is far more useful.

I think there is something here I hadn't really considered before. It's not an example, but also not a useless dump of flags. Food for thought I suppose.

</comment></comment></comment></comment><comment><USER62> Related: [http://docopt.org/](http://docopt.org/) – There are implementations for various languages. Whenever I need to write something that has a CLI, this is my default option…

</comment><comment><USER63> Is it just me or every now and then Medium opens with what looks like to be a snapshot of the article instead of the HTML? I can't select text or scroll the page. If I refresh the page everything is normal, though.

</comment><comment> phoe-krk I clicked this in hope that these was an article describing 12 CLI apps written in the Factor language. [http://factorcode.org/](http://factorcode.org/)

My hopes were crushed.

</comment><comment><USER64> > I also suggest sending the version string as the User-Agent so you can debug > server-side issues. (Assuming your CLI uses an API of some sort)

Isn't it some kind of disguised tracking? I know it doesn't give as much info as the user agent of a browser, but still, you could track the OS, even the linux distribution, and surely more, while still being a reproducible build.

</comment><comment><USER65> Does someone has the name of the terminal app used in the article ? (with the nice colored path)

<comment><USER66> It looks like zsh with the Oh My Zsh [1] with the Agnoster theme [2].

1\. [https://ohmyz.sh/](https://ohmyz.sh/)

2\. [https://github.com/robbyrussell/oh-my- zsh/wiki/Themes#agnost...](https://github.com/robbyrussell/oh-my- zsh/wiki/Themes#agnoster)

<comment><USER65> Thank you !

</comment></comment></comment><comment><USER67> Nitpicks:

Replace "pipe content" with "redirect content"

<comment><AUTHOR> nice catch, ty

</comment></comment><comment><USER68> "12 factor" anything seems to be a symptom of the over-complexity of modern apps, go back and rethink.

<comment><USER69> i found the original 12 factor website had a number of pretty reasonable suggestions based on experience of people who ran a business doing operations for other people's web apps.

sure, web apps are themselves probably over complicated, but given that you're doing a web app, the recommendations arent bad. compare to where things have gone since, with containerisation.

<comment><USER70> In a lot of ways the "12 factors" have overly simplistic views of the world. For instance, storing your config in the environment is fantastic -- until you remember a great many frameworks will dump their environment to the browser in a number of failure scenarios. There go all your secrets.</comment></comment></comment>


8m (26'3") Audioquest Diamond RJ/E (Ethernet) Cable, $5,494.75 - <AUTHOR> http://www.amazon.com/263-Audioquest-Diamond-Ethernet-Cable/dp/B0073HJVSK/ref=cm_cr_pr_product_top

<comment><USER2> My favorite excerpt from the reviews:

"As everyone knows, Ethernet cables are for transmitting digital data and that any basic cable with the right rating will successfully transmit any signal thrown at it. However, what people don't know is that -- given the right product -- you can transmit more than digital information through the cable. In addition to the digital information, this cable lets you transmit analog signals such as love, tea, the color green, and the feeling that you get when you first step into a warm bath.

After experiencing this, I'm never going back to the cheap $5 Ethernet cables that only transmit digital data."

</comment><comment><USER3> There is worst: [http://www.amazon.com/AudioQuest-Diamond-52-49-Braided- Cable...](http://www.amazon.com/AudioQuest-Diamond-52-49-Braided- Cable/dp/B00IL3TZSQ/)

Almost $14k!

<comment><AUTHOR> But but but it's low-distortion _and_ low-jitter!

</comment></comment><comment><USER4> Do these companies actually sell these cables at these prices, or are these pranks? I have a difficult time thinking anyone with an ounce of sense would buy a $5500 patch cable.

<comment><USER5> There are great numbers of people out there with more money than sense. That ratio can reach staggering heights.

<comment><USER6> Possibly the most extreme example I've come across of flawed digital audio logic was an article I was linked to recently co-written by one of MacWorld's technical editors describing in detail the differences in sound quality between various hard drives and SSDs [1]. The audiophile world can provide a laugh now and then.

[1] [http://www.enjoythemusic.com/hificritic/vol5_no3/listening_t...](http://www.enjoythemusic.com/hificritic/vol5_no3/listening_to_storage.htm)

<comment><USER7> ...what? How is this not satire? How do people have the gall to make claims like these, while explicitly stating that their hypotheses are based only on "anecdotal murmurings and some limited first-hand experience?"

</comment></comment></comment></comment><comment><AUTHOR> Serious question: Has anybody found a simple way to explain digital vs analog to a non-technical person? I've been asked this a few times, and even though the concept seems so simple, I have yet to find a good, intuitive way.

Because any people paying $5,000 for an Ethernet cable quite clearly have not grasped the concept.

</comment><comment><USER8> Is that somewhere near the official price tag, or just some number determined by some bot?</comment>


For Alt-Right Trolls, "Star Trek: Discovery" Is an Unsafe Space - <AUTHOR> http://www.newyorker.com/tech/elements/for-alt-right-trolls-star-trek-discovery-is-an-unsafe-space <comment><USER2> Wow, there really is a lot of lens flare.</comment>


LiveJournal Lays Off San Francisco Staff, Will Operate From Moscow - <AUTHOR> http://www.paidcontent.org/entry/419-livejournal-lays-off-majority-of-us-staff-will-operate-from-moscow/

<comment><USER2> Just to be clear, not all the SF staff were laid off.

</comment><comment><AUTHOR> a sad day. seems like nobody knows what to do with the thing since brad fitzpatrick removed himself from day-to-day operations.

<comment><USER3> To be fair Brad didn't either; that's why he sold it.

<comment><AUTHOR> recalling what he wrote about the sale at the time, it seemed like he enjoyed the coding, but was not happy about all the administrivia it took to keep the site running. he felt he was passing off all the boring parts of the job to six apart.

must not have worked out that way though, because he didn't stay at six apart very long. i vaguely recall him writing something about how he'd been doing livejournal so long that it had finally gotten tedious for him, and he was ready for something else. could be true, or it could be that things didn't work out with six apart the way he'd hoped.

</comment></comment></comment><comment><USER4> I don't understand the attraction of LiveJournal in the era of Wordpress, Facebook, and Twitter. Was it a sad day when they started winding down Friendster?

<comment><USER5> It's big in Russia (<http://cache.gawker.com/assets/resources/Picture%20360.jpg>) and so you do get a network affect.

And LiveJournal became really popular with certain subcultures. You're able to do friends-only entries, there's a login system for comments and such for your friends, etc. Great for someone who hates the world and wants to share it with a few others. It also allows you follow others on LJ in a way that you can't with Facebook and that Wordpress requires RSS/Atom. It appeals to some. Not everyone wants a public blog (WP), not everyone wants the randomness of Facebook's feed, not everyone wants a 140 character limit. . .

Facebook's real names thing can deter some postings and its closed nature means you don't get random subcultures becoming prevalent as much as you get more mainstream stuff. Twitter isn't a competitor really and Wordpress doesn't have the same features of authentication, friends, etc.

LJ doesn't appeal to me, but I can see why it does for some.

<comment><USER4> A network effect implies that you get more value from using it the more people do use it. But LiveJournal is just a blog. I can read anyone's LiveJournal without joining.

AIM, on the other hand, you have to join to use, which is why we're all still running the ridiculously baroque OSCAR protocol.

<comment><AUTHOR> no, you _cannot_ read anyone's livejournal without joining. many people make some or all of their entries friends-only, which can only be read by people on their friends list.

it's features like this one, and many others, that make connectedness with friends much stronger than on traditional blogging platforms.

<comment><USER5> To add a bit, LJ users can leave comments attached to their accounts and so comments become "by someone" in a way that blog comments aren't always. Likewise, you can look through the friends lists of people you're friends with and see if you like their stuff. It's not a great network affect like AIM or Facebook, but it's definitely there.

<comment><USER6> I have a lifetime account on livejournal. An LJ friend actually bought it for me (I was very surprised). I love the service and use it as an online diary. It has novelty to those of us who want that. Plus some of us started with it many years ago (2001 for me) and never left.</comment></comment></comment></comment></comment></comment>


I Won't Teach My Kids to Code, and Neither Should You - <AUTHOR> https://slate.com/human-interest/2018/12/against-teaching-kids-to-code-creativity-problem-solving.html <comment><USER2> I think learning to code as a teen or adult is really easy if you have strong abstract reasoning skills and literacy skills. I don't teach my kids about coding, I do hit them with logic puzzles, math questions, and teach them to read. If they nail those skills (in addition to the ones the author mentions) they'll be able to pick up programming in a few weeks.

</comment><comment><AUTHOR> There are a lot of white collar jobs where being able to do a bit of coding, if only at the level of Excel functions, is somewhat useful.

If I had kids, I think making sure they learn to code would be sort of medium- priority. Less important than learning to swim. More important than learning to dance. Perhaps on par with speaking a second language well.</comment>