systemD is coming to a port near you!

InitWare is forging the same path as all other systemd compatibility layer / shim projects - endorsing systemd and kneeling in front of Poettering and paying homage to his abomination...

Poettering's quoted mailing list posting is rather typical, he has made many such postings over the years regarding manipulating users and devs into adoption.

You see this "culture" right through Red Hat, certain Linux kernel devs, gnome project, Debian and Ubuntu people, Arch Linux, etc where there is this supreme arrogance and widening gulf between developers (many of whom are on the IBM/Red Hat payroll) and Linux users who are viewed in much the same way as a Microsoft Windows customer.
 
jbodenmann said:
From the repo's readme.md:

To me it's rather interesting that they chose Rust for this.
Don't get me wrong, I don't want to bash Rust at all. I'm just surprised and intrigued. When thinking of writing "OS level" software specifically and only targeting FreeBSD, Rust is not the language that comes to mind - but I can certainly see the advantages of this decision too! :D

Now then... back to watching the "time elapsed" counter on my poudriere instance building lang/rust... :D
Click to expand...
Yes, strange indeed. Yet another build system and another language to include in base if this ever made it that far; which it won't of course.

But I'm not dissing rust either, as per Benno Rice's talk video where he references: blog.aurynn.com/2015/12/16-contempt-culture
 
ralphbsz said:
Actually, he sadly is NOT working on SystemD. After he left the "FreeBSD universe" (Isilon, iXSystems, also core team), he spent a few years working on Cloud-related stuff for a security company. Then the pandemic put the kibosh on that, and then he was looking for things to work on (ideally with a paycheck). Last I heard, he's found a job. It's interesting to hear his opinions on FreeBSD's init system progress, or lack thereof.
Click to expand...
It was sarcasm as he seems to be the FreeBSD poster child for wanting that crap.
I'm just glad he's no longer on FreeBSD (core or otherwise).
 
If systemd wasn't so monolithic in how to pulled in various parts and hard code directly call parts of the various services; it wouldn't be so bad on porting systemd. The part of being monolithic on single binary is completely off, in that there are several other packages that uses multiple executable files which isn't being blamed for being monolithic. Like towards the end of the video, if they provided a specific api that everything has to use; it would solve a lot of the issues. From what I've heard from all the various shims on systemd, is that it is a constant up hill battle; as systemd is acting hostile in that they will add breaking changes on new versions so you can't split parts off/make is shim for it.
 
The problem is, this is a Linux to userland issue. It always has been.

FreeBSD and indeed all BSDs solved this decades ago when they produced a kernel and a base and released them together. Linux, on the other hand, is a kernel which is pretty useless by itself. Enter all the various distros to make an O/S with their individual views on inits, services, userland libraries etc etc, and you can see the need for some single API or utilities.

Systemd is an attempt to unify, in a crude and somewhat evil way, the Linux to userland interface.
 
I'm really glad the definition what FreeBSD is isn't decided by some of the zealots in this thread. ?

It's a general-purpose OS, and yes, this includes the ability to work as a "desktop". A good CLI is a great thing, suitable for many tasks, but there are also many things you might want to do with a computer that require a GUI to make any sense. If FreeBSD couldn't be used as a desktop, I'd have to run something else (and, for example, fight with crap like systemd as a result…). Well, no, thanks.

Now, ports are just a "distribution" of (mostly) open-source software. You have to take what you get. If many GUI-related projects drift more and more into the hell of linuxisms, sure, that's a problem, and there are several possibilities to do something about it:
  • Nag upstream about portability
  • Do a lot of patching in the port
  • Start alternative projects with the software design you have in mind (well, I guess lumina is/was an attempt into that direction)
It really doesn't make sense to give up the field and more or less accept the fact that OSS GUI stuff is equivalent to "Linux".
 
Zirias I couldn't agree more.

