Debian TC vote on init system coupling
| From: | Ian Jackson <ijackson-AT-chiark.greenend.org.uk> | |
| To: | 727708-AT-bugs.debian.org | |
| Subject: | Bug#727708: Call for Votes on init system coupling | |
| Date: | Fri, 21 Feb 2014 18:04:07 +0000 | |
| Message-ID: | <21255.38167.767638.934892__27452.9149909087$1393005987$gmane$org@chiark.greenend.org.uk> |
I hereby call for votes on my coupling proposal and the amendments
that have been put.
The options on the ballot are:
L Software may not depend on a specific init system
N No TC resolution on this question at this time
A Advice: sysvinit compatibility in jessie and multiple init support
FD Further discussion
(I have removed the proponents' names from the summary lines.)
Thanks,
Ian.
L Software may not depend on a specific init system
====================================================
Rationale
The default init system decision is limited to selecting a default
initsystem for jessie. We expect that Debian will continue to
support multiple init systems for the foreseeable future; we
continue to welcome contributions of support for all init systems.
Rubric
Therefore, for jessie and later releases, we exercise our power to
set technical policy (Constitution 6.1.1):
Loose coupling
In general, software may not require a specific init system to be
pid 1. The exceptions to this are as follows:
* alternative init system implementations
* special-use packages such as managers for init systems
* cooperating groups of packages intended for use with specific init
systems
provided that these are not themselves required by other software
whose main purpose is not the operation of a specific init system.
Degraded operation with some init systems is tolerable, so long as
the degradation is no worse than what the Debian project would
consider a tolerable (non-RC) bug even if it were affecting all
users. So the lack of support for a particular init system does not
excuse a bug nor reduce its severity; but conversely, nor is a bug
more serious simply because it is an incompatibility of some software
with some init system(s).
Maintainers are encouraged to accept technically sound patches
to enable improved interoperation with various init systems.
GR rider
If the project passes (before the release of jessie) by a General
Resolution, a "position statement about issues of the day", on the
subject of init systems, the views expressed in that position
statement entirely replace the substance of this TC resolution; the
TC hereby adopts any such position statement as its own decision.
Such a position statement could, for example, use these words:
The Project requests (as a position statement under s4.1.5 of the
Constitution) that the TC reconsider, and requests that the TC
would instead decide as follows:
N No TC resolution on this question at this time
=================================================
The TC chooses to not pass a resolution at the current time
about whether software may require specific init systems.
A Advice: sysvinit compatibility in jessie and multiple init support
=====================================================================
The following is technical advice offered to the project by the
Technical Committee under section 6.1.5 of the constitution. It does
not constitute an override of maintainer decisions past or future.
Software should support as many architectures as reasonably possible,
and it should normally support the default init system on all
architectures for which it is built. There are some exceptional cases
where lack of support for the default init system may be appropriate,
such as alternative init system implementations, special-use packages
such as managers for non-default init systems, and cooperating
groups of packages intended for use with non-default init systems.
However, package maintainers should be aware that a requirement for a
non-default init system will mean the software will be unusable for
most Debian users and should normally be avoided.
Package maintainers are strongly encouraged to merge any contributions
for support of any init system, and to add that support themselves if
they're willing and capable of doing so. In particular, package
maintainers should put a high priority on merging changes to support
any init system which is the default on one of Debian's non-Linux
ports.
For the jessie release, all software that currently supports being run
under sysvinit should continue to support sysvinit unless there is no
technically feasible way to do so. Reasonable changes to preserve
or improve sysvinit support should be accepted through the jessie
release. There may be some loss of functionality under sysvinit if
that loss is considered acceptable by the package maintainer and
the package is still basically functional, but Debian's standard
requirement to support smooth upgrades from wheezy to jessie still
applies, even when the system is booted with sysvinit.
The Technical Committee offers no advice at this time on sysvinit
support beyond the jessie release. There are too many variables at
this point to know what the correct course of action will be.
--
Posted Feb 23, 2014 19:10 UTC (Sun)
by AngryChris (guest, #74783)
[Link] (207 responses)
Posted Feb 23, 2014 19:15 UTC (Sun)
by keithp (subscriber, #5140)
[Link]
Posted Feb 23, 2014 19:16 UTC (Sun)
by malor (guest, #2973)
[Link] (164 responses)
But, like it or not, they're the people who showed up with the code. And if Debian is going to go through the pain of an init switch anyway, they might as well get full benefit out of the switch, and allow tight 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.
Posted Feb 23, 2014 21:52 UTC (Sun)
by anselm (subscriber, #2796)
[Link] (145 responses)
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]
Posted Feb 24, 2014 7:14 UTC (Mon)
by jude- (guest, #95678)
[Link] (17 responses)
Just because Lennart et al. showed up with *a* solution does not make it inherently better than the status quo. For example, every feature I would use in systemd I already do myself without it (including putting services into cgroups). I'm not saying that systemd doesn't do useful things for other people, of course :) I'm just making the (small) point that showing up with code isn't a reason to necessarily use it, especially when you already have something that works.
Moreover, tightly coupling a distro to systemd (the implementation) precludes the possibility that something better (but incompatible) will come into being later. When (not if) that happens, we'll be right back where we are today if we're not careful.
Fortunately, the solution to achieving loose coupling without boxing ourselves into one init system is to stabilize the systemd APIs--namely, both the systemd-to-application and daemon-to-systemd-PID-1 APIs. This would help developers (and distro maintainers) know exactly what functionality can be expected from the plumbing layer and how to get at it, and will let those wishing to extend/improve/modify the systemd implementation do so without having to work with a constantly-moving upstream target. I know Lennart et al. are working on stabilizing the former (systemd stability promise), but stabilizing latter looks pretty far off, especially since we don't even know yet what the scope of systemd will be.
Once both sets of APIs are stabilized, with systemd serving as a reference implementation, I think a lot of the controversy around init systems will go away. If, for example, OpenRC evolves into something better than systemd, all that would need to be done to make it available would be to ensure it implements the (stabilized) systemd APIs. Then, you would be able to incrementally deploy OpenRC over systemd (possibly using components of both during the transition), without breaking the layers above them.
Posted Feb 24, 2014 9:11 UTC (Mon)
by peter-b (guest, #66996)
[Link] (5 responses)
You will, I'm sure, be pleased to hear that both of the APIs you mention are covered by the systemd interface stability promise.
http://www.freedesktop.org/wiki/Software/systemd/Interfac...
Posted Feb 24, 2014 19:50 UTC (Mon)
by jude- (guest, #95678)
[Link] (4 responses)
Posted Feb 24, 2014 20:07 UTC (Mon)
by fandingo (guest, #67019)
[Link] (3 responses)
If you're instead referring to "reimplementable independently," I think you misunderstand what that is supposed to mean. Those interfaces are considered too specific to systemd and other systems should implement their own specific interfaces. Therefore, the systemd developers don't want to provide counsel for reimplementations. Nonetheless, the interfaces are stable, and the developers won't stop you.
Posted Feb 24, 2014 20:28 UTC (Mon)
by jude- (guest, #95678)
[Link] (2 responses)
> Those interfaces are considered too specific to systemd and other systems should implement their own specific interfaces.
The same article says that these interfaces will eventually be stabilized. Presumably, so that development in the various systemd components can occur without breaking other components' functionality.
> Therefore, the systemd developers don't want to provide counsel for reimplementations.
I would never expect it from them.
Posted Feb 24, 2014 20:34 UTC (Mon)
by fandingo (guest, #67019)
[Link] (1 responses)
Even if we include non-DBus interfaces, every interface except "udev session switch ACL properties" is included in the interface stability promise.
Posted Feb 24, 2014 21:53 UTC (Mon)
by jude- (guest, #95678)
[Link]
The one I was referring to was peter-b's article [2]. This one's the one that says that the D-Bus interfaces to the main daemon are not stable.
My apologies for the confusion.
[1] http://www.freedesktop.org/wiki/Software/systemd/Interfac...
[2] http://www.freedesktop.org/wiki/Software/systemd/Interfac...
Posted Feb 24, 2014 15:34 UTC (Mon)
by ewan (guest, #5533)
[Link] (2 responses)
OK. Are you doing that with distro standard stuff, or custom local things? If the latter, wouldn't it be nice to a) not have to have to deal with custom local stuff, and b) for everyone else to get the same benefits without first having to re-invent your wheel?
Posted Feb 24, 2014 20:09 UTC (Mon)
by jude- (guest, #95678)
[Link] (1 responses)
[1] http://www.freedesktop.org/wiki/Software/systemd/PaxContr...
Posted Feb 24, 2014 22:46 UTC (Mon)
by ovitters (guest, #27950)
[Link]
Posted Feb 24, 2014 16:31 UTC (Mon)
by fandingo (guest, #67019)
[Link] (7 responses)
> Once both sets of APIs are stabilized, with systemd serving as a reference implementation, I think a lot of the controversy around init systems will go away. If, for example, OpenRC evolves into something better than systemd, all that would need to be done to make it available would be to ensure it implements the (stabilized) systemd APIs. Then, you would be able to incrementally deploy OpenRC over systemd (possibly using components of both during the transition), without breaking the layers above them.
The big problem with this sentiment is that it's not clear that any other group has the ability to keep up, desire to go in that direction, or commitment to even attempting to be compatible.
To expand, systemd development is happening at a blistering pace. The most notable thing is that they don't seem to need to spend much time redesigning or patching their code. It's all feature development. Upstart *was* the only project that might have had the manpower and resources to make a go at it, but Canonical has decided it's better to use systemd than commit resources to what would be an alternative without any benefits.
Alternatives and choice sound good in the abstract, but when they require serious amounts of work, you have to question whether that effort is better spent elsewhere. There aren't any complaints about the implementation quality of systemd. What's the point of an alternative implementation of the same interfaces if there's no obvious room for improvement?
Lastly, I don't see OpenRC as a potential competitor (let alone alternative implementation) to systemd. OpenRC doesn't even seek to replace /sbin/init. That leads me to believe that it won't provide a cgroup manager, early logging support, LSM integration, or session management. That doesn't even begin to include all of the medium and minor abilities like host name, time, and machine management.
Posted Feb 24, 2014 20:22 UTC (Mon)
by jude- (guest, #95678)
[Link] (6 responses)
I personally want to implement a separate journald, because the current implementation does not do (and likely will not do) what I need. If the journald-to-systemd-PID-1 API was stable, I would make the replacement, and I wouldn't have to worry about it breaking on the next upgrade.
> To expand, systemd development is happening at a blistering pace.
That is not an excuse to avoid API stability. The Linux kernel keeps a stable userspace API, and it does so while receiving far more patches than systemd.
> The most notable thing is that they don't seem to need to spend much time redesigning or patching their code. It's all feature development.
If this is true, then there is definitely no excuse for a non-stable API, if the API is not changing.
> There aren't any complaints about the implementation quality of systemd. What's the point of an alternative implementation of the same interfaces if there's no obvious room for improvement?
I have one: journald does not gracefully handle log file corruption it causes due to improper shutdown. What I would like it to do is write log records transactionally, so I can tell the difference between someone tampering with my log, and my log being left in an inconsistent state because my laptop crashed (i.e. uncommitted transactions). This will require changing the write protocol, which is non-trivial. Again, I'm willing to do this myself. But, a non-stable journald/systemd API (not to be confused with the external D-Bus API) would mean that I not only have to make the implementation, but also re-write parts of it each time I upgrade systemd. That makes it too cost-ineffective for me.
> Lastly, I don't see OpenRC as a potential competitor (let alone alternative implementation) to systemd. OpenRC doesn't even seek to replace /sbin/init. That leads me to believe that it won't provide a cgroup manager, early logging support, LSM integration, or session management. That doesn't even begin to include all of the medium and minor abilities like host name, time, and machine management.
OpenRC implements a cgroup manager [1]. Whether or not it uses /sbin/init in its implementation is irrelevant, as long as it can reliably start and stop services. Yes, OpenRC is not as mature at this point, but that does not mean that it will not be able to catch up.
Posted Feb 24, 2014 20:31 UTC (Mon)
by fandingo (guest, #67019)
[Link] (5 responses)
You're in luck, and it doesn't require re-implementing journald. I'm at this moment working on a feature to journald that will allow you to do this much easier than you imagine.
I'm unsatisfied with the journald-->remote journald logging, which requires a syslog intermediary. Rather than building in remote logging directly into the journal, which is the obvious solution, I figured that there are other applications that would be interested in this data. (In particular, I was imaging more network-based uses like native loggers for Splunk and LogStash.) The implementation that I'm currently working on exposes log data over KDBus (so practically zero performance impact) to subscribers. Anything can subscribe and get log messages in their entirety. You would be able to set journald.conf Storage=None and have your own persistent writer connect to the system bus and write out your preferred format.
===
> If the journald-to-systemd-PID-1 API was stable
What gives you the impression that it is unstable? The systemd developers include it in the stability promise.
Posted Feb 24, 2014 21:59 UTC (Mon)
by jude- (guest, #95678)
[Link]
Is this the same as the Service bus API (listed in [2])?
[1] http://www.freedesktop.org/wiki/Software/systemd/Interfac...
Posted Feb 24, 2014 22:04 UTC (Mon)
by jude- (guest, #95678)
[Link] (3 responses)
This sounds pretty cool, and is definitely something I'd be interested in using :)
My main concern with regards to transaction-like logging semantics is that the processes of updating the log indexes, updating the rolling log hash, and writing the log message do not occur as a single atomic operation. A crash in the middle of logging a message would leave the logs, indexes, and hashes in an inconsistent (but potentially recoverable) state. Does your implementation address this? As in, once you expose a log record over kdbus, are its associated hashes and indexes guaranteed to be consistent?
Posted Feb 24, 2014 22:47 UTC (Mon)
by fandingo (guest, #67019)
[Link] (2 responses)
> My main concern with regards to transaction-like logging semantics is that the processes of updating the log indexes, updating the rolling log hash, and writing the log message do not occur as a single atomic operation. A crash in the middle of logging a message would leave the logs, indexes, and hashes in an inconsistent (but potentially recoverable) state. Does your implementation address this? As in, once you expose a log record over kdbus, are its associated hashes and indexes guaranteed to be consistent?
This requires a little more explanation on what I'm actually trying to do. There's two separate pieces:
1) Modifications to systemd that expose log messages as signals. (Currently, there are methods to query log messages, but that won't be sufficient for constant forwarding.)
2) A service that listens for these signals and does *something* with them. (My something is sending them across the network to a listening service.)
#1 is the only part that necessarily lives within the systemd tree. Anyone is free to make their own #2, and they can even do wildly different things with those messages (like write them out locally in their own format). Furthermore, since #2 is subscribing to a set of signals, multiple services can simultaneously perform #2, and journald has no clue (except that subscribers >0).
Back to atomic operation, consistency, and tampering.
I suppose that it would be possible for journald to make some sort of log_entry_ack() method available that a #2 service could send back to the journal confirming receipt. The question is what's the purpose? Obviously, that ack cannot be forwarded back to #2 or else there is infinite amplification of acks. The only use would be for journald to use it's internal storage mechanism, but then you're dependent on local logs (which I'm trying to avoid and you don't like due to corruption and other concerns).
A #2 service is free to implement any sort of fancy syncing/checkpointing that it wants. The journal messages already contain useful monotonic timestamps that could be immediately written to disk in a durable manner and with the desired anti-tampering protection. That's certainly going to have performance implications, but you should be able to add as much safety as is desired.
KDBus is still in active development, so we'll have to wait to see what guarantees it provides to message. Nonetheless, it's running as part of the kernel, so there should at least be highly reliable signal delivery, possibly even guaranteed. DBus currently (and safe to assume that KDBus will continue to) guarantees message ordering, so that's also helps with consistency.
Lastly, journald has supported forward secure sealing (FSS). I'm not a cryptographer, but my understanding is that FSS is quality anti-tampering implementation. It would not appear to be that much of a challenge to send the sealing key over the system bus, allowing a #2 service to verify the integrity based on the verification key.
Let me know if you have additional questions or comments. As I said, I'm just getting started on implementation, and I don't want to pigeon-hole this idea to my use case, general network log aggregation.
Posted Feb 25, 2014 3:06 UTC (Tue)
by jude- (guest, #95678)
[Link] (1 responses)
I think the biggest challenge to #1 is getting messages out of systemd without causing systemd to block, without filling up too much buffer space, and without losing messages. While signaling message consumers would get them to wake up and grab the next message, you'd have to be very careful to get the next message quickly (even under load), so systemd can free it. Even with (reliable) real-time signals, you'll still need to ensure that systemd holds onto your message long enough for your to get it (without blocking systemd). This is on top of contending with signal handler races, whereby you might consume messages concurrently and out-of-order. I think you might have better luck with a socket or a message queue.
I took a look at the kdbus GitHub. I looks to be designed specifically to address this challenge, so that might be a better long-term option (maybe use a compatibility library to access kdbus, if you need portability).
> A #2 service is free to implement any sort of fancy syncing/checkpointing that it wants. The journal messages already contain useful monotonic timestamps that could be immediately written to disk in a durable manner and with the desired anti-tampering protection. That's certainly going to have performance implications, but you should be able to add as much safety as is desired.
This is quite helpful :) They're already putting the messages in order for us. It looks like you would be able to get away with sending messages out as soon as they're ready (i.e. once you have the hash for the message).
Posted Feb 25, 2014 3:35 UTC (Tue)
by fandingo (guest, #67019)
[Link]
DBus can take care of this.
> without filling up too much buffer space, and without losing messages
I think that this will be the biggest concern. User-space DBus has always been pretty slow, so it hasn't been used for large data transfers. I've inquired with the systemd developers to see if there is (or will be) any method of "expiring" signals (there is a timeout feature for regular method calls) and how that appears to the subscribers. If that is possible, we should be able to query journald for message IDs, although there are certainly lots of considerations to handle if the listener is overwhelmed by messages and cannot query messages from the journal (especially if the journal is only storing to memory).
I'd like to have someone to collaborate with. If you're interested, join the systemd mailing list. I'm going to work a very rough POC and post it to the list in the next couple of weeks to get some feedback.
Posted Feb 23, 2014 19:17 UTC (Sun)
by cesarb (subscriber, #6266)
[Link] (6 responses)
With systemd, you can have both the /etc/init.d script and a systemd unit with the same name. The systemd unit will override the /etc/init.d script, which will be ignored.
Posted Feb 23, 2014 19:24 UTC (Sun)
by AngryChris (guest, #74783)
[Link] (5 responses)
In fact, the only services my system starts that are started using Upstart jobs are jobs I wrote myself for 3rd party software that isn't distributed with Ubuntu (subsonic, ventrilo, Tiny Tiny RSS, etc).
While it's possible, I am sure, for maintainers to provide both systemd units and sysvinit scripts in their packages, loose coupling allows "path of least resistance" to take over and I believe that sysvinit scripts is all we're going to end up with for the most part. I think that writing that systemd unit is going to be left to the local administrator.
Posted Feb 23, 2014 19:33 UTC (Sun)
by eean (subscriber, #50420)
[Link] (3 responses)
Posted Feb 23, 2014 21:40 UTC (Sun)
by vonbrand (subscriber, #4458)
[Link] (2 responses)
Given that upstart is Ubuntu native, it makes little sense that the upstream distribution hasn't done the job... It was also the init for several Fedora (and RHEL) versions. To me at least it looks like it was too hard to do right, given that in a short time most services got native systemd units.
Posted Feb 24, 2014 1:35 UTC (Mon)
by eean (subscriber, #50420)
[Link] (1 responses)
Posted Feb 24, 2014 2:22 UTC (Mon)
by vonbrand (subscriber, #4458)
[Link]
In this particular case it is Ubuntu who is upstream.
Posted Feb 23, 2014 22:08 UTC (Sun)
by anselm (subscriber, #2796)
[Link]
To me it looks more like »Patching all the stuff we get from Debian to include Upstart jobs is a huge amount work for us few Ubuntu guys, so let's put it off for a while; the SysV init scripts will keep working in the meantime.«
It stands to reason that, if Debian had adopted Upstart as its default init system, eventually most of the Debian packages Ubuntu is re-using would have come with Upstart jobs, thus saving the Ubuntu people rather a lot of work. With the decision in favour of systemd, it was clear that this wasn't going to happen, so it made sense for Canonical to drop Upstart in favour of systemd, instead of ending up doing the work themselves.
However the coupling vote comes out, Debian package maintainers will most probably be encouraged by policy to adopt patches that add systemd unit files to their packages. There are people within Debian who are actively working on providing systemd unit files for other people's service packages. Now that systemd is slated to be the official default init we can expect this effort to gain further momentum, so it is safe to say that eventually most if not all packages that come with SysV init scripts today will also feature systemd unit files.
Posted Feb 23, 2014 19:26 UTC (Sun)
by tao (subscriber, #17563)
[Link] (32 responses)
Posted Feb 23, 2014 19:39 UTC (Sun)
by AngryChris (guest, #74783)
[Link] (31 responses)
The only init that ends up being fully supported is sysvinit because systemd, upstart, and sysvinit itself all run sysvinit scripts. There's no incentive to write those systemd units for those maintainers who decide they just plain don't want to because ... whatever reason (don't know how to write systemd units, it's Tuesday, Lennart, don't like how the vote turned out, etc).
That N option also allows for loose coupling or no coupling at all. I don't think loose coupling should be an option. If a next generation init system is being adopted it should be adopted whole hog. I'm still surprised that even Ubuntu hasn't adopted its own next generation init system completely. I feel tight coupling should at least be one of the items to vote on. While I understand even then it may not pass (which would disappoint me) it should be an option in my opinion.
Posted Feb 23, 2014 20:34 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link] (14 responses)
Posted Feb 23, 2014 22:18 UTC (Sun)
by set (guest, #4788)
[Link] (13 responses)
Posted Mar 2, 2014 9:26 UTC (Sun)
by elvis_ (guest, #63935)
[Link] (12 responses)
Posted Mar 2, 2014 14:26 UTC (Sun)
by rahulsundaram (subscriber, #21946)
[Link] (11 responses)
Posted Mar 8, 2014 6:25 UTC (Sat)
by elvis_ (guest, #63935)
[Link] (10 responses)
I would much prefer unitfile.default and unitfile.localchanges in the same directory.
Posted Mar 8, 2014 8:52 UTC (Sat)
by zdzichu (subscriber, #17118)
[Link] (9 responses)
1) unit location is in the second line of status output:
2) If administrator does customistation by drop-in snippets, all are listed in next line:
3) administrator can review his own changes in /etc/systemd/system. To see final unit, ”systemctl cat” will merge all the changes and present the unit from systemd's point of view.
It is actually quite easy and clear to see what's going on.
Posted Mar 8, 2014 15:53 UTC (Sat)
by raven667 (subscriber, #5198)
[Link] (8 responses)
Posted Mar 8, 2014 17:05 UTC (Sat)
by rahulsundaram (subscriber, #21946)
[Link] (7 responses)
Posted Mar 8, 2014 18:15 UTC (Sat)
by dlang (guest, #313)
[Link] (5 responses)
Posted Mar 8, 2014 18:21 UTC (Sat)
by rahulsundaram (subscriber, #21946)
[Link]
Posted Mar 8, 2014 23:42 UTC (Sat)
by anselm (subscriber, #2796)
[Link] (3 responses)
Here's your system administration convention:
Exactly how does systemd »throw away« anything? If anything, System V init is ignoring the convention by putting loads of stuff into /etc that is really quite difficult to change without producing a maintenance nightmare.
Posted Mar 9, 2014 4:19 UTC (Sun)
by dlang (guest, #313)
[Link] (2 responses)
Posted Mar 9, 2014 5:13 UTC (Sun)
by rahulsundaram (subscriber, #21946)
[Link] (1 responses)
Ex:
--
[Service]
--
man systemd.unit more details
Posted Mar 9, 2014 13:25 UTC (Sun)
by anselm (subscriber, #2796)
[Link]
This is particularly useful because in the systemd setup the configuration files provided by the distribution are cleanly separated from the local settings made by the administrator.
With something like System-V init, everyone unloads their init files in /etc/init.d, and it is difficult for an administrator to (a) see whether any of these scripts have indeed been changed to better suit local preferences, and (b) maintain such changes across updates from the distributor. Systemd makes this much more obvious because anything under /etc is by definition a local change, and updates to the distributor-provided configuration in /usr do not run the risk of either obliterating the local changes or else requiring a tedious manual merge.
Posted Mar 8, 2014 18:29 UTC (Sat)
by raven667 (subscriber, #5198)
[Link]
Certainly in this case there are pros and cons of each approach, which I tried to highlight and provide some guesses of possible rationale for each, none of which was "just because".
Posted Feb 24, 2014 8:38 UTC (Mon)
by palmer_eldritch (guest, #95160)
[Link]
Yes, that's how Debian's supposed to work: trust the maintainers to do what's best for their packages.
Posted Feb 24, 2014 13:34 UTC (Mon)
by nye (subscriber, #51576)
[Link] (14 responses)
Just so we're clear, you think the tech committee should mandate that all packages must depend directly on systemd?
Because that's what you're saying.
Posted Feb 24, 2014 15:06 UTC (Mon)
by raven667 (subscriber, #5198)
[Link] (11 responses)
It seems like the idea is to discourage use of kernel features like cgroups, namespaces, priorities, etc. because they are trivial to use with systemd but harder and less standardized to use by hand and requiring every developer to write management frameworks for these feature is additional work than just letting systemd do it, helping keep these features unpopular makes other kernels more competitive with Linux and the software more portable to other systems. If developers start relying on Linux features then competitive kernels are going to have to implement these features or see their available software drop.
Posted Feb 24, 2014 16:19 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (9 responses)
Under the »loose coupling« approach, packages are not supposed to depend on a particular init system. This does not mean that packages are forbidden from using, e.g., systemd features as long as they can also run on a system that doesn't use systemd – it doesn't mean that they must work identically across all available init systems. If they find that they are installed on a system that does in fact run systemd, they are absolutely allowed to behave differently than they would on non-systemd systems, as long as their behaviour on either system would not be considered RC-buggy if it occurred for all users.
For example, there would presumably be nothing to keep a package maintainer from shipping a systemd unit file that made use of all sorts of interesting, convenient, and helpful systemd features, in addition to a very basic System V init script that supported the very minimum of features that would still be compliant with Debian policy for the benefit of other init systems. There would also be nothing wrong with adding a »--systemd« option to a daemon that made it use all sorts of bells and whistles courtesy of systemd, and keeping the normal (clunky) behaviour for use with other init systems.
Finally, GNOME would not be allowed to depend on systemd in order to avail itself of logind, but it would be OK to depend on some (virtual) package that provided the logind DBUS interface as long as there'd be an alternative implementation outside systemd that could be used with other inits (although that implementation would not be required to perform 100% identically).
Posted Feb 24, 2014 17:44 UTC (Mon)
by raven667 (subscriber, #5198)
[Link] (3 responses)
That's the kind of discouragement I was talking about, the penalty for trying to use logind is that you are now committed to create a re-implementation of logind for people who don't want to use systemd. What kind of software engineer would accept those conditions?
Posted Feb 24, 2014 18:00 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (2 responses)
This is admittedly one of the hairier cases. However, in this case it is worth noting that you don't have to reimplement all of logind, you only need to reimplement those bits that GNOME actually uses, and not even all of those actually need to do anything (although it would sure be nice if they did). For example, you could probably get away with not supporting the nifty multiseat capability that systemd offers.
This approach may in the end still be preferable to supporting non-systemd systems in the actual GNOME code base until who-knows-when. I don't know whether upstream GNOME is planning to go Linux-only (which they would probably have to if they want to rely on systemd exclusively), but if they aren't they'll need something like this anyway.
Posted Feb 24, 2014 20:00 UTC (Mon)
by fandingo (guest, #67019)
[Link] (1 responses)
http://www.freedesktop.org/software/systemd/man/systemd-l...
> systemd-logind is a system service that manages user logins. It is responsible for:
> 1. Keeping track of users and sessions, their processes and their idle state
> 2. Providing PolicyKit-based access for users to operations such as system shutdown or sleep
> 3. Implementing a shutdown/sleep inhibition logic for applications
> 4. Handling of power/sleep hardware keys
> 5. Multi-seat management
> 6. Session switch management
> 7. Device access management for users
> 8. Automatic spawning of text logins (gettys) on virtual console activation and user runtime directory management
It seems quite easy to make basically a "no-op" DBus interface to fake logind. #1 is only minimally necessary, although I can't say how much is actually needed and the complexity. #2 is simple enough to invoke a SUID binary for the underlying scripts, although security leaves something to be desired. #3 is completely optional. #4 could be handled through Gnome by configuring custom keyboard shortcut commands (sprinkle in SUID as necessary). #5 and #6 can be ignored. #7 should be simple. Since there's no multi-seat, it's easy to run a udev script for changing owner/group of the devices and sending a DBus signal to Gnome of the hotplug event. #8 can be ignored in favor of fixed gettys. Runtime directories should be kept and could likely be managed by a Gnome startup script (or if necessary something inserted earlier in the login sequence).
There's no doubt that it will be messy and half-baked (especially as I've described it), but I think it could mostly work. Whether anyone would want to run or enjoying running it is another matter.
Posted Feb 24, 2014 20:16 UTC (Mon)
by anselm (subscriber, #2796)
[Link]
Yes, but that isn't the point. The point would be to achieve Debian policy compliance and make Ian Jackson happy. With proper documentation of the limitations of the gnome-compatibility-logind package it will probably be possible to avoid having any of those limitations look like RC bugs.
It is fairly safe to say that given a choice of a smooth GNOME user experience based on systemd and a clunky GNOME user experience based on »System V init or OpenRC plus essential-compatibility extras«, most GNOME users will be more interested in the former. If anyone doesn't like this, let them come up with a better non-systemd logind for GNOME; it is not the Debian GNOME maintainers' (or upstream GNOME's) job to ensure that the Debian non-systemd GNOME experience is 100% identical to the Debian GNOME experience based on systemd.
Posted Feb 24, 2014 17:56 UTC (Mon)
by ovitters (guest, #27950)
[Link]
Only if the alternative init is guaranteed to work with all current and future init systems. As soon as there is another init system that keeps cgroups for itself, GNOME "would" require specific init systems and be disallowed.
I specifically asked about this.
I find it madness because the burden is placed on GNOME to execute Debian policy. Not with init system developers. I'm totally ok to ensure that we require stable APIs which can be reimplemented. Current state is that we either depend on some stable APIs or ConsoleKit btw. People keep forgetting about our ConsoleKit support (however buggy it might be because I think in practice nobody in practice uses it :P).
Posted Feb 24, 2014 18:33 UTC (Mon)
by rodgerd (guest, #58896)
[Link]
> Russ's text does not contain any
He has explicitly stated he wold prefer GNOME out of the Debian archive. He has also explicitly stated he believes it is appropriate to require than package maintainers be forced to develop the equivalent functionality for every non-systemd init systems before their packages be allowed in the archive.
Ian appears to be very unhappy with, well, a bunch of things in the free software world, and he appears to feel Debian is his bully pulpit to force various upstreams to do thing differently.
Posted Feb 24, 2014 19:30 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (2 responses)
It's been pointed out in previous discussions that the whole tight/loose coupling debate is flawed in that both options have unwanted side-effects, and both options either dump a load of work on maintainers, or dictate to upstream telling them what to do ...
Cheers,
Posted Feb 24, 2014 21:09 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Posted Feb 25, 2014 7:19 UTC (Tue)
by mbunkus (subscriber, #87248)
[Link]
That is still the case in the actual vote[1]. Citing the lose coupling wording:
> The exceptions to this are as follows:…
The cases you've listed would fit this rule and would therefore be allowed to depend on systemd even in the lose coupling case.
[1] https://lists.debian.org/debian-ctte/2014/02/msg00575.html
Posted Feb 25, 2014 12:23 UTC (Tue)
by nye (subscriber, #51576)
[Link]
Arguably that could be more-or-less the end result of 'loose coupling is required', but the point is that the opposite of loose coupling is not 'tight coupling is required', because that's nonsense - the grand majority of packages are not in any way connected to the init system for there to be any coupling of any kind. The opposite of 'loose coupling is required' is 'tight coupling is *permitted*', which is the option that the GP was complaining about, saying it should be *mandatory*, a requirement which makes no sense at all.
I guess he/she probably wants something like 'any coupling that exists must be tightly to systemd, and no package that cares about its init system should work with anything else', but that's obviously not going to fly, so it's hard to tell.
Posted Feb 27, 2014 10:18 UTC (Thu)
by AngryChris (guest, #74783)
[Link] (1 responses)
Posted Feb 27, 2014 11:29 UTC (Thu)
by nye (subscriber, #51576)
[Link]
No, it makes things even less clear, since the T option there is even looser than the N option you are complaining is too loose.
That T option specifically encourages loose coupling where feasible, which I would have expected to upset you even more than allowing maintainers to choose as they see fit.
Posted Feb 24, 2014 2:55 UTC (Mon)
by plugwash (subscriber, #29694)
[Link]
BTW From reading debian-devel it seems like there are a number of people working on the problem of moving away from sysvinit style init scripts while still keeping support for multiple init systems.
Posted Feb 23, 2014 21:21 UTC (Sun)
by vonbrand (subscriber, #4458)
[Link]
The only option that makes any sense for Debian is A. But that has to be done anyway... I don't see the point of this (except for drawing out/kicking the decision to a GR).
Posted Feb 23, 2014 22:06 UTC (Sun)
by abket (guest, #95676)
[Link] (1 responses)
Almost all distributions have now adopted systemd as default, so almost everyone will run it, so we may as well take advantage of it.
Even if they were to choose L, almost nobody would test running without systemd (because everyone will use systemd), so in practice it will likely break often.
Posted Feb 24, 2014 8:07 UTC (Mon)
by jezuch (subscriber, #52988)
[Link]
I suppose the maintainers of non-Linux kernels will test run with something else than systemd, but yes, it's nearly impossible to test for everything with such limited manpower they have... (They also have the users, but pushing testing down to your users is not always such a great idea.)
Posted Feb 24, 2014 6:36 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (11 responses)
Posted Feb 24, 2014 8:40 UTC (Mon)
by rodgerd (guest, #58896)
[Link] (10 responses)
Posted Feb 24, 2014 9:17 UTC (Mon)
by hadrons123 (guest, #72126)
[Link] (1 responses)
Posted Feb 24, 2014 15:33 UTC (Mon)
by plugwash (subscriber, #29694)
[Link]
L has an explicit provision allowing it to be overrideen by a GR with simple majority.
Posted Feb 24, 2014 9:18 UTC (Mon)
by AngryChris (guest, #74783)
[Link] (7 responses)
Posted Feb 24, 2014 9:22 UTC (Mon)
by kugel (subscriber, #70540)
[Link]
Nobody wants to enforce tight coupling. The question is whether to allow it optionally. Therefore you advice multiple init support but DDs can ignore this advice on their own judgement and go for tight coupling (presumably, with reason).
Posted Feb 24, 2014 9:38 UTC (Mon)
by mbunkus (subscriber, #87248)
[Link] (2 responses)
I, as a very happy systemd user and proponent, am glad that there are people like Ian Jackson who look at the bigger picture and engage in a reasonable discussion on the advantages and disadvantages of concentrating on single init system. In a situation as emotionally charged as this debate it's relieving to see such an in-depth discussion among the TC members, and I regard all of them very highly for it.
Posted Feb 24, 2014 10:09 UTC (Mon)
by ovitters (guest, #27950)
[Link]
He doesn't want any tight coupling. I've invited various times on behalf of GNOME just to talk to us directly (in generic to ctte, in private and directly to Ian). I've asked various times to suggest concrete solutions (because I don't see them). All of that has been ignored.
Instead over and over again it is suggested that "upstreams are pushing systemd" (not true and it is starting to become questionable why this is still being repeated after all the communication from at least GNOME side), stuff about purposely not wanting to look at concrete examples (I find this utterly amazing) and something like "upstream has to listen to Debian" (while they're not responding when invited).
I see that Ian has great doubts, but when invited to talk about it, don't go hiding in a corner and cry wolf. My patience is getting thin. I expect that the vote won't go his way, but I tried over and over again that this vote is unneeded anyway. People do what is reasonable, if Debian decides on something I'll follow or not because of the reasoning, not because of "Debian says so" (that is not going to convince anyone).
IMO, it is becoming stop energy and that'll be ignored. He's more than capable to do things (provide/write alternative implementations, engage in technical discussion, etc). Same for other CTTE members. That is a fruitful way of dealing with this (technical work or discussion).
Now systemd is not just a GNOME issue, I know because I/we talk about it a lot it just seems to be viewed as a problem solely with us. Then you get the "GNOME is bad" and "you don't need that functionality" kind of reactions (not talking about Ian). But that's terribly easy way of dealing with things.
I don't see this vote going anywhere. It'll go to a GR anyway. While all the time could be used to properly explain what you want concretely to the various upstreams. Now possibly after 2.5 years we'll get a short GR summary stating like "you cannot depend on systemd" which we'll respond with as "we don't" and "whatever" (especially after trying to start a communication so many times).
Posted Feb 24, 2014 18:51 UTC (Mon)
by rodgerd (guest, #58896)
[Link]
His concerns may be very real, but they (a) are heavily obscured by his tactics and (b) seem to go beyond Debian and into the broader free software world, as far as I can ascertain them. But I'm not sure I can, because of (a).
Posted Feb 24, 2014 14:13 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
And the outcome is good, IMO.
Posted Feb 24, 2014 14:49 UTC (Mon)
by martin.langhoff (subscriber, #61417)
[Link]
As others have posted here, even if you don't like systemd, once it has been chosen, you have to let folks implement it without unnecessary entanglements.
For all its faults, systemd is way better defined than SysV scripts; has a couple of APIs with a promise of stability and systemd authors and the many implementors involved have tamed the problem space. IOWs, it will be easier to replace systemd than it was to replace the jungle of SysV scripts.
... and that upstart implementors never tamed SysV is, in my analysis, their largest failure. There were reasons, I guess, with Ubuntu being downstream of Debian and not wanting to carry all those patches. The end result, however, was that upstart did not get to maturity.
Hats off to all the folks who rowed the boat hard to get systemd unit files all across the early distros (fedora et al), and pushed on systemd to mature early while it was still malleable. It worked.
[ I have worked extensively with both upstart and systemd. Like many others, working up close with it made me overcome my early dislike of systemd. It looks odd at the beginning, and the author might rub you the wrong way. But it is the right design, and it has the momentum. Not unlike git. Get over it -- the best solution, not the sweetest soul, wins. ]
Posted Feb 24, 2014 18:50 UTC (Mon)
by rodgerd (guest, #58896)
[Link]
He voted UL ahead of UT in his original megaballot, so I don't think this is a particularly fair characterisation.
Posted Feb 24, 2014 22:18 UTC (Mon)
by bojan (subscriber, #14302)
[Link] (6 responses)
Posted Feb 24, 2014 23:25 UTC (Mon)
by bluss (guest, #47454)
[Link] (5 responses)
Posted Feb 25, 2014 1:37 UTC (Tue)
by bojan (subscriber, #14302)
[Link] (4 responses)
Posted Feb 25, 2014 2:18 UTC (Tue)
by HelloWorld (guest, #56129)
[Link]
Posted Feb 25, 2014 2:19 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
Once you get /usr/bin and /bin merged, let's get /usr/bin and /usr/sbin merged :D .
Posted Feb 25, 2014 7:46 UTC (Tue)
by mbunkus (subscriber, #87248)
[Link] (1 responses)
[0 mbunkus@chai-latte ~] ls -ld /{s,}bin /usr/{s,}bin
Posted Feb 25, 2014 8:11 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link]
Posted Feb 25, 2014 17:54 UTC (Tue)
by louie (guest, #3285)
[Link]
Posted Feb 25, 2014 22:22 UTC (Tue)
by josh (subscriber, #17465)
[Link] (1 responses)
See https://lists.debian.org/debian-ctte/2014/02/msg00585.html and https://lists.debian.org/debian-ctte/2014/02/msg00586.html .
Given that nobody *asked* the technical committee to rule on the question of "init system coupling" (only on what init system Debian should use), and it only came up because some members of the TC took issue with it themselves, refusing to rule on the unasked question seems like a good outcome here.
Posted Feb 26, 2014 13:48 UTC (Wed)
by Jonno (subscriber, #49613)
[Link]
Actually, the question *was* formally asked by a constitutionally delegated Policy Editor (Russ Allbery), though only after bystanders asked the TC to defer to the Policy maintainers on the matter.
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
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.
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
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
Debian TC vote on init system coupling
Debian TC vote on init system coupling
[2] http://www.freedesktop.org/wiki/Software/systemd/Interfac...
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
I don't know what Ubuntu's policy is, but it looks like loose coupling to me.
I think that writing that systemd unit is going to be left to the local administrator.
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
And systemctl make it dead simple to see where from configuration is gathered.
$ systemctl status gdm
gdm.service - GNOME Display Manager
Loaded: loaded (/usr/lib/systemd/system/gdm.service; enabled)
…
$ systemctl status privoxy
privoxy.service - Privoxy Web Proxy With Advanced Filtering Capabilities
Loaded: loaded (/usr/lib/systemd/system/privoxy.service; enabled)
Drop-In: /etc/systemd/system/privoxy.service.d
└─after-tor.conf
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 distribution provides basic systemd units below /usr, and local changes to those systemd units, or all-new systemd units, go into /etc. Systemd figures out how these go together, and provides tools that make it easy to find the effective configuration that is actually being used. It is actually quite nifty.
Debian TC vote on init system coupling
Debian TC vote on init system coupling
/etc/systemd/system/httpd.service.d/restart.conf
Restart=always
RestartSec=30
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
IOW, I don't think you understand what this vote is about.
Debian TC vote on init system coupling
Debian TC vote on init system coupling
It seems like the idea is to discourage use of kernel features like cgroups, namespaces, priorities, etc. because they are trivial to use with systemd but harder and less standardized to use by hand and requiring every developer to write management frameworks for these feature is additional work than just letting systemd do it, helping keep these features unpopular makes other kernels more competitive with Linux and the software more portable to other systems.
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
Whether anyone would want to run or enjoying running it is another matter.
Debian TC vote on init system coupling
Debian TC vote on init system coupling
> kind of decision or statement that could be used as a part of a strong
> argument by systemd sceptics in the GNOME community
Debian TC vote on init system coupling
Wol
Debian TC vote on init system coupling
Debian TC vote on init system coupling
> * special-use packages such as managers for init systems
Debian TC vote on init system coupling
I am referring to this, nye:
Debian TC vote on init system coupling
Debian's technical committee starts another init system vote [LWN]
== dependencies rider version T (Tight coupling) ==
Software may require a specific init system to be pid 1.
However, where feasible, software should interoperate with
all init systems; maintainers are encouraged to accept
technically sound patches to enable interoperation, even if it
results in degraded operation while running under the init system
the patch enables interoperation with.
== dependencies rider version L (Loose coupling) ==
Software outside of an init system's implementation may not require
a specific init system to be pid 1, although degraded operation is
tolerable.
Maintainers are encouraged to accept technically sound patches
to enable improved interoperation with various init systems.
So no, you are misunderstanding me. Does the above quote make things more clear?
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
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
Next flame war, please...
Next feature to import
Why stop there?
Why stop there?
Why stop there?
Why stop there?
lrwxrwxrwx 1 root root 7 31. Mai 2013 /bin -> usr/bin/
lrwxrwxrwx 1 root root 7 31. Mai 2013 /sbin -> usr/bin/
drwxr-xr-x 1 root root 81396 21. Feb 15:53 /usr/bin/
lrwxrwxrwx 1 root root 3 31. Mai 2013 /usr/sbin -> bin/
Why stop there?
Mailing list archives?
Debian TC vote on init system coupling
Debian TC vote on init system coupling