Slashdot Mirror
Systemd's Lennart Poettering: 'We Do Listen To Users'
M-Saunders writes: Systemd is ambitious and controversial, taking over a large part of the GNU/Linux base system. But where did it come from? Even Red Hat wasn't keen on it at the start, but since then it has worked its way into almost every major distro. Linux Voice talks to Lennart Poettering, the lead developer of Systemd, about its origins, its future, its relationship with Upstart, and handling the pressures of online flamewars.
It's a lot better than openrc, which is needlessly slow due to being written in bash and fails at running tasks that don't depend on each other in parallel. I've converted both my desktop and laptop and now more concerned with keeping openrc away from Gentoo.
OpenRC is written in C for the most part. Each init script is shell based though and works fine with pretty much any shell.
You can use bash if you want to, but I prefer to run dash.
As to the parallel start up - well, some users do have an issue depending on what services they have installed and configured.
I personally have no problem with it and use it all the time.
As to the speed? Well, it gets me to the desktop in the same number of seconds as systemd.
The Unix philosophy is, depending on whom you ask, "everything is a file", "KISS (keep it simple, stupid)", or "do one thing and do it well". Poettering makes up another interpretation, that being like Unix means putting everything in one code repository and releasing in sync, which he then notices is what they do with Systemd, so it's very Unix-like. That of course is completely bogus and counter to everything that Unix represents. In particular, Systemd is a violation of "everything is a file", "KISS", and "do one thing and do it well".
Exactly! I have used openRC since it was in beta and it works really really well. Parallel boot works well, the cgroups container stuff works well as well (before some processes were just not being fully killed...)
My system boots equally fast to desktop as with systemd. The major speedup for me was NOTHING todo with openRC or systemd... it was HDD -> SSD (even before sysd ~= openrc).
Only slow thing is dhcpcd but that is more router based then openrc/dhcpcd/sysd.
OpenRC is really really good.
Its one tool, that does many things and does them typically poorly compared to the replacement tools. Systemd does multiple things and does them poorer then what they replaced, therefore it does not do one thing, let alone well. He is trying to redefine systemd away from being the tool and just being a repository, which utterly fails due to some components requiring others in systemd.
When you cant win, ad hominem.
The parallelism that systemd developed was for the benefit of those that create and kill instances of Linux all the time so fast booting is necessary and i guess thats part of a system administrators task list (and it benefits desktop users as well).
Everything in the systemd package is configurable except journald and udev so you can configure any other network stack etc you want etc, you are not forced to use anything apart from systemd, journald (which you can ignore and use syslog instead) and udev. Move to RHEL7 when its suits you but you'd best start getting to know systemd, its not the monster alluded to by trolls.
its only a big issue for "some" admins, the ones that haven't really done any research into what systemd can/cannot do.
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
Why would LibreOffice
You do realize OpenOffice does run in a server-mode.
It's useful for doing thtings like batch-processing word documents.
Same for Gimp: " This command will start a server, which reads and executes Script-Fu (Scheme) statements you send him via a specified port. ".
...ever be dependent on systemd?
I don't understand why 90% of the crap systemd's trying to suck in (like networking). Yet the systemd guys continue to glom everything in there.
I also like how he calls systemd non-monolithic, of course, without giving any reason for why that is.
And that seems to be one of the big differences between people who like systemd and people who don't.
People who actually took the time to look at systemd more often like the design, and understand that the one project consists of many small tools.
Then there's a community of people who rely entirely on hearsay. They don't like systemd, but almost all of the things they don't like about it aren't true. In this case, believing that PID 1 is a process that does daemon handling, and logging, and firewall rule handling, and DNS, and device node handling, and...
Those things are not handled by the same process. It's non-monolithic. It's small tools doing individual, well defined jobs.
Basically, it's not factually incorrect, but very misleading. Sure, they are separate components but they are so tightly coupled you can't really have one without theother so they operate in the same way as a monolithic system despite being split up into multiple components. Facllacy #1 explains it much better than I could here.
Wrong. That base still wouldn't boot my server for me and the systemd people would still be spinning in circles unable to even conceive of a way to fix it. You see, I want the server to boot w/ btrfs in degraded mode should it suffer a drive failure. But systemd won't do it.
I don't know about Suse, byt Red Hat does not. Otherwise they'd have noticed that sysadmins are sticking with RHEL6 to avoid systemd trouble.