Systemd 198 Brings "Many Big Changes"

[Ericg]

The thing that systemd does is that it works around the problem. The problem still exists. The problem is that distro's don't conform to upstream configuration and systemd does nothing to fix that.

Yes and no. It necessitates a certain amount of conformity. Systemd says "If you use systemd, then THESE configurations are going HERE. Don't like it? Oh well."

It gives a set place / explicit command for handling:

~Hostname
~Locale
~VConsole
~Setting Timezone
~Hardware clock
~Kernel modules (Loading them, blacklisting them, modifying parameters)
~Basic ACPI (which you can use if you want, if you don't then just use gnome or kde with power management enabled-- they properly register themselves as the ACPI handlers and systemd respects their override)
~Location, syntax, and commands for service management / service files

Distros are gonna modify upstream for random, bullshit reasons. Should they? No. Thats why I run Arch, because I got tired of the modifications. Systemd forces them into conformity on certain things, things that have ZERO reason to be different across distros.

[duby229]

I guess I'm just gonna have to disagree and step out of this conversation. I'm surprised that so many people here are defending it. Systemd is nothing but bad for linux. It doesnt solve the problem it just adds significantly to it.

[Ericg]

One of the things I do is I maintain the network for a medical management company. We serve out a popular commercial web app to our customers that handle patient appointments and records. It even handles office management for them. Of course this is on a firewalled VPN and we don't get heavy traffic. None the less I know exactly what I'm doing. Our apache servers are on freebsd. Our thinclient servers are on linux which in turn acts as a gateway to a cluster of windows terminal servers that serve out a few legacy windows clients. the actual physical workstations boot up to a minimal linux that does nothing more than run the terminal client.

The workstations damn sure don't need systemd. Neither do the terminal servers, and it isnt capable of running on the apache servers. I didnt design the network I inherited it, and now I am in a position of maintaining it.

EDIT: you mentioned the bloat that has been going into the linux kernel as a justification for the bloat that systemd employs... I'm sorry but I can't agree with that either..... Bloat is bad no matter where it's being put.

You're right, to an extent here.

Your FreeBSD machines, cant use systemd so thats out of the question. Your workstations probably aren't starting enough services where parallelization of services would matter. You're not using a "normal" computer, you're using an extremely minimal computer. For those systems, systemd may not be worth the change. You're an edge case, basically.

Systemd is designed from the ground up to be both scaleable and mainstream, got a phone? Systemd itself is lightweight to handle those hardware constraints. Got a tablet? See phone. Got a desktop with tons of services? Hey! parallelization makes sure those things start up quick so you can actually get work done instead of waiting for boot. Got a server that needs constant uptime? Systemd can be setup to where if a service dies it will automatically restart the service whilst buffering input to that service--you dont lose any connections. If it dies again within a set-able amount of time you can tell it to flag the logs and not start the service again because at that point something is probably actually wrong, not just like random occurance of it hanging.

Bloat? Systemd and the kernel bloat in the same way-- modules. Don't need it? Don't compile it. Systemd has 3 mandatory things: systemctl, journald, and udev. And the last one is probably already on your system. Everything in systemd is VERY strictly structured to make sure nothing is forced onto the distros. If they want to keep using acpid for ACPI events, then they dont compile that portion of logind OR they tell logind "Hey dont worry about ACPI, we've got something else to handle it." Don't want to use the journal for syslog events? Thats fine. Tell the journal to restrict its log size to 1MB, install syslog, activate it , and the journal automatically pushes all logs it gets onto syslog.

Systemd forces conformity for the minor details that SHOULDNT be changing, but that distros seem to love to change for no reason, and enables and even encourages choice for the things that should be able to be swapped out and moved around.

[duby229]

You're right, to an extent here.

Your FreeBSD machines, cant use systemd so thats out of the question. Your workstations probably aren't starting enough services where parallelization of services would matter. You're not using a "normal" computer, you're using an extremely minimal computer. For those systems, systemd may not be worth the change. You're an edge case, basically.

Systemd is designed from the ground up to be both scaleable and mainstream, got a phone? Systemd itself is lightweight to handle those hardware constraints. Got a tablet? See phone. Got a desktop with tons of services? Hey! parallelization makes sure those things start up quick so you can actually get work done instead of waiting for boot. Got a server that needs constant uptime? Systemd can be setup to where if a service dies it will automatically restart the service whilst buffering input to that service--you dont lose any connections. If it dies again within a set-able amount of time you can tell it to flag the logs and not start the service again because at that point something is probably actually wrong, not just like random occurance of it hanging.

Bloat? Systemd and the kernel bloat in the same way-- modules. Don't need it? Don't compile it. Systemd has 3 mandatory things: systemctl, journald, and udev. And the last one is probably already on your system. Everything in systemd is VERY strictly structured to make sure nothing is forced onto the distros. If they want to keep using acpid for ACPI events, then they dont compile that portion of logind OR they tell logind "Hey dont worry about ACPI, we've got something else to handle it." Don't want to use the journal for syslog events? Thats fine. Tell the journal to restrict its log size to 1MB, install syslog, activate it , and the journal automatically pushes all logs it gets onto syslog.

Systemd forces conformity for the minor details that SHOULDNT be changing, but that distros seem to love to change for no reason, and enables and even encourages choice for the things that should be able to be swapped out and moved around.

Then what is the point? If you have to disable everything for it to simply be as functional, and still more complex, then why? Give me a good reason why I would need a more complex system that I have to disable the majority of to use...

I just don't understand why I need it. Systemd is part of the problem. Eliminating it fixes part of the problem.

EDIT: I have to step out of this conversation because now I'm just repeating myself.

[bwat47]

Then what is the point? If you have to disable everything for it to simply be as functional, and still more complex, then why? Give me a good reason why I would need a more complex system that I have to disable the majority of to use...

I just don't understand why I need it. Systemd is part of the problem. Eliminating it fixes part of the problem.

EDIT: I have to step out of this conversation because now I'm just repeating myself.

You certainly don't need to "disable everything" for systemd to be "functional", that makes no sense. You are just making yourself look ridiculous at this point, none of your arguments have had any merit.

[Nobu]

Apparently, you don't need it. His point is you can have systemd be as simple as init and log management, or you could have the whole she-bang.

If you have only the base, then it's not bloated at all. The executable may be a little bigger than your typical init, but it also removes much of the duplicate code that you would find in init scripts and simplifies debugging the boot process (because it's only one process now, and then the service, rather than init, all the scripts, and the service itself).

