systemd 250 Released With A Huge Number Of New Features, Improvements

[gotar]

Personally, I don't hate every single thing systemd did. I just hate the way it's swallowing more and more userspace facilities. The devs literally seem to know of no boundaries or have a willingness to solve some particular problem as a completely separate, standalone project.

Why didn't you nor anyone else solve these problems up to date?
What specific userspace project was overwhelmed by systemd?
ConsoleKit? PolicyKit? hotplug? devfs? TCP wrappers? utempter? *inetd?

I use Linux since 1998 (RH 5.0) and I can't remember actually removing any tools, except some dead ends that were rotting a long before systemd gained today's attention.

And basically all you're doing is to prove that it indeed took the oxygen away from most other efforts, in this area.

Are you talking about all the abandonware? I recall the mess when replacing shadow, pwdutils, shadow-ng (useradd vs adduser), util-linux-ng, egcs, eglibc, devfs... I remember writing monit files, problems with *initrd generators mapping block devices. I remember setting up my first containers with LXC. Oh, and the infamous 2.2 kernel line... Approaching upstart that was barely solving any problems. How about gawk vs mawk? pdksh vs mksh? mingetty or agetty? X11 vs Wayland? SVGATextMode vs KMS? grub2? vixie-cron vs chrony vs anacron vs fcron... grub2? syslog vs syslog-ng vs rsyslog vs syslog-ng2? grub2? acpid? pm-utils? watchdog? grub2?
Those were real manpower suckers!

Comparing it to systemd there is only ONE disturbing change enforced globally: journal. All the rest is simple and welcomed standarization.
And in fact I didn't trust udev as well, before it proved being The Right solution I was keeping static /dev even with systemd!

But still I can't find any (other that journal) change in my workflow, that I was forced to (using dozens of servers and workstations). I got my crond, syslog-ng2, ntpd, lilo, syslinux, static network configuration (with ~80 interfaces) working as before. But now I can start my MD over LUKS over LVM+iSCSI over dm-integrity just like that. I can restrict sshd logins to confined namespaces without CAP_SYS_ADMIN nor CAP_SYS_PTRACE with read-only mounts and other security (illusions, but still) knobs. I got working supervision and resource control. I got convenient chroots (via nspawn), various accoutings, per-service BPF filters, reliable killing and cleaning up of user sessions. At last my servers start up without waiting for all the filesystems to be online thanks to proper ordering - no more fun with all day long phone calls after some emergency shutdown and 10 hours of fscking some godforsaken partition! All of this for free - no big changes in existing workflow. Well, no, not for free - I got to learn how to use the new features, but I got them now easily, while in SysV-world this was illusory.

So please elaborate or give a few examples, of "separate, standalone projects" that were suffocated by systemd and the negative impact on end-users, ignoring journal (as I find valid some troubles with it), embedded space-constrained environments (these are rolling own inits anyway) and abstracts like "bigger attack surface" (because it's inconceivably smaller if various daemons are taken into account, e.g. yesterday I've reduced hddtempd powers significantly). Pure user perspective please. Because my 20 year experience with servers tell me that systemd solves problem that were next to impossible to address without it (in a finite time).

OTOH there are coreutils - "completely separate, standalone GNU/project". Which in last 10 or so years gained some colors for dmesg and still rejects progress bar for cp...

[oiaohm]

linux kernel only does kernel-level stuff, we are talking about user-level software. kernel doesn't care what userlevel does(and btw that's why kernel doesn't provide containers: so that there could be more than one kind). most decisions involve tradeoffs, just like there are more than one editor or shell, there could be more than one program to launch container.

Dracut and iwd and others are at kernel.org is because the Linux kernel development is not past going into userspace. when there is strict relationship between kernel and the area.

The idea that systemd would eat the Linux kernel is kind of backwards the Linux kernel kernel.org at some point could eat systemd. There has been lot of historic consideration to taking in complete Init system with kernel.org over the decades. Mostly has not gone ahead due to lack of agreement of course this could change in future.

The Linux kernel level not providing containers is that containers is area of great dispute. The reality is its not quite how you write it up. Due to there not being a solid agreement by those implementing containers on the user-space tools they are not part of kernel.org yet. Please note the word yet. Future that can change.

The Linux kernel project is not just restricted to the kernel and is allowed userspace sub projects in the areas with fairly solid agreements.

Not caring about the tools at userlevel is not true of the Linux kernel project. They do care what is used at the userlevel and if their was a solid agreement that everyone would use X shell then we could expect it be hosted at kernel.org. Some areas are just too fragmented at this stage for a solid agreement.

The reality how the Linux kernel works project does things mean if those who want alternative init options don't start finding the their resolve to invest development time one day they could wake up and systemd is at kernel.org being developed in alignment with the Linux kernel making their life even more impossible. Yes is not going to be systemd take in the Linux kernel it would be the reverse linux kenrel project take in systemd most likely in future due to lack of developers working on systemd.

Please do note the Linux kernel project did attempt to force a resolve of container userspace by making only 1 application on a system be able to control cgroups yes that is a historic failed plan.

[gotar]

