Devuan: Debian Without Systemd

[pal666]

The problem with systemd and its Linux kernel dependance as it pertains to Debian is that it inhibits Debian from remaining a kernel choice OS.

utter bullshit. debian is hostile to nt kernel. there is no debian/kreactos. i demand to ban sysvinit from debian because it harms choosing kernels

[pal666]

the sysvinit camp is mostly compromised of system administrators and veteran developers.

no, sysvinit camp is mostly comprised of same assholes who were in miserably failed eudev camp

[AdamW]

That said, twisting my words really does not do justice to any sort of dialogue and reflects poorly on both yourself and those associated with you. Please either confirm that you reject the idea that there are different levels of ability among developers or apologize for misunderstanding my point.

I didn't "twist your words". I directly quoted them. Here's a hint: when your own words quoted back to you look so bad that you have to accuse someone of "twisting" them, you're not doing too well in the argument.

Here's those twisted words again, folks:

"From my perspective, the systemd camp is mostly comprised of an end users who are vulnerable to hype and less experienced developers while the sysvinit camp is mostly compromised of system administrators and veteran developers."

That's what you said, right there. If you were only talking about developers of different levels of ability, perhaps that's what you should have written.

[Dukenukemx]

This issue with systemd vs init just seems like Gamersgate. Nobody knows why to hate systemd other for the reason of because. Is it better? Yes? Then why go through the trouble of making a fork of Debian for something outdated like init? Especially when you know nobody is going to use it.

If the developers of systemd are assholes is inconsequential to me and other people. Mostly because 99% using the OS don't know who the developers are or even know what systemd is. For that matter, even care.

[AdamW]

They are known to change working code and have broken working systems. One example involves the network device interface names, where fallback code was removed and system boot broke. A collegue of mine who is a major systemd fan and I had a discussion about systemd a few months ago. He had significant difficulty believing this was the case, but commit histories show that it was. In a similar vein, the core systemd developers have blamed others for bugs in software that they wrote because other software did not adapt to fix it. A prominent example involved the kernel syslog code. Their attitudes caused them to be banned from contributing to the Linux kernel.

Sigh. It's amazing how you can say stuff that's *almost* true, yet still completely silly.

They're known to "change working code", you say? No! How terrible!

Erm.

What software development project, exactly, doesn't "change working code"? Any commit other than one which exclusively fixes a bug that affected 100% of the user base "changes working code". It's an absurd objection.

"and have broken working systems"

Well, yes. That's called a "bug". Software has them. All software. Hey, let's take a look at the OpenRC bug tracker. Oh, what do we have here? "After update openrc in my lxc container from 0.9.8.4 to 0.11.6 and reboot, network interface in container up fail with error:"

Hey, looks like someone changed working code and broke a working system! (For bonus points, the developers then tell the user they were doing it wrong, just the sort of thing people are forever complaining about with systemd). Objecting to a software project on nothing more than the grounds that it "change[d] working code and have broken working systems" is like objecting to the sun on the grounds that it's hot. If you meant something more specific, *say* something more specific, I can't abide this kind of waffle.

"One example involves the network device interface names, where fallback code was removed and system boot broke...but commit histories show that it was"

But you don't link to anything or provide any kind of details. Hey, Veteran Administrator - this here thing's called the World Wide Web. You may remember why it got so popular in the first place - you can use these things called hyperlinks to handily provide useful references for people. You might want to try it. If you provided any kind of references for this I'm sure we could see that you were badly misrepresenting the situation, like I happen to know that you did the next one, but I'm not familiar with the case you're referencing here so I can't correct it.

"In a similar vein, the core systemd developers have blamed others for bugs in software that they wrote because other software did not adapt to fix it. A prominent example involved the kernel syslog code. Their attitudes caused them to be banned from contributing to the Linux kernel."

So as I said, I happen to know about this case (for which you, again, did not provide any references). What you're talking about is this issue. It was highly controversial, but you're just printing one side as if it were the Universally Acknowledged Truth.

