Very unhappy with FreeBSD 13 MOTD

the reasons seem to be technical, so the technical people are dealing with them

"seem to be"

Oh please.

You totally misunderstand the audience you are addressing.

I repeat -- what are the reasons? What process allowed this change?

(why is it so difficult to get those simple questions answered? Is this the wireguard fiasco repeated?)
 
You seemed to understand the "not an open process" concept pretty well, so... what's so difficult about people not feeling the need to explain themselves to people who aren't stakeholders? Dell is a large company presumably asking a reasonable request. Fsync seemed like a real easy solution. Turns out it wasn't, so they took this measure. Reading between the lines is not enough?

End users don't participate in the dev process. It doesn't matter what the process is to you because what are you going to do about it now that you would have done earlier?
 
why is it so difficult to get those simple questions answered?
As I mentioned earlier there is a group of people that prefer to derail a discussion.
End users don't participate in the dev process.
The same can be said for most software. It does not stop the end user feeling or knowing that a poor decision was made, people can talk about that if they want.

Hell. /etc/motd could have been moved to /etc/motd.original (if /etc/motd existed) and /etc/motd could have been made a file that contained message "/etc/motd is not what it was, please read man page blah"

I tend to remove/truncate the motd anyway so my needs are simple. I can appreciate some people want more, that should be done adding additional software.

What annoyed me most was the unwritten: fuck you figure it out.
 
That FreeBSD Developers are making motd more complicated shows that either they are neglecting important things or that there are too much unnecessary developers. It is like the story of lua in the boot loader. My opinion.
I think this kind of position is hilarious. When you have a development team under contract you can tell them what to do, when you are relying on people volunteering their time you can't say "don't work on that thing that seems important to you, instead work on this".
Sure, you can ask folk to focus on something specific, you can ask committers to spend their time reviewing certain changes over other ones. But if you demand I'm sure you'll find volunteers will stop volunteering.

When we get companies volunteering their work there has to be an appreciation that whatever they are volunteering is helping them and maybe we benefit. FreeBSD doesn't have to accept it, of course, but I'd like to think that there is discussion about changes - I suspect there is but there are too many open/half-open places for it to take place: IRC, possibly multiple mailing lists, reviews.freebsd.org, hallway track at conferences, meetups, etc.
 
Dell is a large company presumably asking a reasonable request.

So you admit you do not know whether or not their request is reasonable. And why does being a large company automatically make a request reasonable? Is a bully always right?

What i know so far, there was some unknown issue with /etc/motd. (still unknown, after days of asking what it was)

Dell EMC came up with some bizarre solution that requires a daemon.

What is not known - what other alternative solutions, besides fsync, were examined, if any.


Could it be possible that the root problem was in what Dell EMC was trying to do with /etc/motd, and not really the process of updating motd? Has anyone discussed that aspect?

So, yes, I acknowledge that FreeBSD is open source but closed process.

The wireguard fiasco has shown that a closed process involving companies may not be as good as all have hoped....

Did FreeBSD learn from that?

Jus' sayin'
 
Sorry, but we have to dial the artificial anger and rhetoric down a little bit. There is ZERO evidence that Dell EMC was acting as a bully. There is zero evidence that this decision is bad. The claim of "days of asking" is irrelevant, as this forum is not where answers will be found, if any. The solution is not bizarre: a daemon is the standard solution for boot-related things (such as recording the OS version). Open source does not imply that every newbie on the forum has to be involved in decisions. And I see no parallels with wireguard. Nor was wireguard a fiasco, I would describe it as a typical example of schedule slip and project setback that happens in software engineering all the time. Finally, just to be clear: the party involved here is not Dell EMC (the whole company), but Isilon, a division of Dell EMC, and a heavy FreeBSD user and contributor.

Personally, I have no opinion on this change, and no horse in the race. But we need to all be a little respectful, and stop being so paranoid and self centered.
 
I think this kind of position is hilarious.
Honestly, the whole thread is hilarious.

This is such a minute change it's perplexing that it's even worth worrying about. The as-is instrumentation makes editing /etc/motd.template so trivially close to what you want anyway, why not go with that?

You could go a step further and remove the motd service from your system and go back to ye olde ways. It's your system, after all. Heck, you could even fork FreeBSD to have "FreeBSD without motd.template"
 
It is not hilarious. The original poster asked:

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

I think, the forum is for asking that questions.

I think that would have been the theme of the thread. If the change would have used
/etc/motd as /etc/motd.template, perhaps very few would have
noted the change.

I never paid attention to motd, and I do not like what it was (changing files that one write).
 
I think that would have been the theme of the thread. If the change would have used
/etc/motd as /etc/motd.template, perhaps very few would have
noted the change.
Correct. If my motd produces something I want to change I reflexively edit /etc/motd... and if that edit doesn't work I get pissed off finding out I have to relearn something that was ultra trivial.
 
...necromancing this thread... :)

So... just throwing some more tomatoes at the wall... Seems like it would have been great to at least give /etc/motd.template a wee bit more power... like maybe the ability to have it evaluate variables available to the user at login %h %t %s %v (hostname, time, shell, vty)...

In the end, editing /etc/motd.template versus /etc/motd is really not that big a deal..
 
How to make motd on FreeBSD-13 look just like FreeBSD-12...

First, in /etc/rc.conf add these lines:
Code:
#
# MOTD
#
motd_enable="YES"
update_motd="YES"

Then in your shell as root...

Code:
mv /etc/motd.template /etc/motd.template.orig
touch /etc/motd.template

reboot or whatever and login, you should then get a login notification that looks something like this:
Code:
Last login: Tue Nov 29 22:18:09 2022 from somehostname.whatever.com
FreeBSD 13.1-RELEASE-p3 GENERIC
user@server ~]#

Mileage may vary. Not responsible for anything that doesn't work.
 
I have solved like this:



rc.conf:
update_motd="NO"

login.conf:
:welcome=/etc/motd:\

user profile: -> .profile :
cat /etc/motd


am not satisfied with such changes
pointless
 
just deploying new server 13.2 , what's with all this motd spam all over the place ? also when running services in jails
no need to fix what is not broken
 
In all honesty, it doesn't bother me, at all. Well, as long as it doesn't affect system stability, functionality. Some may call it evolution.
But hey, we are not the same.
 
Interesting. If one boots directly into a graphical environment, one never sees MOTD. If you ssh into that box, log in on a different virtual console, sure you'll see one.
Me, I do startx so initially log in on a virtual console, but in all honesty, I've never really paid attention to it since 3.x. Now when some of the fortunes were removed, that annoyed me.

Oh, Linux also does MOTD on a ssh/console login.
 
Back
Top