The tragedy of systemd, an interesting perspective

It is long. Good talk though. I agree with this guy for completely. SystemD is a big project but its not monolithic or unUnix/Linux as some people yell about.

I think long term SystemD has a lot of room for refinement, but overall its a pretty reasonable solution.
 
Personally, I love systemd over the old SysV init method. I think the days of individual init scripts for every service being a viable option are over. As he discussed, back in the old days a Unix system didn't have a lot going on, but nowadays a normal desktop system can have hundreds of processes. Doesn't seem smart to run a system with that much going on without a service manager. Sure, systemd might be grabbing things up that it doesn't need to, and we can have a discussion about that, but overall I think it's great, and something that Linux definitely needed.
 
Great talk. I"m a fan of SystemD but as others have said it needs refinement. I really liked his answer to the question about how the SystemD devs and Linux community but heads and don't bother listening to each other. "A lot more sympathy on both sides." Perfect answer.
 
Vermillion said:
Great talk. I"m a fan of SystemD but as others have said it needs refinement. I really liked his answer to the question about how the SystemD devs and Linux community but heads and don't bother listening to each other. "A lot more sympathy on both sides." Perfect answer.
Click to expand...
Agreed. Also, what software doesn't need refinement? I think he said it best when he brought up how people say systemd is buggy. "It's software." Perfect answer there as well.
 
There's actually a lot of great little presentations on that youtube site from that Linux convention. The guy that talked about systemd also gave one about package managers which was good. The kernel one is good as is the increase boot time vid.
 
Lunar said:
Personally, I love systemd over the old SysV init method. I think the days of individual init scripts for every service being a viable option are over. As he discussed, back in the old days a Unix system didn't have a lot going on, but nowadays a normal desktop system can have hundreds of processes. Doesn't seem smart to run a system with that much going on without a service manager. Sure, systemd might be grabbing things up that it doesn't need to, and we can have a discussion about that, but overall I think it's great, and something that Linux definitely needed.
Click to expand...

Disclaimer: I have not watched the Video yet, I will have to watch it when I get home. This is just from my experience with SystemD, especially when writing system software and developing specialized systems under SystemD now compared to previous..

The new system is easier generally for the user, but it isn't exactly more efficient in that regard. Especially when you need to set a certain order of things to start up, you still need to give it priorities. And you are still building your "scripts" into the code for the program now. In reality SystemD is really just packaging up a lot of stuff as part of the OS management now instead of having it separate. in some ways you have to do slightly more than you did before. But overall, I would still say I much prefer SystemD. My only real complaints are having to deal with other choices made in packaging with it, like using ip instead of ifconfig and firewalld instead of iptables. I learned to dislike firewalld with a passion for the work I had to do (which deal with very specific directional ip rules). For the average user, firewalld is probaby a bit easier though. Also had some changes to udev which was a little annoying. We did quite a bit of stuff with udev and having to switch all of that to udevd was a real pita.
 
I've always liked systemd. That may be in part due to also being a long-time MacOS user and appreciating launchd on that platform. Also, init scripts generally suck, and having a single way of handling services is an overall positive (and writing init scripts, especially if you have to cover multiple distros, just sucks).

However, like many, I've always been a little concerned with how systemd seemed to be encroaching into seemingly unrelated things (e.g., networking). But at least I have a bit better understanding as to why after watching the talk.
 
BlueLineSwinger said:
However, like many, I've always been a little concerned with how systemd seemed to be encroaching into seemingly unrelated things (e.g., networking). But at least I have a bit better understanding as to why after watching the talk.
Click to expand...
I've heard they're even going to incorporate a Word Processor in a future release!!!

I kid of course.
 
Its easy to understand why the systemd folks have included other systems into their package. For things like networking to work properly they either have to be part of the project or follow a very exact standard to they can interact properly. We all know how that would likely go.... multiple bigs like Ubuntu and Red Hat squabelling over specifics and SystemD having to tend multiple code paths.

So in a way SystemD militantly taking over all services is for the greater good. lol :)
 
ChadD said:
Its easy to understand why the systemd folks have included other systems into their package. For things like networking to work properly they either have to be part of the project or follow a very exact standard to they can interact properly. We all know how that would likely go.... multiple bigs like Ubuntu and Red Hat squabelling over specifics and SystemD having to tend multiple code paths.

So in a way SystemD militantly taking over all services is for the greater good. lol :)
Click to expand...
Not to mention, that as the guy in the video states, systemd is effectively establishing an official system layer within a Linux system. I would argue that services like networking, device detection and configuration, etc are all part of a "system" layer. I wouldn't call myself a systemd expert, but in what I know of it so far, nothing that has been integrated into it at this point fails to make sense to me.
 
Lunar said:
Not to mention, that as the guy in the video states, systemd is effectively establishing an official system layer within a Linux system. I would argue that services like networking, device detection and configuration, etc are all part of a "system" layer. I wouldn't call myself a systemd expert, but in what I know of it so far, nothing that has been integrated into it at this point fails to make sense to me.
Click to expand...

