On Thursday, 29 September 2016 11:11:22 PM AEST Rick Moen via luv-main wrote:
(I note with appreciation your having addressed this very point in your blog post: 'The sensible option would be to just maintain a separate repository of modified packages as has been done many times before.' I entirely agree.)
It's something that I have a lot of practice doing myself, for many years before systemd was invented.
You'll note that I carefully document on my page what _cannot_ be easily achieved with my approach, at least without supplementing Debian 8 using third-party package repos. The main thing is, of course, GNOME as a whole (but the lion's share of GNOME apps are within easy reach).
More complex things have been done in Debian before. Getting the full GNOME functionality without systemd might not be possible, but getting the functionality that most people want (IE what has been commonly available before systemd) shouldn't be difficult. Unless of course they alienate most of the people who are capable of doing the coding in question.
I am happy for people to document how to not use systemd and I don't flame anyone for doing so. Why do they flame me and others for describing how to use systemd?
Because the existence of 7.2 billion homo saps guarantees a significant number of very odd people on the Internet? And because of John Gabriel's 'Greater Internet F***wad Theory'? ;-> (Warning: crude language, but in context not gratuitous) https://photos.smugmug.com/photos/i-mHzvgPv/2/O/i-mHzvgPv.jpg
Why systemd out of all the things that I have blogged about? You know that there is no shortage of people who disapprove of things that the NSA has done. But the hostility I've received over the course of 15+ years doing SE Linux development is less than what I received in response to a single blog post about systemd! The only topics I've blogged about which have received any significant amount of abuse are Autism, the treatment of women, and systemd. Why is systemd the sole technical issue which has resulted in so much abuse? Why are 2 of the 3 topics which get abuse targetted by the same people?
I think you're (probably) missing the point.
Your blog post flogs the point that some bunch of unidentified (except for one notorious example) bunch of people expressing anti-systemd views
Actually others have been identified. But some of the discussion in question has been on private mailing lists.
There are more than a few DDs who have nothing to do with SysVInit because of the people who they have to deal with if they choose to do so. Why go to the effort of supporting software if there is a better alternative that has the added benefit of avoiding assholes?
_Again_ with the comparison to _just_ SysVInit, as if OpenRC, Runit, and Upstart weren't also maintained packages in Debian-main, and as if nosh weren't available in a compatible .deb from a third-party repo, and as if s6, perp, nosh, ninit, sinit, minit, finit, Epoch, and uinit were not available in source and easy to build.
The options that were most seriously considered for a Debian default were systemd and SysVInit.
Anyway, I have a difficult time believing DDs are helpless to use killfiles.
Some addresses have been banned from the Debian BTS. But that doesn't scale well and causes some annoyance to people maintaining the packages in question and the Debian sysadmin team. You don't get to just use a killfile if you are part of a project like Debian.
Upstart is no longer the default for Ubuntu, I guess it's future isn't that good.
I've never liked Upstart myself -- but it's open source and able to be maintained if anyone continues to care.
True. But the whole process of arguing about systemd has put a lot of people off. Anyone who's not up for an argument is probably giving such packages a wide berth.
If you want a tiny minimal init then having one that is linked with cp, mv, etc probably isn't the way to go.
Busybox isn't exactly 'linked with' those. The code in the Busybox binary able to fulfill those functions isn't used when invoked as /sbin/init, I'm pretty sure. However, yes, it's certainly not ideal. The likes of the s6 PID1 init are probably a lot better.
It is exactly linked with those utilities. For most utilities there is a single .c source file and the .o files are all linked together. If you are worried about security then linking with other code isn't what you really want as there are a variety of attacks that involve jumping to other code. Not that I think such concerns about security should be an issue. I think that PID1 should be simple enough that attacks aren't viable. There's already a dozen systemd daemons doing various things, we should be able to get PID1 down to something small and simple such that there isn't a viable attack surface.
The PID1 program could reap processes and then inform the supervision process about it.
Yes, but this introduces complexity that's just not really worth the benefit. Supervisors work just fine without coordinating with PID1. At $WORK, a large Internet business, we use supervisord with great success, and the theoretical holes in it from lack of coordination with PID1 really don't matter in the real world.
That could be, cgroups should be able to do all this. But in any case I think we can agree that PID1 should be small and simple. The 1MB systemd binary could do with some simplification.
And socket activation is actually a big dumb bad idea as we know from initd/xinetd, but available with sundry toolkits if you actually want it.
Why? inetd always worked well for what it did.
And you might have noticed that it was used only for trivial services and for those unable to open sockets without help.
It turned out, the alleged benefit of socket activation really didn't buy you anything. 'You save having a process until the daemon's needed.' Um, are we running out of process identifiers? 'You save RAM by not having the daemon loaded until it's needed.' Um, are we suddenly unable to have inactive processes swapped out?
One corner case that socket activation could be good for is daemons that aren't really needed. For example if you install KDE you get the mysql server dragged in because kmail wants to store some stuff in a database. As an aside I think that this wasn't a good design choice for kmail, but I'm not involved with the coding. So as you have the mysql server installed the startup process waits on mysql starting for the system even though in most such installations it will never actually be used. If mysql was started by socket activation on a lot of systems it would never be started. Of course people like us can manually set the system mysqld to not start, but most people can't.
If you actually need a superserver, there are much better ones, one per service, such as s6-tcpserver (s6 suite) or tcpsvd (Gerrit Pape's tools). Starting those superservers in parallel, as any supervision suite can, will end up being just as fast as trying to open every possible socket early on in process 1. There is really no reason at all why a superserver should be tied to an init system.
It's true that it doesn't have to be integrated. But the conclusion of the war about this was to accept the systemd defaults.
I'm hardly 'desperate' to call myself a feminist.
Then why are we even discussing it? -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/