I think the essence of the "Tradgedy of Systemd" talk by Benno Rice is summarizing this situation pretty well.
Systemd might not be the solution for FreeBSD (although I am not qualified to judge this) but we (as in the FreeBSD community) should certainly take it serious and properly analyze it in an objective manner. There are certainly things (i.e. concepts) in there which would greatly benefit FreeBSD too. Sure, the implementation might not be suitable for FreeBSD but that doesn't mean that we should just bash it and plainly ignore the benefits such a system layer would introduce.
 
cynwulf said:
he has made many such postings over the years regarding manipulating users and devs into adoption.
Click to expand...
Oh, you mean he has some admirable characteristics? Manipulation is an art form. I've got SystemD running on the Kali box beside this FreeBSD box. As long as it doesn't slip out when I'm not sitting here and invade my freeBSD box, I'm good with it.

Don't take ~/.xinitrc from me too...
 
Last edited by a moderator:
jbodenmann said:
Systemd might not be the solution for FreeBSD (although I am not qualified to judge this) but we (as in the FreeBSD community) should certainly take it serious and properly analyze it in an objective manner. There are certainly things (i.e. concepts) in there which would greatly benefit FreeBSD too. Sure, the implementation might not be suitable for FreeBSD but that doesn't mean that we should just bash it and plainly ignore the benefits such a system layer would introduce.
Click to expand...
Well…

It's never wrong to think about ways to improve your system and design, that's for sure ;)

But, regarding the init system? I'm not convinced… As already mentioned in this thread, the main "selling points" of systemd (at least with the scope "init system") are service supervision and startup performance.

About service supervision, first thing that comes to mind is: you can do that outside init. Sure, for a reliable production system, you want monitoring, you want to notify an admin when a daemon dies. Whether you want to automatically respawn it, it depends… I think more often than not, that's a bad idea. After all, there is normally a reason a service dies, and it can easily happen that automatically respawning it just creates more havoc. But anyways, I don't see any reason why init should do that. Just use a separate tool and let it start and manage exactly those services you want supervised.

As for startup performance: Sure, you can never have the best possible performance with shell scripts. But without them, you sacrifice a lot of flexibility, so, is it really worthwhile? You have to take into account that BSD's init with its mewburn-rc never was the mess sysv-init was. It supports dependency-based ordering and parallel startups, and it keeps init scripts very simple using a sophisticated framework. It's definitely ok to think about possibly better alternatives, but I don't see a pressing need.

And then, anything else systemd does, I guess most people agree it's out of scope of an init system anyways…
 
Just to give you a non-complete list of stuff which systemd does aside starting and supervising services:

* own NTP client
* own DNS resolver
* system logging in binary format
* cron
* automount
* inet
* unified configuration for many system aspects like time settings, hostname, network interfaces
* own console driver
* D-bus integration
* login tracking
* Docker support
* Device event managing daemon
* system-homed: encrypted, portable home folders within a container file

It's basically the Emacs of init systems. Poettering himself does view his brainchild not as init system, but instead basic building block for the operating system, where the distribution creator though can turn on or off quite much stuff.
 
Thank you for the overview. There are a few things in there I didn't know/expect to be handled by systemd.

I do suspect that it would take comparably minimal effort to have interfaces for stuff like "own NTP client" and "own DNS resolver" to use existing infrastructure? Same for "inet" (no idea why systemd would want to handle that but I guess somebody has a reason for that - easier desktop settings utilities maybe?).
I'd be curious to know the technical reasons for "own console driver". The underlying OS would already provide the necessary infrastructure in a usable manner by the time systemd gets invoked/started/becomes-relevant?

Again: Not taking any position here. Just trying to understand and keeping the discussion objective/constructive :)
 
The issue is when writing about "own client" it exactly means that - these clients are based on new code written for systemd. The official reason why was often that "normal stuff does not what we do need it to do at that point during boot time good/fast enough" mostly. Since these were new code bases they had some pretty juicy bugs in the beginning mature code bases don't have. And aside it really leads sometimes to annoying side effects. Quite often the implementation was also not complete or immature. For example systemd just might grab port 53 UDP, even if systemd-resolvd was not running "just in case."