I think it is all trade offs, the more you include in this "system layer" the more bloat you get. For instance, not all systems need network interfaces or the rest of the services that come with that. That is rare, but it is still a thing. The more you start incorporating into the all encompassing systemd, the more difficult it becomes to build a system or even perhaps compile a kernel without it. Also it starts removing some choice as well. One of the great things about Linux is being able to pick and choose what you want to use. The more things you make a core component, the less choice you have. For instance, as I mentioned before, now that udev is part of systemd, there were some things that changed, some stuff was lost, some stuff was better, but certainly a lot of development we had done prior was thrown down the drain. On the positive note, they have seemed to be fairly attentive to issues and resolving them.

EDIT: Another small note, part of my potential issue with the way things are going with systemd, is that once it gets large enough, making an update to one portion of it, might start to require you to reload all of it, potentially forcing you to reboot your system.
 
NoOther said:
I think it is all trade offs, the more you include in this "system layer" the more bloat you get. For instance, not all systems need network interfaces or the rest of the services that come with that. That is rare, but it is still a thing. The more you start incorporating into the all encompassing systemd, the more difficult it becomes to build a system or even perhaps compile a kernel without it. Also it starts removing some choice as well. One of the great things about Linux is being able to pick and choose what you want to use. The more things you make a core component, the less choice you have. For instance, as I mentioned before, now that udev is part of systemd, there were some things that changed, some stuff was lost, some stuff was better, but certainly a lot of development we had done prior was thrown down the drain. On the positive note, they have seemed to be fairly attentive to issues and resolving them.

EDIT: Another small note, part of my potential issue with the way things are going with systemd, is that once it gets large enough, making an update to one portion of it, might start to require you to reload all of it, potentially forcing you to reboot your system.
Click to expand...
While I understand your concerns, one thing to keep in mind is that systemd isn't this monolithic beast. Take networking for example. Sure, it has networkd that handles network connections, it's still just a daemon within systemd. It isn't required for systemd to operate. Plus, networking is still actually implemented at the kernel level, systemd is just the user facing side of the whole networking equation. But, I think that the concern that one systemd daemon going down will cause the whole thing to potentially crumble is a little hyperbolic due to how systemd is designed. Systemd, like the GNU utilities is really more of a collection of tools into one meta package that manages system level services. At least, that's how I think of it. I also like that it adds some much needed standardization to Linux. Now, if say a distro thinks they can develop a better networkmanager, they have a common target (networkd) that then means that they're work is inherently highly portable amongst distros running systemd. At least, that's how I understand it. Correct me if I'm wrong.

Now, none of this is to say that the issues you experienced with switching to systemd are invalid or unimportant. They absolutely are, and I'm glad to hear that the systemd folks seem to be receptive of feedback. However, I would argue that the benefits systemd brings to the table far outweigh any growing pains that have been experienced, especially at this point.

Now Canonical and Netplan, that's a different story. What the hell?
 
Lunar said:
While I understand your concerns, one thing to keep in mind is that systemd isn't this monolithic beast.
Click to expand...

I have only stated fears that myself and many other long time Linux users/devs have. Systemd is a monolithic beast compared to Linux's history by its very nature being a centralized control system. Most of the things in systemd are tied together at the core of systemd. It is one of the ways it collects and provides information on services. The fear that some have is as Systemd grows it will start becoming more static than its current form. Do I think it will become like Windows in that regard? No. But it does share a similar path as Windows did, using similar reasoning. Linux/Unix was built upon the ideal of modularity, systemd is on the opposite path of that tying numerous systems together.

So, while as I have mentioned before, there are many things that I like about systemd, I also fear where it could lead down the road. My opinions are probably fairly similar to Linus Torvald in this regard. There are no serious issues now, but it depends on the path forward and the developers for it have not always been appropriately circumspect about what they are doing.
 
Systemd violates the unix philosophy of simple pieces of software doing one thing & doing it right. It replaced tons of legacy mature/stable systems with a huge cluster**

With that being said, I'll roll with it but expect to see tons of problems that have already been "solved"
 
/dev/null said:
Systemd violates the unix philosophy of simple pieces of software doing one thing & doing it right. It replaced tons of legacy mature/stable systems with a huge cluster**

With that being said, I'll roll with it but expect to see tons of problems that have already been "solved"
Click to expand...


The video touches on this. Systemd solves a lot of stuff that hadn't been properly tackled before. There was Upstart (a good start, but limited) and launchd (open-source IIRC, but too locked-in to macOS).

Fact of the matter is, Linux has outgrown almost all of the utilities that have been replaced by systemd. A simple init that jump-starts a bunch of chained scripts that run serially is no longer sustainable. An init that isn't aware of the network state (and vice-versa) is no longer adequate. A logging system that is simply a text dump of each app using its own format is more difficult to work with.

Systemd's utilities are basic, single-function apps that perform their intended job and nothing more. Only now, they're all coming from a single modern project and designed to work together, instead of a disparate set of developers with their own needs and goals scattered across multiple projects and platforms. Many of those were outdated and/or were created to solve the problems of 20+ years ago that may no longer be relevant.
 
I keep writing a reply and then deleting it but here goes...

