Great fun. One minor nitpick - the story of "Apache Server" being originally derived from "A Patchy Server" is a long-standing myth; the name was originally intended to be a tribute to the Apache Native American peoples. The Wikipedia article on Apache (http://en.wikipedia.org/wiki/Apache_HTTP_Server) includes a link to an interview with Brian Behlendorf (http://www.linux-mag.com/id/472/) where he explains how the story arose.
I personally attended a talk presented by Brian Behlendorf at the ISPF (an early ISP conference) in 1999 (which predates the 2000 Linux Magazine article). In his talk, he used the "A Patchy Server" explanation. He made no mention of any other etymology that I recall.
So either Brian was deliberately propagating the myth himself ... or maybe there's some retconning going on.
> The Apache group was formed around a number of people who provided patch files that had been written for NCSA httpd 1.3. The result after combining them was A PAtCHy server.
(April 1997)
The new story is not consistent with what their website was saying not very long ago.
I was using web servers at the time, and the "a patchy server" story is what everyone said back then. Nowadays people take it all for granted but Apache was radical at the time, previously people had been running httpd out of inetd.conf (!)
Another fun that appears elsewhere but really does deserve to be in this list: Debian is named after Debra and Ian Murdock (he's the founder of the project, she was his girlfriend).
Reminds me of the BDSM-themed splash screen they put in one of the development versions a while back - which seems to have disappeared from the official site, but you can find it if you look hard enough (possibly a bit NSFW):
The difference is that normal people understand the meaning behind the name 'iPad' (Apple's use of 'i' prefix for mobile, the device is like a 'pad' of paper) whilst, to them, Gimp is just a bit ... weird and creepy.
"'Excel' means to be good at something. A 'gimp' is some weird sexual bondage thing" - this is how most people in the real world think and, whether or not they might get used to names over time and disassociate them from their original meaning, it doesn't change their first impression.
I never understood why you would name a package index after something that's literally got nothing to show... I know the reasoning, but it still feels strange.
One of the ideas I liked most during the inception of Python 3000 a.k.a. python3 has been to rename python3 to blackadder. Another snake, another great british comedy.
The etymology of Unix programs: very interesting! The writers of this page also have a sense of humor:
> bc
> originally a front-end for dc ("desk-calculator"); modern GNU bc is instead a backwards-compatible byte-code interpreter for dc, but what it stands for is still "basic calculator"
Some pretty interesting explanations in this list. I personally prefer to not let the developers name things, because they usually come up with very bad names (hard to pronounce, hard to google for, have overtly sexual connotations, etc). Command line utilities are a little different because there's a culture of having short names making them easier to type. But it's still very hard to google for things like "less" because it's a common word.
Searches for "Unix less" or "Linux less" are spot on. Even "less command line" will get you there easily. It's all about context.
And of course there are always the man pages, which is usually the best place to start.
I personally find the man pages very dense and poorly organized. `man grep` for example is my own personal nightmare. I think the man pages should introduce a policy of simple usage examples instead of throwing 99% of information you don't care about at you at once. Something like http://bropages.org/
I have to read the info docs before I can read the docs I wanted to read. They're also divided up into little pieces unnecessarily, so I have to think rather than scroll until my eye catches what I need.
info is up there with inkjet printers and trying to make sound work worth a damn in Linux on my list of things that have frustrated me regularly for the past 20 years.
I have a small script in my ~/bin that pipes `info --subnodes "$@"` into less. That way I don't have to remember all the keys, and the whole output is like a big man page. Although on Debian and Ubuntu the info pages are usually not available by default anyway due to the "GNU docs are non-free"-decision Debian made a few years ago.
I find that the Man pages on BSD-derived systems are generally quite exceptional, where as GNU-based systems seem to be less so. `info` seems to be their attempt at making a better `man`, but it's pretty hit-or-miss if a Linux-based project thats not from the FSF supports infopages over manpages.
But the one thing I hate about info is that they often change the "see also" near the end of a man page from a list of similar or related commands that you might want to also read, to an invitation to use the info chapter for that command. Aarrrggghhh!
man less
...
SEE ALSO
lesskey(1)
man ls
...
SEE ALSO
The full documentation for ls is maintained as a Texinfo manual.
If the info and ls programs are properly installed at your site, the command
info coreutils 'ls invocation'
should give you access to the complete manual.
Why hijack a useful section? Why not just add a "SEE INFO" section?
Seconded. When I was starting out in Solaris sysadmin, I'd read the Solaris man pages for local details, but the OpenBSD pages to see what the hell the command actually thought it was doing.
> Giving cryptic names to software is a well-established UNIX tradition
God, this is so true! I seriously think that world would be much better already if we would just rename many of well-established binaries and C-functions to more-intuitive, better convention. Even without changing APIs that much (which would be great too, of course).
Good luck with that. We can't even give the creat() system call an 'e' at the end.
(Not that it should be used much these days; the 'creat() then open()' idiom is a race condition waiting to happen, so 'open()' has grown the ability to create-and-open in one atomic operation. That seems to handle most of the file creation that Unix programs need to do.)
Stallman liked GNU because it's unpronounceable. When Europeans first discovered the animal, Africans referred to the first sound in its name as a click, which the Europeans didn't use in their languages, so the "g" in the word essentially stands for "unpronounceable sound," and is usually omitted. He used it for fun but brought back the sound in the form of a hard "g."
One last question: What inspired the names CHICKEN and SPOCK? Do they mean anything, aside from the bird and the well-known Star Trek character?
That question always comes up, sooner or later. ;-)
I had a plastic toy of Feathers McGraw on my desk, the evil penguin (disguised as a chicken!) from the Wallace and Gromit movie, “The Wrong Trousers.” Looking for a preliminary working title for the compiler, I used the first thing that came to my mind that day. I’m somewhat superstitious about names for software projects, and things were progressing well, so I didn’t dare to change the name.
Also, there is the old philosophical question: which came first, the chicken or the egg? This applies to CHICKEN, too. The compiler is written in Scheme, so you need CHICKEN in order to compile CHICKEN.
What a coincident. In 2015, Perl 6 (Parrot VM) and Python 3 have difficulties to transfer their community over from the former major releases Perl 5 and Python 2.
Offtopic: We can learn from it. Like fixing a language early or never/only in small steps. Other examples: XHTML 1 and especially 2 failed, HTML5 based on HTML4 won spectacular. PHP6 failed, but won with PHP 5.3+ and now PHP 7. The transition from Visual Basic 6 and VBA 6 to Visual Basic .Net failed, J#/C# won.
Perl 6's biggest mistake was naming their language Perl. It turns out Perl-6 is a completely different language from Perl-5, although they share the surrounding ecosystem. But now that the name is taken, Perl-5 is up to version 20.2 with no clear solution in sight to communicate version numbers in the future.
I don't think any of the Perl-6 developers actually advocates switching from Perl-5. (But please correct me if I'm wrong.) The situation is quite different from Python 3, which is the newest incarnation of the Python language.
From what I've heard of it I'm guessing they would be advocating switching to Perl-6 for new projects if perl-6 had actually shipped a 1.0/6.0 type release and seemed to be succeeding as a practical language.
The original plan, as I recall, was to move everyone to the Parrot VM, such that there would be a Perl 5 compiler, a Perl 6 compiler, a your-language-here compiler, and everyone would be able to share code in an environment that was similar to the JVM but friendlier to dynamic languages.
So Perl 5 was never going to go away like Perl 4 had, it was just going to become one element of a broader ecosystem.
In most cases, it's not cryptic or strange at all and makes perfect sense. This article ignores history. Back then, names were shortened to save every available byte cause ram and disk usage was so limited. It was also easier to type when you did everything from the command line. In addition, a lot of these were created in some lab somewhere, like Bell Labs, and they had no intention of you using it.
Long ago, when I heard of awk and sed, the first thing I did was ask what they stood for. I would think any seriously interested computer person would do the same thing.
In most cases, it's not cryptic or strange at all and makes perfect sense.
Just because it made sense and was entirely justified right then, does not mean that it is not cryptic or strange today. That's kind of the point of the explanations: to explain why the names are so cryptic and strange.
Long ago, when I heard of awk and sed, the first thing I did was ask what they stood for. I would think any seriously interested computer person would do the same thing.
Interesting expectation. I think why I always wondered, I did not really ask that often. Firstly because when I started, there were not many places to ask for (hardly any non-students even had Internet access), second because it would get tedious after a short time.
It's entirely justified for even very serious "computer persons" to have used these commands all the time and only now learning the meaning of some of them.
It makes sense today and isn't cryptic at all. Perhaps to outsiders it is but we're not outsiders. We know it stands for something and "stream editor" should make sense. Looking it up is a matter of "man sed" or, in my case long ago, I'd turn to the guy sitting next to me and ask him.
Yes, awk is an exception, and there are others, but they aren't the rule.
When sed was new, the name wouldn't even have been considered cryptic: everybody already new ed.
Also: before sed there was gres. I'm not saying it's relevant, just that I've thought it would be better to have gres, and have it be the standard, than sed. (Match and substitution in actually-separate arguments.)
