Stderr should only get error messages, and, arguably, warning messages. It shouldn't get status and progress messages. Those should go to /dev/tty, and the program should be gracefully quiet if run without a terminal, e.g., from cron.
Shouldn't the "verbose" option take care of the presence of the status or progress messages? Also, arguably, the error and warning messages are status messages too, so I would say all the status messages, regardless of gravity, belong to the same channel.
Error and warning messages are not status or progress messages, at least not in the context of this discussions, which is that a long-running computation should indicate to the user that it's doing something.
Example: "warning, the x is in y condition and thus z will take place affecting the computation in progress" or "error, could not perform x (out of many x-like things to do, but I'll continue because you instructed me to)". These are status messages in a long-running computation context.
I disagree. They're a warning and an error message, and should go to stderr.
It may _also_ be useful to show them on the terminal, in case the user would like to see them now, and has redirected stderr somewhere other than the terminal. In that case a program might show them on /dev/tty as well.
I see the point you're trying to make; the authorities apparently accept a risk in terms of expensive equipment produced by corporations with strong lobbying funds, but decline that risk in terms of bottled liquids.
One fact that is overlooked is that there is actually a limit on the lithium-equivalent permitted per passenger just like there is a liquid-volume limit.
Last time I checked, the total maximum carry-on lithium-equivalent was 25 grammes which was about four smartphone batteries or two-dozen AA cells. Now as to whether that's an acceptable risk is for someone else more knowlegeable to evaluate.
Strange, I've been traveling with a 500cc refillable water bottle forever, never had any trouble (Germany, Netherlands, East Asia). Maybe it helps that my bottle is designed to be refilled, and not just an empty bottle from the supermarket.
Yes ... but sometimes only hot water is available, and at all times the quality of water not marked 'drinking water' could in principle be suspect (it might come via a tank somewhere — this is certainly common in old UK domestic plumbing — and the tank might have dead rat in it, etc.).
The problem is that with a water bottle, you can immediately see it's some kind of liquid on the x-ray and disallow it during inspection, whereas the Note 7 isn't immediately apparent when inspected from afar. While I don't agree with the liquid ban, it's much easier to ban a liquid than it is to ban a specific model of a phone.
Last time I was on an airplane the crew disallowed all Note 7s being turned on or being charged. I'm not sure if it was seriously enforced, but it was announced.
Aliases are per shell process. You need to reload your .bashrc (or whatever file you define aliases in) in every shell. Shell scripts are instantly available in all shell instances. Also, shell scripts can be invoked by shell scripts, which aliases can't.
I agree, but for something as simple as that I’d prefer a script to use `ssh-keygen` instead of relying on the presence of a one-line script in the PATH.
Does pointing that out advance the discussion in a useful way? Does it help having a constructive debate? Does it make anyone's day or life better? Are you just posting in the hope of getting some upvotes for making a funny, snarky short comment? Is your comment actually relevant to the discussion? Does the fact that you ask that question indicate that you already know the answer?
I did not write that from my Lemote, channeling Stallman, nor I have any general enmity towards closed source software (that I both use and write).
I just don't like inaccurate proclamations of purity.
Since I develop backup software, this is a problem I needed to solve (e.g., for verifying that restore works). So I wrote a tool: http://liw.fi/summain/
It produces output that is meant to be usefully diffable.
That's a neat looking application - bonus points for a good manpage, too.
That said, how does it handle firstpath/somefile.bin and secondpath/somefile.bin being identical? This breaks your "diffable" output because the paths are different.
The difference between free software and open source isn't copyleft. Both free software and open source embrace copyleft.
From your writing I deduce you are of the opinion that open source is more or less equivalent to permissive licensing, i.e., using BSD-style licenses.
The actual difference between the two is that open source values the productivity benefits that come from sharing, whereas free software is primarily about protecting the freedom of people.
Mocking should be done carefully, and one should avoid mocking things one doesn't understand.
> whereas free software is primarily about protecting the freedom of people.
That's why people often misunderstand the redefined/restricted freedom of GPL. I don't even want to associate GNU with "free software". Just replace "have the freedom to ..." for "have the right to ...", this way the philosophy of GPL would sound better to my ears.
