As with many things Linux there are a lot of cultures that feed into it. And the author's frustration on the implementation of motd serve as a reasonable exemplar of this.
There are two (maybe three) nominal 'people' in this particular circle of hell, one is the developer who originally felt that the message of the day should reflect something important without having to actually edit it every day. One is the guy who wants the motd to have something different in it. Culturally the first guy is the 'lazy' type (in quotes because it reflects the culture of "hey I've got a computer here the more work it does the less I do" which is a popular meme in system administrator circles and elsewhere) and the other is the 'KISS' type (where KISS is the 'keep it simple stupid' type of person who oftens stresses simplicity over mechanism. The third (perhaps absent) person is the 'systems' person/distro owner who imposes an implicit design guideline on the system by virtue of the changes they accept or don't, commit or don't into what becomes the final product. In the kernel tree this is clearly Linus but in other parts of the system it isn't always clear whether or not there even is someone in this role.
Underlying this I find a strong sense of frustration at changes that are made to 'small, meaningless' parts of the system when large parts sit there on fire. Of course not everyone can fix bugs in EXT4 or memory leaks in long running daemons, everyone needs to start somewhere, and sometimes changing the colors around in ls(1) so that the default is unreadable on your favorite color scheme is probably some 'starter project' of someone who wants to become a bigger part of the solution.
It is the experience you get when you use Linux, and that experience is an artifact of how Linux is created. So hating it isn't particularly productive, although like UNIX-haters before it rooted in much the same arguments.
Without debating the (IMO very questionable) utility of changing motd behavior, or the (IMO too sloppy) change management of Ubuntu...
A three-line update to man motd would have solved the problem, and the motd maintainer didn't do that, and whoever accepted the patch didn't do that, and now anyone who wants to figure what the Penguin is going on is going to have to google for it and, hopefully, find the answer before they hit the "download source" rabbit hole.
All because of a few sentences.
Yeah, at home I don't use Ubuntu directly anymore. =)
> On Debian GNU/Linux this file is a symbolic link pointing to /var/run.
The contents of this file are regenerated upon every system boot based
on the contents of /etc/motd.tail.
The fundamental problem here is the blog author didn't realize that `echo foo > /etc/motd` wouldn't work, even though the manpage did, in fact, inform him that /etc/motd was just a symlink to something that gets regenerated at boot time. I'm not really sure what the manpage could have done to make it more obvious what his problem was.
Now, it's possible the manpage is out of date, and that it's regenerated via some other mechanism than /etc/motd.tail. I don't know (since I don't use Debian, or even Linux in general). But the salient point here was that it points to a file that gets regenerated at boot time.
*Edit: On second look, it sounds like this change makes it regenerate on each login, not just each boot. I can understand why someone might think that `echo foo > /etc/motd` followed by a login would then print 'foo', given the current manpage. But they certainly wouldn't expect that it would still print 'foo' after a reboot unless the break the symlink (and breaking the symlink fixes the author's complaint).
The manpage says:
> On Debian GNU/Linux this file is a symbolic link pointing to /var/run.
> The contents of this file are regenerated upon every system boot based
> on the contents of /etc/motd.tail.
I do not know how one can go from this to "to get traditional behavior, delete the symlink and make /etc/motd a regular file." Great, so it's a symlink to a file that gets regenerated. Now how do I make it do the traditional thing? The manpage doesn't offer any help, and I couldn't figure it out if I didn't know the answer already.
Furthermore, having a configuration switch depend on whether a file is a symbolic link or not is just asinine.
I've been using Debian/Ubuntu since ~ 1999, and it took be about 20 seconds to figure this out. "ls /etc/motd. Oh, it's a symlink, ok, rm /etc/motd. Done."
In Debian, almost everything in /etc can be edited, and the system is designed to preserve the sysadmin's changes. Maybe this isn't obvious to new users, but if you've been using Debian for a while, this behaviour is exactly what you would expect.
Also, a quick visit to #debian or #ubuntu IRC would have resolved this in a few minutes.
"On Debian GNU/Linux this file is a symbolic link pointing to /var/run. The contents of this file are regenerated upon every system boot based on the contents of /etc/motd.tail."
It should probably read:
"On Debian GNU/Linux this file is usually a symbolic link pointing to /var/run. The contents of the file in /var/run are regenerated upon every system boot based on the contents of /etc/motd.tail."
To make it clear that the programs that generate the contents target the file in /var/run, and do not operate directly on /etc/motd.
Manpages for specific utilities really should not be reiterating basic unix knowledge (e.g. that piping data to a file via the shell > operator doesn't break symlinks).
How else are new users supposed to find out? Man pages are often poorly written and unhelpful. Indeed, calling the utility 'man' instead of 'help' is unhelpful.
You have got to be kidding! Man pages are amazing - often you can figure out what is going on or what niche switch you want to use much quicker with a man page than Google.
I agree; I use Linux infrequently, and I've always found the man pages to be chock-full of details on how to use particular switches, but lacking in examples. I usually have to read them very closely just to get to the point of "look, I just want the basic usage on this tool so I can do X, the thing the tool is made for, rather than X -q -m -p."
I sure hope you would not write it that way, with a double negative. "Regeneration will occur if /etc/motd is a symlink to /var/run/motd"? Still not nice, but IMO easier to understand.
In the kernel tree this is clearly Linus but in other parts of the system it isn't always clear whether or not there even is someone in this role.
In the case of Ubuntu I think this definitely happens, although AFAIK the high-level design discussions & decisions largely happen behind closed doors (happy to be corrected on that point.)
In this case I wouldn't be surprised if there was a requirement/design decision to have the system explicitly remind the user if there were pending package/security updates and also prompting you about available new distro versions. At least, on default Ubuntu systems the motd does these things and has for some time - and it feels to me like a "by design" thing.
Why they rolled it from an update-motd standalone package to a built-in part of the pam module, I have no inkling over, though.
There are two (maybe three) nominal 'people' in this particular circle of hell, one is the developer who originally felt that the message of the day should reflect something important without having to actually edit it every day. One is the guy who wants the motd to have something different in it. Culturally the first guy is the 'lazy' type (in quotes because it reflects the culture of "hey I've got a computer here the more work it does the less I do" which is a popular meme in system administrator circles and elsewhere) and the other is the 'KISS' type (where KISS is the 'keep it simple stupid' type of person who oftens stresses simplicity over mechanism. The third (perhaps absent) person is the 'systems' person/distro owner who imposes an implicit design guideline on the system by virtue of the changes they accept or don't, commit or don't into what becomes the final product. In the kernel tree this is clearly Linus but in other parts of the system it isn't always clear whether or not there even is someone in this role.
Underlying this I find a strong sense of frustration at changes that are made to 'small, meaningless' parts of the system when large parts sit there on fire. Of course not everyone can fix bugs in EXT4 or memory leaks in long running daemons, everyone needs to start somewhere, and sometimes changing the colors around in ls(1) so that the default is unreadable on your favorite color scheme is probably some 'starter project' of someone who wants to become a bigger part of the solution.
It is the experience you get when you use Linux, and that experience is an artifact of how Linux is created. So hating it isn't particularly productive, although like UNIX-haters before it rooted in much the same arguments.