The rest may not be necessary, depending on your specific use-case. In most cases, distributions will make an appropriate choice about what components you will need, however if you have a very specific use-case, you may have to make some of those decisions for yourself (I imagine you chose not to use systemd on your gentoo system). If you are able and inclined, you can install another init or use some alternative to one of the many components that systemd replaces. Otherwise, the documentation is there for you to look at if you need it, and I'm sure someone would be willing to help if you asked on a relevant IRC channel or forum.

I am required to look at documentation before doing any kind of work, sometimes that's just how it is. But I'm being paid for that work, so I don't mind learning a thing or two while I'm at it.

I'm curious to know what distribution you're using for your thinclient servers.

[Ericg]

Then what is the point? If you have to disable everything for it to simply be as functional, and still more complex, then why? Give me a good reason why I would need a more complex system that I have to disable the majority of to use...

I just don't understand why I need it. Systemd is part of the problem. Eliminating it fixes part of the problem.

EDIT: I have to step out of this conversation because now I'm just repeating myself.

Seriously duby, I was really going with ya up until this post. "Disable everything to make it functional"? Are you one of the gentoo guys who goes through and disables every single option the kernel that you dont use / dont know what it is just so its as tiny as possible? Systemd is completly and fully functional whether you pass it every "--disable" flag you can at compile time, or whether you let it compile everything it does by default.

The only POSSIBLE way your post makes sense is with this line: "If you have to disable everything for it to b e simply as functional and yet still more complex" Are you saying you want systemd to do everything sysV does and nothing else? If so, thats the problem here, lemme try an analogy.

Did you ever have a manager that you had to report to that didn't give a fuck about his job or getting the job done? Just kind of let everyone do their own thing and if 1 or 2 people wanted to work, that was fine, good for them, but he really didnt care either way? Thats sysV. Then along comes the systemd style manager, he's the one that makes sure everyone is doing exactly what they are supposed to be doing, no one's goofing off or wasting time. Everyone kind of hates him because he's actually supervising and not just chilling, but at the sametime: Hey what a miracle, things are actually getting done now!

