Which init system for Debian?
Which init system for Debian?
Posted Nov 6, 2013 12:36 UTC (Wed) by josh (subscriber, #17465)In reply to: Which init system for Debian? by tzafrir
Parent article: Which init system for Debian?
(Bonus if the packaging occurs separately: each random daemon could depend on that-daemon-launchd only on kfreebsd, allowing maintenance of that scripting in a separate package.)
Posted Nov 6, 2013 13:20 UTC (Wed)
by tzafrir (subscriber, #11501)
[Link] (34 responses)
per-architecture Maintenance of packages is frowned upon in Debian as it doesn't scale. In practice it would mean that most packages will not Just Work[tm] on kFreeBSD.
[0] well, technically there are two: mfreebsd-i386 and kfreebsd-amd64.
Posted Nov 6, 2013 14:02 UTC (Wed)
by josh (subscriber, #17465)
[Link] (33 responses)
upstart doesn't currently run on kfreebsd; better to support the native init system for that platform than port a new one. And no, supporting sysvinit, upstart, systemd, and launchd would be a bad idea. Supporting systemd and launchd, on the other hand, would be an improvement over supporting systemd and sysvinit (with the latter kept around for the benefit of kfreebsd).
Posted Nov 7, 2013 7:59 UTC (Thu)
by dgm (subscriber, #49227)
[Link] (32 responses)
Neither does systemd.
The question is: is upstart portable to kfreebsd? Because if it is, then it puts upstart in a much better position to be the init that will rule them all. I assume that porting upstart is less work than introducing (and keeping) launchd in the long run. I guess an essential question is if upstart developers are willing to do the port. Knowing they are already part of Debian and actively proposing upstart, I guess they are. But better ask them, and by the way, ask them if it's their intention to maintain upstart even in the case their corporate overlord changes plans.
Posted Nov 7, 2013 12:41 UTC (Thu)
by HelloWorld (guest, #56129)
[Link] (29 responses)
http://lists.debian.org/debian-ctte/2013/11/msg00011.html
Picking anything other than systemd would be a huge mistake both for the debian project and for the Linux ecosystem as a whole.
Posted Nov 7, 2013 15:02 UTC (Thu)
by Seegras (guest, #20463)
[Link] (1 responses)
I don't use them, BUT ports are always a good idea to find bugs. And insofar, I care about them.
More interesting than different kernels are however different architectures. Debian ARM does much more to find bugs than Debian/Hurd does (and Hurd only runs on i386 anyway).
Posted Nov 7, 2013 21:05 UTC (Thu)
by HelloWorld (guest, #56129)
[Link]
Posted Nov 7, 2013 15:08 UTC (Thu)
by dgm (subscriber, #49227)
[Link] (18 responses)
And that are not provided by the current default init system either. And we somehow have managed to live without them so far.
> I won't be using Debian in the future if they actually go with Upstart.
That would not be very rational. To start, I think changing the default does not preclude from having options. Both Upstart and systemd are available right now, for instance.
Anyway, any option chosen will be an step ahead, even if it isn't the option with more features. Simplicity is also a very good quality to have in such a central piece of the system.
> I, like 99% of all Debian users, don't care about the kFreeBSD or Hurd ports.
But you should. For the same reasons you should care about processors other than x86, form factors other than desktops, and OSes other than Windows (that's what most people use, after all).
Posted Nov 7, 2013 16:51 UTC (Thu)
by andreasb (guest, #80258)
[Link]
> But you should. For the same reasons you should care about processors
Well, 99% of all Debian users don't care about m68k. And so the port was dropped from the archive years ago when it couldn't keep up instead of holding back kernel, libc and toolchain versions, Debian freezes/releases and whatnot. Same for alpha and hppa.
Yet people argue that kFreeBSD and Hurd require all of Debian to bend over backwards to support them no matter the cost.
Posted Nov 7, 2013 22:13 UTC (Thu)
by HelloWorld (guest, #56129)
[Link] (16 responses)
> Anyway, any option chosen will be an step ahead, even if it isn't the option with more features. Simplicity is also a very good quality to have in such a central piece of the system.
> But you should.
Posted Nov 11, 2013 14:23 UTC (Mon)
by dgm (subscriber, #49227)
[Link] (15 responses)
You realize there's a difference between "need" and "want", don't you?
> I don't think that's for you to judge.
My opinion is completely for me to judge.
Posted Nov 11, 2013 15:45 UTC (Mon)
by HelloWorld (guest, #56129)
[Link] (13 responses)
> My opinion is completely for me to judge.
Posted Nov 11, 2013 22:14 UTC (Mon)
by dlang (guest, #313)
[Link] (7 responses)
>It's none of your business what I should or shouldn't care about. Of course you're entitled to your opinion, but that doesn't mean you have to tell the world about it, and you're being a smart-arse if you do.
similarly, you can't say that "everyone needs this" or "everyone wants this" when there are people who are saying that they are happy without this.
Nobody is saying that systemd shouldn't be an option for the people who want it. The only thing that people are objecting to is being forced to switch distros to avoid using systemd when they don't want it.
and the statement from Lennart that systemd is not an init system, it is a set of "components needed to build up an operating system on top of the Linux kernel" don't make people happy who want to run a Unix OS instead of a Lennart OS. Again, they don't object to people who want to run LennartOS having that ability, they object to distros being chnaged from Unix to LennartOS while keeping the same name (if you think about this a bit, it's exactly the same objection people have to Gnome3 being so completely different than Gnome2 but keeping the same name)
Posted Nov 11, 2013 23:29 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (6 responses)
Other people object to being forced to switch distros to get systemd by default when they do want it, when essentially all other distributions of note are using it by default, too – rather than having to patch it into Debian after the fact just to keep a small percentage of users on the fringe happy.
The funny thing is how, by and large, the actual Unix OSes have quietly moved over to using other init systems. This should tell us something about the continuing viability (or lack of such) of System-V init, and the sense (or nonsense) of trying to hang on to it at all costs, just for old times' sake. We have made all sorts of other sweeping changes to Linux over the years without bothering to change the name, so claiming that changing the init system suddenly makes Linux into a different operating system seems a bit contrived.
Anyway, after 30 years or so of SysV init, it makes sense to look for a replacement that is up to handling the fact that today's Linux computers, on the whole, do not look like a DEC VAX with two dozen terminals. Various such replacements have been proposed. In my opinion it makes sense for Debian to put the question of which init system should be Debian's default before the TC; we can only hope that this question will be debated on the technical merits of the proposals rather than propaganda and FUD, and that whatever decision is eventually taken will be supported by all the camps in question.
Posted Nov 12, 2013 3:14 UTC (Tue)
by dlang (guest, #313)
[Link] (5 responses)
As for other distros that don't want to offer multiple options, I would say that people who want something not in their distro are the ones who should change to a different distro rather than the ones who want things to keep working.
your positioning of people who are happy with things as they are as the 'fringe' is not conclusive to calm discussion
Posted Nov 12, 2013 9:55 UTC (Tue)
by anselm (subscriber, #2796)
[Link] (4 responses)
Yes, and if the Debian TC decides to make systemd or Upstart the default on Linux, Debian will probably still allow you to use SysV init if you want.
I think that if Debian does decide to change its default init system there will be a huge emphasis on »keeping things working«. Systemd, for example, can deal with SysV init scripts; you just lose some of systemd's special features for those services.
The »people on the fringe« are those who believe that the mere existence of Debian on a FreeBSD or Hurd kernel entitles them to dictate policy to the project as a whole.
It's great if people are »happy with things as they are«. However, progress marches on, and Debian as a project must figure out how to deal with this. Possibly after a transition to a more modern init system, as many (or more) people will be as happy (or even happier) with things as they are then. That there are people who are happy with the current setup today should not act as an automatic barrier to well-reasoned change.
In other words, I'm sure that in the past there were lots of people who were blissfully happy with things like a.out binaries, libc5, or a static /dev directory, but even so the Debian project decided to go with ELF, glibc2, and udev, and by now there is fairly general consensus that these were reasonable decisions. It is very likely that if Debian does decide to go with systemd as the default init system on Linux even in the face of vociferous objections from those people who still like SysV init, a few years from now we will look back and consider that decision reasonable, too, in the grand scheme of things. Fondly remembering the old days when we managed to get by with simpler approaches to many things does not preclude embracing new and better solutions that are designed to deal with today's (or even tomorrow's) challenges.
Posted Nov 12, 2013 10:18 UTC (Tue)
by dlang (guest, #313)
[Link] (3 responses)
This is one of the things I trust Debian (and Gentoo) to do well, they provide options rather than picking the 'one true way'
I would not be thrilled if Debian were to pick systemd as the default, but as long as it remained a requirement that packages work without systemd, it would only be a mild annoyance (very similar to their use of Grub while I still prefer lilo in most cases)
It would only be if they started allowing systemd-only packages as something other than a very rare case that I would have a problem with it.
Posted Nov 12, 2013 10:42 UTC (Tue)
by anselm (subscriber, #2796)
[Link] (1 responses)
Personally I wouldn't want to bet the farm on this. Your best hope is that the non-Linux Debian platforms will stick with SysV init, and that some support for SysV init remains in Debian policy to cater to those.
Speaking as a Debian developer, one enticing advantage of systemd is no longer having to write SysV init scripts, so I would hope that the Debian policy requirement to do so will eventually go away, or that at the very least we will come up with a way of automatically creating SysV init scripts from systemd unit files. I seem to remember that this is being looked at, and if Debian does decide to go with systemd, I would certainly expect the vocal SysV init aficionados to contribute heavily to that effort.
Posted Nov 12, 2013 13:02 UTC (Tue)
by HelloWorld (guest, #56129)
[Link]
Posted Nov 20, 2013 22:53 UTC (Wed)
by josh (subscriber, #17465)
[Link]
There's an option under consideration to keep multiple options; that'd be better than sticking with sysvinit for all eternity, but ideally I'd like to see a switch to systemd with sysvinit script compatibility as the default option, thus allowing software to depend on it.
It'll then be up to people who want to keep other init systems going to submit patches supporting them; it shouldn't be the job of every maintainer of software whose upstream relies on systemd to fork it and remove that dependency. If someone wants that, they should "fix" it upstream or fork the project themselves, rather than making Debian do it.
Posted Nov 13, 2013 17:38 UTC (Wed)
by ThinkRob (guest, #64513)
[Link] (4 responses)
Some developers and power users do.
Users wants systems that boot quickly (for varying definitions of quickly), and work reliably.
Personally I believe that the users' requirements can be (and in the past have been) met without systemd. The power users/developers, on the other hand? Tthey want systemd in part because it's new and cool, and playing with new and cool tech is... well... cool.
Posted Nov 13, 2013 19:28 UTC (Wed)
by smurf (subscriber, #17840)
[Link] (3 responses)
I don't want systemd because it's new and cool. I want it because with systemd I can forget about complex nonsense in the stuff I do care about.
For instance, my daemon process doesn't have to go through the rigmarole of double-forking, detaching from the terminal, cleaning up its environment, etc., any more. This is easy to get wrong. Esp. when a library writes its error messages to STDERR … which daemonizing redirets to /dev/null. Ouch.
I can use journalctl. That gives me the output I care about in exactly one place. This makes my job of debugging programs easier. This makes for more reliable programs. This benefits "normal" users.
I can restart a socket-activated process seamlessly. This benefits normal users because their system is no longer in a semi-reliable in-between state when they upgrade it.
I can give daemons their own /tmp, restrict them from looking at users' /home, and whatnot. Granted that this can be done with some sort of helper program, but with systemd's config files this sort of thing is so simple that it's actually going to be used. (And it's faster.)
And so on.
Posted Nov 13, 2013 20:27 UTC (Wed)
by raven667 (subscriber, #5198)
[Link]
I run into this all the time because most of our locally generated software is perl written by people who's primary job isn't systems programming so I have to try and fix it in shell using nohup and shell job control and whatnot, getting scripts to set their $0 so that I can use pidof to identify and restart them (instead of having everything be /usr/bin/perl). All of this hoop-jumpery doesn't feel like well thought through design, it feels hacky and hokey whereas systemd seems well thought through, well documented and thorough. You can read through the design philosophy and process in the blog posts at 0pointer.de and judge whether they make sense to you, they certainly made sense to me and seem an improvement on daemontools or runit in every way.
Posted Nov 19, 2013 5:57 UTC (Tue)
by ThinkRob (guest, #64513)
[Link] (1 responses)
That's kinda my point. You're a power user. You write your own init scripts.
Most users don't. Most probably never will.
For them, it doesn't really matter if their distros' maintainers had to jump through a bunch of hoops to make sysvinit work.
I'm glad you like systemd. It's got a lot of cool tech in it, and while I'm not sold on it being made a key part of peoples' security strategies, I do think it's good at handling a lot of, well, system tasks. But I'm also not a normal user, so I'm with you in that segment of the community that likes things that offer neat features to developers and sysadmins. I just don't think that my views are majority opinions, that's all.
Posted Nov 19, 2013 9:17 UTC (Tue)
by smurf (subscriber, #17840)
[Link]
I don't. Not any more. And that's a good thing.
I just fail to see any advantage of staying with sysV, for any use case. Other than "hey diversity" or "hey kFreeBSD/Hurd", both of which I frankly do not care about at all, because (a) I propose to be diverse in the areas that actually matter to users and their use cases instead of infrastructure that makes programs more difficult to install and maintain, and (b) the number of kFreeBSD or Debian/Hurd users is, frankly, so small that forcing a suboptimal init system on the rest of Debian ultimately wastes more man-hours than the productive uptime of all these systems combined. :-P
Seriously, also shipping rudimentary sysV init scripts for these systems is not going to be a problem. Or take much effort. If any.
Posted Nov 15, 2013 23:01 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
Systemd, however, will soon be providing that by default. Which means I might have to swap my gentoo install over from OpenRC - I'm not looking forward to it.
THAT is the sort of complexity that presumably is needed in the startup system - I presume that is everything that happens before user login, no?
Cheers,
Posted Nov 10, 2013 14:11 UTC (Sun)
by Jandar (subscriber, #85683)
[Link] (3 responses)
And there are many people who don't want all of this forcible managed by a monolith at the core of the system.
The features of systemd are nice but this overarching greedy tentacle-monster is terrifying.
Posted Nov 10, 2013 17:41 UTC (Sun)
by raven667 (subscriber, #5198)
[Link]
I just can't get there man, all systemd is doing is exposing all of the existing configuration knobs for starting processes that the Linux kernel has accreted over the last decade in a consistent way. Those features and the complexity around them don't just go away if the init system doesn't support them, it just gets pushed into other tools that aren't integrated well. I don't find that terrifying, I'm relieved and glad that I can finally find and use these kernel features, and that the standard for process management has finally moved past pid files and super-hokey scripts. I guess I was spoiled all those years with daemontools.
Posted Nov 10, 2013 20:07 UTC (Sun)
by khim (subscriber, #9252)
[Link]
Once opon time the same thing was said about Linux itself. Remember the infamous Microkernels have won tirade? Systemd looks like a repeat of the same story: sure it's theoretically nice to have many small packages instead of one large package, but in practice it just makes no sense. What difference does it make if error in any one of these can give you root access? Useless frictions on the boundaries between packages? Once upon time GNU has fileutils, shellutils, and textutils. Not they have combined it all in coreutils. Systemd does the same to set of utilities dedicated to the system startup. It does not merge tham into a huge monolythic monster, instead it offers a collection of well-integrated utilities when each one does few things and does them well. It's core is large for the same reason Linux core is large: many things are just hard too pull of if you don't control PID 1. You can kinda make them work but not reliably, you can introduce interface between PID 1 and other utilities, but if there will be exactly one consumer for the interface it'll just complicate everything without giving anyone any real benefits.
Posted Nov 10, 2013 20:07 UTC (Sun)
by khim (subscriber, #9252)
[Link]
Once opon time the same thing was said about Linux itself. Remember the infamous Microkernels have won tirade? Systemd looks like a repeat of the same story: sure it's theoretically nice to have many small packages instead of one large package, but in practice it just makes no sense. What difference does it make if error in any one of these can give you root access? Useless frictions on the boundaries between packages? Once upon time GNU has fileutils, shellutils, and textutils. Not they have combined it all in coreutils. Systemd does the same to set of utilities dedicated to the system startup. It does not merge tham into a huge monolythic monster, instead it offers a collection of well-integrated utilities when each one does few things and does them well. It's core is large for the same reason Linux core is large: many things are just hard too pull of if you don't control PID 1. You can kinda make them work but not reliably, you can introduce interface between PID 1 and other utilities, but if there will be exactly one consumer for the interface it'll just complicate everything without giving anyone any real benefits.
Posted Nov 14, 2013 7:22 UTC (Thu)
by kevinm (guest, #69913)
[Link] (3 responses)
(syscall filtering should be setup in the individual apps, by the way).
Posted Nov 14, 2013 8:30 UTC (Thu)
by khim (subscriber, #9252)
[Link]
Really? Recall that it's ability to kill and restart services and indeed, the whole underlying infrastructure (cgroups) were designed specifically for server needs, they were adopted by Gnome only later. Recall that all "big" UNIXes switched to custom-made init systems for more-or-less the same reason even if they no longer viable on desktop (indeed sales of UNIX workstations have ended) and it'll become obvious that even on servers systemd makes perfect sense. kFreeBSD or Hurd, on other hand... have anyone ever seen them used on server in production?
Posted Nov 15, 2013 6:38 UTC (Fri)
by smurf (subscriber, #17840)
[Link] (1 responses)
Go through the list of systemd's features sometime, and then tell us honestly which are more appropriate for workstations vs. servers.
SysV "server management" can still mostly be replaced with a linear list of command lines. systemd cannot.
Posted Nov 16, 2013 20:50 UTC (Sat)
by kleptog (subscriber, #1183)
[Link]
By all accounts systemd will do an even better job, though I've not had the opportunity to find out yet...
Posted Nov 7, 2013 13:49 UTC (Thu)
by josh (subscriber, #17465)
[Link] (1 responses)
I never said it did; it makes more sense to use the most capable native init for each platform than to force one less capable init system across the board in the name of portability.
Hence systemd for Linux and launchd for kfreebsd.
Posted Nov 7, 2013 14:55 UTC (Thu)
by dgm (subscriber, #49227)
[Link]
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
I doubt that. systemd offers a ton of features that people want and that Upstart doesn't have: cgroup arbitration, resource management, logind, kdbus, syscall filtering, capability management and a lot more. Choosing Upstart means that they'll have to develop and maintain this by themselves (or get Canonical to do it), and that's a ton of work. I don't see that happening, and thus I won't be using Debian in the future if they actually go with Upstart. Because I, like 99% of all Debian users, don't care about the kFreeBSD or Hurd ports. Others seem to agree with that:
Which init system for Debian?
> Hurd ports.
Which init system for Debian?
I disagree. Probably most of the bugs that are found by porting to other platforms only affect that platform or abstraction layers that only exist to make the software portable. I also think it's more efficient to spend time on dedicated debugging measures (code review, valgrinding, bug triaging etc.) than to spend it on a new port that nobody actually uses in production and hope for bugs to be eliminated as some sort of side effect.
Which init system for Debian?
Which init system for Debian?
>> ports.
> other than x86, form factors other than desktops, and OSes other than
> Windows (that's what most people use, after all).
Which init system for Debian?
Yeah, and my grandma somehow manages to live with no computer at all. What kind of argument is that supposed to be?
The need for complex features doesn't simply go away when your init system doesn't offer them, the complexity is simply shifted elsewhere. This is a common phenomenon that is expressed, among others, in Greenspun's tenth rule of programming.
I don't think that's for you to judge.
Which init system for Debian?
Which init system for Debian?
It doesn't matter at all. Just replace "need" with "demand" in my comment, that doesn't change the essence of the point I'm making. People want it, and if they don't get it from debian, they'll get it from somewhere else.
It's none of your business what I should or shouldn't care about. Of course you're entitled to your opinion, but that doesn't mean you have to tell the world about it, and you're being a smart-arse if you do.
Which init system for Debian?
Which init system for Debian?
The only thing that people are objecting to is being forced to switch distros to avoid using systemd when they don't want it.
they object to distros being chnaged from Unix to LennartOS while keeping the same name
Which init system for Debian?
Which init system for Debian?
Debian already allows you to use systemd if you want.
I would say that people who want something not in their distro are the ones who should change to a different distro rather than the ones who want things to keep working.
your positioning of people who are happy with things as they are as the 'fringe' is not conclusive to calm discussion
Which init system for Debian?
Which init system for Debian?
I would not be thrilled if Debian were to pick systemd as the default, but as long as it remained a requirement that packages work without systemd, it would only be a mild annoyance
Which init system for Debian?
https://github.com/akhilvij/systemd-to-sysvinit-converter
That project seems to have gone dormant about a year ago.
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
> That's kinda my point. You're a power user. You write your own init scripts.
Which init system for Debian?
Which init system for Debian?
Wol
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?