Debian: Transition plan to systemd by default
lists.debian.org
lists.debian.org
This will lead to a lot more efficient and maintainability of the Linux OS for a long time to come once we get past the near term hurdles of reduced stability and various regressions (and obvious design issues to be resolved) that come from such a huge change.
I'll be honest, I didn't think this was possible.
How does consolidating functionality and control into one piece of software increase efficiency and maintainability? In my past experience, monolithic software efforts can be more efficient in the beginning, but they quickly become a maintenance nightmare as fewer and fewer people understand all of the moving parts.
You don't have to look far to see the effects of this: the Linux kernel is filled with small "I'm not sure we can remove this but I don't think it does anything" comments. You can also see it in the SaaS market as they move towards microservices, away from the monoliths of yesterday. You can see it in the giant corporate structures who take 6 months to requisition a smartphone for testing which will be obsolete in another 6 months.
The init system has the flaw of being too distributed to offer intelligent coordination between processes, but I'm not sure that following the pendulum swing to the complete opposite end of the spectrum was the best choice either.
Yes, there is a chance that components of systemd could suffer bitrot, but I'd argue its less likely that a project under the tutelage of Red Hat in the interests of its enterprise crowd will see the rot that other projects like xinetd have in recent years, where major contributors just stop, the whole project grinds to a halt, but because its not part of some broader software project nobody notices to pick up the slack (note, my example has gone through periods of rot and revival when someone notices its become a problem). If one component starts rotting the bugs will pile up on the systemd bug trackers and the broader project will notice and respond more efficiently since everything in systemd uses the same semantics and code formatting and the developers will be more comfortable changing their working directory than their repository.
Except for generators, certain auxiliaries like rfkill, journald, udevd and others. It's rather inconsistent, as is the specific libraries that can be disabled.
I'm not speaking of the entire systemd daemon ecosystem (which already displays coupling between logind and journald), just the systemd-as-init daemon.
> I'd argue its less likely that a project under the tutelage of Red Hat
I'd argue in return that if the Lennart Poettering bus factor suddenly went critical, systemd development would indeed hit a significant roadblock. Perhaps not insurmountable, but how many people understand the entirety of the systemd ecosystem? How many resources would RedHat be capable of devoting to this one project?
> the bugs will pile up on the systemd bug trackers
The RHEL bug tracker is currently at 250 open bugs, with 40-50 of them in the "NEW" category, with some of those dating back to 2013. The oldest open bugs date back to 2011. In my opinion, this shows a lack of bug triage, one of first outward signs of "bug pileup".
This seems to be the initial design document for logind: https://docs.google.com/document/d/1_ev4f0gwBuvs6SH_N8fN5LO4...
But then seat tracking on any platform where IO devices can come and go while in operation seems like a gnarly issue to say the least.
Because people working on components that interact with each other are working in the same project now. They see each others commits. They see each others question on the mailing list. etc.
Let me ask the reverse question: How would this be improved by splitting systemd into independent projects?
From what I see on the devuan page, in the spirit of FOSS, the people that prefer to keep init as part of their setup, have forked debian into devuan, and propose to retain the "init based debian", for people that prefer init scripts.
That's the shortest summary I could come up with for you.
Another short writeup by @tinco https://news.ycombinator.com/item?id=9094142
Maybe the downvoter(s) were some of the same folks who raised their concerns in the above thread? Or maybe it's just the typical systemd holy war going on. I'd guess the former though.
If I understand Devuian correctly, they will port releases of core software off of systemd and back to init, giving you the option of still using core software packages without systemd.
> Devuan will derive its own installer and package repositories from Debian, modifying them where necessary, with the first goal of removing systemd
Debian is committed to support sysvinit for the next release at least. I really doubt anyone in Debian will add dependencies on systemd "just because": if they do so they may have compelling reasons (eg. ConsoleKit is unmaintained and broken) and the correct reaction would be to fix the issue (eg. like the ConsoleKit2 people are trying to do) rather than forking Debian just to ignore the issue.
Not that forking Debian is bad and people should not do it for whatever irrational reason if they want: it's just that in this case there's no rational reason the same task couldn't have been carried over in Debian itself other than the fact that in your own fork you may accept lower quality contributions more easily.
http://lists.devuan.org/dwn/1424284246.7620_1.fork:2,S.html
https://git.devuan.org/devuan-infrastructure/dak (last commit 8 hours ago as I type this).
I've been a happy Debian user for many years but lately I've fallen back to using *BSD (particularly OpenBSD). I guess that puts me in the "old and afraid of change" camp but for me it's nice to be back using something that looks and, more importantly, _works_ like Unix.
Debian will remain my goto distribution when I want/need Linux but it's no longer my first choice...
> but it's no longer my first choice
What is out of interest?
Other than that I've been playing around with FreeBSD and have revisited Slackware which was the first Linux I was introduced to via a book/cdrom back in the mid 90's.
Having had some success with OpenBSD on servers I'm running it on a laptop as one of two workstations at work. The other has Wheezy on it. I'm able to do most of my day to day work on OpenBSD but do find myself remoting into the Linux box for some things (e.g. mysql-workbench).
I imagine many people might trust systemd more than the overlapping set of init/cron/at/supevisord/monit/forever/user generated SysV init shell scripts of varying quality.
Who/what is driving this despite all the controverse?
Code contributions, even if controversial, pack a much stronger punch than emails, forum posts, blog posts, etc.
Also, remember that launchd on OSX has been around for a decade. People from the linux world who encountered it tended to think "hey, this is kinda nice, I wish we had something like it." Perhaps launchd itself had a predecessor somewhere, I dunno. But the point is that people had seen these systems in the wild, so when someone showed up who was serious about seeing the project through there were a bunch of maintainers whose reaction was "about damn time" rather than "what is this?"
There is a very loud minority in the linux community that doesn't want things to change. There are a ton of linux users who's lives this improves, and they are not as noisy.
Debian is the larges distro and when the maintainers took a vote systemd won with like a 60+% majority. Almost all other distros that are going to, have switched over the last 3 years.
2/ Gnome started requiring systemd (via the dependency of GDM on logind). So, if they want to keep supporting Gnome, they have a choice between switching to systemd or developping some shims. And it's probably safe to assume other major pieces of software (KDE?) will adopt similar requirements.
I suppose one might say that this is a core component of the system and even three or so years of testing is not enough... But, I think at that point, we're off in the realm of opinion.
I love Arch too, but damn! I remember the "upgrade" process to systemd that wrecked my system (not unrecoverably, but before they released the fix path, I already reinstalled.)
I don't remember the systemd transition in Arch being too bad, though it was sort of rough around the edges. I guess that roughness is why (mentally) I hadn't expected anyone to have adopted systemd before Arch.
It is almost as if you can see the frog slowly boiling...
And nobody is even shipping a distro with networkd as the only network daemon. They are all still using networkmanager. I doubt anyone will switch any time soon either, since the faculties of networkd are a lot more limited.
And I'm wondering how a project that is meant to encompass a common base userspace OS is boiling anyone by adopting things like network management into it. That seems pretty base OS nowadays to me. I'll worry if once everyone is on systemd we start getting horror stories of the upstream systemd developers blocking contributions and fixes because they conflict with what they want in the project (a la Gnome, not like KDE).
2. It would really surprise me if networkmanager finds itself being anything more than a frontend for networkd within a year or two.
At this point in time i am starting to think that going back to pre-freedesktop Linux may be better for my ulcer than trying to keep up with the desktop (developers) uber alles threadmill.
Here's an article where debian is talking about systemd in 2011 [0]. Forgive me for beign a bit shocked when people say things like 'it happened so fast!', but it's almost like people just sincerely want to hate systemd.
[0]http://lwn.net/Articles/452865/
edit: I really wanted to ignore this, but it's eating away at me.
>and, more importantly, _works_ like Unix.
Maybe I'm just cynical, but I get the feeling people who pretend their interpretation of the unix philosophy regarding systemd is the superior interpretation, probably didn't even know what the tenets of unix philosophy were before the drama.
I only read part of the Debian voting process, it's wasn't years but I admit not knowing how long systemd was discussed in Debian's ML before that. On archlinux board's, adoption was quickly reached (without too much user troubles).
Also one of the busybodies within systemd development is directly involved with Arch maintenance...
Btw, the big pedia claims that OpenSuse and Mageia(?) also use systemd. At least one of them is a fork of what used to be a RHEL fork with a more desktop orientation.
Then again, the adoption may well have happened before systemd started absorbing/reimplementing so many other functions.
Smarter people than me have done a great job of debating both sides of the issue and it looks like systemd has won. That doesn't mean I have to like it and thankfully I can fall back to using OpenBSD since I want a Unix that looks and feels like the Unix I've been using my whole career.
I don't care if you disagree with me but please don't assume that I "don't even know the tenets of unix philosphy" becuase I happen to view systemd in a way that you apparently do not. If all the major distributions are going with systemd than OK, but the beauty of free software is that I have choices and I've made mine.
But the worst part is probably init scripts.
$ wc -l /etc/init.d/smartd 653 /etc/init.d/smartd
653 lines of code to start a demon, because of the differences between all distros.
Guys, seriously ?
What you're doing is the equivalent of looking at some old Mach performance statistics and concluding that microkernels cannot possibly work... never mind there's one alongside every smartphone.
I miss OpenRC, for that matter. Using that is the only time I've felt something like contentment while managing init.
Yeah, they should give it a few decades of thought...
And maybe check out if this ANSI C thing is worth supporting over plain ole K&R C.
Both the sysvinit and systemd crowds have brought up great points - issues that needed to be addressed. The strong willed nature of the *nix communities is what makes them great. Strength in numbers. "Fighting" is a natural process; whether it's a team or a family.
Incredibly excited to see what kind of impact this has on computing as a whole. Time to learn something new.
This announcement only occurred because, after that transition, someone formerly on the technical committee (now resigned, but a member at the time) attempted to use the technical committee to force a revert of that transition. This announcement is effectively the current technical committee saying "nope, the other teams in Debian have done a fine job arranging this transition, and we're not going to overrule anyone".
(I helped draft this proposal, and spent a fair bit of time trying to make sure it would not be taken as changing the current state of affairs in any way, only affirming the work others had already done.)
I'm not a fan, it has caused a variety of problems (which may be teething trouble or not), I'm not a fan of its logging and I don't like that when I make changes to 'legacy' stuff in /etc/init.d systemd tells me I need to issue more commands to get it to re-read the startup scripts rather than just use them... feh.
Can anyone give a (brief) explanation as to the background of the controversy?
(I don't agree btw, just giving some info on opinions that others have)
One example of this interpretation - we can no longer reliably use `netstat -nlp` to determine what process is responding to requests a particular socket. In certain configurations, `netstat -nlp` will show systemd owning the socket, not the process who receives and responds to the process.
e.g. Systemd will own port 80, and feed it back to Apache who listens over 8080.
To determine who will truly respond, you need to know the proper systemctl incantation, or find the configuration file (there are 8 locations across 3 folder hierarchies where these can live[0]).
[0] http://man7.org/linux/man-pages/man5/systemd-user.conf.5.htm...
Isn't this true for all commandline programs? It's a different way to do things in many ways, but this argument doesn't really talk about the merits or pitfalls, only the fact that it's different.
Also, netstat has existed and worked for more years than I've been a sysadmin. I'm not opposed to learning new things, but this magnitude of change and inconsistency is hard to keep up with.
Now that socket-activated services may see more widespread usage, hopefully someone interested will add to `netstat` the ability to tell who is listening on the socket and not only who opened it (all the data is available in /proc, which netstat is using already).
And in the meantime there's always `systemctl list-sockets`.
Either way, netstat -nlp isn't lying about who owns the port 80 socket. It's a terrible idea, but the data returned is not incorrect.
In other cases, Systemd acts as an advanced xinitd and start services on demand, which means that Systemd listens and starts a service, but the service does the accept and responds.
So... it's hard to say without digging into the systemd configs.
Nope, systemd only opens the socket and passes the fd to Apache.
> Or is it launching Apache on demand like some sort of advanced inetd?
Yes. Since it's already init's job to start services, it does not make any sense to have a different system to start socket-activated services.
You also get socket activation, for free.
Within individual process trees, yes. Across all process trees via the init system, not so much.
I agree that it is a very useful thing to do and has been technically possible forever (since spawned processes need to have their inherited file handles over 2 intentionally closed), but it adds a bit of uncertainty and unnecessary coupling when it starts crossing the (admittedly arbitrary) process role boundary.
The benefit of faster startup time is negligible for the typical non-desktop.
> You also get socket activation, for free.
Socket activation has been available for many (10+) years via xinitd, but it is infrequently used for a variety of reasons. For one, it's slow. The time required to spin up a new process to handle the requested information is non-0, particularly in cases where socket activation is most likely to be used (shell scripts, Python/Ruby/Node applications). This is OK for services used only occasionally, but for any frequently used service it is usually unacceptable.
Plus, the overhead of keeping an occasionally-used service running in memory and listening to its own socket is typically pretty low, yet it provides the benefit of knowing exactly what is responding to a given socket.
https://dougvitale.wordpress.com/2011/12/21/deprecated-linux...
At least for smaller tasks like toggling a interface up or down.
No, Apache actually listens to port 80, just on a socket created by systemd. systemd opens the TCP listening socket, spawns Apache (potentially on demand when connected to), and passes along the file descriptor for the socket. Apache then treats that file descriptor as though it had opened it itself. Similar to inetd, except that it isn't limited to stdio.
That said, since netstat -p shows who opened the socket rather than who is using the socket, socket activation does make it less useful. Given that netstat -p already reads all the necessary information from /proc, it'd be nice to teach netstat to show multiple programs listening on a socket, not just the opener.
I have not read this carefully enough to fully endorse everything it says, but the main point should be (lack of) modularity.
Remember the stability, flexibility and reliability that PulseAudio brought to Linux audio? Imagine that in your boot process.
I wonder if Lennart Poettering is secretly funded by a consortium of Microsoft, Apple and IBM.
Number one pet peeve - I can't disable mic auto-volume.
Number two - if you don't run Gnome, you're screwed having to resort to very complex, not-self-documenting command line tools to do the simplest of stuff. How do I change the volume of the box from the command line ?
Number 3 - everytime I plug my laptop's DisplayPort into a TV (used for presentations here), PA routes the audio automatically over the TV. But when I plug it out, the sounds happly continues into the depths of /dev/null, and I have yet to find a way to re-route it to my headphones without killing the PA daemon.
And I can continue. PA works ok only if you if you run Gnome, and you never plug in/out audio devices. It's a horrible software piece, but I'm stuck with it because it's not my priority to write audio daemon replacements.
You can use pavucontrol without Gnome. Don't know what command-line tools, if any, are available for Pulse Audio.
There is an option to disable upmixing entirely but that triggers at least a couple of bugs. One involves the VU meter indications (shrug). The other causes pulseaudio to emit silence instead of mono streams (fatal).
This bug has been open for over a decade now. At least one patch has been submitted and shrugged off. If you look at the tracker you will see lots of bugs like these where knowledge of the entire system is required to fix them. What seems to have happened is that once the original developers left, some bugs became eternal.
I clearly have tons left to learn as a Sysadmin
Jordan Hubbard already said that FreeBSD needs an systemd equivalent. OS X was the first one to get one, Windows traditionally has a general design that resembles systemd much more than any other init system. I think you are running from reality.
Give me the coolness of systemd maintained by someone that isn't impossible to work with, and i'd be all for it.
Truth to be told, the systemd community has been reported as one of the most welcoming and productive environment in the FLOSS ecosystem.
Heck, even that wouldn't be a thing if the people involved had the ability to publicly say "I was wrong on that" - but not even that happens that I've seen.
Of course they have a strong vision, and popping up proposing something that has already been discussed to death and rejected won't be the most pleasing experience ever (it happens all the time here, I don't even want to imagine how tiresome it should feel for them).
There are thankfully a few non-systemd linucies around - Gentoo, or others have mentioned Slackware.
On the other hand, the issues are also in the soft-realtime-ness, the hardware drivers, the embedded community,etc.
Indeed for Desktop or Server, *BSD might do it just fine, though many OSS development env these days are tested by default on Ubuntu/Debian etc instead of BSDs.
My nightmare is that systemd evolves towards a system like this--opaque, baroque and difficult to debug.
It's the position of the verb that makes war. ^^
This might not be the end of linux but it's really really harming it.
Windows and FreeBSD with ZFS are beautiful in comparison. I've come to recommend those over Linux these days.