Very unhappy with FreeBSD 13 MOTD

[mer]

Maybe the OP finally has changed? He was last time seen on the forums on Dec 11, 2021

Sorry, it was ramib that picked up the thread and finally figured out fortune.

 

[getopt]

Sorry,

No reason for saying sorry.
It was more an opportunity for funny writing.

Trained to find bugs in code it's even more fun to "debug" text.
I appreciate your writings no doubt about that.

 

[MakeItSnappy1234]

Most new operating systems that were once good are now over-engineered which defeats the purpose of what they were.

 

[astyle]

Most new operating systems that were once good are now over-engineered which defeats the purpose of what they were.

This sounds like you've been trying derivative projects. I'd suggest going upstream.

A derivative project is not the same thing as a completely different OS. For example, Debian has Ubuntu as a derivative, Arch has Manjaro as a derivative, FreeBSD has MidnightBSD as a derivative.

 

[Dan The Man]

This may not be the right audience, but I'm very displeased with FreeBSD 13 changing the traditional /etc/motd logic and turning it into what I see as over-engineered triviality which contradicts the unix philosophy. I don't know where is the right place to express my thoughts about it, sorry if this isn't one of them.

IMO, if someone wanted to make MOTD more generic/flexible - they should have written a port to automate that, rather than breaking half a century of unix motd implementations and deviating further from all other unix-like platforms; for what though? for motd? because they didn't want to periodically change a config in /etc/? I don't understand this, and until I do this will continue to seem whimsical and unnecessary.

Does anyone have a rationalization for changing something so simple yet fundamental at the cost of half century of unix lineage and interchangeability?

cd /etc; rm motd; ln -s motd.template motd
service motd restart

 

[kpedersen]

cd /etc; rm motd; ln -s motd.template motd
service motd restart

Lets get this fix pushed upstream!

 

[wayne47]

Just got bit by this. Yet another annoying "feature" degrading the OS for no good reason (FreeBSD is picking up more and more stupid over time). If the entire purpose was to eliminate changing /etc, there was no reason for a service or template.

freebsd-update should have copied /etc/motd to /var/run/motd and replaced /etc/motd with a symlink to /var/run/motd. Boot could then update /var/run/motd.

No significant user impact. No extra service.

 

[drhowarddrfine]

I thought this whole thread was started as a lark. Just for fun. I still question the sincerity of it.

 

[Cath O'Deray]

If the entire purpose was to eliminate changing /etc,

It was not.

 

[Alain De Vos]

I installed "fortune". I'm already rich.

 

[kpedersen]

If the entire purpose was to eliminate changing /etc, there was no reason for a service or template.

I also think the change was of dubious benefit. Having an motd service is such a pointless addition of complexity for something so trivial.

Based on the man pages, I am inclined to believe it is so that the FreeBSD version can be appended onto the motd that gets generated rather than the user needing to keep it in sync in the motd file. Presumably, for people who updated the OS for a long time i.e 8.x -> 10.x were a little confused that the original motd still had the 8.x release tag. So basically this does create a cleaner update process.

However, perhaps they should have just gotten rid of the release tag entirely from motd and instead the individual program (login?) that displays it could just output the release tag itself.

 

[olli@]

FreeBSD always modified /etc/motd during boot and updated the version information. It did that since day 1. In ancient times, the modification was done by /etc/rc, and when rc-NG was introduced, that task was delegated to /etc/rc.d/motd. This is not new in FreeBSD 13; the motd service exists for a very long time, as does the ability to do “service restart motd” to update the version string in /etc/motd.

The long-standing problem with that approach is the fact that /etc is not meant to be used for files that are regularly being written to during the boot process. This is exactly what /var/run is meant for, see the hier(7) manual page. So that problem was fixed in FreeBSD 13 by splitting the file into a static file that remains in /etc, and a dynamically generated file that is properly placed in /var/run (symlinked to /etc/motd for compatibility). That’s all. This change improves cleanliness and consistency of the file system layout, and it also benefits certain installations like embedded systems that have /etc on read-only media.

If you don’t like any of that, then put update_motd=NO in /etc/rc.conf and do whatever you want with /etc/motd and/or /var/run/motd. They will never be touched by any automatism. This isn't new in FreeBSD 13 either; the “update_motd” switch exists for a very long time, dating back to the pre-rc-NG era, when /etc/rc did all of those jobs.

 

[marian_cerny]

Very happy with FreeBSD 13 MOTD​

I on the other hand welcome this change to motd. Finally I do not need to manage changes to /etc/motd each time I update the system (kernel) in my versioned configuration management. And I can still use custom message in /etc/motd.template.
(I am also happy the RCSID $FreeBSD$ tags have been removed.)

 

[kpedersen]

(I am also happy the RCSID $FreeBSD$ tags have been removed.)

How so, out of interest?

Did you not find them a useful indicator for things such as issue reproduction / development?

 

[marian_cerny]

How so, out of interest?

The same reason. I won't need to manage (unnecessary) "merge" conflicts around RCSID tags with every minor or major FreeBSD system upgrade with my versioned configuration files management.