Look what I've found! Coder, are you the blindcoder maybe?

udev is NO replacement for devfs! It's just a bunch of crap. Why? Read this: https://www.benjamin-schieder.de/blo.../09/23/15.html [URL adjusted] and you'll understand why I hate udev as it is now. It's just far too userunfriendly.

Oh, about the abandonware in the very core of Linux - remember the module-init-tools? Yep, just another crucial part of ecosystem left unmaintained to be replaced by kmod. It appears that "separate projects (and maintainers) for different tasks" model has already been tested and failed.

[oiaohm]

Look what I've found! Coder, are you the blindcoder maybe?

Oh, about the abandonware in the very core of Linux - remember the module-init-tools? Yep, just another crucial part of ecosystem left unmaintained to be replaced by kmod. It appears that "separate projects (and maintainers) for different tasks" model has already been tested and failed.

https://lwn.net/Articles/331818/

devfs is a interesting bit of history. Yes it was removed then a replacement was made that called devtmpfs in 2009 yes modern day udev distributions use devtmpfs.

https://www.linuxquestions.org/quest...3/#post1874359

udev is NO replacement for devfs! It's just a bunch of crap.
Why? Read this: https://www.benjamin-schieder.de/blo.../09/23/15.html
and you'll understand why I hate udev as it is now. It's just far too userunfriendly.

Yes this post is right. Also did not stop devfs in the kernel space being a trouble causing unmaintained issue with growing complexity that lead to its removal in 2005. The new one devtmpfs in 2009 being tmpfs based means LSM(Linux security module) meta data has somewhere to go and the maintenance is reduced.

https://lwn.net/Articles/139595/

Yes 2005 when devfs was removed most distributions were refusing to use devfs due to the problems. Yes devfs had a 5 year run from 2000-2005 and devtmpfs has had from 2009 to current. Yes devtmpfs is used by the majority of Linux distributions out there.

I don't think this coder is blindcoder. Yes prior to systemd there are many people who have complained about different changes in the way people attempt to complain about systemd.

There is example after example key projects being left without maintainers. Devfs from 2005 is example of excessive maintenance cost resulting in path being completely dropped for 4 years.

coder the biggest problem here is how to have a modular init system without having excessive maintenance cost and not having the bus factor problem raise its head. Yes systemd documentation problems come down to lack of people todo that so there is already maintenance problem. Yes the poor documentation of libsystemd functionality..

Please note your highly skilled C coders are not your highly skilled documentation writers. Its rare to get a person who good at writing functional code and documentation people normally better at one or the other. Horrible the term use the code as documentation comes from the people really good at writing functional code yet happen to be really bad at reading and writing documentation as well those people happen to be poor at commenting their code as well.

Human diversity is one of the cursed factors here that result in projects like having massive number of documentation writers or massive number of coders with bugger all of the other resulting in bad time for end users and this happens over and over again as well. There is a repeating set of failures.

[gotar]

Yes systemd documentation problems come down to lack of people todo that so there is already maintenance problem. Yes the poor documentation of libsystemd functionality..

Fortunately the issue tracker at github provides many answers. It is so superior to e.g. bash abomination, that the real problem would appear if this service closed someday without releasing the data...

[coder]

1990s early you had 3 times the count of developers work in the areas systemd covers. 2000s early is double. 2010 it was down to about 1.5 of now. Yes the loss in systemd time frame is basically the same as the decade before.

The reality is we have not been getting newer developers as fast as losing older developers in this area..

First, I'm curious to know where you're getting these stats.

Second, the existence of a decline before systemd doesn't disprove that systemd further used up the oxygen in this space.

Its like the Linux kernel documentation problem where there was nobody being paid todo it.

The kernel maintainers could address some of that, through policies requiring that more extensive doc updates accompany patches. That would probably also result in better quality patches.

[coder]

I would if that would change your opinion, but you're obviously here just to troll.

I'm here to represent a point of view. If I get attacked for it, I'm not about to back down. I don't see that fitting an accepted definition of trolling, but you may call it what you will.

Don't project your own limitations on others.

Likewise. My involvement with Linux isn't primarily as an admin. Therefore, I don't gain much value from learning more about Linux admin than I happen to need at my job and for maintaining my own personal systems. Maybe creating Linux distros plays into your career objectives or is something you consider a hobby, but this isn't true for many. To pretend otherwise is disingenuous.

Of course I use off-the-shelf components written by others, so does every other distribution on the planet. You can do the same and put whatever off-the-shelf init system in yours.

Ah, but that's the point, isn't it? If a competitive alternative to systemd doesn't exist, then rolling my own distro is really a false alternative. A far better use of my time would be spent contributing patches towards improving an existing one, or writing a new one. There again, I'm reminded that I already have too many projects on my plate and while I think it's important to have good userspace services that systemd covers, it's not particularly relevant to my skills or interests. Therefore, even working on an alternate set of services wouldn't be worth the opportunity cost to me.

I'm perfectly happy with systemd:

That's great, but irrelevant.

It's definitely an answer to YOUR complaints, because you have failed to provide any legit complaints.

Sure I did. Only a child cannot distinguish between its own interests and those of others. As such, you're being childish.

