
Fear and Loathing in Linux, or Who Needs /etc/motd (2010) - akkartik
http://web.archive.org/web/20131205090841/http://deadmemes.net/2010/10/19/fear-and-loathing-in-debianubuntu-or-who-needs-etcmotd
======
kevhito
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.

~~~
adrianratnapala
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.

~~~
pjc50
Well, apart from the most common screwup: changing something and then _not_
rerunning LILO.

------
0x0
Debian 8 has gone back to a normal file in /etc/motd and has gotten rid of all
the motd.tail shenanigans, though. :)

~~~
pdw
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.
    

Which seems pretty sane.

------
vmarsy
This seems to be a (2010) post.

> ….Did that really just take as long as I thought? This machine has a gigabit
> connection to the Internet. I must be imagining something.

> ….Okay, I wasn’t imagining something. It must have downloaded a TON of
> source!
    
    
      root@tessier:/usr/src/ubuntu# du -sh
      19M	.
    

> …Oh. I guess not. But, hey, fuck git, or something.

Having a gigabit internet connection means you can download any content from
any server in the world at 1Gb/s, right? _/ s_

The tone of the post makes it pretty hard to take that rant seriously.

~~~
eaceaser
Yeah. Honestly, of all things to be (ostensibly) this angry about...

~~~
tomc1985
One cut in a death by thousands perhaps?

This propensity for complexity is really irksome. The "generation lost in the
Bazaar" headline couldn't be better timed.

------
xupybd
This is the same crap they pulled with networking. The first 30 mins after an
Ubuntu install is now pulling out the automatic networking rubbish.

~~~
anonbanker
I think you'd really like Arch or Devuan. You seem to be progressing past
Ubuntu.

~~~
voltagex_
Couldn't you also say that it might be worth trying to help the Ubuntu project
get better by fixing some of these problems?

~~~
freshhawk
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.

~~~
zdkl
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.

~~~
aw3c2
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.

~~~
zdkl
Indeed. That and not installing packages on a whim!

------
tomc1985
Why do all these developers hate simplicity?

~~~
rakoo
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.

~~~
tomc1985
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

------
Paul_S
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.

------
dfox
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.

~~~
the_mitsuhiko
Where does it say that?

~~~
dfox
It seems to be somehow cut off, but:

    
    
           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.

~~~
prodigal_erik
What it clearly states is that the symlink is expected to exist, with no
assurance that something sane will happen if it doesn't.

------
keypusher
If you care about this kind of stuff, you may want to consider running
something other than Ubuntu. Debian, CentOS, FreeBSD, etc.

------
kasabali
Previous discussion:
[https://news.ycombinator.com/item?id=3325510](https://news.ycombinator.com/item?id=3325510)

------
reacweb
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.

------
ckastner
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.

~~~
gkya
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).

~~~
ckastner
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.

~~~
gkya
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.

~~~
ckastner
> 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.

~~~
gkya
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:

    
    
      mail -s '<subject>' $(awk -F: '/^<group-name>/ {print $4;}' /etc/group  | tr , ' ')
    

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.

------
znpy

        Please use:                                                                     
        bzr get https://code.launchpad.net/~ubuntu-core-dev/pam/ubuntu                  
        to retrieve the latest (possibly unreleased) updates to the package.
    

So we ubuntu users are possibly running possibly unreleased code to manage
authentication.

Isn't this like an ultra-serious issue ?

~~~
ckastner
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.

------
jimjag
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...)

------
Adutude
I think this might be a bikeshed discussion.

[http://bikeshed.com](http://bikeshed.com)

~~~
sp332
It's not just wanting the message to be different. It's that it is now very
difficult to figure out how to even change the message.

~~~
voidz
Not really. `pam` is where you look.

~~~
CaptSpify
Your kind of proving the point though. WTF does 'pam' have to do with the
motd?

Thats a complexity that doesn't make any sense.

~~~
digi_owl
Welcome to "modern" Linux where PAM is everything.

PAM is why systemd has its own SU replacement, because their Logind PAM module
was mangling environment variables when SU was used.

------
charonn0
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.)

------
rlpb
Don't like it? Just drop the calls to pam_motd.so from /etc/pam.d/login. Done.

~~~
eropple
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!

~~~
voidz
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..

~~~
CaptSpify
Why does the motd need any interaction with pam? Those are two completely
separate things

------
qwertyuiop924
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?

~~~
colemickens
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.

~~~
qwertyuiop924
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.

~~~
serge2k
So this article has nothing to with systemd.

~~~
qwertyuiop924
...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.

~~~
prodigal_erik
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.

~~~
qwertyuiop924
Which is what I said in my original post.