The concept of systemd is a valid one... an additional supervisor to deal with system Daemons. However, its deployment, its architecture and more specifically its management is atrocious.
Pottering really needs to sort his act out. Linus can act like an arrogant git because he is right, Pottering gets it wrong yet still tries to pull the same condescending tone.

I follow what is going on in systemd closely to make sure I am informed. Go have a look at how bugs are handled. Yes all software has bugs but DAMN! the community interaction is embarrassing... Winning the Pwnie award speaks volumes.

It is a constant "Not Invented Here" approach, either out of arrogance or a lack of understanding OR poor architecture. Linux/UNIX works well as each application does its job and only its job. SystemD keeps absorbing functionality rather than exposing a common api.

Potterings threat to the gentoo community really was a line crossed for me. Threats about udev (resulting in Gentoo creating eudev to protect itself) is out of order.

The video and Potterings stance on how init "use to be" handled is wrong. They blame sysvinit as being buggy and slow YET the issue is actually sysvrc, maintained by RedHat and really REALLY dodgy bash. SysVinit does its job really well... the 1st process to started by the kernel to then spawn some main runtime AND then to collect zombie processes. PID1 is therefore nice and simple.
Look at OpenRC, look at the size of openrc-init, again nice and simple as PID1 has todo two simple tasks. By all means make PID2 overly complicated, but PID1?

Finally before I post more of a rant so others then dismiss what I wrote as a rant (as oppose to concern...)
The funny thing is, systemd's design would anger probably at least 95% of GNU/Linux users (probably including you too) IF it was anything but the init system.

I know some of you think the "Unix Way" is just a meme, but it's actually the reason you can do shit like pipe terminal commands into each other. It's THE reason you have components you can wrap your brain around which can all be pieced together and managed in a simple and flexible way. That's what the Unix Way does.

You want another great example of the Unix Way? Ironically systemd is a GREAT example of the Unix Way. Not in its design though, but in its mere existence.

Have you ever realized how absolutely amazing it is that a new piece of software as fundamental as PID 1 could be swapped out in all of our major distros (even "stable" ones) in only a few years time?

The significance of that cannot be overstated. And yet, although systemd owes its success to the Unix Way which made it so easy for them to step in, it undermines the Unix Way in its own design.

Do you think 20yrs from now when systemd is old and busted that it will be so easy to swap it out with something better? Well not only is the scope of this thing which needs to be replaced now massive compared to what it used to be, but you'd also probably have to rewrite a lot of other software, or beg the developers to change their dependencies. It doesn't matter if systemd works. You didn't start using GNU/Linux because it "works" did you? You started using it because it allowed you to be the master of how your data flows, and it allowed you to combine things in ways nobody else on GNU/Linux was doing to get exactly what you want.

Quit being led astray by the "just works" argument when it comes to systemd just because init systems aren't something you care to play around with and customize all that much. That shouldn't matter, and we should stick to the tried and true design principles that have served us so well all these years.
Click to expand...
 
BlueLineSwinger said:
The video touches on this. Systemd solves a lot of stuff that hadn't been properly tackled before. There was Upstart (a good start, but limited) and launchd (open-source IIRC, but too locked-in to macOS).

Fact of the matter is, Linux has outgrown almost all of the utilities that have been replaced by systemd. A simple init that jump-starts a bunch of chained scripts that run serially is no longer sustainable. An init that isn't aware of the network state (and vice-versa) is no longer adequate. A logging system that is simply a text dump of each app using its own format is more difficult to work with.

Systemd's utilities are basic, single-function apps that perform their intended job and nothing more. Only now, they're all coming from a single modern project and designed to work together, instead of a disparate set of developers with their own needs and goals scattered across multiple projects and platforms. Many of those were outdated and/or were created to solve the problems of 20+ years ago that may no longer be relevant.
Click to expand...
I have NEVER heard any Linux/Unix/BSD admin complain about text logging. Until now. First for everything I suppose.
 
/dev/null said:
I have NEVER heard any Linux/Unix/BSD admin complain about text logging. Until now. First for everything I suppose.
Click to expand...


It's really one of those things, I believe, that you don't realize could be much better until you see an actual improved implementation. Regular text logs are OK, but you often have to grep around different files and archives to find what you're looking for. Being able to run 'sudo systemctl status <service>' and get the exact log messages that show why a service failed is great.

Examples of what journalctl can do.
And more.
 
BlueLineSwinger said:
It's really one of those things, I believe, that you don't realize could be much better until you see an actual improved implementation. Regular text logs are OK, but you often have to grep around different files and archives to find what you're looking for. Being able to run 'sudo systemctl status <service>' and get the exact log messages that show why a service failed is great.

Examples of what journalctl can do.
And more.
Click to expand...

When you manage tons of servers (as I do at work) you log to a centralized syslog server anyhow.

Maybe it's just me, but I've never had the issue you are speaking of and I really enjoy my text parsing tools. They give me the power & flexibility I need to do what I want. AFAIK stuff like fail2ban uses text logs as well. I also much prefer to see what else what was happening on the system at the time a problem occured (in common log files) so you can get an overall picture of what was going on when an issue happens.
 
You must log in or register to reply here.
Back
Top