The console driver is another area. The one in the Linux kernel - systemd does only care about Linux - is ancient, dated and has its own set of annoyances/problems to some. Some were of the opinion such a thing should be implemented mostly in user space anyway. So in 2014 systemd developers just started working on such a project, because they felt the need for a better console driver than what was being available in the Linux kernel.

Nowadays it's being called kmscon, and this is its description: kmscon is a system console for linux. It does not depend on any graphics-server on your system (like X.org), but instead provides a raw console layer that can be used independently. It can replace the linux kernel console entirely but was designed to work well side-by-side, too. Even though initially targeted at providing internationalization to the system-console, it has grown into a fully modularized console layer including features like multi-head support, internationalized font rendering, XKB-compatible keyboard handling, hardware-accelerated graphics access and more.

Here's the git commit in which it was introduced within systemd: https://cgit.freedesktop.org/systemd/systemd/commit/?id=b62a309a47dd11e11729616767421397b6ca7053

It first was introduced into systemd, then ripped out and renamed, and since then it's been rotting away.
 
hardworkingnewbie said:
Just to give you a non-complete list of stuff which systemd does aside starting and supervising services:

* own NTP client
* own DNS resolver
* system logging in binary format
* cron
* automount
* inet
* unified configuration for many system aspects like time settings, hostname, network interfaces
* own console driver
* D-bus integration
* login tracking
* Docker support
* Device event managing daemon
* system-homed: encrypted, portable home folders within a container file

It's basically the Emacs of init systems. Poettering himself does view his brainchild not as init system, but instead basic building block for the operating system, where the distribution creator though can turn on or off quite much stuff.
Click to expand...

Holy…
 
hardworkingnewbie said:
Just to give you a non-complete list of stuff which systemd does aside starting and supervising services:
* own NTP client
...
Click to expand...
The list itself is the problem.
Why is "test" aka "/bin/[" external? To keep shell generic, and the rest of the system flexible. Do you need some new avant-garde "test"? Write a new one.
That's how I understand the UNIX psyche.
 
mer said:
system logging in binary format has always been the killer for me.
System won't boot? Oh, do you know the magic command to actually see what failed? No? Sucks to be you.
Click to expand...
Can be worse, I had scenarios that the systemd logging system corrupts the filesystem with their changas, so the filesystem was able to heal itself (in my experience, btrfs, ext4 and xfs was able to heal without any problem) so of course you want to use the journalctl to see whats happening and guess what, you can't, because the entire log was corrupted in the process. So the only solution was to remove the entire journal chimichanga and reboot. Oh, and you'll also want to flush because eh.. they put some chimichangas in /run that should be flushed into /var/log, because reasons.
Said that, I had similar issues with freebsd and syslog-ng on linux, and situations like that just corrupt one single line in the log files, which is fine.
 
In case you want to know even more stuff Systemd can do, here's a handy list over at Suckless.

Also always interesting to read this blog post features on Freebsd.org on the press releases from 2017 by Synergy Sky, named: "Why we did build our solution on top of FreeBSD?" So in a year where Systemd has already been around for quite a while, and also in their Linux distribution of choice CentOS.

Money quote: "One major issue we experienced was that Systemd managed to crash the whole dbus-systemd connection if our software took too much memory, leaving the system in unstable state, with reboot as only option (I don’t think we can blame CentOS directly for that, however pulling in such premature technology into a proclaimed stable platform, makes no sense at all!!). We had some other minor issues as well which is probably weeded out in the latest versions of CentOS (and not worth mentioning)."

Theodore T'so, creator of ext2/3/4 file systems had also problems to tinker it in a way he wanted it to behave. It was a really interesting read back then, sadly lost with the begone Google+.