You're simply a time waster,

If you find this exchange a waste of time, you have only yourself to blame. Nobody forced you to engage. However, like jacob, I think you're a self-appointed systemd defender, looking to bully anyone who dares to claim it's anything less than ideal.

Unfortunately for you, you cannot cancel me. You don't control my opinions or posts. All you can control is your own.

nothing will change your opinion obviously.

Opinions about software design, based on decades of personal experience are indeed hard to change. Depending on the opinion, that might actually be a good thing.

The time you and other trolls spent flame baiting systemd threads you could EASILY whip together a distribution without systemd and infrastructure to maintain it. The problem is that you'd rather sit on your ass and complain and try to tell everyone else how to run their project.

As I explained, this is a false choice, not least because I'm forced to use systemd at my job and it's too inefficient for me to waste time trying to use anything different at home. Even if it weren't, my opinion and giving voice to it are my right. It's your right to counter, but also to ignore it.

only those that can't accept reality a decade after the fact.

This is more pseudo-majoritarian thinking that systemd's dominance makes it ideal. There have been many examples of dominance, throughout history, by sub-optimal solutions.

Systemd isn't going away unless

I didn't say it should. I criticized its endless scope-creep. There are two things I wish: that the systemd maintainers will eventually reach a point where they start building separate and independent services to solve additional problems, and maybe that they'll one day refactor systemd into a set of independent services. Of those, I think only the former is particularly likely.

Please tell me "CODER", what have you achieved so far with all your bitching and moaning? How is that going for you?

Mine is but one voice. Nothing more and nothing less. My opinions are no more or less relevant than yours. That you don't pretend otherwise is all that I ask.

[coder]

everyone can have an opinion, but not everyone's opinion is worth listening to.

That goes without saying.

btw, you didn't pay for systemd

Oh didn't I? What if my employer used RHEL and if I've even bought packaged Redhat distros, in the past?

[oiaohm]

First, I'm curious to know where you're getting these stats.

Second, the existence of a decline before systemd doesn't disprove that systemd further used up the oxygen in this space.

The data mining the old repositories who comments and who was doing what. Redhat did this before the start of systemd as well.

There haw been a change in the make up of distributions.

https://upload.wikimedia.org/wikipedia/commons/b/b5/Linux_Distribution_Timeline_21_10_2021.svg

Do notice how we are not seeing as many new unique distributions starting and we are starting to more distributions disappear than new ones created. Yes last 4 years there has not been a single new unique designed Linux distribution released mainstream.

The idea that systemd used up the oxygen in the space is wrong. They change in distribution development means less people are working on the init system. More and more are copying other peoples work. This was happening before 2010.

Yes we have more so called distributions now but over all we have less unique distributions. More copy paste distributions for core parts. Yes you could call this something like plagiarism. Yes people take credit for making new distribution but they are not putting the resources into the core parts by this copy paste process.

This is why even that Linux world appears bigger now when you are looking at init system development its smaller. More resources are going into the window dressing parts than the core init the system parts.

I would some what say that systemd has taken the wind out of the sales of some distributions. But when you look closer lot of those were copy paste with their init systems.

Waking up with redhat moving to systemd then caused distributions to find themselves in a location where they had not been funding any init system development so they were then in trouble. Yes there is a need to organise and work out how to fund init system development if we want diversity.

The disruption systemd caused is more example of copy paste problem of distributions.

The kernel maintainers could address some of that, through policies requiring that more extensive doc updates accompany patches. That would probably also result in better quality patches.

The reality no they cannot. The hard reality here there are many areas if the Linux kernel maintainers mandated documentation in detail you would not have the developers with coding skill to maintain the code. There is the issue that some of these companies have requirement for all documentation written by their staff to go past legal review. Yes this does make even getting hardware specifications out of them up hill battle let alone asking for more documentation.

[coder]

Those were real manpower suckers!

I don't know enough of the specifics to comment about any of those, but there are plenty of examples where competition likely yielded better results on both sides. For instance, gcc vs. clang or mysql vs. postgressql.

10 hours of fscking some godforsaken partition!

That's more of a change in the filesystems, themselves. No?

while in SysV-world this was illusory.

I don't think anyone is arguing SYS-V Init was better, or that we want to go back to it. I remember using Monit as a bolt-on, back when we used it. I'm not sorry to see it go.

There were certain advantages from having SYS-V Init utilize shell scripts that now require more point-solutions for systemd to support the same range of capabilities. I tripped over one of these issues, not too long ago.

So please elaborate or give a few examples,

One specific example I saw was systemd leaking dbus connections. I think we found that during soak testing before a release, and had to upgrade to a newer release of systemd to get the fix, which was more risk than we wanted to take on. I wasn't directly involved in that one.

my 20 year experience with servers tell me that systemd solves problem that were next to impossible to address without it (in a finite time).

I never said it wasn't an improvement. However, we also shouldn't assume we'd still be using SYS-V Init, if it hadn't won out. Whether it was Upstart or something else that came along, whatever had entered that niche would've been the subject of a lot of the improvements that have since gone into systemd.