Very unhappy with FreeBSD 13 MOTD

There was some recent news about "useless" commits to the Linux kernel by some Huawei employees. Speculation was that this was for some KPI (key performance indicators) credit. Any commits by an employee to the Linux kernel would surely count as "meaningful" work, right?! Not saying this is what is going on WRT the motd commit but the thought did cross my mind. May be commits should be checked for such uselessness?
 
rotor said:
Dell EMC probably wanted to have a commit to FreeBSD, so they chose the MOTD non-problem to fix.
Click to expand...
Nonsense. Isilon (now a division of Dell/EMC) have been heavy users of FreeBSD for at least 10 years. Their storage appliance is built around a modified version of FreeBSD, using their own cluster file system.

These people are professional software engineers, not amateurs. They don't write software unless there is a reason for it.

Makes sense now. :)
Click to expand...
🤣

Although Bakul's theory is even more laughable. The level of paranoia in this forum is close to the point where participating in it no longer makes sense.
 
As I wrote before, it is /etc/rc what adapted /etc/motd to contain the first line with the kernel info.
If you change the kernel without rebooting (laugh) or write a completely new motd without
the kernel info, you needed to reboot to get the first line correct. It is in my opinion bad design.

The change in 13 solves this bad design with worse design.

The best solution would have been to leave the admin to write the first line, if he wants it.
Just to delete the code in /etc/rc that change motd. The other solution would be debians
one, it shows the info, but not from motd. But as a service you can now perhaps disable
this mechanism without deleting in rc, perhaps an advantage.
 
mark_j That has absolutely nothing to do with what I said. To explain further, what I said was, if you want to know the answer to the question, "Why?", go to the mailing lists or irc and ask the people who did this that question because no one here has the answer.

That the end user might be bothered by this has nothing to do with anything I said.
 
tux2bsd said:
To get back on-topic, I'll repeat myself about the proper way motd should have been modernised:
By default /etc/motd text file, as it was. A more complex motd could then be installed via ports/pkg if desired.
Click to expand...

hruodr said:
There was nothing to modernise.
Click to expand...

I agree. If someone did want to expand on motd, for whatever crazy reason, then it should be done externally to the OS (i.e. ports/pkg).
 
mark_j said:
And you'll see nothing as /etc/motd is not used unless you stay on 12.
Click to expand...
What will happen if he opens /var/run/motd with a text editor?


Tell me, tell me, tell me do...


Because it looks much the same from the man page:

From OP's post:
Code: 
DESCRIPTION
The file /var/run/motd is normally displayed by login(1) after a user has
logged in but before the shell is run. It is generally used for
important system-wide announcements. During system startup, a line
containing the kernel version string is prepended to /etc/motd.template
and the contents are written to /var/run/motd.

/var/run/motd can be updated without a system reboot by manually
restarting the motd service after updating /etc/motd.template:
service motd restart

Individual users may suppress the display of this file by creating a file
named “.hushlogin” in their home directories or through login.conf(5).

From my FreeBSD 12.2-RELEASE-p7 man page:
Code: 
DESCRIPTION
     The file /etc/motd is normally displayed by login(1) after a user has
     logged in but before the shell is run.  It is generally used for
     important system-wide announcements.  During system startup, a line
     containing the kernel version string is prepended to this file.

     Individual users may suppress the display of this file by creating a file
     named ".hushlogin" in their home directories or through login.conf(5).
 
Note that if you create a /etc/motd and don't have a template yet, it will automatically get converted:
Code: 
        if [ ! -f "${TEMPLATE}" ]; then
                # Create missing template from existing regular motd file, if
                # one exists.
                if [ -f "${COMPAT_MOTD}" ]; then
                        sed '1{/^FreeBSD.*/{d;};};' "${COMPAT_MOTD}" > "${TEMPLATE}"
                        chmod $PERMS "${TEMPLATE}"
                        rm -f "${COMPAT_MOTD}"
                else
                        # Otherwise, create an empty template file.
                        install -c -o root -g wheel -m ${PERMS} /dev/null "${TEMPLATE}"
                fi
                # Provide compatibility symlink:
                if [ ! -h "${COMPAT_MOTD}" ]; then
                        ln -sF "${TARGET}" "${COMPAT_MOTD}"
                fi
        fi
 
