Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Mon, Dec 30, 2013 at 02:03:22 -0800, Steve Langasek wrote: The upstart session init runs as the user, not as root. Note that a session init can run as root (sudo init --user) but yes, conventionally they are run as non-priv users. I'm not sure if upstart as a user session has any dependencies on upstart being PID 1. Cc:ing James, who would know better - James, do you know if upstart session init works on non-upstart systems? I've got a Session Init running fine on Wheezy with SysVinit as PID 1. To do this: 1) sudo apt-get install libnih1 2) sudo apt-get -y build-dep upstart 3) Download an upstart release (or branch the code from lp:upstart). 4) Unpack. 5) autoreconf -fi ./configure make 6) Manually install the following: util/initctl from the build tree as /sbin/initctl init/init from the build tree as /sbin/session-init. 7) Setup a few basics and create a single job to start a terminal (no WM :) mkdir -p ~/.config/upstart mkdir -p ~/.cache/upstart cat ~/.xsessionEOT XDG_RUNTIME_DIR=/some/where export XDG_RUNTIME_DIR mkdir -p $XDG_RUNTIME_DIR exec /sbin/session-init --user EOT chmod 755 ~/.xsession cat ~/.config/upstart/terminal.confEOT start on startup exec gnome-terminal EOT 8) Login. Kind regards, James. -- James Hunt #upstart on freenode http://upstart.ubuntu.com/cookbook https://lists.ubuntu.com/mailman/listinfo/upstart-devel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Hi Russ, On Fri, Nov 01, 2013 at 08:11:38PM -0700, Russ Allbery wrote: Steve Langasek vor...@debian.org writes: For the TC decision, what kind of information are you looking for about the plans, beyond the Ubuntu developers expect to need to address this before upgrading from systemd logind 204 and will hold at 204 until a correct solution is known? I think the right way to put this is that systemd has significant development resources behind it and is working in fairly close cooperation with both kernel developers and GNOME developers to make available new kernel functionality and to provide implementations of various other interfaces. Multiple implementations are good, but there's potentially an ongoing stream of development to keep up with, and (putting aside arguments about coupling and appropriate ways to integrate that functionality) I believe there is a general agreement that functionality is desirable and will be used by other software that Debian wants to provide. So, one question is whether anyone outside of Canonical is in a position to help with the heavy development (as opposed to the occasional patch). Red Hat is clearly committed to systemd, and there's some convergence towards it among other RPM-based distributions, so long-term resources for systemd don't seem to be in doubt. Canonical is a smaller company, and does not always have the resources to keep projects for which it is the sole upstream vibrant and growing, even when it seems strongly committed to them (c.f. bzr). While it's fair to note that Canonical is a smaller company with fewer resources than Red Hat, Canonical is certainly not the only company working on technologies that don't fit into systemd upstream's model. On the question of cgroup management for instance, while there's broad consensus that we want to move to a single-writer model, there is not consensus about what that single writer should be; at the last on-line Ubuntu Developer Summit, developers from Canonical and Google discussed how to collaborate around their respective cgroup technologies (lxc, lcmtfy) to address the single-writer requirement for non-systemd systems. http://summit.ubuntu.com/uds-1311/meeting/21982/core-1311-cgroup-manager/ We're not talking here about whether Google will contribute to upstart upstream, because this is code which is separate from upstart by design. But in the wider ecosystem of projects that exist in parallel to (and are incompatible with) systemd, there are other players besides Canonical. For logind, which is the main point of contention with respect to systemd 205 being usable on systems that don't use systemd as init, the main blocker is, again, around logind's use of init as the cgroup manager. In that same UDS session, a decision was taken to provide cgroup manager API compatibility with systemd via the systemd-shim package, which is a small Canonical-maintained compatibility layer (not yet in Debian, but that's easily addressed). This will enable use of logind 205 on systems running upstart (or, for that matter, sysvinit). I don't believe we need to worry about sufficient manpower to keep up with systemd development. There are a fair number of people who have resigned themselves to systemd because they've been led to believe it's the only option. If Debian standardizes on upstart, some of these developers will be interested in collaborating with Debian to provide equivalent functionality / compatible interfaces. It may not be many developers in absolute terms, but the rate of development for an init system should not be high in absolute terms either. The greater Free Software community does not have inexhaustible patience for projects that are constantly breaking backwards-compatibility; whether Debian adopts systemd or not, we are going to care about things like being able to run current systems in chroots/containers on older (stable) kernels, and we're going to care about being able to cleanly upgrade from one stable release to the next, and a revolving door of rapidly changing kernel interface requirements is bad for the ecosystem as a whole - and will therefore be self-limiting. If Canonical *is* the sole upstream, the upstream future here is troubling to me, particularly given Canonical's current strategic direction towards Unity. To give a specific example of the sort of thing that I'm worried about, suppose that GNOME Shell wants a new piece of functionality that is, on Red Hat, provided via kernel functionality managed by systemd, but Unity has no need for that functionality. Is Canonical going to develop an upstart equivalent in support of GNOME Shell, when it is pushing Unity over GNOME Shell? Maybe this example is very artificial; I know it's not clear what piece of functionality would be required from the init system and surrounding infrastructure that would be required by GNOME Shell and not Unity. But I think it's at least conceivable given
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Steve Langasek vor...@debian.org writes: While it's fair to note that Canonical is a smaller company with fewer resources than Red Hat, Canonical is certainly not the only company working on technologies that don't fit into systemd upstream's model. On the question of cgroup management for instance, while there's broad consensus that we want to move to a single-writer model, there is not consensus about what that single writer should be; at the last on-line Ubuntu Developer Summit, developers from Canonical and Google discussed how to collaborate around their respective cgroup technologies (lxc, lcmtfy) to address the single-writer requirement for non-systemd systems. http://summit.ubuntu.com/uds-1311/meeting/21982/core-1311-cgroup-manager/ We're not talking here about whether Google will contribute to upstart upstream, because this is code which is separate from upstart by design. But in the wider ecosystem of projects that exist in parallel to (and are incompatible with) systemd, there are other players besides Canonical. For logind, which is the main point of contention with respect to systemd 205 being usable on systems that don't use systemd as init, the main blocker is, again, around logind's use of init as the cgroup manager. In that same UDS session, a decision was taken to provide cgroup manager API compatibility with systemd via the systemd-shim package, which is a small Canonical-maintained compatibility layer (not yet in Debian, but that's easily addressed). This will enable use of logind 205 on systems running upstart (or, for that matter, sysvinit). This is useful, thank you. So you believe that the necessary cgroup functionality will be easy to maintain going forward in collaboration with a different cgroup manager? How far away is this functionality from being production-ready? My understanding is that this will need to be tested and working for jessie. I don't believe we need to worry about sufficient manpower to keep up with systemd development. There are a fair number of people who have resigned themselves to systemd because they've been led to believe it's the only option. If Debian standardizes on upstart, some of these developers will be interested in collaborating with Debian to provide equivalent functionality / compatible interfaces. It may not be many developers in absolute terms, but the rate of development for an init system should not be high in absolute terms either. Well, I partly agree with this, but I'll point out that upstart is currently significantly behind in functionality. Contrary to some other expressed opinions here, I personally do not consider systemd's support for such things as private /tmp or other security and isolation features to be minor side features or only marginally interesting. I think these sorts of features are where the Linux ecosystem is moving, quite quickly, and Debian badly needs those features as soon as we can get them. It's going to take some time to adapt all of our software to use those features, so the sooner our init system can provide them and we can get started, the better. I have a similar question about OpenRC: the lack of this sort of functionality is, for me, a very serious issue, although one that would be mitigated by a clear plan to add it that seems likely to happen. Well, I guess you wouldn't expect me to say yes here, or if I did, you wouldn't believe me; it's unrealistic for Canonical to commit to implementing some arbitrary - and hypothetical - future functionality. Canonical is committed to being a good steward for upstart for as long as Ubuntu itself uses it, and welcomes its use by other distributions. But this isn't an act of altruism, it's enlightened self-interest. Canonical isn't going to make an indefinite committment to maintain features it doesn't have need for itself. But I think the same can be said of systemd. If Debian concluded that systemd's cgroup manager design was wrong because it embeds it in PID 1, and wanted systemd to be compatible with other container solutions like lxc and lmctfy, I don't think we would expect Red Hat to make this happen for us. The problem for upstart is that these are not comparable, precisely because Canonical plays such a smaller role in the broader ecosystem. For better or worse, integration with Red Hat and Fedora is extremely important to most of our upstream projects, and Red Hat provides significant development resources itself to many upstream projects. This means that systemd integration is far more likely to happen without Debian's assistance than upstart integration. I think the argument for upstart relies on the assumption that such integration is not horribly important or normally won't be a serious issue. In essence, my understanding of how you view a world with upstart (and the world that Ubuntu is implementing) is that we will use most of the systemd services but not its init engine,
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
The original question was which init system[s] are going to be the default. But there are still some other things I'm curious about: 1. we already have alternate init systems in the archive; could it be some kind of release goal to ensure they are installable? i.e. make it possible for them to satisfy the dependencies of essential packages. (Steve Langasek's metapackage idea in [0] seems to be in the right direction for accomplishing that, except it wouldn't work for OpenRC or indeed for keeping the original sysvinit/sysv-rc). [0]: http://lists.debian.org/debian-devel/2013/11/msg00389.html 2. would exceptions be permitted; could some packages explicitly depend on a non-default init system if it's the only one providing functionality it needs (and still be part of a stable release)? I'm thinking that GNOME might (someday, if replacements for logind or other APIs can't be found) want to do this, if systemd isn't chosen as the sole default on GNU/Linux. (It seems similar to a maintainer being able to restrict packages to Arch: linux-any if they cannot / do not want to support non-Linux ports). Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Tue, Nov 5, 2013 at 2:02 PM, Russ Allbery r...@debian.org wrote: Peter Dolding oia...@gmail.com writes: ExecStartPre=, ExecStartPost= can be written many times. ExecStartPre= rm somewhere ExecStartPre= touch somewhere That really doesn't help, because... In fact lot of cases I see one line entries in systemd and I see bad form. Unless one line has like if or for statements its really bad form inside systemd. ...of this. If you can't write the scripts with proper block structure, it's actually better to just externalize them in a separate file rather than doing something this awful to try to inline them. I don't think you're going to convince me to like this syntax. :) But it's a minor issue. The multi line option in systemd has other uses when debuging. Basically upstart is lacking one key feature. If it not fixed it will come back and bite us. Really I would like to see this fixed before debian takes up upstart if debian takes up upstart at all. I'm afraid there is little chance you will manage to convince me that this is a key feature. I've been writing portable shell scripts for years, and Debian has been dealing with shell portability issues for years. Regardless of what we do with the init system, we will still have to deal with this with maintainer scripts, etc. I do see why you're concerned, but I just don't see this as critical compared to other issues under discussion. Russ I take it from this point of view. If we cannot get a minor key feature for future compatibly taken upstream. Will means the upstart maintainer ship has to be classed as proven hostile. This is in fact a good test to see what init systems Debian can work with to see if debian can get minor alterations upstream. At this point upstart maintainer-ship is suspected of being possibly hostile. Its about time we find out if they are. As you say we have to deal with maintainers scripts. We also have to deal with third party items at times. Basically upstart is tieing one of my hands behind my back to deal with bad upstart files. The worst risk is ubuntu and debian using a different /bin/sh and having different portability requirements and I am for some reason forced to use a ubuntu .deb package for something. Remember the case of steam binaries. History tells us that your idea we can write script portable is a foolish idea. Just because you can not everyone else can. Like if I have altered a script from some third party they can blame my alteration. Yes there is a reason why you must be able to just change the shell. This is not exactly a minor issue. The lack of means to set shell effects future possibilities of importing binaries built only for Ubuntu and other distributions using upstart. Also upstart means writing a more complex auditing tool. Vastly more complex. Systemd single line system is really simple to write a script to go through and check everything starting exec after the = for ; so finding where any maintainer gets the idea of in-lining foolishly. So is fairly simple to automated a debian test to badly designed systemd unit files. Yes the external shell script files will audit with debians existing tools without modifications. Peter Dolding -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Hi TC and people, Another issue that might or might have not already been answered, that was triggered from seeing direct comparison metrics. Do we have some kind of a metric or some even personal experience with regards to which project has been the most friendly in accepting patches *from* Debian? I think it's also important, especially if the patches are not really relevant to the project's direct goals, say, fixes for a specific Debian port or missing feature that Debian needs and has a patch for, but upstream does not care about. I'm being generic here, but it's quite common for Debian to have distro-specific patches in its packages. Some of them can be upstreamed, but there are cases where Debian has to carry those patches around forever. So the question is, which of the init systems has been the friendliest to Debian so far, if anyone has any experience on this matter? Regards Konstantinos pgpZg0xGjjIMY.pgp Description: PGP signature
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Thijs Kinkhorst th...@debian.org writes: On Wed, November 6, 2013 01:16, Russ Allbery wrote: We'll want to look at both sides of that question, and try to understand how much work like that is potentially on the horizon with the various choices. Do you? In the past Debian has not shied away from making the choice that it considers technically (or philosophically) the most sound, not the one that implies the least amount of work. The choice will probably be made on just a few high-level factors, such as the chosen approach (dependency vs event based), best user experience and/or licensing. Well, my choice won't be made on just those few high-level factors, for whatever that matters. And I seem to have one. :) Technically the most sound and implying the least amount of work are not two unrelated factors. Apply reductio ad absurdum: vaporware is not technicallly sound, regardless of what lofty design principles underlie it. We need to be realistic here about what we, as a project, can accomplish. The ideal init system for Debian is, almost by definition, the one we write ourselves from scratch to do exactly what we want it to do. There's a good reason why no one has proposed that. We have certain realistic limitations about what we can and can't do as a project, which in this space, among other things, require us to adopt an existing project rather than writing our ideal implementation from scratch. The same also applies to other subsystems that go into our distribution. We aren't going to, realistically, write our own new syslog implementation, or our own new user session manager, or our own udev implementation, or our own desktop environment, or our own kernel. We're going to use existing projects, maintained by other people with other goals, some with goals that have nothing to do with Debian's goals. We need to choose useful, interoperable sets of those projects that can, at the end of the day, come together into a coherent system for our users. Since that's why we're all here. As part of that process, we may well contribute to those projects, perhaps substantially. But Debian is not an island to itself, and if we pretend we are, we won't produce the quality of distribution that we want to produce. We're part of a larger ecosystem, and that has quite a bit to do with the specific decision of how we choose our init system. Facts are being gathered about the percentage of code comments, but I it seems unlikely that Debian would reject a solution that it thinks is architecturally superior because of it having fewer code comments. That metric is trying to get at something that we do care about, namely is a particular upstream project going to be excessively buggy (poorly documented code implies harder to understand code implies people make mistakes when they change it) and can we understand it well enough to make whatever integration changes we need to make to it. Percentage of code comments is a very rough and somewhat dubious metric to use for getting at that question, but it's getting at something real. Just like the discussion that we had about syntax is getting at something real around the UI of the init system that we will expose to our users, even if the specific question of how one embeds shell commands in the startup script is not one on which the choice of init system will turn. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, November 6, 2013 09:10, Russ Allbery wrote: Thijs Kinkhorst th...@debian.org writes: On Wed, November 6, 2013 01:16, Russ Allbery wrote: We'll want to look at both sides of that question, and try to understand how much work like that is potentially on the horizon with the various choices. Do you? In the past Debian has not shied away from making the choice that it considers technically (or philosophically) the most sound, not the one that implies the least amount of work. The choice will probably be made on just a few high-level factors, such as the chosen approach (dependency vs event based), best user experience and/or licensing. Well, my choice won't be made on just those few high-level factors, for whatever that matters. And I seem to have one. :) Technically the most sound and implying the least amount of work are not two unrelated factors. Apply reductio ad absurdum: vaporware is not technicallly sound, regardless of what lofty design principles underlie it. We need to be realistic here about what we, as a project, can accomplish. The ideal init system for Debian is, almost by definition, the one we write ourselves from scratch to do exactly what we want it to do. There's a good reason why no one has proposed that. We have certain realistic limitations about what we can and can't do as a project, which in this space, among other things, require us to adopt an existing project rather than writing our ideal implementation from scratch. I doubt that Debian writing something from scratch would not be realistic: Debian actually has chosen to go the self-implementing route in key infrastructures the past, for example for the installer or package managers. Nonetheless, that's not relevant here. There are several likely candidates in existence, so the choice will not be to use something existing versus implementing from scratch; the choice will be between existing projects, and given that, the amount of work per system may differ but the difference will not likely be that great that it's unsurmountable, as they exist, they have active upstreams and they have successfully been used in other distributions. That metric is trying to get at something that we do care about, namely is a particular upstream project going to be excessively buggy (poorly documented code implies harder to understand code implies people make mistakes when they change it) and can we understand it well enough to make whatever integration changes we need to make to it. I do agree that it's nice to have the very best code quality available, but in the long run, having underdocumented code is annoying and may lead to bugs, but bugs can be fixed and documentation improved; changing the basic architecture of the system is unlikely to be fixed. I really believe we are going to regret it if Debian chooses the architecture it likes less for the reason that it has more documentation. Which system has better code documentation is not relevant. The relevant question is whether a system has adequate documentation, regardless of the documentation of other systems. I think I would like it better if the choice process was split in two. First, for each candidate system assess the supportability in Debian. Code quality can be a factor here. Can we reasonably run this? (Given that the two major choices have been used by several other distributions probably qualifies them, but Debian can make its own assessment here.) Then, from the shortlist of candidates, choose the 'best' one based on high-level but fundamental criteria, like architecture, licensing etc. Currently, it seems these two steps (is it supportable vs what should be the default) are conflated and a big matrix of facts of the different systems is built. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
* Thijs Kinkhorst (th...@debian.org) [131106 12:51]: Nonetheless, that's not relevant here. There are several likely candidates in existence, so the choice will not be to use something existing versus implementing from scratch; the choice will be between existing projects, and given that, the amount of work per system may differ but the difference will not likely be that great that it's unsurmountable, as they exist, they have active upstreams and they have successfully been used in other distributions. I'm not sure we are all convinced about that. And the question is not only do they have active upstreams, but also would upstream (continue to) develop things in a direction that's also useful for us. Taking an example (and this one is made-up, so please don't use the flame-key on me), if systemd would start to only work with the gnome desktop chooser this might be considered inacceptable, and wouldn't be too helpful for us I'd expect. Same example would work with upstart and unity. Or whatever else. I do agree that it's nice to have the very best code quality available, but in the long run, having underdocumented code is annoying and may lead to bugs, but bugs can be fixed and documentation improved; changing the basic architecture of the system is unlikely to be fixed. I really believe we are going to regret it if Debian chooses the architecture it likes less for the reason that it has more documentation. In the end (at least from my perspective) we need to choose on a set of advantages and disadvantages. There are different sets available (or at least there is no consensus in Debian at large that only one of them works). First of all, we need to check which ones would be working at all. If we notice that one of them won't allow us to properly release jessie, I think we don't need to check if that architecture might be a bit nicer. Also, if we notice that one architecture is unbearable broken, the same applies. If we however notice that a set might only work if Debian spends quite some effort, and we also notice that there are enough people in Debian willing to do the work - well, that returns this set in the group of sets we could choose from. Of course it still could happen that after this pre-check we end up with examples where we say no, really not because and we have to re-evaluate what other optins we have. But also we're not there yet. Andi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
]] Russ Allbery Peter Dolding oia...@gmail.com writes: ExecStartPre=, ExecStartPost= can be written many times. ExecStartPre= rm somewhere ExecStartPre= touch somewhere That really doesn't help, because... In fact lot of cases I see one line entries in systemd and I see bad form. Unless one line has like if or for statements its really bad form inside systemd. ...of this. If you can't write the scripts with proper block structure, it's actually better to just externalize them in a separate file rather than doing something this awful to try to inline them. I don't think you're going to convince me to like this syntax. :) But it's a minor issue. Disliking the syntax is of course fair enough. :-) In general, there should be enough declarative knobs that you can twiddle that you don't need to write shell scripts. That's the idea, at least. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
* Russ Allbery (r...@debian.org) [131104 18:21]: Carlos Alberto Lopez Perez clo...@igalia.com writes: Regarding the development force behind each project, I find the following comparison at Ohloh very illustrative https://www.ohloh.net/p/compare?project_0=openrcproject_1=upstartproject_2=systemd This isn't really a fair comparison since systemd as a project contains considerably more subsystems than upstart or OpenRC do. Actually I think this comparison contains valuable data points. However, one shouldn't think of it as more code is always better - in fact, I have often made the experience that too much code in critical systems is a problem by itself. And as you pointed out, it doesn't show the amount of development force correctly. However, it shows two things: one is as you said that systemd contains many more subsystems as the others (whether this is good or not is a different question), the other is that code documentation seems to be not as verbose as for upstart or OpenRC (in spite of the remarks I saw earlier about how much documentation is there). Andi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Tuesday, November 05, 2013 10:05:40 Andreas Barth wrote: [...] However, it shows two things: one is as you said that systemd contains many more subsystems as the others (whether this is good or not is a different question), the other is that code documentation seems to be not as verbose as for upstart or OpenRC (in spite of the remarks I saw earlier about how much documentation is there). On the latter point -- according to Ohloh, in OpenRC [1] and Upstart [2], 19% of the code is comments, where for SystemD [3] it's 11%. 1: https://www.ohloh.net/p/openrc/factoids#FactoidCommentsAverage 2: https://www.ohloh.net/p/upstart/factoids#FactoidCommentsAverage 3: https://www.ohloh.net/p/systemd/factoids#FactoidCommentsLow -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
* Russ Allbery (r...@debian.org) [131102 04:12]: If Canonical *is* the sole upstream, the upstream future here is troubling to me, particularly given Canonical's current strategic direction towards Unity. To give a specific example of the sort of thing that I'm worried about, suppose that GNOME Shell wants a new piece of functionality that is, on Red Hat, provided via kernel functionality managed by systemd, but Unity has no need for that functionality. Is Canonical going to develop an upstart equivalent in support of GNOME Shell, when it is pushing Unity over GNOME Shell? [...] In other words, it's not so much a specific roadmap as it is a roadmap approach and resource committment. Debian, by choosing a default init system, is potentially investing a lot of developer effort on supporting that platform for packaged daemons, somewhat akin to an organization choosing a product on which to base a required piece of internal functionality. I would like to ask this question even a bit more general (for all involved init systems): How much would we have vendor lock-in by each init system? Means, is there more software except the pure init system we might need to take if we switch to that init system. Also, what can we expect for the future? How much does the roadmap allow for exchanging other services without changing the init service? And also looking from the other perspective, if we would change the init service later on, which of the nearby services would we loose at the same moment as the init service? For upstart, this might be the case described above. For systemd, just one example (which might be as artificial as the upstart example): there are more services included in the code base, like IIRC a syslog server. Can we continue to run different services, or do we de-facto need to switch to systemds implementations of the services? Would upstream be interested to keep the non-systemds implementation of the accompying services working? (Examples for the other init systems are also possible, but I think I can save the time of writing them down. But I would also be interessted in answer for those.) Andi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Andreas Barth a...@ayous.org writes: I would like to ask this question even a bit more general (for all involved init systems): How much would we have vendor lock-in by each init system? Means, is there more software except the pure init system we might need to take if we switch to that init system. Also, what can we expect for the future? How much does the roadmap allow for exchanging other services without changing the init service? And also looking from the other perspective, if we would change the init service later on, which of the nearby services would we loose at the same moment as the init service? I think it's worth noting that there are a couple of angles on this. One is the direction that you note, but there's also the inverse direction: committing to a particular init system may mean that we *can't* run some other piece of software, at least without additional work on our side that may constitute a fork. For example, we're apparently already in that situation with logind. In order to run logind with an init system other than systemd, we will need to fork it (to a greater or lesser extent), possibly in conjunction with Ubuntu and Gentoo. It would be good to know if there are, or will be, other cases like that. We'll want to look at both sides of that question, and try to understand how much work like that is potentially on the horizon with the various choices. For systemd, just one example (which might be as artificial as the upstart example): there are more services included in the code base, like IIRC a syslog server. Can we continue to run different services, or do we de-facto need to switch to systemds implementations of the services? Yes -- I think both your question and my question are two sides of the same coin, and what side we're looking at in any given case is largely determined by whether there *are* any other implementations of that particular service. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
* Russ Allbery (r...@debian.org) [131106 01:21]: We'll want to look at both sides of that question, and try to understand how much work like that is potentially on the horizon with the various choices. Yes, and I hope that all potential init systems add appropriate information to their position page (on both sides of this coin). Andi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, November 6, 2013 01:16, Russ Allbery wrote: We'll want to look at both sides of that question, and try to understand how much work like that is potentially on the horizon with the various choices. Do you? In the past Debian has not shied away from making the choice that it considers technically (or philosophically) the most sound, not the one that implies the least amount of work. The choice will probably be made on just a few high-level factors, such as the chosen approach (dependency vs event based), best user experience and/or licensing. Facts are being gathered about the percentage of code comments, but I it seems unlikely that Debian would reject a solution that it thinks is architecturally superior because of it having fewer code comments. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On 02/11/13 04:11, Russ Allbery wrote: I think the right way to put this is that systemd has significant development resources behind it and is working in fairly close cooperation with both kernel developers and GNOME developers to make available new kernel functionality and to provide implementations of various other interfaces. Multiple implementations are good, but there's potentially an ongoing stream of development to keep up with, and (putting aside arguments about coupling and appropriate ways to integrate that functionality) I believe there is a general agreement that functionality is desirable and will be used by other software that Debian wants to provide. So, one question is whether anyone outside of Canonical is in a position to help with the heavy development (as opposed to the occasional patch). Red Hat is clearly committed to systemd, and there's some convergence towards it among other RPM-based distributions, so long-term resources for systemd don't seem to be in doubt. Canonical is a smaller company, and does not always have the resources to keep projects for which it is the sole upstream vibrant and growing, even when it seems strongly committed to them (c.f. bzr). Regarding the development force behind each project, I find the following comparison at Ohloh very illustrative https://www.ohloh.net/p/compare?project_0=openrcproject_1=upstartproject_2=systemd signature.asc Description: OpenPGP digital signature
Bug#727708: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Carlos Alberto Lopez Perez clo...@igalia.com writes: Regarding the development force behind each project, I find the following comparison at Ohloh very illustrative https://www.ohloh.net/p/compare?project_0=openrcproject_1=upstartproject_2=systemd This isn't really a fair comparison since systemd as a project contains considerably more subsystems than upstart or OpenRC do. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Fri, Nov 1, 2013 at 2:51 PM, Russ Allbery r...@debian.org wrote: Peter Dolding oia...@gmail.com writes: The one property about systemd unit files that is extremely good is there are no multi line commands. Every command is a single line. Yes, that's exactly what I think is obnoxious. I prefer the upstart syntax, which avoids the temptation to write unreadable one-line shell constructs. (Indeed, several have already been posted in recipes in various threads on debian-devel about this.) You can, of course, be disciplined about this when writing systemd helper scripts by always exernalizing the shell script into a separate file, but I really like that upstart lets me inline trivial shell fragments without worrying about that while still keeping them readable. http://www.freedesktop.org/software/systemd/man/systemd.service.html Systemd in fact support the exec lines being written many times. ExecStart= is recommend against being used many due to using XDG desktop processing by somethings. But that is something can could be changed in time. Personally I think it should be changed. http://www.freedesktop.org/software/systemd/man/systemd.service.html ExecStartPre=, ExecStartPost= can be written many times. ExecStartPre= rm somewhere ExecStartPre= touch somewhere That is in fact valid and both will run in order. From the start of unit file to end. In fact lot of cases I see one line entries in systemd and I see bad form. Unless one line has like if or for statements its really bad form inside systemd. Yes systemd supports ; split statements most cases this should not be used in most cases. Its cleaner in the log to see what statement failed the multi line way. Really I would like to see some of those unreadable single line script.I am a little bit suspect they will be people not understanding systemd. So failing to split over many Exec statements for clear readability. Even using upstart you don't stop people from doing unreadable shell script. I personally don't find any of your other arguments persuasive (maybe I'm too used to writing portable /bin/sh scripts), but I do see where you're coming from. I have been the the receiving end of too many not portable shell scripts. My big problem about not being able to set it is what if Ubuntu and Debian decide on a different /bin/sh to each other. No way to set no way to work around this with current upstart. Its not like /bin/sh has not changed in the past. https://wiki.ubuntu.com/DashAsBinSh Has everyone forgot the screw ups that happened when bash was swapped for dash with the old sysvinit. They were workable around under sysvinit by setting the scripts that required bash to bash. So means to change the shell is remembering historic stuff ups. There is already complaints with upstart with canonical controlling the upstream. So we have to be very careful with dependencies. Basically upstart is lacking one key feature. If it not fixed it will come back and bite us. Really I would like to see this fixed before debian takes up upstart if debian takes up upstart at all. Openrc and systemd both can work around the prior issues that have effected sysvinit in history. Replacement we have to be able to beat up like sysvinit and still have it work. SourcePath= option exists in systemd to mark a location of a file that the current file is generated from. I don't know openrc or upstart to say if either of them have this functionality as well. History tells us what is likely to happen again. History is what against taking in upstart in it current form.Upstart in it current form cannot get past the same issues sysvinit got around without major trouble. It should only be a minor fix to add a means to define /bin/sh as a different executable per service. Peter Dolding -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Peter Dolding oia...@gmail.com writes: ExecStartPre=, ExecStartPost= can be written many times. ExecStartPre= rm somewhere ExecStartPre= touch somewhere That really doesn't help, because... In fact lot of cases I see one line entries in systemd and I see bad form. Unless one line has like if or for statements its really bad form inside systemd. ...of this. If you can't write the scripts with proper block structure, it's actually better to just externalize them in a separate file rather than doing something this awful to try to inline them. I don't think you're going to convince me to like this syntax. :) But it's a minor issue. Basically upstart is lacking one key feature. If it not fixed it will come back and bite us. Really I would like to see this fixed before debian takes up upstart if debian takes up upstart at all. I'm afraid there is little chance you will manage to convince me that this is a key feature. I've been writing portable shell scripts for years, and Debian has been dealing with shell portability issues for years. Regardless of what we do with the init system, we will still have to deal with this with maintainer scripts, etc. I do see why you're concerned, but I just don't see this as critical compared to other issues under discussion. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On 10/31/2013 09:51 PM, Russ Allbery wrote: You can, of course, be disciplined about this when writing systemd helper scripts by always exernalizing the shell script into a separate file, but I really like that upstart lets me inline trivial shell fragments without worrying about that while still keeping them readable. I can very well imagine that this is how sysv init scripts started out. Let's make them shell scripts, it's so convenient to be able to place that extra bit of initialization code in there... In other words: the ability to add extra features to upstart jobs by extending them with shell scripts could eventually end up making them just as complex as sysv scripts. I am guilty of having written some rather complicated trickery in upstart shell sections myself, so I know how tempting it is. (In my case, I was mostly working around my still insufficient understanding of the upstart event system to start a job only in some specific conditions. Just coding the condition and stopping the job in its pre-start script (in itself a rather weird concept, but it came from the upstart cookbook) turned out to be quicker and easier, but it certainly wasn't the proper solution...) Best, Nikolaus -- Encrypted emails preferred. PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Hi, Russ Allbery r...@debian.org writes: Steve Langasek vor...@debian.org writes: For the TC decision, what kind of information are you looking for about the plans, beyond the Ubuntu developers expect to need to address this before upgrading from systemd logind 204 and will hold at 204 until a correct solution is known? [...] If Canonical *is* the sole upstream, the upstream future here is troubling to me, particularly given Canonical's current strategic direction towards Unity. To give a specific example of the sort of thing that I'm worried about, suppose that GNOME Shell wants a new piece of functionality that is, on Red Hat, provided via kernel functionality managed by systemd, but Unity has no need for that functionality. Is Canonical going to develop an upstart equivalent in support of GNOME Shell, when it is pushing Unity over GNOME Shell? Maybe this example is very artificial; I know it's not clear what piece of functionality would be required from the init system and surrounding infrastructure that would be required by GNOME Shell and not Unity. But I think it's at least conceivable given different priorities around such things as multiseat, and in any case it provides a concrete example of the sort of scenario I'm worried about. Thanks for finding a nice wording for this. This is also my main concern in the init systemd discussions: upstart might end up playing catch-up, but stay behind in the end. In Lennart's Google+ post referenced earlier in the discussion[1] there was also an example of new functionality in systemd 205+ that I'm not sure Canonical has a business interest in supporting (namely all the nifty stuff that allows Wayland to run nicely without privs is implemented in the newer logind versions). As Canonical has decided to go with Mir instead of Wayland, these features might not get backported to their logind fork (unless they are also required there, I don't know). So having a more concrete roadmap than we might just stay at logind 204 forever from the UpstarT proponents seems very important to me. [1] https://plus.google.com/115547683951727699051/posts/8RmiAQsW9qf Ansgar -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Hi Russ, On Tue, Oct 29, 2013 at 04:16:04PM -0700, Russ Allbery wrote: Therefore, I think it's important for arguments against using systemd to somehow engage directly with the questions about functionality. Either there needs to be an argument that the functionality is not important and can be done without (which raises questions about how one would build GNOME in such an environment), or there needs to be some sort of plan for how equivalent functionality to systemd will be provided. I agree; and the plan from the Upstart side is to ensure that equivalent functionality remains available, but it's premature to try to flesh this plan out in any detail while the interfaces themselves are not yet finalized. For the TC decision, what kind of information are you looking for about the plans, beyond the Ubuntu developers expect to need to address this before upgrading from systemd logind 204 and will hold at 204 until a correct solution is known? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Steve Langasek vor...@debian.org writes: For the TC decision, what kind of information are you looking for about the plans, beyond the Ubuntu developers expect to need to address this before upgrading from systemd logind 204 and will hold at 204 until a correct solution is known? I think the right way to put this is that systemd has significant development resources behind it and is working in fairly close cooperation with both kernel developers and GNOME developers to make available new kernel functionality and to provide implementations of various other interfaces. Multiple implementations are good, but there's potentially an ongoing stream of development to keep up with, and (putting aside arguments about coupling and appropriate ways to integrate that functionality) I believe there is a general agreement that functionality is desirable and will be used by other software that Debian wants to provide. So, one question is whether anyone outside of Canonical is in a position to help with the heavy development (as opposed to the occasional patch). Red Hat is clearly committed to systemd, and there's some convergence towards it among other RPM-based distributions, so long-term resources for systemd don't seem to be in doubt. Canonical is a smaller company, and does not always have the resources to keep projects for which it is the sole upstream vibrant and growing, even when it seems strongly committed to them (c.f. bzr). If Canonical *is* the sole upstream, the upstream future here is troubling to me, particularly given Canonical's current strategic direction towards Unity. To give a specific example of the sort of thing that I'm worried about, suppose that GNOME Shell wants a new piece of functionality that is, on Red Hat, provided via kernel functionality managed by systemd, but Unity has no need for that functionality. Is Canonical going to develop an upstart equivalent in support of GNOME Shell, when it is pushing Unity over GNOME Shell? Maybe this example is very artificial; I know it's not clear what piece of functionality would be required from the init system and surrounding infrastructure that would be required by GNOME Shell and not Unity. But I think it's at least conceivable given different priorities around such things as multiseat, and in any case it provides a concrete example of the sort of scenario I'm worried about. In other words, it's not so much a specific roadmap as it is a roadmap approach and resource committment. Debian, by choosing a default init system, is potentially investing a lot of developer effort on supporting that platform for packaged daemons, somewhat akin to an organization choosing a product on which to base a required piece of internal functionality. I'm therefore asking the same sort of question that I would ask of a vendor whose products we were evaluating for my day job: what guarantees do we have that this product will continue to be developed and supported going forward? The situation with free software is a bit different from a vendor, of course, since Debian could always patch or even pick up development of the software ourselves, but I think we'd all agree that Debian ending up committed to a system service family (since that's really what we're talking about here -- not just the init system itself, but also how the equivalents, forks, or refactorings of logind, D-Bus, cgroups, udev, and so forth will be handled) whose pace of development has slowed to the extent that bzr's has would be a very bad outcome. At least superficially, that outcome looks more likely to me with upstart than it does with systemd, so I'm looking for some reassurance for why the risk of ending up in that situation is low. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, Oct 30, 2013 at 08:41:10PM -0400, Theodore Ts'o wrote: On Mon, Oct 28, 2013 at 06:21:27PM -0700, Russ Allbery wrote: Well, I've said this before, but I think it's worth reiterating. Either upstart or systemd configurations are *radically better* than init scripts on basically every axis. They're more robust, more maintainable, easier for the local administrator to fix and revise, better on package upgrades, support new capabilities, etc. Can you please go in to more detail why you believe this was true? The lsat time I played with Upstart, I saw a lot of policy moved from shell scripts into C code (which I would have to edit and recompile) if I wanted to change things. I'm surprised by this comment. Very little policy is actually encoded in upstart's C code; in fact, the only policy I can think of offhand that is is some basic stuff around filesystems, which, aside from some must-have kernel filesystems without which it can't boot the rest of the system, should be entirely overrideable via /etc/fstab. Perhaps you could expand on what policies you saw a need to change? I also was extremely frustrated with a massive lack of documentation, where at least with shell scripts I could read the scripts to understand what was going on. There's an awful lot of documentation available for upstart, but of course people look for documentation in lots of different ways and we aren't necessarily presenting the documentation where and when we need it. There's comprehensive documentation available at http://upstart.ubuntu.com/cookbook/, but from context it's possible that's not what you were looking for. Aside from adding links to manpages to all of the upstart jobs themselves (which I don't think is reasonable), are there things you think should be done to make the right documentation easy to find? (For starters, what were you trying to find documentation of?) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Op 31-10-13 02:50, Theodore Ts'o schreef: On Wed, Oct 30, 2013 at 06:18:29PM -0700, Russ Allbery wrote: I suspect you and I have a root disagreement over the utility of exposing some of those degrees of freedom to every init script author, but if you have some more specific examples of policy that you wanted to change but couldn't, I'd be interested in examples. It's not necessarily the init script author who might want the degrees of freedom, but the local system administrator. The most basic is the idea that whether you can control (via shell scrpit fragments) whether or not a service should start at all, and what options or environments should be enabled by pasing some file. The fact that we can put that sort of thing in configuration files such as /etc/default/*, for example. This, in my opinion, is one of the worst abominations we currently have in Debian. Whether an init script should run at boot time has no relation whatsoever to whether it should run when the system administrator calls it manually. Yet, with ENABLE= variables in /etc/default, this is related, because the initscript will say I'm disabled, go edit this file if you want to start me, even if you just want to start a daemon just this once manually, for testing. AIUI, both upstart and systemd have configuration options where you can tell the system that this particular service should not start at boot; that will then, however, not affect the result when one manually tries to start the service. I'm not sure that's a very good argument ;-) -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Dear Committee members, I'm not a DD, just a random contributor, and I haven't been actively involved in the init system debate at all, nor do I have any stake in it, though I've followed it with some interest. Now that the question has been referred to the Technical Committee (which seems reasonable given the lack of progress in the discussion so far), it strikes me as somewhat odd that the issue of impartiality/bias hasn't been discussed in the committee to this point. The issue has already been raised on the Debian mailing lists[1] and externally[2][3]. The aphorism Not only must Justice be done; it must also be seen to be done [4], which is oft quoted, not only in judicial proceedings, but also in domestic tribunals (which would probably best describe the committee), is based on the principle that the mere appearance of bias (as opposed to actual bias which can be shown to have influenced a decision) is sufficient to taint the process/decision. I would expect that a discussion that leads up to a decision on the technical issues would at least address the question of bias as well. Please note that I'm *not* trying to start a flame war here, and I'm *not* accusing anyone, but I'm afraid that any discussion (and decision) which was completely silent with regard to bias, once the question has been raised, would appear to be lacking and would undermine public confidence in the decision itself (and that's also the reason I bring this up on a public list rather than in private email). Kind regards, David Härdeman [1] http://lists.debian.org/debian-devel/2013/10/msg00963.html [2] http://slashdot.org/story/13/10/28/1621219/debian-to-replace-sysvinit-switch-to-systemd-or-upstart [3] http://www.phoronix.com/scan.php?page=news_itempx=MTQ5NzQ [4] http://en.wikipedia.org/wiki/R_v_Sussex_Justices,_ex_parte_McCarthy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
* Russ Allbery (r...@debian.org) [131031 02:19]: Theodore Ts'o ty...@mit.edu writes: On Mon, Oct 28, 2013 at 06:21:27PM -0700, Russ Allbery wrote: Well, I've said this before, but I think it's worth reiterating. Either upstart or systemd configurations are *radically better* than init scripts on basically every axis. They're more robust, more maintainable, easier for the local administrator to fix and revise, better on package upgrades, support new capabilities, etc. Can you please go in to more detail why you believe this was true? I think it's painfully obvious if you compare an init script to an upstart or systemd configuration file for a simple daemon like, say, my lbcd package. For simple packages we would be far better of with a simple snippet that is either used by programms like systemd or upstart directly, or converted to a script by dh_initsnippet. One way or another we should as you write below go to an higher level language for init scripts. Note that *Debian*, as a distribution, has a significant interest in standardizing policy around how daemons are managed. It's therefore not a bad thing for the distribution if we have an init system that handles that policy, provided that it encodes the policy that we want. I realize that the local administrator may have other goals, and they should have ways of achieving them, but both systemd and upstart support running SysV init scripts for those cases. Also I think we should make sure that the init system we use doesn't make it unnecessarily hard for local system administrators to change local defaults. Andi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Thu, Oct 31, 2013 at 01:41:53AM -0700, Steve Langasek wrote: I'm surprised by this comment. Very little policy is actually encoded in upstart's C code; in fact, the only policy I can think of offhand that is is some basic stuff around filesystems, which, aside from some must-have kernel filesystems without which it can't boot the rest of the system, should be entirely overrideable via /etc/fstab. Perhaps you could expand on what policies you saw a need to change? The details are a bit fuzzy, because this was a quite a while ago, when Upstart was first introduced into Ubuntu, and it was so frustrating that it was what caused me to abandon Ubuntu and switch back to Debian. The high bit was I couldn't get a particular service to start (it might have been bind, or some such), and I had no idea how to debug the darned thing. With shell scripts, it's possible to insert echo debug 1 $variable /tmp/debug.log to figure out what's going on. With upstart, I had no way of figuring out what was going on, and why it was failing, and the no user-serviceable parts inside was extremely frusrtating. I'm sure part of the problem was lack of documentation. That seems to be a common theme with many of these higher level language systems. They may be powerful if you know the magic XML file to edit (in the case of policy kit), but it took me several hours before I figured out even something as simple as say 'yes' to for all authorization questions, which is how I still run to this day, because (a) the default of prompting for the root password in popup windows all the time was too painful, and (b) trying to figure out how to XML language, and all of the triggeers, etc., was ***far*** too painful. One of the nice things about shell scripts is that they are far more self-documenting, and easier to debug, than XML and other 'higher-level' configuration files (at least for this dumb kernel hacker :-). So hopefully that is something the technical committee will take into account --- how well things are documented, both in terms of a comprehensive reference manual, and a tutorial that helps people with common things that system administrators might want to do. The docuementation you pointed to at http://upstart.ubuntu.com/cookbook/ is something I wish I had access to when I first was forced to use Upstart; maybe if Upstart was as polished back then, I might not have given up on Ubuntu in disgust. Regards, - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
* Theodore Ts'o: The most basic is the idea that whether you can control (via shell scrpit fragments) whether or not a service should start at all, and what options or environments should be enabled by pasing some file. Curiously, a lot of system administrators do not do this correctly using sysvinit, causing system daemons to start unexpectedly after installing package updates. I hope that a new init system will finally allow us to have something like chkconfig (not the best name in the world, I admit) that works reliably. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
David Härdeman writes (Bug#727708: tech-ctte: Decide which init system to default to in Debian.): I'm not a DD, just a random contributor, and I haven't been actively involved in the init system debate at all, nor do I have any stake in it, though I've followed it with some interest. Now that the question has been referred to the Technical Committee (which seems reasonable given the lack of progress in the discussion so far), it strikes me as somewhat odd that the issue of impartiality/bias hasn't been discussed in the committee to this point. Several of the messages on debian-devel in the init system GR proposal thread on -devel have discussed this. Please read that thread, which has comments from a number of TC members on this question. I don't think there would be any value in formally addressing this as part of the TC resolution on the init system question. If nothing else, it would be rather circular to have people voting on whether to disqualify each other. There is a clear constitutionally defined process for excluding some TC members from voting on some matters, which does not apply in the current situation. If your concern is just that those messages from TC members aren't [discussion] in the committee as you put it, I think simply repeating the earlier messages, as postings to this bug, doesn't seem to have much value. But just for reference here are the urls I found of the contributions from TC members and (ex-)DPLs on the subject of bias: http://lists.debian.org/debian-devel/2013/10/msg00692.html http://lists.debian.org/debian-devel/2013/10/msg00747.html http://lists.debian.org/debian-devel/2013/10/msg00777.html http://lists.debian.org/debian-devel/2013/10/msg00699.html http://lists.debian.org/debian-devel/2013/10/msg00702.html http://lists.debian.org/debian-devel/2013/10/msg00818.html http://lists.debian.org/debian-devel/2013/10/msg00946.html http://lists.debian.org/debian-devel/2013/10/msg01014.html And generally on democracy vs technogracy (if I may put it like that): http://lists.debian.org/debian-devel/2013/10/msg00996.html http://lists.debian.org/debian-devel/2013/10/msg00821.html http://lists.debian.org/debian-devel/2013/10/msg00830.html Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Thu, Oct 31, 2013 at 07:20:12AM -0400, Theodore Ts'o wrote: On Thu, Oct 31, 2013 at 01:41:53AM -0700, Steve Langasek wrote: I'm surprised by this comment. Very little policy is actually encoded in upstart's C code; in fact, the only policy I can think of offhand that is is some basic stuff around filesystems, which, aside from some must-have kernel filesystems without which it can't boot the rest of the system, should be entirely overrideable via /etc/fstab. Perhaps you could expand on what policies you saw a need to change? The details are a bit fuzzy, because this was a quite a while ago, when Upstart was first introduced into Ubuntu, and it was so frustrating that it was what caused me to abandon Ubuntu and switch back to Debian. The high bit was I couldn't get a particular service to start (it might have been bind, or some such), and I had no idea how to debug the darned thing. With shell scripts, it's possible to insert echo debug 1 $variable /tmp/debug.log to figure out what's going on. With upstart, I had no way of figuring out what was going on, and why it was failing, and the no user-serviceable parts inside was extremely frusrtating. Ah. Sounds like you may have been hit by upstart's lack of logging support for jobs at the time. Upstart has supported logging of all output from jobs (stderr,stdout) since 1.5, which was included in 12.04 LTS. This was added precisely because of that sort of frustrating experience you describe - an experience that was shared not only by administrators, but also Ubuntu developers trying to debug remaining corner cases in the init system integration itself. So on 12.04 and later, you just look at /var/log/upstart/$job.log to get the debugging info you're looking for. And if you need to debug upstart's own state, you can boot with --verbose (or if necessary, --debug) to get useful information dumped to kmsg - or turn this on with 'initctl log-priority info' after boot. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Russ Allbery (r...@debian.org) In general, upstart's integration with arbitrary actions in shell fragments is considerably better than systemd's, at least based on the documentation I've read. upstart feels like it provides more useful flexibility This is in fact a extremely bad idea how it is implemented in upstart. ExecStartPre=, ExecStartPost=,ExecReload= Kind of model in systemd is better. 1 the upstart method you have to be watching the version of shell that the scripts in the init system are using. So we are back to the sysvinit problem of update bash and hello stack of stuff don't start any more. ExecStartPre=/bin/bash somescript.sh Think lets say I am a php or python developer. Upstream. Why do they have to code there init items in bash or some other shell script. The one property about systemd unit files that is extremely good is there are no multi line commands. Every command is a single line. script # do some stuff if [ ... ]; then ... fi end script This pattern in upstart is in fact highly bad. script # do some stuff if [ ... ]; then ... fi end script post-stop script # do some stuff if [ ... ]; then ... fi end script Think about this case. While editing you by mistake delete something. script # do some stuff if [ ... ]; then ... fi post-stop script # do some stuff if [ ... ]; then ... fi end script See what missing. Now your service start does something completely you wrong. --script instead gives shell script code that will be executed using /bin/sh.-- Exactly what says that /bin/sh will be bash ash dash. Basically you need to be able to declare interpreter of script. Under sysvinit you can declare interpreter of script. systemd and openrc you can also declare interpreter of script. upstart has it hard coded. This hard coded bit is bad. systemd forces you to use many small shell files. With systemd you delete a line you take out a complete command. You cannot mutate the command todo something strange. We are in a modern age of Languages there is no point taking in a init system that forces the usage of one scripting interpreter that can change and bring the system down. Peter Dolding -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Peter Dolding oia...@gmail.com writes: The one property about systemd unit files that is extremely good is there are no multi line commands. Every command is a single line. Yes, that's exactly what I think is obnoxious. I prefer the upstart syntax, which avoids the temptation to write unreadable one-line shell constructs. (Indeed, several have already been posted in recipes in various threads on debian-devel about this.) You can, of course, be disciplined about this when writing systemd helper scripts by always exernalizing the shell script into a separate file, but I really like that upstart lets me inline trivial shell fragments without worrying about that while still keeping them readable. I personally don't find any of your other arguments persuasive (maybe I'm too used to writing portable /bin/sh scripts), but I do see where you're coming from. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Op 29-10-13 09:26, Steve Langasek schreef: I see no reason that, if upstart were chosen as the default, porters could not use it for our non-Linux ports as well. With some work, sure. This is a much better outcome across our distribution as a whole than to require developers to continue maintaining init scripts just for our non-Linux ports. I did not say require, I said encourage. I agree that it's unreasonable to expect developers to maintain init scripts that they themselves do not use in addition to init configuration for whatever init system we end up with; and I do agree that it should be fair game for people to drop the init script from their package. However, there are some advantages to be had in continue to ship init scripts (while I can see no downsides, apart from the fact that they need to be written), and in that light it can make sense for us to encourage people to continue shipping init scripts. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ signature.asc Description: OpenPGP digital signature
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Hi Steve, On Tue, Oct 29, 2013 at 09:31:37AM -0700, Steve Langasek wrote: On Tue, Oct 29, 2013 at 10:22:54AM +0100, Helmut Grohne wrote: Having read the parts of the ctte bug, it feels odd to preclude the option of supporting multiple init systems from discussion or consideration. If Debian is to support only one init system and that one init system is systemd, then given my above analysis it will be very hard for non-Linux ports to catch up. I argue that in this case we should consider dropping support for non-Linux ports. So if we really are considering such an outcome, why not consider the outcome of supporting multiple init systems (but maybe only one per architecture)? While other members of the TC may wish to consider this option, I've ruled it out myself because we would lose most of the benefits of switching away from sysvinit and instead accrue significant maintenance costs to individual developers who would then have to support both init systems in their packages. What makes switching init systems worth doing is being able to *simplify* the interfaces between the init system and the services. Continuing to support different init systems across different architectures would add complexity instead. That's a pretty bleak outcome. I fully agree with your reasoning. Yet, I see that the options * drop support for non-Linux ports and * maintain some support for an alternate init system are similarly painful. I see neither of them a desirable, but if we really consider one of them, I'd ask for the other one to be considered and evaluated as well. Most participants in this thread appear to agree that the sysvinit *interface* for services (shell scripts) is suboptimal. We are currently mostly arguing about implementations, because each proposed interface has only one implementation. It might make sense to consider a subset of the interface that one implementation provides as our standard and provide a degraded experience to that interface on non-Linux ports. For example, if systemd were to be the init system of choice, it could be required to provide an init script for services with Type=notify. The interfaces of all init systems (except sysvinit, but are we really considering that one?) still are somewhat in flux, so this is the point where we can still influence and shape them. dream Imagine a world where upstart and systemd would use the same syntax (structure) but implement different and somewhat overlapping aspects. Maybe 50% of the daemons would work with either of them without needing changes. wakeup/ But now we call it exec here and ExecStart there, export here and Environment there, and chdir here and WorkingDirectory there. Bummer. /dream Oh wait, I am talking to one of the guys who can actually fix this. :) This would become radically easier if gnome were to become Architecture: linux-any. GNOME may be the trigger for this being raised to the TC, but it's not the core question that we need to address. Even though I did mention gnome over there, the argument is not restricted to gnome in any way. It can be applied to any other package not deemed worthy to support on non-Linux ports (and I should have made this explicit). Furthering this thought leads to turning non-Linux ports into derivatives as presented by others in this thread. I argue that a resolution of this bug needs to answer: What is going to happen with non-Linux ports? Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Op 30-10-13 00:16, Russ Allbery schreef: Carlos Alberto Lopez Perez clo...@igalia.com writes: On 28/10/13 20:14, Christoph Anton Mitterer wrote: For those who haven't seen it, Lennart has posted some of his comments about all this on G+: https://plus.google.com/u/0/115547683951727699051/posts/8RmiAQsW9qf And here is the reply from Gentoo developer Patrick Lauer: http://gentooexperimental.org/~patrick/weblog/archives/2013-10.html#e2013-10-29T13_39_32.txt This, sadly, was not particularly useful or interesting. I disagree. His point isn't argued very well (seems more like a rant than a discussion), but it's there. As near as I can tell, the core content was that he doesn't think cgroup management is particularly difficult (fine, but I don't think that was the point; the point, instead, was that it's important to have a single arbitrator, which if true poses specific technical challenges) and he believes that the components to systemd would be easy to implement as separate daemons if they were properly documented. I'm one of those people who thinks that nearly everything in Linux is horribly underdocumented, so I'm not going to argue with that point, but it's not a very useful statement from a practical viewpoint. systemd offers specific pieces of integrated functionality. By and large, no one seems to question that the operations enabled by that functionality are useful (although there is some debate over how useful). GNOME is not depending on systemd out of some nefarious plot. It's depending on systemd because GNOME wants to use those pieces of functionality systemd provides. Therefore, I think it's important for arguments against using systemd to somehow engage directly with the questions about functionality. Either there needs to be an argument that the functionality is not important and can be done without (which raises questions about how one would build GNOME in such an environment), or there needs to be some sort of plan for how equivalent functionality to systemd will be provided. From the above link: The only thing stopping me from reimplementing that functionality is that I have no idea what it's supposed to *do* ... and I don't enjoy reading through all of systemd to find out. (about logind) While I agree with your point, it's pretty difficult to reimplement the interesting parts of systemd in other implementations of pid1 if whoever wrote the interesting parts does not document it, does not say what it's supposed to do, does not want to accept patches for things they're not interested in, and is by and large uninterested in anyone who prefers to use something else than whatever their kool-aid is. I'll grant that maybe logind provides interesting functionality which other projects might want to depend on, and that there's nothing wrong with that. The problem, however, is that the functionality is not defined: if I want to provide an alternative pid1 implementation, then the specifications are clear, and I should Just Do It (not that I'm going to muddle the waters even more by doing so, but you understand the point). If I want to provide an alternative implementation of logind, however, then the only spec out there is the logind code, which might change one day to the next just because the logind developer feels like it. This wouldn't be much of a problem if I could just take logind (and udev, and dbus, and more things) out of the systemd source tree and use it without systemd, should I want to. But you can't; the problem is that the upstream of all these projects is by and large uninterested in doing so, and also does not seem to support other people who are, and at least the Debian maintainers of systemd have gone on record as saying that they won't guarantee this would remain possible (if the systemd developers would be willing to do so, then I suppose that could ameliorate some concerns). The obvious solution would be that the world changes to systemd because what, essentially, amounts to a level of sabotage by the systemd developers of things that aren't systemd. If systemd is in fact the best choice out there, of which I'm not convinced at this point in time, then I wouldn't mind that (much). But I'd like us to do so for the right technical reasons, not just because it means we make our lives easier in not having to fight with a stubborn upstream all the time. We could, after all, fork, like we have done on other occasions of stubborn upstreams. Given all of the above, I would even argue that perhaps Debian should *not* adopt systemd as init system, out of principle; if we were to do so, then almost all the major distributions would be using systemd (with the sole exception of Ubuntu; I expect redhat to switch to systemd for their next EL version), which could go a long way to making it part of what it means to be running Linux. At that point, any competing innovative implementations would simply face an almost insurmountable heap of
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, Oct 30, 2013 at 03:10:16PM +0100, Helmut Grohne wrote: The interfaces of all init systems (except sysvinit, but are we really considering that one?) still are somewhat in flux, so this is the point where we can still influence and shape them. dream Imagine a world where upstart and systemd would use the same syntax (structure) but implement different and somewhat overlapping aspects. Maybe 50% of the daemons would work with either of them without needing changes. wakeup/ But now we call it exec here and ExecStart there, export here and Environment there, and chdir here and WorkingDirectory there. Bummer. /dream Hi Helmut, exec vs. ExecStart= and export vs. Environment= is easy. Anyone can whip up a sed script to convert between those. The question is how to deal with more advanced options. Let's say that I have a systemd unit with CapabilityBoundingSet=CAP_SYS_TIME# limit the capability bounding set to CAP_SYS_TIME PrivateTmp=yes# run with unshared /tmp InaccessibleDirectories=/home # run without access to /home WatchdogSec=60# consider the service dead if it hasn't pinged the # manager for in the last minute Restart=on-failure# restart service on watchdog failure or unclean exit This isn't a question of syntax, it's a question of significant functionality in the manager. I think that sharing service descriptions between disparate init managers is infeasible, unless we forbid the use of anything but the basic features. Another thing that is turning into a significant gap is socket activation. In systemd, socket activation allows the service to receive multiple open sockets (e.g. ports 80 and 443 for an httpd server). Socket activation of daemons is cool: - it is very easy to write such a daemon, it must just do accept(), read() and write() - resource efficent because of activation on demand - great for running unpriviledged, since the daemon only does accept(), read() and write() - we get rid of a lot of inter-daemon ordering dependencies. With the recent addition of (experimental) systemd-socket-proxyd[1], even daemons like apache which do not support socket activation internally can be launched on demand by wrapping them with a helper. Socket activation is a great technique, bound to be used more. Achieving the same functionality with init scripts is very hard, and AFAIK, upstart doesn't support socket activation with more than one socket. [1] http://www.freedesktop.org/software/systemd/man/systemd-socket-proxyd.html Oh wait, I am talking to one of the guys who can actually fix this. :) Zbyszek -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
]] Wouter Verhelst Yes, absense of documentation is common on Unix and Linux systems; but no, I do not think that this is okay, or that we should in any way encourage that sort of thing. By absense of documentation, are you referring to the almost 10% of the source base that are comments or the 15% that is DocBook XML based documentation? (Almost 14kLOC and almost 36kLOX, respectively.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
2013/10/30 Helmut Grohne hel...@subdivi.de: What is going to happen with non-Linux ports? Debian is not Debian without non-Linux ports. As for me, I think it is not very hard to maintain diffrent init systems for different kernels. Especially if Debian GNU/Linux get rid of sysvinit: writing systemd or upstrart services is simple (as well as SMF). Just one example from OSDyson (lighttpd): 1. dh-smf: http://cgit.osdyson.org/dh-smf.git 2. lighttpd depends on dh-smf for illumos kernel: http://cgit.osdyson.org/lighttpd.git/tree/debian/control#n10 3. No changes in d/rules (!): http://cgit.osdyson.org/lighttpd.git/tree/debian/rules 4. DH automatically peeks up dh_smf: http://cgit.osdyson.org/debhelper.git/tree/dh?id=3769023faf4758f944e710480c43cda220821690#n524 5. dh_smf looks into this directory: http://cgit.osdyson.org/lighttpd.git/tree/debian/lighttpd.smf 6. dh_installinit is no-op on Dyson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, Oct 30, 2013 at 04:29:24PM +0100, Wouter Verhelst wrote: While I agree with your point, it's pretty difficult to reimplement the interesting parts of systemd in other implementations of pid1 if whoever wrote the interesting parts does not document it, does not say what it's supposed to do, does not want to accept patches for things they're not interested in, and is by and large uninterested in anyone who prefers to use something else than whatever their kool-aid is. I'll grant that maybe logind provides interesting functionality which other projects might want to depend on, and that there's nothing wrong with that. The problem, however, is that the functionality is not defined: if I want to provide an alternative pid1 implementation, then the specifications are clear, and I should Just Do It (not that I'm going to muddle the waters even more by doing so, but you understand the point). If I want to provide an alternative implementation of logind, however, then the only spec out there is the logind code, which might change one day to the next just because the logind developer feels like it. Are there things missing from http://www.freedesktop.org/wiki/Software/systemd/logind/ from an implementor's perspective? For my part I regard this as a tempest in a teapot. Lennart has been effective at making people worry that not using systemd is too dangerous to consider. But Ubuntu has done just fine with splitting the dbus services off of init up through systemd 204, and while we know there are some big issues on the horizon with the cgroup manager and kdbus questions, these are not settled matters across the Free Software ecosystem. There are lots of other people besides the upstart and Debian non-Linux-port community who have reservations about the systemd gravity well, including anyone using cgroups today on top of lxc or using the Google tools. So I'm not going to give anyone a roadmap today for how these capabilities will be made available in a non-systemd environment, because a lot of this has to do with decisions that need to be made in the relevant wider technical communities and have nothing to do with the init system per se. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Theodore Ts'o ty...@mit.edu writes: On Mon, Oct 28, 2013 at 06:21:27PM -0700, Russ Allbery wrote: Well, I've said this before, but I think it's worth reiterating. Either upstart or systemd configurations are *radically better* than init scripts on basically every axis. They're more robust, more maintainable, easier for the local administrator to fix and revise, better on package upgrades, support new capabilities, etc. Can you please go in to more detail why you believe this was true? I think it's painfully obvious if you compare an init script to an upstart or systemd configuration file for a simple daemon like, say, my lbcd package. For those who don't agree, please try the exercise of writing systemd and upstart configuration files for some typical daemon package and look at the number of lines of code in both and the behavior in edge cases (daemon already running, daemon running but with no PID file because something else deleted it, daemon part of a dependency chain that shouldn't fire until the daemon is actually listening to the network, correct exit status for various failure conditions, stopping the daemon when there is a user process with the same name as the daemon also running, and the other cases Policy says one must handle). Now compare the length of time it took you to make an init script correctly handle all those cases versus how long it took to write the upstart or systemd configuration. (Note that I have found, IIRC, two different edge-case bugs in /etc/init.d/skeleton while working on Debian, so even if you start from that file, which is only applicable to a relatively narrow range of circumstances, you can still fail edge cases.) I have prior experience here both as Policy editor dealing with the Policy sections related to init scripts and as a Lintian maintainer dealing with Lintian checks for init scripts. Both of those experiences were, shall we say, convincing. Another way to look at this is that both upstart and systemd provide a high-level programming language for writing init scripts. Not only does it implement a higher level of abstraction, it's also better-suited to the problem space because it's declarative rather than imperative. (systemd somewhat more so than upstart, although that makes it somewhat more awkward to use in cases where you really need to run some shell script on various actions.) As with any move to a higher-level programming interface, there are drawbacks; if you really want to do your own memory management, you don't get to any more. And as with most moves to a higher-level programming interface well-suited to the task at hand, the advantages outweigh the drawbacks. (And in this case, I'd go a step farther and say that I think most of the drawbacks people cite around loss of flexibility are at least arguably benefits. The world would be a better place with fewer init scripts doing weird and unexpected things to paper over bugs better fixed somewhere else.) This really shouldn't be a particularly controversial stance. Ever since Solaris SMF, various UNIX implementations have been abandoning traditional init scripts for exactly these reasons. I really don't think that all those completely independent technical teams, which at this point include most major Linux distributions (counting OpenRC as another higher-level implementation), are all wrong. This is an area of personal interest of mine. I followed daemontools development back when Dan Bernstein was tackling this same basic problem in his distinctively radical way, and have subsequently been paying at least casual attention to various different daemon management facilities ever since. A lot of people have tried to solve various aspects of the problem that init scripts are actually horrible at what they do, and the solutions have been slowly improving and becoming more and more robust. AFS attempted to solve this problem all the way back in the 1980s. Even back then, it was obvious that init scripts were insufficiently powerful to manage production services properly, hence the whole bosserver system that persists in OpenAFS to this day and which, coming from MIT, you may be familiar with. Not that I would advocate use of bosserver for anything other than AFS these days, as there are now lots of newer technologies that have surpassed it, although (relatively) secure network management of services is still an interesting feature. The lsat time I played with Upstart, I saw a lot of policy moved from shell scripts into C code (which I would have to edit and recompile) if I wanted to change things. I also was extremely frustrated with a massive lack of documentation, where at least with shell scripts I could read the scripts to understand what was going on. I suspect you and I have a root disagreement over the utility of exposing some of those degrees of freedom to every init script author, but if you have some more specific examples of policy that you wanted to change
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Mon, Oct 28, 2013 at 06:21:27PM -0700, Russ Allbery wrote: Well, I've said this before, but I think it's worth reiterating. Either upstart or systemd configurations are *radically better* than init scripts on basically every axis. They're more robust, more maintainable, easier for the local administrator to fix and revise, better on package upgrades, support new capabilities, etc. Can you please go in to more detail why you believe this was true? The lsat time I played with Upstart, I saw a lot of policy moved from shell scripts into C code (which I would have to edit and recompile) if I wanted to change things. I also was extremely frustrated with a massive lack of documentation, where at least with shell scripts I could read the scripts to understand what was going on. Maybe things have changed, but that was my impression with both Systemd and Upstart (and policykit, and consolekit, etc. all of which has caused me no end of frustration). - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, Oct 30, 2013 at 06:18:29PM -0700, Russ Allbery wrote: I suspect you and I have a root disagreement over the utility of exposing some of those degrees of freedom to every init script author, but if you have some more specific examples of policy that you wanted to change but couldn't, I'd be interested in examples. It's not necessarily the init script author who might want the degrees of freedom, but the local system administrator. The most basic is the idea that whether you can control (via shell scrpit fragments) whether or not a service should start at all, and what options or environments should be enabled by pasing some file. The fact that we can put that sort of thing in configuration files such as /etc/default/*, for example. Yes, yes, you can do this via if you use system V init scripts scripts in backwards compatibility mode, but you've argued that we should be moving briskly away from that. In which case system administrators will need to hand-edit the services files by hand, which will no doubt increase the chances of conflicts at package upgrade time, compared to if the configuration options were isolated away in files such as /etc/default/rsync (for example). I realize that the local administrator may have other goals, and they should have ways of achieving them, but both systemd and upstart support running SysV init scripts for those cases. If the package does not ship a SysV init script (which is your ideal long-term outcome), that may not be very practical option for a system adminsitrator who may need to recreate a SysV init script, especially if the service file is rather complicated, or is using some of the more advanced feature of systemd/upstart. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Theodore Ts'o ty...@mit.edu writes: On Wed, Oct 30, 2013 at 06:18:29PM -0700, Russ Allbery wrote: I suspect you and I have a root disagreement over the utility of exposing some of those degrees of freedom to every init script author, but if you have some more specific examples of policy that you wanted to change but couldn't, I'd be interested in examples. It's not necessarily the init script author who might want the degrees of freedom, but the local system administrator. The most basic is the idea that whether you can control (via shell scrpit fragments) whether or not a service should start at all, and what options or environments should be enabled by pasing some file. The fact that we can put that sort of thing in configuration files such as /etc/default/*, for example. Yes, yes, you can do this via if you use system V init scripts scripts in backwards compatibility mode, but you've argued that we should be moving briskly away from that. In which case system administrators will need to hand-edit the services files by hand, which will no doubt increase the chances of conflicts at package upgrade time, compared to if the configuration options were isolated away in files such as /etc/default/rsync (for example). Ah, I see. However, I do think this is mostly a solvable problem. We should provide meaningful flexibility in our init script configuration, which may include providing hooks so that local administrators have a place to put that local policy. You're right that some of this functionality will probably be lost in the initial conversion to something other than init scripts, but I would consider that to (usually) be a bug, and as people report problems, we can be sure it's added back in after understanding the issues involved. Yes, this may be a bit annoying for people in the short term, but I do think it gets us to a better place in the long run by way of supporting clean and documented interfaces for those policy settings. It is true that currently init scripts are full-blown programs, allowing anyone who is capable of programming in that language to make arbitrary policy modifications. We lose that by switching to a higher-level language, and only policy decisions anticipated by that language will be easily implemented. More complex policy decisions would have to be handled at a higher level, via selectively creating or removing the configuration files. It's certainly a disruptive change. I'm not convinced it's a net negative, but it will depend on how strong the available hooks are and what types of policy the local administrator wants to easily change. I do think that being able to treat the init scripts as real configuration files will make maintaining such local policy easier than it is currently. The prospect of modifying init scripts was already dire enough that we pushed most meaningful configuration into /etc/default instead of asking that people change the complicated init scripts and then handle merges on package upgrades. *Most* local changes are fairly simple, and would only require small and mergable changes to upstart configuration files, and small overrides to systemd files. I personally like upstart's model a little better, but systemd's model of /etc overrides /lib is, I think, workable as long as people remember to change only the setting they want and then include the original instead of making copies of the whole configuration. (That being said, I'm worried about how the systemd model handles the common case of wanting to change the command-line arguments to a daemon, and then having the package also change the command-line arguments in some orthogonal way.) If the package does not ship a SysV init script (which is your ideal long-term outcome), that may not be very practical option for a system adminsitrator who may need to recreate a SysV init script, especially if the service file is rather complicated, or is using some of the more advanced feature of systemd/upstart. You can do quite a bit with the hooks that are part of the specification of both types of files. For example, logic that you may add to control whether the service should start at all can be implemented by adding a pre-start stanza to the upstart configuration. This particular action appears to be harder to do in systemd, which doesn't, at least from the documentation that I've found, support running arbitrary shell code to determine whether to start a unit, but there are a bunch of other possible built-in checks. I suppose one could also change the command started to wrap it and put the check there, although that feels quite ugly. In general, upstart's integration with arbitrary actions in shell fragments is considerably better than systemd's, at least based on the documentation I've read. upstart feels like it provides more useful flexibility. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, Oct 30, 2013 at 09:50:53PM -0400, Theodore Ts'o wrote: On Wed, Oct 30, 2013 at 06:18:29PM -0700, Russ Allbery wrote: I suspect you and I have a root disagreement over the utility of exposing some of those degrees of freedom to every init script author, but if you have some more specific examples of policy that you wanted to change but couldn't, I'd be interested in examples. It's not necessarily the init script author who might want the degrees of freedom, but the local system administrator. The most basic is the idea that whether you can control (via shell scrpit fragments) whether or not a service should start at all, and what options or environments should be enabled by pasing some file. The fact that we can put that sort of thing in configuration files such as /etc/default/*, for example. Both systemd and upstart support this well enough. With systemd you can say EnvironmentFile=/etc/default/whatever and use the variables in ExecStart=/path/to/prog $VAR1 $VAR2. This is usually discouraged, not because it doesn't work, but because it uses two files to provide very little value. In majority of cases it turns out that the settings in /etc/default either can't be changed in an useful way, or are better read by the daemon itself from a different configuration file. But if you want this, then it's there. If the settings are to complicated for the declarative style, you can always use an helper shell script to launch the daemon. Again, discouraged, but certainly supported. Yes, yes, you can do this via if you use system V init scripts scripts in backwards compatibility mode, but you've argued that we should be moving briskly away from that. In which case system administrators will need to hand-edit the services files by hand, which will no doubt increase the chances of conflicts at package upgrade time, compared to if the configuration options were isolated away in files such as /etc/default/rsync (for example). Actually this doesn't happen that often. Typical systemd service file has 1-3 lines of documentation, 1+ lines of ExecStart stuff, and a few additional settings. They are mostly orthogonal, so you just override the one you need. Probably most common case is to override ExecStart=, done by adding the file like /etc/systemd/system/myservice.d/custom-start.conf which only overrides ExecStart. Nice and simple, no conflicts on upgrade. I realize that the local administrator may have other goals, and they should have ways of achieving them, but both systemd and upstart support running SysV init scripts for those cases. If the package does not ship a SysV init script (which is your ideal long-term outcome), that may not be very practical option for a system adminsitrator who may need to recreate a SysV init script, especially if the service file is rather complicated, or is using some of the more advanced feature of systemd/upstart. Why would you recreate the whole script? Let the init manager take care of starting and stopping and supervising, and only do the custom stuff in the script. Then it should be just a few lines. Zbyszek -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On 10/31/2013 02:50 AM, Theodore Ts'o wrote: The most basic is the idea that whether you can control (via shell scrpit fragments) whether or not a service should start at all, and what options or environments should be enabled by pasing some file. The fact that we can put that sort of thing in configuration files such as /etc/default/*, for example. Yes, yes, you can do this via if you use system V init scripts scripts in backwards compatibility mode, but you've argued that we should be moving briskly away from that. In which case system administrators will need to hand-edit the services files by hand, which will no doubt increase the chances of conflicts at package upgrade time, compared to if the configuration options were isolated away in files such as /etc/default/rsync (for example). Ted, I'm sorry, but it's very obvious you have no clue how systemd is supposed to be used. First of all, systemd - like udevd - supports two places where to place systemd service files. One is located below /usr/lib/systemd which is the directory where service files provided by the package are placed, and one is /etc/systemd where your own, custom service files are located. If systemd finds an appropriate service file in /etc/systemd it will ignore the appropriate service file in /usr/lib/systemd, always. So there is never a problem with service files being overwritten during an upgrade like you describe. The same holds true, btw, for udevd with it's rules files which are located in /lib/udev/rules.d and /etc/rules.d respectively. And everything that you might want change in the configuration of a service can be done by editing the service file and this in a much easier and consistent way. Editing a file in the .ini file format is a no-brainer which, in the worst mistake case, will probably lead to an error message from the daemon or systemd while messed up custom code may end up rendering your whole system unusable if you are smart enough to mess up an rm command. Just have a look at this wonderful bug in upstart [1]. If the package does not ship a SysV init script (which is your ideal long-term outcome), that may not be very practical option for a system adminsitrator who may need to recreate a SysV init script, especially if the service file is rather complicated, or is using some of the more advanced feature of systemd/upstart. No, System V Init scripts are not ideal on the long-term outcome since they are highly distribution-specific, error-prone and annoying to maintain. We have had tons of bugs in the bug tracker because of broken init scripts, like this one [2]. I don't understand why anyone would think that having to write a small piece of code to start another program is a sensible and good design, especially when this is done for dozens of programs (= daemons) in very much the same way. It absolutely makes sense to encode the logic to start and control a daemon through a single piece of C code rather than writing more-or-less the same bash script for every single daemon on your machine. Adrian [1] https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/557177 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668890 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
]] Russ Allbery (Cleaned up the Cc line somewhat) You can do quite a bit with the hooks that are part of the specification of both types of files. For example, logic that you may add to control whether the service should start at all can be implemented by adding a pre-start stanza to the upstart configuration. ExecStartPre=/bin/false will make the service be considered failed. The ExecStartPre line can of course be an executable that implements more checking or logic. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On 28/10/13 at 18:21 -0700, Russ Allbery wrote: Wouter Verhelst wou...@master.debian.org writes: Also, since all alternative init implementations under consideration do support sysv-style init scripts, I think that whatever init system we (well, you, the TC) end up choosing, the requirement in policy should be that a package should ship either some init configuration for the default init system, or a sysv-style init script. In fact, I think we should continue to encourage the latter, in cases where it does make sense (e.g., when a given daemon doesn't have any init system specific features that could be enabled), since that will help our non-Linux ports without significantly impacting performance of the new init system. Well, I've said this before, but I think it's worth reiterating. Either upstart or systemd configurations are *radically better* than init scripts on basically every axis. They're more robust, more maintainable, easier for the local administrator to fix and revise, better on package upgrades, support new capabilities, etc. I believe that much of the benefit for adopting a new init system is dropping init scripts and using a much better configuration language. If we're not going to take advantage of that benefit, it calls into question whether we should change init systems at all. Note that there are two options that could be explored, to remove the need to maintain init scripts: - generating sysvinit scripts from systemd service files or upstart job files at build time (this was explored, for systemd service files, during a GSoC project in 2012, without much success) - having a .service/job files runtime interpreter (that sounds quite promising) Even if it cannot be used for all services, using such as interpreter could maybe provide an easy support path for sysvinit on non-linux platforms for a large number of simple services. There's a subthread about that starting at https://lists.debian.org/debian-devel/2013/05/msg01309.html Helmut Grohne (Cced) did most of the work on analyzing those possibilities. Lucas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Mon, Oct 28, 2013 at 05:22:14PM +, Wouter Verhelst wrote: On Sat, Oct 26, 2013 at 11:20:21AM -0700, Steve Langasek wrote: Right. Whichever init system we pick, I do expect the next step to be to drop the requirement to maintain sysvinit backwards-compatibility; While I'm not sure from your mail whether you meant to suggest otherwise, I do think that whatever we decide for jessie, we should continue the requirement of sysvinit compatibility for at least one release after we ship with some more modern init system. The point was not about whether the init system would maintain backwards-compatibility with sysvinit, which is straightforward to conserve for some time, but whether individual packages providing services need to maintain compatibility with sysvinit or if they can adopt the native service definition format. If we adopt a different init system as the default in jessie, then certainly by jessie+1 at the latest, maintainers should feel free to use the native format exclusively and not feel required to maintain compatibility with sysvinit. Also, since all alternative init implementations under consideration do support sysv-style init scripts, I think that whatever init system we (well, you, the TC) end up choosing, the requirement in policy should be that a package should ship either some init configuration for the default init system, or a sysv-style init script. In fact, I think we should continue to encourage the latter, in cases where it does make sense (e.g., when a given daemon doesn't have any init system specific features that could be enabled), since that will help our non-Linux ports without significantly impacting performance of the new init system. I see no reason that, if upstart were chosen as the default, porters could not use it for our non-Linux ports as well. This is a much better outcome across our distribution as a whole than to require developers to continue maintaining init scripts just for our non-Linux ports. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
TL;DR: Thoughts on using systemd .service files on non-Linux ports. On Tue, Oct 29, 2013 at 09:20:10AM +0100, Lucas Nussbaum wrote: Note that there are two options that could be explored, to remove the need to maintain init scripts: - generating sysvinit scripts from systemd service files or upstart job files at build time (this was explored, for systemd service files, during a GSoC project in 2012, without much success) - having a .service/job files runtime interpreter (that sounds quite promising) Even if it cannot be used for all services, using such as interpreter could maybe provide an easy support path for sysvinit on non-linux platforms for a large number of simple services. There's a subthread about that starting at https://lists.debian.org/debian-devel/2013/05/msg01309.html Helmut Grohne (Cced) did most of the work on analyzing those possibilities. Thanks for inviting me to speak up here. Lucas asked me to summarize my analysis of systemd/sysv integration earlier and I'll be giving this summary (written for Lucas at that time) below. For better separation of facts and opinion, let me point out my motivation for working on this aspect. I believe that the declarative service configuration of systemd and upstart is superior to init shell scripts. Consequently, dropping the need for init shell scripts is the only way to improve the situation (imo). Lacking time, I mostly neglected upstart. On 23/08/13 at 22:32 +0200, Helmut Grohne wrote: The existing converter (GSOC) can be found at https://github.com/akhilvij/systemd-to-sysvinit-converter. My analysis of this project: https://lists.debian.org/debian-devel/2013/05/msg01309.html This includes a drafted idea on how to do runtime conversion. Implementation details on runtime conversion: (last pragraph) https://lists.debian.org/debian-devel/2013/05/msg01337.html Random details about service file conversion issues: https://lists.debian.org/debian-devel/2013/05/msg01334.html Important point over here: In .service files important dependency information has been elided by socket activation. Socket activation is official part of the dependency tree and any conversion utility that does not do socket activation will not produce correct boot ordering. Statistical analysis of existing .service files in Debian. https://lists.debian.org/debian-devel/2013/07/msg00436.html .service file parser written in C, could be used as a starting point. https://lists.debian.org/debian-devel/2013/07/msg00429.html I presume that you are preparing arguments for a discussion with the CTTE about how to move forward with /sbin/init. The question of whether or how to support systemd .service files on non-Linux platforms will be asked over there. The biggest issue I see here is the socket activation. It is mandatory for syslog, so no service will declare a dependency on syslog and just assume it to be present. On a technical level implementing socket activation on non-Linux platforms is possible. It would require a super server (similar to inetd) to be started early on and it would start .service files on request by other interpreted .service files when executed as init scripts. This amounts to reimplementing a fair part of systemd. The only alternative would be to annotate .service files with the missing dependency information, but which would likely be wrong most of the time. I guess that an implementation that allows socket activation would be able to support around 50% of the currently existing .service files. Bear in mind that systemd is a rapidly moving target. When I talked to Lennart about the idea of a portable .service file interpreter, he summarized future extensions to systemd that would raise the bar. The next issue will likely be the tight integration with dbus and later kdbus (the kernel implementation of dbus). By the time we would have an implementation featuring socket activation, we will likely need it to do dbus activation as well. Having read the parts of the ctte bug, it feels odd to preclude the option of supporting multiple init systems from discussion or consideration. If Debian is to support only one init system and that one init system is systemd, then given my above analysis it will be very hard for non-Linux ports to catch up. I argue that in this case we should consider dropping support for non-Linux ports. So if we really are considering such an outcome, why not consider the outcome of supporting multiple init systems (but maybe only one per architecture)? This would become radically easier if gnome were to become Architecture: linux-any. In any case, feel free to ask me for answers or help with respect to possible integration of systemd .service files in a non-Linux environment. I hope that this mail moves the discussion/decision forward. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Hi Helmut, On Tue, Oct 29, 2013 at 10:22:54AM +0100, Helmut Grohne wrote: Having read the parts of the ctte bug, it feels odd to preclude the option of supporting multiple init systems from discussion or consideration. If Debian is to support only one init system and that one init system is systemd, then given my above analysis it will be very hard for non-Linux ports to catch up. I argue that in this case we should consider dropping support for non-Linux ports. So if we really are considering such an outcome, why not consider the outcome of supporting multiple init systems (but maybe only one per architecture)? While other members of the TC may wish to consider this option, I've ruled it out myself because we would lose most of the benefits of switching away from sysvinit and instead accrue significant maintenance costs to individual developers who would then have to support both init systems in their packages. What makes switching init systems worth doing is being able to *simplify* the interfaces between the init system and the services. Continuing to support different init systems across different architectures would add complexity instead. That's a pretty bleak outcome. There's nothing fundamental that prevents upstart from being ported to non-Linux ports. So certainly, if the TC decides for upstart, I see no reason we would want to support sysvinit on ports instead of expecting the porters to port upstart to their architecture. This would become radically easier if gnome were to become Architecture: linux-any. GNOME may be the trigger for this being raised to the TC, but it's not the core question that we need to address. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Hi Paul, On Fri, Oct 25, 2013 at 02:43:44PM -0400, Paul Tagliamonte wrote: And, since I've been informed that this was basically a contentless bug, I'd like to frame the technical half of the question better: Thanks for bringing this question to the Technical Committee. It's been on my todo list to raise this myself, with the intent of getting a TC decision before the end of this year. With only two months left in the year, it's well past time that we start on this, so thanks for beating me to it. In keeping with discussions I've had with other members of the TC regarding what they feel would help with their decision making process, I've begun preparing a wiki page outlining the position of the upstart maintainers on why Debian should adopt upstart as the default init system for jessie. https://wiki.debian.org/Debate/initsystem/upstart The page is not yet complete - in particular, I'm still fleshing out the why upstart and not systemd section. But there's enough there to give the TC a starting point for discussion, I think. Whereas: * the init system / pid 1 is a bit of software that multiple packages provide * the choice of init system also dictates which types of init scripts package maintainers write and maintain * the situation in which packages depend on a feature of systemd that's not dependent on pid 1 being systemd (such as dbus shutdown, or using logind) being run without systemd as pid1 is *not* something the systemd maintainers will support (fairly) is getting *more* common, and has been introduced into a major package (GNOME) It is requested that the tech-ctte make a decision as to the init system Debian shall use as the default, and make a judgement call on where the efforts to resolve this situation shall go (patching *around* the lack of systemd, or patching software to use systemd) I believe this is within the ctte's jurisdiction, given 6.1 section 2. It seems to me that these are two separate questions, one dependent on the other. First we need to decide what jessie will use as the default init system. Once that's decided, if the decision is /not/ to use systemd, we can look at making recommendations about how to approach upstream incompatibilities; but while we should be aware that choosing a non-systemd default does imply a certain amount of work, we shouldn't rathole on deciding how to structure that work if we haven't even decided yet if that work will be necessary. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Hi guys, I'm just an user. Well, can I make a suggestion? We know systemd can't run on kFreeBSD and because of it Gnome can't run on kFreeBSD too, but what about Cinnamon? Cinnamon is dependent on systemd? 1- If not, so Cinnamon + good apps can make kFreeBSD usable. So replacing Gnome by Cinnamon on kFreeBSD (in CD-1, netinst, DVD-1 or whatever) is feasible. 2- If yes, MATE can be another good idea (I already have build MATE on it :D). MATE + good apps for example Pidgin, VLC, Brasero, and other). 3- In last case, if necessary kill kFreeBSD in favor to Illumos, the OSDyson project still alive and can be adopted in Debian project. Or, considering Gnome 3.10 is in OpenBSD ports, maybe a kOpenBSD is feasible. I think FreeBSD is not worried about the existence of systemd, and they are using your init yet, so kFreeBSD can work around that too. Sorry if I said some very absurd, I'm noob. Thanks.
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Tue, Oct 29, 2013 at 12:05:25PM -0700, Steve Langasek wrote: Hi Paul, Good afternoon, Steve, Thanks for bringing this question to the Technical Committee. It's been on my todo list to raise this myself, with the intent of getting a TC decision before the end of this year. With only two months left in the year, it's well past time that we start on this, so thanks for beating me to it. Happy to do it! In keeping with discussions I've had with other members of the TC regarding what they feel would help with their decision making process, I've begun preparing a wiki page outlining the position of the upstart maintainers on why Debian should adopt upstart as the default init system for jessie. https://wiki.debian.org/Debate/initsystem/upstart The page is not yet complete - in particular, I'm still fleshing out the why upstart and not systemd section. But there's enough there to give the TC a starting point for discussion, I think. Great, that sounds like really productive stuff. It seems to me that these are two separate questions, one dependent on the other. First we need to decide what jessie will use as the default init system. Once that's decided, if the decision is /not/ to use systemd, we can look at making recommendations about how to approach upstream incompatibilities; but while we should be aware that choosing a non-systemd default does imply a certain amount of work, we shouldn't rathole on deciding how to structure that work if we haven't even decided yet if that work will be necessary. Totally agree. FWIW; I had a brief conversation with a core Gentoo developer about their situation, and they also have a hard dep on systemd from GNOME, even though their default is OpenRC. As they're in the same situation, I can tell there's likely a lot of cross-distro work that *can* be done in collaboration with another (community driven) distribution if we decide to not default to systemd. (such as maintaining replacements for components which require the hard systemd pid1 dep) Thanks for taking this (very divisive) subject on, Paul -- .''`. Paul Tagliamonte paul...@debian.org : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag signature.asc Description: Digital signature
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On 28/10/13 20:14, Christoph Anton Mitterer wrote: For those who haven't seen it, Lennart has posted some of his comments about all this on G+: https://plus.google.com/u/0/115547683951727699051/posts/8RmiAQsW9qf And here is the reply from Gentoo developer Patrick Lauer: http://gentooexperimental.org/~patrick/weblog/archives/2013-10.html#e2013-10-29T13_39_32.txt signature.asc Description: OpenPGP digital signature
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Carlos Alberto Lopez Perez clo...@igalia.com writes: On 28/10/13 20:14, Christoph Anton Mitterer wrote: For those who haven't seen it, Lennart has posted some of his comments about all this on G+: https://plus.google.com/u/0/115547683951727699051/posts/8RmiAQsW9qf And here is the reply from Gentoo developer Patrick Lauer: http://gentooexperimental.org/~patrick/weblog/archives/2013-10.html#e2013-10-29T13_39_32.txt This, sadly, was not particularly useful or interesting. As near as I can tell, the core content was that he doesn't think cgroup management is particularly difficult (fine, but I don't think that was the point; the point, instead, was that it's important to have a single arbitrator, which if true poses specific technical challenges) and he believes that the components to systemd would be easy to implement as separate daemons if they were properly documented. I'm one of those people who thinks that nearly everything in Linux is horribly underdocumented, so I'm not going to argue with that point, but it's not a very useful statement from a practical viewpoint. systemd offers specific pieces of integrated functionality. By and large, no one seems to question that the operations enabled by that functionality are useful (although there is some debate over how useful). GNOME is not depending on systemd out of some nefarious plot. It's depending on systemd because GNOME wants to use those pieces of functionality systemd provides. Therefore, I think it's important for arguments against using systemd to somehow engage directly with the questions about functionality. Either there needs to be an argument that the functionality is not important and can be done without (which raises questions about how one would build GNOME in such an environment), or there needs to be some sort of plan for how equivalent functionality to systemd will be provided. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Sat, Oct 26, 2013 at 11:20:21AM -0700, Steve Langasek wrote: Right. Whichever init system we pick, I do expect the next step to be to drop the requirement to maintain sysvinit backwards-compatibility; While I'm not sure from your mail whether you meant to suggest otherwise, I do think that whatever we decide for jessie, we should continue the requirement of sysvinit compatibility for at least one release after we ship with some more modern init system. Also, since all alternative init implementations under consideration do support sysv-style init scripts, I think that whatever init system we (well, you, the TC) end up choosing, the requirement in policy should be that a package should ship either some init configuration for the default init system, or a sysv-style init script. In fact, I think we should continue to encourage the latter, in cases where it does make sense (e.g., when a given daemon doesn't have any init system specific features that could be enabled), since that will help our non-Linux ports without significantly impacting performance of the new init system. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Wouter Verhelst schrieb am Monday, den 28. October 2013: On Sat, Oct 26, 2013 at 11:20:21AM -0700, Steve Langasek wrote: Right. Whichever init system we pick, I do expect the next step to be to drop the requirement to maintain sysvinit backwards-compatibility; While I'm not sure from your mail whether you meant to suggest otherwise, I do think that whatever we decide for jessie, we should continue the requirement of sysvinit compatibility for at least one release after we ship with some more modern init system. Also, since all alternative init implementations under consideration do support sysv-style init scripts, I think that whatever init system we (well, you, the TC) end up choosing, the requirement in policy should be that a package should ship either some init configuration for the default init system, or a sysv-style init script. In fact, I think we should continue to encourage the latter, in cases where it does make sense (e.g., when a given daemon doesn't have any init system specific features that could be enabled), since that will help our non-Linux ports without significantly impacting performance of the new init system. It will also make backporting much easier. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
For those who haven't seen it, Lennart has posted some of his comments about all this on G+: https://plus.google.com/u/0/115547683951727699051/posts/8RmiAQsW9qf Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Hi! Please may I suggest another option for consideration: a commitment to support two chosen init systems. On mainstream ports (Linux amd64, i386) where two init systems are available, a package should be tested and made to work reasonably well on both. Any port would have at least one of these init systems. This offers users a choice to avoid a particular init system, try the new features in another one, or perhaps stay with what they already have. It would require work, but maybe this turns argument into something that can be accomplished through team effort. Supposing systemd and sysvinit were chosen: * systemd folks would aim to make best use of the existing sysvinit scripts, and provide help to packages where improvement can be made; * sysvinit users and porters can help ensure things keep working there. I've begun a debate page here, more suggestions are welcome: https://wiki.debian.org/debate/initsystem/multiple or follow up on debian-devel@ Thanks! Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Tue, 2013-10-29 at 00:45 +, Steven Chamberlain wrote: a commitment to support two chosen init systems. The question is would supporting two be enough to give a considerable benefit? I guess the competition will be mostly between: systemd vs. upstart. And not between sysvinit, anything else vs. systemd or upstart. sysvinit is simply too old and lacks many modern features. With anything-else, Debian would be more or less completely alone since all world (except *buntu) seems to settle on systemd. So from that POV, I'd even say upstart is already an island solution. Look at most core daemons and systems/technologies (read about CUPS and Wayland just a few days ago) - their upstreams seem to focus on systemd. So when Debian really supports two init systems... what could that be? Either a) systemd AND upstart I guess that would largely be a political benefit, since then the two major fractions are happy. b) (EITHER systemd OR upstart) AND sysvinit That could have a real technical benefit, with respect to !Linux flavours- since then we'd have systemd|upstart for Linux and sysvinit for !Linux. At least systemd does not support !Linux... and I guess it's the same for upstart(??). But then we'd have again the political problem of systemd vs. upstart, since only one could win. So *if* supporting multiple init-systems, and by supporting I mean, that every package must support _at least_ those, then supporting 3(!) seems to make more sense: sysvinit, systemd and upstart. I generally hope, that the tech-ctte will not *forbid* the use of any other init system, but just rule about a _minimum_ set of initsystems (or one) that MUST be supported. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Wouter Verhelst wou...@master.debian.org writes: Also, since all alternative init implementations under consideration do support sysv-style init scripts, I think that whatever init system we (well, you, the TC) end up choosing, the requirement in policy should be that a package should ship either some init configuration for the default init system, or a sysv-style init script. In fact, I think we should continue to encourage the latter, in cases where it does make sense (e.g., when a given daemon doesn't have any init system specific features that could be enabled), since that will help our non-Linux ports without significantly impacting performance of the new init system. Well, I've said this before, but I think it's worth reiterating. Either upstart or systemd configurations are *radically better* than init scripts on basically every axis. They're more robust, more maintainable, easier for the local administrator to fix and revise, better on package upgrades, support new capabilities, etc. I believe that much of the benefit for adopting a new init system is dropping init scripts and using a much better configuration language. If we're not going to take advantage of that benefit, it calls into question whether we should change init systems at all. In other words, I don't think it would make any sense at all to standardize on upstart or systemd and then ask people to continue to write init scripts in the long run (transition issues aside). Getting rid of init scripts is not the whole point, but it's a huge part of it. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Anyone suggesting staying with sysvinit should be shot at down for foolishness If you wish to stay something sysvinit like you should be backing OpenRC. The basic issue with sysvinit is lack of process tracking. This is the historic problem. You start a service. You stop a service. Ok everything is fine. You go to start service again. Hello some random process is still running so preventing the service starting because the service did not stop properly. Systemd and OpenRC both can address this using cgroups under Linux. OpenRC also can use Jails under BSD line. Upstart might be simpler to port but it does not address this base problem at all. The dbus issue is going to get major on all platforms. This is another http://www.freedesktop.org/wiki/Software/hal/ item. Hal was implemented in userspace and its functionality it has been replaced by devicekit. Same with the recent termination of userspace X11 drivers. kdbus changes things major way.Both upstart and openrc are well behind. The big risk is after kdbus is in the Linux kernel items like kernel power management move straight connected to it. So there may be no option bar use kdbus while running on the Linux kernel. Debian has big trouble ahead. No point putting head in sand. The Multi OS debian is means there is a lot of critical work that must start straight now. Like will kdbus be a feature we should expect from all kernels debian supports? Cgroups from Linux and Solaris Containers from Solaris operate close enough to make porting systemd possible. The major road block to systemd on freebsd kernel is nothing really like cgroups or Solaris Containers. Yes I know this would upset the freebsd guys no end but at this point we do have to serously consider if the freebsd branch is even worth keeping it is too alien to Linux. Working with www.openindiana.org to bring on something that can be systemd compatible as second kernel might be the correct way forward. Maybe then freebsd kernel developers would see the need to provide Container class features in their OS kernel. http://www.oracle.com/technetwork/articles/servers-storage-admin/intro-smf-basics-s11-1729181.html Service Management Facility of Solaris and systemd of Linux have a lot in common how they operate. This is why porting systemd to Solaris is not too bad. cgroup functionality can be directly swapped with Solaris Containers functionality. Cgroups was not a magical new idea that the Linux world dreamed up. Someone had been look at Solaris and liked what they saw. This is really the choice do we keep on attempting to make incompatible designed kernels interchange or do we move to kernels with similar operating designs. Yes we can still maintain the multi OS going forwards. But we are to the fork in the road. Debian cannot support everything.The project has to be willing to spill blood at times. I know killing kfreebsd branch completely is a lot of blood shed. But if that allows redirecting those resources to a more compatible kernel so be it. The big answer we need from freebsd kernel developers are they going to implement functionality to match cgroup and solaris containers. If not going forwards compatibility with them is going to become harder and harder to maintain. https://people.gnome.org/~alexl/glick2/ something people forget container/cgroup class tech enable relocatable installation of programs without the program seeing it. Containers is something that could be used in future to make multi-arch cleaner. Like allowing 32bit and 64bit development files and applications to be installed side by side without issues. Like being able to install 32bit and 64bit ice-weasel at the same time. The road block coming from freebsd is blocking systemd is also blocking debian from using the same features to address other problems as status normal. Solaris kernel and Linux kernel could have identical instructions given to developer to build packages due to the existence of container tech in both. Sorry everyone is hard choice time. Do we go forwards having to work around the limited functionality of freebsd? Do we nuke freebsd and move on to another kernel more compatible? Do we pressure freebsd kernel developers to add containers? Yes most people are missing the major road block to systemd on freebsd is road blocking a solutions to stacks of other problems. So really this is more than a init system problem. The fact systemd is not portable to freebsd is showing missing features. So far no one other me has went out and looked at the other kernels to see if the bsd line is a edge. This case they are an outer edge. Peter Dolding -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Hi, apart of the arguments raised by others, I'd like to point out three more things: - If we'd be inclined to switch the init system to something different to sysvinit, let's start rather soon than later. Starting with today we have one year until we expect to freeze which sounds like a lot, but it's not if you take in mind that (up to) 1200 packages [1] need to be adapted to this change, some in a non-trivial way. I guess any alternative being discussed here is able to provide some fall-back mechanism in case it's really needed, but if we rely on that, I don't see a reason to switch in the first place. Thus, I'd appreciate if the TC decides on that case rather soon than later since I'm one of these persons who maintains several not-trivial init scripts. - Please bear in mind that supporting more than one init script type is not feasible or doable. Especially for non-trivial scripts [2][3] maintaining an init script is a substantial piece of work, and I claim, that we could spend our time in better ways than maintaining three pieces of code (or, as for me, meta-language description files) which all need to be tested, fixed and updated every once in a while. I guess, I could deal with that burden once for Jessie, but please don't get us into that as a long term solution. - Whatever you decide, please do also turn your attention to the outside world apart of Debian. This discussion was raised (well, this time), because Gnome started to depend transitionally on systemd. Whether we like it or not, but we're not the center of the universe. There are distributions, and very important pieces of software outside the control Debian and the TC that have (biased) points of view conflicting with Debian's on this matter. Thus, I suspect that we are not going to succeed with an isolated island solution, which does not care about the ways other distributions move - especially since the init system choice seems to be heavily tied to the choice of the desktop these days. Whether it's systemd or upstart, both have major players standing behind its respective technologies, each with substantial financial resources to drive development of these platforms in a direction where Debian with an isolated solution cannot compete with, due to its community driven organizational structure. [1] $ apt-file search /etc/init.d | wc -l 1194 [2] http://anonscm.debian.org/gitweb/?p=pkg-apache/apache2.git;a=blob;f=debian/apache2.init;h=f5977abd302115e1517110fc2e00ca0cd2054afd;hb=HEAD [3] http://anonscm.debian.org/gitweb/?p=users/wouter/nbd.git;a=blob;f=debian/nbd-client.init.d;h=23994dd93b315533ee43bbb961b21aa40ff25c00;hb=HEAD -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On 25/10/13 at 12:16 -0400, Paul Tagliamonte wrote: In response to the recent threads, I'd like to ask the tech-ctte to please vote on and decide on the default init system for Debian. I agree. I don't think that many substantial new arguments are going to be brought by waiting more on this topic. And it is clear that we have reached a point where not having clear guidance is severely hurting the project. On 25/10/13 at 16:40 +, Thorsten Glaser wrote: I’d still say, let’s just GR about it. Prepare one now, then have some time to cool down before the vote period. I think that it would be a failure of the Debian project if we had to have a GR about such a technical decision. I think that we need to trust that the Technical Committee will make the right decision. A GR about this will likely result in splitting and hurting the project even more. On 25/10/13 at 14:43 -0400, Paul Tagliamonte wrote: And, since I've been informed that this was basically a contentless bug, I'd like to frame the technical half of the question better: Whereas: * the init system / pid 1 is a bit of software that multiple packages provide * the choice of init system also dictates which types of init scripts package maintainers write and maintain * the situation in which packages depend on a feature of systemd that's not dependent on pid 1 being systemd (such as dbus shutdown, or using logind) being run without systemd as pid1 is *not* something the systemd maintainers will support (fairly) is getting *more* common, and has been introduced into a major package (GNOME) It is requested that the tech-ctte make a decision as to the init system Debian shall use as the default, and make a judgement call on where the efforts to resolve this situation shall go (patching *around* the lack of systemd, or patching software to use systemd) I believe this is within the ctte's jurisdiction, given 6.1 section 2. I think that there are two different questions: 1) Could you clarify which init system(s) must be supported by packages involved during system startup (daemons, etc.) and low-level services? [ the answer to that question would likely result into a update of the Debian Policy, section 9.3 and 9.11 ] [ Note that most daemons will likely still have to support sysvinit in jessie, in order to handle partial upgrades. ] 2) sysvinit is currently Essential: yes, which causes it to be installed by default by the installer. Should sysvinit stay Essential? If not, should another init system be Essential? If not, how should this be addressed in the debian installer? Lucas signature.asc Description: Digital signature
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Sat, Oct 26, 2013 at 11:07:36AM +0200, Lucas Nussbaum wrote: I think that there are two different questions: 1) Could you clarify which init system(s) must be supported by packages involved during system startup (daemons, etc.) and low-level services? [ the answer to that question would likely result into a update of the Debian Policy, section 9.3 and 9.11 ] [ Note that most daemons will likely still have to support sysvinit in jessie, in order to handle partial upgrades. ] 2) sysvinit is currently Essential: yes, which causes it to be installed by default by the installer. Should sysvinit stay Essential? If not, should another init system be Essential? If not, how should this be addressed in the debian installer? I don't think either of these are the right question. Even if we change the default init system for jessie, because we *must* support backwards compatibility with sysvinit for upgrades, there is no justification for requiring packages to do anything else for jessie and no policy change is needed. Likewise, the Essential: yes bit on the sysvinit package will be in effect for a full release cycle regardless of what init system we choose, so it needs to become a metapackage that depends on an ORed list of possible implementations in order for us to make any change in jessie. The real question before the TC is simply: what should the default init system be for jessie? The rest are technical details that can be straightforwardly worked out once we have a decision on the direction. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Steve Langasek vor...@debian.org writes: I don't think either of these are the right question. Even if we change the default init system for jessie, because we *must* support backwards compatibility with sysvinit for upgrades, there is no justification for requiring packages to do anything else for jessie and no policy change is needed. That isn't obvious to me. We have, in the past, allowed upgrades to require a preliminary upgrade of one or more packages. The udev transition comes to mind. We *could* do the same thing here and require an init upgrade as a pre-upgrade step when going from wheezy to jessie, alongside a dependency on systemd or upstart (added by debhelper, for example) for all packages providing startup configuration but not an init script. I'm not saying that's necessarily a good option, but it is an option that we should discuss. Also, we will eventually have to decide whether to drop the requirement that packages provide sysvinit-compatible init scripts. Even if we agree on a requirement to do so for jessie, we could drop that requirement for jessie+1 (and indeed will want to if we choose any init system other than sysvinit or all of the above, given that most of the benefits of either upstart or systemd from a packaging perspective will only be seen when we take that step). We could always defer that decision until jessie+1, but that's the decision with the most impact on kFreeBSD and Hurd, and if I were them, I'd want to know whether that's the eventual project direction or not as soon as possible so that I have as much time as possible to decide on my next steps. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Sat, Oct 26, 2013 at 10:46:38AM -0700, Russ Allbery wrote: Steve Langasek vor...@debian.org writes: I don't think either of these are the right question. Even if we change the default init system for jessie, because we *must* support backwards compatibility with sysvinit for upgrades, there is no justification for requiring packages to do anything else for jessie and no policy change is needed. That isn't obvious to me. We have, in the past, allowed upgrades to require a preliminary upgrade of one or more packages. The udev transition comes to mind. udev transitions have always happened under duress. We should do better than this where we reasonably can. (In the udev case, we had no choice but to require a risky lockstep upgrade of the kernel and udev, because maintaining udev compatibility with older kernels would have required an excessive amount of new work.) We *could* do the same thing here and require an init upgrade as a pre-upgrade step when going from wheezy to jessie, alongside a dependency on systemd or upstart (added by debhelper, for example) for all packages providing startup configuration but not an init script. I'm not saying that's necessarily a good option, but it is an option that we should discuss. Ok, point taken. We *could* decide that something other than sysvinit was now the new least common denominator for jessie, and using dependencies ensure a smooth upgrade (i.e., this still wouldn't be the udev problem). I think that would be a surprisingly bold change for Debian to make in the space of a single release cycle, when up to now we collectively have very little experience running either systemd or upstart in production on Debian, and we don't as yet have a resolution for compatibility with non-Linux ports. Also, we will eventually have to decide whether to drop the requirement that packages provide sysvinit-compatible init scripts. Even if we agree on a requirement to do so for jessie, we could drop that requirement for jessie+1 (and indeed will want to if we choose any init system other than sysvinit or all of the above, given that most of the benefits of either upstart or systemd from a packaging perspective will only be seen when we take that step). We could always defer that decision until jessie+1, but that's the decision with the most impact on kFreeBSD and Hurd, and if I were them, I'd want to know whether that's the eventual project direction or not as soon as possible so that I have as much time as possible to decide on my next steps. Right. Whichever init system we pick, I do expect the next step to be to drop the requirement to maintain sysvinit backwards-compatibility; my point was that I don't expect this to be something we change in policy for this cycle as part of the TC decision. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi there! I've been asked to write about OpenRC here. I'm a bit reluctant to do it, but feel that it's my duty as I've been mentoring the OpenRC GSoC project this summer. Well, it's been a month the OpenRC package is waiting in the FTP NEW queue (after a successful GSoC project), so it's a bit silly to tell about something which isn't even in Debian yet... Though if anyone wants to test it, it's in /git/collab-maint/openrc.git on Alioth. Anyway, the main point of OpenRC, IMO, is that it can work on non-linux platforms. But at this point, it is hard to make a case for it, since the porting work (well, I should rather say the no-FTBFS work... as it should be only a mater of configuring the build environment) hasn't been done yet. :( Note that OpenRC already works on some (non-Debian) BSD platforms, and that it should be trivial to have it to build on kFreeBSD and Hurd, though I didn't (and probably wont in the next few weeks/months, due to professional duties and personal events) have time to work on this. Though when this is done, OpenRC will be a drop-in replacement, with normally very little trouble to take care of. I of course welcome anyone to work on these ports. With a bit more goodies than with sysv-rc (for example, cgroups support for the platforms who supports it), OpenRC can be seen as an evolution of it, with more features. As for my own opinion on #727708, I'd like the tech committee to decide we *must* continue to support something that works on kFreeBSD and Hurd (either sysv-rc, or OpenRC when it's fully working on all arch) as a requirement in the Debian policy, at least if we don't have an upstart working port for Hurd / kFreeBSD (if this ever happens). It is to be noted that it's Systemd upstream opinion as well that Debian has no choice but to support something else than Systemd (sysv-rc, OpenRC,...) scripts for platforms which wont ever be supported by Systemd (I discussed about that with Lennart during Debconf). Even if there's no such a decision from the tech-ctte, some ways of starting daemons must be done for the non-linux Debian archs. And OpenRC could be adopted for them (in the absence of Upstart / Systemd), to simplify writing of these init scripts and bring more features. So, whatever the tech-ctte decides, OpenRC, in my opinion, makes sense! :) I also would like to wish good luck to the tech-ctte. Whatever you will decide, I will support it. I wouldn't like to be in your seats, and I hope everyone will also support your final decision. Hoping that the work on OpenRC will be useful for Debian, Cheers, Thomas Goirand (zigo) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJSbA5ZAAoJENQWrRWsa0P+YYUP/37zqCtcornktT3xb7LKC4w7 ZdDig/g6cGW1JbL90q/6OPSN0CDUiVcF66HkP5RXk6jUG9CBm5OMmkz2+VX3THLR Vhnyd/t5dQiyBLGgSO9YI4I9DizppasYjRpqsK7O3bI7cfmGgg8xyBk6CL3Kblvm D7+jvRbBwdt+HqJccHsM4+n3mUgJFLOajVwU2E8Mp7TFY3bRwIyXWDPsE+7q0Jxi 1F1sS/bBxtaBOlj3tEAMRxLHH74bwKiT5VTo114ygQTu8ylsZ8hSCnNuDFSAm7mk 0TL28xaD1bA7VN2VwYd41J/KIWHel+0In5fG7FOIX1DGf543Fyei+CfpaINAHS+7 Yt8X2C/EFJr/4dERXTrxhxSN9T0B8fRvXwe1I6KEvcoyzIsEKjJO/yJxmr8NNrVA w5Qp/jjLfrL82HlUIdvva4OonFCHGIVZkP+KFjTYMnKUJ9mlOnqCIF7m+cfH7ZkR RFfodY3eWAiVY+Nq2SJ0EB9R+cslxXovotNvmMZQvagLIhlLC+qXMGTkV6VvXHbF B0nVT6qCGmuDHQSUBCCeGy7nEKU1ObRcyfW3YJ0tiXmOTBuCBltHJpOiV4OwBcMK 7b20W8AtAyTbdtheksoUS4TSg25LOAQfeP0Gk0AVDV7nDDGLDVcCJ6L84JBjcu03 5wvRVoh1K0uf/pC/jWM9 =E/op -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Package: tech-ctte Severity: normal thanks In response to the recent threads, I'd like to ask the tech-ctte to please vote on and decide on the default init system for Debian. There's been quite a lot of discussion and it's clear no consensus is coming out of the discussion. In addition, I find that developers care quite a bit (in both directions), and dependencies / conflicts are only going to become more common and serious for our users. Thank you! Paul -- .''`. Paul Tagliamonte paul...@debian.org : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag signature.asc Description: Digital signature
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Paul Tagliamonte dixit: please vote on and decide on the default init system for Debian. It’s not (just) about the _default_ but also on whether we will force this default init system onto *all* our users, or whether we commit to support more than one, and if so, how. This is an *important* distinction / first step, and it absolutely *must* be decided *before* the default is decided, because otherwise the default system becomes just so much more important. Why is it so hard to understand that this is (for me) about freedom of choice? I’d still say, let’s just GR about it. Prepare one now, then have some time to cool down before the vote period. bye, //mirabilos -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Fri, Oct 25, 2013 at 04:40:15PM +, Thorsten Glaser wrote: Paul Tagliamonte dixit: please vote on and decide on the default init system for Debian. It’s not (just) about the _default_ but also on whether we will force this default init system onto *all* our users, or whether we commit to support more than one, and if so, how. We've only ever supported one as a project; if you'd like to start supporting more, please start a thread on that, and perhaps a release goal. This is an *important* distinction / first step, and it absolutely *must* be decided *before* the default is decided, because otherwise the default system becomes just so much more important. The default is the only thing we should support. Trying to support every init system is insane, and again, this has implications on how daemons are started, and small bugs for some radom daemon may start causing subtle heisenbugs in unrelated apps. Why is it so hard to understand that this is (for me) about freedom of choice? It may be, but it's not for the project. Let's let this bug be, and have the tech cttie decide on *the* init system for Debian. If you want to support more, again, please suggest it in another thread and/or bug. Cheers, Paul -- .''`. Paul Tagliamonte paul...@debian.org : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag signature.asc Description: Digital signature
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Paul Tagliamonte dixit: It may be, but it's not for the project. Let's let this bug be, and have the tech cttie decide on *the* init system for Debian. If you want No, this must really really be decided first. bye, //mirabilos -- diogenese Beware of ritual lest you forget the meaning behind it. igli yeah but it means if you really care about something, don't ritualise it, or you will lose it. don't fetishise it, don't obsess. or you'll forget why you love it in the first place. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Fri, Oct 25, 2013 at 04:53:52PM +, Thorsten Glaser wrote: Paul Tagliamonte dixit: It may be, but it's not for the project. Let's let this bug be, and have the tech cttie decide on *the* init system for Debian. If you want No, this must really really be decided first. Moving bug off CC. Please don't re-add it. Feel free to start a new thread. Let that thread and bug be. -- .''`. Paul Tagliamonte paul...@debian.org : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag signature.asc Description: Digital signature
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
And, since I've been informed that this was basically a contentless bug, I'd like to frame the technical half of the question better: Whereas: * the init system / pid 1 is a bit of software that multiple packages provide * the choice of init system also dictates which types of init scripts package maintainers write and maintain * the situation in which packages depend on a feature of systemd that's not dependent on pid 1 being systemd (such as dbus shutdown, or using logind) being run without systemd as pid1 is *not* something the systemd maintainers will support (fairly) is getting *more* common, and has been introduced into a major package (GNOME) It is requested that the tech-ctte make a decision as to the init system Debian shall use as the default, and make a judgement call on where the efforts to resolve this situation shall go (patching *around* the lack of systemd, or patching software to use systemd) I believe this is within the ctte's jurisdiction, given 6.1 section 2. Thanks for your consideration, Paul -- .''`. Paul Tagliamonte paul...@debian.org : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag signature.asc Description: Digital signature
