> argonaut-*
> (server-client distributed deployment infrastructure) for some of the package descriptions in the suite this name is a groan-inducingly obvious Greek-mythology pun, but others don't even mention that its message protocol is encoded in JavaScript Object Notation (JSON "Jason")
> mysql-* a Structured Query Language server named after the original developer's daughter "My" (cf. also mariadb)
Learned something new today... It's crazy to think how we take some of these technologies for granted while never stopping to think about the individual human beings that made it all possible to begin with.
Anyone know of a good podcast or website that does a deep dive into the history of how different computer technologies (esp open source ones) came to be the way they are?
> daughter Maria (after whom MariaDB was named), and has a daughter My (after whom MySQL was named)[16] and a son Max (giving the name for MaxDB) from his first marriage
I think I learned the MySQL tidbit recently from an episode of the podcast Libre Lounge. What you ask for is not a bad description of what the hosts of that podcast do: deep dives into open source technologies and discussions of how they came to be the way they are.
>chromium - web browsers on Linux spent a decade going through a cycle of slick new slimline web browsers gradually getting buried in creeping features until they were as weighed down with chrome grills and ornamental fins as a fifties US car, at which point everyone would switch to some new minimalist alternative. Meanwhile these GUI widgets came to be referred to as "chrome", which explains why Google would choose to advertise their browser as if it was manufactured entirely out of deadweight bling...
One interesting bit that I found missing on that page is ncmpcpp, which is a simple one (in a way), and also contains its entire genealogy in the name.
First there was mpc, the music player (daemon) client.
Then someone made the ncurses version, so of course that was named ncmpc.
Then someone decided to add more features and rewrite it in C++, and voila.
There's similar story to urxvtcd which is my nickname here, haha. They have an entry on rxvt:
Rob Nation's fork of the X11 Virtual Terminal; originally "Robert's" xvt, later "our" xvt.
Then they added "u" for unicode support. And then urxvt can run a daemon to which clients connect for faster startup or something, so we have urxvtc and urxvtd, and finally there was a script on some distro I used which checked for a daemon, run it if it not existed, and then run client, so urxvtcd.
Could have made one with color support included in the name too, like urxvtcd256.
... which is only part of the tale. Some of the rest involves the fact that "rxvt-unicode-256color" is too many characters for the termcap/terminfo databases on some operating systems.
> Apache-Licensed PINE, where pine was the old (non-DFSG-free) "Program for Internet News and E-mail" - formerly known as "Pine Is Nearly Elm", named after a yet older electronic mail program. Nowadays contains its fork realpine, which the developers insist is re-alpine (alpine development restarted, since the original team seems to not be doing much) and not real-pine…
Forgive me if this is a bit morbid, but we are lucky as computer scientists and engineers to have a largely "living history" over the last century of innovation.
Documentation is great in some respects but we should try and go out of our way to interact and cherish the pioneers of early computing more before they pass on.
What do I mean by "more"; when we have forums, mailgroups, IRC, conferences etc.?
I guess more books, more interviews and more documentation.
One thing I like to do with junior developers is when I see them using a terminal command that they just copy and pasted from stackoverflow, I try and coach them to read up about it on manpages or documentation online, so they can get a better feel of what the history was behind that tool.
I hope you're right, most of what we know about Plato's teachings came from his students that took good notes.
That said, I do have trouble finding the "history" of a particular technical idea. There's a lot of interesting things that are a certain way but haven't been documented about "why" because the author never thought to put them down.
Indeed the most interesting things to posterity are the ones we don't even think about.
> I hope you're right, most of what we know about Plato's teachings came from his students that took good notes.
You're thinking of Socrates, not Plato. Plato is the one of the few ancient writers where it's believed that basically his the entire body of work has been preserved. What we know of Plato's philosophy, we know from Plato directly.
Socrates, however, did not write anything down: he was famously opposed to the concept of writing, thinking it induced forgetfulness. His philosophy is thus almost entirely known through his students, primarily through Plato. There are a few others (Xenophon was also Socrates' student and wrote about him), but Plato is by far the most significant.
To oversimplify: we should write more interesting and historical comments in our codebases, write more blog posts and give more talks, and share more links to blog posts and talks other people have created.
I couldn't agree more. Growing up, my dad would tell me stories about 70s and 80s and 90s computing and it always fascinated me. I wouldn't consider myself a history buff, but when it comes to computers, I definitely am. More books on computing history would be great, the only one that comes to mind this very second is "Unix: A History and Memoir", which is fantastic.
I've considered writing one myself as a little hobby project, but I'm not sure where to focus.
> The project name is pronounced Deb'-ee-en, with a short e in Deb, and emphasis on the first syllable. This word is a contraction of the names of Debra and Ian Murdock, who founded the project. (Dictionaries seem to offer some ambiguity in the pronunciation of Ian (!), but Ian prefers ee'-en.)
It would be fun to have a list of projects that contrived the reasoning after choosing the name.
The DNF package manger always springs to my mind when naming comes up. Originally it didn't stand for anything, despite the use of DNF in sports to denote "Did Not Finish" (hardly a great connotation for most software). Though it appears to have since been coined as "Dandified YUM".
I wish the topics here on HN would include a bit more context so it wasn't necessary to click on each link to find out what the post was about.
I love these sort of naming derivations, and it shows a certain creativity and irreverent humor found in the free software world. I wish that naming was a simpler aspect of software development -- often times it's the ultimate form of bikeshedding.
The name of the post was originally something like "etymology of Debian package names", but an admin decided that they did not like that name and changed it.
a bit tangential, while this is cute, what I've never been able to find is a definitive digestible guide to the final Debian package names. what does -dev -doc etc. really mean? (I often need a -dev package for stuff I'm not even building for some reason) why do some libs tack on a 'lib' at the front while some do not? why are package versions often seemingly unrelated to upstream versions? and sometimes packages come is multiple versions (like GCC) and yet often they don't.. seemingly randomly. for instance i just looked up lxqt which is listed as version 13... I don't know what version that corresponds to upstream.. 1.13? Maybe? it's all incredibly beginner unfriendly
-dev packages ship the header files for C/C++ libraries, and in some odd cases also static libraries.
-doc packages ship documentation (unsurprisingly). Usually they only exist for things like libraries and interpreteres, where the documentation can be sizable and is only needed by a (small) subset of the users that have the package installed.
> I often need a -dev package for stuff I'm not even building for some reason
That's because to compile something that links against a library, you need to have the header files available.
> why do some libs tack on a 'lib' at the front while some do not
Aside from a few leftover historical oddities (primarily zlib), all shared libraries should be prefixed with lib.
> why are package versions often seemingly unrelated to upstream versions?
They should be. Exceptions are made for "native" packages (which usually provide Debian-specific software or integrations) and upstreams that don't really follow any versioning scheme.
> sometimes packages come is multiple versions (like GCC) and yet often they don't
In the steady state there should be only one version of every package. During the transition to a new version, especially of very core packages such as GCC, there might temporarily be more. It's unfortunately happened in the past that multiple versions ended up in stable, but that was because the Linux kernel required a specific GCC version.
> for instance i just looked up lxqt which is listed as version 13... I don't know what version that corresponds to upstream.. 1.13?
The LXQT package is a "native" package that only provides integration between Debian and LXQT, and as such it doesn't follow LXQT's version numbering. If you instead look at any actual LXQT software (e.g. lxqt-session), they follow the upstream versioning (0.14). I agree that it's a bit confusing, but it's a result of the development process.
And yeah, zlib is a weird one. It's listed as zlib1g sometimes and the files are libz from what I remember
I have a followup if you don't mind. I'm trying to rack my brain for old confusions I've had... For instance I look up libssl. There is a libssl-dev, but no corresponding libssl. There are other libssl libs but all the names are inconsistent: libssl1.0.0 with no libssl1.0.0-dev and then there is a libssl1.0.2, but it has no libssl1.0.2-dev haha. But I do see a libssl1.0-dev and when I click through it have 1.0.2 as a dependency... So what's going on?
> And yeah, zlib is a weird one. It's listed as zlib1g sometimes and the files are libz from what I remember
Fun fact: the "g" in the zlib1g package names comes from the transition to the GNU C library back in 1997, and zlib hasn't had any ABI-incompatible changes since then (ABI-breaks are the point where libraries are usually renamed, so that you can (temporarily) have both installed while users of the library are migrated to the new version).
If it would be introduced nowadays it would just be called libz1, consistent with other libraries.
> I have a followup if you don't mind. I'm trying to rack my brain for old confusions I've had... For instance I look up libssl. There is a libssl-dev, but no corresponding libssl. There are other libssl libs but all the names are inconsistent: libssl1.0.0 with no libssl1.0.0-dev and then there is a libssl1.0.2, but it has no libssl1.0.2-dev haha. But I do see a libssl1.0-dev and when I click through it have 1.0.2 as a dependency... So what's going on?
The usual structure is to have libfoo-dev with the development headers of the newest version, and then libfooX (with X the version number) with the shared libraries. There's usually only one of each, but during development older versions of the shared library might be around so that you can run binaries using them until they've been recompiled to link against the new version. There sometimes have been exceptions if it's very hard to get all software ported to the new version in time, but that's quite rare.
As far as I can see for OpenSSL, Debian 8 (jessie) shipped OpenSSL 1.0.0 (libssl-dev and libssl1.0.0). Debian 9 (stretch) had both OpenSSL 1.1 as default (libssl-dev and libssl1.1), and (as one of those exceptions) also OpenSSL 1.0 for legacy software (libssl1.0.2 and, again as an exception because the libssl-dev name is already taken, libssl1.0-dev). Debian 10 (buster), the current version, ships only OpenSSL 1.1.0 (libssl-dev and libssl1.1).
(In the case of OpenSSL it's even more confusing because 1.0.1 was a backward-compatible release with 1.0.0, but 1.0.2 wasn't. So the packages named 1.0.0 were actually version 1.0.1. Fortunately upstream has fixed their versioning scheme since then, so it will get better. That's also the reason old versions included the full version number, and now there's only the major and minor version -- since patch releases are compatible.)
thank you so much for that deep dive into the history and issues involved. I hadn't considered that it's tricky to have multiple -dev headers floating around. You can have packages link to different versions as needed, but you don't wanna hard code version paths into source code. Sounds like a tricky problem to solve cleanly.
Thank you again for sharing your unique unsight. This is stuff that's really hard to find otherwise. I just wish all these details where in the package descriptions. It would be so incredibly helpful. Especially in -dev packages where the description isn't going to be seen by "casual" users anyway
The zlib1g name has something to do with the libc5 to libc6 transition that affected all of Debian back circa the year 2000 I think.
The libssl-dev thing is because (usually) you can only have the headers installed for a single version of a library. So you get libssl-dev. But you can have multiple binary versions installed, to support other packages that may have been compiled with older versions of the library with incompatible ABIs & that haven’t been recompiled or updated to the latest version yet.
So you have a -dev package that depends on the latest binary package.
Sometimes, you have headers that live in their own versioned directories, so you can compile against older library releases (maybe there’s an API change & not all your packages have been updated to the new API yet). Hence the libssl1.0-dev, which put headers for the old libssl version in a subdirectory in Debian stretch (I think?) so they didn’t interfere with the ones for the new version.
I would love to see an article about how people pronounce some of the strange names and acronyms we have ended up with. Quick survey? 'etc', 'gif', 'uefi', 'wget', 'cifs' ?
'dd' is a JCL utility from IBM mainframes. Both the Unix command name and syntax are directly lifted from the mainframe version of the ... data definition ... utility.
DD in JCL is not an utility, but keyword. Its functionality is something between shell's IO redirection and mounting volumes inside docker containers. The syntax itself is not that obscure in the context of JCL and IBM OSes.
> Apache-Licensed PINE, where pine was the old (non-DFSG-free) "Program for Internet News and E-mail" - formerly known as "Pine Is Nearly Elm", named after a yet older electronic mail program. Nowadays contains its fork realpine, which the developers insist is re-alpine (alpine development restarted, since the original team seems to not be doing much) and not real-pine…
> argonaut-* > (server-client distributed deployment infrastructure) for some of the package descriptions in the suite this name is a groan-inducingly obvious Greek-mythology pun, but others don't even mention that its message protocol is encoded in JavaScript Object Notation (JSON "Jason")
Learned something new today... It's crazy to think how we take some of these technologies for granted while never stopping to think about the individual human beings that made it all possible to begin with.
Anyone know of a good podcast or website that does a deep dive into the history of how different computer technologies (esp open source ones) came to be the way they are?
> daughter Maria (after whom MariaDB was named), and has a daughter My (after whom MySQL was named)[16] and a son Max (giving the name for MaxDB) from his first marriage
He has a habit, apparently :P
>chromium - web browsers on Linux spent a decade going through a cycle of slick new slimline web browsers gradually getting buried in creeping features until they were as weighed down with chrome grills and ornamental fins as a fifties US car, at which point everyone would switch to some new minimalist alternative. Meanwhile these GUI widgets came to be referred to as "chrome", which explains why Google would choose to advertise their browser as if it was manufactured entirely out of deadweight bling...
http://www.catb.org/~esr/jargon/html/C/chrome.html
First there was mpc, the music player (daemon) client.
Then someone made the ncurses version, so of course that was named ncmpc.
Then someone decided to add more features and rewrite it in C++, and voila.
Rob Nation's fork of the X11 Virtual Terminal; originally "Robert's" xvt, later "our" xvt.
Then they added "u" for unicode support. And then urxvt can run a daemon to which clients connect for faster startup or something, so we have urxvtc and urxvtd, and finally there was a script on some distro I used which checked for a daemon, run it if it not existed, and then run client, so urxvtcd.
Could have made one with color support included in the name too, like urxvtcd256.
> Apache-Licensed PINE, where pine was the old (non-DFSG-free) "Program for Internet News and E-mail" - formerly known as "Pine Is Nearly Elm", named after a yet older electronic mail program. Nowadays contains its fork realpine, which the developers insist is re-alpine (alpine development restarted, since the original team seems to not be doing much) and not real-pine…
Documentation is great in some respects but we should try and go out of our way to interact and cherish the pioneers of early computing more before they pass on.
What do I mean by "more"; when we have forums, mailgroups, IRC, conferences etc.?
I guess more books, more interviews and more documentation.
One thing I like to do with junior developers is when I see them using a terminal command that they just copy and pasted from stackoverflow, I try and coach them to read up about it on manpages or documentation online, so they can get a better feel of what the history was behind that tool.
That said, I do have trouble finding the "history" of a particular technical idea. There's a lot of interesting things that are a certain way but haven't been documented about "why" because the author never thought to put them down.
Indeed the most interesting things to posterity are the ones we don't even think about.
You're thinking of Socrates, not Plato. Plato is the one of the few ancient writers where it's believed that basically his the entire body of work has been preserved. What we know of Plato's philosophy, we know from Plato directly.
Socrates, however, did not write anything down: he was famously opposed to the concept of writing, thinking it induced forgetfulness. His philosophy is thus almost entirely known through his students, primarily through Plato. There are a few others (Xenophon was also Socrates' student and wrote about him), but Plato is by far the most significant.
https://www.youtube.com/watch?v=4PaWFYm0kEw
To oversimplify: we should write more interesting and historical comments in our codebases, write more blog posts and give more talks, and share more links to blog posts and talks other people have created.
I've considered writing one myself as a little hobby project, but I'm not sure where to focus.
I wish I could have thanked Ian in person for making the Linux community a better place. It's still the only Linux distro I'll use.
> The project name is pronounced Deb'-ee-en, with a short e in Deb, and emphasis on the first syllable. This word is a contraction of the names of Debra and Ian Murdock, who founded the project. (Dictionaries seem to offer some ambiguity in the pronunciation of Ian (!), but Ian prefers ee'-en.)
---
[0]: https://www.debian.org/doc/manuals/debian-faq/basic-defs.en....
... and then noted the inconsistency made at https://en.wikipedia.org/wiki/Special:Diff/909924023 by JWilk. (-:
(Link for the curious. Reposts are ok after a year: https://news.ycombinator.com/newsfaq.html)
The DNF package manger always springs to my mind when naming comes up. Originally it didn't stand for anything, despite the use of DNF in sports to denote "Did Not Finish" (hardly a great connotation for most software). Though it appears to have since been coined as "Dandified YUM".
I believe you're looking for the word "backronym"? There's a few notable ones I can think of, like Amber Alert, and SOS.
TIL.
I love these sort of naming derivations, and it shows a certain creativity and irreverent humor found in the free software world. I wish that naming was a simpler aspect of software development -- often times it's the ultimate form of bikeshedding.
maybe someone has a good reference?
-dev packages ship the header files for C/C++ libraries, and in some odd cases also static libraries.
-doc packages ship documentation (unsurprisingly). Usually they only exist for things like libraries and interpreteres, where the documentation can be sizable and is only needed by a (small) subset of the users that have the package installed.
> I often need a -dev package for stuff I'm not even building for some reason
That's because to compile something that links against a library, you need to have the header files available.
> why do some libs tack on a 'lib' at the front while some do not
Aside from a few leftover historical oddities (primarily zlib), all shared libraries should be prefixed with lib.
> why are package versions often seemingly unrelated to upstream versions?
They should be. Exceptions are made for "native" packages (which usually provide Debian-specific software or integrations) and upstreams that don't really follow any versioning scheme.
> sometimes packages come is multiple versions (like GCC) and yet often they don't
In the steady state there should be only one version of every package. During the transition to a new version, especially of very core packages such as GCC, there might temporarily be more. It's unfortunately happened in the past that multiple versions ended up in stable, but that was because the Linux kernel required a specific GCC version.
> for instance i just looked up lxqt which is listed as version 13... I don't know what version that corresponds to upstream.. 1.13?
The LXQT package is a "native" package that only provides integration between Debian and LXQT, and as such it doesn't follow LXQT's version numbering. If you instead look at any actual LXQT software (e.g. lxqt-session), they follow the upstream versioning (0.14). I agree that it's a bit confusing, but it's a result of the development process.
And yeah, zlib is a weird one. It's listed as zlib1g sometimes and the files are libz from what I remember
I have a followup if you don't mind. I'm trying to rack my brain for old confusions I've had... For instance I look up libssl. There is a libssl-dev, but no corresponding libssl. There are other libssl libs but all the names are inconsistent: libssl1.0.0 with no libssl1.0.0-dev and then there is a libssl1.0.2, but it has no libssl1.0.2-dev haha. But I do see a libssl1.0-dev and when I click through it have 1.0.2 as a dependency... So what's going on?
Fun fact: the "g" in the zlib1g package names comes from the transition to the GNU C library back in 1997, and zlib hasn't had any ABI-incompatible changes since then (ABI-breaks are the point where libraries are usually renamed, so that you can (temporarily) have both installed while users of the library are migrated to the new version).
If it would be introduced nowadays it would just be called libz1, consistent with other libraries.
> I have a followup if you don't mind. I'm trying to rack my brain for old confusions I've had... For instance I look up libssl. There is a libssl-dev, but no corresponding libssl. There are other libssl libs but all the names are inconsistent: libssl1.0.0 with no libssl1.0.0-dev and then there is a libssl1.0.2, but it has no libssl1.0.2-dev haha. But I do see a libssl1.0-dev and when I click through it have 1.0.2 as a dependency... So what's going on?
The usual structure is to have libfoo-dev with the development headers of the newest version, and then libfooX (with X the version number) with the shared libraries. There's usually only one of each, but during development older versions of the shared library might be around so that you can run binaries using them until they've been recompiled to link against the new version. There sometimes have been exceptions if it's very hard to get all software ported to the new version in time, but that's quite rare.
As far as I can see for OpenSSL, Debian 8 (jessie) shipped OpenSSL 1.0.0 (libssl-dev and libssl1.0.0). Debian 9 (stretch) had both OpenSSL 1.1 as default (libssl-dev and libssl1.1), and (as one of those exceptions) also OpenSSL 1.0 for legacy software (libssl1.0.2 and, again as an exception because the libssl-dev name is already taken, libssl1.0-dev). Debian 10 (buster), the current version, ships only OpenSSL 1.1.0 (libssl-dev and libssl1.1).
(In the case of OpenSSL it's even more confusing because 1.0.1 was a backward-compatible release with 1.0.0, but 1.0.2 wasn't. So the packages named 1.0.0 were actually version 1.0.1. Fortunately upstream has fixed their versioning scheme since then, so it will get better. That's also the reason old versions included the full version number, and now there's only the major and minor version -- since patch releases are compatible.)
Thank you again for sharing your unique unsight. This is stuff that's really hard to find otherwise. I just wish all these details where in the package descriptions. It would be so incredibly helpful. Especially in -dev packages where the description isn't going to be seen by "casual" users anyway
The libssl-dev thing is because (usually) you can only have the headers installed for a single version of a library. So you get libssl-dev. But you can have multiple binary versions installed, to support other packages that may have been compiled with older versions of the library with incompatible ABIs & that haven’t been recompiled or updated to the latest version yet.
So you have a -dev package that depends on the latest binary package.
Sometimes, you have headers that live in their own versioned directories, so you can compile against older library releases (maybe there’s an API change & not all your packages have been updated to the new API yet). Hence the libssl1.0-dev, which put headers for the old libssl version in a subdirectory in Debian stretch (I think?) so they didn’t interfere with the ones for the new version.
It means light weight, like air. This comes from the name of the wind spirits, the Sylphs."
https://sylpheed.sraoss.jp/doc/faq/en/sylpheed-faq-1.html#d0...
(* tea piped through nose out to keyboard)
https://en.wikipedia.org/wiki/Revolutionary_Girl_Utena
> corosync
Not useful for Corona!
> figlet
Surprisingly - not a portmanteau of figure + piglet!
https://wiki.debian.org/WhyTheName?action=info
actual LOL
'dd' stands for copy and convert.
'cc' was taken by the C compiler.
'dd' is a JCL utility from IBM mainframes. Both the Unix command name and syntax are directly lifted from the mainframe version of the ... data definition ... utility.
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/...
https://groups.google.com/forum/m/#!msg/alt.folklore.compute...
https://groups.google.com/forum/m/#!msg/alt.folklore.compute...
* https://wiki.debian.org/WhyTheName?action=diff&rev1=14&rev2=...
* https://news.ycombinator.com/item?id=9323623
* https://wiki.debian.org/WhyTheName?action=diff&rev1=183&rev2...
Ok, I guess…?