Reading the whole thread, and motd(5), I am still not sure about what’s the canonical way of turning off the „message(s) of the day“ altogether. While I like the OS information, I dislike aleatory messages of Drew in special, and in general any stuff which you get without having asked for.

In the moment I have an empty /etc/motd.template, is this the correct way of suppressing any of the messages?

My son uses Windows 10 for gaming, and I set up the machine in 2019 and ever since I only made sure that it becomes updated frequently, without paying too much attention to the UI. Yesterday, I entered into my admin account of said machine, and suddenly in the task bar I recognized a weather and news item, that must have happened in the course of the 21H1 update, WTF, a visual motd. And the best of all, it came with similar obstacles like our new motd(5) on how to turn this off.

I am not so much concerned about the exact mechanism, I dislike the missing/hidden OFF setting/button.
 
obsigna said:
In the moment I have an empty /etc/motd.template, is this the correct way of suppressing any of the messages?
Click to expand...
In that case the MOTD will only contain the FreeBSD version number.

If you don't want an MOTD at all, rm /var/run/motd and sysrc update_motd="NO"
 
ralphbsz said:
These people are professional software engineers, not amateurs. They don't write software unless there is a reason for it.
Click to expand...

So then, what is that reason?

I've still not seen a use case for this change. I've still not seen a list of problems that needed to be solved. Was this implementation the only possible way to solve the problems? Could there have been another less-intrusive solution?

Lots of people seem to be defending a change, yet no one seems to know the reason the change was made.

Isn't that odd?
 
rotor said:
I've still not seen a use case for this change. I've still not seen a list of problems that needed to be solved. Was this implementation the only possible way to solve the problems? Could there have been another less-intrusive solution?
Click to expand...
rc now does not modify a file on /etc, but on /var/run. It has sense to have a read only /etc, and anyway
/var/run must be writable. The "solution" was to make the rc mechanism more complicated: why not, if
it is jet complicated enough? In OpenBSD the code that modify /etc/motd is stil on /etc/rc. And still there
are other files in /etc that are modified by the system, you know the old resolv.conf that is modified by
dhclient.
 
rotor said:
what is that reason
Click to expand...

Fsync issues in jails or something. The problem was something along the lines of "I update this file in a esoteric but supposedly supported way, and it doesn't work."

rotor said:
Was this implementation the only possible way to solve the problems? Could there have been another less-intrusive solution?
Click to expand...

This gets into "Did you just volunteer for coding up solution #3?" and "This discussion was held in 2019."

"I like text files" and "This was unnecessary" are not good arguments against a vendor who sponsored (aka probably paid a developer) a fix to a problem. You could email the developers for more specifics but you're close to running up to a poisoned well here. Why should anybody bother explaining it to you if they expect you to just use the explanation as a club against them and not deliver Solution #3? Go look at the phabricator logs to see that there's a lot of back and forth and problem solving that you'd be signing up for.
 
I wonder if you did a git blame on the files would you get back to a commit message that has pertinant information?

On the other hand is there any more horse left to flog?
 
msplsh said:
This gets into
Click to expand...

To my eyes, what it actually gets into is that "open source" is not "open process."

The user community does not seem to know the reasons behind this rather drastic change to a minor, yet significant aspect of FreeBSD.

It is all the more troubling that the reasons for the change are not apparent.
Why are they being hidden?

Are the reasons that undefensible?
 
The reasons seem to be technical, so the technical people are dealing with them. Nobody is having a technical problem with having to do MOTD updates differently. If you were, then get on the mailing lists and articulate them.

/etc/passwd has changed from a flatfile to a multi-flatfile process. What's the big deal with this less significant thing? Nothing.
 
You must log in or register to reply here.
Back
Top