[duby229]

I many other ways do I need to say it? It's bloatware... It doesnt -need- to do just about anything that it does. It is a workaround for a problem that is being addressed in a really bad manner. In addition it tries to be everything for everyone. Where is the line going to be drawn?

What it needs to do is manage services. Anything more than that should be a different project and should be a service. This bullshit integration crap is nothing more than an excuse. It wouldnt need to be modular (which it does poorly, and which LP has publicly stated is temporary) if all these additional functionalities were split out and maintained separately under individual projects and were themselves managed as independent services.

EDIT: When is systemd going to go fetch my email for me? When is it going to synchronize my phone for me? When is it going to -be- the firewall. When is it going to render opengl for the gpu drivers... etc, etc... Where is the line in the sand going to be drawn?

[Nobu]

Alright, I'll run with that.

It manages services. Services need to make logs, it manages the services' logs. Services need to communicate, it manages the services' communication. Services need to run a certain amount of time, with a limited amount of resources, it manages the time and resources that the services are allowed. Some services need to be isolated from other services, it manages that isolation. Some services need to know the system name and various other system details, it provides that information to those services. I could go on...

There are, of course, certain things that you could argue that it doesn't need to do. You could argue that it doesn't need to manage desktop sessions, and I wouldn't be that inclined to disagree with you. I'm sure there are others, but that doesn't mean the whole thing is a heap.

You could similarly argue that the whole Linux kernel is bloated and does a lot of things it doesn't need to or shouldn't. Maybe it should be a micro-kernel, with everything implemented in user-space? But that's not what we were given, and unless you or I learn to write programs which work better, more efficiently, and with less bloat than systemd and Linux, we're going to have to stick with what we've got, or use something else, or help solve bugs in what we do use. (Edit: This last sentence is part of my job too, except not with software)

[Ericg]

I many other ways do I need to say it? It's bloatware... It doesnt -need- to do just about anything that it does. It is a workaround for a problem that is being addressed in a really bad manner. In addition it tries to be everything for everyone. Where is the line going to be drawn?

What it needs to do is manage services. Anything more than that should be a different project and should be a service. This bullshit integration crap is nothing more than an excuse. It wouldnt need to be modular (which it does poorly, and which LP has publicly stated is temporary) if all these additional functionalities were split out and maintained separately under individual projects and were themselves managed as independent services.

Systemd manages the lifetime of the machine. bottom line. Its the userspace mirror to the kernel.

It handles poweron and poweroff and suspend (three major states of the machine.) Sysv did too. (Not suspend, but sysv was thought of long before 'sleeping' was a thing). Why should systemd do it? Because when you go to sleep you're effectively killing everything. All services need to be made sure they are starting and stopping appropriately on wake up / sleep respectively. Replaces acpid in that regard (Seriously, why did we need a tiiiiiiiiny little daemon just to handle lid open, lid close, and power button push?)

It handles what xinetd used to do because sysV didn't want. Well, what did xinetd do? it started services...but wasn't that sysV's job? well yeah, but sysV didnt want to do it.

It, more specifically the journal, handles logging. Why does it handle logging? Because the services themselves dont. Do you really want every service putting its own logs in different places, of varying quality? systemd starts the service, if the service is killed, or segfaults, systemd needs to know so it can restart it, or atleast flag the service for review.

It handles resource management. Why does it handle resource management? Because under sysV you could get away from your parent process by double-forking. Systemd though has a very tight chain on processes and no amount of forking will ever get a process way from its parent process, or out of its cgroup. Could this be split off into another project? Yeah, it could. But systemd was the first one to go "Hmmm...we could do this..." so it does. The upside is since systemd does it, then resource limits can just be put into the services unit files. What does that do? It means the resource limitations of a service are right there with the services unit file, not off in some other directory. Its a "This goes with this" relationship.

All of the things I listed above-- why does it do them? Easy: force uniformity FINALLY. If you want all the upsides and benefits of systemd, then the distros also have to go "Okay, yeah, all these random bullshit changes we've been making all these years...probably not necessary." If those things were in seperate projects, then the distro could just choose to not adopt that project or convince the developer to join their project and thereby strong arm him into making the changes for THEIR distro's style the new default for everyone else.