What actually happened is that one particular systemd dev (Kay Sievers) and some kernel devs had a disagreement over the semantics/ownership of the boot command line; whether it's valid for systemd to enable its debugging mode when the 'debug' parameter is passed, or whether generic parameters like that should be assumed in some sense to 'belong' to the kernel. And then, as developers are sometimes wont to do, they got all Maury Povich about it. I wouldn't say it reflected particularly well on either side of that particular debate, but it's nowhere near as clearcut as you represent it. As for the 'banned from contributing to the kernel' bit, that was Linus in full-on "people should be retroactively aborted" mode. I'm inclined to suspect he was being melodramatic - here's his post, for reference. It's hard to tell whether he really meant the mail literally (hey, people are always keen to tell me he was just talking figuratively/non-seriously when I quote that earlier email, so why can't I suggest he was in this case?), because Kay doesn't really write upstream kernel code anyway, so it's kind of academic - but even if we assume for the purpose of argument that he was, you state "the core systemd developers...attitudes caused them to be banned from contributing to the Linux kernel.", which is clearly not supported by the facts, because Linus did not say anything about any systemd dev other than Kay in that particular debate.

Can we please have less of the vague, detail-free, reference-free mudslinging and more properly supported facts?

[AdamW]

I should clarify something above - when I said "Kay doesn't really write upstream kernel code anyway" I meant he doesn't do it much *any more*, because he got worn down by the LKML attitude. He did used to do so. His last credited commit is from April 2013, and the last before that was in 2012. https://git.kernel.org/cgit/linux/ke...thor&q=sievers

[You-]

Watching the systemd fiasco continue to unfold from my perfect FreeBSD Unix workstation.

systemd - it's funny because it's not happening to me.

I see you haven't been keeping up with FreeBSD-land.

FreeBSD Founders/developer are proposing a systemd-like system to be created and laughing at linux for being held back by these flamewars about systemd instead of moving forward.

[phrx_reader]

Don't name Debian 8 Jessie

It is relevent as it is, but is not releveant anymore for Jessie... systemd decision as default init system is maded for Jessie many months ago.



In perfect world, users should choose what they understand and not what they not . Some people probably does not care about writing very much comprehensive manuals, when init is so simple - code reading spoke very much about it

The true name is Debian Lendows 1 (tm)

[tomegun]

There are a significant number of distribution developers who think that systemd is the only way to start software because of GNOME's dependence on it. There are also a significant number who think that systemd will be the only way to start all of their present software in the future. I also hear from people developing new Linux distributions that they are concerned about these things. These are concerns of inexperienced developers. Starting a daemon is not rocket science.

You didn't provide any sources, so this is clearly speculation on my side (but I have been involved in most these discussions, so I feel pretty confident): You are most probably misrepresenting the views of your oponents here. It is of course entirely implausible that "systemd is the only way to start a given daemon". systemd is just software, so whatever it does can be emulated by anything else. However, it may very well be that starting daemons in the (race-free, secure) way that upstream intended is only possible with systemd out of all the current init systems as they currently stand. I.e., if I ship a daemon which only supports dbus or socket activation it will not work reliably on OpenRC unless you modify OpenRC in some way, or add significant glue-code inbetween OpenRC and the daemon. The simple fact is that systemd provide useful features which OpenRC does not, so daemons taking advantage of these features would have to somehow reimplement them in the daemons/wrappers in order to work correctly on OpenRC. This they may not want to do (as they don't see it as their business to solve problems that their init implementation should have solved for them). So my educated guess is that you have heard "I don't want to do the unnecessary work to make my daemon work on non-systemd systems", rather than "my daemon cannot work on non-systemd systems".

They are less experienced compared to developers such as Robert Leigh and Ted T'so.

Name-dropping does not impress anyone... We all know that finding a couple of well-known people to support whatever statement, no matter how outlandish is trivial. Unless you have proper statistics, naming people who spoke out against systemd (no matter how respected) is just meaningless. Perhaps the only thing would be if some senior systemd developer spoke out against systemd, or in favor of something else, that would be surprising and noteworthy (in the same way it was somewhat interesting that Scott James Remnant stated that he prefers systemd to Upstart), anything else is just random noise.

The same could be said about system administrators adopting Windows versus those with UNIX beads who refer other systems. Many of them felt coerced into adopting it. There are people developing distributions who speak to me and say "I don't like systemd, but people say that I cannot develop a Linux distribution going forward without it.".

Again you are probably misrepresenting here. _Of course_ you can develop a distribution without systemd, if you have the manpower to do so. Thing is, you probably don't. And this is not due to some evil scheme by the shadowy systemd backers. It is simply that systemd are providing useful features that allow other software to be simplified and new software that is developed to be vastly simpler, so if you want to create a distro based on the same software, but without systemd (and without an init system with many of the features systemd provides), you have _a lot_ of work to do to keep up.