And Bruce Perens, who was within Debian, was of this opinion in 2014:
"Here's another issue brought to a head by systemd. There's a conflict for anyone with a job like being on the TC for an obvious reason: Systemd achieves some powerful and important goals for Linux systems. And at the same time Systemd doesn't play well with others (especially other init systems) and is badly in need of being broken up into separate projects.

Debian was able to allow individual developers to make decisions because it's modular. Systemd isn't modular enough to fit the Debian paradigm, at least at present. And the way it's been pushed upon the entire community is deplorable.

It's time to put on the brakes. We need to break systemd up into separate projects, resolve the issues that cause the largest objections to it, and make sure it plays with others (again, including other init systems). Oh, and pushing back on the team that pushed it upon us is unfortunately necessary.

Until those issues are handled, Debian (and other sensible distributions) should not be based upon systemd."

And it gives you fun stuff like this now and then, crashing a whole machine by sending a specially designed dbus message to it: https://seclists.org/oss-sec/2019/q1/140

And even Linus Torvalds dislikes the systemd developer's attitude, because systemd uses some kernel stuff in a way it was not meant to be, e.g. dmesg buffter. So people are filing bugs against the kernel, not systemsd. When then the kernel developers filed these bugs against systemd, they were pretty much and fast closed.

Interesing mail from 2017 on same patch: "
So I see many different approaches (that could be combined: I like
combining (a) and (c), for example), and absolutely none of them
involve the random "take some values from init".

And yes, a large part of this may be that I no longer feel like I can
trust "init" to do the sane thing. You all presumably know why."

Which basically is him saying that the he thinks that the most popular init thingie on his kernel sucks. And he's gruntled about when he's got to change his kernel do to the inability/unwillingness of the systemd developers to correct their mistakes.
 
jbodenmann said:
I know right? It feels like it's almost an entire OS. Wouldn't be surprised if it would come with its own dynamic memory management too!
Click to expand...
I really like how Benno drew a diagram of a modern OS.

In the old days of Unix, there was "kernel" and "user", and nothing else. Remember, Unix was not designed as a production operating system, but as a research tool: It allowed the Bell Labs OS research group (and later the Berkeley CSRG, where the acronym stands for Computer Systems Research Group). This is after many other OSes had more than two different kinds of code (the VAX famously has an extra ring for the shell). The job of the kernel was well defined, and includes virtualizing the hardware (provide isolation), resource management, and providing common services (like networking or file systems).

But in reality, there has always been another component, which Benno calls "system". For example, it decides which file systems gets mounted, how networks are set up and connected, and hardware attached and detached. It allows new connections to be established, for example CLI users logging in. These are all functions that have traditionally been done by init and its children (like inetd and getty). When the initial Unix versions were written (50 years ago), this area was mostly ignored and treated as an afterthought. In those early days, hardware configuration was done by editing kernel source and config files and recompiling ... I have added serial ports to machines in this way to allow more login from terminals. But this part of the overall problem has gotten much more complex than it was 50 years ago. Hardware comes and goes dynamically, configuration like networks and storage have to follow that fast movement, and the number of daemon processes that have to be managed has increased by orders of magnitude.

To me, this means that this whole area needs to be re-thought, architected, and implemented. In commercial systems, this has long happened. SystemD is one such project for the open source / free world. We can complain about some details of it. The biggest single problem with SystemD is that Lennart is an a**h*** (you can figure out what the stars in that word mean). Note that I didn't say that he doesn't understand systems research and architecture, or is a bad software engineer.

At this point, FreeBSD is already dead: it's market share has reached the point of being irrelevant, a lot of necessary development work is falling behind further and further. It has become a good base to create embedded systems (Netflix, Juniper, NetApp, Isilon), and as an alternative for hobbyists. I'm seeing more and more of that hobbyist use being driven by near-religious beliefs and paranoia, not by rational engineering tradeoffs. In the discussions here and other places, I see the biggest driver of FreeBSD adoption being irrational things like "I hate Linux" or "I hate Lennart" or "I'm old and don't like change". Obviously, people don't say these things out loud, but hide them behind lofty statements like "Unix philosophy".

