The Debian init system general resolution returns
| From: | Ian Jackson <ijackson-AT-chiark.greenend.org.uk> | |
| To: | debian-vote-AT-lists.debian.org | |
| Subject: | Re-Proposal - preserve freedom of choice of init systems | |
| Date: | Thu, 16 Oct 2014 16:05:41 +0100 | |
| Message-ID: | <21567.57029.724173.958520@chiark.greenend.org.uk> | |
| Archive‑link: | Article |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I wish to propose the following general resolution, and hereby call for seconds. This GR resolution proposal is identical to that proposed by Matthew Vernon in March: https://lists.debian.org/debian-vote/2014/03/msg00000.html and the substantive text is that which was drafted for the purposes of the technical committee's vote (where they decided not to pass a resolution on the subject). IMO developments since March show that the concerns put forward then were well-founded. Following discussions elsewhere including -devel I have received enough offers of seconds by private email. As Matthew said, I don't think further lengthy discussion of the issues is likely to be productive, and therefore hope we can bring this swiftly to a vote. This is particularly true given the impact on the jessie release. Thanks, Ian. ** Begin Proposal ** 0. Rationale Debian has decided (via the technical committee) to change its default init system for the next release. The technical committee decided not to decide about the question of "coupling" i.e. whether other packages in Debian may depend on a particular init system. This GR seeks to preserve the freedom of our users now to select an init system of their choice, and the project's freedom to select a different init system in the future. It will avoid Debian becoming accidentally locked in to a particular init system (for example, because so much unrelated software has ended up depending on a particular init system that the burden of effort required to change init system becomes too great). A number of init systems exist, and it is clear that there is not yet broad consensus as to what the best init system might look like. This GR does not make any comment on the relative merits of different init systems; the technical committee has decided upon the default init system for Linux for jessie. 1. Exercise of the TC's power to set policy For jessie and later releases, the TC's power to set technical policy (Constitution 6.1.1) is exercised as follows: 2. Loose coupling of init systems 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. 3. Notes and rubric This resolution is a Position Statement about Issues of the Day (Constitution 4.1.5), triggering the General Resolution override clause in the TC's resolution of the 11th of February. The TC's decision on the default init system for Linux in jessie stands undisturbed. However, the TC resolution is altered to add the additional text in sections (1) and (2) above. ** End Proposal ** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJUP96EAAoJEOPjOSNItQ05JYcH/367UqEXLQ3BkWdm2nIGeNN2 rAkdFTso+H3qckCIZnltbWuV+2cZmqXAFac627GoT2hvnu4KwrsiKgyu1PInVWPh 0XUt/8eeR95v2B9JYMuOSlxOOPLwgRZLpJ7vtd1pEU+Skrml0hoHFPCqbrFFathz K92Kv6HFd5v9vgc1nJir719wZ0zZe20ChSRc8wyMCaM68kddnmRJcpyWF7A3o2jD 9M4coOVlBQRt7kAu65LHV72OcjJbWq4qGeTIxBIExk1nWKNLRYEOHveF7nSaiLxk D4t0466fknL23SYukhpRSjAdcr6/3tHp7pbZGBHQfrszyb1pQvzL1oNGgBUn4dw= =eHpN -----END PGP SIGNATURE----- --
Posted Oct 17, 2014 5:54 UTC (Fri)
by flewellyn (subscriber, #5047)
[Link] (46 responses)
Posted Oct 17, 2014 6:15 UTC (Fri)
by cebewee (guest, #94775)
[Link] (45 responses)
Posted Oct 17, 2014 6:50 UTC (Fri)
by jspaleta (subscriber, #50639)
[Link] (44 responses)
There isn't even a current active bug at the heart of this...its a policy fix for integration problems that have come up and already been resolved through existing collaboration. I have some modicum of faith that that the vote will not pass... and technical issues will be resolved as they come up in the future as the have thus far been dealt with.
This GR is effectively an unfunded mandate of the worst kind, there's no man power in place to deal with the RC bugs this GR will create in the future. And moreoever I don't really think anyone knows what the secondary impacts of this GR will be if it passes. There could be some very critical stuff that doesn't work with one of the alternative toy inits already in the repo. It's not like people actively test full workloads with minit. But this GR doesn't really make a distinction between toy and full featured inits or place the value of one init over another. So if something doesn't work with minit but works with sysvinit right now.. it becomes a blocker as an unintended side effect. And that's just super silly.
Posted Oct 17, 2014 7:21 UTC (Fri)
by josh (subscriber, #17465)
[Link] (38 responses)
systemd-shim already exists, and will continue to exist as long as developers take the time to maintain it. If the shim stops drawing enough developer interest to maintain ongoing compatibility, then it will stop working naturally. This GR will not magically make such interest materialize.
Posted Oct 17, 2014 10:36 UTC (Fri)
by man_ls (guest, #15091)
[Link] (37 responses)
Posted Oct 17, 2014 13:33 UTC (Fri)
by yaap (subscriber, #71398)
[Link] (36 responses)
Seriously, there are big transitions on-going or soon to come in the Linux user space. Init/systemd discussed here, but later X/Wayland and also filesystems with btrfs (whose features may be increasingly used by other software, and become expected at some point in the future). Big transitions like this are never free and perfectly smooth, let's not kid ourselves. But at some point a majority will want to move forward, and it will happen.
It's perfectly fine not to like any such big change. Any person ok with the previous situation will suffer some instability and changes (learning/retraining has some cost) and even loose some particular feature. This person has the right to be unhappy about the change. But then it is NOT ok IMHO for such person to feel entitled to continuing support of the old platform, or even worst to coerce people in on-going support by playing tricks like this GR.
1) stick with older/stable distros for as long as the transition take, and jump only after the dust has fully settled. You will still migrate, with some cost, but minimize the impact this way;
2) actively support the old scheme to keep it alive. Either by your work or by funding people.
Here, this GR wants to force others to do what Ian wants. This is just not acceptable IMHO.
BTW: I expect the Linux world to be rocky for a few years, with all the big transitions I mentioned above. As far as I'm concerned I'll stick to Debian and I'm tracking Jessie/testing and despite the odd glitch am ok with it. I believe in the end it'll be fine. I like the idea of an init/platform configuration system that supports a dynamic environment like a modern device or server container, I like the prospect to have a secure graphic environment at last and I like cheap snapshots, send/receive and integrity. I'm sure not everything that will happen will be to my taste, but hey considering all I get for free I'm not complaining.
Posted Oct 17, 2014 21:48 UTC (Fri)
by man_ls (guest, #15091)
[Link] (1 responses)
I don't feel entitled to any of it, and I'm open to some degree of breakage since I'm using testing. But I will be very sad if decades of rock-solid stability go away, just for changing init systems -- which IMHO is not such a big advantage. No doubt other people have different priorities, but the point is: Debian has usually progressed forward slowly and smoothly, but without pause; and they should not burn devs and users alike because of a sudden urge to do some particular change. So on the surface, this GR looks like the right thing to do.
Posted Oct 18, 2014 1:18 UTC (Sat)
by misc (subscriber, #73730)
[Link]
Posted Oct 19, 2014 1:25 UTC (Sun)
by zblaxell (subscriber, #26385)
[Link] (33 responses)
In some ways they are very similar. btrfs has an in-place migration tool from ext4 that almost works, and with LVM snapshots and merging the transition can be made almost live. We can't mount two copies of the same btrfs on the same kernel because of the way btrfs assembles multi-device filesystems in the kernel using UUIDs--a limitation that firmly closes the door on several existing disaster recovery and data management procedures. I don't disagree that the systemd transition experience is similar to the upcoming btrfs transition experience. They're both awful.
Right now only fools and filesystem geeks put hard dependencies on btrfs. I am a filesystem geek, so I have dozens of btrfs filesystems. Nothing in btrfs works properly. It has been 0 months since the last commit to fix filesystem-corrupting in bugs basic Unix filesystem features like rename() and fsync(), 1 week since I last had to rebuild a btrfs filesystem from backups using mkfs and rsync because of metadata corruption that btrfsck couldn't repair, 2 days since I had to clean up data corruption on a btrfs filesystem that passes btrfs scrub and check, 1 day since I hit a kernel-crashing BUG() in the brtfs code, and 0 days since I last had to reboot a machine because of assorted hang bugs that still exist in the rename() and mkdir() system calls of 3.17.1. And all that covers just the core filesystem features that ext4 and xfs can already do with better performance. New features like snapshots and send that might be attractive to application developers work even less well (and are already implemented in an incompatible way by ZFS).
At the moment, if someone said I must use btrfs and exclude any other choices, my answer--and the answer of any sane distro maintainer--would be "hahaha no." Each day that passes makes FUSE implementations of the btrfs features (yes, they exist!) on top of any other existing filesystem seem more attractive. I don't doubt that btrfs will get better, but I do doubt whether it will get better fast enough to capture the interest of application developers who might notice that all these features work in ZFS today, and never look back.
I'm not sure why systemd--which is 1/3 the age of btrfs and whose behavior has greater impact on much more than mere storage--should be treated with less skepticism. I would (and have!) adopt btrfs before systemd, simply because I can choose to use as much btrfs--or as little--as I like, without changing distros or even rebooting.
When systemd gets to the point where it can coexist with other software with overlapping functionality--as X11 and btrfs can do--there is literally no reason to object to systemd any more. I don't see why this concept is so hard for systemd people to understand, or why they haven't bothered to fix their implementation yet.
Posted Oct 19, 2014 3:16 UTC (Sun)
by pizza (subscriber, #46)
[Link] (30 responses)
Maybe because systemd doesn't eat your data if something goes awry?
Maybe because, with systemd, they've produced something that, at the very worst, is just as reliable as what it replaces?
> I don't see why this concept is so hard for systemd people to understand, or why they haven't bothered to fix their implementation yet.
Oh, it's pretty simple -- what you consider a "bug" to be "fixed" is a deliberate, fundamental design decision that the entire project is built around.
Posted Oct 19, 2014 6:53 UTC (Sun)
by zblaxell (subscriber, #26385)
[Link] (26 responses)
systemd's own bug tracker contains a number of examples where systemd is worse than the things they are replacing. Aggregating failure modes and moving them up the process tree is objectively not better than leaving the failures distributed around the leaves.
The idea that systemd's monolithic design is fundamental to anything is absurd. systemd-shim is one counterexample. Just delete the cgroup code from systemd for another.
Linux now has a prctl(PR_SET_CHILD_SUBREAPER) so you don't need to be PID 1 to reap orphan processes. That was the single and only reason systemd ever needed any part of itself to be PID 1, and it no longer exists. Add ten lines of code to use the prctl, delete all the code that checks for PID 1 (holy crap there is a lot of it), and that bug is fixed.
Seriously, systemd people. Respect valid criticism and revisit the design. If the systemd maintainers would stop insisting that its implementation-convenience hacks are immutable design decisions then we'd all be more than willing to help systemd move forward. Right now it's pointless to try to work with the project--the biggest current problems are the ones the systemd maintainers alone refuse to solve.
Posted Oct 19, 2014 7:36 UTC (Sun)
by mchapman (subscriber, #66589)
[Link] (20 responses)
Given that this was introduced by Lennart Poettering specifically so that they could support per-user systemd instances, I'm pretty sure the systemd developers are well aware of it.
> That was the single and only reason systemd ever needed any part of itself to be PID 1, and it no longer exists. Add ten lines of code to use the prctl, delete all the code that checks for PID 1 (holy crap there is a lot of it), and that bug is fixed.
I don't think that really solves much. It certainly complicates things quite a bit.
If this non-PID-1 systemd were to crash, then its children would be reparented by the real PID 1. But even if this real PID 1 were to start up a new systemd, it wouldn't be able to reparent the children back to that. A new non-PID-1 systemd would not be able to manage processes forked from the previous non-PID-1 systemd. The real PID 1 would have no option but to go into a dumb "only wait for children" mode... which is close to what systemd does already when it receives a crash-worthy signal.
At least with systemd running as PID 1 it's protected against fatal signals for which it has no configured handler (e.g. SIGKILL).
Posted Oct 25, 2014 1:18 UTC (Sat)
by zblaxell (subscriber, #26385)
[Link] (19 responses)
I find your perception of the relationship between systemd and other people sharing a machine with it to be...disturbing.
I'm mostly concerned with the ability to run systemd under some kind of supervisor without having run a full VM or build that supervisor into systemd itself (self-supervision isn't). Since systemd does everything, different systemd instances would have to be able to do different parts of what a monolithic systemd does, but they would be isolated from each other by cgroups, namespaces, and so on, enforcing that isolation from outside.
When that supervisor wants a systemd process dead, it's a bug when that systemd process is anything but dead. All this talk about surviving fatal signals is missing the point.
Fatal signals aren't the problem I collide with. Re-exec failure is, and the only way to solve that is to not be PID 1. What happens to systemd if an upgrade fails due to a bug?
Posted Oct 25, 2014 2:31 UTC (Sat)
by viro (subscriber, #7872)
[Link] (18 responses)
More interesting class of bugs stems from the systemd propensity to spew^Wdistribute tons of information to the rest of the system. Extra complexity in a sensitive place is only a part of the problem - much worse is that if dbus-daemon can't keep pace with it, the backlog is stored in memory of PID 1 until it can be sent. Now, recall what makes PID 1 special from the OOM killer point of view...
And no, it's not a pure theory - I've run into one of the bugs in that class; a lot of umount activity going on (e.g. on shutdown with several thousand bindings present in the system) ended up with quadratic amount of dbus traffic. The damn thing kept resending the entire mount table every time it saw a change. Welcome to 8G of dirty memory held by PID 1... Basically, they were too lazy to compare the old and the new tables and send a proper delta. Sure, fixing that one hadn't been hard, but the underlying architectural deficiency is still there.
_Anything_ that convinces systemd to generate a major spew is likely to take the system down. From what I've heard they had an earlier bug of the same kind; this one - with spew consisting of network device information.
It's not so much systemd codebase fault as one of the reasons why dbus is not suitable for high-volume traffic, combined with systemd using it for potentially huge amounts of such with PID 1 as originator. And no, bringing that festering shitpile of protocol into the kernel won't make the things any better - dbus is broken by design.
Posted Oct 25, 2014 2:48 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (17 responses)
PS: no, Plumber is not in any way better.
Posted Oct 25, 2014 3:22 UTC (Sat)
by viro (subscriber, #7872)
[Link] (16 responses)
PID 1 is in extremely *bad* position for keeping track of everything and sending reliable notifications of everything. No mechanism would really help with that; it's just that dbus pretends to provide one that will cope with such demands. It can't. Neither can kdbus.
Every time somebody finds a way to trigger a huge amount of traffic originating at PID 1, it's a serious bug. And they insist on keeping track of a lot of system state in PID 1, with all kinds of traffic being sent. Asking for trouble...
Posted Oct 25, 2014 3:59 UTC (Sat)
by raven667 (subscriber, #5198)
[Link] (7 responses)
Posted Oct 25, 2014 4:47 UTC (Sat)
by viro (subscriber, #7872)
[Link] (6 responses)
And yes, _that_ particular bug had been fixed - current systemd (since March or so) doesn't produce quadratic amount of traffic in that situation. My point is that _anything_ that tricks it into hosing the bus with shitloads of traffic will cause the same kind of problem, kdbus or no kdbus.
IOW, it's something they have to watch out for, and sending a lot of stuff (a lot of kinds of stuff, even) as part of normal operation, expected by the rest of the system, is seriously asking for trouble.
Posted Oct 25, 2014 6:15 UTC (Sat)
by viro (subscriber, #7872)
[Link] (5 responses)
The point being, bugs happen; the architectural mistake there is what's making them a lot more severe. Namely, the use of dbus to send notifications of many kinds of system state changes as they are happening, with PID 1 as sender. And one *still* can trigger obscene amount of traffic there - mount tmpfs on /tmp/a, create a bunch of bindings in /tmp/a/* and then keep doing mount --move /tmp/a /tmp/b; mount --move /tmp/b /tmp/a. Nowhere near as bad as "it panics on shutdown when there's a lot of mounts", but the same "let's keep telling dbus-daemon about those changes, no matter what" easily translates into severe slowdowns and OOMs. Single syscall, done in constant time kernel-side, ends up with massive dbus spam, and no throttling. Moreover, the processes receiving those notifications can bloody well get the same information themselves, and do it cheaper...
Posted Oct 25, 2014 14:56 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Nov 2, 2014 15:27 UTC (Sun)
by nix (subscriber, #2304)
[Link] (3 responses)
The same applies to anything at all related to network interfaces.
Presumably this traffic is meant to be consumed by udev, i.e. it's a replacement for the existing in-kernel uevent messages over the netlink socket. Seems like a rather baroque, ludicrous, and bug-prone change to me.
Posted Nov 2, 2014 16:33 UTC (Sun)
by raven667 (subscriber, #5198)
[Link]
Posted Nov 2, 2014 17:08 UTC (Sun)
by viro (subscriber, #7872)
[Link] (1 responses)
There's a very strong smell of PHB all over the design. Worse, a PHB that had been told by some conslutant about Web 2.0 and social media being The Thing for millenial generation and decided to have a local equivalent of twitter built for communication with the plebes. It doesn't work well? Why, let's move it to the critical servers; those are on beefier intertubes, or something... Still doesn't work well? Too fucking bad for those who maintain those servers - it's their responsibility now (and of course, any questions regarding the basic design of the damn thing are countered with generous loads of "we had it behave that way before, therefore it must behave the same").
And yes, I am talking about dbus and plans of moving it kernel-side ;-/
Posted Nov 2, 2014 21:35 UTC (Sun)
by johannbg (guest, #65743)
[Link]
That nack of his was a bit weird if you ask me but I guess I need to sacrifice a chicken, dance on one foot and drink some of that kernel koolaid to get my mind into the kernel cult and communication.
Posted Oct 25, 2014 6:03 UTC (Sat)
by johannbg (guest, #65743)
[Link] (3 responses)
The underlying problem is the same basically parallelizing X where X can = d-bus, sockets, file system jobs, you name it.
"PID 1 is in extremely *bad* position for keeping track of everything and sending reliable notifications of everything. No mechanism would really help with that"
So let's hear it based on the function of PID-1 how would you do it if not PID 1?
What architectural design do you have in mind to solve this?
Posted Oct 25, 2014 6:38 UTC (Sat)
by viro (subscriber, #7872)
[Link] (2 responses)
And if you do insist on IPC, for some reason, you could bloody well start a caching daemon on demand (with e.g. timeout for inactivity). There's no reason whatsoever to keep that in PID 1 or anywhere near it.
We already have mechanisms for parallelizing. Had them for more than four decades. Called "processes"...
Having systemd forwarding a bunch of stuff it gleans from the kernel is asking for bottlenecks, for no good reason. System calls are not going away; not unless you want a truly monumental bottleneck with systemd playing the role of Mach server. Even then read(2) and open(2) wouldn't disappear, including those of /proc/self/mountinfo...
Posted Oct 25, 2014 8:40 UTC (Sat)
by johannbg (guest, #65743)
[Link] (1 responses)
We have to agree to disagree on the push vs pull implementation.
Posted Oct 25, 2014 19:23 UTC (Sat)
by dlang (guest, #313)
[Link]
Posted Oct 25, 2014 15:13 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
Systemd uses a protected DBUS interface, so if you're able to DDoS it then you already have enough capabilities to wreck the system. It's not a fatal flaw in the design.
Also, it looks like KDBUS can help to throttle the senders - the regular DBUS daemon can't really do it cleanly.
Posted Nov 2, 2014 15:28 UTC (Sun)
by nix (subscriber, #2304)
[Link] (2 responses)
Or they could read /proc/self/mounts or /proc/self/mountinfo and get an always-reliable, namespace-aware view with none of this nonsense.
Posted Nov 2, 2014 17:09 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Besides, netlink sockets can block senders just as well as kdbus.
Posted Nov 2, 2014 17:31 UTC (Sun)
by viro (subscriber, #7872)
[Link]
Posted Oct 19, 2014 12:35 UTC (Sun)
by cortana (subscriber, #24596)
[Link] (1 responses)
I believe the problem with this approach is that if a non-pid-1 process with 'child subreaper' dies, all its children are reparented to pid 1, and there's no way for the restarted process to get back to the same state it was in before.
OTOH, you could take the approach that in that case, the real pid 1 kills everything before restarting the child, so it would be a bit like a crash followed by a fast reboot. That would be interesting to see.
Posted Oct 19, 2014 21:45 UTC (Sun)
by neilbrown (subscriber, #359)
[Link]
Not quite. The children are reparented to the next child-subreaper up the process tree, which will often be pid-1.
systemd could run normally as a parent and a child, both of which are 'child subreapers'. If the child dies, the parent re-starts it and feeds the new child any completion information for other processes that exit.
Posted Oct 19, 2014 15:11 UTC (Sun)
by misc (subscriber, #73730)
[Link] (2 responses)
And so far, I do use systemd since a few years now and it only caused me a fatal issue only once on a rawhide system. I had worst report of problem on btrfs. People keep repeating this as if there was lot of crash, but so far, the evidence do not indicate so.
Posted Oct 19, 2014 17:07 UTC (Sun)
by raven667 (subscriber, #5198)
[Link] (1 responses)
Posted Oct 25, 2014 2:13 UTC (Sat)
by zblaxell (subscriber, #26385)
[Link]
The same can be said of the Linux kernel, but I still greet each release with a full dose of well-deserved skepticism.
For what it's worth, I stick to discussions about the problems with systemd I've personally discovered. Other people have written at length about the ones I haven't.
I've used some of those millions of systems you're talking about. When they work they're OK, but in a crisis, a lot of surprising and disruptive behavior gets in the way of response, which is why I still choose to not run any outside of a test lab. Arguably the "surprising" part can be fixed with experience, but "disruptive" can only be fixed by patches (patches to default unit files that you have to install on every machine are still patches).
Posted Oct 19, 2014 14:45 UTC (Sun)
by flussence (guest, #85566)
[Link] (2 responses)
The same can be said of Btrfs — with a slight difference in the storage world though, nobody sane would run a system of two dozen interdependent moving parts with no redundancy or backups and expect it to stay working for long.
Posted Oct 20, 2014 0:31 UTC (Mon)
by pizza (subscriber, #46)
[Link] (1 responses)
> The same can be said of Btrfs
No, it can't.
Posted Oct 24, 2014 22:16 UTC (Fri)
by flussence (guest, #85566)
[Link]
I've been a bit more forgiving of other filesystems since then, since the de-facto standard has forced me to *really* lower my own standards.
Posted Oct 25, 2014 12:25 UTC (Sat)
by ms_43 (subscriber, #99293)
[Link] (1 responses)
In other words, this is purely a downstream distro packaging / policy issue. Why do you think that there is an onus on "systemd people" to "understand" or "fix their implementation" here?
Posted Oct 25, 2014 14:24 UTC (Sat)
by rahulsundaram (subscriber, #21946)
[Link]
https://fedoraproject.org/wiki/Fedora_14_talking_points#S...
Posted Oct 17, 2014 10:45 UTC (Fri)
by juliank (guest, #45896)
[Link] (4 responses)
Posted Oct 17, 2014 11:54 UTC (Fri)
by smurf (subscriber, #17840)
[Link] (3 responses)
Posted Oct 18, 2014 0:17 UTC (Sat)
by ewan (guest, #5533)
[Link] (2 responses)
It's mostly a good system, but it does rather rely on the idea that everyone involved is acting with good faith and this is not that. It's a wholly destructive lashing out - not an attempt to improve anything, just to damage a project that's doing something Ian hates. The previous rounds of this argument were messy, but they were just part of the process; this is an abuse of process, and I don't see how Debian can tolerate this behaviour and still hope to retain the ability, credibility, and respect to be able to do what it's always done.
Posted Oct 18, 2014 1:04 UTC (Sat)
by anselm (subscriber, #2796)
[Link] (1 responses)
German political activist Rosa Luxemburg is credited with the quote, “Freedom is always the freedom of those who think differently“. Ian Jackson and his seconders are 100% free to propose a GR even if it seems ill-advised and basically flogging a horse that is practically fossilised by now. This shouldn't reflect badly on the project as a whole, as the project is simply upholding its ideals by allowing its members to introduce GRs, even ill-advised ones, in accordance with Debian's constitution as they see fit. If anything it reflects badly on Ian Jackson's good judgment for bringing the issue up right now, when he could have done it months ago or else waited after the Jessie release.
Posted Oct 20, 2014 6:43 UTC (Mon)
by tuomasjjrasanen (guest, #86050)
[Link]
This is probably one of the most valuable comment in this thread.
It's about freedom to think differently and freedom to disagree with others. And it works both ways. That is why it is Debian.
Posted Oct 17, 2014 8:03 UTC (Fri)
by niner (subscriber, #26151)
[Link] (27 responses)
Posted Oct 17, 2014 8:10 UTC (Fri)
by josh (subscriber, #17465)
[Link] (26 responses)
Posted Oct 17, 2014 8:26 UTC (Fri)
by mgb (guest, #3226)
[Link] (3 responses)
All of the software in Wheezy works without systemd.
Except where it has been deliberately broken, all of that software would work in Jessie without systemd.
Posted Oct 17, 2014 8:50 UTC (Fri)
by josh (subscriber, #17465)
[Link] (1 responses)
The interesting case comes up when no patch exists or is forthcoming. The proponents of this GR would have the packages removed or otherwise held hostage to force the maintainer to add support for sysvinit, with no provisions for software that actively used and depends on systems features.
Posted Oct 17, 2014 9:10 UTC (Fri)
by josh (subscriber, #17465)
[Link]
s/systems/systemd/
Posted Oct 18, 2014 10:54 UTC (Sat)
by BenHutchings (subscriber, #37955)
[Link]
Posted Oct 17, 2014 9:18 UTC (Fri)
by smurf (subscriber, #17840)
[Link]
Posted Oct 18, 2014 20:40 UTC (Sat)
by jch (guest, #51929)
[Link] (20 responses)
I'm confused. You're not implying that Ian Jackson does no real work, I hope?
Posted Oct 20, 2014 0:30 UTC (Mon)
by josh (subscriber, #17465)
[Link] (19 responses)
A GR won't make support magically materialize, and if such support already exists, a GR isn't necessary to obtain contributions from it. So, this GR is either futile or redundant, and either way it's a giant waste of everyone's time.
Posted Oct 20, 2014 2:13 UTC (Mon)
by mgb (guest, #3226)
[Link] (18 responses)
Everything in Wheezy works without systemd.
Anything in Jessie which now depends on systemd was deliberately broken.
Posted Oct 20, 2014 2:35 UTC (Mon)
by josh (subscriber, #17465)
[Link] (17 responses)
Such software is not "broken"; it works just fine with its dependencies (systemd, etc) installed. If you want it to work with other init systems, that is a wishlist feature request. The maintainer, or upstream, may choose to implement that feature request for you. You or someone else could also choose to submit a patch, and for the record, I do think maintainers should accept reasonable and maintainable patches.
The interesting case comes up when no patch exists or is forthcoming. The proponents of this GR would have the packages removed or otherwise held hostage to force the maintainer to add support for sysvinit, with no provisions for software that actively uses and depends on systemd features.
To give a parallel example: suppose you want to build a Debian system without glibc. You could attempt to make piles of software work with another libc implementation, and you'll sometimes run into bugs where software depends specifically on features of glibc. Such software is not broken for doing so; it simply avoided reimplementing glibc functionality to work with other libc implementations that don't have that functionality. You could submit patches for such projects, to make them build without glibc; some projects might take those patches. However, the bugs you might file are wishlist at best, and a maintainer would not be particularly unreasonable to close such a bug as wontfix if the patches needed to work with another libc are large, invasive, and not easily maintainable.
Posted Oct 20, 2014 3:30 UTC (Mon)
by mgb (guest, #3226)
[Link] (15 responses)
Debian doesn't need patches. We have the Wheezy source we can recompile.
We just need a GR to prevent systemd proponents from deliberately breaking things again.
Posted Oct 20, 2014 3:41 UTC (Mon)
by josh (subscriber, #17465)
[Link]
You seem to be either clue-resistant or deliberately ignoring my responses, and I have no further interest in arguing this further with you. I believe anyone reading the comment thread can see the point we're each trying to make, and evaluate each for themselves.
Posted Oct 20, 2014 7:39 UTC (Mon)
by tao (subscriber, #17563)
[Link] (2 responses)
Debian doesn't need patches. We have the Woody source we can compile.
We need a GR to prevent the proponents of recent versions of the kernel from deliberately breaking things again.
Posted Oct 20, 2014 9:51 UTC (Mon)
by josh (subscriber, #17465)
[Link] (1 responses)
It worked before without glibc. It doesn't work now without glibc. It was broken. Deliberately.
Debian doesn't need patches. We have the Bo source we can recompile.
We just need a GR to prevent glibc proponents from deliberately breaking things again.
Posted Oct 22, 2014 7:34 UTC (Wed)
by jordi (guest, #14325)
[Link]
Posted Oct 20, 2014 13:23 UTC (Mon)
by jrn (subscriber, #64214)
[Link] (10 responses)
Posted Oct 20, 2014 13:57 UTC (Mon)
by josh (subscriber, #17465)
[Link] (9 responses)
Posted Oct 20, 2014 14:10 UTC (Mon)
by jrn (subscriber, #64214)
[Link] (8 responses)
I was hoping someone could clarify what was broken, so it can get fixed in time for the release.
Posted Oct 20, 2014 14:17 UTC (Mon)
by jrn (subscriber, #64214)
[Link]
Especially when people disagree a lot and their identity seems to be wrapped up in a question, actual practical problems can be easier to solve than finding abstract principles to agree on.
Posted Oct 20, 2014 14:39 UTC (Mon)
by josh (subscriber, #17465)
[Link] (6 responses)
Posted Oct 20, 2014 14:52 UTC (Mon)
by johannbg (guest, #65743)
[Link] (5 responses)
Posted Oct 20, 2014 15:03 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
There is a ton of insightful guest comments here, so banning them is counter-productive. However, banning all the systemd-related threads might make sense. The SNR has become way too low in these threads.
Posted Oct 20, 2014 15:10 UTC (Mon)
by johannbg (guest, #65743)
[Link]
Posted Oct 22, 2014 19:48 UTC (Wed)
by Kamilion (subscriber, #42576)
[Link] (2 responses)
I don't have much money, but I do keep my LWN subscription running to pick up some of the most meaningful insight into the linux world and it's players.
So far, I think Raven667 summed it up best with:
So far most of what I've heard has been grunts of indifference, a couple 'oh thank god I can finally kill that horrible initscript hack', and only one outright dismissal of systemd from a hardcore gentoo'er I know.
But hey, I helped out Gerard Beekmans and Jessie Tie-Ten-Quee with the getting the first copies of Linux from Scratch out the door -- I understand my system enough to know why things are. I understand others may not necessarily have that clarity, nor do I fault them for not wishing to develop it. Humans are by nature self-specializing, after all.
Posted Oct 23, 2014 21:13 UTC (Thu)
by cdmiller (guest, #2813)
[Link] (1 responses)
Around here a few consternations expressed by sysadmins are the implementation of the binary log (corruption handling, reinvention of the wheel), lack of log shipping (yay let's run 2 loggers now), and a perception of "crazy feature creep" (one current joke/betting pool is when windows-registryd will appear).
In the server realm a couple precepts are stability generally trumps features and "sudden or quick" forklift changes to services are to be avoided if possible. If or when systemd becomes a problem or too much of a pain point our sysadmins will eventually route around it is the sysadmin feedback I receive at present.
Posted Oct 23, 2014 22:19 UTC (Thu)
by johannbg (guest, #65743)
[Link]
1. https://www.debian.org/vote/2014/vote_003
Posted Oct 20, 2014 21:57 UTC (Mon)
by rodgerd (guest, #58896)
[Link]
Posted Oct 17, 2014 8:19 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (14 responses)
Posted Oct 17, 2014 8:28 UTC (Fri)
by dgm (subscriber, #49227)
[Link] (13 responses)
Posted Oct 17, 2014 8:30 UTC (Fri)
by dgm (subscriber, #49227)
[Link] (4 responses)
Posted Oct 18, 2014 2:09 UTC (Sat)
by misc (subscriber, #73730)
[Link] (1 responses)
Posted Oct 18, 2014 16:22 UTC (Sat)
by weue (guest, #96562)
[Link]
Posted Oct 18, 2014 15:56 UTC (Sat)
by drag (guest, #31333)
[Link] (1 responses)
That's really the problem isn't it?
If Debian politics result in terrible design choices that over-complicate the OS while reducing it's effectiveness and make life harder for users and app developers; it doesn't matter if you care about Debian politics or not.
Posted Oct 20, 2014 7:28 UTC (Mon)
by dgm (subscriber, #49227)
[Link]
Can you point to some example?
Posted Oct 17, 2014 8:32 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (7 responses)
Posted Oct 17, 2014 10:37 UTC (Fri)
by man_ls (guest, #15091)
[Link] (6 responses)
Posted Oct 17, 2014 11:50 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (5 responses)
Of course, some people really care about food being prepared without certain components and in a certain way. And usually that's dictated by religion (kosher/halal food).
PS: ok, ok. I won't try to stretch the analogy further.
Posted Oct 17, 2014 21:34 UTC (Fri)
by man_ls (guest, #15091)
[Link] (4 responses)
In the second case you need to mess up with "meat processing", "politics" and other disgusting but necessary business. That is not always possible, especially with operating systems. In Debian we have the unique opportunity of having the factory guts completely exposed, and that's how we like it -- mostly because we can look inside and ask questions. And even get involved.
Posted Oct 17, 2014 23:00 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
I certainly don't want to run PCR on my lettuce to verify that it doesn't contain dangerous strains of bacteria. The same with RedHat - I don't want to look at every bit of code in the init scripts.
> In the second case you need to mess up with "meat processing", "politics" and other disgusting but necessary business.
With RedHat at least I clearly understand their goal: making a reliable Linux system for its customers.
Posted Oct 18, 2014 16:20 UTC (Sat)
by drag (guest, #31333)
[Link] (2 responses)
That's kinda like claiming you don't have to worry about computer security because you trust the NSA to take care of it for you. The USDA allows and supports all manner of unhealthy things to go on.
It's probably accurate to think of must of us here as 'chefs' or 'connaisseurs' since this is a highly technical oriented forum and we are professionally involved in software. Those sorts of professional food people, if they are any good, really do heavily care about who grows the food and how it's prepared and all sorts of details. Those are the people that have to care because it's their job to make sure their customers get healthy, tasty food.
> Yes, and I've lost trust in it.
This GR is very disappointing to say the least. I am not going to put that much emphasis on it, however. The reason for this is because, I suppose, anybody (with enough rights in the Debian org) can propose anything... even if it's silly. However if it gets squashed as silly pretty quickly then there is no harm done and there is no negative impact to the quality of Debian.
And, I guess, Debian's gears run slow. So it would probably be a good idea to avoid getting caught up in the drama and just ignore it for the time being. If in a few weeks it ends up being a disaster like the last time the systemd subject came up then I would consider that to be a big failure for Debian.
Posted Oct 18, 2014 17:26 UTC (Sat)
by misc (subscriber, #73730)
[Link]
I also have yet to hear about case of harassment of famous cooks by people who eat their food ( or even worst, by people who would receive a menu with their food ), so maybe the analogy between their community and our community is tenous.
Posted Oct 18, 2014 18:24 UTC (Sat)
by jwarnica (subscriber, #27492)
[Link]
They have no mandate to help non-US Government entities, but perhaps coincidentally do so. Entities producing products, processes or configuration that are not selling to the US Government have no requirement to involve the NSA (conspiracy theories aside).
The USDA is involved in all commercial meat production in the USA. It is illegal(??) to sell meat not USDA inspected. Now, it might not do a great job on ethics or health, but it does a job.
Not at all a comparable situation.
Posted Oct 17, 2014 8:39 UTC (Fri)
by johannbg (guest, #65743)
[Link] (3 responses)
Drop systemd-shim and other legacy bits and their support that needs dropping and go for a full systemd only integration, migrate what needs to be migrated and bear in mind that the timer units are only relevant to bootup,udev,unit startup,suspend,shutdown so if your component does not already depend on systemd but ships an cron job it should not be migrated.
Posted Oct 17, 2014 9:22 UTC (Fri)
by smurf (subscriber, #17840)
[Link] (2 responses)
Debian isn't going to do that any time soon.
Posted Oct 17, 2014 10:44 UTC (Fri)
by johannbg (guest, #65743)
[Link]
We all know that this yet another stunt by Ian is going to distract Debian's maintainers from preparing Jesse by forcing them to be debating this for atleast 2 weeks if not more and it would be a shame if Martin Pitt recent work [1] patching 215 in Ubuntu and reviewing some of Debian's patches cleaning them up in preparation for upstreaming would some how be stalled because of this political stunt of his.
[1] https://plus.google.com/107564545827215425270/posts/1jFJw...
Posted Oct 17, 2014 11:36 UTC (Fri)
by jmm (subscriber, #34596)
[Link]
Posted Oct 17, 2014 11:57 UTC (Fri)
by ovitters (guest, #27950)
[Link] (9 responses)
My summary:
It seems there are 10-15 seconds on this. Quite interesting to see the results. The text is very vague, strictly speaking it cannot be done (people who want the work done aren't doing the work). So I'm hoping the GR succeeds and then jessie gets delayed for 24 months followed by a new GR :-P (no problems with self inflicted drama)
Ian also mentioned that he is raising this GR because something which he wanted since March at least didn't materialize. IMO if he wanted something to be done, he or others interested should've done this. Seems instead it is time to dump it on someone else. :-P
Posted Oct 17, 2014 14:00 UTC (Fri)
by nowster (subscriber, #67)
[Link] (1 responses)
Yes, it is a late call. However, there is (currently) no package I know of that would automatically become RC if the GR passes. If that's the case, why the cry of "extra work"?
Posted Oct 17, 2014 14:12 UTC (Fri)
by ovitters (guest, #27950)
[Link]
People not doing work forcing other people to do the work. A former Debian project leader actually asked in private email not to get involved while Debian is deciding what they think upstream should do. Wtf.
Regarding "crying" (really?): The GR is because stuff needs changing. That's in the GR proposal already.
Posted Oct 17, 2014 14:42 UTC (Fri)
by jwiltshire (guest, #66212)
[Link] (1 responses)
There wasn't a previous GR, so there was no previous opportunity to vote.
Posted Oct 18, 2014 12:33 UTC (Sat)
by ovitters (guest, #27950)
[Link]
Posted Oct 17, 2014 17:58 UTC (Fri)
by jspaleta (subscriber, #50639)
[Link] (4 responses)
It was a very long discussion in March, and at the time pointing out serious deficiencies with the text and the implicit burden the policy put on maintainers. It seems none of the concerns expressed in that discussion were incorporated in the re-proposal at all. That's a bit unfortunate. Lucas's alternative proposal attempts to pick up where the discussion in March left off. Ian's proposal basically ignores the previous discussion entirely and takes the same text that was proposed in March.
So really its going to come down to whether the opponents to Ian's proposal are willing to step up and go another round and make the same critical and effective arguments they made last time in March. They can't just sit back and expect people to go back and read the previous discussion. Opponents are going to have to gear up and knock this proposal down again like the previous discussion and restate the same objections again.
I think someone should really make it a point to ask why Ian waited so very long to re-propose what is essentially the same thing that was withdrawn in March. I mean waiting till July or even August...for people to cool off, reset a bit and come at this again with a clear head. I can see waiting that long to repropose in good faith. Still gives everyone else a couple of months to deal with resulting workflow changes that might result. But now...it could be argued this is a deliberate attempt to throw a bomb into the jesse release process. I'm not sure this sort of behavior shouldn't be rewarded. It's not like this is an issue that came up suddently. This is very literally a re-proposal of a GR shoved into a desk drawn since March and dusted off just it in time to cause the biggest headache for everyone.
-jef
Posted Oct 18, 2014 12:40 UTC (Sat)
by Zack (guest, #37335)
[Link] (3 responses)
You mean the brute forcing of the hung vote by the chairman of the TC in favour of systemd, thereby cutting short the amendment "the opposition" was working on (which has now become this upcoming GR) specifically to allow for a conflict-less resolution by simple majority?
Posted Oct 18, 2014 14:20 UTC (Sat)
by anselm (subscriber, #2796)
[Link] (2 responses)
There was no “hung vote“ being “brute forced” in the TC. The Debian Constitution says that in cases such as this the chairman of the TC has the casting vote, and that is what eventually decided the matter. Everything happened according to the rules.
It's probably just as well to remember that the people who voted in favour of systemd did so after looking into it and the alternatives in considerable technical detail, while the people who voted in favour of Upstart mostly voted that way because they were the Upstart package maintainer in Debian or otherwise connected with Canonical. People like Russ Allbery, who eventually voted for systemd, generally came across as a lot more dispassionate and level-headed in the discussion than those who were against systemd. There were also various procedural shenanigans mostly instigated by Ian Jackson (including a motion to depose the TC chairman), who is also behind the GR currently being recycled.
Posted Oct 18, 2014 19:46 UTC (Sat)
by Zack (guest, #37335)
[Link] (1 responses)
No, it's what *directly* decided the matter, pre-empting the ongoing effort to find consensus through an amendment. "Eventually" it would have been decided by an amendment concerning loose/tight coupling, much like now, except with a lot less hostility and no need for a GR.
> It's probably just as well to remember [..]
Yes, there was a bit of a smear campaign where those in favour of systemd were hailed as technological visionaries whereas the others obviously must be driven by ulterior motives. In fact, it's just started again in this very thread: "I hope all the DD's understanding that the person proposing this is perfectly okay with the next Debian release getting delayed... indefinitely..."
> There were also various procedural shenanigans mostly instigated by Ian Jackson (including a motion to depose the TC chairman)
In as far as instigating a motion of no confidence against a chairman who derails and cuts short a good-faith effort to find consensus can be called "shenanigans". Seeing how Debian is looking at a GR to decide on the matter, maybe that chairman really did make a short-sighted decision back then.
Posted Oct 19, 2014 17:20 UTC (Sun)
by HelloWorld (guest, #56129)
[Link]
Posted Oct 17, 2014 14:00 UTC (Fri)
by xxiao (guest, #9631)
[Link] (2 responses)
Posted Oct 17, 2014 14:21 UTC (Fri)
by mrshiny (guest, #4266)
[Link] (1 responses)
/sarcasm
Posted Oct 19, 2014 20:15 UTC (Sun)
by javispedro (guest, #83660)
[Link]
Posted Oct 17, 2014 15:25 UTC (Fri)
by jb.1234abcd (guest, #95827)
[Link]
I hope that they kill the systemd(efeat) dragon, amend their unfortunate
Posted Oct 17, 2014 15:43 UTC (Fri)
by amacater (subscriber, #790)
[Link]
Original GR requested by Ian Jackson, amended by Lucas Nussbaum as Debian Project Leader.
Discussion period 17 October 2014 - 31 October 2014
If the voting period is, for example, one week, that puts the result as two days after the freeze date for Jessie on November 5 2014
Posted Oct 17, 2014 15:47 UTC (Fri)
by rahvin (guest, #16953)
[Link] (11 responses)
How can you have a GR that proposes violating one of the founding principles of Debian?
Posted Oct 17, 2014 16:42 UTC (Fri)
by mpr22 (subscriber, #60784)
[Link] (2 responses)
No part of the proposed general resolution seeks to impose any requirement on any maintainer. It seeks to impose requirements on the software that is packaged in Debian, and to encourage maintainers to accept assistance in making the software they maintain fulfil those requirements. A maintainer who, for whatever reason, did not want to do the work of making the packages they maintain compatible with all supported init systems would not be obliged by this GR to do the work; they would merely be required to abstain from work that would hinder other people seeking to make those packages compatible with all supported init systems.
Posted Oct 18, 2014 0:26 UTC (Sat)
by rahvin (guest, #16953)
[Link] (1 responses)
Forcing a volunteer maintainer to either remove the systemd dependency or their project is tossed from Debian sounds like an unfunded mandate to me and a violation of the Debian constitution. You can dance around it say they just have to stay out of the way but as the package maintainer they are supposed to have final say on all issues dealing with the package and this takes that away.
I don't see how this isn't spitting in the face of all the maintainers. It's an evil abuse of project processes to undo a technical decision that (from all appearances) a small minority of people in Debian disagree with.
Posted Oct 18, 2014 2:02 UTC (Sat)
by misc (subscriber, #73730)
[Link]
Posted Oct 17, 2014 17:06 UTC (Fri)
by johannbg (guest, #65743)
[Link] (1 responses)
I honestly dont know how deb-devs manage to put up with this.
It is extremely time consuming, disruptive and energy draining and at a time ( two weeks to rc ) when the whole community is supposed to be focusing on it's upcoming release *after* an already existing, time consuming exhausting discussion.
And for what?
For the freedom to chose between multiple init systems.
What does it mean having to support multiple init system in a Linux distribution these days.
It means..
Maintaining each init system by itself in the distribution
And
Maintaining cross compatibility with each init system
What the above here means
A) Fork all applications that upstream decide to drop in favour of using the feature systemd provides
B) Maintain compatibility between existing applications that take advantage of what systemd provides and those applications that Debian has chosen to become upstream for to be able to provide that maintainability for all of the multiple init system it provides.
C) Write and maintain their own alternative udev as well as alternative userspace which does initialization/policy/activation to kdbus and or maintain the existing alternative and dbus implementation.
In the case of the above I dont think people realize how much added load that is on the Debian community and it's maintainers.
Perhaps the Debian community has abundance of free resources to spare to do all this added work ( this also affects QA, release engineering etc ) in the name of choice but if not, I as an Debian maintainer was being forced having to maintain this I would simply orphan my component(s) and find another distribution to work on that already uses systemd and ships my component and help maintain it there since it would in turn free up my time since that maintenance work is now distributed between all distribution that use systemd while allowing those that choose supporting multiple init systems having to maintain all that themselves and the added load it brings.
Posted Oct 19, 2014 2:28 UTC (Sun)
by jrn (subscriber, #64214)
[Link]
This GR is about defining "buggy".
Posted Oct 18, 2014 0:48 UTC (Sat)
by russell (guest, #10458)
[Link] (5 responses)
Personally, I think it's the first. Systemd has a history of trying to usurp other peoples work. Forcing them into a particular way of doing things. It has no right to force that on others.
Posted Oct 18, 2014 1:40 UTC (Sat)
by jonabbey (guest, #2736)
[Link]
Posted Oct 18, 2014 8:58 UTC (Sat)
by hunger (subscriber, #36242)
[Link] (3 responses)
They did replace other peoples projects with something that is in their opinion better than what was there before. That is what basically all free software projects do. Or have you ever run into one that has the stated goal to build something worse than already available?
How can any free software force other people to do anything?
Is Lennart traveling around threatening developers to have them beat up if they do not integrate systemd? Considering that someone asked for bitcoins to hire someone to hurt Lennart, it is more the other way around.
Posted Oct 20, 2014 9:15 UTC (Mon)
by russell (guest, #10458)
[Link] (2 responses)
The TC is a small number of people. So far the larger community has not had a say. The reason they have general resolutions is because the TC is not always representative of the community.
Usurp... Systemd uses the embrace, extend, extinguish method that we are all very familiar with. It started as an init, it's now trying to take over network management, console management, device management, where will it end. Soon to do any task other than the systemd way will involve replacing the bulk of the operating system. We loose the ability to apply linux to all sorts of tasks. It ends in another version of windows. Useless.
Posted Oct 20, 2014 9:22 UTC (Mon)
by rahulsundaram (subscriber, #21946)
[Link]
Posted Oct 21, 2014 9:51 UTC (Tue)
by jezuch (subscriber, #52988)
[Link]
You make it sound like it's a bad thing. What's wrong with having network management, console management and device management integrated together? Seriously.
Also, it's nowhere near that disastrous state of affairs until it has an email client[1].
https://en.wikipedia.org/wiki/Jamie_Zawinski#Zawinski.27s...
Posted Oct 17, 2014 17:44 UTC (Fri)
by Lionel_Debroux (subscriber, #30014)
[Link]
systemd clearly isn't perfect, but sysvinit is no longer enough, upstart is worse than systemd (that's what I learnt in the previous episode), and nearly all other distros switched to systemd without plans of switching back to anything else, so it's not desirable to diverge from other distros.
As a Debian user making software that runs on Debian as part of my day job (and doesn't run in Wheezy because it would need way more backports), I really hope DDs will punt this GR...
Posted Oct 17, 2014 18:04 UTC (Fri)
by ctpm (guest, #35884)
[Link] (27 responses)
The systemd kool-aid drinking insanity has gone for too long, and it would be better to stop rather sooner than later. Applications should *not* care or be made to depend on what init system is in use, as much as possible. It should be clear that this crazy plan of world domination by lock-in (seems like the 90's and MS all over again) and deliberate incompatibility, coming from an overly aggressive development team, is not a good engineering solution in the long run. Sadly, most people don't seem to take enough time to think about that.
I've been a happy Debian user for 14 years (and have promoted and helped spread it to hundreds of systems), but I'll have to ditch it and stop promoting it, if no option is given to use classic init in the future. It's a shame, really.
Hopefully, more people will see it in time, since this is basically history repeating itself...
Posted Oct 17, 2014 18:44 UTC (Fri)
by pizza (subscriber, #46)
[Link] (10 responses)
Serious question: Why were you using and promoting Debian to begin with?
Posted Oct 17, 2014 20:02 UTC (Fri)
by ctpm (guest, #35884)
[Link] (9 responses)
Let's see...
* Excellent package management system, probably the first (or one of the first) to resolve dependencies.
Now Debian seems to be on the brink of making a U-turn on some the traits that made it great, by foolishly following along with other distros in a failed engineering experiment called systemd, and all that while apparently trying to shove said failed experiment down every user's throat whether they need it or not.
The sensible option would be to, at least, give users the *choice* of init system. Arguing that that would be "forcing developers to do extra work" is an artificial problem created by this whole debacle itself: a daemon/service/whatever should not care by whom it was spawned. Most packages already ship with reasonable startup scripts. If some fancy init system wants to play games and "innovate", that system should provide all the compatibility layers needed, not the other way around. This idea of almost needing to port the distro to a new kind of architecture should be more than enough evidence of the absurdity of the whole situation.
I'm not gonna repeat every (lack of) reliability, design decisions and UNIX philosophy argument about systemd. Plenty has been written about that on the web. I mean no personal offense but frankly, that's Engineering 101. There are many books on that -- that the systemd dev team apparently never read, and thus, once again made the usual design mistakes so many have done before.
I'm just gonna say that, if you want to use it on your desktop, go wild! But why should this be forced on _everyone_ else that does not benefit from it? It's a solution to a problem which doesn't exist to a lot of us.
As many of us, I manage servers for a living. Just as one of many examples, why would I care that systemd shaves 5 seconds out of a boot sequence that happens once every 6 months or a year? Why do they want to force feed users something they don't really need? Even if you do reboot often due to kernel updates, then you'll have done a failover to a redundant node, so boot time is still a non-issue.
Anyway, Debian used to be a distro that set standards, for some reason the community now seems to have a desperate need to feel integrated and *follow* the Cool Boys group, and that apparently means choosing between Ubuntu Fancy Init system or RedHat/Fedora/Whatever Fancy Init system. Because "doing things different means it must be better", right? Because new is better than "old 70's technology bla bla bla", right? Maybe not...
So much for user freedom of choice. If it's Their Way Or The Highway, I'm choosing the highway.
So enjoy my wall of text :-)
Posted Oct 17, 2014 20:11 UTC (Fri)
by pizza (subscriber, #46)
[Link] (3 responses)
So... you're not only throwing out the baby with the bathwater, but you're throwing out the tub, the bathroom, and the house as well, and presumably moving to something that's vastly inferior for all the reasons you enumerated above.
But hey, you're free to make your own choices, even when they are of the "cut off your nose to spite your face" variety.
Posted Oct 17, 2014 20:45 UTC (Fri)
by ctpm (guest, #35884)
[Link] (2 responses)
I'm not the one throwing the baby out with the bathwater, nor did I want to leave the house. I happens the house has been invaded by some kind of thug that insists on abusing everyone and everything.
It's a pity to loose all those qualities, but IMO, the sudden unwelcome visitor just negates the benefit of many of them.
Sure as hell I'm not gonna stick close by for that, the real estate is starting to loose its value ;-)
Posted Oct 17, 2014 23:06 UTC (Fri)
by cesarb (subscriber, #6266)
[Link]
It's a good thing, then, that the systemd developers do justify their technical choices.
Just one example of systemd developers explaining their technical choices: https://lwn.net/Articles/436012/. The explanation was good enough to make me go from "what an ugly change" to "it makes a lot of sense" (see my comment at https://lwn.net/Articles/436072/), and the change itself was so good that even distributions which were not using systemd adopted it.
There are many more like that one, starting with the very first few blog posts announcing systemd.
Posted Oct 18, 2014 1:53 UTC (Sat)
by misc (subscriber, #73730)
[Link]
If there is so much, just give like 4 or 5, because you do not want to look like giving unverifiable facts, don't you ?
Posted Oct 17, 2014 21:04 UTC (Fri)
by mpr22 (subscriber, #60784)
[Link] (4 responses)
A sensible option which Debian developers have, in fact, already made happen while various people rage and flame about systemd for reasons varying from the thoughtful and well-reasoned to the spiteful to the downright paranoid. Debian jessie has multiple init systems available right now while it is still testing, and when it is released as stable it will have multiple supported init systems, and upgrading from wheezy to jessie without changing init systems is a thing that works now in testing and will work at stable release.
Posted Oct 17, 2014 22:23 UTC (Fri)
by ctpm (guest, #35884)
[Link] (3 responses)
>Debian jessie has multiple init systems available right now while it is still testing, and when it is released as stable it will have multiple supported init systems, and upgrading from wheezy to jessie without changing init systems is a thing that works now in testing and will work at stable release.
Well, yes, but that multiple init system support is worthless *if* the maintainer of one of the packages you wish to install makes it depend on a _specific_ init system, out of the ones supported. Then you may be hosed.
So, AFAICS, Ian's proposal makes total sense in that it prevents packages from arbitrarily depending on specific init systems left and right, but instead work with every one (within reasonable conditions, as described in the proposal). This too seems pretty obvious and well-reasoned on his part.
Posted Oct 18, 2014 0:39 UTC (Sat)
by rahvin (guest, #16953)
[Link]
That is not sensible policy. It's an authoritarian nightmare.
Posted Oct 18, 2014 10:47 UTC (Sat)
by farnz (subscriber, #17727)
[Link] (1 responses)
So, serious question time. Assume I'm an upstream developer of a desktop environment; I need a mechanism to allow an unprivileged user to power down their system at the close of their working day, except where the system administrator has chosen to prevent that from happening (e.g. so that they can install updates).
My choices are:
In your view, which of the three options should I take? If option 3, would this GR oblige someone wanting to package my DE for Debian to reimplement the DBus interface for another init system, or not?
Note too that at least on Fedora, if not other distros as well (Fedora happens to be what I use), option 3 integrates nicely with the package manager - if the sysadmin logs in remotely and runs "yum", the package manager will inhibit shutdown for the duration of the operation.
Posted Oct 18, 2014 13:23 UTC (Sat)
by HelloWorld (guest, #56129)
[Link]
Posted Oct 17, 2014 19:12 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (9 responses)
The first sentence should be:
Posted Oct 17, 2014 20:21 UTC (Fri)
by ctpm (guest, #35884)
[Link] (7 responses)
The only argument I've read from you in this thread is you saying that you don't care and you don't want to care.
But the people who want or need to keep real life systems working *will* need to care and know what's happening on their systems, and fix them when they break.
Bury your head (and your sausage) in the sand as much as you want, but don't come whining in 2 years when most distros are so FUBAR that the solution is to throw half of that trash away.
Posted Oct 17, 2014 23:00 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
For me this script was the deal-breaker: http://anonscm.debian.org/cgit/users/lamont/bind9.git/tre...
Posted Oct 17, 2014 23:15 UTC (Fri)
by mgb (guest, #3226)
[Link] (2 responses)
A good modular design would have been technically acceptable to everybody, but systemd was never about technology.
Systemd is about seizing control of Linux. And the extraordinarily serious downside of systemd's awful design is that the lack of modularity makes it hard to improve Linux in future.
Posted Oct 17, 2014 23:17 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
So for me systemd's public interfaces seems crystal clear.
Posted Oct 18, 2014 0:15 UTC (Sat)
by anselm (subscriber, #2796)
[Link]
Great. Feel free to design, implement, debug, and document something that is better than systemd. If systemd is really so terrible, people will be celebrating you for the next few decades.
In reality, though, actually coming up with a software system that does what systemd does but better is probably not all that easy. Talk is cheap, but actually doing the work is hard – which is why out of all the people who are moaning and griping about how systemd is so bad, nobody so far has actually got their gear together enough to come up with anything at all to compete with it. They tell us, for example, that sysvinit would be perfectly equal to systemd if only someone added component X, feature Y, or approach Z that is superior to what systemd does, but nobody develops the code or writes the documentation. Many of the missing bits and pieces purportedly exist and are working great, but nobody even comes up with a proof-of-concept derivative of a popular Linux distribution that integrates them by default. My personal guess is that most of these people simply lack the vision, technical competence, and will of someone like Lennart Poettering, but they still think they're entitled to tell everyone what they should or should not be using. I don't think these people are really worth listening to.
Have you actually looked at systemd? The design is pretty modular as these things go. And the interfaces between the modules are way better documented than anything in the sysvinit universe.
Exactly who is supposed to be “seizing control of Linux” through systemd? The systemd developer community includes people from all major Linux distributions. If getting rid of every distribution's /etc/hostname, /etc/HOSTNAME, and /etc/sysconfig/whatever_the_file_is_called_this_week in favour of one standardised configuration file is “seizing control of Linux“ then I say bring it on.
Systemd consists of a bunch of modules with documented interfaces and a stability promise. It would certainly be possible to replace individual modules with different implementations that adhere to the same interfaces. It may be often be an easier route, however, to simply improve systemd's components instead. These could be forked if required, and/or improvements could be fed back into the systemd development process.
Posted Oct 18, 2014 7:01 UTC (Sat)
by wt (subscriber, #11793)
[Link] (2 responses)
The Debian TC already found systemd to be the technically superior choice. It makes sense to want to use the best technical solution as broadly as possible, meaning systemd support should be a priority for Debian. However, systemd only supports Linux-based systems, which accounts for ~98.4% of Debian's user base according to popcon data[1].
With regard to other Debian archs, it's straightforward to look at the ecosystem and conclude that it's dominated by the Linux kernel over the alternative kernel options. In fact, according to popcon data, only ~1.6% of users run hurd, kfreebsd, or have an unknown arch.
Given those stats, forcing support for the other kernels basically means holding back ~98.4% of Debian users to support those other choices. In order to have those choices available a sacrifice must be made in terms of time needed to deliver a release or quality of a release or both.
I don't think the resistance to supporting multiple init options has so much to do with not caring about the other viewpoint as much as not wanting to sacrifice the benefits of what they see as the best way forward for 98.4% of the user base.
wt
Posted Oct 18, 2014 8:10 UTC (Sat)
by zwenna (guest, #64777)
[Link] (1 responses)
Small correction: the number is 1.6 ‰, not 1.6 %.
Posted Oct 20, 2014 6:32 UTC (Mon)
by wt (subscriber, #11793)
[Link]
I guess I was trying to be fair and erred on the side of to much share for the alternative kernels.
wt
Posted Oct 18, 2014 1:36 UTC (Sat)
by misc (subscriber, #73730)
[Link]
Posted Oct 17, 2014 19:38 UTC (Fri)
by HIGHGuY (subscriber, #62277)
[Link]
Also, most packages don't even care about init systems. It's mostly daemons and plumbing that depend on it. And even then, upstream isn't prevented from maintaining support for multiple init systems.
Pretty much everyone has the freedom to choose their init system one way or another (even if it means creating your own distro). But given that the whole world+dog is converging on a single solution is pretty impressive by itself and should be welcomed (even if there are some deficiencies).
In my opinion there's so much time wasted on duplicate+boring work in the Linux community. Effort that is better spent creating added value for users. If distros could converge on a subset of solutions (systemd, wayland, btrfs, ... maybe even packaging system if you'll let me dream a bit) a lot of hands would be free to add value to the ecosystem.
I'm not a proponent for any of the above solutions, but as always with change, it's better to embrace and help steer it rather than fight it. Then you'll at least have the opportunity to make it fit whatever it is you want.
Posted Oct 17, 2014 19:42 UTC (Fri)
by edomaur (subscriber, #14520)
[Link]
Personnaly I see it for the first concerted movement to modernize the init process since the eighties, and even if it's not absolutelly perfect, it's still better that the other proposals. And I don't kid myself, there will be no better alternative to systemd, because (as I see it) all its opponents are all talk and no code. So, prove me wrong.
Posted Oct 17, 2014 19:50 UTC (Fri)
by HelloWorld (guest, #56129)
[Link] (3 responses)
Posted Oct 17, 2014 23:50 UTC (Fri)
by Zack (guest, #37335)
[Link] (2 responses)
Specifically, I boot my systems with sysvinit.
> and how does systemd do less good a job at it?
Systemd does a less good job at booting my systems on account of not being installed.
"So why don't you install systemd then?"
Why do I even need a reason to *not* install software? A lot of people spend the majority of their time *not* installing software; it's quite a common pastime.
Posted Oct 18, 2014 0:22 UTC (Sat)
by HelloWorld (guest, #56129)
[Link] (1 responses)
Posted Oct 18, 2014 0:43 UTC (Sat)
by Zack (guest, #37335)
[Link]
Posted Oct 17, 2014 18:29 UTC (Fri)
by mgb (guest, #3226)
[Link] (146 responses)
It is this deliberate breakage of Debian that has to stop.
Posted Oct 17, 2014 18:37 UTC (Fri)
by jspaleta (subscriber, #50639)
[Link] (133 responses)
So I'm a bit confused as to why systemd-logind is pid 1 on debian. Shouldn't have to be. If systemd-logind is pid 1 in Debian that's probably something that can be easily fixed.
-jef
Posted Oct 17, 2014 19:38 UTC (Fri)
by mgb (guest, #3226)
[Link] (132 responses)
Pid 1 bloat increases the attack surface and makes it harder to improve Linux in future.
Posted Oct 17, 2014 20:04 UTC (Fri)
by jspaleta (subscriber, #50639)
[Link] (131 responses)
This is how the forked systemd-shim works with logind in Debian right? I mean its still systemd-logind running... and just systemd-shim is running as non pid=1 and acting as the dbus service logind expects to see. Sure shim isn't a full independent implementation of the dbus service....but its not pid=1. If logind really were tied to pid=1 systemd as you claim shim using cgmanager wouldn't even be possible.
I fear you are confusing the "design" with the "implementation" details of the stable API for logind and the reference implementation as implemented in the functional systemd codebase.
You shouldn't confuse those two things. I understand its really easy to confuse those things when there is only one implementation out in the wild.
Logind's dbus managed interprocess communication design is way more init agnostic than you give it credit for. The APIs are part of a stability promise We just don't have a true second implementation of the service logind is talking to.
Replacing systemd as pid 1 and keeping logind working is completely possible. Someone just has to code up a replacement backend service. Logind really really doesn't care what its talking to over the bus. I'm pretty sure someone clever enough could find a way to extend runit with a helper and get systemd-login working with runit running as non pid 1, if they really really wanted to do it, once they understand the interprocess communication "design." In fact I think eventually someone will do just that to scratch a personal itch.
What's much much harder is making logind work with out cgroups at all.
Posted Oct 17, 2014 20:15 UTC (Fri)
by mgb (guest, #3226)
[Link] (130 responses)
Bloating pid 1 with that D-Bus interface increases the attack surface and the lack of modularization makes it harder to improve Linux in future.
Therefore, this is yet another example of systemd's bad design.
QED
Posted Oct 17, 2014 20:56 UTC (Fri)
by jspaleta (subscriber, #50639)
[Link] (4 responses)
Lets make sure we've concluded the on-topic argument before moving on to the off-topic one about the security implications of relying on dbus.
you admit that logind does not in fact depend on anything being running on pid=1 Right? And you rescind your previous criticism that GNOME or anything else which depends on the logind API for functionality is implicitly dependent on any particular init being pid=1 right? I'll just go ahead and assume you've answered yes to those questions and we'll move on safe in the knowledge that you previously stated issues about high level software relying on a specific codebase running as pid=1 have now been address.
So... reliance on dbus in pid=1 as a security risk over other available ipc mechanisms available. I do not share your opinion that having pid=1 rely on dbus for IPC is an inherent security weakness. I personally look forward to the day when kdbus is a standard piece of kit for every process to rely on for inter process communication from pid=1 to pid=infinity+1.
Anyways... for everyone who agrees with you about the implications of relying on dbus in pid=1, then sysvinit with shim and cgmanager should work for you to keep logind for higher level bits of to rely on for now. You and those who agree with your opinion would of course be better off replacing shim with a fully independently developed codebase that implements the stable systemd dbus API.
As shim is just a fork of systemd and I don't see that being sustainable long term because users of that fork will be continually fighting against implementation decisions they don't agree with in the mainline codebase. That's not where you want to be.
Better to start fresh and build the implementation that works more consistently with your world view about the security risk of dbus. I've sort of hinted at extending runit with a helper to talk systemd APIs, as a way forward for you and people who share your opinion about the security of dbus while still keeping logind working. runit is in my estimation the best choice for you moving forward, as even upstart suffers from your perceived dbus over-reliance so you shouldn't even bother with resurrecting and extending it. The point being, logind will still operate as long as your independently developed service implementation running pid!=1 as long as it speaks the expected documented APIs logind expects to see.
-jef
Posted Oct 17, 2014 21:00 UTC (Fri)
by mpr22 (subscriber, #60784)
[Link] (3 responses)
Posted Oct 17, 2014 21:02 UTC (Fri)
by jspaleta (subscriber, #50639)
[Link] (2 responses)
-jef
Posted Oct 17, 2014 21:13 UTC (Fri)
by mpr22 (subscriber, #60784)
[Link] (1 responses)
A few. To be precise, two .c and three .h files (out of the total of sixteen files comprising the C source code), which contain rather generic helper functions and look to be rather extensively pruned compared to wherever in systemd they came from, too. This really, really isn't a "fork of systemd" by any reasonable definition of the phrase.
Posted Oct 17, 2014 22:06 UTC (Fri)
by jspaleta (subscriber, #50639)
[Link]
Either way I hope debian is able to sustain it and cgmanager, even if Canonical looses interest in maintaining either with staffed manpower. As clearly these two codebases are going to be critical if Debian is serious about multi-init support. GNOME might be today's firefight..but this is just a prelude to the much more difficult discussion concerning container support and the cgroup management question bound up in that. And containers go right to the heart of Debian's relevance in the server workloads and a much more interesting issue for the project long term I think. But I digress.
-jef
Posted Oct 17, 2014 21:10 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (124 responses)
It is reasonable to put cgroup management – which is what logind needs from systemd – into PID 1 because otherwise whichever external service is used to manage cgroups can't be managed by PID 1 like other services in the system are managed. This leads to nasty special cases in the code and increases the probability of bugs. It becomes a chicken-and-egg problem. The systemd documentation explains this in more detail here.
Many other things that systemd handles in PID 1 do make considerable engineering sense, too. For example, the fact that in traditional sysvinit, PID 1 has no idea what its child processes are and hence, how to restart a service that it notices has crashed is a glaring design flaw. Calling systemd badly designed because it fixes this obvious problem (among other things) isn't exactly logical.
Posted Oct 17, 2014 21:26 UTC (Fri)
by ctpm (guest, #35884)
[Link] (123 responses)
Why the heck should the init system restart failed crashed processes? Who restarts init if it crashes? A trained monkey?
If your daemon suffers from that, it should provide an overseer process. Or _you_ should use a configuration management/monitoring daemon, for which there are many to choose from today.
Your solution is to bloat PID 1 with more mechanism and more policy, knowing there's a kernel panic if it crashes? That would be a glaring design flaw, yes.
Init is engineered correctly as it is.
Posted Oct 17, 2014 22:34 UTC (Fri)
by jonabbey (guest, #2736)
[Link]
Posted Oct 17, 2014 22:41 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (18 responses)
This script was shipped in a major Debian release and it's not like BIND is some kind of obscure daemon that nobody uses. So "better testing" is not an answer.
Posted Oct 17, 2014 23:21 UTC (Fri)
by ctpm (guest, #35884)
[Link] (1 responses)
Posted Oct 20, 2014 0:06 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Oct 18, 2014 0:05 UTC (Sat)
by nowster (subscriber, #67)
[Link] (15 responses)
Posted Oct 18, 2014 0:57 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (9 responses)
The worst bug is at line 92 - if for some reason BIND becomes unresponsive during the shutdown then this loop will go on indefinitely. Halting the shutdown process.
That has happened to me during a maintenance server reboot and required me to go at night to our datacenter and power-cycle the machine.
Systemd has timeout logic built-in and it can also reliably kill services.
Posted Oct 18, 2014 1:26 UTC (Sat)
by misc (subscriber, #73730)
[Link]
I am also not 100% on how the initscript would react with a chroot or a docker file, with named running inside the chroot and outside, due to pgrep likely seeing all processes.
I am personnally unsure of why this test the OS to be solaris. And I am not really sure that ignoring errors silently is the right thing to do ( like the chown line 52 ), and the check network seems a bit strange.
Posted Oct 19, 2014 23:17 UTC (Sun)
by simoncion (guest, #41674)
[Link] (7 responses)
start-stop-daemon --stop --retry 10 --pidfile $PIDFILE --exec /usr/sbin/named
There's so much wrong with how that guy is trying to stop BIND. He's already using daemontools. Take advantage of the tools that it gives you.
Go look at how Gentoo does it. http://pastebin.ca/2861076 (That pastebin expires in two months.)
Posted Oct 19, 2014 23:42 UTC (Sun)
by ABCD (subscriber, #53650)
[Link] (1 responses)
Posted Oct 20, 2014 22:09 UTC (Mon)
by simoncion (guest, #41674)
[Link]
Posted Oct 20, 2014 0:11 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
It'd be actually interesting to write a completely correct race-free init script that explicitly supports all the systemd's features. I suspect that it's close to impossible.
Posted Oct 20, 2014 22:27 UTC (Mon)
by simoncion (guest, #41674)
[Link] (3 responses)
Posted Oct 20, 2014 23:06 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (1 responses)
See systemd.service(5). The “ExecReload=” key lets you specify a sequence of commands. If one command fails then the remaining commands will not be executed, but the service will be kept running.
Posted Oct 21, 2014 9:08 UTC (Tue)
by cortana (subscriber, #24596)
[Link]
Posted Oct 21, 2014 5:56 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Running checkconf is supported by ExecReload. Running inside a namespace is supported out-of-box by simply doing this:
Gentoo's script is still racy - and there's no way to un-race it.
The reload action is asynchronous, because it uses a signal ('rndc reload' should be used instead).
And seriously, using 'fuser' to check if all processes have exited? Is it really real?? It's like these folks haven't heard about cgroups.
> 2) You want an init script to handle SELinux labeling and policy enforcement? Do I misunderstand you? If I don't, how, exactly, would that work?
You need to sanitize the SELinux environment to avoid passing user's labels.
Posted Oct 18, 2014 14:16 UTC (Sat)
by tialaramex (subscriber, #21167)
[Link] (4 responses)
In systemd a configuration file is... just a configuration file.
I think that's a very nice piece of simplification. But doubtless if you're inclined to see beauty in every nasty sharp corner of sysvint you'd argue that a configuration file is exactly the right place to run arbitrary code as root...
Posted Oct 18, 2014 14:30 UTC (Sat)
by anselm (subscriber, #2796)
[Link] (3 responses)
It is funny how people keep complaining about the purportedly large “attack surface” of systemd while at the same time not seeming to mind that large swathes of the traditional setup basically amount to shell scripts being run with root permissions. In particular, many Linux distributions use bash as the default shell, and anybody who has recently been following security news should have been reminded that bash isn't the most secure piece of software around.
In that sense, systemd's attempt to dispense with the shell to as great an extent as possible does not seem to be entirely misplaced. The various binaries within systemd that take part in the boot process, for example, are generally small enough to be individually audited, and as such their potential to reduce a system's attack surface is considerable compared to the status quo.
Posted Oct 21, 2014 18:00 UTC (Tue)
by nix (subscriber, #2304)
[Link] (2 responses)
Meanwhile, the APIs systemd exposes are, IIRC, exposed to *everyone*. One hole in the libdbus permissions checking -- tested, sure, but much less tested than the battle-hardened kernel fs permissions code -- and systemd is suddenly much more exposed than that.
(Is this point *really* not immediately obvious?)
Posted Oct 21, 2014 18:22 UTC (Tue)
by JGR (subscriber, #93631)
[Link] (1 responses)
The problem is not modifying the shell scripts themselves, but that the attack surface comprises the shell script, the shell itself, and all the various other scripts, executables, etc. which get invoked in the script.
Posted Nov 2, 2014 14:57 UTC (Sun)
by nix (subscriber, #2304)
[Link]
Posted Oct 18, 2014 1:40 UTC (Sat)
by misc (subscriber, #73730)
[Link] (71 responses)
So yeah, maybe your employer do not have such policy and do not care about restarting crashed processes, but there is a lot that care enough to have spawned a industry around the whole idea of supervision and first level handling.
Posted Oct 18, 2014 3:07 UTC (Sat)
by mgb (guest, #3226)
[Link] (70 responses)
Anything more complex requires active monitoring and intelligent response. Systemd handles a trivial corner case by restarting a dead daemon but does nothing for the more common cases of resource exhaustion, process hangs, disk failures, configuration errors, and network outages.
Systemd bloats pid 1, increases attack surface, makes Linux much harder to improve in future, and provides only trivial benefits in return.
A case can certainly be made for a better init, but systemd is not it.
Posted Oct 18, 2014 3:35 UTC (Sat)
by raven667 (subscriber, #5198)
[Link] (2 responses)
Posted Oct 18, 2014 3:51 UTC (Sat)
by mgb (guest, #3226)
[Link] (1 responses)
Posted Oct 18, 2014 4:08 UTC (Sat)
by raven667 (subscriber, #5198)
[Link]
Posted Oct 18, 2014 5:53 UTC (Sat)
by misc (subscriber, #73730)
[Link] (55 responses)
Now, as you were already explained, systemd do more than inittab since it will log the restart and it will not restart if something is restarting too often.
As a side note, I also think that repeating the same thing over and over do not really help to make your case. People do usually understand the first time, and it personnally only increase my perception that some of the most vocal critics of systemd do seems to have a problem ( which is sad, because this prevent more reasonable people problem to be taken in account by the fact they are less visible under the flood of message ).
Now, maybe you speak of the the code that listen to socket, who is small enough to be audited and was audited. The majority of problem would occurs in a parser, and that's offloaded to the started daemon. Not that there is no problem ever but again, this bring features and I think people see them worthwhile, as seen on the first article on systemd.
Now, the whole idea of making Linux harder to improve in the future is laughable, wrong and wouldn't make sense if it was not wrong. I mean, you seriously suggest to prevent innovation now just to permit someone to innovate later, something that didn't seems to happen that much in the previous years ?
If we were able to change everything in the past few years ( like redoing kde/gnome, moving to wayland, using kms, splitting xorg in smaller tarball, moving from static /dev to devfs to udev, consolekit, hal, pulseaudio, alsa, oss ), I do not see what would prevent replacing systemd one day. You keep repeating it, but you do not give anything concrete, just hand waving. As we have source code for lots of stuff, there isn't much that would prevent anything.
And for trivial benefits, it is sad that it doesn't bring you anything, but it do bring benefits for others. That you only care about you is ok, luckily, not all people are like you.
Posted Oct 18, 2014 6:09 UTC (Sat)
by mchapman (subscriber, #66589)
[Link] (49 responses)
systemd does have "runlevels"... they're just named instead of numbered. :-)
It would be fairly straight-forward to have each service unit generated from inittab depend upon the appropriate systemd target unit.
> Now, as you were already explained, systemd do more than inittab since it will log the restart and it will not restart if something is restarting too often.
To be fair, sysvinit has the latter behaviour as well.
I've always wondered why systemd's lack of built-in inittab support is such a huge problem. systemd isn't the first init system to lack inittab support: Upstart has no support for inittab services either. Neither sysvinit nor Upstart even support initscripts natively; there's always some kind of shell wrapper to negotiate which services should be started or stopped on a runlevel change.
So arguing about feature parity across init systems is kind of silly, even without bringing systemd into the picture. Different init systems simply have different features. There's no a priori reason they *should* all be the same.
Posted Oct 18, 2014 13:52 UTC (Sat)
by mathstuf (subscriber, #69389)
[Link]
And the numbers still work. I use them out of habit still.
Posted Oct 21, 2014 18:03 UTC (Tue)
by nix (subscriber, #2304)
[Link] (47 responses)
Posted Oct 21, 2014 18:47 UTC (Tue)
by mgb (guest, #3226)
[Link] (46 responses)
All but one of our systems - that includes desktops, laptops, servers, and VPSs - have one or more inittab entries in addition to those supplied by the distro.
There is no point in creating an initscript in those cases where inittab already does exactly what is needed.
This reminds me of Poettering's surprise when sound drivers in the real world were not as he had imagined either.
Posted Oct 21, 2014 19:28 UTC (Tue)
by jspaleta (subscriber, #50639)
[Link] (5 responses)
I'm not discounting the idea that people have a customized inittab. But I am seriously skeptical that there is a functional situation in the wild where inittab semantics is more capable of expressing the desired action than what systemd unit semantics are able to provide.
If you simply don't want to learn a new system. Fine. I can respect that. I'll let you continue to use like and prefer inittab, just as long as you let me like an prefer 8-track cassettes. But please don't continue to express an expectation that factory installed default options will continue to support your preference. I've given up on getting an 8-track cassette player installed years ago.
-jef
Posted Oct 21, 2014 19:45 UTC (Tue)
by mgb (guest, #3226)
[Link] (4 responses)
You are at liberty to replicate an inittab function with a Turing machine if you wish.
F/LOSS and Debian are about choice. They are not about RH using EEE to force us to use the wrong tool for the job.
Posted Oct 21, 2014 20:32 UTC (Tue)
by louie (guest, #3285)
[Link] (1 responses)
Posted Nov 18, 2014 17:26 UTC (Tue)
by blujay (guest, #39961)
[Link]
Posted Oct 21, 2014 22:24 UTC (Tue)
by rodgerd (guest, #58896)
[Link] (1 responses)
Posted Oct 22, 2014 12:27 UTC (Wed)
by micka (subscriber, #38720)
[Link]
_But they do the work themselves_!
Posted Oct 21, 2014 19:39 UTC (Tue)
by anselm (subscriber, #2796)
[Link] (39 responses)
More power to you. So keep using sysvinit.
In the unlikely event that you'd ever want to move to systemd, it's a pretty trivial exercise to come up with a systemd unit file corresponding to an inittab entry. If your /etc/inittab has a line like
From a maintenance POV, this setup has the additional benefit that you don't have to fix your configuration by hand like you need to when your distribution installs a new version of the /etc/inittab file.
Posted Oct 21, 2014 20:03 UTC (Tue)
by mgb (guest, #3226)
[Link] (38 responses)
sysvinit has provided respawn rate-limiting for as long as I can remember.
> additional benefit that you don't have to fix your configuration by hand like you need to when your distribution installs a new version
inittabs are updated by the configuration management system.
//
There may well be situations where systemd is the right tool for the job. The problem is RH using EEE to preclude us from using the right tool for the job when that tool is not systemd.
Posted Oct 21, 2014 21:26 UTC (Tue)
by anselm (subscriber, #2796)
[Link] (37 responses)
Sort of. Sysvinit's rate limiting is hard-coded and not configurable – it's great if its fixed parameters suit your application but it sucks if they don't. Systemd gives you a lot more control.
In general, systemd lets you do many more things out of the box that would be a hassle to configure with sysvinit.
With sysvinit, there is a completely arbitrary and superfluous distinction between services started from inittab and services started by init scripts. This is one of sysvinit's various design flaws. Systemd, on the other hand, treats all services the same regardless of how they're started. This makes life easier for admins and people who are learning or teaching how the system works.
You still need to reconcile your tweaks with whatever changes to the base configuration file the distribution makes from one version to the next. With systemd this is a complete non-issue since the distribution's base configuration files and one's own local changes are cleanly separated by design. (/etc/inittab is a reasonably simple file but the issue is worse with init scripts.)
Posted Oct 21, 2014 21:30 UTC (Tue)
by mgb (guest, #3226)
[Link] (36 responses)
You are not welcome to force other people to use systemd where it is the wrong tool for the job.
Posted Oct 21, 2014 21:34 UTC (Tue)
by jspaleta (subscriber, #50639)
[Link] (19 responses)
And by that logic, when an application or framework developer thinks the systemd APIs are the right tool for the job, they have the freedom to choose to support those APIs without being forced to support other less optimal APIs.
-jef
Posted Oct 21, 2014 21:48 UTC (Tue)
by mgb (guest, #3226)
[Link] (18 responses)
And Debian has the freedom not to include software which violates Debian's policies.
Posted Oct 21, 2014 22:06 UTC (Tue)
by jspaleta (subscriber, #50639)
[Link] (17 responses)
And in point of fact.. up until very recently sysvinit was the _only_ forced init in debian due to its essential nature:
http://www.vitavonni.de/blog/201410/2014102101-avoiding-s...
So even without the GR in place to coerce or mandate, maintainers have already been working to make it easier for everyone involved in Debian to have more "choice" and to agree to disagree as to watch choices are best.
Makes me wonder... Why was it okay to mandate sysvinit as essential prior releases? if this is really about choice...why weren't the choice proponents making the case back then that sysvinit as essential was taking choice away? Where were the proponents champion the choice to run a system on runit or minit without having sysvinit installed at all on the system?
The GR solves nothing, addresses nothing. Even if it passes, sysvinit compatibility in the future when uselessd becomes available as a packaged alternative to systemd.
-jef
Posted Oct 21, 2014 22:31 UTC (Tue)
by mgb (guest, #3226)
[Link] (16 responses)
Debian's "Essential: yes" package attribute does not mean what you think it does.
Thanks to modular design, Debian Wheezy supports numerous tools in this space including daemontools, filerc, openrc, runit, systemd, sysvinit, and upstart.
The problem comes now that RH deliberately breaks existing software so that it no longer works without systemd.
Posted Oct 21, 2014 23:06 UTC (Tue)
by anselm (subscriber, #2796)
[Link]
For the record, “Essential: yes” means that the package can't be removed with the package management tools (without a special command line option to dpkg, anyway).
Please name a package in Debian that has been “deliberately broken so that it no longer works without systemd.“
Posted Oct 21, 2014 23:25 UTC (Tue)
by pizza (subscriber, #46)
[Link] (14 responses)
Whether or not you have any valid points...this is *not* one of them.
FYI, Your "existing software" will continue to work as well now as it did the moment you first installed it. If you *chose* to install a newer version of said software, then guess what? It isn't "existing software" any longer; it is "new software", usually developed by independent third parties, which may have new features, along with new prerequisites to support those features.
You've even conceded this point elsewhere in this thread, so I can only wonder why you keep bringing it up. Your insistence on harping on something demonstrably false only hurts your credibility and any legitimate arguments you may have. I respectfully suggest you drop it.
Posted Oct 22, 2014 1:16 UTC (Wed)
by mgb (guest, #3226)
[Link] (13 responses)
Debian is deciding whether to include in Jessie software which has been deliberately crippled to only work with systemd.
RH cannot force Debian to distribute broken software.
Posted Oct 22, 2014 1:19 UTC (Wed)
by raven667 (subscriber, #5198)
[Link] (9 responses)
Posted Oct 22, 2014 4:44 UTC (Wed)
by dlang (guest, #313)
[Link] (8 responses)
Posted Oct 22, 2014 5:28 UTC (Wed)
by jspaleta (subscriber, #50639)
[Link] (7 responses)
But I'd be a little more nuanced than that. Its the dependence on the logind API specifically. There are other systemd provided APIs like hostnamed and friends which have not be controversial as they were easily re-implementable as small tools outside the systemd codebase. But there was a real question as to whether or not the existing -shim was going to gain support logind in time to matter for jessie.
Now with -shim supporting logind API that original concern has been taken care of. So credit where credit is due. The work to bring logind API support to -shim should be applauded as it definitely is going to benefit Debian users who desire to update systems to jessie and transition to systemd more slowly.
Moving forward I expect the next pain point is going to be the GNOME concept of app containers which will be using systemd APIs. But I don't have a good feel for the shape of that battleground yet. cgmanager does exist now so its not as dire. Maybe there might have to be an API translation layer to connect systemd API to cgmanager API, but not nearly as scary as the logind situation before -shim gained gained support for logind using cgmanager in the background.
Then in the longer term, kdbus is going to be a big problem... because nobody outside of systemd dev is looking to implement a userspace side to support kdbus. I fully expect GNOME to start making use of kdbus as soon as it goes mainline. And unlike for what happend for -shim, I'm not sure Debian can rely on Canonical/Ubuntu to help lead an alternative to systemd's implementation. If Ubuntu fully transitions over to systemd before kdbus is merged in the kernel mainline (and that seems likely) then there's no obvious candidate to do the work to provide the alternative implementation.
-jef
Posted Oct 22, 2014 5:37 UTC (Wed)
by dlang (guest, #313)
[Link] (2 responses)
Therefor fearing that such software may be created in the future is not someone being a fearmonger or being deceitful, instead it's someone expecting that what was done before will be done again.
If Gnome no longer requires systemd, that's a good thing. It's also what the response should have been in the first place rather than taking the attitude that doing anything other than forcing everyone to switch to systemd was putting an unreasonable burden on Gnome.
Posted Oct 22, 2014 5:59 UTC (Wed)
by mchapman (subscriber, #66589)
[Link]
To be fair, it never really *required* systemd. It can make use of a particular D-Bus interface that systemd provides, but it doesn't care one iota whether that interface happens to be provided by some other project instead. So it's probably wrong to think of Gnome as having undergone change -- what has happened is that the environment "around" GNOME has changed: there is now more than one implementation of this interface. And that most certainly is a good thing!
Posted Oct 22, 2014 6:27 UTC (Wed)
by jspaleta (subscriber, #50639)
[Link]
GNOME is still technically depending on exactly the same thing it did 6 months ago. systemd-logind is still the only implementation of logind's API. -shim just now implements the systemd APIs that systemd-logind is using.
So again its more nuanced. If GNOME upstream or GNOME debian maintainers had waited for a second implementation to exist before depending on an API, would a second implementation ever been made? Or is it because GNOME upstream pushed ahead and the distro maintainers integrated the new upstream code, that created the need for the alternative implementation that caused it to be created? The need being the mother of invention and all that.
I think the historic Debian transition to use hal is instructive: https://lists.debian.org/debian-user/2009/09/msg00915.html
then the application incompatibilities transitioning from hal to udev in wheezy:
Call me a greybeard..but it sure seems like kids these days seem to have a poor grasp on how Debian has handled major userspace plumbing historicly.
The transition to hal and then to udev both introduced incompatibilities and there was never a requirement that multiple implementations be expected to work seamlessly as alternatives of each other. What mattered was a plan to get from old default to new default.
And so it should be with the transition for new default init. Regardless of changes in the API.
-shim is an important piece to aid the transition to the new default init. But to hold the idea of init diversity as something sacrosanct after years and years of previous Debian project experience transitioning plumbing in a more focused linear manner is.. smirkable.
No matter how this all shakes out sysinit is going to join HAL and devfs in the software retirement home. It's just a matter of time.
-jef
Posted Oct 22, 2014 8:29 UTC (Wed)
by johannbg (guest, #65743)
[Link] (3 responses)
I would take that "support" with a very and I mean very much grain of salt.
systemd-shim package is a futile attempt since the goal that it has to aim for, keeps moving around. There are no stability promises on a core functionality logind uses and as a result of that has left systemd-shim broken for months before and will do so again each and everytime it's (afaik sole ) maintainer Steve Langasek has to play catchup with upstream changes.
Now as it's name indicated requires you to still have systemd installed so the Debian community has the choice of using a) An component which is busy chasing rainbows and developed/maintained by single individual or b) Use systemd with logind and all the other bells and whistle systemd provides which is backup by Tollef Fog Heen, Michael Biebl, Marco d'Itri, Michael Stapelberg, Sjoerd Simon and the entire upstream systemd community.
Now let's return to the core of the matter, the work required by the Debian, ( as well as Gentoo,Slackware and whomever intents to support multiple and or use alternative init system than systemd whatever they may be called uselessd,openrc,sysvinit etc in the long run ) community has to come up with ( and the systembsd maintainer bumped into as well and significantly slowed down the development or grounded his development to halt entirely ).
In *addition* having to carry downstream compatibility patches for all upstream components that have decided to integrate/use what systemd provides them with *beside* logind and the added load on the service support community ( help,qa,releng etc ) and it's maintainers that will bring, they will need to write and thus provide a daemon that provides the external, supported, and guaranteed stable "login" API, an daemon that maps the "login" API to the non-portable operating-system-specific underpinnings which is an hefty chunk of development work.
You cant workaround this problem in apt through some dependency/resolving magic and you wont achieve this with something like systemd-shim or have it magically appear by whining about it on mailing lists, in forum, and various comment sections or by continually coming up with GR's and the likes, you actually need to get your hands dirty and start doing that hefty coding period.
Ian and his followers are doing pretty good job disrupting the Debian community from doing what needs to be done to make Jessie the most awesome release ever ( integrate it to the best of it's ability to systemd. I've been midst in this integration work myself and I know how much it pains users have things half integrated, half migrated and thus half working ) and ensuring Jessie will become the worst release ever by having no init working reliably since him and his followers are not coming up with components and the code necessary to do so.
I just sincerely hope for the sake of Debian that the DD will vote for Luca Falavigna proposal ( Choice 3 ) which will put this power into the hands of the maintainers themselves since I know quite few of them know the reality for what it is but have chosen to keep themselves outside any ( systemd ) discussion and mud sliding.
Posted Oct 22, 2014 15:40 UTC (Wed)
by jspaleta (subscriber, #50639)
[Link] (2 responses)
point of information. I think ryan lortie is primary committer upstream.
both U and D bzr packaging systems suck in the upstream releases from ryan and seem to be point to http://people.gnome.org/~desrt/ as the source
Ryan seems to be using github primarily, but not github's release tagging mechanism, so the tarballs in http://people.gnome.org/~desrt/ are probably the canonical upstream release source.
Steve is acting primarily in the role of distribution packaging maintainer I think. And Martin Pitt is committing at both the distro and upstream levels.
Anyways... Ryan had a lovely blog post back in Feb, which I believe concurs with your assessment of the difficulty of using -shim to mimic the full systemd API. I think he draws different conclusions than you do from that. Considering what Ryan posted in Feb, I'm actually surprised that they got -shim updated to support logind. His post implied to me that it wasn't going to be attempted.
Seems -shim grew all the necessary cgroups stuff since september looking at ryan's github for -shim.
-jef
Posted Oct 22, 2014 17:45 UTC (Wed)
by johannbg (guest, #65743)
[Link] (1 responses)
Which happens to be one area him and or him and Martin will be constantly playing catchup with systemd.
I would not be surprised if they will only continue to maintain it until unity/ubuntu catches up with systemd and at that point they loose interest.
In anycase bottom line still remains the same if people want to ( continue to ) use alternate init system(s), be it single or plural instead of systemd in the name of choice or disgust towards systemd, individual members of the systemd community or the systemd community in whole, those individuals *will* have to code up/beef up those existing init system ( or write one from scratch ) to be somewhat on par with systemd. Once they have achieved that then they will have to convince wide variety of upstreams that currently use systemd to support that and or integrate it with their alternative.
Posted Oct 22, 2014 18:27 UTC (Wed)
by jspaleta (subscriber, #50639)
[Link]
What I don't really have my head around is what the plan is for updating systemd in either U or D and how conservative the systemd packaging updating is going to be. Both could basically peg systemd to a specific upstream version and skip some upstream releases in an effort to lower the risk of creating an API delta that -shim will have to keep up with.
I expect work on -shim compatibility to be bursty...and only happen for upstream versions of systemd that land in Ubuntu pre-release packaging, even if systemd versions roll into Debian unstable/experimental on a more regular fashion thanks to the effort of the systemd debian maintenance team. So I expect to see a delta to build up in the Debian unstable/experimental repo just to the differences in available attention and interest in tracking upstream systemd.
I'm willing to see this admitted low expectation on -shim work to be surpassed and I'll take any well deserved lumps for discounting the commitment of the people working on -shim if they are able to keep the delta between -shim and systemd API coverage low without another 4+ month lapse in -shim activity.
-jef
Posted Oct 22, 2014 1:29 UTC (Wed)
by jspaleta (subscriber, #50639)
[Link] (2 responses)
Proponents of the GR have stipulated in the ongoing discussion on -vote that there is no current issue in jessie currently which the outcome of this GR would impact.
Also they have explicitly stipulated that any RC bugs which are created due to the mandates of this GR for a yet to be found issue that -shim doesn't adequately handle, such RC bugs would be treated by the release team as jessie-ignore.
Do I need to provide citations to the ongoing discussion for these facts?
In very fundamental ways this GR is explicitly _not_ about fixing any perceived brokenness in jessie release. As there is no perceived brokenness in the jessie release.
Which is why the timing of this is a bit of a head scratcher. This could have waited for post jessie freeze.
-jef
Posted Oct 22, 2014 1:53 UTC (Wed)
by mgb (guest, #3226)
[Link] (1 responses)
Furthermore he said that ignoring such bugs is but one possible course of action. He did not say that the release team would ignore such bugs. Other possible courses of action include fixing the bugs and omitting Gnome from Jessie.
Posted Oct 22, 2014 4:38 UTC (Wed)
by jspaleta (subscriber, #50639)
[Link]
The proposed GR text was amended by Ian after discussion concerning the impact on jesse. The amended GR text that exists right now stipulates that the expectation the release team with ignore RC bugs generated if the proposed GR passes for the express purpose of avoiding blockers on jessie release.
Citations:
Posted Oct 21, 2014 21:48 UTC (Tue)
by anselm (subscriber, #2796)
[Link] (15 responses)
At the risk of sounding like a broken record, nobody is “forcing“ anyone to use systemd. Sysvinit isn't going away as long as there are people willing to put in the work to keep it around.
Posted Oct 21, 2014 21:56 UTC (Tue)
by mgb (guest, #3226)
[Link] (14 responses)
Posted Oct 21, 2014 22:03 UTC (Tue)
by anselm (subscriber, #2796)
[Link] (13 responses)
Exactly which Debian packages in jessie force you to run systemd as PID 1?
(Other than systemd-sysv, that is.)
Posted Oct 23, 2014 3:37 UTC (Thu)
by xz (guest, #86176)
[Link] (12 responses)
network-manager
Here is another more complete graph generated by debtree for packages with hard dependecy on systemd: http://i.imgur.com/5MchQde.png
Posted Oct 23, 2014 6:56 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (11 responses)
For example: https://packages.debian.org/jessie/lighttpd has a dependency on systemd or lsb-base. Systemd is not mandated at all.
Posted Oct 24, 2014 1:05 UTC (Fri)
by xz (guest, #86176)
[Link] (10 responses)
The list I provided can be manually verified and they require systemd (via libpam-systemd or not). The fact that user applications far downstream start having hard dependency on systemd shows the dependency land grabbing scheme in the work.
Thanks for the catch on lighttpd though. That was because debtree doesn't have a good way to deal with alternative dependencies (`apt-cache -i rdepends systemd` doesn't show lighttpd as an alternative reverse dependency). I had to manually weed out many irrelevant packages, like -dbg, -plugins, -mod packages, and I skipped many of gnome packages for the sake of showing the effect on non-gnome users. It is certain there could be some errors. Large part of the result is valid.
Here, I patched debtree to ignore all alternative dependencies. The updated graph is largely unchanged: http://i.imgur.com/SxufNQ2.png . Error reports are welcome.
Posted Oct 24, 2014 1:20 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (9 responses)
Anyway, it still doesn't hard-depend on systemd. Libpam-systemd can work just fine with systemd-shim: https://packages.debian.org/jessie/libpam-systemd
Posted Oct 24, 2014 2:00 UTC (Fri)
by mchapman (subscriber, #66589)
[Link]
Moreover, libpam-systemd can work "perfectly well" -- as a no-op -- on systems that don't have any logind implementation at all. Looking at its code, it simply appears to check whether /run/systemd/seats/ exists, exiting successfully if it doesn't. Curiously, on Debian this check is patched out...
Posted Oct 24, 2014 2:32 UTC (Fri)
by xz (guest, #86176)
[Link] (7 responses)
Tell me, how do you install libpam-systemd without systemd? I'm sure you have reason for libpam-systemd to be technically optional, but why does it have a hard dependency on systemd? Is it a bug?
libpam-systemd itself is NOT optional if you happen to be one of the users of the packages I listed above. I listed hard reverse dependencies above to demonstrate which users will have to use systemd because of (reverse) dependencies. If everything depends on libpam-systemd but you're not using anything, I guess you can still have the truism of libpam-systemd being optional.
Posted Oct 24, 2014 2:39 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
libpam-systemd ( https://packages.debian.org/jessie/libpam-systemd ) has the following dependency:
>dep: systemd-sysv
So yes, systemd is optional and not required in Jessie.
Posted Oct 24, 2014 2:41 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (5 responses)
That's incorrect, libpam-systemd simply needs some files packaged in the systemd package. It doesn't require it running.
To actually activate systemd on Debian one needs to install the systemd-sysvinit package (or manually specify it in the kernel command line).
Posted Oct 24, 2014 3:38 UTC (Fri)
by xz (guest, #86176)
[Link] (4 responses)
Is the package designed for being installed without being used? No.
As Chapman pointed out, libpam-systemd is explicit patched in Debian to start logind on demand. Therefore libpam-systemd depends on and actively uses an integral component of systemd. If it is really as simple as using some files from the systemd package, why not put those files into libpam-systemd?
Or are you changing the definition of systemd? logind is not systemd! I know systemd the word can mean a lot of things.
P.S. who on earth think it is a good idea to start daemons from deep inside a library "on demand"?
Posted Oct 24, 2014 3:59 UTC (Fri)
by dlang (guest, #313)
[Link] (1 responses)
The first requires coding to fix, the second just requires packaging changes.
Since the systemd advocates have less than zero interest is supporting anyone not using systemd, it's not at all surprising that the packaging of the software drags in extra stuff
After all, it's the advocates who become package maintainers, they are interested in making that package work, not in supporting other packages working without their favourite software. It takes extremely mature maintainers to support that level of compatibility. This isn't the dig against systemd maintainers that it may sound like, _very_ few packages have maintainers or project leads that think about how people who don't use their whole package should be supported, either by breaking out components that are useful to others, or in terms of how users will be able to migrate cleanly away from the software.
Posted Oct 24, 2014 9:44 UTC (Fri)
by anselm (subscriber, #2796)
[Link]
Packaging software pretty much always involves tradeoffs.
It would probably be possible to divide the “systemd” package on Debian into a number of packages that split out library support, etc. However, given that systemd is the designated default init system for Debian, we can reasonably expect that in the future a majority of Debian systems will run systemd. This means that for most users, splitting systemd into a number of packages that will all be installed doesn't really add value – it mostly makes extra work for the package maintainers and increases the probability of bugs.
For those who don't run systemd as PID 1 but still need the package installed for the libraries, a few extra files likely won't make that much of a difference, and if at some point a reasonable case for separating out some functionality emerges (say, when kdbus becomes popular) then the package can still be split.
Posted Oct 24, 2014 4:37 UTC (Fri)
by mchapman (subscriber, #66589)
[Link]
The Debian systemd package maintainers, clearly.
As I pointed out, the upstream systemd code does not do this. If you use the upstream pam-systemd on a non-systemd system, it's a no-op.
Posted Oct 24, 2014 4:44 UTC (Fri)
by mchapman (subscriber, #66589)
[Link]
Well, I think Cyberax is wrong there. It isn't as simple as "using some files".
pam-systemd uses the logind D-Bus interface, org.freedesktop.login1. Anything that implements that interface correctly should work with it, which is why Debian's libpam-systemd can work with systemd-shim.
The error here is in removing the "test if logind even appears to be installed" check. While that's probably the right idea, in that I suspect systemd-shim doesn't create the directory it looks for, it means that D-Bus activation now takes effect: it's made pam-systemd *require* a logind D-Bus interface, instead of failing gracefully if logind isn't present.
Posted Oct 18, 2014 8:08 UTC (Sat)
by mgb (guest, #3226)
[Link] (4 responses)
A weak non-modular design might be laughable were it not being forced on us. Sadly the consequence of this weak non-modular design is indeed to make it harder to improve Linux in future.
> it do bring benefits for others
And that would be fine if it were an option. Those who have serious work to do could just use sysvinit or openrc until something better came along.
When one has choices one can ignore bad software. Ultimately the most serious bug in systemd is that it is being forced on us.
Posted Oct 18, 2014 8:35 UTC (Sat)
by mchapman (subscriber, #66589)
[Link]
You keep using those words.
On my system, systemd consists of 80 separate binaries. Only one of them runs as PID 1. The software as a whole consists of 7 different DBus interfaces, each of which could in theory be implemented independently. When building systemd you have a choice of 59 separate --enable/--disable options to choose the components you want.
In what sense is it "non-modular"?
> When one has choices one can ignore bad software. Ultimately the most serious bug in systemd is that it is being forced on us.
If you feel that you lack influence over your distro's software decisions, then that sounds like a problem between you and your distro.
Posted Oct 18, 2014 13:56 UTC (Sat)
by mathstuf (subscriber, #69389)
[Link]
You know, maybe if you cut it out with the backhanded comments, you'd have better discussions with others about systemd. As such, your apparent willful ignorance (e.g., insisting that it is non-modular) plus this makes you easily ignorable when you come with complaints.
Posted Oct 18, 2014 14:59 UTC (Sat)
by anselm (subscriber, #2796)
[Link]
Nothing is being “forced on you”. If you're a Debian user, the next version of the distribution will very probably still work with sysvinit – so far there are no packages that actually have a hard dependency on systemd as PID 1, and given that the freeze is just around the corner this is unlikely to change. That means that after the actual release of jessie (which is still some time away) there will be 2 to 3 years with jessie as “stable”, at least 1 year of additional security support after jessie+1 is released, and quite possibly even longer support under the auspices of Debian LTS, so a sysvinit-based Debian system should, as a conservative estimate, continue working with reasonable support for at least 4 years from now.
4 years should be ample either for Debian to figure out that systemd really is as crappy as some people claim and come up with a better approach for jessie+1, or for you to band together with other people who don't like systemd and create a systemd-free version of Debian jessie+1 (which should be straightforward even if Debian decides sysvinit support will not be mandatory in jessie+1 – consider that in jessie, all packages already support sysvinit, so it's not as if you would have to write a million init scripts from scratch).
Posted Oct 18, 2014 17:17 UTC (Sat)
by misc (subscriber, #73730)
[Link]
A more modular ( like actually modular in the sense there would be proper interfaces for module ) design would greatly help commercials vendors and out of trees kernels.
Yet, no one complain about that on the LKML would be considered, because as a community, we decide to not care about others people choice of license, and we think it is better to have all like this.
So tell us, why is the tight integration on the kernel fully ok despites having actual complain from coders since years and why is not ok on systemd ?
And why would it prevent innovation for userspace while it work fine with the kernel who kinda innovate a lot ?
In fact, thanks to systemd, there was much more innovation in the last 4 years than in 20 before. Your innovation point doesn't really work if anyone stop and think about it.
Posted Oct 18, 2014 10:44 UTC (Sat)
by cortana (subscriber, #24596)
[Link] (4 responses)
In fact, systemd's resource control & watchdog features can be used to deal with many of the above failure scenarios.
Posted Oct 18, 2014 12:40 UTC (Sat)
by peter-b (subscriber, #66996)
[Link] (3 responses)
> In fact, systemd's resource control & watchdog features can be used to deal with many of the above failure scenarios.
All of them, actually.
Posted Oct 18, 2014 17:04 UTC (Sat)
by misc (subscriber, #73730)
[Link] (2 responses)
Posted Oct 21, 2014 17:51 UTC (Tue)
by pbonzini (subscriber, #60935)
[Link] (1 responses)
Posted Nov 2, 2014 14:55 UTC (Sun)
by nix (subscriber, #2304)
[Link]
Posted Oct 18, 2014 21:15 UTC (Sat)
by jspaleta (subscriber, #50639)
[Link] (5 responses)
So starting with no gettys active I start a getty on tty4
and to manually restart it...
And then I can kill it off with
And looking at the getty service file seems its configured to always restart if it crashes... so I can test that... forcible kill the agetty process... and systemd respawns it as configured.
And starting up specific gettys on boot is easy as well through normal systemd target want mechanisms. arch wiki covers some of the options available to admins if you need a starting example.
So what am I missing with regard to getty restart that you want to do that systemd doesn't provide for? Serious question.
Given the capabilities I have access to right now with systemd's concept of targets, which are far more flexible than inittab's concept of runlevel.. I really don't understand the advantage of trying to keep support for inittab. I'm not aware of any functionality I'm giving up at present by not having access to inittab symantics.
Meh.
-jef
Posted Oct 19, 2014 14:09 UTC (Sun)
by flussence (guest, #85566)
[Link] (4 responses)
Some of RedHat's paying customers might be able to explain the value of not breaking a running system better.
Posted Oct 19, 2014 14:15 UTC (Sun)
by rahulsundaram (subscriber, #21946)
[Link]
Posted Oct 19, 2014 14:57 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Systemd haters simply latched on to a minor detail and now it's becoming an icon of anti-systemd crusades.
Posted Oct 19, 2014 20:49 UTC (Sun)
by anselm (subscriber, #2796)
[Link] (1 responses)
RHEL breaks stuff between major versions as if there was no tomorrow.
The good people at Red Hat do try to keep stuff stable within the same major version of RHEL,
which is good for more than a decade (i.e., longer than most servers last),
so upgrades from one major version to the next are rarely required.
Consequently, unlike Debian, Red Hat makes no attempt to even support
upgrading between major versions of RHEL.
Debian, on the other hand, makes no attempt to be RHEL. If you want that
sort of stability, be a Red Hat customer; it's their business, and they're
really pretty good at it.
Posted Oct 20, 2014 10:46 UTC (Mon)
by michich (guest, #17902)
[Link]
Posted Oct 18, 2014 1:46 UTC (Sat)
by misc (subscriber, #73730)
[Link]
See https://github.com/systemd/systemd/blob/master/src/core/m...
and the freeze() call, and the signal handler calling this function just after it.
Posted Oct 18, 2014 10:41 UTC (Sat)
by cortana (subscriber, #24596)
[Link] (27 responses)
Increased service availability.
> Who restarts init if it crashes? A trained monkey?
Hardware watchdogs can be used to reboot the system if either systemd or the kernel stop responding. You can read more about these features at http://0pointer.de/blog/projects/watchdog.html.
> If your daemon suffers from that, it should provide an overseer process.
As a sysadmin, I do not want to deal with n different implementations of service babysitters, each of which work slightly differently, and have their own bugs and configuration mechanisms. This stuff is too critical to leave to application developers.
As an application developer, I want to program to the much simpler "new-style daemons" interface described in daemon(7) rather than the "sysv daemon" interface from the same man page, because one is much quicker and easier to correctly implement than the other.
Babysitting should be done by the init system. Even Microsoft got this right with the design of the service manager in Windows NT!
> Or _you_ should use a configuration management/monitoring daemon, for which there are many to choose from today.
None of which can _really_ guarantee robustness, given that the *only* way to monitor a service properly on linux is to wait(2) on it, which can only be done to a process's children.
> Your solution is to bloat PID 1 with more mechanism and more policy, knowing there's a kernel panic if it crashes? That would be a glaring design flaw, yes. Init is engineered correctly as it is.
Please accept that these are merely your opinions. Those adopting & using systemd (and the init systems that came before it: NT's service manager, daemontools & friends, SMF, launchd, upstart) do not agree.
Posted Oct 18, 2014 12:09 UTC (Sat)
by Zack (guest, #37335)
[Link] (24 responses)
Can I have that in writing? Preferably something like:
"User Zack is entitled to have opinions. As such we, systemd proponents, will not rams ours down his throat by making software he might use have a hard dependency on systemd so he will be required to accept our opinions when upgrading."
Come to think of it, that's pretty much what the proposed GR is about, isn't it? That those who for some unfathomable reason cannot see the glorious nature of systemd and all that it encompasses (and will encompass) will not be required to use it.
Posted Oct 18, 2014 12:39 UTC (Sat)
by peter-b (subscriber, #66996)
[Link] (13 responses)
If, in my opinion, using systemd interfaces makes my software better, then I'll enjoy the freedom to use them. And you'll have still get to enjoy the aforementioned freedoms.
You have the freedom to have whatever opinions you like. Guess what? *So does everybody else.*
Posted Oct 18, 2014 12:58 UTC (Sat)
by Zack (guest, #37335)
[Link] (12 responses)
> You have the freedom to have whatever opinions you like. Guess what? *So does everybody else.*
If only everybody else who champions systemd would feel as strongly about this you do.
Posted Oct 18, 2014 13:06 UTC (Sat)
by pizza (subscriber, #46)
[Link] (11 responses)
> If only everybody else who champions systemd would feel as strongly about this you do.
Those who do the work, decide what gets done.
To paraphrase a saying, "Your right to hold an opinion ends when it requires me to perform unpaid work for you."
Posted Oct 18, 2014 19:24 UTC (Sat)
by Zack (guest, #37335)
[Link] (10 responses)
Why should I be doing unpaid work for an init system I do not want or need? It's great people like systemd and have a high opinion of it, but that opinion should really end when it's about to be installed on someone else's machine as a dependency.
Posted Oct 18, 2014 19:50 UTC (Sat)
by mathstuf (subscriber, #69389)
[Link] (8 responses)
And as has been linked in this article's comments already, nothing that worked with sysvinit before doesn't work now. As such, I think Lucas' amendment makes much more sense than Ian's.
Posted Oct 20, 2014 4:24 UTC (Mon)
by edomaur (subscriber, #14520)
[Link] (5 responses)
Anyway, as a sysadmin with a bunch of servers on Debian and RedHat EL, and I am quite happy to get systemd on both : this way, I will (probably) not needing to write the same scripts 2 time each, and I will be able to remove some complexity from my day job.
Posted Oct 20, 2014 10:21 UTC (Mon)
by Zack (guest, #37335)
[Link] (4 responses)
This isn't about systemd's availability in Debian, it's about preventing maintainers from deliberately stonewalling others from doing the work to keep an alternative init system usable because they are of the opinion that systemd should be the only viable option for Debian.
Posted Oct 20, 2014 11:45 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (3 responses)
AFAIK there is no evidence that this is actually a problem. Please tell me about such a case if one exists.
I don't think package maintainers will deliberately refuse to merge contributions by interested third parties that enable their packages to run with particular init systems. It's just that package maintainers should not be forcibly volunteered by third parties to come up with the required code by themselves if they don't want to (which would be against Debian's constitution).
One solution could always be to team-maintain the packages in question such that maintainer A can take care of the adaptation to init system X that maintainer B (for whatever reason) doesn't want to touch, while maintainer B maintains the adaptation to init system Y that maintainer A (for whatever reason) doesn't want to touch. On the whole, Debian package maintainers are reasonable people, and it should generally be possible to work something out.
Posted Oct 20, 2014 13:27 UTC (Mon)
by Zack (guest, #37335)
[Link] (2 responses)
> I don't think package maintainers will deliberately refuse to merge contributions
And I'm not so sure about that. This GR will (or will not) give me the reassurance that any work done on alternative init implementations (or maintenance of sysvinit) will not be blocked simply by systemd being the default.
This GR isn't about shoving around work; it's about reassuring those who are not (yet) convinced about systemd, that Debian is still a suitable distribution for them and that their contributions are welcome.
Posted Oct 20, 2014 15:31 UTC (Mon)
by anselm (subscriber, #2796)
[Link]
I think that the GR is only peripherally connected with that. As I said, even without the GR it is unlikely that package maintainers will deliberately decline to include support for other init systems than systemd if that support is volunteered by interested third parties.
It seems to me, though, that the GR in its present form tries to force package maintainers to create support for additional init systems even if the upstream package doesn't come with such support and nobody else steps forward to do it. In addition, it is unclear whether packages must support all init systems that are part of Debian or whether any two will do as long as one of them is systemd. One might also ask exactly what actually constitutes an “init system”.
In my opinion it is unreasonable to ask package maintainers to actively create support in their packages for additional non-default init systems. As of now most if not all relevant packages do support sysvinit, and that support should not be removed without good cause. Bug reports can be opened if required, and if the package maintainers don't (or can't) take care of them themselves then those people who are sufficiently interested in keeping sysvinit support going in Debian can help out. The same goes for support for things like Upstart; I don't think package maintainers should be compelled to add, debug, and maintain Upstart support for packages that don't come with it in the first place. If they want to do it, fine; but let those people who are interested in widespread Upstart support in Debian do the work if the package maintainer won't or can't do it, and have the package maintainer integrate it once it is done.
Posted Oct 20, 2014 17:32 UTC (Mon)
by jspaleta (subscriber, #50639)
[Link]
What this GR does is make specific set of potential release blockers... regardless of whether patches have been contributed or not.
And let me be clear about this... this GR is not scoped to be just about ensuring a systemd transition from sysvinit.
In the future, post jesse if uselessd shows up in the repo, and uselessd works as a systemd replacement that will meet the requirement of this GR, without anything having to continue to work with sysvinit.
And that is the fundamental problem with this GR. It's not actually addressing the specific ongoing concern of making sure users can transition from old default (sysvinit) to new default (systemd) with minimal disruption.
The abstract language of the GR about init choice is just silly. Nobody really expected everything to work with mini as an alternative init without a lot of close hand-to-hand combat by the admin. The "freedom" to choose an alternative init has been until this point in time the "freedom" to break your system by choosing to use an alternative init.
This GR tries to make an overly broad policy statement that drastically changes the character of how all alternative inits are to be handled, but does not actually do anything to address the ongoing concern of transitioning from an old default init to a new default init...which is the only actionable concern that was triggered by choosing to change the default init.
-jef
Posted Oct 20, 2014 21:29 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (1 responses)
Actually, the LO devs (and I should know, I'm involved in it) ARE rewriting LO to remove the Java dependency. Incidentally, if you do build LO --without-java, pretty much the only thing that will break is Base.
Cheers,
Posted Oct 26, 2014 19:23 UTC (Sun)
by HelloWorld (guest, #56129)
[Link]
Posted Oct 20, 2014 0:56 UTC (Mon)
by HelloWorld (guest, #56129)
[Link]
Posted Oct 18, 2014 12:56 UTC (Sat)
by cortana (subscriber, #24596)
[Link] (3 responses)
Posted Oct 18, 2014 20:29 UTC (Sat)
by jspaleta (subscriber, #50639)
[Link] (2 responses)
-jef
Posted Oct 21, 2014 21:33 UTC (Tue)
by nix (subscriber, #2304)
[Link] (1 responses)
And this is supposed to *dissuade* us? :P
Posted Oct 21, 2014 21:35 UTC (Tue)
by jspaleta (subscriber, #50639)
[Link]
Posted Oct 19, 2014 15:24 UTC (Sun)
by misc (subscriber, #73730)
[Link] (5 responses)
Once this social dynamic is understood, you can clearly see that any user protests is going to have almost no traction, especially since that's one of the strong point of Debian, being free from pressure. A commercial distribution where you pay money would be a different beast, since the customer is listened, due to the fact he exchange money for the work, so the relationship is balanced. A community distribution, not so much.
So you decided to take a distribution where no one can influence it, so you get what you asked for
Posted Oct 19, 2014 23:17 UTC (Sun)
by jb.1234abcd (guest, #95827)
[Link] (4 responses)
Once this social dynamic is understood, you can clearly see that any user protests is going to have almost no traction, ..."
I think your interpretation of this social dynamic is lacking.
Now with regard to systemd.
If systemd were not questioned the way it was (which forced the devs to
From this point of view alone, this Debian's GR is an attempt to limit
So, this alone invalidates your interpretation of one-way social dynamic that presumably governs relations between devs and the rest of OSS
jb
Posted Oct 20, 2014 11:13 UTC (Mon)
by vonbrand (subscriber, #4458)
[Link]
Said closed dev cabal, who you claim developed everything in a closet with no input whatsoever from the wider community, does include someone from all important distributions. Their "in a closet" development model contemplated detailed analysis of extant init systems (not only Unixy ones, BTW), careful consideration of existing configuration file formats and locations among Linux distributions, and extensive consultation with interested parties. Go check systemd's blog for development (pre)history.
Posted Oct 20, 2014 17:45 UTC (Mon)
by misc (subscriber, #73730)
[Link] (1 responses)
Sure, you can think users are part of the movement and they are, but the truth is quite clear. There is no voting right for them, and they are barely acknowledge. Most distribution do not have a group dedicated to feedback from people. never wondered why there is several bug reporting tools for free software, but not so much to get feedback with a clear user orientation ?
When there is a problem, the priority is on the developer side, by pushing the work on users ( ie, filling a bug report ), because we clearly put more value on the time of people who contribute code than people that don't.
You can delude yourself in the state of free software, and I would be the first one to say that this balance of power is unfortunate and should be fixed.
Yet, being sorry about the state of affairs doesn't make it disappear, no matter how hard you want to believe. If you want things to change, you have to be constructive and do something, not just protest and post. As Linus once said "talk is cheap, show me the code".
Posted Oct 20, 2014 20:31 UTC (Mon)
by pizza (subscriber, #46)
[Link]
When there is a problem, it is up to the person who finds the problem to report it. That's not "pushing work on users" or making value judgements of anyone's time.
You can't fix what you don't know is broken.
Posted Oct 25, 2014 15:10 UTC (Sat)
by ms_43 (subscriber, #99293)
[Link]
Instead, the systemd project was started as an open bazaar-style community without silly CLAs that give a single corporation control, and the project managed to attract many contributors (https://www.openhub.net/p/systemd/contributors/summary).
You can educate yourself by reading Scott James Remnant's comments on this post:
Thus it is hard for me to see what "philosophy and rules of software development" were violated by the systemd project.
Posted Oct 18, 2014 15:07 UTC (Sat)
by ctpm (guest, #35884)
[Link] (1 responses)
>Hardware watchdogs can be used to reboot the system if either systemd or the kernel stop responding. You can read more about these features at http://0pointer.de/blog/projects/watchdog.html.
Yes, hardware watchdogs have been around for a very very long time and are obviously useful when a *kernel* stops responding or there is no process running in userspace to let you in and recover the system manually. And that is where HW watchdog use is justified -- as a last resort.
But if your failure is caused by a bug on a potentially complex thing like systemd, which could be recoverable by restarting that service alone, why would you want to bring the system down with mounted filesystems and everything? Think of a server exporting luns via network or a distributed FS shard. That spontaneous reboot may cost quite a lot in terms of recovery for the whole system. Why would you choose to nuke the system as a first option, when a least a good portion of it might be still doing useful work?
So IOW, I'm not saying that the service monitoring and recovery features on systemd are useless. I'm saying that the complex logic and state machines to handle that, should run on a child of PID 1, not in PID 1 itself.
Posted Oct 18, 2014 18:43 UTC (Sat)
by peter-b (subscriber, #66996)
[Link]
I'm not sure why you consider it unreasonable to put functions for starting and monitoring services into a process that's sole role and reason for being is to start and monitor services...
Posted Oct 20, 2014 12:19 UTC (Mon)
by josh (subscriber, #17465)
[Link]
That's one of init's primary jobs, and has been since long before systemd. In particular, note that sysvinit has similar functionality to restart processes if they're launched via inittab rather than init.d; it doesn't work as well, but it does exist.
Posted Oct 21, 2014 16:56 UTC (Tue)
by nix (subscriber, #2304)
[Link]
Posted Oct 17, 2014 19:54 UTC (Fri)
by HelloWorld (guest, #56129)
[Link] (10 responses)
Posted Oct 20, 2014 21:33 UTC (Mon)
by da4089 (subscriber, #1195)
[Link] (9 responses)
Posted Oct 20, 2014 22:17 UTC (Mon)
by louie (guest, #3285)
[Link]
Posted Oct 21, 2014 17:24 UTC (Tue)
by HelloWorld (guest, #56129)
[Link] (7 responses)
Posted Oct 21, 2014 18:33 UTC (Tue)
by mgb (guest, #3226)
[Link] (6 responses)
Sorry. Most people here are already familiar with KISS.
Pid 1 is the privileged process which is the first started (and therefore usually has to start some more processes) and which handles orphans.
Putting functionality in pid 1 which doesn't have to be in pid 1 is a violation of KISS. Violating KISS wrt pid 1 is serious because of the negative consequences for stability and security.
The only reason systemd has additional functionality in pid 1 is RH EEE.
Posted Oct 21, 2014 20:19 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
> The only reason systemd has additional functionality in pid 1 is RH EEE.
Or, you know, maybe because people find it useful?
Posted Oct 21, 2014 20:33 UTC (Tue)
by jspaleta (subscriber, #50639)
[Link]
since systemd never supported inittab, there was no embracing action with regard to sysvinit's API.
I move for dismissal.
-jef
Posted Oct 22, 2014 7:20 UTC (Wed)
by palmer_eldritch (guest, #95160)
[Link] (1 responses)
You're talking about DBus and cgroup management?
Posted Oct 24, 2014 8:16 UTC (Fri)
by jezuch (subscriber, #52988)
[Link]
Case in point: microkernels.
The Linux kernel is such a blatant violation of KISS that I'm surprised any self-respecting engineer takes it seriously.
/sarcasm
Posted Oct 22, 2014 18:09 UTC (Wed)
by rgmoore (✭ supporter ✭, #75)
[Link] (1 responses)
Two points to refute this:
A good example of this is the Linux kernel. In theory, it could be made much simpler by adopting a microkernel architecture. In practice, we don't do that, partly because modular kernels have performance advantages and partly because it's really just pushing the complexity into userspace drivers rather than eliminating it from the system as a whole.
The same thing is generally true of the added complexity of systemd vs. sysvinit. Yes, the actual PID 1 is much simpler with sysvinit, but a lot of that is because it doesn't provide much in the way of functionality. Instead, that functionality winds up being provided by other parts of the system. By trying to keep PID 1 simple, you wind up with less functionality and more complexity in the whole system.
Posted Oct 22, 2014 21:18 UTC (Wed)
by louie (guest, #3285)
[Link]
Thank you for stating that so well and concisely.
Posted Oct 17, 2014 19:56 UTC (Fri)
by tao (subscriber, #17563)
[Link]
Posted Oct 18, 2014 8:59 UTC (Sat)
by hunger (subscriber, #36242)
[Link]
This low level stack and its interfaces is what provides value to developers. For this reason uselessd is so hilarious: It keeps the comparatively boring part of systemd and removes the interesting parts.
I would appreciate seeing alternate implementations of those interfaces -- things like the logind shim and systembsd that are independent of systemd-the-init-system. Once those are stable it actually makes sense to have software higher up in the stack depend on the interfaces they use. Currently they simply depend on "systemd" -- simply because that is the only implementation of the interfaces that is available in the distribution at this time.
In fact debian ships the logind shim, and even Ian admits that this works. He agreed that his resolution will not cause any RC bugs at this time.
Of course the alternate implementations of systemd-the-low-level-stack will also depend on an particular init system: There are reasons for systemd to have those dependencies after all.
Posted Oct 18, 2014 12:27 UTC (Sat)
by maniax (subscriber, #4509)
[Link] (6 responses)
Posted Oct 18, 2014 12:40 UTC (Sat)
by HelloWorld (guest, #56129)
[Link]
Posted Oct 18, 2014 12:43 UTC (Sat)
by mchapman (subscriber, #66589)
[Link] (1 responses)
Maybe it is "almost nobody", but it's certainly been my preferred service manager for sysvinit and Upstart systems, at least for services that don't come with their own initscripts. I have no intention of running it on systemd systems though. There'd be no point.
Posted Oct 18, 2014 14:10 UTC (Sat)
by cortana (subscriber, #24596)
[Link]
Posted Oct 18, 2014 12:57 UTC (Sat)
by Jandar (subscriber, #85683)
[Link]
License.
DJB is a proponent of free software, but his license sucked.
Daemontools README:
This gives you absolutely no rights. Not to use, to modify or to distribute.
6 years later in http://cr.yp.to/distributors.html:
This was to late. Everyone knew by than daemontools is nice but the lawyers say: no way.
Posted Oct 18, 2014 14:10 UTC (Sat)
by anselm (subscriber, #2796)
[Link]
People who don't like systemd because they think its lead developer is rude probably shouldn't go anywhere near daemontools.
Posted Oct 18, 2014 16:17 UTC (Sat)
by weue (guest, #96562)
[Link]
Systemd is the best you can do regardless of any constraint.
Posted Oct 18, 2014 16:03 UTC (Sat)
by weue (guest, #96562)
[Link] (3 responses)
0. Rationale
Lennart Poettering is the Lord our God.
1. Policy
1.1. We shall have no other init systems other than Systemd
Posted Oct 18, 2014 18:46 UTC (Sat)
by peter-b (subscriber, #66996)
[Link] (2 responses)
Posted Oct 18, 2014 19:45 UTC (Sat)
by weue (guest, #96562)
[Link]
Posted Oct 19, 2014 14:54 UTC (Sun)
by seyman (subscriber, #1172)
[Link]
It does give me the opportunity to use lwn's comment filtering system.
Posted Oct 18, 2014 17:42 UTC (Sat)
by mgb (guest, #3226)
[Link] (11 responses)
According to systemd proponents this proposed GR is both a no-op and the end of the world. This is because systemd rollout relies on the concept of breakable promises. For Debian to use a GR to enforce a promise is somehow unfair.
Systemd is a weak non-modular design - a rat's nest of processes and D-Bus interfaces. This is deliberate - systemd is not about init, it is about control. Systemd's oft-stated goal is to leverage itself into a takeover of the entire Linux plumbing layer. Debian is to be subjected to systemd's mediocre network configuration, mediocre process monitoring, mediocre time service, and mediocre everything else. The serious downside to systemd's lack of modularity is already apparent - over time it becomes increasingly difficult to replace any one component of systemd with something better. Systemd thus makes it much harder to improve Debian and Linux in future.
Systemd supports only Linux. It requires glibc in pid 1, which makes it too big for embedded. Systemd's logging is too slow for most serious servers, and it's even worse if you need forwarding. Systemd is the opposite of Debian. If Debian becomes dependent on systemd it puts RH in control, allows RH to portray Debian as perpetually playing catchup to RHEL, and gives RH an opening to replace Debian in the embedded world with a new non-systemd RH offering.
Only eight DDs have voted on this issue. Most of them voted despite serious conflicts of interest, and one of them voted twice. It's time for the real DDs to have their votes counted. It's time to protect Debian and F/LOSS from RH and systemd.
Posted Oct 18, 2014 18:23 UTC (Sat)
by pizza (subscriber, #46)
[Link] (2 responses)
I call Bullshit.
network configuration: strictly optional.
> Systemd supports only Linux.
So does sysvinit and upstart incidentally. All those shell scripts? Also relying on non-portable linux-isms for things like job control.
> It requires glibc in pid 1, which makes it too big for embedded.
Nope, it does not require glibc; it requires Linux-specific stuff that glibc and some other libcs implement.
Incidentally, "embedded" folks would beg to differ with you when it comes to "sizes"
Anything that's too small to hold glibc is also going to be too small to hold Debian, incidentally.
>Systemd's logging is too slow for most serious servers, and it's even worse if you need forwarding.
s/serious/applications requiring hundreds of thousands of log messages per second/ -- which is a niche use case.
Also, the ability to bypass the journal has already been committed and will be in the next release of systemd.
> Systemd is the opposite of Debian.
That is a pretty nonsensical statement on the face of it.
> If Debian becomes dependent on systemd it puts RH in control
No more so than Debian becoming reliant on the Linux kernel, GCC or glibc, which RedHat also "controls" using your definition.
> allows RH to portray Debian as perpetually playing catchup to RHEL
Even if this were true, so what? It's not like they're competing for the same type of customers.
> and gives RH an opening to replace Debian in the embedded world with a new non-systemd RH offering.
This is even more ludicrous than your last statement.
FYI - Anything truly embedded won't use RHEL *or* Debian; they're both far too large and cumbersome.
> It's time to protect Debian and F/LOSS from RH and systemd.
So I take it you don't use GCC, glibc, or the Linux kernel either? Not to mention the literally dozens of other things they directly fund or contribute to:
http://fedoraproject.org/wiki/Red_Hat_contributions
RH is the single largest corporate contributor to F/LOSS, period, and their employees do even more in their own time.
Posted Oct 19, 2014 15:38 UTC (Sun)
by misc (subscriber, #73730)
[Link]
Openstack integration is Ubuntu or RHEL/Centos. Docker (who is the new big stuff, according to analysts and others) is being pushed on RHEL, Canonical following. Cloud in general do not see much Debian as host, the dominants free software private PaaS are Ubuntu ( cloud foundry ) or RHEL based ( openshift ).
Gnome is likely developed on Fedora or Ubuntu, Unity on Ubuntu, and so does part of KDE, so the desktop innovation is not on Debian either.
And when it comes to configuration management, I see more often ubuntu than Debian. Given Canonical push on the mobile, I wouldn't be surprised to see that "embedded" Debian is also losing ground to Ubuntu there.
I still see Debian is strong is with academics and activists, and that's all. It was not really like this before, and IIRC, it was the topic of a debconf talk 2 or 3 years ago.
So sure, you can also decide that keeping a old init system is gonna be so much better when it come to innovation. But you cannot complain that systemd is feature bloat and at the same time do not bring features, that's just incoherent.
Posted Oct 21, 2014 21:42 UTC (Tue)
by nix (subscriber, #2304)
[Link]
Posted Oct 18, 2014 20:29 UTC (Sat)
by weue (guest, #96562)
[Link]
Once all Linux systems run on systemd, it becomes much easier to introduce system-wide changes and to quickly evolve conventions, because you only have to change systemd rather than having to convince all distributions to change.
However, it's open source software, so anyone can replace any of its components that he deems to be mediocre, and Debian can very well package a version with whatever changes they want, just like they do with the kernel.
Posted Oct 18, 2014 20:55 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Several people posted patches in systemd mailing list to do just that.
Posted Oct 26, 2014 11:12 UTC (Sun)
by ms_43 (subscriber, #99293)
[Link] (5 responses)
This sounds quite disrespectful to the members of the Debian technical committee. Yes, 3 of them were current or former employees of the corporate owner of upstart, but why do you believe that they didn't also genuinely believe that upstart was the best choice for Debian when they voted it above systemd?
Posted Oct 26, 2014 19:43 UTC (Sun)
by HelloWorld (guest, #56129)
[Link] (4 responses)
Posted Oct 27, 2014 9:42 UTC (Mon)
by tao (subscriber, #17563)
[Link] (3 responses)
Things like the "COMEFROM"-like dependency handling (start on started), sigstop to indicate readiness and ptrace for pid-tracking are things that might seem totally normal if you're "born" with them, but totally bizarre if you observe them from a neutral perspective.
Posted Oct 27, 2014 19:02 UTC (Mon)
by HelloWorld (guest, #56129)
[Link] (1 responses)
On my last job I wasn't allowed to receive gifts from the people I was professionally involved with, and if it couldn't be avoided, I had to turn them in and they would be disposed of. And that's *not* just because my employer was concerned that gifts might affect my judgement but because if I had received a gift from a person affected by my decisions, it would be impossible for third parties to ever be *sure* that that gift didn't affect my judgement. IOW, receiving gifts would have undermined my trustworthiness regardless of whether and how they affected my judgement.
And it's similar here. Maybe the concerned committee members were (directly or indirectly) affected by their (former) employer and maybe they weren't, but it's impossible for third parties to ever be sure about this. The professional thing would have been to abstain, definitely for Colin Watson and Steve Langasek and probably for Ian Jackson, too.
Posted Oct 27, 2014 19:26 UTC (Mon)
by bronson (subscriber, #4806)
[Link]
The important bit: "shall disqualify himself in any proceeding in which his impartiality might reasonably be questioned." Note that merely the question needs to exist. Evidence does not.
I was really surprised this wasn't more of an issue in the last vote, especially since the vote split so cleanly down "employed/funded by Canonical" lines.
Posted Oct 28, 2014 7:58 UTC (Tue)
by anselm (subscriber, #2796)
[Link]
They could have done what various other people on the committee did, namely take a close technical look at both systemd and Upstart from the point of view of what would be best for Debian (rather than Ubuntu). As it was, their main argument for Upstart was something like “We can't stand Poettering, and surely someone could add stuff to Upstart to make it as good as systemd before jessie comes out, even if that stuff can't be upstreamed because of Upstart's CLA.”
If Debian had gone with Upstart that would have been a tremendous boost for Ubuntu, which gets lots of packages from Debian. The Ubuntu crowd could have saved themselves from having to create loads of native Upstart configuration files for packages that so far used Upstart's sysvinit compatibility on Ubuntu. In addition, having Debian on board with Upstart would do a lot to counter the perception that Upstart was a niche Ubuntu thing (modulo Chrome OS). It should be noted for the record that these issues have nothing to do with technical merit of Upstart vis-à-vis systemd.
Even so, these two points created a powerful incentive for the (ex-)Canonical crowd on the Debian tech-ctte to push Upstart – and anyone studying the discussion can tell that there was a lot of kicking and screaming going on. The proper thing would have been for these people to recuse themselves from voting (they could still have participated in the discussion in order to advocate for Upstart on its technical merit) but as we all know that didn't happen.
Posted Oct 18, 2014 23:39 UTC (Sat)
by zblaxell (subscriber, #26385)
[Link] (1 responses)
The GR does put some more work on systemd proponents--as it should, since the systemd transition is still highly disruptive to current users. systemd proponents made various choices that make transitions harder, so they get to help fix them. They don't get to say "we've decided to permanently break the essential package on all Debian systems because democracy and marketing" and walk away from responsibility for the technical work of making a smooth transition to the next release.
There are a lot of good ideas in systemd, but it needs to be broken down into less co-dependent pieces that can be upgraded separately. Separation is technical necessity when the "it has been 0 days since we last modified the core" clock keeps getting reset by new code, and the "it has been 355 days since our last privilege-escalation CVE" clock keeps getting reset by what looks like a bug-compatible assimilation of PolicyKit. (Why would you do that?)
I would care more about this GR if Debian hadn't done such a poor job on the Wheezy upgrade. I ended up having to fire the Debian-maintained sysvinit scripts for storage, networking, and service management and replace most of them with my own. Now it hardly matters which binary execve()s them.
Posted Oct 19, 2014 1:00 UTC (Sun)
by jspaleta (subscriber, #50639)
[Link]
The GR is entirely unnecessary. It does not solve an existing problem, not does it provide a useful tool to better solve problems that have come up already and been dealt with through existing policy and collaboration. It only creates potential secondary problems in the future.
Right now the only outstanding issue is how to deal with upgrades to jesse that need to install either systemd-shim or systemd-sysv to meet dependances associated with systemd-logind's depchain. That's it. For users who don't care about moving to the default init for jesse as part of the upgrade they get one package. For users who care about keeping sysvinit as alternative init, they will need the other package. And this GR doesn't even come close to dealing with the current discussion on how best to encode that logic in the packaging and debconf.
This GR is pointless and is just sucking up manhours. There is no standing issue associated with running sysvinit and using systemd-shim to provide the necessary dbus API that higher level bits expect to see. hostname, timedate and all the systemd APIs that bits of GNOME and everything else are handled by -shim on non systemd init jesse because people have done the work to make sure -shim is available. GR or no GR that's how this sort of things is going to be solved moving forward as applications grow deps on dbus facilitated APIs.
to wit... the GR actually has some very bad secondary consequences because the proposal submitted doesn't specifically talk about ensuring applications continue to work with sysvinit. It just talks about any alternative init working.
It could be argue that all inits have to continue to work. If that's how you interpret then packages have to be sure they work with all inits no matter what their interaction design is. And considering that the linux kernel will basically let you make almost any executable pid=1 via a kernel cmdline argument, we quickly see how even the definition of an "init" system becomes problematic. Bash as init... sure why not.
And there's no requirement that an init system have to be drop in compatibility with sysvinit. so minit, runit or cowsay or anything else you can run as PID 1 would all have to work equally well or be considered an RC bug. That's unworkable and adding one additional toy init into the repo that applications do not work with would trigger a cascade of rc level bugs for post jesse. That's stupid and would only act to prevent introduction of a new niche init.
Or it could be argued that just one additional init need be supported by an application that requires the systemd APIs. But most importantly it says nothing about that additional init being sysvinit. So you can easily get into a situation with this GR passing that something would work with runit as PID 1 and systemd PID 1 (or upstart and systemd) but NOT sysvinit and would meet the strictures of the proposal and it would absolutely not address the concern you are expressing here about being able to move from sysvinit at your own pace as an admin. And you build a landsca where apps work with different alternatives to systemd. Hell man, just a forked renamed systemd project could be included as an alternative init and would meet the strictures of the one alternative init requirement of this GR...since sysvinit compat is not specifically required.
And moreover its possible to have code that works only with runit or minit pid 1 that doesn't work with anything else. This has been true since runit/minit have been in debian. And this is not to pick on these executables at all. The point is this GR is very general and impacts _all_ the toy/niche inits that have existed for years when it really just wants to talk about the transition from old default to new default. I very much doubt anyone has done a full analysis of where the full repository stands right now with regard to what actually knows if the repo is clear of running afoul of this GR's restrictions when it comes to all the available inits collectively. And again... how you define "init" can be very very difficult as you can run almost anything as an "init"
Yes keeping a transition from the current default to the new default init working for users is a noteworthy concern. But the GR as proposed is taking advantage of that concern and is proposing something much more general and incorrectly scoped and will have secondary impacts. And the process of normal collaboration and workflow is working without the GR. There is no need for this GR.
Posted Oct 19, 2014 7:53 UTC (Sun)
by zeek (guest, #99418)
[Link] (57 responses)
We are about to merge the udev sources into the systemd source tree. After that, the next version of systemd will continue with udev’s version numbering, i.e. jump immediately from 45 to 184. After udev is merged into the systemd tree you can still build it for usage outside of systemd systems, and we will support these builds officially. In fact, we will be supporting this for a long time since it is a necessity to make initrds (which lack systemd) work properly.
https://lwn.net/Articles/490413/
EXTEND
Sporting an "Open Source Tea Party" T-shirt, Lennart Poettering used his linux.conf.au talk to introduce an effort that he and several others have been working on for the better part of the last year: reimplementing the D-Bus mechanism within the kernel.
https://lwn.net/Articles/580194/
EXTINGUISH
Also note that at that point we intend to move udev onto kdbus as transport, and get rid of the userspace-to-userspace netlink-based tranport udev used so far. Unless the systemd-haters prepare another kdbus userspace until then this will effectively also mean that we will not support non-systemd systems with udev anymore starting at that point.
http://lists.freedesktop.org/archives/systemd-devel/2014-...
Posted Oct 19, 2014 9:57 UTC (Sun)
by anselm (subscriber, #2796)
[Link] (56 responses)
Note that just because Lennart Poettering no longer thinks it is worth his (or his colleagues') time to maintain an obsolete niche communication scheme within udev once a better more general mechanism is available, that doesn't mean udev as such is going to go away. Nothing is being “extinguished”. It only means that those people who are actually interested in a non-kdbus udev get to maintain the legacy version of udev that doesn't use kdbus. In the free-software world, we call this “scratching your own itch”.
Also note that kdbus is not a systemd-only thing. It's just that right now the canonical userspace side of kdbus, like udev, happens to live within the systemd repository. If people hate systemd with such a passion that they simply will not touch systemd's kdbus library (even though that doesn't imply they need to take up anything else from systemd) then they will just need to bite the bullet and write their own kdbus userspace library (not exactly rocket science), which is going to be useful for more things than just udev.
Posted Oct 19, 2014 17:46 UTC (Sun)
by zeek (guest, #99418)
[Link] (31 responses)
Posted Oct 19, 2014 18:27 UTC (Sun)
by rahulsundaram (subscriber, #21946)
[Link]
Posted Oct 19, 2014 20:58 UTC (Sun)
by anselm (subscriber, #2796)
[Link] (13 responses)
The difference is that if Microsoft decides they no longer want to support
something, it's dead. Udev is free software, which means that a udev version
that doesn't use kdbus will exist for exactly as long as there are people (anyone, really, not just the original developers) willing to do the actual work to support it.
As a topical example, there are probably many people in this world who would be more than happy to put money in the kitty for somebody to keep Windows XP going forever even if Microsoft itself is no longer interested. However, since Microsoft, unlike Greg K-H and Kay Sievers, does not condescend to publish XP sources under a free license, this won't happen. Go figure.
Posted Oct 19, 2014 21:36 UTC (Sun)
by fmuellner (subscriber, #70150)
[Link]
Posted Oct 19, 2014 22:43 UTC (Sun)
by zeek (guest, #99418)
[Link] (11 responses)
The parallels between udev, Redhat, systemd and Java, Microsoft are chilling.
Posted Oct 19, 2014 22:51 UTC (Sun)
by rahulsundaram (subscriber, #21946)
[Link] (2 responses)
Posted Oct 23, 2014 4:09 UTC (Thu)
by zeek (guest, #99418)
[Link] (1 responses)
Posted Oct 23, 2014 11:39 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link]
Posted Oct 19, 2014 22:53 UTC (Sun)
by anselm (subscriber, #2796)
[Link] (7 responses)
Yep, that went really well for Microsoft and accomplished exactly what it was supposed to. After they were done with it Java never went anywhere and died. Everybody knows that.
Posted Oct 20, 2014 5:11 UTC (Mon)
by zeek (guest, #99418)
[Link] (6 responses)
Posted Oct 20, 2014 5:20 UTC (Mon)
by rahulsundaram (subscriber, #21946)
[Link] (5 responses)
Posted Oct 20, 2014 7:24 UTC (Mon)
by zeek (guest, #99418)
[Link] (4 responses)
Posted Oct 20, 2014 7:47 UTC (Mon)
by peter-b (subscriber, #66996)
[Link] (3 responses)
Exactly the same? So, that means that you can point me to: 1) a breach of contract and 2) a trademark violation. I'm waiting.
Posted Oct 20, 2014 22:20 UTC (Mon)
by louie (guest, #3285)
[Link] (2 responses)
* Deliberate subtle changes in widely-depended-on interfaces. (Hint: systemd is a complete replacement, not subtle replacements.)
The list could go on. And on.
As I said on twitter, the parent here is really hard to top for layers of wrongness per word - quite impressive, really!
Posted Oct 21, 2014 1:53 UTC (Tue)
by zeek (guest, #99418)
[Link] (1 responses)
* Deliberate changes in widely-depended-on interfaces.
(*) Redhat and its derivatives comprise more than 50% of Linux.
> As I said on twitter, the parent here is really hard to top for layers of wrongness per word - quite impressive, really!
What a weak-ass ad hominem attack! Can't argue this on its merits?
Posted Oct 21, 2014 3:50 UTC (Tue)
by louie (guest, #3285)
[Link]
Posted Oct 20, 2014 8:24 UTC (Mon)
by nhippi (subscriber, #34640)
[Link] (15 responses)
Likewise, arguing on the internets won't stop systemd. Bullshit talks code walks. Where are Ians patches to packages that depend on systemd?
Posted Oct 20, 2014 16:15 UTC (Mon)
by mgb (guest, #3226)
[Link] (14 responses)
All the necessary code to support sysvinit already exists in Wheezy. At most it might need to be recompiled.
We do however need a GR to prevent a very small number of people from harming Debian by removing sysvinit support.
Posted Oct 20, 2014 16:31 UTC (Mon)
by johannbg (guest, #65743)
[Link]
No but as has been repeated on numerous occasion is that you do need to write patches for other applications and application stacks for example read this [¹] and answer the question to whom does the burden fall having to come up with, carry and maintain the alternative to systemd logind which is provided to support the $other_initsystems in Debian for this particular application stack?
1. http://blog.martin-graesslin.com/blog/2014/10/libinput-in...
Posted Oct 20, 2014 16:37 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link] (12 responses)
Is there an instance of this that you can link to? Or is it a strawman?
Posted Nov 9, 2014 7:20 UTC (Sun)
by mgb (guest, #3226)
[Link] (11 responses)
Gnome 3 of course needs systemd but Gnome 3 is totally avoidable so it is not a problem.
The most obstructive borged package is probably policykit-1. A separate systemd-policykit-1 could trivially have been created while leaving the working package in Jessie but instead the working package was replaced.
Another egregious borgee is bsdutils. The good version works fine with both syslog and journald but a ridiculous function was added to Jessie which bloats Essential with libsystemd0 and more.
In all we currently pin five Wheezy packages and thereby avoid both systemd and systemd-shim in Jessie. We will have to pin or replace a half dozen more packages in order to avoid libsystemd0. These numbers may change depending on the outcome of the GR between the borg and the free DDs.
Posted Nov 9, 2014 8:10 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link]
I'm a rabid systemd fan and I've been biting people all the time, infecting them left and right with systemd-virus.
However, I have a slight problem with sysv-phobia. How can I excise every last trace of it from my systems? I tried removing sysvinit-utils, but it totally b0rked my system by removing everything!!!
Why do you insist on forcing megabytes of dead SysV weight on everyone???
Posted Nov 9, 2014 13:46 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link] (9 responses)
As for polkit1, if parallel packaging efforts would have been possible, why not package it yourselves ("you" being the "we" you, mgb, keep referring to)? Here, you would have forced a rename of a package where the old one may well have been unmaintained /anyways/ and potentially dropped unless someone stepped up. This route seems much more manageable than threatening a fork of the distro where you claim system-wide breakage when the actual defect set is of size 1 and would potentially be solvable with a parallel packaging effort. It also seems small enough to not deal with the inflammatory threads part of the GR[2] so much and burn so much time and energy from the entire DD community.
[1]One example that comes to mind is the set of packages for the current Fedora theme (artwork, icons, and cursors) when I'm completely happy with bluecurve. So I'm forced to have adwaita (at least today) when I don't use it at all with no loss of functionality.
Posted Nov 9, 2014 15:28 UTC (Sun)
by mgb (guest, #3226)
[Link] (8 responses)
libsystemd0 is still a problem. It bloats Essential and is itself deliberately monolithic and therefore a roadblock to F/LOSS progress.
We're evaluating alternatives to decide where to go next. Jessie looks possible but increasingly inconvenient. We need to move before Stretch and my guess is we'll be on a more modern distro before Wheezy EOLs.
Posted Nov 9, 2014 15:39 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link]
libsystemd0 is a small 250kb library. Hardly a 'bloat'. And it certainly doesn't interfere with you using upstart, sysv or whatever over crap you so want to use.
Posted Nov 9, 2014 17:16 UTC (Sun)
by jspaleta (subscriber, #50639)
[Link] (6 responses)
And you keep using the royal we... its just a bit creepy.
Posted Nov 9, 2014 17:33 UTC (Sun)
by mgb (guest, #3226)
[Link] (5 responses)
More modern distros may offer systemd as an option but they don't limit themselves to that fossilizing plumbing.
> And you keep using the royal we... its just a bit creepy.
"I" am posting here. "We" are working on this. "You" work alone?
Posted Nov 10, 2014 9:36 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (4 responses)
It would be interesting to find out who will actually be providing such a “more modern distro”. It seems that the current mainstream Linux distributions pretty unanimously won't.
Going with a niche distribution of course carries its own risks, including the one that the distribution in question, if avoiding systemd is not its major selling point, will eventually also include stuff that depends on libsystemd0.
Posted Nov 10, 2014 18:08 UTC (Mon)
by mgb (guest, #3226)
[Link] (3 responses)
Then Microsoft used EEE to seize power. So we moved forward with F/LOSS.
Then systemd borged many of the old distros. "You could try to escape us by forking but haha you couldn't possibly muster the resources." Well that might be true if we limited ourselves to old technology but there is newer and better technology.
Central Command & Control always stagnates. Free distros are the next future.
Posted Nov 10, 2014 18:19 UTC (Mon)
by jspaleta (subscriber, #50639)
[Link] (1 responses)
Can we just shelve this conversation until y'all are ready to present something concrete that uses the newer and better technologies. The coy references to unspecified better technologies is getting sort of tiring, it and sounds a lot like mealy mouthed vaporware hype. I don't even know wtf technologies you are talking about at this point as you haven't actually pointed to candidate technologies. I'm glad your excited by unspecified new and better technologies. I look forward to evaluating these new and better technologies at whatever point in time you are prepared to make them public for critical review. Good day.
Posted Nov 10, 2014 19:45 UTC (Mon)
by mgb (guest, #3226)
[Link]
Emerge, OBS, and decentralized distribution are some of the technologies already providing more freedom than Redhat.
F/LOSS is progressing beyond Redhat-enforced conformity.
Posted Nov 10, 2014 18:57 UTC (Mon)
by bronson (subscriber, #4806)
[Link]
If true, this would require an immense amount of effort. What would their motivation be? And who exactly is "they"? You seem to implying an IBM or Microsoft Borg conspiracy... Is there a shadow group acting behind the scenes? Is there money behind establishing a service manager monopoly?
Also, "central command and control" describes this very resolution, doesn't it? Wouldn't you want to give Debian developers the freedom to make their own decisions?
Genuinely curious.
Posted Oct 20, 2014 17:23 UTC (Mon)
by timtas (guest, #2815)
[Link] (12 responses)
It's about time Lennart and his colleagues fork the kernel and put it in the systemd repo. Then, they can quickly get rid of all those niche communication schemes such as netlink, in the same process maybe remove all obsolete filesystems (everything apart from btrfs) and of course only start systemd as init.
People that don't like that because they are to stupid and slow to see the advantages of all that can then just go and scratch their own itch and fork from there,
Posted Oct 20, 2014 17:33 UTC (Mon)
by misc (subscriber, #73730)
[Link] (9 responses)
Maybe because gregkh is not a popular hate target ?
Posted Oct 20, 2014 17:40 UTC (Mon)
by timtas (guest, #2815)
[Link] (8 responses)
- Lennart refers to systemd as "his" code, if you really want, I can pull dig out the recent systemd mailing list entry where he states that (it was of course about a compatibily request).
Also note that at that point we intend to move udev onto kdbus as transport, and get rid of the userspace-to-userspace netlink-based tranport udev used so far. Unless the systemd-haters prepare another kdbus userspace until then this will effectively also mean that we will not support non-systemd systems with udev anymore starting at that point.
But you all know this, of course.
Posted Oct 20, 2014 20:35 UTC (Mon)
by jspaleta (subscriber, #50639)
[Link] (7 responses)
I do find it nicely ironic that a quote using the plural "we" after deriding use of a personal possessive pronoun in other contexts.
And you keep focusing on LP. GKH has been just as clear on the matter with regard to where kdbus is going. Even if the same mailing list thread where you lift that unattributed and uncited qoute from LP.. GKH weights in with this:
http://lists.freedesktop.org/archives/systemd-devel/2014-...
Thats pretty clear messaging from "kernel-side" to me.
31 messages in that thread... 2 of them are from LP.. one of which you quote without citing and 9 from GKH.. and GKH replies both before and after LP. I think you've gotten caught up in the mystique of LP by assuming he is singularly pushing an agenda.
Man I really look forward to seeing kdbus making into mainline. That's going to be pretty sweet.
And actually now that I think about it... positioning LP to take all the incoming irrational fire, makes it possible for all the other people working in the problem space to avoid taking much at all...and they can continue to work on things safe in the knowledge LP will get the blame. That would be sort of an interesting social hack to sidestep the trollscape, if LP were a completely synthetic persona mananged by a shadowly faceless cabal and not a real person.
Posted Oct 20, 2014 21:07 UTC (Mon)
by timtas (guest, #2815)
[Link] (6 responses)
Regarding the post of Greg you provided: There's nothing in there about stripping netlink support from udev, it's about firmware loading stuff. It's not about kdbus at all.
As for the inclusion of kdbus into the kernel. I don't mind at all, and would even welcome it.
You are guessing right that I'm one of them.
Posted Oct 20, 2014 21:32 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (1 responses)
Remind me again who is holding a gun to your head to force you to use systemd.
You're absolutely free to hang on to sysvinit for however long you're prepared to put in the necessary work. You could even pay someone to do it for you. What you don't get to do is to compel other people (like Debian package maintainers) to do that work for you for free if they don't want to.
Posted Oct 20, 2014 22:02 UTC (Mon)
by timtas (guest, #2815)
[Link]
Posted Oct 20, 2014 22:44 UTC (Mon)
by johannbg (guest, #65743)
[Link] (2 responses)
Systemd does not grab a hold of anything as you can see here [1] with all the "--disable" options but hey let's try not to stick with facts shall we.
What you and others which seem to be under the assumption that systemd is somehow swallowing one bit after another ( as oppose to see it for what it is providing much wanted, much needed competing solution to what already exist out there ) need to realize,accept and come to terms with is that wide variety of upstream application and application stacks developers are *choosing* to integrate their application and or application stack with systemd for wide variety of reasons.
For every upstream component that *chooses* to integrate themselves with systemd, will ( obviously ) make the life of distribution and others that want to use existing alternatives, either to systemd itself or what functionality systemd provides given upstream with, harder since those wanting to keep that compatibly or functionality with alternatives have to maintain ( and in certain cases come up with ) that themselves as is with anything else that directly conflicts with the direction or decision any upstream takes or made at any given time.
That is the price Debian community has to pay if they intent on supporting multiple init systems or otherwise conflict with upstream directions and decisions one way or another as well as any distribution or individuals that chose to do the same.
Blaming systemd for providing upstream with these options or blaming upstream for choosing to use what systemd provides is just silly since it is *you* that has chosen to go against what upstream thinks is best for itself and it's userbase.
1. http://cgit.freedesktop.org/systemd/systemd/tree/configur...
Posted Oct 20, 2014 22:58 UTC (Mon)
by timtas (guest, #2815)
[Link] (1 responses)
Posted Oct 20, 2014 23:57 UTC (Mon)
by pizza (subscriber, #46)
[Link]
As a FYI, You may want to consider how your advice applies to yourself.
Posted Oct 21, 2014 3:25 UTC (Tue)
by misc (subscriber, #73730)
[Link]
I guess that apply in both side. Maybe if people start to do something ( like packaging uselessd, nosh, etc for debian, adding features, discussing with DE to see what is the feature they need ), it would change.
Posting on lwn, not a chance to convince anyone.
Posted Oct 20, 2014 17:55 UTC (Mon)
by corbet (editor, #1)
[Link] (1 responses)
Posted Oct 20, 2014 18:14 UTC (Mon)
by timtas (guest, #2815)
[Link]
Posted Oct 21, 2014 21:47 UTC (Tue)
by nix (subscriber, #2304)
[Link] (10 responses)
Posted Oct 21, 2014 21:57 UTC (Tue)
by anselm (subscriber, #2796)
[Link] (9 responses)
Then you're mistaken.
Even if udev at some point uses kdbus rather than its own home-cooked netlink-based IPC mechanism, that doesn't mean it will “require systemd”. It's just that the kdbus userspace library happens to live in the systemd source code repository, much like udev happens to live in the systemd source code repository. It should be perfectly possible to use both without having to have anything to do with systemd proper.
Posted Nov 2, 2014 15:08 UTC (Sun)
by nix (subscriber, #2304)
[Link] (8 responses)
> Unless the systemd-haters prepare another kdbus userspace until then this will effectively also mean that we will not support non-systemd systems with udev anymore starting at that point.
So according to Lennart itself, it's not just a userspace library, it's systemd itself that's needed: the system must be a 'systemd system' in order to use udev from that point on. (Though I don't quite understand why kdbus usage would imply systemd: do all kdbus messages go through PID 1 or something? Seems most unlikely.)
(Note: this message was a pig to find due to its hiding in a thread with a somewhat unrelated subject line. Changing the subject line to something appropriate when massive incompatibilities are newly announced is apparently too difficult.)
Posted Nov 2, 2014 15:28 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link] (4 responses)
Posted Nov 2, 2014 15:42 UTC (Sun)
by nix (subscriber, #2304)
[Link] (3 responses)
That seems like an absolutely ridiculous architecture to me.
Posted Nov 2, 2014 16:35 UTC (Sun)
by raven667 (subscriber, #5198)
[Link] (2 responses)
Posted Nov 2, 2014 19:07 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Posted Nov 2, 2014 20:26 UTC (Sun)
by anselm (subscriber, #2796)
[Link]
To be precise, there is a userspace library that any program whatsoever can use to access kdbus, and the source code for that library happens to be maintained as part of the systemd repository. (The library also includes other systemd support functionality such as the journald client-side API, but that can probably be ignored if you don't want to use it in your program.)
That's really all there is to it. Using that library doesn't mean you need to use any other part of systemd, and if you hate systemd with such a passion that even the idea of using a library whose only connection to systemd is that it is part of the same source code repository and systemd uses it, too – then you will just have to bite the bullet and write your own kdbus client-side library.
Posted Nov 19, 2014 15:28 UTC (Wed)
by makomk (guest, #51493)
[Link] (2 responses)
Posted Nov 19, 2014 15:51 UTC (Wed)
by viro (subscriber, #7872)
[Link]
If nothing else, it's a thing to watch for in kdbus patches (and it's very close to NAK threshold, as far as I'm concerned, unless a very good explanation is given).
Posted Dec 12, 2014 7:53 UTC (Fri)
by smurf (subscriber, #17840)
[Link]
kdbus is implemented by a specialized file system. Any process can mount that someplace and bingo, a new kdbus instance.
Posted Oct 20, 2014 16:24 UTC (Mon)
by jb.1234abcd (guest, #95827)
[Link] (14 responses)
Posted Oct 20, 2014 17:15 UTC (Mon)
by tao (subscriber, #17563)
[Link]
Posted Oct 20, 2014 20:26 UTC (Mon)
by mgedmin (subscriber, #34497)
[Link] (2 responses)
Posted Oct 21, 2014 9:48 UTC (Tue)
by jb.1234abcd (guest, #95827)
[Link] (1 responses)
Posted Oct 21, 2014 14:20 UTC (Tue)
by tjc (guest, #137)
[Link]
Posted Oct 20, 2014 22:24 UTC (Mon)
by louie (guest, #3285)
[Link]
Posted Oct 21, 2014 0:44 UTC (Tue)
by rgmoore (✭ supporter ✭, #75)
[Link] (8 responses)
That's going nowhere. The people pushing that admit upfront that they don't have the time and energy to get involved as Debian Developers who would have a say on the GR vote, so there's no way they're going to have the time and energy to maintain a fork.
Posted Oct 21, 2014 1:00 UTC (Tue)
by louie (guest, #3285)
[Link] (7 responses)
Posted Oct 21, 2014 1:54 UTC (Tue)
by mgb (guest, #3226)
[Link] (6 responses)
"We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities."
Debian's users are highlighting the disconnect between the Debian Social Contract and the TC's pushing systemd über alles despite the objections of users. Indeed one member of the TC now seems to be actively censoring users' objections in debian-user.
Posted Oct 21, 2014 2:58 UTC (Tue)
by misc (subscriber, #73730)
[Link] (1 responses)
The fun part is that some ask for a vote of users without making any proposal on what is exactly a user. Would Ubuntu users get a vote ? Would Spotify or HP, heavy Debian users get a vote for every people in the company, or every server ? Would I get 4 votes if the family computer of me and my boyfriend and our 2 adopted childs is running Debian ? What about if I have a arm board somewhere ?
Posted Oct 24, 2014 5:08 UTC (Fri)
by csirac2 (guest, #99520)
[Link]
Posted Oct 21, 2014 4:55 UTC (Tue)
by louie (guest, #3285)
[Link]
So for someone to claim they are a Deeply Committed Debian User and also to have no clue who votes in Debian GRs, what the reasons are for that, how impossible it would be to change... it suggests they aren't actually all a very Committed Debian User. (Same with all the Very Concerned Debian Users at debianfork.org, who are willing to put in so much work that... none of them are DDs.)
Posted Oct 21, 2014 5:48 UTC (Tue)
by edomaur (subscriber, #14520)
[Link] (1 responses)
Posted Oct 21, 2014 10:49 UTC (Tue)
by jwakely (subscriber, #60262)
[Link]
Posted Oct 21, 2014 10:06 UTC (Tue)
by jezuch (subscriber, #52988)
[Link]
Which users? Those who shout the loudest, or those that are happy with Debian's choices and can't be bothered to shout as loud "I AM HAPPY!"? Vocal minorities tend to create, deliberately, an impression that they are representative of the entire community. But that's just dishonest. And no, we who are happy with systemd are not sheeple and this is not a case of silent acquiescence of millions.
For the record: I AM HAPPY! [Even though currently systemd doesn't boot my machine at home. But do I really have to be disgusted and spew hateful drivel because of that? It's just software, for goodness sake.]
Posted Oct 21, 2014 5:58 UTC (Tue)
by zeek (guest, #99418)
[Link] (11 responses)
Understanding this point is key to understanding one of the main arguments against systemd. Systemd due to its vertical integration at all levels of the Linux stack will create a Linux monoculture as the various distros will run the same software at all levels.
The systemd supporters are adapt at spreading pro-systemd FUD. This is frustrating and Debian should not stoop to this level. If one believed the systemd team sysvinit is so bug ridden in can barely boot a system. Strange that Linux runs on 485 out of the top 500 super computers in the world, and none of them use systemd.
We need to be vigilant, else Redhat will take over Debian from within. Understand that we want whats best for Debian. Viva Debian!
Posted Oct 21, 2014 7:12 UTC (Tue)
by louie (guest, #3285)
[Link]
Recent commits are from, just at a quick glance:
"they are trying to make Redhat better."
This is why SuSE, Arch, Mageia, and Tizen have adopted it? Or... is there some other reason?
Posted Oct 21, 2014 7:32 UTC (Tue)
by Felix (subscriber, #36445)
[Link] (8 responses)
Uhm, let's do a quick fact check:
Posted Oct 21, 2014 7:41 UTC (Tue)
by zeek (guest, #99418)
[Link] (7 responses)
Posted Oct 21, 2014 9:26 UTC (Tue)
by Felix (subscriber, #36445)
[Link] (1 responses)
He was #3 in commits over the last 12 months, even before Kay Sievers.
One other example:
He's #5 in commits.
One more:
He's #6 in commits.
Looking more to the bottom of the committer list you can also spot people from Intel and a lot of other companies. The fact that there are 193 committers detected by OpenHub in total tells you that this project can't be controlled entirely by Red Hat. (Then on the other hand that's what Red Hat always does with successful projects - hire enough developers so they can support the software in RHEL for 10 years.)
Posted Oct 21, 2014 12:01 UTC (Tue)
by johannbg (guest, #65743)
[Link]
Posted Oct 21, 2014 11:17 UTC (Tue)
by anselm (subscriber, #2796)
[Link] (4 responses)
First of all, it's not a bad thing to have people work on documentation. The traditional setup – which is documented a lot less well than systemd – could use some of those.
Secondly, it is easy to see that there are loads of obviously non-Red-Hat people in systemd who do way more than commit whitespace changes. Of course since that undermines the claim that systemd is really an attempt on the part of Red Hat to secretly force all distributions to be like Red Hat, we can see why you must deny this fact with great fervour, but denying it doesn't change the numbers.
Posted Oct 23, 2014 1:42 UTC (Thu)
by zeek (guest, #99418)
[Link] (3 responses)
Posted Oct 23, 2014 1:51 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link] (2 responses)
Posted Oct 24, 2014 7:08 UTC (Fri)
by zeek (guest, #99418)
[Link] (1 responses)
Posted Oct 24, 2014 7:39 UTC (Fri)
by Felix (subscriber, #36445)
[Link]
I pointed out three guys from the top committers list with 1,779 commits in total. As you can see systemd (project) has seen 17,367 commits in total. So these guys are good for about 10% of all systemd commits.
I mentioned that Openhub counts 193 committers which surely made a few commits.
Do think it is plausible that none of these commits was "relevant"? All just whitespace changes? Or "just" documentation?
I'll stop here because I think there is nothing to discuss here. If you add hard facts or links to real bug reports supporting your points that'll be appreciated otherwise it more like hot air to me.
Posted Oct 21, 2014 17:22 UTC (Tue)
by luya (subscriber, #50741)
[Link]
Posted Oct 22, 2014 11:01 UTC (Wed)
by jb.1234abcd (guest, #95827)
[Link] (35 responses)
Being dependent on one sys init software that you do NOT control is a risky
You have already seen the next trial balloons by some of them (that "systemd cabal"), like "The #systemd cabal wants to revolutionize distros and packaging".
Any half-remedies like systemd-shim or "systemd API translation layers" are
One is always behind, always following in somebody's (systemd's) footsteps.
Either you as a distro make your software independent from any particular sys init, or you are suicidal long-term.
One way to prevent a *one sys init* lockup is to do it administratively, as
The other long-term solution could be this, but to get all the ducks in line is improbable, if not outright impossible:
So, let's hope that the Debian voting devs do the right thing !
Linux From Scratch released non-systemd and systemd based versions. Wise !
I think it would be desirable if e.g. Arch Linux restrained systemd honchos in their own ranks and implemented OpenRC as an official alternative sys init system:
Systemd as known today is a time bomb, a precursor to Windows Linux in
I am sure the Linux/UNIX ecosystem will only then return to peace and
jb
Posted Oct 22, 2014 11:52 UTC (Wed)
by JGR (subscriber, #93631)
[Link] (5 responses)
> One is always behind, always following in somebody's (systemd's) footsteps.
> Would you be confident if *your* business had to follow these "visioneries" ?
> Either you as a distro make your software independent from any particular sys init, or you are suicidal long-term.
Posted Oct 22, 2014 13:24 UTC (Wed)
by jb.1234abcd (guest, #95827)
[Link]
This time is different, really ...
It is not about like any other package Debian has in its repo.
Here is what it looks like:
Do not fool yourselves - the signs are written all over the wall.
Keep in mind we just say "keep an active alternative sys init software".
jb
Posted Oct 22, 2014 14:13 UTC (Wed)
by mgb (guest, #3226)
[Link] (3 responses)
Other critical packages are modular and are not trying to take over login, networking, time service, logging, package management, udev, dbus, and whatever the systemd borg decide to assimilate tomorrow.
The systemd rat's nest makes it much more difficult to incrementally improve Debian in future.
Posted Oct 22, 2014 15:58 UTC (Wed)
by JGR (subscriber, #93631)
[Link] (2 responses)
Posted Oct 22, 2014 16:34 UTC (Wed)
by mgb (guest, #3226)
[Link] (1 responses)
What limited interface stability promises exist are explicitly stated to be revokable:
Systemd functions also have extremely limited reimplementability and support for non-systemd distros.
Posted Oct 22, 2014 17:28 UTC (Wed)
by pizza (subscriber, #46)
[Link]
Citation needed.
> Systemd functions also have extremely limited reimplementability and support for non-systemd distros.
You seem to be asserting that systemd only supports distros that use systemd.
Posted Oct 22, 2014 12:15 UTC (Wed)
by tao (subscriber, #17563)
[Link] (28 responses)
Being dependent on one libc that you do NOT control is a risky strategy.
Guess what?
When glibc went haywire, someone forked off eglibc.
The Linux kernel hasn't gone haywire, so no need to fork that one...
You're seeing making init systems independent as a good thing. Personally I see it as a nightmare. Why, you may ask? Because we lock ourselves down to the lowest common denominator. You're preventing software from taking advantage of really useful features, all for the "benefit" of outdated init systems that cannot boot a system in a reliable (as in predictable, race-free) manner.
If systemd had been a closed source project, I could've understood your concern.
Even if systemd had been a project that, like glibc, gcc or XFree86 of the past, doesn't accept any patches from anyone, I might have understood your concern.
But systemd is a free software project that is happy to accept patches (as long as they meet the minimum criteria of the project, meaning -- for instance -- no patches to work around deficiencies elsewhere).
If this GR passes, what's next? Requiring that we don't accept any software that require kernel interfaces provided by Linux that aren't supported by Hurd?
If any of the alternative init systems had features that aren't available in systemd and by their nature not possible to implement in systemd, there might be some benefit to this GR.
But as it is, the only thing the GR serves to achieve, is to force Debian Developers to either not package new software (or new versions of old software) or to force them to provide compatibility with non-default installations.
As per the original TC decision, the onus is on the users of systems that run non-default setups to provide patches (or find someone else to do it for them); the maintainers only have to apply these patches -- unless there are technical objections.
I hope that the joke/troll Debian fork actually happens though. That way maybe we could rid ourselves of some of the worshippers of cargo cult init programming (let's insert another sleep 2 here in this script, that'll solve the race condition) and focus on something more important -- high reliability (proper process monitoring), consistent behaviour (no race conditions), easier maintenance (similar/same unit files for all distributions that use systemd), proper dependency handling (socket activation), etc.
Posted Oct 22, 2014 12:41 UTC (Wed)
by timtas (guest, #2815)
[Link] (27 responses)
You really believe that socket activation is something new and great? Go and read a bit about inetd/xinetd and all. I already used it 10 to 15 years ago to allow the frequent ftp or pop3 connect on our machines. It.is.not.something.new. And the same goes for a lot of other systemd features. Binary logging for instance was already discussed in the early nineties, and considered shit by a majority. Just as it is now.
So, gotta go back to my cargo-cult programming, have a nice time in your new and better world.
Posted Oct 22, 2014 13:26 UTC (Wed)
by raven667 (subscriber, #5198)
[Link] (1 responses)
I have literally _no_ idea what you are talking about, I don't see any of those attributes in the text you responded to, are you sure you are in the right thread?
Posted Oct 22, 2014 17:05 UTC (Wed)
by timtas (guest, #2815)
[Link]
Posted Oct 22, 2014 14:16 UTC (Wed)
by misc (subscriber, #73730)
[Link] (24 responses)
Now, inetd/xinetd do not do the same ( it didn't support multiple socket for, one, no unix ), so there is a improvement.
And for the rest, if nothing is new, I still wonder why people complain since everything already exist, it should just be a transparent change.
Posted Oct 22, 2014 17:22 UTC (Wed)
by timtas (guest, #2815)
[Link] (23 responses)
- journald: Hard dependency, lots of people don't like it. Cannot be configured away. Believe me, a lot of people objecting to binary logging have thought long and hard about it and have their reasons.
- Too much happening in pid one that doesn't have to be happening there. I'm sure you've heard about that one before.
- the systemd -> logind -> gnome dependency story.
Generally speaking, a lot of people actually liked to UNIX way of things, of interchangeable components with all its advantages and disadvantages. Now, I'm sure you don't care about history and stuff, but the reason Linux was able to become so quickly so usable was in fact because other folks decided to release portable, platform-independant programs. That's why Linux users were able to use all the bsd stuff, all the gnu stuff and all the XFree86 stuff and have a working system so quickly. Now systemd doesn't care about that one bit. They did not decide to support cgroups, they make it a hard requirement. They did not decide to support a binary logger, they have it hardwired into it. I wouldn't be surprised if btrfs features will become a requirement of systemd in the future, as soon as all major distributions have switched.
Posted Oct 22, 2014 17:35 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (16 responses)
> - Too much happening in pid one that doesn't have to be happening there. I'm sure you've heard about that one before.
> Generally speaking, a lot of people actually liked to UNIX way of things, of interchangeable components with all its advantages and disadvantages.
To wit - the most popular Linux distribution (Android) dispensed with the whole X11 crap entirely.
Posted Oct 22, 2014 17:56 UTC (Wed)
by timtas (guest, #2815)
[Link] (3 responses)
So? The UNIX way doesn't cut with the current reality? You might be surprised how many totally current real people with current real systems strongly disagree with you. And about the "one big server with one graybeard lording his power over tons of small users": I don't know what movies you've watched, but you see, that's where you folks lose so many people: you either have a totally wrong and distorted conception of what the UNIX way means or else are just deeply insulting people for no reason. And then start wondering why so many people get so angry...
Posted Oct 22, 2014 18:30 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
A large portion of Unix infrastructure works mostly because certain race conditions are rare. It's not a big deal when you have just a couple of big servers and a live human administrator that can deal with problems that happen. It's another matter entirely when you have a 30000-machine cluster that works mostly on virtualized hardware. It's the same with the mobile phones - everything on them has to work without any administrative intervention.
Want an interesting story? Just yesterday we had a problem - sometimes an application failed to connect to the database server (PostgreSQL) working on the same node. Even though we have all the dependencies set up correctly in the initscripts (Debian Stable, no systemd in sight). Turns out that the local disk subsystem was sometimes experiencing slowdowns (down to 100kb/sec) during the node spin-up and PostgreSQL's init script doesn't check that the DB is actually ready. Whoops. Classic Unix infrastructure epic failure.
> And about the "one big server with one graybeard lording his power over tons of small users": I don't know what movies you've watched
Posted Oct 22, 2014 18:46 UTC (Wed)
by timtas (guest, #2815)
[Link] (1 responses)
Correct me if I'm wrong: But you're talking about limitations of sysvinit and not about limitations of the unix model. Of course in your situation service supervision seems to be a must, but, as has been pointed out many times by other people, is nothing that only systemd is providing and more importantly is certainly the least controversial bit about systemd.
About the beards: Sorry, haven't been to university, my experience comes from various companies that run some unix servers (2500 redhat systems in the last company). And grumpy, unhelpful sysadmins are just as common in the binary-logging, service-supervised windows world, I can tell you.
Posted Oct 22, 2014 20:07 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link]
What else is in systemd? I don't really care much about hostnamed or NTP client daemon. We also have highly customized networking and it works great for us with systemd.
> but, as has been pointed out many times by other people, is nothing that only systemd is providing and more importantly is certainly the least controversial bit about systemd.
> About the beards: Sorry, haven't been to university, my experience comes from various companies that run some unix servers (2500 redhat systems in the last company). And grumpy, unhelpful sysadmins are just as common in the binary-logging, service-supervised windows world, I can tell you.
In the old world, it wasn't unusual to have just one or two large servers per administrator. So custom solutions like modified init.d scripts were acceptable and commonplace, administrators could handle the conflicts during upgrades. So that led to a culture where hacks like 'sleep 10' to avoid race conditions were perfectly acceptable.
Posted Oct 22, 2014 19:00 UTC (Wed)
by johannbg (guest, #65743)
[Link] (7 responses)
You dont happen to have a reference to that (hack) by any chance?
Posted Nov 2, 2014 15:11 UTC (Sun)
by nix (subscriber, #2304)
[Link] (6 responses)
Posted Nov 2, 2014 21:08 UTC (Sun)
by johannbg (guest, #65743)
[Link] (5 responses)
"That's going to be changed soon, it'll be possible to configure per-service symlinks for the /dev/log."
is not happening upstream so if you are going to implement this you will have to implement this as somekind of downstream hack
Posted Nov 3, 2014 1:22 UTC (Mon)
by dlang (guest, #313)
[Link] (4 responses)
Posted Nov 3, 2014 1:45 UTC (Mon)
by rahulsundaram (subscriber, #21946)
[Link]
Posted Nov 3, 2014 1:49 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Nov 3, 2014 19:19 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
> In recent versions of systemd you can just override Symlinks= in
Posted Nov 3, 2014 23:07 UTC (Mon)
by johannbg (guest, #65743)
[Link]
And you probably can simply achieve the same breakage ( although untested ) by fiddling with existing ListenDatagram= entries in journal/syslog.socket for example something like removing ListenDatagram=/dev/log in systemd-journald.socket and add it to syslog.socket instead.
Posted Oct 22, 2014 19:51 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (1 responses)
> The old UNIX way with one big server, one graybeard lording his power over tons of small users is dead for good. And it turns out that the old UNIX way of doing things doesn't really cut it with the current reality.
What gets me is all the people moaning "the new way isn't Unix" don't seem to get that the old way isn't Unix either! BSD networking doesn't believe in "everything is a file", SysVInit is a monolithic monster that does NOT do the one thing it is supposed to very well at all, etc etc.
I'm sure people can come up with plenty more examples - KDE and Gnome are massively "Un Unix", and equally as massively popular ...
Cheers,
Posted Oct 22, 2014 20:15 UTC (Wed)
by jb.1234abcd (guest, #95827)
[Link]
It surprizes me what you said, at least about KDE.
http://api.kde.org/frameworks-api/frameworks5-apidocs/
https://techbase.kde.org/Development/Tutorials/Using_KParts
jb
Posted Nov 2, 2014 15:13 UTC (Sun)
by nix (subscriber, #2304)
[Link] (1 responses)
> The old UNIX way with one big server, one graybeard lording his power over tons of small users is dead for good. And it turns out that the old UNIX way of doing things doesn't really cut it with the current reality.
There's not much of an actual argument in that non sequitur. Interchangeable components and 'one greybeard lording his power over tons of small users' are not related: indeed, most modern Unix systems, whether using systemd or not, are single-user or even less-than-one user.
Moving to a single-user system does not seem to me to necessarily require the introduction of tight coupling at this level: your assertion that it not only does but that they are *identical problems* such that arguing against the one naturally implies that you're arguing against the other is extremely bad reasoning.
Posted Nov 2, 2014 16:15 UTC (Sun)
by raven667 (subscriber, #5198)
[Link]
Posted Oct 22, 2014 17:53 UTC (Wed)
by jspaleta (subscriber, #50639)
[Link] (4 responses)
PID 1 doing too much:
logind dep.
The explicit use of the logind APIs and the implicit use of other symtemd APIs in the background really isn't much different for me than the historic transitions around devfs and hal and udev. If anything this is just the next step on the same journey to implement the goals of project utopia for making pretty much everything hotpluggable. I'm really not surprised logind was adopted so quickly, it solves real problems. The dynamic hotpluggable multi-seat stuff that logind supports is really interesting.
-jef
Posted Oct 22, 2014 23:28 UTC (Wed)
by dlang (guest, #313)
[Link] (3 responses)
we've been through this before, this is nowhere near enough to get journald out of the way for high performance logging.
Posted Oct 22, 2014 23:31 UTC (Wed)
by jspaleta (subscriber, #50639)
[Link] (2 responses)
-jef
Posted Oct 22, 2014 23:36 UTC (Wed)
by dlang (guest, #313)
[Link] (1 responses)
Believe it or not, people are able to think ahead and realize that if other people's concerns are treated that way, when something happens that they care about, they can't expect any better treatment.
Posted Oct 23, 2014 0:07 UTC (Thu)
by jspaleta (subscriber, #50639)
[Link]
I'm trying to remember. When you brought this up originally here at LWN you said you were asked to keep quiet about it. I obviously can't dispute that.
But it's hard to judge for myself if the handling the high performance logging issue was inappropriately if the entire conversation concerning the tradeoff is happening outside of normal archived discussion channels.
So outside of discussion here in lwn... is there archived discussion on the matter that you can point to now? If you provided a reference previously and I've forgotten it, I apologize for asking you to re-reference. I just can't find it in the previous lwn discussion. All i'm getting is your description of the problem, and 3rd hand commentary on how you think its going to be resolved by other parties using liblogging or some such.
-jef
Posted Oct 22, 2014 18:32 UTC (Wed)
by jb.1234abcd (guest, #95827)
[Link]
This has been already decided :-)
https://news.ycombinator.com/item?id=8251898
jb
Posted Oct 24, 2014 5:03 UTC (Fri)
by csirac2 (guest, #99520)
[Link] (14 responses)
I dare you to get an OMAP3 board running anything newer than 3.6 without crashy mmc support. I just got a quote from the world's largest most reputable embedded COM module vendor who are shipping Freescale i.MX6 which supports... Linux 3.0.16. And if it wasn't for the Linaro ecosystem I'm sure it'd be even worse than that.
Check out http://www.gumstix.org/access-source-code.html - how many of these boards will be able to run the "Universal Operating System"?
I've been maintaining a systemd version of my work and it mostly works on the ARM target I need to support, but the obscure out-of-tree kernel modules need to be ported and re-validated. Which I just can't do in-house here. So I'm hoping like hell sysvinit systems will at least remain partially compatible until I have time to deal with this properly.
Posted Oct 24, 2014 7:14 UTC (Fri)
by johannbg (guest, #65743)
[Link] (13 responses)
systemd v216 needs the XOR filter.
BPF_XOR was introduced in kernel 3.7 ( hence the bump on the dep )
If you want it backport the goddam BPF XOR filter to 3.4 or whatever like the rest of the ( embedded ) world has been doing geez...
filter: add XOR operation
x86 bpf_jit: support BPF_S_ANC_ALU_XOR_X instruction
filter: add XOR instruction for use with X/K
x86: bpf_jit_comp: add XOR instruction for BPF JIT
Posted Oct 24, 2014 8:02 UTC (Fri)
by csirac2 (guest, #99520)
[Link] (12 responses)
In my own case, I have to support a fleet of devices sold with *current* product lines from vendors who think kernel 3.0 is still an acceptable thing to tie all their customers to for another 5 years. That's including a dual-core 1GHz Freescale I.MX6, Cortex A9 upgrade option which to my dismay, is also still on kernel 3.0.
I have experimented with Linaro kernels for these CPUs but porting over the platform drivers is a non-trivial task (custom peripheral bus, magic numbers, strange undocumented timing quirks), and then I'd have to pitch a business case to go through re-validation all over again.
Perhaps it really is asking too much of Debian package maintainers to retain sysvinit scripts in packaging for Jessie, but dismissing this concern as "helpless n00bs don't want to do the slightest bit of work" and that I should just back-port cgroups and BPF_XOR isn't exactly the pinnacle of enlightenment either.
Posted Oct 24, 2014 8:46 UTC (Fri)
by johannbg (guest, #65743)
[Link]
That is an industry/vendor problem that has chosen to go down the path of added burden of continues back porting which you unfortunately have to maintain from the looks of it. I guess pushing back harder that it is the wrong thing to do or rather the *costly* thing to do, which perhaps those that make those decision would understand better.
"Perhaps it really is asking too much of Debian package maintainers to retain sysvinit scripts in packaging for Jessie"
It requires package split, an sub package that contains the relevant init script for the init system being supported, ( one for unit file, one for sysv script and one for upstart for example ) and last time I checked none of the embedded devices are running "stock" distributions on their devices but heavily customized systems, which in turn they could just as well carry/maintain this stuff themselves could they not?
Bottom line asking of or expecting others to do the work for you, is the fallacy in open source project in general as Thomas Gleixner touched upon in the "future of the realtime patch set". There seems to be whole lot of consumers be it users or industries that expect they get the whole pie without having to pay for it ( in this case in the form of contributing back to the relevant project(s) they are depended upon )
Posted Oct 24, 2014 9:53 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (8 responses)
For the record, any claims that Debian package maintainers are falling over themselves to get rid of sysvinit scripts for jessie are wildly exaggerated. Removing existing (and working) sysvinit support from packages is not Debian policy so far, or even a good idea. We would of course like Debian maintainers to add systemd unit files to packages, but since systemd can deal with sysvinit's init files there is no particular hurry, and there is no problem whatsoever if a package contains both systemd and sysvinit support.
Posted Oct 24, 2014 11:29 UTC (Fri)
by johannbg (guest, #65743)
[Link] (7 responses)
The backwards compatibility to legacy sys V format is not 100% so technically yes there is ( since those init scripts are to put it mildly vary in quality and LSB compliance ) and then there are the problems from a practical, usable standpoint so indeed there are dragons if you chose that path. ( Remember Debian is not the first distribution to be migrated we have gone through the same discussion, the same dance in each community that was deciding to make the switch, Fedora,Mageia,OpenSuse, Arch etc all of them )
If you ship both the administrator/end user is under the assumption he can use either the legacy sysv initscript or the systemd native service unit ( since both of them are now installed ) which they will quickly and painfully realize they cannot ( followed by usual complains,bug reports to the relevant maintainer(s) and mailinglists ).
Systemd units take precedence over legacy sysv initscripts which results in the administrator or the end user, who thinks units are junk and the shell scripts are the holy grail of all things as written in the illusion of existence of some kind of unix bible, is to "delete" the service unit and their problems are all solved. ( As I have observed )
Ding Ding Ding wrong answer, on next package update for the component that unit file "re-appears" and takes precedence ( again ) over the existing legacy sysv initscript, effectively rendering it's usage and potential customization it carry's with it useless.
So if the intent is to support more then one init system you have split the initscript, relevant to each init system into it's own component and have that sub-package installed based on what init system is installed on the system.
The alternative is just to ship ( and fix the legacy initscript to be compliance with LSB ) but if you do that you effectively render the work and benefits of switching the init system in the first place useless as can be seen previously with all the distribution that switched to upstart, since with the exception of ChromeOS no distro ever attempted to integrate upstart with the distribution to any extent.
If they had switched to native upstart format it would have caused just as much "disruption as systemd currently is doing.
Now the question that's on everybody's mind and depends on the outcome of the GR' who's going to do all that work necessary to support multiple init system if/when it comes down to it in the distribution.
Posted Oct 24, 2014 12:23 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (6 responses)
I don't buy this. LSB compliance for init scripts has been standard in Debian for a very long time. Lintian has included checks for LSB compliance since 2006. My system has 98 init scripts and not a single one of them does
not have an LSB metadata header. I don't think non-LSB init scripts are
actually a real issue on Debian.
Debian packages for jessie that provide background services should ideally contain both an LSB-compatible sysvinit init script and a systemd service unit file (which may enable systemd-specific bells and whistles that are difficult to support with sysvinit). If systemd finds the service unit file it disregards the init script. Sysvinit of course disregards the systemd unit file completely. Nothing about this is rocket science. There is no need to provide separate packages depending on the init system in use. Add upstart/… configuration files to taste.
If this doesn't work on a systemd-based jessie system you file a bug against the package. If this doesn't work on a sysvinit-based jessie system you file a bug against the package. Where's the problem?
Of course – but that is neither here nor there.
As far as I'm concerned, packages must support the default init system (systemd). If packages have working support for sysvinit, as pre-jessie packages will, it makes little sense to remove it (at least for jessie, but probably also going forward). People who want packages to support other non-default init systems – or sysvinit, for packages newly added to Debian after jessie's release whose upstream versions only support systemd – are free to volunteer their efforts if package maintainers won't do it by themselves, and package maintainers should include appropriate patches from third parties if possible. This is how things generally get done in FLOSS, and I'd presume that most package maintainers would have pursued this course in any case, even without a GR. Personally I'd be surprised if the GR will say anything substantially different but who knows.
Posted Oct 24, 2014 13:26 UTC (Fri)
by johannbg (guest, #65743)
[Link] (5 responses)
My experience tells a different story by overseeing and handling the process of integration as well as doing the most of the migration/integration of systemd into Fedora. I too was under the assumption that those maintainers actually knew what they where doing and adhered to standards but oh boy oh boy was I wrong and as I was crawling through those up to 1000 components in total. looking at and migrating them I came across one fuckup after another ( including pourly written initscripts up 900 lines long ) ranging from packaging mistakes and or simply outdated spec files ( or full of if fucking this RH platform then do this or if this fucking RH release do this ), to broken initscript, useless cron jobs, incorrect dependency's ( or no dependency's ), half migrated features to literally no maintainers existing maintaining that component at all ( as long as it builds it shipped hurray for wasting service support community time and potentially exposing users to security risks ) and remember these are just the components on core/baseOS and or contained services daemons and on top of that I had to deal with the incompetence of FESCo ( with the exception of Miloslav Trmač ) and the FPC.
And I can tell you despite what Red Hatters might claim and state that Fedora has migrated to systemd after doing precisely that for what 5 years or since the initial push in F14. the integration/migration to Fedora is ca 80% done roughly 1000 man hour I had calculated myself to finish that to be on par what I considered acceptable for our end user base and as a project ( apparently I held things at much higher standards then most people in Fdora ) stuff that when I left the project due to certain Red Hatters and them demolishing what the project had stood for all these years.
I can also tell those Red Hat conspiracy theorist that Red Hat is to busy misusing contributors and their time in Fedora for their own benefit and that it as an company is as organized as bunch of cats ( and I ain't talking about Lions ) that they dont have neither the intelligence nor the time to cook up any kind of world conspiracy plot and I know for a fact that certain individuals from the self dubbed systemd cabal would walk away from the company if it ever tried to influence the systemd project and it's community.
My message to anyone that thinks about contribute to Fedora, dont for the life of it contribute to it or any other distribution or basically anything that Red Hat associates itself with as an "Community sponsor". What it as an corporate sees as "community sponsorship" is equivalent of corporate oppression in rest of the world
Posted Oct 24, 2014 13:58 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (4 responses)
Great. So what does that tell us about Debian?
Posted Oct 24, 2014 14:42 UTC (Fri)
by johannbg (guest, #65743)
[Link] (3 responses)
How much and for how long that transitioning pain depends on themselves but they should in all be able to catch quickly to same point the other distribution are due to the collaboration effort of existing distribution that have *already* handled the migration for at least the half of what the initscripts Debian ships and they should be able to easily achieve that if they work *together* before Jessie gets released.
Unfortunately they seem to be choosing the route of most resistance with all these GR's and thus the route of most distraction and most transaction pain ( and length of that pain ) in the process ( and arguably also the route of the harder maintainership during the life cycle of Jessie ).
Based on my experience and if it was up to me and I was doing this all over again from scratch and at this point in time ( the current work that distributions have done would have already be done which was not the case when I was working on this ) then I would delay Jessie until it had caught up with the point other distributions are now at with systemd, release and then gradually migrate the rest in unstable ( and hopefully manage to have that covered for next Debian release ) but it's not up to me so meh...
Posted Oct 24, 2014 15:18 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (2 responses)
”They” is perhaps a dozen people or so. In addition, the GR is not about jessie at all, and shouldn't impact the jessie release in any way other than by distracting attention from the upcoming freeze (which is annoying but probably not really a problem). I don't think the discussion has anything useful to add at this point, so most Debian developers will probably lose ten minutes or so in order to fill in a ballot when the vote comes around. Anything more is really luxury.
This is probably what will happen in the end. The GR doesn't really matter as far as jessie is concerned, and I don't think we're in that bad a shape to begin with – most of the packages in question have reasonable sysvinit scripts that we will be able to use with systemd in jessie even if they don't have native systemd unit files. Various bugs have been identified and fixed recently, we'll probably shake out some more bugs during the freeze, and we'll have a couple of years after jessie is released to do the rest of the conversion. The end of the world is not nigh.
Posted Oct 24, 2014 15:49 UTC (Fri)
by johannbg (guest, #65743)
[Link] (1 responses)
Distractions for individuals working in the IT sector not only delay task completion and increase the number of bugs ( encase you are a developer ), but can also lead to increased stress and frustration levels, which can then lead to even more delays and in some cases, burnout for contributors.
And what you are basically saying if that is the case is that this stunt by Ian and his seconders was deliberately made to distract the community from it's work since it wont have any effect on Jessie hence could have waited until Jessie would have been released.
Something I personally would not take lightly and would immediately propose or insist that at some point in the development cycle GR's would be put on Freeze until after release to prevent misuse of the process and distracting people from doing their work.
"most of the packages in question have reasonable sysvinit scripts that we will be able to use with systemd in jessie even if they don't have native systemd unit files"
As I mentioned elsewhere dont hesitate to be in contact upstream if you need help with that migration since these kind of migration/integration work in distributions with systemd is beneficial to *all* so it does not take many resources from systemd community from every distro to lend a hand and help with that migration. ( It's better to get a crew already familiar with this rather then expecting each maintainer being able to put themselves into inner workings of systemd, they can always do so *after* the component shipped native systemd units ) It just requires a bit of organizing and packagers ( in all distros ) to be on stand by when that happens and it will be quickly over and integrated for *everybody* involved.
Posted Oct 24, 2014 17:27 UTC (Fri)
by anselm (subscriber, #2796)
[Link]
If you look at the debian-vote mailing list it seems that 95% or more of Debian developers aren't bothered by the GR. At least it doesn't seem to distract them to a point where they feel the need to add to the discussion. The whole thing really seems to be a tempest in a teacup. We'll see how the vote comes out when it comes out.
Posted Oct 24, 2014 10:01 UTC (Fri)
by tao (subscriber, #17563)
[Link] (1 responses)
While the "helpless n00bs" thing is uncalled for (though I must say that a lot of the systemd opponents use arguments amount to "I've learned to do things this way, I don't want to try to adapt to systemd"), your scenario when you already run a non-Debian kernel is hardly a scenario that Debian should be expected to take into consideration. With over 30000 packages there's enough work as it is to keep things working with *is* part of Debian...
Besides, for Jessie sysvinit scripts *WILL* be retained, so I don't really see much cause to worry about that. The GR, mistimed though it is, would only affect Jessie + 1 (where I *personally* think that dropping sysvinit scripts would be the sane thing to do; no one required upstart support while sysvinit was the default; requiring sysvinit scripts with systemd as default seems similarly stupid). For your particular product I'm bravely gonna assume that you won't be supporting an upgrade to Jessie+1 while still running a 3.0 kernel...
Posted Oct 24, 2014 14:00 UTC (Fri)
by dlang (guest, #313)
[Link]
And you really don't want to have to fight backporting software, especially if the newer versions start depending on systemd, which is going to be very hard to backport.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
systemd-shim has caused breakage on my testing systems, so I think it doesn't work that well. I guess I could just embrace systemd, but that has caused breakage too. What am I missing?
The Debian init system general resolution returns
The Debian init system general resolution returns
It's free software: be happy to benefit from the work of others, but this means at times that things won't go the way you want. When this happen the proper attitude IMHO is to:
And I don't think anyone owe me anything just because I grace their software with my use (tongue firmly in cheek ;).
But that's not how Debian works, or at least how it's worked for me for the past few years. The first principle that I have observed is to not break running systems, even if they run testing. The second is to give choices, and the third to migrate smoothly between versions. And sadly, disruptions in testing are the herald of larger disruptions in upgrades.
The Debian init system general resolution returns
The Debian init system general resolution returns
There are some important differences between btrfs and systemd.
The Debian init system general resolution returns
The Debian init system general resolution returns
systemd doesn't eat data in and of itself, but it does get irretrievably stuck, kill innocent processes, and even panic the kernel when it fails.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
It's not really worth bothering with any IPC, let alone the one of push instead of pull variety.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
I suspect that parent could be kept simple enough that the chance of misbehaviour was as low as for a traditional init.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
https://lwn.net/Articles/401856/
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
I don't see how Debian can tolerate this behaviour and still hope to retain the ability, credibility, and respect to be able to do what it's always done.
The Debian init system general resolution returns
Irrationality at it's best
Irrationality at it's best
Irrationality at it's best
Irrationality at it's best
Irrationality at it's best
Irrationality at it's best
What's more, there is no friggin' point to all of this. You can't compel others to do work they don't want to do, so why proscribe that? File a bunch of RC bugs, justified by this GR, which nobody's going to fix and which will hold up jessie(+1?) indefinitely??
NB: at *its* best. :-P
Irrationality at its best
Irrationality at it's best
Irrationality at it's best
Irrationality at it's best
Irrationality at it's best
Irrationality at it's best
Irrationality at it's best
Irrationality at it's best
Irrationality at it's best
Irrationality at it's best
Irrationality at it's best
Irrationality at it's best
Irrationality at it's best
Irrationality at it's best
Irrationality at it's best
Irrationality at it's best
Irrationality at it's best
Irrationality at it's best
Irrationality at it's best
"If things were as bad as the detractors say it would have been obvious for a long time and they wouldn't be talking about 'potential' problems, there would be a long line of angry pitchfork wielding sysadmins."
Irrationality at it's best
Irrationality at it's best
Irrationality at it's best
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
And just like sausage, it is in your best interests to know what it's made of.
The Debian init system general resolution returns
The Debian init system general resolution returns
In food, as in operating systems and everything else, there is no "simply safe, tasty and appropriately balanced". You can either delegate the task of verifying if it's good for you to someone else, which does not usually go well; or verify it yourself, whenever possible.
Sorry for stretching the analogy a bit more
Sorry for stretching the analogy a bit more
Yes, and I've lost trust in it.
Sorry for stretching the analogy a bit more
Sorry for stretching the analogy a bit more
Sorry for stretching the analogy a bit more
The Debian init system general resolution returns
( There seems to be some frantic motivation migrate every cron job to timer units which is just silly and adds dependency on systemd where there should be none )
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
Bike shedding. A GR about something people can easily have an opinion on, but implications of the GR: for someone else to sort out. Resulting work: for someone else to do.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
It clearly wasn't in good faith. Mr Jackson realised that the vote about init systems wouldn't go the way he'd like it to, which is why he tried to conflate two completely unrelated point into a single poll. If that's not a blatantly obvious abuse of the procedure I don't know what is.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
accidentally locked in to a particular init system (for example,
because so much unrelated software has ended up depending on a
particular init system that the burden of effort required to change
init system becomes too great)".
original voting result, and save themselves as an OS / Linux distro.
jb
The Debian init system general resolution returns
Voting period TBC
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
( Which is a noble goal on paper )
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
As for other kernels... well, debian-kfreebsd and debian-hurd are nice experiments, but they're not release architectures due to persistent lack of both functionality and manpower, so why bother right now, before maintainers of other kernels improve them to provide more functionality ?
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
* Very large package repository, large community.
* Didn't have a corporate agenda, not for profit - one less thing to worry about.
* Quite consistent (and usually sane, up to now) file system policy, as far as configuration files and related stuff is concerned.
* Good security support.
* Not a moving target, in terms of software releases (maybe not that great on the desktop, but quite good for server environments)
* Reasonably sane config. defaults out of the box for many, if not most, software, contrary to RH and derived distros.
* Not dumbed down and/or targeted for desktops only -- can get very lean and small server environments/VM images, without too much bloat.
* Last, but not the least, even though it provides a consistent policy, it still leaves plenty of CHOICE for end users.
KTHXBYE
The Debian init system general resolution returns
The Debian init system general resolution returns
Look, people have surely seen plenty of times what happens when these big, megalomaniac software projects come along. They come with the promise to solve every problem and do everything there is to do and make you an expresso on top. They also come with arrogant, egomaniacal self-righteous developers that don't seam to have the nerve to justify their technical choices, but instead prefer to play the victim and throw tantrums on blog posts.
And we all have seen how most of those projects end in a fiasco, the real victims being the gullible end users who bought into them.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The sensible option would be to, at least, give users the *choice* of init system.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
1) It's time to stop this madness.
2) It's time to stop the Microsoftization of Linux by RedHat.
3) It's time to return to the wisdom of the ancient Unix masters.
4) If we don't support FreeBSD, NetBSD and IRIX then the world is going to fall apart.
The Debian init system general resolution returns
And that's fine! You can keep eating your mystery sausage with eyes closed for as long as you want. That's your prerogative.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
One can certainly consider improving upon sysvinit, but a rat's nest of processes and D-Bus interfaces is not an improvement.
A good modular design would have been technically acceptable to everybody
Systemd is about seizing control of Linux.
And the extraordinarily serious downside of systemd's awful design is that the lack of modularity makes it hard to improve Linux in future.
possible motivation for not supporting forced-support of multiple init options
possible motivation for not supporting forced-support of multiple init options
possible motivation for not supporting forced-support of multiple init options
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
You expect free updates, support, bug fixes etc. from the community (how do I know? Because otherwise you'd just run sysvinit and stop whining, it's not like it suddenly disappeared). Systemd makes the lives of the people whom you expect to provide you with that much easier, and itdoes a superset of what sysvinit did and it does it better. Given that, yes, you very much need a reason to not install systemd. Because if you can't come up with one, people are likely to write you off as some kind of weird dork and not care about you. Which is pretty much what is happening right now.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
But implementation choices are distinct from design choices. And your beef really is with implementation choices. If there was a second implemention coded up that spoke the dbus service api that logind expected...without making any changes in the design of logind... then well..we'd be having a very different conversation.
The Debian init system general resolution returns
The Debian init system general resolution returns
A cursory inspection of the systemd-shim source tree indicates that systemd-shim is not a fork of systemd. It is an independent reimplementation of a subset of systemd's functionality, which imports a few source files from the systemd code base.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
What is wrong with that init script? It looks fairly sane to me. How does starting named using systemd fix it?
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
2) You want an init script to handle SELinux labeling and policy enforcement? Do I misunderstand you? If I don't, how, exactly, would that work?
3) SELinux integration is handled by the SELinux subproject of the Hardened Gentoo project. The package manager handles FS labeling, and the system administrator can either manually install policies, or tell the package manager to auto-install them. More info here: http://wiki.gentoo.org/wiki/SELinux
The Debian init system general resolution returns
How do you make systemd run named-checkconf before you restart BIND, and refuse to attempt the restart if named-checkconf finds an error?
The Debian init system general resolution returns
The Debian init system general resolution returns
No it isn't correct and it doesn't do all the systemd's work, even if we do not consider socket activation.
> ProtectSystem=full
> ProtectHome=true
> PrivateTmp=true
> CapabilityBoundingSet=CAP_SYS_NET_BIND
See this for the discussion of the problem: https://access.redhat.com/documentation/en-US/Red_Hat_Ent...
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
Guaranteeing that all of these are security bug free is non-trivial when compared to auditing a narrow dbus interface.
The Debian init system general resolution returns
If libdbus had a security flaw in that manner
'If' is the wrong word to use here. It's happened, repeatedly.
The problem is not modifying the shell scripts themselves, but that the attack surface comprises the shell script, the shell itself, and all the various other scripts, executables, etc. which get invoked in the script.
Guaranteeing that all of these are security bug free is non-trivial when compared to auditing a narrow dbus interface.
If GNU coreutils, iputils etc aren't safe to run as root, everyone is buggered in any case. Sysadmins routinely run these things as root, and systemd existing isn't going to make them stop.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
Lot of people seems to be fine with the tradeoff of marginally increasing the attack surface for the benefit it provides ( ie, dbus provides a API unlike initscripts that don't ). Since dbus is locally accessible, the attack surface is not as catastrophic as you seems to think, and since upstart was already dbus powered, we would have seen this attack surface exploited since a long time as ubuntu and rhel do use upstart )
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
All but one of our systems - that includes desktops, laptops, servers, and VPSs - have one or more inittab entries in addition to those supplied by the distro.
fb:2345:respawn:/usr/local/bin/foobar -baz
simply add a file /etc/systemd/system/foobar.service containing
[Unit]
Description=Foobar service (from inittab)
[Service]
ExecStart=/usr/local/bin/foobar -baz
Restart=always
[Install]
WantedBy=multi-user.target
At first glance this seems more wordy but it does allow all sorts of useful features that sysvinit doesn't offer (like, for example, rate limiting for respawns). In addition, the service can be started and stopped manually like all other systemd services where with sysvinit you would need to edit the /etc/inittab file, and it shows up in the usual service status listings.
The Debian init system general resolution returns
The Debian init system general resolution returns
sysvinit has provided respawn rate-limiting for as long as I can remember.
inittabs are updated by the configuration management system.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
Debian's "Essential: yes" package attribute does not mean what you think it does.
The problem comes now that RH deliberately breaks existing software so that it no longer works without systemd.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
https://wiki.debian.org/Suspend
The Debian init system general resolution returns
The Debian init system general resolution returns
ref: http://blogs.gnome.org/desrt/2014/02/19/on-portability/
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
Please don't mislead people. Ian said he was not aware of any RC bugs - not that there are none, or that there will be none.
The Debian init system general resolution returns
"This GR seeks to preserve the freedom of our users now to select an
init system of their choice, and the project's freedom to select a
different init system in the future. It will avoid Debian becoming
accidentally locked in to a particular init system (for example,
because so much unrelated software has ended up depending on a
particular init system that the burden of effort required to change
init system becomes too great). A number of init systems exist, and
it is clear that there is not yet broad consensus as to what the
best init system might look like."
The Debian init system general resolution returns
https://lists.debian.org/debian-vote/2014/10/msg00124.html
https://lists.debian.org/debian-vote/2014/10/msg00197.html
https://www.debian.org/vote/2014/vote_003
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
libvirt-*
hplip - HP Linux Printing and Imaging System
fprintd - D-Bus daemon for fingerprint reader access
colord - system service to manage device colour profiles
bluefish - advanced Gtk+ text editor for web and software development
steadyflow - Simple download manager for GNOME
sparkleshare - distributed collaboration and sharing tool
nemo - File manager and graphical shell for Cinnamon
nautilus - file manager and graphical shell for GNOME
caja - file manager for the MATE desktop
brasero - CD/DVD burning application for GNOME
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
> system and service manager - SysV links
>or systemd-shim (>= 8-2)
> shim for systemd
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
Ultimately the most serious bug in systemd is that it is being forced on us.
The Debian init system general resolution returns
And to give a example, the kernel policy didn't prevent android from emerging or grsec to innovate, despites them being out of the kernel.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
systemctl start getty@tty4.service
seems to work just fine to start the getty up. A see an agetty instance on tty4 now in the ps output.
systemctl restart getty@tty4.service
new agetty pid on tty4 on ps output.
systemctl stop getty@tty4.service
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
Red Hat makes no attempt to even support upgrading between major versions of RHEL.
That's no longer true. There is a supported upgrade path from RHEL 6 Server to RHEL 7 Server (only on x86_64 so far). See KBase articles:
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
It's about preventing maintainers from deliberately stonewalling others from doing the work to keep an alternative init system usable because they are of the opinion that systemd should be the only viable option for Debian.
The Debian init system general resolution returns
The Debian init system general resolution returns
This GR will (or will not) give me the reassurance that any work done on alternative init implementations (or maintenance of sysvinit) will not be blocked simply by systemd being the default.
The Debian init system general resolution returns
The Debian init system general resolution returns
Wol
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
This ecosystem functions according to different laws than a commercial
organization offering a product to a paying customer.
The reason for that is obvious - Open Source Software has a participatory
and contributory character. Those active in it, whether devs or all other
people assuming formal or informal roles of users, testers, ambassadors,
commentators, etc depend on each other organically.
Many of OSS projects, including kernel, would be non-starters or suffer
quality issues without often anonymous and free code contributions, advice, discussions, and PR-like activities at home, work place, and public at large.
I do not remember any software project, in this ecosystem or elsewhere,
that polarized the participants (see above) so much.
And for a good reason, as its aims as presented violated that ecosystem's
philosophy and rules of software development. It was an ambush style,
"my way or hiway" approach to introduction of a new software that impacted
everybody dependent on this ecosystem. As a result, it was met with
resistance and mistrust as to its intentions.
In the process of subsequent evaluation, the devs were even shown to lack
understanding of which domain's problems (real or perceived) they were trying to solve, which led them to a wrong model, which led them to some
antics in design and implementation.
My opinion is that systemd, if it had been properly evaluated in advance,
it would be structered and look different today, if not stopped altogether
at least until revised from top to bottom.
It is my opinion that the distros that hastily adopted systemd contributed
mightily to subsequent uproar in the ecosystem.
make some corrections), then the damage would be even bigger.
the damage to themselves, but also to the rest of us, and so it is
a positive step.
That's why it should find support among Debian devs, and beyond.
participants.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
https://plus.google.com/+KaySievers/posts/C3chC26khpq
The Debian init system general resolution returns
Yes, PID 1 has the advantage of adopting every orphan in the system, but the costs of a failure can be quite high. I think a more useful approach would be to work with the kernel people to perhaps solve the waiting and re-parenting problem, instead of just overloading PID 1 and hoping for the best, and that nobody else minds about being restarted by HW watchdog. It's not like the kernel isn't already getting code whose main user will be systemd anyway.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
Why the heck should the init system restart failed crashed processes?
The authors of sysvinit. (What else do you think /etc/inittab is for?)
Who restarts init if it crashes?
Nobody. If init crashes, the kernel panics. (It is quite hard for init to crash: it has a special dispensation to never receive signals for which it does not have a handler, including fatal signals.)
The Debian init system general resolution returns
Bull shit.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The argument is that moving them outside of PID1 would make things more complicated and it would have negative consequences for stability and security.
That's a design decision. Throwing acronyms around saying a design sucks because it doesn't conform to them doesn't prove anything.
A different design might look nicer on paper but until it's tested and proven in real-life situations it's not worth much.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
> Copyright 2001
> D. J. Bernstein
> http://cr.yp.to/daemontools.html
> 2007.12.28: I hereby place the daemontools package (in particular, daemontools-0.76.tar.gz, with MD5 checksum 1871af2453d6e464034968a0fbcb2bfc) into the public domain. The package is no longer copyrighted.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
1.2. We shall not make for us any other init system
1.3. We shall not take the name of the Lord our God in vain
1.4. Remember the systemd TC decision day, to keep it holy
1.5. Honour our GNU and our Linux
1.6. We shall not kill pid 1
1.7. We shall not install other init system
1.8. We shall not steal code from our init system
1.9. We shall not bear false witness against our init system
1.10.We shall not covet the init systems of other distributions
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
process monitoring: optional, configured on a per-service basis.
time service: strictly optional.
everything else: almost entirely optional.
http://community.redhat.com/software/
http://www.sourceware.org/projects.html
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
Porting systemd to uclibc or musl libc is trivial. It requires several small patches and implementation of several missing functions.
The Debian init system general resolution returns
The Debian init system general resolution returns
Perhaps they did, so what? The problem isn't necessarily that they're lying but that their judgement is likely to be biased by their employer who had a stake in the outcome of the vote. And let's face it, it clearly was: three out of four upstart supporters in the committee were at some point employed by Canonical while none of the systemd supporters were. There's *no way* something like this could happen by pure chance.
The Debian init system general resolution returns
The Debian init system general resolution returns
But that's no better!
The Debian init system general resolution returns
The Debian init system general resolution returns
But I believe that it was more a case of what they had experience with (they'd been using upstart a lot and thus saw the world through upstart-coloured glasses) rather than bias based on whom their current/previous employer is/was.
I see the GR as a last attempt to be inclusive before forcing a lot of users to skip the next Debian release (or at least put sysvinit on hold and not install anything with a systemd dependency). Until systemd can coexist with sysvinit on a running system, the transition can only happen through attrition, and that is a real problem for users who need to upgrade machines in place. While we're waiting for systemd to be fixed, we still need maintenance and low-risk upgrades. Currently that means sysvinit with patches over the more egregious bugs. There is no love for sysvinit here--sysvinit is installed and working now, so its privileged position is purely pragmatic.
The Debian init system general resolution returns
The Debian init system general resolution returns
right now.. without this GR it is possible to use systemd-shim with sysvinit or I think even minit and will allow anyone who does not want to move over to systemd as part of an upgrade to continue to use sysvinit as an alternative.
The Debian init system general resolution returns
The Debian init system general resolution returns
EXTINGUISH
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
In the Microsoft context "Embrace, Extend, Extinguish" refers to their treatment of Java, which was open source and controlled by another vendor.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
* Monopoly power used to require distribution. (Hint: RH is powerful, but SuSE, Mageia, Tizen, etc., aren't beholden to RH in the same way Sun was beholden to MS. Quite the opposite, really - they're plausible competitors.)
The Debian init system general resolution returns
* Monopoly(*) power used to require distribution.
I apologize to everyone else for feeding the troll.The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
[2]Maybe the GR itself is useful; I make no assertion here.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
More modern distros may offer systemd as an option but they don't limit themselves to that fossilizing plumbing.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
- My post was in direct reply of another post here that said "Lennart and his colleagues" by anselm
- His post was in direct reply of another post that quoted not Greg, but Lennart, saying:
The Debian init system general resolution returns
The Debian init system general resolution returns
I don't mind the existence of systemd, I just don't ever want to use it. That's what most people are annoyed with, systemd grabbing hold of everything unconditionally. And this won't go away just because you deny it, or talk around it. A lot of people just don't want binary logs, period, you can call them stupid as long as you like. A lot of people want a small init, period, you can call them stupid as long as you like.
The Debian init system general resolution returns
I don't mind the existence of systemd, I just don't ever want to use it.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
And please stop explaining all the bleeding obvious to me, I'm not as stupid as you may think. This totally arrogant nature of communication from most of the systemd camp is what is partly to blame for all the hatred you receive.
The Debian init system general resolution returns
The Debian init system general resolution returns
OK... (1) this kind of language is wholly inappropriate and is unwelcome here. Please desist. (2) nobody has yet asked Linus to merge kdbus, so of course he has not done it. Until somebody brings it to the mailing lists for review and asks for inclusion, it will not be included. Just like any other patch.
kdbus
kdbus
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
[Debian Social Contract]
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
- Red Hat
- Samsung
- Intel
- Canonical(?!)
The Debian init system general resolution returns
https://www.openhub.net/p/systemd/contributors?query=&...
... you're wrong.
The Debian init system general resolution returns
The Debian init system general resolution returns
- OpenHub user name "keszybz"
- real name Zbigniew Jdrzejewski-Szmek
- commits: 577 (last 12 month), 1337 (all time)
- http://cgit.freedesktop.org/systemd/systemd/log/?qt=autho...
- Fedora home page: http://fedoraproject.org/wiki/User:Zbyszek
"I work in a computational neuroscience lab (CENlab) at the George Mason University in Fairfax, VA (nearby Washignton, D.C.)."
- Thomas Hindoe Paaboel Andersen
- commits: 192 (last 12 month), 237 (all time)
- http://cgit.freedesktop.org/systemd/systemd/log/?qt=autho...
- is also active in Gnome, no clear employer
- connecting a few sources (LinkedIn, Facebook, OpenHub) it seems that he's a student at Aalborg University Copenhagen.
- OpenHub user name "David Herrmann"
- real name: David Herrmann
- commits: 180 (last 12 month), 205 (all time)
- http://cgit.freedesktop.org/systemd/systemd/log/?qt=autho...
- home page: http://dvdhrm.wordpress.com/about-me/
"I am studying Computer Science and Mathematics and in my spare time I like coding C, working on the Linux kernel or writing firmwares."
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
Understanding this point is key to understanding one of the main arguments against systemd. Systemd due to its vertical integration at all levels of the Linux stack will create a Linux monoculture as the various distros will run the same software at all levels.
Case to invalidate that claim, take a look at artist painters works from different cultures using the same tool to produce different results.
The Debian init system general resolution returns
They need this GR now and in the future.
strategy.
You make yourself permanently dependent on present or future actions of
systemd devs - this may not be healthy to independently-thinking Debian or any other distro.
And the typical answer to it ? "I just hope it will not be forced to everyone through #systemd".
Would you be confident if *your* business had to follow these "visioneries" ?
just that, temporary and useless in the long run.
This is a fool's game.
a matter of distro's policy. Bingo. Everybody (devs and users) know what
the rules are, now and in the future.
It also gives you flexibility to react if needed (like some "visionaries"
hijacking a sys init system and much more and creating havoc in the Linux/UNIX ecosystem).
http://debianfork.org/
...
What should have been done (*):
...
I would hope that some other distros that hastily committed to systemd lockup will follow and reconsider their misguided decisions.
https://aur.archlinux.org/packages/?O=0&C=0&SeB=n...
disguise !
Return to UNIX philosophy and proven model of software development - it will save you in times of doubt, wickedness and tribulation !
tranquillity, a state everybody wants, of course ... :-)
The Debian init system general resolution returns
> risky strategy.
> You make yourself permanently dependent on present or future actions of
> systemd devs - this may not be healthy to independently-thinking Debian or any other distro.
This applies just as much to the long list of software projects that Debian packages and relies on.
Distros have better things to do than endlessly reinvent the wheel for the sake of a feeling of control.
An init system is not somehow sacred in needing every distro to cobble together their own (slightly incompatible) ones.
This is true for just about every other upstream as well.
As opposed to the "visionaries" of all the other software projects which Debian imports wholesale?
> Systemd as known today is a time bomb, a precursor to Windows Linux in
> disguise !
> Return to UNIX philosophy and proven model of software development - it will save you in times of doubt, wickedness and tribulation !
I am inclined to suspect that there may be some small element of hyperbole inherent in these statements.
Frankly the whole thing is a storm in a teacup, and I see no reason to panic and proclaim that the world is about to end.
The Debian init system general resolution returns
>> risky strategy.
>> You make yourself permanently dependent on present or future actions of
>> systemd devs - this may not be healthy to independently-thinking Debian
>> or any other distro.
> This applies just as much to the long list of software projects that
> Debian packages and relies on.
It is about systemd, a sys init plus much more (a wolf in sheep's clothing).
http://lwn.net/Articles/609809/
and this list is not complete - it is already longer than that by now.
So that when you wake up one day and discover that systemd-and-your-OS-distro train left without you, you have a fallback option ready, in production state. It is that simple.
The Debian init system general resolution returns
The Debian init system general resolution returns
systemd is a collection of components with well defined interfaces, it seems a bit odd to lambast it for not being modular.
If you don't want to use networkd or whatever then don't, conversely if you want to make or fork your own implementation of a particular interface then you can do that.
Many of the systemd blob's interfaces are volatile and/or undocumented and thus inhibit future incremental improvement of Linux.
The Debian init system general resolution returns
"Note that this is a promise, not an eternal guarantee. These are our intentions, but if in the future there are very good reasons to change or get rid of an interface we have listed above as stable, then we might take the liberty to do so, despite this promise."
The Debian init system general resolution returns
The Debian init system general resolution returns
Being dependent on one kernel (face it, neither Debian KFreeBSD nor Debian Hurd are relevant) that you do NOT control is a risky strategy.
Being dependent on one X-server that you do NOT control is a risky strategy.
Being dependent on one compiler (the situation for many, many years before we got llvm too) that you do NOT control is a risky strategy.
When XFree86 went haywire, someone forked off Xorg.
When gcc went haywire, someone forked off egcs.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
That's going to be changed soon, it'll be possible to configure per-service symlinks for the /dev/log.
That's not a technical argument.
The old UNIX way with one big server, one graybeard lording his power over tons of small users is dead for good. And it turns out that the old UNIX way of doing things doesn't really cut it with the current reality.
The Debian init system general resolution returns
The Debian init system general resolution returns
I'm running software on large clusters for a living. All of it works on Linux (we used to support BSD and Solaris but nobody wants them). We really try to make sure that our infrastructure is _reliable_ against all possible failure modes and it turns out to be impossible with the classic Unix model.
Just ask anyone who worked in the old university labs.
The Debian init system general resolution returns
The Debian init system general resolution returns
Also, service readiness protocol is a nice-to-have feature. Journald to collect stdout/err of services is greatly appreciated. Other than that, resource management and process tracking with cgroups is systemd's masterstroke (we're using it even without systemd).
What should I be worried about?
The major difference between modern sysadmins and the old-school big-iron UNIX adminstrators is the number of servers they manage.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
http://lists.freedesktop.org/archives/systemd-devel/2014-...
> systemd-journald-dev-log.socket and set it to the empty array, and
> then add Symlinks=/dev/log in syslog.socket instead, which should
> change /dev/log from being directed to the journal, to beign directed
> directly to your syslog instance. But note again, that will lose much
> of the early-boot loggind that way. Also "systemctl status" of course
> won't show you any logs anymore (or at least incomplete ones).
The Debian init system general resolution returns
The Debian init system general resolution returns
Wol
The Debian init system general resolution returns
Is it a monolithic monster ?
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
man journald.conf read up on the configurable Storage="none" option
I still contend that people are confused as to what PID 1 is actually doing and what the modular systemd utilities that run as separate processes are doing. Which makes it difficult to talk in the abstract about this. Every time I reach into the discussion for a particular issues its not actually PID 1, its a helper utility in the systemd codebase.
Meh. There is a long history here with higher level applications reaching for new APIs for new plumbing as the available plumbing gets better. GNOME has in the past previously picked up a dep on hal and then required udev in GNOME replacing hal. And nobody in Debian seems to have ever suggested at any point that making it possible to keep hal and udev working as interchangeable plumbing would be a good use of project resources.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
> systemd in the future, as soon as all major distributions have switched.
systemd needs linux > 3.7, which excludes most ARM embedded hardware
systemd needs linux > 3.7, which excludes most ARM embedded hardware
How helpless you people ( that comment here ) seem to be when it comes to do even the slightest work...
(ffe06c17afbbbd4d73cdc339419be232847d667a)
(4bfaddf15bac7afa7048d105864dab65c5d1f9e7)
(9e49e88958feb41ec701fa34b44723dabadbc28c)
(82c93fcc2e1737fede2752520f1bf8f4de6304d8)
systemd needs linux > 3.7, which excludes most ARM embedded hardware
systemd needs linux > 3.7, which excludes most ARM embedded hardware
systemd needs linux > 3.7, which excludes most ARM embedded hardware
Perhaps it really is asking too much of Debian package maintainers to retain sysvinit scripts in packaging for Jessie
systemd needs linux > 3.7, which excludes most ARM embedded hardware
systemd needs linux > 3.7, which excludes most ARM embedded hardware
So if the intent is to support more then one init system you have split the initscript, relevant to each init system into it's own component and have that sub-package installed based on what init system is installed on the system.
If they had switched to native upstart format it would have caused just as much "disruption as systemd currently is doing.
Now the question that's on everybody's mind and depends on the outcome of the GR' who's going to do all that work necessary to support multiple init system if/when it comes down to it in the distribution.
systemd needs linux > 3.7, which excludes most ARM embedded hardware
systemd needs linux > 3.7, which excludes most ARM embedded hardware
systemd needs linux > 3.7, which excludes most ARM embedded hardware
systemd needs linux > 3.7, which excludes most ARM embedded hardware
Unfortunately they seem to be choosing the route of most resistance with all these GR's and thus the route of most distraction and most transaction pain
then I would delay Jessie until it had caught up with the point other distributions are now at with systemd, release and then gradually migrate the rest in unstable
systemd needs linux > 3.7, which excludes most ARM embedded hardware
systemd needs linux > 3.7, which excludes most ARM embedded hardware
Something I personally would not take lightly and would immediately propose or insist that at some point in the development cycle GR's would be put on Freeze until after release to prevent misuse of the process and distracting people from doing their work.
systemd needs linux > 3.7, which excludes most ARM embedded hardware
systemd needs linux > 3.7, which excludes most ARM embedded hardware