Only a masochist would [maintain downstream patches]. I would rather just refuse to put systemd on my computers than engage in such a one-sided relationship. Consequently, that is what I do.

No masochism implied at all. This is simply how mature opensource developers agree to disagree, whilst keeping a working relationship. Work together on all the things you agree on, figure out the things you don't agree on, and maintain a minimal diff that is continuously rebased. You should not expect to always get your way, and doing the equivalent of storming out at the first disagreement seems pretty immature. I contribute to lots of open source projects, and I too get suggestions rejected on a regular basis, one just have to try to find a compromise, or find a way to work around the problem. But trying to impose ones will on the maintainer, or waging a holy-war with claims of "these people don't play well with others becase they didn't take all my patches" is just not the open source way (nor any way, outside of perhaps kindergarten).

I have sent patches to fix things in systemd-udev in the past and they were rejected because my use cases were considered stupid, despite the enterprise distributions getting patches for similar things. I have no interest in trying again. That was part of the reason eudev was founded.

Hm, you are sort of changing the topic here, as I was commenting on the post by Ts'o, which you falsly claimed contained "ignored problems" about systemd.

Anyway, if you don't want to contribute to udev, then that is your right. And I actually applaude the eudev people for forking when there was a fundamental disagreement (which there was). To the best of my knowledge the disagreement was about backwards compatibility with older kernels and compatibility with non-glibc libc's. Whatever stance you take on these issues I believe are fair, nothing is inherently wrong here, it is just about what your aims are as a project. However, these aims (of udev and eudev) are mutually exclusive, so a compromise is not really possible. I have criticised the way in which the eudev group technically went about their fork, as that was not really professional nor helpful to themselves nor conductive to future collaboration (they made forwards and backwards porting extremely hard, and broke a lot of stuff unnecessarily). What they could have done instead would have been to maintain a handful of patches on top of systmed which would give them precisely the same result but without all the code-churn. At the end of the day, that's their problem, I just wanted to point out that I did not mean to criticise the fact that they forked, I'm all for that.

I consider those that claim that /etc/rc?.d is part of sysvinit to lack understanding at such a fundamental level that they have no idea what they are discussing.

Not really. At the end of the day this is a technical detail, and an irrelevant one at that. sysvinit (as used today) does nothing really interesting, and could easily have been dropped completely if people wanted just sysvrc/OpenRC without sysvinit. People conflating these things may just be a short-hand, I certainly am often guilty of doing this myself (and having maintained a sysvrc alternative for a few years, I _do_ know the distinction).

The discussions in which you have taken part are *much* better than the ones in which I have taken part.

Then you have my sympathies...

You are going to have to be more explicit. The way that OpenRC scripts work is to block until something is up and things are allowed to run in parallel provided that they do not depend on one another. I am not familiar with any races under this model.

Oh, so parallel boot has been enabled by deafult in OpenRC now? That's nice to hear, last I checkd it was still not stable.

Anyway, the aim should be simplified daemon startup (i.e., move as much of the common logic from the daemons to the supervisor), and simplified dependency handling. In order to do that systemd implements things like socket-activation (which means there is in many cases no longer a need to specify the dependencies between things anywhere), and to allow daemons to drop things like double-forking.

Now, if you were to take a daemon written for systemd (i.e., without any explicit dependencies, and/or without doing double-forking and PID-file writing) and run that under OpenRC, it will be racy as OpenRC does not know precisely when it is ready, so does not know when to start follow-up services. Or worse still, daemons that do double-forking and PID-file writing and all the other dances they need to do in order to work properly on OpenRC, but somehow messes it up (it is not that easy to get right, and daemons _keep_ getting it wrong) will also be racy. It is much easier to write a correct daemon under systemd as all this code can simply be dropped.

The purpose of the redundancy is to enable updates to be done without restarting the system. I understand that systemd can do execve, although this is much more dangerous

Bugs? In my experience this works just fine, and in fact works better than upgradeing sysvinit (as we had some problems there in the pre-systemd past).

than just changing things outside of PID 1.

