Debian TC vote on init system coupling
Debian TC vote on init system coupling
Posted Feb 23, 2014 21:52 UTC (Sun) by anselm (subscriber, #2796)In reply to: Debian TC vote on init system coupling by malor
Parent article: Debian TC vote on init system coupling
Words can't easily express how much I'd prefer it to have a different team and different design in such a central position in Linux, but if it's happening anyway, we might as well take full advantage.
The thing is, there is no other team and no other design. The pre-existing solution doesn't have any sort of design at all, and even something like Upstart didn't do a lot to help with that situation in general (it just tried to replace one part of the mess by something a little less messy).
Getting the foundations of Linux userspace in order is a huge job that has been long overdue, and it is a big relief that finally some people stepped up to tackle that job. It is even better that the project has had huge buy-in from all major Linux distributions, and that there is an active development community whose members span these distributions as well. In the end, Linux is only doing what essentially all other Unixes have done before.
Of course, like in all software projects there will be shortcomings and bugs, but it is safe to assume that these will be addressed in the usual manner, i.e., by people showing up with bug reports, enhancement requests, and fixes that the development team will evaluate on their merits and act upon as appropriate. OTOH, what is unlikely to happen is that sweeping changes to systemd's design and implementation will occur based on unspecific bitching by random people who in many cases have not even looked at the software and/or documentation, let alone tried it for themselves.
Posted Feb 23, 2014 21:55 UTC (Sun)
by malor (guest, #2973)
[Link] (144 responses)
But... he's the guy who showed up with the code. Nobody else has.
Posted Feb 23, 2014 22:26 UTC (Sun)
by HelloWorld (guest, #56129)
[Link] (4 responses)
Posted Feb 23, 2014 22:29 UTC (Sun)
by malor (guest, #2973)
[Link] (3 responses)
Posted Feb 23, 2014 22:35 UTC (Sun)
by HelloWorld (guest, #56129)
[Link] (2 responses)
Posted Feb 23, 2014 23:10 UTC (Sun)
by malor (guest, #2973)
[Link]
Posted Feb 24, 2014 17:49 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
It's irrational, I know it's irrational, therefore I don't make a fuss over it. I just make a personal point of avoiding Red Hat as much as I can. Unfortunately for him, avoiding systemd is likely to be hard.
And Poettering IS a difficult person to get on with, if you don't like teutonic abrasiveness. "I just don't like so-and-so" is a perfectly acceptable statement, provided you accept that it's "just personal" and don't make a fuss about it. I suspect I'd get along with Lennart pretty fine, because I'm pretty pedantic and logic-focussed, and if we argued one of us would win by persuading the other. But when it gets down to gut feelings, you can't win arguments that way. You have to agree to differ, and that can be hard.
Cheers,
Posted Feb 23, 2014 22:27 UTC (Sun)
by javispedro (guest, #83660)
[Link] (137 responses)
From my point of view, all of the alternative init systems presented did their homework. It's just that they didn't share the "shell scripts are evil" preconception.
Posted Feb 23, 2014 22:44 UTC (Sun)
by ovitters (guest, #27950)
[Link] (134 responses)
That's not what happened. OpenRC is portable, but not really. They e.g. advertise being reliable due to cgroup, while only adding that way later. Than saying portability while that means you aren't as reliable anymore. If you follow the discussion and changes in OpenRC in Debian, one of the latest additions was something like that shutdown is reliable. That change was pretty recent, all the time before it wasn't mentioned. Ignoring problems like this makes you think it might be a good alternative, just because so much is not talked about.
Your "not cool enough" tells me you have no idea.
Posted Feb 24, 2014 0:57 UTC (Mon)
by Zack (guest, #37335)
[Link] (106 responses)
As far as I'm concerned, my machines aren't suddenly going to burn down during Jessie when I keep using sysvinit, and after Jessie I'll take a look at how far OpenRC has come along (And hopefully Debian will as well.)
And that's what loose coupling is all about as far as I'm concerned: keeping options open for a later re-evaluation of init systems that might actually cater to Debian's needs instead of the other way around.
Posted Feb 24, 2014 2:20 UTC (Mon)
by vonbrand (subscriber, #4458)
[Link] (14 responses)
It looks more like "let's see if Debian will take this seriously, nobody else did"...
Posted Feb 24, 2014 10:13 UTC (Mon)
by Zack (guest, #37335)
[Link] (13 responses)
And now, hypothetically, if you put Fedora, Ubuntu, and Suse on one side, and Gentoo and Debian on another side: what would you say the main difference between the two sides would be?
Posted Feb 24, 2014 13:11 UTC (Mon)
by mbunkus (subscriber, #87248)
[Link] (12 responses)
Posted Feb 24, 2014 13:31 UTC (Mon)
by Zack (guest, #37335)
[Link] (11 responses)
You make a good point however. One side generally needs sustained commercial viability to remain relevant, and it's easy to confuse commercial viability with proprietary interests, which are helped by one large uniform platform to build against.
Of course it's not likely to be all about Adobe or Oracle-db and games, and it might just be an unintended side effect of widespread systemd adoption, but it goes along with the "Sturm und Drang" mentality of some of its proponents (and developers), which prevents systemd from quietly and naturally (and more importantly, uncontested) arising as the default init system.
Posted Feb 24, 2014 13:59 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (10 responses)
Linux in general is helped by more uniformity of the Linux-kernel, or systemd, kind. Claiming that this is mostly for the sake of »commercial viability« or third-party proprietary software vendors is a bit strange. There is really no benefit whatsoever in every distribution inventing the »plumbing layer« over and over again the way it used to be necessary before systemd came along. If developers no longer need to waste time doing that sort of thing they have more time to dedicate to other tasks, of which there are still loads in every distribution. It is a win-win situation.
It does make sense for systemd to be the »default case«, and this in no way precludes people staying with System-V init, or even rolling their own bare-bones init scheme à la Busybox, for special applications – much like people are perfectly able to roll their own kernel for special applications. In general, however, no longer having to worry about issues like where exactly the system hostname is defined or how to figure out the status of terminal so-and-so can only be a good thing. It is worth pointing out that nobody who argues against systemd has so far advanced a technical argument as to why this sort of standardisation is a bad idea; they just seem to object to the fact that the standardisation happens at all, without actually justifying that position.
Posted Feb 24, 2014 17:02 UTC (Mon)
by javispedro (guest, #83660)
[Link] (9 responses)
It was never necessary to reinvent the "plumbing layer" before -- new distros that did not care just copied a existing one from another distro (often Debian or Ubuntu, or even Fedora).
This is an area where everyone wants to have its word and has been like that for the best of a decade or two. You should not be surprised that standardization is rejected (in the same way as when `rpm' was made LSB standard). E.g. I still remember initng (also readily ignored) which offered a extensible (plugins) init that was both event and dependency based. Even Fedora had a wiki page on the early days with ideas for a future init system based on D-Bus services and "launch on demand".
Such proposal actually resembled upstart more than it did resemble systemd, which basically appeared out of nowhere.
Posted Feb 24, 2014 17:28 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (8 responses)
I don't think using systemd as the plumbing layer precludes innovation. Many people don't appreciate the fact that systemd is actually a fairly modular framework that just happens to come in one big source tarball. It would be perfectly feasible for a distribution to replace one part of systemd by something better on a trial basis and fold worthwhile innovations back into the main codebase later.
By analogy, distributions don't seem to mind not differentiating on the kernel, either. There are some distributions that actually sponsor serious kernel development, but these usually have a policy of aggressively pushing their patches upstream; the idea of a »Red Hat kernel« or »Debian kernel« that includes innovative bits that no other kernel has and isn't going to get, and that motivates people to pick Red Hat over Debian or vice-versa, does not actually exist.
Finally, for Linux distributions there is ample room for differentiation left above the plumbing layer, which is probably much more gratifying from the point of view of addressing users – many of whom will probably not really care what their plumbing layer is like as long as it does the job, but may be quite passionate about »their« distribution's UI experience.
The problem with other standardisation efforts like the largely-stillborn LSB was that they usually meant extra work for distributions. One of the maxims of the Internet is »rough consensus and working code«, and while it was possible to get the consensus (sort-of anyway), the working code was left to the distributions to come up with (each on its own). The big difference is that systemd actually comes with the code that does the standardisation, and that allows distributions to save work rather than put extra effort in. Hence the buy-in to systemd was much more vigorous and widespread than the buy-in to LSB. (And the LSB RPM issue is a red herring – LSB didn't try to mandate RPM as the official packaging format for all Linux distributions, it made RPM the standard for the distribution of LSB-compliant software packages, which is not at all the same thing.)
Posted Feb 24, 2014 17:56 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
So any lsb package could easily be converted to and installed upon an apt-based system.
Cheers,
Posted Feb 24, 2014 22:57 UTC (Mon)
by javispedro (guest, #83660)
[Link] (6 responses)
One of the points raised during the Debian discussion was that Debian's existing binfmt `manager' was better (objectively more featureful) than the one in systemd, which was based on Fedora's. Because Fedora won't change for standarization reasons, Debian would be forced to switch to systemd's or just rip systemd's builtin one from the codebase. Just a few years ago it was still trivial to replace GDM's "shutdown" script with a simple bash script. I would gladly chose whichever distribution allows me to continue doing that, instead of "by UI experience". Please don't assume there's no differentiation left in the plumbing layer :( . And there are still distros out there innovating on the kernel side (e.g. Debian offers Hurd!, Gentoo offers framebuffer, hardened stuff, etc.) Sidenote: I already tried to be careful with the LSB RPM wording and thus my use of `a standard' instead of `the standard'. No discussion was intended.
Posted Feb 24, 2014 23:27 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (2 responses)
This is a lot less scary than it sounds. Since systemd is modular, the only thing you need to do is disable systemd-binfmt.service and enable Debian's binfmt support instead, which helpfully already comes with a systemd unit file. No ripping anything from any codebase involved.
Posted Feb 25, 2014 0:01 UTC (Tue)
by mchapman (subscriber, #66589)
[Link]
And if that's not good enough, you can even build systemd with --disable-binfmt. After all, isn't the choice of configure options the kind of decision package maintainers *should* be making?
Posted Feb 25, 2014 0:51 UTC (Tue)
by ermo (subscriber, #86690)
[Link]
@Anselm: Could you please stop being so damn well-informed and eloquent? You're ruining any chance of watching the discussion devolve into inane, yet highly entertaining and entirely unconstructive flamewars based on the notion that systemd/Red Hat/Lennart is evil (for a suitable definition of evil). P.S. I'm with Henry Ford on this one: You can have your init in any color as long as it's systemd.
Posted Feb 25, 2014 0:03 UTC (Tue)
by HelloWorld (guest, #56129)
[Link]
> And there are still distros out there innovating on the kernel side (e.g. Debian offers Hurd!, Gentoo offers framebuffer, hardened stuff, etc.)
Posted Feb 25, 2014 1:11 UTC (Tue)
by rahulsundaram (subscriber, #21946)
[Link] (1 responses)
Others have addressed the easy solution to the problem you are posing but I want to challenge this underlying assumption. Fedora frequently adopts new technologies and has a long history of throwing away home grown solutions in favor of the standardized components including for instance in the case of kudzu, various system-config-* tools, nash etc. Even systemd required adoption new conventions and configuration formats etc.
Posted Feb 25, 2014 1:38 UTC (Tue)
by jspaleta (subscriber, #50639)
[Link]
The Debian utility has a long history inside Debian, but it doesn't appear to have been picked up by Red Hat prior to Fedora, or by SUSE, or by Gentoo as a widely used helper to simplify initscripts. It appears that the more "standard" thing to do was to poke at the /proc entry inside of multiple initscripts instead of dropping config files into a location on package install for a common binfmt helper to parse. Debian's implementation for a helper doesn't seem to have cross-pollinated at all in the years prior to systemd adoption, for whatever reason.
Regardless, it seems like Debian maintainers have this sorted out and are going to disable systemd's binary by default. Which actually does make some sense for their upgrade path. Debian has sysvinit scripts in service built assuming binfmt-support's implementation and its config directory, so its not unreasonable for Debian to continue to assume their traditional service implementation in their packaging as a conservative approach to their upgrade path. I don't think any of the previous systemd adopters had to worry about the existence of binfmt-support package and its related service, as they all appear to just be replacing hardwired sysvinit script logic with something equivalent.
Posted Feb 24, 2014 2:31 UTC (Mon)
by hadrons123 (guest, #72126)
[Link]
FUD. Systemd upstream did not beg Debian for anything. They can survive on their own even if Debian have not chosen systemd.
Loose coupling = strangling the package maintainer with policy decision and forcing the maintainer to support defunct inits.
Ian has lost the init war now and he is trying to force the other DDs into supporting the sysvinit support, since he wants it. This is clear abuse of power forcing other people what they should and shouldn't in a voluntary project since you have CTTE membership. People tend to forget why this init decision for Debian came to CTTE, when you magically assume sysvinit is better.
Posted Feb 24, 2014 2:32 UTC (Mon)
by vonbrand (subscriber, #4458)
[Link] (87 responses)
All other distributions have opted for systemd. What makes Debian so special that it just isn't enough?
Posted Feb 24, 2014 3:24 UTC (Mon)
by mgb (guest, #3226)
[Link] (58 responses)
The Fedora plumbing we're starting to see dragged in with systemd is a serious downgrade.
Posted Feb 24, 2014 3:37 UTC (Mon)
by vonbrand (subscriber, #4458)
[Link] (57 responses)
Could you please elaborate? I've been using Fedora from the beginning, and have had few problems with its plumbing. Sure, there have been radical changes, but AFAICS Debian did go through much the same changes at roughly the same time with more or less the same sort of problems.
Posted Feb 24, 2014 4:27 UTC (Mon)
by mgb (guest, #3226)
[Link] (51 responses)
Posted Feb 24, 2014 8:10 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (49 responses)
Could you explain why a systemd-based Debian wouldn't be just as smoothly upgradeable as a SysV-init based Debian?
Posted Feb 24, 2014 8:45 UTC (Mon)
by nim-nim (subscriber, #34454)
[Link] (48 responses)
Plus the "you should reboot to help software" attitude does not help much.
Posted Feb 24, 2014 9:01 UTC (Mon)
by heftig (subscriber, #73632)
[Link] (25 responses)
Systemd would be pinned at a certain version (plus backported fixes) for the entire release. You would only get a major systemd upgrade as part of a release upgrade, which comes with loads of other upgrades such as a new kernel.
You'd have to be crazy not to reboot.
Posted Feb 24, 2014 15:53 UTC (Mon)
by mgb (guest, #3226)
[Link] (24 responses)
The only serious pothole affecting Debian upgrades in recent years was of course udev. Udev incompatibilities doubled the amount of work involved in upgrading Debian from one major release to the next.
But now Debian has systemd - udev on steroids. Systemd's plumbing warts and interference with well-behaved packages are already hurting Debian.
Posted Feb 24, 2014 16:04 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (18 responses)
You must be running a Debian that is significantly different from mine. I've been upgrading loads of Debian systems ever since way before udev even existed, and I have yet to experience even one upgrading snag that was attributable to udev.
Posted Feb 24, 2014 17:13 UTC (Mon)
by mgb (guest, #3226)
[Link] (17 responses)
Booting the 2.6.26 kernel from lenny with the udev from squeeze may result in a failure to correctly assign names to network devices, and will also fail to apply certain additional permissions to block devices (such as access by the disk group). The software itself will appear to be working, but some rules (for example, network-based rules) will not be loaded properly. It is therefore strongly recommended that you upgrade the kernel on its own at this point, to ensure a compatible kernel is available before upgrading udev.
Posted Feb 24, 2014 17:34 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (16 responses)
So? In my book, upgrading a Debian system means reading the release notes and following what they say. So you upgrade the kernel first. Problem solved.
Also, please explain how the issue you cited is udev's fault, other than by virtue of its mere existence. You could argue that without udev this problem wouldn't occur in the first place, but on the other hand udev is so useful in day-to-day life that paying attention when doing a stable-Debian upgrade (something that happens once every two years or so) is probably worth our while.
Posted Feb 24, 2014 17:56 UTC (Mon)
by mgb (guest, #3226)
[Link] (15 responses)
Systemd is far more intrusive and disruptive than udev.
Posted Feb 24, 2014 18:07 UTC (Mon)
by HelloWorld (guest, #56129)
[Link] (14 responses)
Posted Feb 24, 2014 18:24 UTC (Mon)
by mgb (guest, #3226)
[Link] (13 responses)
Systemd distros will migrate to Fedora plumbing elements whenever systemd so dictates - a huge loss of Debian functionality.
And systemd have further made it very clear that they will continue to "standardize" additional plumbing whenever they feel like it - leaving Debian struggling under an endless deluge of systemd bikeshedding.
Posted Feb 24, 2014 18:43 UTC (Mon)
by rahulsundaram (subscriber, #21946)
[Link]
I have already pointed this out to you but systemd is not carrying over Fedora plumbing at all. Fedora moved to the things that systemd standardized on, many of which were adopted from Debian and none were adopted from Fedora!
Posted Feb 24, 2014 18:44 UTC (Mon)
by anselm (subscriber, #2796)
[Link]
I don't think this is in fact true. Various parts of systemd's plumbing have been patterned on Debian even before Debian decided to adopt systemd as its default init, because the Debian approach was better than what Fedora had at the time.
I think in the long run the plumbing will gravitate to whatever is best for the job at hand. If Debian has a better approach to some plumbing issue than Fedora, it ought to be possible to convince the systemd developers that this is in fact the case, and nudge systemd towards the Debian way of doing things. They're not stupid, after all, and they're interested in technical excellence, not in making everything Fedora. In other cases whatever Fedora does may actually be superior, and it is entirely appropriate to base systemd's plumbing on Fedora. Or SUSE. Etc.
Anyway, more Debian involvement in systemd means that Debian's approaches and wishes will be that much better understood by the systemd community, which is to everybody's benefit given that Debian, like systemd, is committed to technical excellence.
Posted Feb 24, 2014 18:53 UTC (Mon)
by HelloWorld (guest, #56129)
[Link] (10 responses)
> Systemd distros will migrate to Fedora plumbing elements whenever systemd so dictates - a huge loss of Debian functionality.
> And systemd have further made it very clear that they will continue to "standardize" additional plumbing whenever they feel like it - leaving Debian struggling under an endless deluge of systemd bikeshedding.
Posted Feb 25, 2014 1:19 UTC (Tue)
by rahvin (guest, #16953)
[Link] (9 responses)
I have no idea how anyone could feel that way but it's clearly her/his point of view and it's rather pointless to even discuss facts because the facts really aren't relevant to the point he/she is trying to make, which is Redhat is evil. You'd have better luck trying to have a philosophical discussion with an inanimate object.
Posted Feb 25, 2014 4:44 UTC (Tue)
by mgb (guest, #3226)
[Link] (8 responses)
Fedora is different. It works better for some people. Debian works better for some people.
Replacing Debian plumbing with Fedora/systemd plumbing is a serious loss.
Posted Feb 25, 2014 5:56 UTC (Tue)
by rahulsundaram (subscriber, #21946)
[Link] (2 responses)
To be honest, you want to call that Fedora/RHEL/Mageia/openSUSE/Arch plumbing instead of pretending it is Fedora specific.
Posted Feb 25, 2014 6:07 UTC (Tue)
by mgb (guest, #3226)
[Link] (1 responses)
Nobody is claiming there's anything unique about Fedora plumbing.
However Debian/Ubuntu/etc plumbing is different, many but not all people find it better, and replacing it with Fedora/systemd/etc plumbing is a massive loss.
Posted Feb 25, 2014 6:23 UTC (Tue)
by rahulsundaram (subscriber, #21946)
[Link]
Ironically, that is a big strawman by itself.
" Nobody is claiming there's anything unique about Fedora plumbing."
If you don't mean to imply that, you should avoid writing Fedora/systemd that gives that impression you are trying to equate these two projects. If you want to attach distros to the systemd project, then you want to list all the distros that use systemd instead of singling out Fedora.
Posted Feb 25, 2014 8:48 UTC (Tue)
by anselm (subscriber, #2796)
[Link] (2 responses)
Which is why nobody is proposing to do this, at least not in a way that does cause »serious loss«.
First of all, »systemd plumbing« is not necessarily »Fedora plumbing«. Considerable parts of »systemd plumbing« actually derive from Debian, or from other Linux distributions.
Secondly, in many cases it doesn't actually matter. For example, whether a system's host name is stored in /etc/hostname, /etc/HOSTNAME, or /etc/sysconfig/hostname is quite immaterial, and it is hard to argue that one approach is technically superior to another. Which is why the standardisation that systemd catalyses is overdue and very welcome.
There are cases where it makes sense for Debian to stick with »Debian plumbing«, e.g., for compatibility or because the Debian approach offers more features than the systemd default. In these cases it is generally easy to disable/mask or override the systemd default, with a view to possibly integrating whatever Debian does into upstream systemd if it is of general interest.
I'm personally confident that the systemd developers and the Debian systemd maintainers are going to come up with a way of providing systemd for Debian that will let us take full advantage of the stability improvements and new features that systemd enables. There will not be »serious loss«. Two or three years from now we will look back and wonder what all the fuss was about.
Posted Feb 25, 2014 9:41 UTC (Tue)
by bangert (subscriber, #28342)
[Link]
And that even though Debian had not committed itself to systemd at that point. I take this as a clear indication of the systemd developers being committed to technical excellence and their willingness to cooperate...
... or, if that does suit your world view, it could be an effort to bribe Debian into adopting systemd.
Posted Feb 25, 2014 14:31 UTC (Tue)
by mebrown (subscriber, #7960)
[Link]
Posted Feb 25, 2014 14:28 UTC (Tue)
by mebrown (subscriber, #7960)
[Link]
Asserting this over and over does not make it true and moves my mental slider for your comments further into troll territory every time you repeat the same thing without offering anything new.
Posted Feb 25, 2014 15:00 UTC (Tue)
by Chousuke (subscriber, #54562)
[Link]
I've been running systemd as a default init for a long while on my Debian laptop now (and finally uninstalled sysvinit a shorter while ago when the package dependencies no longer prevented it) and it's been working perfectly.
Posted Feb 24, 2014 16:12 UTC (Mon)
by palmer_eldritch (guest, #95160)
[Link]
Posted Feb 24, 2014 16:33 UTC (Mon)
by fandingo (guest, #67019)
[Link]
Posted Feb 24, 2014 18:29 UTC (Mon)
by rodgerd (guest, #58896)
[Link] (2 responses)
Really. I guess that's why the libc->glibc transition resulted in me having to reinstall Debian boxes from scratch, because of Debian's perfect record on smooth upgrades. And when I couldn't boot some servers after the MD tool changeover left me with non-starting software RAID arrays, that was an exemplar of Debian's perfect upgrade process, too, was it?
Posted Feb 24, 2014 19:59 UTC (Mon)
by malor (guest, #2973)
[Link]
And, fer chrissake, the glibc transition was fifteen years ago. You could probably let that go. I don't think any distro did well with that particular mess. The conversion from a.out to ELF, even earlier, was also very disruptive. Debian has, pretty consistently, been the least painful distro for upgrades, but least painful != painless.
If you believe that Debian sucks horribly at upgrading, why on earth would you think making it worse would somehow be a good idea?
If your argument is that it won't, in fact, be worse, because of a bad experience you had a decade and a half ago, that's not very persuasive, either.
Posted Mar 1, 2014 6:48 UTC (Sat)
by k8to (guest, #15413)
[Link]
Really everything was pretty fubar around that transition point, even without upgrades, so I wouldn't put too much weight on that scenario from 1997 or so.
Posted Feb 24, 2014 9:21 UTC (Mon)
by anselm (subscriber, #2796)
[Link]
Debian being Debian, I think we can rest assured that upgrading systemd from one stable version of Debian to the next will be quite well tested.
Posted Feb 24, 2014 11:23 UTC (Mon)
by vonbrand (subscriber, #4458)
[Link] (14 responses)
Any examples? Or is this just extrapolating from "migrating will hurt, so upgrades must be painful too"? It had it's problems early on, now it just works for me. One version after the other, no issues at all for me on Fedora.
Posted Feb 24, 2014 11:37 UTC (Mon)
by nim-nim (subscriber, #34454)
[Link] (13 responses)
It seems to get better now but maybe that's because there are fewer systemd releases now.
And, I've read at least some of the systemd authors used to never test in enforcing mode so systemd was broken by default on release before selinux policy is fixed by other people (don't know about the situation right now, I cross fingers it's all past).
Posted Feb 24, 2014 11:45 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (2 responses)
This state of affairs will presumably profit from the enhanced exposure that systemd will get in Debian. This will lead to systemd being exercised in more real-world setups, and more problems being detected and ironed out.
And it's not as if System-V init didn't have any problems at all; the problem there is that nobody is in charge, and that every distribution needs to fend for itself (and the setup itself is pretty brittle, especially in corner cases).
With systemd, at least there is a cross-distribution development community which will help ensure that every distribution profits from enhancements made under the auspices of another distribution. This works for the Linux kernel, so why shouldn't it work in this case? What's not to like?
Posted Feb 24, 2014 12:58 UTC (Mon)
by vonbrand (subscriber, #4458)
[Link] (1 responses)
Don't try to paint Debian as a trailblazer in exercising systemd in new scenarios, that train left some three years back.
Posted Feb 24, 2014 13:05 UTC (Mon)
by anselm (subscriber, #2796)
[Link]
True, but chances are that, with systemd deployed on more Debian machines, somewhere something will break, and be fixed, and systemd (and Debian) will be the better for that. This is just how things work with free software.
People often accuse the systemd developers of »not taking Debian's needs into account«. Regardless of whether this is in fact true or not, the obvious way to fix this is to become more active in systemd development on Debian's behalf. The more systemd is used within Debian, the more enhancements and bug fixes will be contributed to systemd from Debian, and the more influence Debian will have on systemd development. Again, this is just how things work with free software.
Posted Feb 24, 2014 12:27 UTC (Mon)
by vonbrand (subscriber, #4458)
[Link] (9 responses)
My Fedoras run SELinux enforcing all the time (since before systemd, in fact). Never seen boot hangs due to this. Never seen LVM related trouble either (but no RAID or encrypted filesystems on any of them). Yes, I know that the plural of "anecdote" isn't "data," but still.
Posted Feb 24, 2014 18:20 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (8 responses)
UNATTRIBUTABLE STORIES are anecdotes. First-hand accounts are datum points. And ignoring datum points is what gets scientists accused of either (a) fabricating evidence or (b) ignoring inconvenient evidence. Either charge if proven is - and should be - fatal to any scientific argument.
Cheers,
Posted Feb 24, 2014 18:35 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (7 responses)
On the other hand, not all types of »evidence« are the same. One person claiming they briefly saw something fuzzy in the distance that might have been a Sasquatch is different from one person bringing an actual live Sasquatch in a cage to a convention of field zoologists. It is a lot easier (as well as usually more appropriate, Occam's razor being what it is) to ignore the first than the second.
In the same vein, somebody claiming that they once had some sort of terrible problem with software package X but they don't quite remember the details is different from somebody demonstrating an easily reproducible sequence of steps that reliably makes the current version of software package X crash – especially if the person in question is on record as preferring software package Y which is a direct competitor to X. The latter is evidence but the former is FUD.
Posted Feb 24, 2014 18:44 UTC (Mon)
by mgb (guest, #3226)
[Link] (5 responses)
Tens of thousands of people with unreproducible pulseaudio problems signify an engineer who designs clever but fragile software for a non-existent perfect world.
Posted Feb 24, 2014 19:00 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (2 responses)
Tens of thousands of people with unreproducible Pulseaudio problems eventually lead to those problems becoming reproducible, being traced to buggy ALSA drivers, and being fixed there (rather than in Pulseaudio) as is proper. Pulseaudio is now quite stable.
What would you prefer, Pulseaudio working around the driver bugs? I know what I'd want: a simpler Pulseaudio and less-buggy ALSA drivers, thank you very much.
Posted Feb 24, 2014 19:25 UTC (Mon)
by sfeam (subscriber, #2841)
[Link] (1 responses)
I can hear you thinking "And this is relevant how?". Well, it serves as an example of how difficult, or at least annoying, it is to have to work around faults in a subsystem that has become too tightly integrated. I have had no problems with systemd myself, but I sympathize with those who worry about the consequences of allowing it to subsume more and more system functions.
Posted Feb 25, 2014 2:10 UTC (Tue)
by ermo (subscriber, #86690)
[Link]
"(...) it serves as an example of how difficult, or at least annoying, it is to have to work around faults in a subsystem that has become too tightly integrated. I have had no problems with systemd myself, but I sympathize with those who worry about the consequences of allowing it to subsume more and more system functions." To a desktop user, working sound reproduction is considered a basic necessity, i.e. 'must-have'. To a server admin, sound reproduction might not be considered a basic necessity, but merely 'nice-to-have'. To a desktop user, a working init etc. system is a basic requirement. To a server admin, a working init etc. system is a basic requirement. In other words, a working init system is 'must-have' in both cases. You can probably see where this argument is going: Comparing the two on equal terms is perhaps slightly misleading if only for the fact that there is a bigger group of people who have a vested (commercial) interest in the init system just working. It thus seems reasonable to suggest that, if a problematic edge-case is discovered in systemd, there is likely to be much more pressure to get it fixed ASAP than if PA needs to be restarted every now and again on your box, which (lest we forget) is running a desktop OS which only has a market share of a couple of percent or so if we're being generous. Unless I'm mistaken, the majority of the Internet runs on Linux-based servers? That said, I haven't noticed any issues with PA on my machines in, like, forever; my personal impression is that it tends to "Just Work™" regardless of distribution these days.
Posted Feb 24, 2014 19:00 UTC (Mon)
by HelloWorld (guest, #56129)
[Link]
Posted Feb 24, 2014 19:02 UTC (Mon)
by pizza (subscriber, #46)
[Link]
The plural of anectdote isn't data, but "tens of thousands" random points of noise aren't terribly useful as data, especially when contrasted against a far greater larger sample set of folks who had a greatly improved experience.
Meanwhile. Speaking as an engineer who designs stuff for the real world, you need reproducible test cases in order to take action, less you break other crap in the process and possibly/probably not solve the original problem. Whatever it may have been.
Posted Feb 24, 2014 20:45 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
Yup. But the advantage of a first-hand account is that you can go back and verify it. Okay, you might not be able to repeat it (the sciences of eg biology and astronomy often suffer from this where they can only observe, not experiment), but if you have a reliable witness or account then it is extremely dangerous to ignore it.
At an absolute minimum you need to take it seriously and explain it.
Cheers,
Posted Feb 25, 2014 15:42 UTC (Tue)
by mbt (guest, #81044)
[Link] (5 responses)
This comes up against the fact that systemd is so grossly huge and all-encompassing. Every one of those "modular" components is subject to having bugs discovered in it; having all those components together in one package only increases the probability there will have to be a patch to the whole package.
Right now, in a sane system, if there is a CVE for the cron, all one needs to do is install the updated cron and keep running. If the CVE instead applied only for the cron component of systemd, you have to replace all of systemd.
Sorry, security updates don't wait for distribution's release schedules. And given the rollicking pace of systemd development and what appears to be no provision for stable-branch releases in the systemd upstream, upgrades are going to be fun.
Handy thing that systemd is faster for rebooting. You'll need them more often and they will be more interesting.
Posted Feb 25, 2014 16:02 UTC (Tue)
by anselm (subscriber, #2796)
[Link] (4 responses)
It is by no means clear that systemd upgrades will require a reboot. Systemd's PID 1 executable has a facility where it can serialise its internal state to disk, reexecute itself, and continue where it left off with all pre-existing sockets remaining open.
It is also very likely that large parts of systemd can be updated without actually having to touch PID 1 in the first place.
Posted Feb 26, 2014 22:53 UTC (Wed)
by viro (subscriber, #7872)
[Link] (3 responses)
Just call pipe(2), fork, have parent call execve(), notice that it had been asked to re-exec itself and that pipe is there, then have child serialize the state and feed it into pipe, with parent fetching it from there.
Not much harder than disk variant and a _lot_ more robust; there's a whole lot of failure modes that disappear that way. Sure, you need to block all signals before forking, but you need it for other reasons anyway...
Posted Feb 27, 2014 3:40 UTC (Thu)
by tao (subscriber, #17563)
[Link] (2 responses)
Posted Feb 27, 2014 4:25 UTC (Thu)
by raven667 (subscriber, #5198)
[Link]
Posted Feb 27, 2014 4:51 UTC (Thu)
by viro (subscriber, #7872)
[Link]
Don't read into that comment anything other than a surprise at the decision to use an on-disk file for passing the state. All software is full of WTFs of that kind and the life is too short to fix ones in the stuff one doesn't use. I have more than enough fun with the kernel and with the userland I do use, TYVM. If I run across something of that kind in e.g. OpenBSD kernel, or djbdns, I'll probably comment on it and move on. Same as with systemd. Has nothing to do with my (lack of) liking of their authors, before anyone goes into that - if I run across something fishy in glibc or openssh, I *will* do more than commenting, no matter how little I am fond of Ulrich and Theo resp.
Same reason why I won't contribute to GNOME or emacs - I don't use either, they are not within 0.01% of programs that are pleasant to read, I'm not interested in developing them and it's not even what I'm paid for. Bugs in e.g. nvi are something I will deal with (and had done so in the past), something similar in aforementioned emacs... apt-get remove emacs\* solves them all nicely, as far as I'm concerned.
Posted Feb 27, 2014 7:42 UTC (Thu)
by AdamW (subscriber, #48457)
[Link]
Posted Feb 24, 2014 8:58 UTC (Mon)
by oldtomas (guest, #72579)
[Link] (4 responses)
Gaah. Way to argue.
I've been using SysV init from the beginnings (I know, that's a long time!) and have had few problems with its configurability, stability, etc.
And now?
Posted Feb 24, 2014 10:23 UTC (Mon)
by jonnor (guest, #76768)
[Link] (1 responses)
Posted Feb 24, 2014 17:45 UTC (Mon)
by oldtomas (guest, #72579)
[Link]
Ain't it?
> The post asked you to elaborate on your claim that systemd-based plumbing was more fragile on upgrade.
First: the post didn't ask *me*, as I wasn't the OOP. Anyway.
Second: my issues with systemd are a tad different. They are being expounded all over the place, but the more strident systemd proponents just chose not to read them (there are more even-headed ones, thankfully).
And third: I was taking issue with the pattern "I've been using X and haven't had any problems with it" -- a pattern much derided by the (again) more strident systemd proponents. So I stand by my comment: I selected the quote on purpose, and I don't think I misrepresented anything.
Posted Feb 24, 2014 10:49 UTC (Mon)
by vonbrand (subscriber, #4458)
[Link]
I have used SysV init style since it's beginnings (before Linux even existed), and while it is much better than what came before, I just don't want to go into the many, many times it got the system into weird states that only a reboot (sometimes of the entire lab) would cure. Too varied and too painful.
Posted Feb 24, 2014 12:54 UTC (Mon)
by vonbrand (subscriber, #4458)
[Link]
I have used SysV init style from it's beginning, since before Linux. On a variety of systems, Solaris, SCO Unix, various Linux distributions, an AIX machine, and probably a few others I've forgotten right now. The TL;DR version is that this is almost as non-portable as humanly possible. Next to impossible to configure (but Fedora/Red Hat setups cleaned that up so it was manageable, but those were distribution-specific...). The LSB mandate for init script headers was also a large step forward. Migrating even a simple service from one system to the other meant (1) read and understand a init script of a hundred lines, mostly boilerplate with little reason for this specific case, (2) chase down shell code libraries of a thousand or so lines to look up what exactly some strange functions do (after wasting time looking for them as commands), (3) trawl through manpages to understand the meaning of some exotic flags to common (or not-so-common) utilities. And then the real fun of redoing all this in a wildly different setup just started: (4) find a similar service whose init script can be used as template, (5) understand it and modify it to fit, (6) again reverse engineering of shell libraries, (7) manpages for non-GNU utilities to see how to get things done, (8) workarounds for non-existing/different/broken commands, (9) endless fun with shell differences. (10) is see where to fit in in in the rigid start/stop order (luckily most of the time this is just slapping it on at the end, as nothing else should depend on it). Then (11) try starting/stopping/restarting (if the target setup even allows that...). (12) is to set it up so it is started/stopped in the right runlevels (no, not all systems have the ntsysv(8) helper, runlevels vary in their definition, ...). Finally (13) reboot and hope for the best. No real tracing/debugging available, so it is fire and cross your fingers.
Posted Feb 24, 2014 9:24 UTC (Mon)
by dakas (guest, #88146)
[Link] (21 responses)
Posted Feb 24, 2014 10:27 UTC (Mon)
by ovitters (guest, #27950)
[Link] (19 responses)
Right, racism, theft, murder. Don't be amazed if you're not taking seriously on LWN with such an emotional discussion style. I suggest having a look at http://slashdot.org.
Posted Feb 24, 2014 18:28 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (18 responses)
Your post makes you seem an espouser of the philosophy "the tyranny of the majority".
Whether intentional or not, it is an unfortunate fact that the actions of the majority feel oppressive to a minority. If you can't see that, then you are an oppressor. It's that simple. (Fixing it is a lot more complicated, I agree. That can be NP-hard ... :-(
And yes, he did use emotive language. Unfortunately, usually that is the only language that manages to open eyes :-(
Cheers,
Posted Feb 24, 2014 22:52 UTC (Mon)
by ovitters (guest, #27950)
[Link] (17 responses)
I think you should go away from this site and move over to Slashdot. How's that opening eyes? I think you're trolling, and the other person as well. Being purposely emotional is not acceptable. I already said to go to Slashdot.
See how we're not talking about anything other than the emotional language? How's this helping?!?
Posted Feb 25, 2014 0:43 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (16 responses)
And as someone who's been a registered reader of lwn for a lot longer than you, I would have thought the odds were stacked far more in favour of you being a troll than me.
At the end of the day, this IS an emotive issue. Let me ask a provocative question - are you human? Because if you refuse to accept that people have emotions, you're not! Actually, it's pretty clear you are, because the OP used emotion-inducing words, and you responded.
More to the point, imho he was simply describing the natural condition. If you don't like his choice of words, you are simply wearing a veneer of civilisation. How does the old saw go? "Civilisation is only three square meals away from barbarism"? Has humanity really got away from the reality he described? Or have we just swept it under the carpet?
People have emotions. We like to *pretend* we are civilised. If you're not prepared to accept that other people are human, you are de-humanising yourself, and I'm sorry to say but that's where I think you are going... On the other hand, if you accept the reality of the human condition, then it becomes a lot easier to do something about it.
Cheers,
Posted Feb 25, 2014 10:01 UTC (Tue)
by ovitters (guest, #27950)
[Link] (15 responses)
I responded exactly because it is emotional and useless. You're pretending it is a good thing. Again: this discussion is going nowhere.
He's talking about racism. You're arguing it is a good thing. I don't accept that at all. You're putting in a lot of words, but equating some technical thing with racism? Yeah, get lost. It is not acceptable behaviour. I won't tolerate it. It is not going to be something you can turn around and claim it is my problem. I find you asserting that it is part of civilization? That's based on social rules.
If you cannot win on an argument itself, then yeah, this emotional discussion style is I guess something you'd appreciate. I think: get lost.
Posted Feb 25, 2014 11:16 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (14 responses)
PLEASE go back and read dakas original post. He was saying that if the majority are allowed to trample over the minority then we are all the poorer - and more importantly that if we DO NOT LOOK OUT FOR THE MINORITY then we will let that happen.
"First they came for sysvinit and ovitters didn't speak out. Then they came for the BSDs and ovitters didn't speak out. Then they came for the HURD. And when they came for Gnome, there was no-one left to speak out for ovitters".
And that is what neither dakas nor myself would like to see happen!
Okay, I'm not bothering to speak out because I think most of the arguments are false, anyway, but seriously, if you make yourself deliberately blind to what is going on, you are complicit. Sorry if you don't like dakas' lanmguage, but he is simply accepting the reality that is the human condition. Groupthink and the herd mentality are real, they affect US just as much as anyone else, and if you think they don't apply to you then you are opening yourself up to brainwashing and mindless oppression (as in, you will perpetrate it, not be the victim).
Look out for the weaker people - you never know when you will join their ranks.
Cheers,
Posted Feb 25, 2014 13:05 UTC (Tue)
by cortana (subscriber, #24596)
[Link]
Posted Feb 25, 2014 13:24 UTC (Tue)
by anselm (subscriber, #2796)
[Link] (11 responses)
This is a terrible kind of analogy. You know where that quote originally comes from, right? I'll let you in on a secret: Nobody is »coming for« sysvinit, the BSDs, the HURD, or GNOME to cart them off to a concentration camp, never to be seen again. These pieces of technology are going to stick around for exactly as long as there are people who are actively interested in them to a point where they spend the effort to keep them going. If the projects disappear it is precisely because nobody can be bothered to work on them any longer, and there are usually reasons for that sort of thing – obsolescence, uselessness or simply the arrival of a better, faster, or otherwise superior solution. Of course projects such as these hardly ever go away completely – there are probably people somewhere out there running TOPS-10 on a PDP-10 emulator, and more power to them – but they need to be interesting to however thin a slice of the community in order to stay around.
Free-software projects don't have human rights, and there is no moral obligation on the part of the community to look out for them if they can't fend for themselves by attracting enough developers to be viable. In particular, if you're not prepared to roll up your sleeves and pitch in on behalf of your favourite free-software project, don't whine if nobody else wants to do for you. You don't get to decide how other people spend their time (unless you sign their paycheck, anyway).
Posted Feb 25, 2014 13:28 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
/me looks around fearfully.
Posted Feb 25, 2014 14:03 UTC (Tue)
by Zack (guest, #37335)
[Link] (9 responses)
Not to speak of the promises of the great resurgence of the mainstream "Linux" push because now we have "One Kernel, One Init, One System."
And then, as icing on the cake, when asking questions about how decisions are taken and implemented on the mailing list, you often gets reminded that you simply might not understand the Teutonic/German way of interacting as is prevalent on the mailing lists.
None of that has anything to do with systemd or its quality of course, but I can't help but find these tidbits unintentionally humourous, in a Charlie Chaplin satire kind of way.
Posted Feb 25, 2014 14:11 UTC (Tue)
by HelloWorld (guest, #56129)
[Link] (7 responses)
Posted Feb 25, 2014 18:48 UTC (Tue)
by rodgerd (guest, #58896)
[Link]
I can only assume people who refuse to use software written by people with abrasive personalities have not only abandoned systemd, but Linux, glibc, and openssh as well.
Posted Feb 26, 2014 8:01 UTC (Wed)
by dgm (subscriber, #49227)
[Link]
Posted Feb 26, 2014 23:25 UTC (Wed)
by malor (guest, #2973)
[Link] (1 responses)
I get no such sense from Lennart.
Posted Feb 26, 2014 23:31 UTC (Wed)
by jake (editor, #205)
[Link]
Have you spoken to Lennart or seen him speak? I think there is a "core of fundamental good humor" there too, personally. We don't always see eye to eye, but Lennart is not just a "jerk" by any means.
just another perspective ...
jake
Posted Feb 27, 2014 5:32 UTC (Thu)
by dlang (guest, #313)
[Link] (2 responses)
Lennart fights for the one true way, and anyone who don't like it needs to shut up and get with the program.
this basic attitude is very different.
Posted Feb 27, 2014 14:21 UTC (Thu)
by anselm (subscriber, #2796)
[Link] (1 responses)
I think this is a conspiracy theory. Linus is trying to make Linux the best operating system it can be. Linus does not "fight for the ability of the user to choose to move away from Linux". Linus does not work on BSD, Solaris, OS X, or Windows, simply so Linux users can have alternatives to Linux. These exist because other people actively prefer them to Linux, to the point where it is worthwhile for them to go to the trouble of keeping them around. If Microsoft suddenly decided to base future versions of Windows on the Linux kernel, Linus would for sure not try to convince them otherwise just to keep Linux users' options open.
And exactly how does Lennart, by doing for systemd exactly what Linus does for Linux, namely trying to make it the best init system for Linux it can be, take away your option to stick with System V init, inetd, cron, syslogd, etc. for as long as you like, if you actively prefer them? How are distribution makers coerced to jump onto the systemd bandwagon against their better judgment? How are developers of background services forcibly brainwashed into believing that systemd's features may make their software simpler, more secure, and more efficient? Isn't systemd just as much of an open-source program as the Linux kernel, such that people can decide at some point that Lennart has gone off his rocker and they don't trust him any more, and take further development into their own hands?
It's not the fault of Lennart and his colleagues (other than by doing good work on systemd) if systemd is so convincing that most mainstream Linux distributions have decided they want to make it their default init system. If anything it is SysV init etc.'s fault for sucking so much in comparison that many people (and especially people in charge of distributions, who are the ones who matter most in this game) believe systemd is the better long-term option. Lennart does not have magical powers to make everybody bend to his will; if systemd is becoming the new standard it is on its technical merits and not through conspiracy. The Debian TC vote only emphasises this.
Posted Mar 3, 2014 6:38 UTC (Mon)
by dlang (guest, #313)
[Link]
Linus also rants about the need for new features to default to "off", that no new feature is worth hurting existing users over, and that the users (i.e. admins) need to have the options available to them to not do something that the developers think is neat and important.
Systemd development seems just the opposite, they know better than the users what's important, don't use systemd in any way other than the one they intend you to, etc.
Posted Feb 25, 2014 14:28 UTC (Tue)
by anselm (subscriber, #2796)
[Link]
Linus Torvalds, Lennart Poettering, et al. do not get to dictate to you which kernels or configurations you are allowed to find desirable or relevant. If you want to use FreeBSD or the HURD, great, nobody is telling you no. On the other hand you don't get to dictate to them what they ought to consider desirable or relevant – which is fair enough – so if you want systemd on FreeBSD and they don't, they're not going to be the ones who do the work. Again, that is fair enough.
The nice thing is that all the code is freely available so you can scratch your own itch without having to talk Lennart or Linus into scratching it for you. And as we said, no software package or configuration is »irrelevant« as long as there are people interested in supporting it. The problem is really some people's sense of entitlement which apparently suggests to them it is OK to demand that others work on their behalf for free.
Posted Feb 25, 2014 18:50 UTC (Tue)
by rodgerd (guest, #58896)
[Link]
Posted Feb 24, 2014 10:37 UTC (Mon)
by anselm (subscriber, #2796)
[Link]
Nobody is telling the developers of Debian GNU/HURD and Debian GNU/kFreeBSD to stop what they're doing. The situation remains exactly the same as it was before; there are people who are interested in spending time on porting Debian to alternative kernels, and these people will be expected to do most of the work. They in turn do not get to tell the rest of the Debian developer community what they should or should not do. This is how free software generally works; you scratch your own itch.
It should also be pointed out that it is a fallacy to believe that currently all of Debian runs on the FreeBSD or HURD kernels, and that systemd will be an exception because it won't. Many other packages also don't work on the alternative kernels, so it is not as if Debian/HURD or Debian/kFreeBSD offered users the same experience as Debian/Linux even now. In that sense they remain experimental, »fringe« versions of the distribution; they are proofs of concept to see whether porting Debian will even work, not necessarily the sort of reliable workhorse people are expecting when they think »Debian GNU/Linux«. As such they should be put firmly in perspective.
Having said that, Debian package maintainers are encouraged by Debian policy to address portability problems that lead to bugs in their packages on Linux architectures other than the ones they're using themselves, and on non-Linux platforms. They are, however, not required to go to the trouble of actively testing their packages on all architectures and kernels supported by Debian or to engage into large development projects in order to port packages whose upstream versions are not portable; we just want them to listen to relevant bug reports, and evaluate and possibly incorporate suggested portability fixes.
In the init system context, this means that, while package maintainers will be asked to support the default init system on their platform, they should also be open to bug reports from people who are interested in making the packages in question run with other init systems. In other words, on a very basic level a System-V init script is currently sufficient to make a package work on all Debian platforms (with or without systemd). A package maintainer will be encouraged to package an equivalent systemd unit file but they will not be forced to come up with it themselves unless they want to.
Posted Feb 24, 2014 10:27 UTC (Mon)
by Zack (guest, #37335)
[Link] (5 responses)
A "install once, upgrade flawlessly for the next decade" policy.
An open inclusive approach to alternatives to allow for future developments and satisfy minority operating system needs.
Little or no allowance for changes that would ease the installation of proprietary software.
Posted Feb 24, 2014 11:16 UTC (Mon)
by vonbrand (subscriber, #4458)
[Link] (3 responses)
Except for the "two non-Linux kernels" (which isn't much more than the hobby of two tiny groups), this describes most distributions. Debian isn't anything special, really.
Posted Feb 24, 2014 12:50 UTC (Mon)
by Zack (guest, #37335)
[Link] (2 responses)
except one if them is a officially released and supported architecture, and so far from being "barely usable" and "toy" that most people running GNU/Linux would hardly notice any difference if you secretly swapped it for GNU/kFreeBSD.
>>A "install once, upgrade flawlessly for the next decade" policy.
> this describes most distributions.
No, that's just plain nonsense.
I've witnessed no other distribution manage new release upgrades so flawlessly that a re-install was never necessary or simply easier to perform. Even if some of them have caught up regarding system wide upgrades, they do not have a track record going that far back.
As for open inclusive approach. The main architect of systemd is the record for speaking disparaging about other operating systems, other kernels, competing implementations, everything that doesn't fit with his view of how things should be done. Adopting that software is adopting those policies, which are definitely not "open" and "inclusive" by any definitions of the words.
>>Debian isn't anything special, really.
Well, it used to be. Incidentally you mention "My Fedoras" in an earlier comment; you do actually run Debian somewhere, right?
Posted Feb 24, 2014 13:04 UTC (Mon)
by vonbrand (subscriber, #4458)
[Link]
Not currently. Tried it a few times, but stable was just much too stale for my tastes; and if I want the exitement of running an experimental branch, I'd want it to have latest stuff too. Besides, some of the configuration tools just felt too weird (I'm a long-time Red Hat/Fedora user; I'm not saying they are better or worse, just different).
Posted Feb 24, 2014 15:32 UTC (Mon)
by ewan (guest, #5533)
[Link]
That's rather unfair. I'd characterise his position as being more that Linux users should not be held back from making full use of the advantages that Linux offers over other kernels. If other kernels which to catch up and offer similar features, then that's fine - he just doesn't care either way.
Frankly, moving to systemd for Linux should be a good thing for the other kernels too - they either need to have their own plumbing layers that deliver the same benefits as systemd does on Linux, or equivalent kernel interfaces to those systemd uses on Linux. Either case is better than the woolly mess that everyone has at the moment.
Posted Feb 24, 2014 11:31 UTC (Mon)
by anselm (subscriber, #2796)
[Link]
The goals of the Debian project are set out in its Social Contract, which does not contain an explicit commitment to making Debian available on non-Linux platforms, or indeed to »satisfying minority operating system needs«.
Debian, however, doesn't mind people trying unusual things if they are willing to do the work – although such people do not necessarily get to control the direction of the project as a whole.
What changes would that be, and how has Debian resisted them in the past?
The Debian project has no problem in general with proprietary software. It even distributes certain types of »non-free« software from its own servers (and has received flak from the FSF for that in the past). This is because the Social Contract emphasises Debian's goal of offering a computing platform that serves its users' needs, not ideological purity – although Debian makes it reasonably easy to eschew proprietary software if one doesn't want it.
Posted Feb 24, 2014 10:21 UTC (Mon)
by ovitters (guest, #27950)
[Link]
What do you mean? Upstart developers know Debian *really* well. They've started a port to FreeBSD, etc. Systemd developers have used various configuration files that were initiated in Debian. IMO OpenRC development only started picking up *after* the bug being opened. This CTTE bug is taking ages and ages. Meanwhile some OpenRC development is going on.
But as said: I don't think OpenRC is being totally up front. They're adjusting things to Debian. But sometimes it seems because that was due to lack of thought in the design. E.g. conflicting script names, directories, etc. It gives the impression it hasn't been used enough IMO. So you get issues once it is used on another distribution. Those should have to be fixed anyway.
If you check the latest thoughts, it seems they're working on a shim layer for systemd compatibility. This is what I really like: it proves that we should define new interfaces. Then rely on those interfaces, not go around adding loads of #ifdefs in all the software. The burden of implementing those interfaces should be on the init system developers.
Posted Feb 24, 2014 14:47 UTC (Mon)
by drag (guest, #31333)
[Link]
You are, basically, going to end up dedicating a huge amount of your personal time to making your system worse.
And, I am guessing, that if you run into software that is broken with sysvinit you are going to be filling bugs and causing a racket to try to force other people, who really don't care, to help make your system worse.
which ultimately means that it's a goal to make everybody else that doesn't care about using sysvinit have the complexity of what happens when people try to make a OS forward compatible with low-level obsolete and incomplete software solutions.
And the purpose of all of this is... what exactly?
Not trying to pick on you, but this whole 'choice for choice sake' mentality is a bit mysterious to me.
Posted Feb 24, 2014 16:46 UTC (Mon)
by javispedro (guest, #83660)
[Link] (26 responses)
And you can certainly be "reliable" without cgroups. Some of the BSDs contain functional equivalents that were designed decades before cgroups, and OpenRC supports at least one of them just fine.
Posted Feb 24, 2014 17:46 UTC (Mon)
by HelloWorld (guest, #56129)
[Link] (25 responses)
Posted Feb 24, 2014 20:07 UTC (Mon)
by peter-b (guest, #66996)
[Link] (1 responses)
> What functional equivalents are you talking about? Please don't say jails now, they're something completely different.
He may be referring to process fds?
Posted Feb 24, 2014 22:49 UTC (Mon)
by ovitters (guest, #27950)
[Link]
Posted Feb 24, 2014 22:40 UTC (Mon)
by javispedro (guest, #83660)
[Link] (22 responses)
I was actually going to say jails, because it is the only way to do it reliably. Then I realized daemons can escape cgroups, so I guess it's not that "reliable" after all...
Posted Feb 25, 2014 17:32 UTC (Tue)
by michich (guest, #17902)
[Link] (1 responses)
Why don't you (and/or anyone else who says it's possible to do what systemd does using mechanisms other than cgroups) finally prove Lennart wrong by showing us the code of a portable fork of systemd?
Posted Feb 28, 2014 10:58 UTC (Fri)
by javispedro (guest, #83660)
[Link]
Posted Feb 25, 2014 20:37 UTC (Tue)
by fandingo (guest, #67019)
[Link] (19 responses)
That's quite the bold claim. Do you mind sharing how that's done?
Posted Feb 26, 2014 7:43 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link]
Posted Feb 28, 2014 10:54 UTC (Fri)
by javispedro (guest, #83660)
[Link] (17 responses)
Posted Feb 28, 2014 11:43 UTC (Fri)
by khim (subscriber, #9252)
[Link] (6 responses)
Really? Let's exclude explicitly written malicious code (if you run malicious code under root in any UNIX system you are hosed anyway). How does that happen? You need something stronger to run potentially malicious code, sure. But that's totally different task: given kernel's track record you can not even run malicious code from unknown origin under regular user (you need some level of sandboxing like NaCl or seccomp) thus of course systemd does not try to solve that problem.
Posted Feb 28, 2014 19:27 UTC (Fri)
by vonbrand (subscriber, #4458)
[Link] (5 responses)
You can't exclude malicious code, a vulnerability might allow the attacker to execute arbitrary code.
Posted Feb 28, 2014 20:00 UTC (Fri)
by khim (subscriber, #9252)
[Link] (4 responses)
Posted Feb 28, 2014 21:57 UTC (Fri)
by javispedro (guest, #83660)
[Link] (3 responses)
Posted Feb 28, 2014 22:24 UTC (Fri)
by fandingo (guest, #67019)
[Link] (1 responses)
I'm still looking for a concrete example of a service process escaping cgroups when using the systemd single-writer that lives in PID 1. The only thing I can come up with is a full kernel exploit, and that breaks everything. Even khim's worst-case scenario of root with unconfined_t, can't escape other processes from service cgroups. The manager will not allow it, and there's no way to replace the manager.
Posted Feb 28, 2014 22:35 UTC (Fri)
by mjg59 (subscriber, #23239)
[Link]
Posted Feb 28, 2014 23:33 UTC (Fri)
by khim (subscriber, #9252)
[Link]
Indeed. Cgroups are designed to be unescapable and non-intrusive means of managing process groups thus they are the only logical choice for the init system, but if you don't really care about making usable system and only want to create safe system there are many possibilities. Besides ptrace there are seccomp (and no, not this new fancy seccomp-bpf but plain old seccomp: it's enough, surpisingly enough). You can use it to create completely safe init system. Why this is bad idea left as an excercise for a reader.
Posted Feb 28, 2014 16:42 UTC (Fri)
by peter-b (guest, #66996)
[Link] (6 responses)
Why are you running daemons as root?
Posted Feb 28, 2014 16:59 UTC (Fri)
by fandingo (guest, #67019)
[Link] (5 responses)
Posted Feb 28, 2014 18:36 UTC (Fri)
by vonbrand (subscriber, #4458)
[Link] (4 responses)
You configure the port in the unit file, no privileges in the daemon required at all.
Posted Feb 28, 2014 18:50 UTC (Fri)
by fandingo (guest, #67019)
[Link] (3 responses)
Second, even some services that do, still run as root. openssh-server supports socket activation, but the main process is still root, and every session has a root process used for permission separation.
Posted Feb 28, 2014 19:15 UTC (Fri)
by vonbrand (subscriber, #4458)
[Link] (2 responses)
Fix them? At the very least, this reduces the attack surface to a handful of daemons...
Posted Feb 28, 2014 21:06 UTC (Fri)
by fandingo (guest, #67019)
[Link] (1 responses)
That being said, while the current processes are "root" mostly in name. SELinux (and other LSMs) for the most part have neutered these processes.
The real security threat comes from kernel exploits, and unfortunately, neither changing service users nor using a LSM sandbox helps prevent kernel exploits that much.
Posted Feb 28, 2014 23:23 UTC (Fri)
by mgb (guest, #3226)
[Link]
Not.
P.S. Does systemd support AF_APPLETALK?
Posted Feb 28, 2014 16:57 UTC (Fri)
by fandingo (guest, #67019)
[Link]
Short of a kernel exploit, there is no way to move out of cgroups or to a non-allowed cgroup. The cgroup manager won't allow it, and there's no way even a malicious program could kill the cgroup manager and register as a new manager with the kernel because the manager is PID 1, making it unkillable.
Yes, cgroupfs is insecure because it allows arbitrary writers, and you absolutely need something like SELinux to keep the privileged portions of daemons from causing a jailbreak. Fortunately, this mode of operation will disappear soon (at least for those using systemd).
Posted Feb 28, 2014 18:57 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Posted Feb 28, 2014 20:06 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
A root process can simply move itself to another cgroup hierarchy, since it has access to cgroups.
And a single writer model won't really protect against it because a malicious root process can simply ptrace or replace the cgroups manager with a modified version that allows it to do anything.
Additional confinement is needed to fix this problem, in any case. Be it namespaces, SELinux, AppArmor or something else.
Posted Feb 24, 2014 2:34 UTC (Mon)
by josh (subscriber, #17465)
[Link]
OpenRC was never ignored or rejected out of hand; the TC evaluated it, and across the board considered it less featureful than either systemd or upstart, though potentially better than sysvinit. That seems like a mostly accurate assessment. You might be bothered by the characterization of "featureful" as a desirable property (as opposed to properties such as "portable" or "minimalist" or "based on shell scripts"), but describing the reasoning process as "not cool enough" is both disingenuous and insulting.
Posted Feb 24, 2014 18:35 UTC (Mon)
by rodgerd (guest, #58896)
[Link]
They got ignored because their code doesn't solve the same range of problems as either upstart or systemd. The habit of arguing that "features coming Soon" should be treated as "features already here in upstart" probably didn't help.
Posted Feb 25, 2014 15:57 UTC (Tue)
by xxiao (guest, #9631)
[Link]
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Wol
And, when other people also "show up with code" (e.g. see busy OpenRC maintainers trying to figure out how to port it to all Debian supported architectures and fixing other problems) they get ignored or rejected out of hand as they're "not cool enough".
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
But most of the interesting distros actually care; instead, they don't care on "the other tasks", which is the reason they will not able to keep on forward porting non-systemd Gnome3 forever.
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Wol
Debian TC vote on init system coupling
It would be perfectly feasible for a distribution to replace one part of systemd by something better on a trial basis and fold worthwhile innovations back into the main codebase later.
Not even `mighty' canonical really managed to do that with logind. How can a mere mortal even dream to do that, specially when even systemd maintainers are encouring strongly tying everything to systemd (as exemplified by this very article)?
Debian TC vote on init system coupling
Because Fedora won't change for standarization reasons, Debian would be forced to switch to systemd's or just rip systemd's builtin one from the codebase.
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
>
> One of the points raised during the Debian discussion was that Debian's existing binfmt `manager' was better (objectively more featureful) than the one in systemd, which was based on Fedora's. Because Fedora won't change for standarization reasons, Debian would be forced to switch to systemd's or just rip systemd's builtin one from the codebase.
systemd's binfmt stuff can be trivially disabled with a configure switch. Are you honestly trying to say that that's an insurmountable challenge?
What does Gentoo do differently with respect to framebuffers? And I hate to bring this to you, but Hurd is a toy. I has been around forever, yet it's still nowhere near production ready, it's based on outdated technology (Mach), attempts to port it to other microkernels have failed, and worst of all, there's no momentum around it, nobody even takes it seriously.
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
> And that's what loose coupling is all about as far as I'm concerned: keeping options open for a later re-evaluation of init systems that might actually cater to Debian's needs instead of the other way around.
Loose coupling !=freedom of choice for the package maintainer.
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
the udev version in lenny will not provide all the functionality expected by the latest kernels, special care must be taken when upgrading to avoid putting your system in an unbootable state.
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Systemd distros will migrate to Fedora plumbing elements whenever systemd so dictates - a huge loss of Debian functionality.
Debian TC vote on init system coupling
systemd doesn't care where the plumbing comes from, it just tries to pick the most sensible alternative. And in quite a few cases, they adopted debianisms, which were then also adopted by Fedora.
systemd can't possibly dictate anything, it's just an open source project, and also new functionality in systemd doesn't mean that the equivalent features in debian somehow magically disappear. In short, what you're saying here is nonsense.
In fact, if debian has a better implementation of something, the sensible thing to do is to try to push it into systemd, so other distros eventually end up offering it to their users too (except if they go out of their way to disable it). Everybody wins that way.
WTF? Sometimes storing the hostname in /etc/HOSTNAME, sometimes in /etc/hostname and sometimes in /etc/sysconfig/network, *that's* bikeshedding. It's a huge win that systemd stops that kind of madness.
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Replacing Debian plumbing with Fedora/systemd plumbing is a serious loss.
Debian TC vote on init system coupling
> from other Linux distributions.
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
He made no claim that it was perfect; that was all you. He merely said that it was good, and that udev added a lot of work to the upgrade process, both of which are true, as far as I know.Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
"The plural of anecdote isn't data"
Wol
"The plural of anecdote isn't data"
"The plural of anecdote isn't data"
"The plural of anecdote isn't data"
"The plural of anecdote isn't data"
"The plural of anecdote isn't data"
"The plural of anecdote isn't data"
"The plural of anecdote isn't data"
"The plural of anecdote isn't data"
Wol
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Fedora upgradability has little to do with this rather vague concept of 'plumbing' and a lot to do with the fact that upgradability is really hard, and we ship new Fedora releases with giant piles of new things in them every six months, and we never really developed a culture of offering particularly guaranteed upgradability anyway.Debian TC vote on init system coupling
Great argument!
Great argument!
Great argument!
Great argument!
Great argument!
There is Debian GNU/HURD, there is Debian GNU/BSD (or something like that), there may even be something like FreeBSD/Linux.
Debian is basically the only GNU/Linux distribution that offers sailing on a variety of alternative kernels and platforms.
That may quite understandably about different choices regarding how much one wants to tie the dominant distribution into very specific technologies. It might mean that a number of packages in other distributions might stop receiving the benefits from some packages created to operate on GNU/Linux to easily port to other systems.
Of course, it is a problem for supporting diversity if you take a majority vote about portability issues when 90% are users of one platform.
That's like taking majority votes about individual decisions of cultural diversity, desegregation, resource sharing and similar stuff.
Without explicitly viewing it as a moral problem and looking at long-term consequences, chauvinism, racism and tribalism always win. It's a natural urge that one has to fight explicitly, like taking what you want or hitting who you want (we do this with religious and secular laws against theft and murder).
While I am not a user of the "fringe distributions" of Debian myself, I think that they are something to be proud of. Even while Debian GNU/Linux is a rather dominant crowd, the support of those "fringe" systems demonstrates that Debian cares about openness and cooperation.
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Wol
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Wol
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Wol
Debian TC vote on init system coupling
Debian TC vote on init system coupling
"First they came for sysvinit and ovitters didn't speak out. Then they came for the BSDs and ovitters didn't speak out. Then they came for the HURD. And when they came for Gnome, there was no-one left to speak out for ovitters".
Debian TC vote on init system coupling
That's what THEY want you to think.
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Well, there have been sounds of how some kernels and configurations are considered undesirables or irrelevant in the greater scheme of things.
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
>>An open inclusive approach to alternatives to allow for future developments and satisfy minority operating system needs.
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
An open inclusive approach to alternatives to allow for future developments and satisfy minority operating system needs.
Little or no allowance for changes that would ease the installation of proprietary software.
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
What functional equivalents are you talking about? Please don't say jails now, they're something completely different.
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Process fds is one way. If you're going to repeat Lennart's propaganda, you'll have to elaborate a bit more.
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Any daemon running as root can trivially escape a cgroup.
You need something stronger in order to actually ensure "reliability".
Debian TC vote on init system coupling
Once you are unrestricted root the game is finished. End of story. You can do whatever you want with a system (using DMA in GPU works just fine for that). There are plenty of ways to restrict root and, surprise, surprise, most of them make it impossible to escape from cgroup as a nice added bonius. But it's not systemd's place to solve that problem. You can not on one hand complain about systemd “feature creep” and on the other hand complain that it does not work as intrusion detection and/or prevention system.
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
"Bound sockets should exclusively come from the init system."
And all P2P S/W should be trash-canned.
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling