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-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87txfrql54@qurzaw.varnish-software.com
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-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131105090540.gf28...@mails.so.argh.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-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5495365.GDkCjXMk91@trelane
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-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131106000306.gg28...@mails.so.argh.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-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fvracrl5@windlord.stanford.edu
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-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131106004420.gh28...@mails.so.argh.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-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1a6c605b3ecd4e4d717292526bcfe2db.squir...@aphrodite.kinkhorst.nl