Nah, this is where almost all the problems lie. The amount of stuff that can go wrong with live upgrades is huge (in reality it mostly 'just works', but if you look at the details there is just no way with our current systems (nothing to do with PID1) that we can be in any way confident in this. I'm entirely convinced that double-buffered upgrades is the way of the future

Add support for other libc libraries, add compatibility shims for older kernels,

This is not in the scope of the systemd project. If you want to have a "portable systemd" fork which does this, then you have my support and I'd be happy to help you out in any way I can. However, just because a project does not fulfill all your goals, does not mean that it is impossible to work with. We just have to figure out what our respctive aims are, and focus on working on collaborating where it makes sense.

document things like XDG_RUNTIME_DIR so that you do not get maintainers of alternative systems like Roger Leigh complaining about how poorly documented things are,

systemd is extremely well documented. However, there is always room for improvements. Patches, or detailed questions about current documentation, are more than welcome. As to XDG_RUNTIME_DIR, that is not really for systemd to document though, it is an XDG spec, which we implement: http://standards.freedesktop.org/bas...ec-latest.html. If there is anything specific to our implementation that we should comment on in our docs, then I'd be happy to improve on that. Suggestions welcome.

actually offer suggestions on how use other distributions' existing cases can be handled without telling them that they are stupid,

No one should be insulted, with that I agree. And almost any usecase I believe is worth supporting. However, there are of course limits. I.e., if someone insist on doing things in very specific ways, and refuse alternative solutions that give the same result, then we may end up not being able to help (say you want to have /usr on a separate partition, but you don't want to use an initramfs).

stop making backward incompatible changes to long established code (e.g. network device naming) without leaving compatibility code to avoid breaking system services.

This particular code (renaming netdevs within the kernel namespace (eth0 to eth1 and similar)) was racy and never worked reliably. It is of course a question what is best; shipping code that works 99% of the time for 99% of the people and say that that's good enough, or say that it is better to fail hard and early to avoid the one in a thousand failure that you really can't afford. We tend to go with the latter: "if it is broken, no matter how little, drop it and provide a working alternative". Of course, distributions should be very careful about how such upgrades are done (either with lots of warnings, or by only doing it in "major" releases).

If marketshare is your only measure of success, then there is nothing that could make systemd more successful. The same can be said for the Windows operating system. That said, there are other metrics, such as not breaking systems when package upgrades are done and keeping an always releasable HEAD. Commits to the systemd repository have historically failed these metrics so horribly that I no longer bother to look.

A combination of quality and adoption sounds like a reasonable metric. We are clearly doing well on the adoption front, and considering most complaints about the software itself are either from people not using it at all, or related with the transition to systemd from something else as part of an upgrade (which is bound to be painful), I do feel pretty good about the quaity too. I guess time will tell though.

There are a significant number of distribution developers who think that systemd is the only way to start software because of GNOME's dependence on it. There are also a significant number who think that systemd will be the only way to start all of their present software in the future. I call that buying into hype.

I read most the systemd debates, and I have yet to hear anyone make this claim. I hear lots of people saying similar things which may be misconstrued in this way, but not at all the same thing.

Telling people that they are the equivalent to members of a terrorist groups for not using systemd with Linux as someone did in this thread and other remarks like it are contrary to the principles of free software. Do you mean to say that this is not the case?

Three things: 1) that statement is not contrary to the principles of free software, in fact it has _nothing_ to do with the principles of free software. 2) that is not what the person said, your whole argument would be much more credible if you were more careful when paraphrasing people... 3) both what the person said, and what you claim they said, are immature and outright stupid things to say, and such statements should not be welcome in any community (free software or otherwise).

I disagree. OpenRC handles people's use cases and incrementally improves as time passes. We do not have to deal with inoperable systems because of the latest experiment that the OpenRC developers decided to do. To me, that is very exciting.

"Inoperable systems because of the latest experiments" is that an insinuation? Care to back that up with staticstics or bug reports?

[Xaero_Vincent]

utter bullshit. debian is hostile to nt kernel. there is no debian/kreactos. i demand to ban sysvinit from debian because it harms choosing kernels

Should've said *nix-style kernels

I know this is a troll post but just how would a NT kernel be made to interact with a completely *nix GNU userland? Maybe with a huge amount of hacking, implementing *nix style system calls and subsystems into into the ReactOS kernel, things can be made to work. As of now ReactOS and it's kernel can only run Windows applications with likely less compatibility than even Wine.

There was once even an effort for Debian/kNetBSD but it was abandoned because almost nothing worked and that was even a *nix kernel.

In contrast, Debian GNU/kFreeBSD is pretty straightforward and most programs compile and run without problems in Debian using GCC and glibc rather than BSD libc; Only minor patches here and there are needed for things to work. At least this was the case until systemd appeared. Granted, the BSDs are beginning to work on a systemd-compatable "systembsd", so in the long term it might not be a huge problem. They are also trying to reimplement somthing like launchd from MacOS X.