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.
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.
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.
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.
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?
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.
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.
The Unix command /bin/true (do nothing, exit with code zero) can be implemented as an empty file. When it's run, the kernel doesn't recognize it as binary code, so it gives it to /bin/sh to run.
There's at least two bugs in a zero-byte implementation of /bin/true: it's too slow and it uses too much memory.
I have been keeping a journal in a private ikiwiki instance for several years now. Basically, I set up an ikiwiki blog that generates a static website, served by Apache over localhost. Files are in markdown, and kept in git. I do searches via "git grep". The static site is for easier browsing.
I've added things like "topics" (sub-blogs based on links to a topic page) and "people" (ditto). A topic is a page and automatically shows (via ikiwiki inline) all the blog posts that link to the topic page. A person is also represented by a page, and similarly lists linking blog posts. Topics are usually using a meta link directive in ikiwiki, whereas people use a person/lastname.firstname link to achieve the same.
I wrote a little tool to make admining topic and person pages easier, and to easily add new blog posts and attach images or other files to the blog post. http://git.liw.fi/cgi-bin/cgit/cgit.cgi/jt/ has the code; I should probably write this up some day.
I've published some of my journal, related to one of my hobby projects. http://liw.fi/obnam/journal-dump/ if you're curious, though from server access logs I know nobody is.
I keep my journal private mostly so I can be more honest when I write. If I need to, I can be rude and impolite and use quite dirty language, which I wouldn't if I was writing in public. Also, some topics are private and nothing good will come from disclosing them.
I don't recognise the Nautilus I use from the screenshot or the description. For example, I have a completely different sidebar and I have no problem having multiple tabs in a window.
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.