If FreeBSD fails to re-build its init system simply because of "being allergic to innovation" or lack of manpower, it will become even more irrelevant. Which is sad, but it may be inevitable.
 
I fully get your point (and I hope most others of this community do too!).

As far as I can tell, the largest part of (Free)BSD people opposing systemd are not opposing the idea of a system layer or rejecting the overall concept behind systemd (these would probably be the "Unix philosophy"-huggers that you mentioned). I think the opposition arises from some (note: not all!) design decision present in systemd.
I won't even bother talking about things such as personal attitude of a project maintainer or anything like that. I am not involved enough to judge any of this and frankly I also don't want to be.

Personally I would like to see more efforts to design/suggest/provide/implement solutions to some of the problems rather than just bitching about it and missing out on a lot of good capabilities. As Benno put it: We don't have to use systemd if we don't want to - but we need something similar/equivalent pretty soon.

Of course, I can be very wrong with all of this.
 
ralphbsz said:
..and as an alternative for hobbyists.
Click to expand...
You say that like it's a bad thing.
ralphbsz said:
I'm seeing more and more of that hobbyist use being driven by near-religious beliefs and paranoia, not by rational engineering tradeoffs.
Click to expand...
Ad hominen much?
ralphbsz said:
In the discussions here and other places, I see the biggest driver of FreeBSD adoption being irrational things like "I hate Linux" or "I hate Lennart" or "I'm old and don't like change". Obviously, people don't say these things out loud, but hide them behind lofty statements like "Unix philosophy".
Click to expand...
You manage to pack 3-4 fallacies in those two short sentences. See items 3, 5, 11, and maybe 9 here:
sysdfree.wordpress.com

Systemd: The Biggest Fallacies by Jude C. Nelson

We are reproducing here a very good article we found on without-systemd.org which is on the dreaded blogspot. It took allowing three different sites to flash scripts so the simple text html docume…
sysdfree.wordpress.com sysdfree.wordpress.com
ralphbsz said:
If FreeBSD fails to re-build its init system simply because of "being allergic to innovation" or lack of manpower, it will become even more irrelevant. Which is sad, but it may be inevitable.
Click to expand...
And I say embrace the long tail! The Internet has made it possible to be small and yet remain relevant. This is a Good Thing.
 
What a great news! I remember when I first tried FreeBSD, there was no systemd, and it was so surprising. However, now I'm familiar with rc. Maybe I will try it if it comes out.
 
So FreeBSD is a real life example of Monty Python "I'm not quite dead yet! I'm feeling better! I think I'd like to go for a walk!"

Relevant. What is relevant? What is not?
Does financial/commercial support connotate relevancy?
Does User Base?
Does "most blingiest window manager ever"?

Based on those 3 Windows is the only thing relevant today.

Systemd: the "emacs of init systems" is the best analogy I've seen. But sometimes emacs is what you want.
My main issue with Systemd is "It's like Sendmail". One big huge monolithic bit of software that is doing a bazillion things.
From a pure security aspect, < insert your favorite puking emoji here > because it's too big to properly vet.
Why does it need to be NTP client? "Because NTP doesn't start fast enough" Really? Then you have your ordering wrong or you are not properly waiting for NTP ready state. It's the old "thundering herd" vs "orderly bring up". Thundering herd can work but everything needs to properly wait for it's dependencies. It usually winds up "hurry up and wait". Orderly can be slower but more repeatable and testable.

Security should be one of the primary concerns for anyone writing software today. If you can't draw the boxes and arrows and explain the interrelationships on one sheet of A4 paper, you need to decompose further.

My opinions, agree, disagree, all the same to me.
 
You must log in or register to reply here.
Back
Top