As a reluctant admin for a half dozen odd home and work systems, and having just dealt with a few clean reinstalls, the /etc/motd issue bit me too. It also reminded me a bit of the horror that grub configuration has become.
When I started years ago there was LILO. It had quirks and was a pain to configure. Then grub came along and it had some great new features -- edit the easy-to-understand config file, and changes would automatically take effect. Easy background images. Easy menu building in the config file. Grub understood enough of the filesystem to avoid the LILO cruft.
Now there seems to be about 5 layers of indirection, autodetection, probing, and shell scripting hacks to generate scripts that will eventually spit out a mess of obfuscated grub config files, and god forbid you touch any of this mess because any changes you make will be overwritten (a) next boot, (b) next time the scripts decide to update the config, (c) next system update, or (d) just whenever. All of this dynamic stuff to configure something that, for many systems, needs a config change about zero times per year.
I'm with you except that I never understood grub, not even when it was new and innocent.
It's not even fair to say LILO was "a pain to configure". `lilo.conf` was pretty clear and straightforward.
It's just that boot-loading is arcane and dangerous. This makes it possible to make your LILO screw-ups really simple and obvious. Which is much better than the kind of screw-ups you can make with GRUB.
I find grub incomprehensible so I still use lilo on my home computer.
It works every single time without even one failure. On the other hand grub has failed me multiple times on the machines it's installed on.
Grub has an overly complex config that you can't verify until you reboot and try it - if it fails you have a huge pain trying to get the exact right code to type in to make it work.
Lilo on the other hand either works, or it tells you it didn't before you reboot, which makes it much more reliable.
I know nil about bootloaders, but about until 6 months ago, I used syslinux to load Arch for a bunch of years and it just worked (since then I departed for FreeBSD where you don't care about the brand of your bootloader). IDK if I ever saw the config file for that actually.
I still have lilo on my slackware-based machine. And you know what, while I have countless troubles with grub (couldn't find the initrd, couldn't install itself to the MBR though it pretended there was absolutely no error, etc, etc), LILO never failed me: when you run "lilo" if it says "installed successfully", well at least it's installed.
Yes. The description section of Debian's motd(5) manpage now reads:
The contents of /etc/motd are displayed by pam_motd(8) after a successful login
but just before it executes the login shell.
The abbreviation "motd" stands for "message of the day", and this file has been
traditionally used for exactly that (it requires much less disk space than mail
to all users).
On Debian GNU/Linux, dynamic content configured at /etc/pam.d/login is also dis‐
played by pam_exec.
Have you used Bazaar? I wouldn't blame you if you haven't.
This is not about the server being slow, it's that Bazaar is really astonishingly inefficient and badly designed. Look at the guy in the replies who says "it's not that bad, I can clone a bzr repo in under 2 minutes". That is what you get used to when you use Bazaar.
>Having a gigabit internet connection means you can download any content from any server in the world at 1Gb/s, right? /s
Anecdotal, but bzr(1) has always run fairly slowly for me. I don't know much about it, so perhaps I'm doing something wrong, but I've never gotten it to download at more than a few KBps, when git(1) manages to hit my max download speed easily.
These aren't problems to that community, it's a difference in goals. Ease of use and simplicity are very often trade-offs.
I use Arch at home and Ubuntu servers and containers at work. Ubuntu auto-detects and auto-configures much more than Arch does but that last 10% can be a hell of fight with Ubuntu due to the added complexity.
I followed a similar path. I love Arch but in terms of reliability I don't trust that I'll have a workable system at an arbitrary time. Manjaro is a good compromise between Arch and Ubuntu goals I believe: it works with a well rounded desktop environment on top of Arch out of the box and there wasn't much to rip out off the fresh install.
I've had several (non technical) friends report basically no issues on either install process or daily use. Not to go all fanboy on this thread but that distro restored my faith in using linux on a general use laptop.
As long as you don't update at random times, the "workability" should be very predictable. And breaks on updates have become extremely rare for me, although of course it depends on your packages and configuration.
What Manjaro did for Arch, Calculate did for Gentoo. I don't even mind the occasional package compile, as most is binary-based, and everything just works.
I'm dumping Ubuntu. They think that all these churning changes are improvements and they are too swayed by their own intellectual arguments as Engineers. If you look at history, Windows overtook Apple when Apple broke compatibility to improve their product (most people have forgotten that at one time Apple was ahead of Windows in the PC world - and many thought that Windows didn't stand a chance.) Even great product changes have a cost - and they don't seem to understand that.
Ubuntu will still be very compatible with Debian, which provides second-only-to-Redhat levels of compatibility and package availability. The problem is their internal application ecosystem; instead of contributing Wayland and GNOME/KDE, they decided to reinvent the wheel. Yes, they have Samsung and other corporations on-board to support their vision, but it doesn't contribute to Linux/GNU overall.
I dumped Ubuntu when the Unity Netbook Edition switched from the (beautiful) EFL libraries to Qt, which added significant performance penalties, and then the main distro adopted the new interface. It felt like everything could've been built upon Plasma 5, but because it wasn't controlled by them, they had to make their own in order to be XKCD-927 Compliant.
Honestly, I think it comes from the need to pad resumes. "Rewrote motd system" sounds a lot better than "Reviewed existing motd system, couldn't see any need for improvement"
Because they have different needs ? Maybe they do want to see how many processes are running, who's connected, and some simple status on the machine, contrary to OP ?
Their fault is not so much in complexifying motd, it's in removing the simple options for the majority of people who don't need the added configurability.
Complex problems sometimes require complex solutions. I get it. But this implementation, where all are suddenly thrust into the complex solution for something that the collective memory determines to be simple, is a net negative.
I have the same complaint about what has happened to Xorg.conf, or grub2. Yay, they are more flexible and dynamic. But they also run contrary to Unix philosophy of simplicity
I remember when I ran into login issues after switching from debian and tracking it down to the motd clusterfuck. My solution was to use hosts file to block any attempts to communicate with canonical. Probably saved myself extra hassles with other "smart dynamic" solutions.
It seems to me that the cited motd(5) manpage cleanly states that breaking the /etc/motd symlink is what you should do if you want to manage it's contents yourself.
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 agree with most of this very interesting rant. Stupid changes like this one makes many people lose a lot of time.
Stupid changes will always occur. They may even be fixed one day. For me, the big problem is that software changes should imply an update of the man pages.
When I introduce unix (shell) to someone, I always start with the command man (man man).
I dream of a system where all the commands and all the options are documented in man pages that are up to date.
It is almost comical how the author went info full rage mode about a change without even pretending to try to comprehend why it was implemented.
Yeah, why would you want to generate the motd -- the message of the DAY file -- dynamically, through a daily cron job? Ludicrous! That file is supposed to be static!
And that was literally just the opening statement. The rest of the article is also littered with misinterpretations and misrepresentations.
That's not what he criticises. His criticism is about all the bloat that's there as layers of unnecessary abstractions for what can be done with a simple script that's run regularly by cron as root (or rather as a separate motd user who can write to /etc/motd, for better security).
A simple script may be sufficient to address your needs, but please don't generalize that to everyone else.
Simple counter-example to your point: other Debian packages who wish to provide information in /etc/motd. The solution to go with drop-in directories (just like /etc/cron.d) has certain advantages over other patterns, but the author seems to be oblivious to all of this.
It should be obvious how to disable the mechanism for being able to use the normal, expected behaviour. The author is hostile in his way of writing, but the point stands. Furthermore, motd is a tool for sysadmin anouncements, not random news from random packages, so autogenerating is not all that useful.
> It should be obvious how to disable the mechanism for being able to use the normal, expected behaviour.
The author posted the following as the conclusion of the article: remove the symlink, create your own motd.
root@tessier:/etc# rm -rf motd && echo "DO I WORK NOW??" > /etc/motd
It doesn't get much simpler or intuitive than that.
> Furthermore, motd is a tool for sysadmin anouncements, not random news from random packages, so autogenerating is not all that useful.
Nobody suggested it was for random news for random packages. Useful examples would be output from smartmontools, unattended-upgrades, systemd or any other sysadmin-relevant package which might perform periodic tasks in the background.
For your examples, local mail is more fit than anything. The user may want to look back to past notifications, archive, delete, read later etc. It's easy, just run "mail <user>", or:
Good use of motd: pointers to essential reading for new users, like a tutorial, some man pages, etc.; contact information, to sysadmins, product help desk etc. The user reads it to get clues on how to get going with the system, then runs 'touch $HOME/.hushlogin' to silence it.
Edit: Besides, the manual does not tell you that simply breaking the symlink will do the desired effect.
> Yeah, why would you want to generate the motd -- the message of the DAY file -- dynamically, through a daily cron job? Ludicrous! That file is supposed to be static!
Running a set of shell scripts on every login is not the same as generating a file through a cron job. The author is complaining about the former, while you're stating he complains about the latter.
It's would be proper to take care not to misrepresent matters while accusing others of doing it.
No, because that is not what is happening. The author is completely misconstruing that information fragment.
apt-get source <package>
will get you the exact source of the package as released = installed on your system (assuming only one version is present -- otherwise, it returns the newest, but this is configurable).
The message you are seeing is a hint to other developers that the development HEAD is in Bazaar.
This is similar to the relation between GitHub releases, and the master branch.
It was the systemd of its day... Declare it "broken"; "fix" it; Make it super complex and ignore some of the basic tenets behind the success of Unix-like system ('everything is a file', 'avoid monolithic code', 'filters and i/o redirection', etc...)
It's not even wanting it to be different: it's wanting complete control of the processes. I am positive that the more complicated motd is vulnerable in some way the basic motd is not.
Why not unset the execute bit on the motd shell scripts? I seem to recall that being the solution for disabling motd in Ubuntu (at least it was a few years ago when I did it.)
I feel obligated to point out that having to "just" do that is kind of really insane. Making the default provide effectively useless information (nobody's gonna scroll back to read that motd for an IP address and it sure doesn't replace running htop for system info), and then making actually fixing the original mistake difficult and annoying, is not a good look.
Also, as the sibling notes, this kills MOTDs entirely, not because for some reason we need to bolt this whole contraption together and then not really document it at all. Ubuntu!
> Making the default provide effectively useless information...
That's quite presumptuous I think. You may find it effectively useless. Others may not. The job of a default is to cater for a majority. One size does not fit all, so it is certain that there will exist people unhappy about the default whatever it is. So just because some number of people complain does not mean that the default is wrong.
On the other hand, I accept the documentation could be improved, but this does generally need someone other than the author to point out deficiencies. The author could have written and submitted a documentation patch in the time it took him to write that blog post.
You use a lot of words. Insane? It is actually quite the opposite, pam is where the author should have started. Not knowing about pam and refusing to learn about it, as a server administrator: if I ever would call something insane..
It looks like that also skips displaying /etc/motd. If you just want to skip regenerating /var/run/motd, you have to blow away /etc/update-motd.d but continue running pam_motd.so because it's bizarrely responsible for both.
Ah... And we see one of the many roots of the cancer that metastacized into systemd. Because everybody expects all their live processes (screen included) to die when they log out, right?
What does this article have to do with systemd, let alone the very specific, recently-widely-discussed issue you're referencing to?
edit: Thanks for the downvotes! I love that anything can be used as a non-sequitur to start bagging on systemd these days. Apparently it's wrong to even ask someone how this article about motd relates to systemd. I'll try to remember that.
It's another example of invalidating an old convention for no good reason.
And the entirety of systemd is an overly complex mess that does a lot of this. It tries to replace cron. It tries to replace automounters. It tries to replace inetd. It will try to replace dbus, with the aid of the kernel. It replaces everything for no good reason, and that which it doesn't replace, it consumes.
Do one thing well, work together, and handle text streams? More like do everything meh, work alone, and handle binary formats known only to you.
...Aside from the fact that the article is about the attitude amongst devs that manifested itself both as the motd-framework and as systemd, making this article thourougly linked to systemd, yes.
The problem is bad taste about how responsibility and customization should be divided between discrete components, and how the boundaries should be managed over time. systemd is merely another symptom.
1. Take something with an established functionality, that works, at least to some order (I'm aware of the debates on this concerning systemd).
2. Replace it. Without apparent option. In the /etc/motd case, the problem was one of swapping a read file with a dynamic process in more-or-less the same namespace. Systemd at least advertises its malevolence.
3. Fail to adequately document behaviours.
4. Deprecate bug reports.
5. Create a fragile system within a core system context (login(1), init(8)).
>edit: Thanks for the downvotes! I love that anything can be used as a non-sequitur to start bagging on systemd these days. Apparently it's wrong to even ask someone how this article about motd relates to systemd. I'll try to remember that.
I agree you shouldn't have been downed, but I DID explain in detail, as did others, why my post wasn't a non-sequitur.
When I started years ago there was LILO. It had quirks and was a pain to configure. Then grub came along and it had some great new features -- edit the easy-to-understand config file, and changes would automatically take effect. Easy background images. Easy menu building in the config file. Grub understood enough of the filesystem to avoid the LILO cruft.
Now there seems to be about 5 layers of indirection, autodetection, probing, and shell scripting hacks to generate scripts that will eventually spit out a mess of obfuscated grub config files, and god forbid you touch any of this mess because any changes you make will be overwritten (a) next boot, (b) next time the scripts decide to update the config, (c) next system update, or (d) just whenever. All of this dynamic stuff to configure something that, for many systems, needs a config change about zero times per year.