Re: Survey answers part 3: systemd is not portable and what this means for our ports
The Wanderer wrote: [...] and the proprietary[0] interfaces they seem to use [...] [...] [0] Meaning approximately we create our own language and talk it to ourselves, and anyone else who wants to talk to us has to learn our language, not intending to imply undocumented or legally restricted or anything of the sort. This isn't a very good term for what I mean, but I couldn't find a better one. I tend to think that custom interfaces would be more appropriate for what you described here. The term proprietary seems to imply some sort of exclusivity with regard to those interfaces, while my current impression is that systemd developers do not have any interest in locking them to systemd: to the contrary the seem quite happy that some of them got adopted by others (hostnamed, localed, logind, etc.) and link to them from their wiki: http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/ In the case of logind, it has even been made able to run standalone to let others reuse the same implementation, not only the interface. Sorry for the digression, I just took the chance to mention this stuff here since it's not the first time I see this term used somewhat inappropriately in this context. -- Emanuele Aina http://www.collabora.com -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1376431619.3526.35.ca...@autarpio.lan
Re: Survey answers part 3: systemd is not portable and what this means for our ports
Uoti Urpala preached with fire in his heart and wind in his head: I'd say that mainly shows that systemd upstream has managed to develop things forward. Creating and changing things involves decisions, and there's no way to make everyone happy. And when old things are changed there's bound to be a lot of controversy, even if the old stuff was total crap and new is almost perfect. Almost perfect as in: http://www.happyassassin.net/2013/06/14/fedora-1920-logfile-explosions/ http://blog.gerhards.net/2013/06/systemd-journal-causes-loop-in-imjournal.html Verily, sir, you're one of the best upstart advocates on this mailing list. – jubal -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/42dcd21351a3d6f968b7a7d9bb7a9...@hell.pl
Re: Survey answers part 3: systemd is not portable and what this means for our ports
Miroslaw, On Thu, Jul 25, 2013 at 12:00 PM, Miroslaw Baran ba...@hell.pl wrote: Uoti Urpala preached with fire in his heart and wind in his head: Miroslaw, please, do not troll. This list has enough flames and we don't need more. Anecdotal evidence of some bugs in some software doesn't prove your point (or the point of the other party). O. -- Ondřej Surý ond...@sury.org
Re: Survey answers part 3: systemd is not portable and what this means for our ports
brian m. carlson wrote: On Mon, Jul 22, 2013 at 07:17:04PM +0300, Uoti Urpala wrote: If you don't do development, and nobody sharing your views does either, then there's a limit to the extent you can choose your direction just by refusing to follow those that do develop things further. You can't stick with Minix forever even if you think the direction of Linux is undesirable. My point is that Debian developers create lots of great software, and certainly maintain lots of patches to software for which Debian is not upstream. But it's simply not feasible for Debian to be the upstream for all software. That's true, but doesn't affect what I said above. If you can't develop Minix to be competitive then you either have to switch to Linux at some point or you'll become increasingly obsolete. I don't think it's controversial to say that Debian developers prefer upstreams that take concerns relevant to Debian and its users into account. Of course. But my point was that when no other upstreams offer competitive functionality, the friendliness of upstream isn't really relevant when choosing which program to use. The friendliest possible Minix maintainer can't make it a good choice over Linux, no matter how much you despise Torvalds. In the systemd case most of the concerns that upstream has been accused of not taking into account have clearly more been controversial views of some Debian developers than concerns of its users. For example, if kFreeBSD died as a result of lacking systemd support, that would probably be a net win for users. Suppose that in the future systemd does go in a direction you don't like. Now would it have done any good for Debian to not adopt it? Not really, if nobody develops a competitive alternative to its functionality. Not using it would only make Debian obsolete for most use cases. And the most realistic way to create a competitive alternative going in a different direction would be to fork systemd, so adopting current systemd would not make moving to such alternatives harder. The vast majority of the work I do on a Linux box, desktop, laptop, or server, does not involve init in any way. It is therefore not accurate to claim that using an init system other than systemd would make Debian obsolete. The init system matters for dynamic behavior like hardware discovery and network connectivity. It will matter in a lot of typical workflows, and choice of init system of course affects how easy it is to develop a distribution overall. Of course there are lots of tasks that you can still achieve on a 10-year-old machine with 10-year-old software. But even if such a machine does not become completely unusable, it is clearly obsolete. For example, RHEL 6 and Ubuntu use upstart, and I think it's hardly accurate, based on their significant adoption, to call them obsolete. And Debian still defaults to sysvinit, yet I wouldn't call it obsolete yet. But it does already suffer from its init system. For example, if an upstream expresses disinterest in supporting non-PC architectures, that may be a bad piece of software for Debian to place in an important role, even if it currently works on all our architectures, since Debian is very portable among different architectures. Of course, this isn't relevant to systemd, as it has no hardware- specific code and supports embedded platforms for which Debian is too bloated. This was meant as an illustrative example of a common problem with upstreams, not as a problem particular to systemd. systemd upstream has made a lot of controversial decisions that Debian may or may not want to support: combined / and /usr, the journal, logging to the kernel ring buffer, lack of portability to non-Linux kernels, and merging udev and systemd are a few examples. I'd say that mainly shows that systemd upstream has managed to develop things forward. Creating and changing things involves decisions, and there's no way to make everyone happy. And when old things are changed there's bound to be a lot of controversy, even if the old stuff was total crap and new is almost perfect. I do not believe there would have been any chance to achieve a similar amount of progress without controversy. The alternative to this kind of controversy is stagnation, not any magical form of progress with total consensus. If Debian decides that it is preferable for whatever reason not to adopt one or more of these decisions, the willingness of upstream to accept that decision and work with Debian instead of saying, Too bad, so sad, is something that should be considered before making a major change. I'm not saying not to use systemd, I'm just suggesting making a well-reasoned decision. I strongly disagree with the view that being a good upstream should imply accepting such arbitrary demands from distributions. IMO what a good upstream should answer to requests to change most of the things you listed
Re: Survey answers part 3: systemd is not portable and what this means for our ports
]] The Wanderer If someone implementing a new alternative wanted to retain the other tools with which systemd integrates, that person would have to match their interfaces, which might limit the functionality the new alternative could be able to provide - much as having to match the sysvinit interfaces would seem to limit the functionality systemd can provide. systemd isn't limited by sysvinit interfaces in what kind of interfaces it can implement. It just means a subset of the functionality is supported for sysvinit scripts. (No socket activation to take an obvious example.) The sysvinit support is actually optional and can be compiled out. As for the concerns that a new tool would require a lot of work if it were to replace systemd, well, yes, it would. Systemd does cover a lot of ground and if you want to feature match/feature exceed it everywhere, that's not an easy task. Zbigniew pointed out some bits that can be broken out piecemeal and used independently, though. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ip03f5mw@qurzaw.varnish-software.com
Re: Survey answers part 3: systemd is not portable and what this means for our ports
Vincent Cheng vincentc1...@gmail.com writes: On Fri, Jul 19, 2013 at 9:35 AM, John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de wrote: On 07/19/2013 06:12 PM, Mathieu Parent wrote: As the recommended way to install systemd is using init= and not installing systemd-sysv, maybe the popcon vote count is the correct metric? Plus, systemd isn't pulled in by anything else which means when it's there it's there because it was actively installed. I don't think it magically lands onto a user's hard disk or someone installs it just in order to not use it actually. On the contrary, in experimental, gnome-shell depends on gnome-settings-daemon, which in turn depends on systemd. I wouldn't be surprised if this is one of the reasons sid still has version 3.4 of the shell, rather than the latest upstream version (3.8). If/when gnome-shell 3.8 hits unstable and systemd gets forced on end users as well...I dare say that the general outcry here on debian-devel would make the past network-manager related threads look tame in comparison. I offer my deepest condolences to the gnome maintainers in advance (I doubt that they're looking forward to dealing with all this). systemd being installed does not mean it will be used as init. The package happens to contain a few tools the GNOME Shell needs, that is all, to the best of my knowledge. It's a harmless dependency if you don't use systemd, one that is only scary on paper. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ppubm199.fsf@algernon.balabit
Re: Survey answers part 3: systemd is not portable and what this means for our ports
Le lundi 22 juillet 2013 à 10:45 +0200, Gergely Nagy a écrit : systemd being installed does not mean it will be used as init. The package happens to contain a few tools the GNOME Shell needs, that is all, to the best of my knowledge. It's a harmless dependency if you don't use systemd, one that is only scary on paper. If you don’t use systemd, logind will be non-functional, and you lose all features that require the system to know who is logged on what. Such as shutting down the system, mounting USB devices, and so on. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1374484629.2461.1289.camel@pi0307572
Re: Survey answers part 3: systemd is not portable and what this means for our ports
Josselin Mouette j...@debian.org writes: Le lundi 22 juillet 2013 à 10:45 +0200, Gergely Nagy a écrit : systemd being installed does not mean it will be used as init. The package happens to contain a few tools the GNOME Shell needs, that is all, to the best of my knowledge. It's a harmless dependency if you don't use systemd, one that is only scary on paper. If you don’t use systemd, logind will be non-functional, and you lose all features that require the system to know who is logged on what. Such as shutting down the system, mounting USB devices, and so on. Ah, I didn't know that. That does sound considerably scarier than I thought. (Mind you, I am using systemd.) Thanks for the clarification! -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehaqnbai.fsf@algernon.balabit
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 22 July 2013 10:17, Josselin Mouette j...@debian.org wrote: Le lundi 22 juillet 2013 à 10:45 +0200, Gergely Nagy a écrit : systemd being installed does not mean it will be used as init. The package happens to contain a few tools the GNOME Shell needs, that is all, to the best of my knowledge. It's a harmless dependency if you don't use systemd, one that is only scary on paper. If you don’t use systemd, logind will be non-functional, and you lose all features that require the system to know who is logged on what. Such as shutting down the system, mounting USB devices, and so on. If packaged right, this is not the case. I am running my machine with logind and upstart as system user session init. Most of upstream packages were modified to correctly check for logind presence, instead of systemd presence. (Many thanks goes to pitti). Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluialjedcgquy-7p5ii5bnrmp-x0erlosgm1qkrdc91...@mail.gmail.com
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 07/22/2013 02:52 AM, Tollef Fog Heen wrote: ]] The Wanderer If someone implementing a new alternative wanted to retain the other tools with which systemd integrates, that person would have to match their interfaces, which might limit the functionality the new alternative could be able to provide - much as having to match the sysvinit interfaces would seem to limit the functionality systemd can provide. systemd isn't limited by sysvinit interfaces in what kind of interfaces it can implement. It just means a subset of the functionality is supported for sysvinit scripts. (No socket activation to take an obvious example.) Yes, that's what I was referring to; living within the limitations of the sysvinit formats, rules, and assumptions restricts the functionality systemd can provide. (If you look at the phrasing, I used provide vs. implement somewhat carefully, although maybe not carefully enough.) The sysvinit support is actually optional and can be compiled out. As for the concerns that a new tool would require a lot of work if it were to replace systemd, well, yes, it would. Systemd does cover a lot of ground and if you want to feature match/feature exceed it everywhere, that's not an easy task. Zbigniew pointed out some bits that can be broken out piecemeal and used independently, though. My concern was that the integrated nature of it would make it harder to replace any one part, especially if desiring to extend rather than just reimplement. Having it made clear that it's more compatible with being split out piecemeal, as you put it - with being essentially modular - than I'd thought does help somewhat in that regard, however. Part of it is also a matter of sense of fairness; systemd faced certain obstacles in implementing an alternative to the established sysvinit, but its design seems to place even more obstacles in front of something looking to implement a future alternative to an established systemd, especially one which (as with systemd vs. sysvinit) does not use the same assumptions as what it's looking to replace. That imbalance is a large part of what bothers me about this, I think. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51ed257a.3050...@fastmail.fm
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 21 July 2013 20:22, The Wanderer wande...@fastmail.fm wrote: I'm saying that it looks to me as if the lock-in to systemd would be even stronger than the lock-in to sysvinit, and might well extend to the point of even making it harder to implement another new alternative in the first place. So let's never switch to anything better than what we have now unless we also support 1 or 2 alternatives simultaneously just to be safe. /s Jeremy -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAajCMaWbUDKK1eA=h2oWqR2L0M2wv-b=cp2oz1b-f_8hmx...@mail.gmail.com
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 07/22/2013 08:48 AM, Jeremy Bicha wrote: On 21 July 2013 20:22, The Wanderer wande...@fastmail.fm wrote: I'm saying that it looks to me as if the lock-in to systemd would be even stronger than the lock-in to sysvinit, and might well extend to the point of even making it harder to implement another new alternative in the first place. So let's never switch to anything better than what we have now unless we also support 1 or 2 alternatives simultaneously just to be safe. /s That's not really what I'm saying, though part of me thinks it doesn't sound like an inherently bad idea. I suppose what Im trying to say is mostly... if we do switch to something with the potential to make things worse in the lock-in department, make sure that we do it with our eyes wide open, with full awareness of the fact that it could make things worse, and with due consideration of how to manage and possibly mitigate that. The reason I brought it up in the first place is that even among all the other objections being raised, I hadn't seen this aspect of a potential negative mentioned at all, and I didn't (and don't) want to see things go forward without its being taken into account. If it *is* taken properly into account, that's another matter. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51ed3654.7080...@fastmail.fm
Re: Survey answers part 3: systemd is not portable and what this means for our ports
Am 22.07.2013 11:17, schrieb Josselin Mouette: Le lundi 22 juillet 2013 à 10:45 +0200, Gergely Nagy a écrit : systemd being installed does not mean it will be used as init. The package happens to contain a few tools the GNOME Shell needs, that is all, to the best of my knowledge. It's a harmless dependency if you don't use systemd, one that is only scary on paper. If you don’t use systemd, logind will be non-functional, and you lose all features that require the system to know who is logged on what. Such as shutting down the system, mounting USB devices, and so on. No longer true with 204-1. We made it possible to use logind standalone and it will be activated via D-Bus ondemand on sysvinit when other software needs it. So what Gergely said is correct. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On Mon, Jul 22, 2013 at 2:28 PM, The Wanderer wande...@fastmail.fm wrote: My concern was that the integrated nature of it would make it harder to replace any one part, especially if desiring to extend rather than just reimplement. Having it made clear that it's more compatible with being split out piecemeal, as you put it - with being essentially modular - than I'd thought does help somewhat in that regard, however. We have a *zillion* libraries where we are *locked-in*. Just a few examples: 1. there's one big lock-in called dpkg :) 2. try to get rid of OpenSSL 3. we cannot use GTK+ for KDE and QT for Gnome - also a lock-in 4. just do dpkg --get-selections and see yourself I don't see a single reason why the modern sysvinit case should be any special. Yes, change is hard, but one should not resist the change just because it's a change. Few side notes: 1. As far as I have noticed - systemd is well documented, modular and have documented interfaces between modules. 2. The syntax of any declarative init files is and will be simple enough to write a conversion script. That's not possible to do with sysvinit shell scripts. Thus any possible future change will be *easier* and not harder that this step. O. -- Ondřej Surý ond...@sury.org
Re: Survey answers part 3: systemd is not portable and what this means for our ports
brian m. carlson wrote: On Mon, Jul 22, 2013 at 02:59:20AM +0300, Uoti Urpala wrote: Whether your argument was honest or not, I think it was a bad one. OK, perhaps you have concerns about the philosophy behind systemd and where that might take it in the future. Such philosophy issues are rather subjective. But your argument objectively fails at the ... and therefore moving to systemd may not be the right choice part. Your concerns, even if taken seriously, do justify such a conclusion. If systemd development goes in a direction you don't like, the rational answer is to fork it and do better if you can. Leaving Debian behind with an inferior init system is not an answer to your concerns. Since Debian is always in need of developers and volunteers, it isn't objectively reasonable to expect that forking a project will be possible. One thing that needs to be taken into consideration is the *likelihood* that upstream will take development in an undesirable direction, or in a direction that is not acceptable for Debian. If you don't do development, and nobody sharing your views does either, then there's a limit to the extent you can choose your direction just by refusing to follow those that do develop things further. You can't stick with Minix forever even if you think the direction of Linux is undesirable. Suppose that in the future systemd does go in a direction you don't like. Now would it have done any good for Debian to not adopt it? Not really, if nobody develops a competitive alternative to its functionality. Not using it would only make Debian obsolete for most use cases. And the most realistic way to create a competitive alternative going in a different direction would be to fork systemd, so adopting current systemd would not make moving to such alternatives harder. For example, if an upstream expresses disinterest in supporting non-PC architectures, that may be a bad piece of software for Debian to place in an important role, even if it currently works on all our architectures, since Debian is very portable among different architectures. Of course, this isn't relevant to systemd, as it has no hardware- specific code and supports embedded platforms for which Debian is too bloated. IMO being portable should not be considered a positive thing by itself. Being suited to a lot of use cases is positive, but that could be achieved by either porting to more platforms or supporting more use cases on the same platform. Assuming X.Org had supported x86 platforms only and supporting multiple X servers in Debian had not been realistic, do you think Debian should have kept using XFree86 on every platform rather than move to X.Org and drop support for X on non-x86? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1374509824.21442.82.camel@glyph.nonexistent.invalid
Re: Survey answers part 3: systemd is not portable and what this means for our ports
The Wanderer wande...@fastmail.fm writes: Leaving aside fears about what upstream might decide to do at some point (e.g. the make udev require systemd proposal), much of that objection simply comes down to how difficult it looks like it would be to switch *away* from systemd, once it becomes entrenched. Making the switch away from the entrenched sysvinit is visibly very difficult, at least as a social matter, even in the environment we have. systemd et al., by virtue of the integration which is apparently one of their selling points and the proprietary[0] interfaces they seem to use, look like they would create an environment where a similar switch to whatever comes next would be even harder - at least partly as a technical matter, rather than a social one. [..] I think this argument is way too far in the realm of hypotheticals to be useful. You could construct an infinite number of other hypotheticals to argue for pretty much anything. For example, what if the systemd+1 init is backwards compatible with systemd unit files, but not sysvinit scripts? Not having switched to systemd would make the transition even more painful. Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y58y2m0h@vostro.rath.org
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On Mon, Jul 22, 2013 at 07:17:04PM +0300, Uoti Urpala wrote: brian m. carlson wrote: Since Debian is always in need of developers and volunteers, it isn't objectively reasonable to expect that forking a project will be possible. One thing that needs to be taken into consideration is the *likelihood* that upstream will take development in an undesirable direction, or in a direction that is not acceptable for Debian. If you don't do development, and nobody sharing your views does either, then there's a limit to the extent you can choose your direction just by refusing to follow those that do develop things further. You can't stick with Minix forever even if you think the direction of Linux is undesirable. My point is that Debian developers create lots of great software, and certainly maintain lots of patches to software for which Debian is not upstream. But it's simply not feasible for Debian to be the upstream for all software. I don't think it's controversial to say that Debian developers prefer upstreams that take concerns relevant to Debian and its users into account. Suppose that in the future systemd does go in a direction you don't like. Now would it have done any good for Debian to not adopt it? Not really, if nobody develops a competitive alternative to its functionality. Not using it would only make Debian obsolete for most use cases. And the most realistic way to create a competitive alternative going in a different direction would be to fork systemd, so adopting current systemd would not make moving to such alternatives harder. The vast majority of the work I do on a Linux box, desktop, laptop, or server, does not involve init in any way. It is therefore not accurate to claim that using an init system other than systemd would make Debian obsolete. For example, RHEL 6 and Ubuntu use upstart, and I think it's hardly accurate, based on their significant adoption, to call them obsolete. For example, if an upstream expresses disinterest in supporting non-PC architectures, that may be a bad piece of software for Debian to place in an important role, even if it currently works on all our architectures, since Debian is very portable among different architectures. Of course, this isn't relevant to systemd, as it has no hardware- specific code and supports embedded platforms for which Debian is too bloated. This was meant as an illustrative example of a common problem with upstreams, not as a problem particular to systemd. systemd upstream has made a lot of controversial decisions that Debian may or may not want to support: combined / and /usr, the journal, logging to the kernel ring buffer, lack of portability to non-Linux kernels, and merging udev and systemd are a few examples. If Debian decides that it is preferable for whatever reason not to adopt one or more of these decisions, the willingness of upstream to accept that decision and work with Debian instead of saying, Too bad, so sad, is something that should be considered before making a major change. I'm not saying not to use systemd, I'm just suggesting making a well-reasoned decision. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Survey answers part 3: systemd is not portable and what this means for our ports
Le samedi 20 juillet 2013 à 19:21 -0400, The Wanderer a écrit : [I am almost certainly going to regret this.] I hope so. Making the switch away from the entrenched sysvinit is visibly very difficult, at least as a social matter, even in the environment we have. systemd et al., by virtue of the integration which is apparently one of their selling points and the proprietary[0] interfaces they seem to use, look like they would create an environment where a similar switch to whatever comes next would be even harder - at least partly as a technical matter, rather than a social one. Hey guys, I know this “Linux” thing is better than Minix, but it brings a lot of new features that we will be growing accustomed to. If we ever want to switch to Hurd one day, this is going to be much more complicated. This has to be one of the most twisted and bad faith arguments I ever heard in a situation of change resistance. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1374440648.4511.9.camel@tomoyo
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On Sun, Jul 21, 2013 at 11:04:08PM +0200, Josselin Mouette wrote: Le samedi 20 juillet 2013 à 19:21 -0400, The Wanderer a écrit : Making the switch away from the entrenched sysvinit is visibly very difficult, at least as a social matter, even in the environment we have. systemd et al., by virtue of the integration which is apparently one of their selling points and the proprietary[0] interfaces they seem to use, look like they would create an environment where a similar switch to whatever comes next would be even harder - at least partly as a technical matter, rather than a social one. Hey guys, I know this “Linux” thing is better than Minix, but it brings a lot of new features that we will be growing accustomed to. If we ever want to switch to Hurd one day, this is going to be much more complicated. This has to be one of the most twisted and bad faith arguments I ever heard in a situation of change resistance. Not at all. If we're looking a bit further ahead than just the immediate discussion, then this is an legitimate concern. We don't want to paint ourselves into a corner we can't get out of. With the features and interfaces systemd offers, asking the question of how we can move to something else in the future is entirely reasonable, since it's quite likely that the answer would be that it would be difficult and painful once it became pervasive and entrenched. We would be effectively locked in. -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130721214841.gc4...@codelibre.net
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 07/21/2013 05:04 PM, Josselin Mouette wrote: Le samedi 20 juillet 2013 à 19:21 -0400, The Wanderer a écrit : [I am almost certainly going to regret this.] I hope so. Please don't be a jerk. Making the switch away from the entrenched sysvinit is visibly very difficult, at least as a social matter, even in the environment we have. systemd et al., by virtue of the integration which is apparently one of their selling points and the proprietary[0] interfaces they seem to use, look like they would create an environment where a similar switch to whatever comes next would be even harder - at least partly as a technical matter, rather than a social one. Hey guys, I know this “Linux” thing is better than Minix, but it brings a lot of new features that we will be growing accustomed to. If we ever want to switch to Hurd one day, this is going to be much more complicated. My objection has nothing whatsoever to do with growing accustomed to features. (The line further down about without losing other functionality might have hinted at that fact.) It has to do with A: lock-in to the interfaces of the current proposed solution, even if those interfaces might not suit whatever comes next, and B: potential interdependency between the current proposed solution and other (theoretically distinct) elements, such that you can't replace one of them without replacing all of them - unless your replacement exactly matches all of the interfaces of the current proposed solution. I could go on at considerable length about what I mean by this and why your sarcastic counterexample does not counter it, but I seriously doubt you would be receptive, and this is probably not a good place for that discussion. (Though the places which might be more appropriate probably wouldn't welcome it either.) This has to be one of the most twisted and bad faith arguments I ever heard in a situation of change resistance. My argument may perhaps be twisted (that's at least partly a matter of perspective), but it is absolutely not in bad faith. I made my previous post partly in hopes of drawing attention to my honest concerns, and partly in hopes of having those concerns convincingly shot down - and of thereby being reassured about the idea of going forward with systemd. (As I've said, I actually like what I've read about its functionality and so forth; if those concerns could be eliminated, I'd be greatly looking forward to seeing it adopted.) This sort of sneering, hostile response does not serve to convincingly shoot down my concerns, or to reassure me about systemd. If anything, it would probably have the opposite effect. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51ec59bd.9080...@fastmail.fm
Re: Survey answers part 3: systemd is not portable and what this means for our ports
2013/7/22 Roger Leigh rle...@codelibre.net: We would be effectively locked in. We are locked in sysvinit. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/call-q8xfw+ypmuiwagmn0fmvs1ovc+zc4obdbbserurudv-...@mail.gmail.com
Re: Survey answers part 3: systemd is not portable and what this means for our ports
Игорь Пашев pashev.i...@gmail.com writes: 2013/7/22 Roger Leigh rle...@codelibre.net: We would be effectively locked in. We are locked in sysvinit. Except we're not: both systemd and upstart support sysvinit scripts. Which is why we can do a gradual migration, or even switch back and forth between various alternatives. However, the native formats of both systemd and upstart (and, for that matter, OpenRC) are mutually incompatible, so migration from one to another is much more difficult than migration from sysvinit to any of the alternatives once a substantial number of init scripts are written in the new format and the old init scripts are dropped. That's the point. I can certainly see why people may not consider that a significant drawback, or may consider other advantages more than worth that tradeoff, and indeed we do make tradeoffs like that all the time. I'm not horribly worried about it personally. But that doesn't change the fact that it *is* a potential drawback. If we adopt a single alternative and move a substantial number of the current init scripts to the new format, we have locked ourselves into that alternative in a more substantial way than we currently have (where we're using a portable, if horrible, init format that is supported by all the alternatives). Come on, everyone. We can maintain a higher quality level of discussion than this. Please stop trying to find gotchas in everyone else's statements and instead take a little time to try to understand what they're actually saying. It's perfectly fine if you disagree or weigh tradeoffs differently, but when people say that they're concerned about an issue, they're probably neither lying nor idiots. They're just concerned about a different set of things than you are. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d2qb4jzh@windlord.stanford.edu
Re: Survey answers part 3: systemd is not portable and what this means for our ports
❦ 21 juillet 2013 23:48 CEST, Roger Leigh rle...@codelibre.net : Making the switch away from the entrenched sysvinit is visibly very difficult, at least as a social matter, even in the environment we have. systemd et al., by virtue of the integration which is apparently one of their selling points and the proprietary[0] interfaces they seem to use, look like they would create an environment where a similar switch to whatever comes next would be even harder - at least partly as a technical matter, rather than a social one. Hey guys, I know this “Linux” thing is better than Minix, but it brings a lot of new features that we will be growing accustomed to. If we ever want to switch to Hurd one day, this is going to be much more complicated. This has to be one of the most twisted and bad faith arguments I ever heard in a situation of change resistance. Not at all. If we're looking a bit further ahead than just the immediate discussion, then this is an legitimate concern. We don't want to paint ourselves into a corner we can't get out of. With the features and interfaces systemd offers, asking the question of how we can move to something else in the future is entirely reasonable, since it's quite likely that the answer would be that it would be difficult and painful once it became pervasive and entrenched. We would be effectively locked in. We are currently locked in with an old and ineffective init system. It would be better to be locked in by something more modern. -- Replace repetitive expressions by calls to a common function. - The Elements of Programming Style (Kernighan Plauger) pgpCJAzPquwqJ.pgp Description: PGP signature
Re: Survey answers part 3: systemd is not portable and what this means for our ports
2013/7/22 Russ Allbery r...@debian.org: Игорь Пашев pashev.i...@gmail.com writes: 2013/7/22 Roger Leigh rle...@codelibre.net: We would be effectively locked in. We are locked in sysvinit. Except we're not: both systemd and upstart support sysvinit scripts. Which is why we can do a gradual migration, or even switch back and forth between various alternatives. However, the native formats of both systemd and upstart (and, for that matter, OpenRC) are mutually incompatible, so migration from one to another is much more difficult than migration from sysvinit to any of the alternatives once a substantial number of init scripts are written in the new format and the old init scripts are dropped. That's the point. I can certainly see why people may not consider that a significant drawback, or may consider other advantages more than worth that tradeoff, and indeed we do make tradeoffs like that all the time. I'm not horribly worried about it personally. But that doesn't change the fact that it *is* a potential drawback. If we adopt a single alternative and move a substantial number of the current init scripts to the new format, we have locked ourselves into that alternative in a more substantial way than we currently have (where we're using a portable, if horrible, init format that is supported by all the alternatives). Well, if a new alternative is written in future, and there already is a substantial number of scripts in $format, it will almost certainly support these, and we can migrate away to the new system. It will be the same situation as we currently have sith SysV-Init. So I wouldn't worry about this at all :-) Regards, Matthias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caknhny9fvwc4thez6jmn8cezkhdrnzootxmhwxvfk37f1vg...@mail.gmail.com
Re: Survey answers part 3: systemd is not portable and what this means for our ports
The Wanderer wrote: On 07/21/2013 05:04 PM, Josselin Mouette wrote: Le samedi 20 juillet 2013 à 19:21 -0400, The Wanderer a écrit : Making the switch away from the entrenched sysvinit is visibly very difficult, at least as a social matter, even in the environment we have. systemd et al., by virtue of the integration which is apparently one of their selling points and the proprietary[0] interfaces they seem to use, look like they would create an environment where a similar switch to whatever comes next would be even harder - at least partly as a technical matter, rather than a social one. Hey guys, I know this “Linux” thing is better than Minix, but it brings a lot of new features that we will be growing accustomed to. If we ever want to switch to Hurd one day, this is going to be much more complicated. My objection has nothing whatsoever to do with growing accustomed to features. (The line further down about without losing other functionality might have hinted at that fact.) I think the Minix comparison is still a very valid one, whatever the exact reasons are that you fear will make a future switch harder. Let's assume there are very valid technical reasons why you think switching to Linux will make a future move to Hurd harder than switching directly from Minix would have been. Is this a good reason to stay with Minix for now? I think the above is a good parallel for the systemd situation. The current alternatives are simply much worse than systemd. Staying with them in the hope of some possible benefit in the far future is not sane. This has to be one of the most twisted and bad faith arguments I ever heard in a situation of change resistance. My argument may perhaps be twisted (that's at least partly a matter of perspective), but it is absolutely not in bad faith. I made my previous post partly in hopes of drawing attention to my honest concerns, and partly in hopes of having those concerns convincingly shot down - and of thereby being reassured about the idea of going forward with systemd. (As I've said, I actually like what I've read about its functionality and so forth; if those concerns could be eliminated, I'd be greatly looking forward to seeing it adopted.) Whether your argument was honest or not, I think it was a bad one. OK, perhaps you have concerns about the philosophy behind systemd and where that might take it in the future. Such philosophy issues are rather subjective. But your argument objectively fails at the ... and therefore moving to systemd may not be the right choice part. Your concerns, even if taken seriously, do justify such a conclusion. If systemd development goes in a direction you don't like, the rational answer is to fork it and do better if you can. Leaving Debian behind with an inferior init system is not an answer to your concerns. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1374451160.21442.60.camel@glyph.nonexistent.invalid
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 07/21/2013 07:06 PM, Matthias Klumpp wrote: 2013/7/22 Russ Allbery r...@debian.org: Игорь Пашев pashev.i...@gmail.com writes: We are locked in sysvinit. Except we're not: both systemd and upstart support sysvinit scripts. Which is why we can do a gradual migration, or even switch back and forth between various alternatives. However, the native formats of both systemd and upstart (and, for that matter, OpenRC) are mutually incompatible, so migration from one to another is much more difficult than migration from sysvinit to any of the alternatives once a substantial number of init scripts are written in the new format and the old init scripts are dropped. That's the point. I can certainly see why people may not consider that a significant drawback, or may consider other advantages more than worth that tradeoff, and indeed we do make tradeoffs like that all the time. I'm not horribly worried about it personally. But that doesn't change the fact that it *is* a potential drawback. Thank you for understanding the idea. I don't know if I'd even consider it a critical, fatal drawback myself; if we do end up moving to systemd without this concern having been addressed, I'm not likely to raise a screaming fit or go tearing my hair out over it or anything. But I would probably still go forward with a niggling sense of discomfort, a sense that things aren't quite right, that my world doesn't quite fit me the way it should - there's a screw loose somewhere, there is a leak in the tank, if that conveys the idea. If we adopt a single alternative and move a substantial number of the current init scripts to the new format, we have locked ourselves into that alternative in a more substantial way than we currently have (where we're using a portable, if horrible, init format that is supported by all the alternatives). Well, if a new alternative is written in future, and there already is a substantial number of scripts in $format, it will almost certainly support these, and we can migrate away to the new system. My concern in that context is that having to support that format could impose a limitation on the ability of the new alternative to provide added functionality, just as having to live within the constraints of sysvinit would (and, for the fallback case, ISTR allegedly does) impose limits on the benefits that systemd can provide. The potential need to also interoperate with the various other things with which systemd apparently integrates (e.g. journald, and I think other things - which may eventually include udev) *in the same way that systemd then does* seems like it could also impose an even stronger limitation on potential functionality; either you'd have to limit your functionality to what that interoperation would support, or you'd have to either fork those other things or implement replacements for them as well. Either would make the process of implementing a new alternative much bigger than just implementing a new init system; any new alternative would then have to jump over considerably bigger hurdles than systemd did. It will be the same situation as we currently have sith SysV-Init. So I wouldn't worry about this at all :-) Isn't the current situation with trying to migrate from sysvinit plenty bad enough? -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51ec7b9d.10...@fastmail.fm
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 07/21/2013 06:12 PM, Игорь Пашев wrote: 2013/7/22 Roger Leigh rle...@codelibre.net: We would be effectively locked in. We are locked in sysvinit. Agreed, to an extent we are. And you can see how hard it's being to migrate away from that, even once alternatives have been implemented. I'm saying that it looks to me as if the lock-in to systemd would be even stronger than the lock-in to sysvinit, and might well extend to the point of even making it harder to implement another new alternative in the first place. If someone implementing a new alternative wanted to retain the other tools with which systemd integrates, that person would have to match their interfaces, which might limit the functionality the new alternative could be able to provide - much as having to match the sysvinit interfaces would seem to limit the functionality systemd can provide. If someone implementing a new alternative didn't want to retain those tools, then since those tools would have by then come to replace all the non-integrated tools which now perform (lesser versions of?) the same roles, that person would have to implement alternatives to all of them as well - a potentially much bigger job than just implementing a new init system. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51ec7b61.5000...@fastmail.fm
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On Mon, Jul 22, 2013 at 02:59:20AM +0300, Uoti Urpala wrote: Whether your argument was honest or not, I think it was a bad one. OK, perhaps you have concerns about the philosophy behind systemd and where that might take it in the future. Such philosophy issues are rather subjective. But your argument objectively fails at the ... and therefore moving to systemd may not be the right choice part. Your concerns, even if taken seriously, do justify such a conclusion. If systemd development goes in a direction you don't like, the rational answer is to fork it and do better if you can. Leaving Debian behind with an inferior init system is not an answer to your concerns. Since Debian is always in need of developers and volunteers, it isn't objectively reasonable to expect that forking a project will be possible. One thing that needs to be taken into consideration is the *likelihood* that upstream will take development in an undesirable direction, or in a direction that is not acceptable for Debian. For example, if an upstream expresses disinterest in supporting non-PC architectures, that may be a bad piece of software for Debian to place in an important role, even if it currently works on all our architectures, since Debian is very portable among different architectures. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On Sun, Jul 21, 2013 at 05:59:25PM -0400, The Wanderer wrote: On 07/21/2013 05:04 PM, Josselin Mouette wrote: Le samedi 20 juillet 2013 à 19:21 -0400, The Wanderer a écrit : [I am almost certainly going to regret this.] I hope so. Please don't be a jerk. Making the switch away from the entrenched sysvinit is visibly very difficult, at least as a social matter, even in the environment we have. systemd et al., by virtue of the integration which is apparently one of their selling points and the proprietary[0] interfaces they seem to use, look like they would create an environment where a similar switch to whatever comes next would be even harder - at least partly as a technical matter, rather than a social one. Hey guys, I know this “Linux” thing is better than Minix, but it brings a lot of new features that we will be growing accustomed to. If we ever want to switch to Hurd one day, this is going to be much more complicated. My objection has nothing whatsoever to do with growing accustomed to features. (The line further down about without losing other functionality might have hinted at that fact.) It has to do with A: lock-in to the interfaces of the current proposed solution, even if those interfaces might not suit whatever comes next, and B: potential interdependency between the current proposed solution and other (theoretically distinct) elements, such that you can't replace one of them without replacing all of them - unless your replacement exactly matches all of the interfaces of the current proposed solution. Hi, I think that in the end you are worried about lock-in due to features, not anything else. Replacing systemd, in part or in whole, is hard only because of compelling features, not found in other systems. There is no classical lock-in in the sense of e.g. undocumented and brittle interfaces, APIs or syntax, or the inability to retrieve existing data. The unit syntax is trivial to parse, meaning of various items is documented, and in general it is pretty easy to substitue one provider of a dbus interface for another. A similar situation is true in the case of the journal, which (for producers) provides just a few simple C functions. And there *are* examples of piecewise replacement: - Ubuntu is using just logind, without using systemd. Probably the hardest part is building journald cleanly, without the rest of systemd. And if you were implementing a replacemnt, this problem wouldn't exist. - rsyslog provides a replacement of the journal logging API, allowing one to use journal logging functions on systemd-journald-less systemd. - rsyslog slurps journal files, so if for whatever reason you wanted to stop even using journalctl, you could pull in the data into another logging solution from disk without any trouble. (There are other ways to retrieve this data, but I mention this one because it is a different program reading the same data, i.e. a reimplementation.) Zbyszek -- they are not broken. they are refucktored -- alxchk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130722023959.gi28...@in.waw.pl
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 07/20/2013 07:39 AM, Adam Borowski wrote: So why do we even discuss popcon data here Because John Paul Adrian Glaubitz started writing about it, and defended strongly that it is be data we should consider... He is currently alone defending that opinion. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51ea2e06.8000...@debian.org
not really vaporware but almost (Re: Survey answers part 3: systemd is not portable and what this means for our ports
Hi, On Samstag, 20. Juli 2013, Thomas Goirand wrote: The problem isn't that OpenRC isn't fit. The problem is that *NONE* of the projects are fitting *ALL* of our requirements. All of the 3 solutions have problems. so, there is systemd and there is upstart. what is the 3rd solution? After having read http://wiki.debian.org/OpenRC and looking at the packaging, I would like you to stop speaking about openrc for Debian as if existed. (In case you curious, read the paragraph labeled Compile Out OpenRC on that wiki page and clone git://anonscm.debian.org/collab-maint/openrc.git and read debian/openrc.postinst.) So pleease, stop hyping something which is not even remotely ready, until it at least is installable with git clone debuild or better yet, until it passed NEW. Oh, and there should also be a sane way to remove openrc after trying it. Restoring from backup is not such a way. cheers, Holger, who thinks the 3rd solution must by SysV-init signature.asc Description: This is a digitally signed message part.
Re: Survey answers part 3: systemd is not portable and what this means for our ports
Le samedi 20 juillet 2013 à 13:40 +0800, Thomas Goirand a écrit : The problem isn't that OpenRC isn't fit. The problem is that *NONE* of the projects are fitting *ALL* of our requirements. What requirements are you talking about? Which requirements are not met by systemd? If this is about kFreeBSD, it would be nice and all to share the init system with these ports, but it should certainly not have an influence on the choice of init system for the Linux ports. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1374312478.4511.2.camel@tomoyo
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On Sat, 20 Jul 2013 11:27:58 +0200, Josselin Mouette j...@debian.org wrote: If this is about kFreeBSD, it would be nice and all to share the init system with these ports, but it should certainly not have an influence on the choice of init system for the Linux ports. Why? Grüße Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1v0w5w-0004xv...@swivel.zugschlus.de
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On Samstag, 20. Juli 2013, Marc Haber wrote: Why? http://lists.debian.org/debian-devel/2013/05/msg00725.html signature.asc Description: This is a digitally signed message part.
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On Fri, Jul 19, 2013 at 11:14 PM, Russ Allbery r...@debian.org wrote: I would *hope* a lot of Debian developers would do things like that, for any of the options! There's no substitute for actually trying the software and seeing how easy it is to use, how well it works, and how difficult it is to support. There are a bunch of good reasons to install packages, even if one isn't going to use them regularly. Among other things, it's often the easiest way to read the documentation so that one knows what people are even talking about! JFTR I did that (I already know upstart quite well from Ubuntu, so I just did install systemd on my work machine) and now I am replacing sysvinit with systemd on every machine I maintain. I have missed a supervised services from init(1) for too long (I can only +1 to Russ's mail about experiences with administration) and I have already used that to supervise crashing gitlab-sidekiq service. I also did add support for systemd and upstart to php5-fpm (and kept sysvinit script) and I am quite confident I can support all three of them without any trouble. It has a learning curve, but I am willing to learn that (sysvinit scripts also have a learning curve - the idea that those are just simple shell scripts are just wrong.) And if I could use upstart job to extort Ubuntu PHP maintainers to contribute back more, even better! :) Anyway - this is the question for all proponents of systemd and upstart. It's quite obvious that we cannot reach full consensus (and we never will be able to reach one), but we have a body to make technical decisions - tech-ctte. Why we just don't shove it to tech-ctte and let the independent body decide? (Or GR, but I think that GR is an overkill.) This could stop this endless debate and force the participants to write the technical summary. O. -- Ondřej Surý ond...@sury.org
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 20 July 2013 08:17, Marc Haber mh+debian-de...@zugschlus.de wrote: On Sat, 20 Jul 2013 11:27:58 +0200, Josselin Mouette j...@debian.org wrote: If this is about kFreeBSD, it would be nice and all to share the init system with these ports, but it should certainly not have an influence on the choice of init system for the Linux ports. Why? Because http://lists.debian.org/debian-devel/2013/07/msg00379.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAajCMYX_wABY-TsZd0=Ga+rBK7BCq-t6KC8chXASDXnFgN=r...@mail.gmail.com
Re: Survey answers part 3: systemd is not portable and what this means for our ports
(On my phone, I hate this ui, sorry for the CC Russ) On Jul 19, 2013 5:30 PM, Russ Allbery r...@debian.org wrote: David Kalnischkies kalnischk...@gmail.com writes: Of course, both analysis are obviously flawed as this popcon data can't really be interpreted that way as its an apple to banana comparison and way too few datapoints, but everyone likes misinterpret statistics as proven by this thread – and statistics say that I am a pro-faker! I only believe in statistics that I doctored myself. -- Winston Churchill [...] P.S.: Everyone who is now trying to disprove my facts has missed the point. Yes, exactly. The point is that none of this really means very much at this point, for a whole bunch of reasons. Ways to use non-sysvinit init systems are not widely publicized, neither upstart nor systemd are (yet) that widely supported, and both are quite firmly experimental configurations at this point. There's nothing *wrong* with that; it just means that if you're trying to use popcon as a democratic vote on which one people like better, there's simply no data there. We're still very much in the installing things to try them out stage. For example, as soon as I get my new laptop back from servicing, the systemd numbers will go up by one, because I want to try running it for a while so that my opinions are based on facts and so that I can start adding systemd unit files to some of my packages. I don't have the same level of need to do so for upstart because I can see upstart on Ubuntu boxes, although I'm looking around for a good system to run with upstart for a while as well for similar reasons. None of those really constitute user choices or votes or whatnot for that particular init system. I would *hope* a lot of Debian developers would do things like that, for any of the options! There's no substitute for actually trying the software and seeing how easy it is to use, how well it works, and how difficult it is to support. There are a bunch of good reasons to install packages, even if one isn't going to use them regularly. Among other things, it's often the easiest way to read the documentation so that one knows what people are even talking about! Yes. This. I was a pretty avid syatemd hater, but having used it for a solid 6 months, I can't imagine using anything else. I find myself installing systemd as one of the first things I do when I get a new install. If you're laying down systemd criticism - *try* systemd for a month. My 2c, T P.s. sorry if this comes out HTML. Maybe at some point in the future when whatever options we've converged on have been widely publicized and everyone knows how to switch and test and whatnot we might be able to gauge something about levels of interest from popcon. But it's going to be a while before we're at that point. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ip06fe1e@windlord.stanford.edu
Re: Survey answers part 3: systemd is not portable and what this means for our ports
2013/7/20 Paul Tagliamonte paul...@debian.org: Yes. This. I was a pretty avid syatemd hater, but having used it for a solid 6 months, I can't imagine using anything else. I find myself installing systemd as one of the first things I do when I get a new install. If you're laying down systemd criticism - *try* systemd for a month. Me too - I was never a hater, I always loved the idea and concept of logind and systemd, but I was sceptical about the benefits of e.g. the journal and the dbus integration (and I also feared that too much functionality would be moved into PID 1). This has changed immediately after I started to use the features it provides :P I now run rsyslog and the journal in parallel, while I previously disabled it. I also just *love* the multiseat capacities systemd provides, and the separation of user-written units and distributor-provided systemd-units (you can still easily display differences by using a systemd-tool). And for developers of DEs, logind is just great ;-) (admittedly, I always hated ConsoleKIt ^^) Also, I don't find upstream very hostile - even the most stupid questions were answered with patience, and Lennart even resembled some of the concepts for me on IRC, when I asked some really silly questions about cgroups and the systemd design decisions about a year ago. The documentation is very good too (and now, since Google doesn not consider systemd a typo anymore, you can also easily find it online, if you don't want to install the manual pages) I would recommend trying systemd in a VM to see what changes it brings :-) (make sure sd is recent enough (= 204)) Cheers, Matthias -- I welcome VSRE emails. See http://vsre.info/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKNHny-ZCZWyF2bju4seK+Ft8Qh8L2p7c-YvpZ=2egoii4v...@mail.gmail.com
Re: Survey answers part 3: systemd is not portable and what this means for our ports
[I am almost certainly going to regret this.] On 07/20/2013 12:52 PM, Paul Tagliamonte wrote: (On my phone, I hate this ui, sorry for the CC Russ) On Jul 19, 2013 5:30 PM, Russ Allbery r...@debian.org wrote: I would *hope* a lot of Debian developers would do things like that, for any of the options! There's no substitute for actually trying the software and seeing how easy it is to use, how well it works, and how difficult it is to support. There are a bunch of good reasons to install packages, even if one isn't going to use them regularly. Among other things, it's often the easiest way to read the documentation so that one knows what people are even talking about! Yes. This. I was a pretty avid syatemd hater, but having used it for a solid 6 months, I can't imagine using anything else. I find myself installing systemd as one of the first things I do when I get a new install. If you're laying down systemd criticism - *try* systemd for a month. For my part, despite having not personally used it I'm not (and haven't recently, and I hope ever, been) opposed to systemd's functionality, or even necessarily to its design - just to its apparent philosophy, and where that philosophy might take it (and anyone who adopts and therefore comes to rely on it) in the future. Leaving aside fears about what upstream might decide to do at some point (e.g. the make udev require systemd proposal), much of that objection simply comes down to how difficult it looks like it would be to switch *away* from systemd, once it becomes entrenched. Making the switch away from the entrenched sysvinit is visibly very difficult, at least as a social matter, even in the environment we have. systemd et al., by virtue of the integration which is apparently one of their selling points and the proprietary[0] interfaces they seem to use, look like they would create an environment where a similar switch to whatever comes next would be even harder - at least partly as a technical matter, rather than a social one. Similarly, in an environment where systemd is entrenched, setting up a system which doesn't use it (for whatever reason that might be desirable, e.g. a toy system of some sort or an experimental environment or a system with extremely limited resources) without losing other functionality looks like it might be considerably harder than setting up something which doesn't use sysvinit without losing functionality not provided by the init scripts currently is. I could easily be wrong about both of those, and I hope I am, but so far I don't think I've seen anything which even tries to convince me otherwise. [0] Meaning approximately we create our own language and talk it to ourselves, and anyone else who wants to talk to us has to learn our language, not intending to imply undocumented or legally restricted or anything of the sort. This isn't a very good term for what I mean, but I couldn't find a better one. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51eb1b7d.8090...@fastmail.fm
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 07/19/2013 08:32 AM, John Paul Adrian Glaubitz wrote: On 07/18/2013 09:45 PM, Thomas Goirand wrote: If OpenRC isn't what we need (I still believe it does address a bunch of problems and that the fact it can work for non-Linux port is a key factor), then I'd be for Upstart. I do maintain my packages so that they work for both Ubuntu and Debian, having to write things for 2 init systems would be useless added work. Popcon however speaks a completely different language: Even if that was truth (Russ showed it might not), I don't see how this is a counter argument to what I wrote. Besides this, this is not a voting system: if we were governed only by a majority of users, we would all be running Windows. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51e8f58f.7060...@debian.org
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On Thu, July 18, 2013 09:15, Thomas Goirand wrote: - Fast startup I thought everyone claimed (including systemd supporters) that this was a teenager side effect which we didn't care much about. Definitely not. Debian should care about fast boot a lot. Rebooting a system, planned or not, is downtime. If we can reduce the amount of downtime that Debian systems experience, that is a big win. Someone mentioned server POST that take minutes of boot time anyway. True. However, this ignores that the world and their dog are moving to virtual machines en masse for hosting their services. The boot times of vm's are negligible and we now have many systems rebooting in 1 min. This is a very big advantage for professional and large scale installations, and the more that time is reduced, the more advantageous it will be for these users. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/9fc621eb254d5515cfac75075e4918c5.squir...@aphrodite.kinkhorst.nl
Re: Survey answers part 3: systemd is not portable and what this means for our ports
]] Russ Allbery The upstart package takes over process 1, so 100% of the systems with the upstart package installed are using it as process 1. The same is true of systemd-sysv, of course. This isn't necessarily true. I used to run my laptop with systemd as pid 1 and the upstart package installed, for historical reasons (it used to run Ubuntu and was upgraded to Debian). I agree that's not a reasonable configuration, though. I don't think there's a way to do a straight apples to apples comparison on adoption based on the current popcon numbers. The number of people running systemd is more than the install count of systemd-sysv, but less (and I suspect much less) than the install count of systemd. Correct. We are not talking about a huge number of systems in any case (for either systemd or upstart). -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m2ehau3orc@rahvafeir.err.no
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 07/19/2013 10:15 AM, Thomas Goirand wrote: Popcon however speaks a completely different language: Even if that was truth (Russ showed it might not), I don't see how this is a counter argument to what I wrote. Besides this, this is not a voting system: if we were governed only by a majority of users, we would all be running Windows. Jeez, and I was honestly thinking all the time that Debian was a community project which has a democratic organization and larger decisions are primarily made with our users in mind. I thought we were making software which is to be useful for our users in the end, but it turns out that according to your line of arguments, Debian is primarily made to fuel the egos of its developers. Guess, I am in the wrong project then. Cheers, Adrian -- .''`. 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51e905ef.5080...@physik.fu-berlin.de
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On Fri, Jul 19, 2013 at 10:50:36AM +0200, Thijs Kinkhorst wrote: On Thu, July 18, 2013 09:15, Thomas Goirand wrote: - Fast startup I thought everyone claimed (including systemd supporters) that this was a teenager side effect which we didn't care much about. Definitely not. Debian should care about fast boot a lot. Rebooting a system, planned or not, is downtime. If we can reduce the amount of downtime that Debian systems experience, that is a big win. Someone mentioned server POST that take minutes of boot time anyway. True. However, this ignores that the world and their dog are moving to virtual machines en masse for hosting their services. The boot times of vm's are negligible and we now have many systems rebooting in 1 min. This is a very big advantage for professional and large scale installations, and the more that time is reduced, the more advantageous it will be for these users. It's also worth noting that kexec-based reboots (if they work properly) can eliminate POST time, but still has to go through the whole init run. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Re: Survey answers part 3: systemd is not portable and what this means for our ports
Hi William, William Giokas 1007...@gmail.com writes: * 'Graphical UI: yes': Nope. side note: it is from http://0pointer.de/blog/projects/why.html Cheers, Benda pgpLYHGdS_e5Z.pgp Description: PGP signature
Re: Survey answers part 3: systemd is not portable and what this means for our ports
2013/7/19 Russ Allbery r...@debian.org: John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de writes: On 07/19/2013 02:55 AM, Russ Allbery wrote: I believe the equivalent systemd package to the upstart package is the systemd-sysv package, so 174 rather than 1604 is perhaps the better number to use. I'm not sure whether I can follow. I am using systemd on both my desktop and my laptop and neither of them has the systemd-sysv package installed which, AFAIK, is required for compatibility reasons only. I see no sign that installing systemd replaces init or takes over process 1. All of the symlinks to do so are in the systemd-sysv package, and that's the only package that conflicts with sysvinit and thereby removes the other init system. Am I missing something? checks Ah, here we go: | systemd can be installed alongside sysvinit and will not change the | behaviour of the system out of the box. This is intentional. To test | systemd, add: | | init=/bin/systemd | | to the kernel command line and then rebooting, or install the | systemd-sysv package. I didn't know about the init= method and was assuming the systemd-sysv method. Anyway, my point is that I suspect the vast majority of the systems with the systemd package installed are not actually using it as process 1. The upstart package takes over process 1, so 100% of the systems with the upstart package installed are using it as process 1. The same is true of systemd-sysv, of course. I don't think there's a way to do a straight apples to apples comparison on adoption based on the current popcon numbers. The number of people running systemd is more than the install count of systemd-sysv, but less (and I suspect much less) than the install count of systemd. As the recommended way to install systemd is using init= and not installing systemd-sysv, maybe the popcon vote count is the correct metric? NB: vote is the number of people who use this package regularly According http://qa.debian.org/popcon-graph.php?packages=upstart%2Csystemdfrom_date=2013-06-06: systemd is used regulardly on about 1200 popcon submiters, upstart on about 600 (this is even less than 100 from 2013-07-04, but what happened!). Regards -- Mathieu Parent -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAFX5sbyeJzuOVkEXhQZYVgxYtrab-QUxmJP==b=uj0cfaqe...@mail.gmail.com
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 07/19/2013 06:57 PM, Scott Kitterman wrote: sysvinit148865 99.83% The reason might be that systemd does not conflict with sysvinit :). Adrian -- .''`. 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51e9751c.9030...@physik.fu-berlin.de
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 07/19/2013 06:43 PM, John Paul Adrian Glaubitz wrote: On 07/19/2013 05:43 PM, Thomas Goirand wrote: We try to have technical reasoning, which is (one of) the reason this list exists. This has nothing to do with voting. If we actually did, the choice would have already been made for systemd long time ago. Don't make yourself any illusions. It has been explained to you by many people before that OpenRC isn't fit for the purpose at all and I really don't think upstart will meet the criteria either. I thought we were making software which is to be useful for our users in the end,... That is the case, but not using popcon as a metric to our technical decisions. Well, technical reasons are obviously not counted in. ...but it turns out that according to your line of arguments, Debian is primarily made to fuel the egos of its developers. Now you are crossing the line. No, I am not. How often do I have to read people claiming that systemd is a bad project because they don't like their upstream authors? Honestly, I do not care about upstream at all, but I'm still concerned about systemd (as well as about upstart). I had sufficient issues with upstart before - stopping to boot and not telling about its current state is from my point of view a show-stopper. And from my point of view it is irrelevant if there are underlying bugs. Important is that it helps the admin to figure out what went wrong and how this can be solved or worked-around. So upstart leaves a mostly blank screen without a console. What is systemd going to do if something fails? How does it help me if it crashes? How am I'm going to bring up a basic system then. Thanks, Bernd -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51e97c73.8070...@aakef.fastmail.fm
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On Friday, July 19, 2013 06:35:48 PM John Paul Adrian Glaubitz wrote: On 07/19/2013 06:12 PM, Mathieu Parent wrote: As the recommended way to install systemd is using init= and not installing systemd-sysv, maybe the popcon vote count is the correct metric? Plus, systemd isn't pulled in by anything else which means when it's there it's there because it was actively installed. I don't think it magically lands onto a user's hard disk or someone installs it just in order to not use it actually. systemd is used regulardly on about 1200 popcon submiters, upstart on about 600 (this is even less than 100 from 2013-07-04, but what happened!). Like several people pointed out before, the popcon entries for the Ubuntu upstart package pointed to Debian which at a particular time which resulted in wrong data being sent to popcon. The data that we have now is the actual data and it shows upstart isn't very popular. sysvinit148865 99.83% Neither is systemd. The numbers for either are small enough to be meaningless. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1559462.SK62LhKSUs@scott-latitude-e6320
Re: Survey answers part 3: systemd is not portable and what this means for our ports
Scott Kitterman wrote: On Friday, July 19, 2013 06:35:48 PM John Paul Adrian Glaubitz wrote: On 07/19/2013 06:12 PM, Mathieu Parent wrote: systemd is used regulardly on about 1200 popcon submiters, upstart on about 600 (this is even less than 100 from 2013-07-04, but what happened!). Like several people pointed out before, the popcon entries for the Ubuntu upstart package pointed to Debian which at a particular time which resulted in wrong data being sent to popcon. The data that we have now is the actual data and it shows upstart isn't very popular. sysvinit 148865 99.83% Neither is systemd. The numbers for either are small enough to be meaningless. The 99.83% percentage is meaningless as sysvinit is typically installed even on those machines that use systemd. When considering the absolute numbers, you need to take into account that a large portion of popcon reporters have old installations or aren't in any sense developers or system administrators; those are not even potentially target audience for manually installing a new init system. For a different perspective, systemd has currently 1602 installs, and gcc-4.8 (has been default GCC version for over a month) has 3809. gdb has 27116 (a large portion of those likely old systems that are not being actively updated); systemd is over 5% of that. I think a better comparison would be to pick some packages that are typically manually installed by developers or sysadmins, choose only the systems which contain recently updated versions of those packages, and then see what portion of those systems have systemd installed. But AFAIK the public popcon data does not contain such information about package relationships. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1374258109.21442.34.camel@glyph.nonexistent.invalid
Re: Survey answers part 3: systemd is not portable and what this means for our ports
John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de wrote: On 07/19/2013 06:57 PM, Scott Kitterman wrote: sysvinit 148865 99.83% The reason might be that systemd does not conflict with sysvinit :). So are we playing word games now or trying to solve a problem? According to the popcon data, neither systemd nor upstart have enough deployment to be considered anything other than essentially zero. It really shouldn't be a factor at all (I don't have an opinion on the right answer, just that this is irrelevant). Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5498f324-b641-4a2c-9aee-7b2441766...@email.android.com
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 07/19/2013 05:43 PM, Thomas Goirand wrote: We try to have technical reasoning, which is (one of) the reason this list exists. This has nothing to do with voting. If we actually did, the choice would have already been made for systemd long time ago. Don't make yourself any illusions. It has been explained to you by many people before that OpenRC isn't fit for the purpose at all and I really don't think upstart will meet the criteria either. I thought we were making software which is to be useful for our users in the end,... That is the case, but not using popcon as a metric to our technical decisions. Well, technical reasons are obviously not counted in. ...but it turns out that according to your line of arguments, Debian is primarily made to fuel the egos of its developers. Now you are crossing the line. No, I am not. How often do I have to read people claiming that systemd is a bad project because they don't like their upstream authors? What else is it other than a hurt ego if some people can't cope with the fact that both PulseAudio and systemd are actually useful software? What's the point in delaying the decision over and over again? 1/ Don't put words in my mouth which I never used. 2/ Try to write more useful things. Doing personal attacks doesn't help. Says the guy who posted this to back up his chain of arguments: http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems Adrian -- .''`. 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51e96caf.50...@physik.fu-berlin.de
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 07/19/2013 07:47 PM, Scott Kitterman wrote: John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de wrote: On 07/19/2013 06:57 PM, Scott Kitterman wrote: sysvinit148865 99.83% The reason might be that systemd does not conflict with sysvinit :). So are we playing word games now or trying to solve a problem? According to the popcon data, neither systemd nor upstart have enough deployment to be considered anything other than essentially zero. I don't understand why anyone would assume that the popcon data in this context is not accurate. Again, sysvinit is essential, systemd is not and it doesn't have any reverse dependencies. Thus, every counted systemd installation was actually actively performed. Adrian -- .''`. 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51e98a07.5070...@physik.fu-berlin.de
Re: Survey answers part 3: systemd is not portable and what this means for our ports
David Kalnischkies kalnischk...@gmail.com writes: Of course, both analysis are obviously flawed as this popcon data can't really be interpreted that way as its an apple to banana comparison and way too few datapoints, but everyone likes misinterpret statistics as proven by this thread – and statistics say that I am a pro-faker! I only believe in statistics that I doctored myself. -- Winston Churchill [...] P.S.: Everyone who is now trying to disprove my facts has missed the point. Yes, exactly. The point is that none of this really means very much at this point, for a whole bunch of reasons. Ways to use non-sysvinit init systems are not widely publicized, neither upstart nor systemd are (yet) that widely supported, and both are quite firmly experimental configurations at this point. There's nothing *wrong* with that; it just means that if you're trying to use popcon as a democratic vote on which one people like better, there's simply no data there. We're still very much in the installing things to try them out stage. For example, as soon as I get my new laptop back from servicing, the systemd numbers will go up by one, because I want to try running it for a while so that my opinions are based on facts and so that I can start adding systemd unit files to some of my packages. I don't have the same level of need to do so for upstart because I can see upstart on Ubuntu boxes, although I'm looking around for a good system to run with upstart for a while as well for similar reasons. None of those really constitute user choices or votes or whatnot for that particular init system. I would *hope* a lot of Debian developers would do things like that, for any of the options! There's no substitute for actually trying the software and seeing how easy it is to use, how well it works, and how difficult it is to support. There are a bunch of good reasons to install packages, even if one isn't going to use them regularly. Among other things, it's often the easiest way to read the documentation so that one knows what people are even talking about! Maybe at some point in the future when whatever options we've converged on have been widely publicized and everyone knows how to switch and test and whatnot we might be able to gauge something about levels of interest from popcon. But it's going to be a while before we're at that point. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ip06fe1e@windlord.stanford.edu
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On Fri, Jul 19, 2013 at 8:48 PM, John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de wrote: On 07/19/2013 07:47 PM, Scott Kitterman wrote: John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de wrote: On 07/19/2013 06:57 PM, Scott Kitterman wrote: sysvinit148865 99.83% The reason might be that systemd does not conflict with sysvinit :). So are we playing word games now or trying to solve a problem? According to the popcon data, neither systemd nor upstart have enough deployment to be considered anything other than essentially zero. I don't understand why anyone would assume that the popcon data in this context is not accurate. Again, sysvinit is essential, systemd is not and it doesn't have any reverse dependencies. Thus, every counted systemd installation was actually actively performed. Oh, really? Because its the second time you claim that? apt-cache rdepends systemd --important --no-conflicts --no-breaks -o APT::Cache::ShowDependencyType=1 Granted, the rdependencies in stable/testing/unstable are all alternatives in the second position which can be easily solved otherwise. But we have also gnome-settings-daemon in experimental which depends without an alternative on it. Now, if you look really close on the popcon data for systemd you see that in March 2013 there is a plateau reached for systemd, which suddenly at the end of the month is followed by the constant up – which neatly alines with the upload of the previously mentioned gnome-settings-daemon to experimental with a systemd dependency. So, what do you think: More people wanting to testdrive GNOME 3.8 or systemd? Oh, and while you have the graph open: Do you see the bump in the graph at the end of May? Lets guess when the systemd survey was… so we can assume that a lot people installed systemd to test it for the survey and it worked so great that they not only not continued to use it, but have also actively deinstalled it again – even though you don't have to, like for upstart which doesn't seem to have obvious bumps (beside the ubuntu misreporting) so everyone installing it sticked with it… I will leave the obvious conclusion as an exercise for the reader. Of course, both analysis are obviously flawed as this popcon data can't really be interpreted that way as its an apple to banana comparison and way too few datapoints, but everyone likes misinterpret statistics as proven by this thread – and statistics say that I am a pro-faker! I only believe in statistics that I doctored myself. -- Winston Churchill Best regards David Kalnischkies P.S.: Everyone who is now trying to disprove my facts has missed the point. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fbmbdhcruh+m4k-6m3wvkg3pezm1ursg0jvbexd-jo...@mail.gmail.com
Re: Survey answers part 3: systemd is not portable and what this means for our ports
Dear Russ, Russ Allbery r...@debian.org writes: I would *hope* a lot of Debian developers would do things like that, for any of the options! There's no substitute for actually trying the software and seeing how easy it is to use, how well it works, and how difficult it is to support. There are a bunch of good reasons to install packages, even if one isn't going to use them regularly. Among other things, it's often the easiest way to read the documentation so that one knows what people are even talking about! Maybe at some point in the future when whatever options we've converged on have been widely publicized and everyone knows how to switch and test and whatnot we might be able to gauge something about levels of interest from popcon. But it's going to be a while before we're at that point. Your objective thinking is much appreciated! Actually I was thinking of setting up test environments of systemd upstart, OpenRC (and other candidates?) on Debian development boxes (or some third party boxes which is open to DD), when Steve (excuse me for not digging out your original words) mentioned in this thread that we need a _modern_ init system which can handle race conditions in a sophiscated setup (NFS, aufs, as / /usr etc.) reliably and expected OpenRC would fail in this realm. Then we can prove our points in public and open to peer review that something is not suited for such and such. Is it realistic? Yours, Benda -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8761w6dwrk@proton.in.awa.tohoku.ac.jp
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 07/19/2013 05:25 PM, John Paul Adrian Glaubitz wrote: On 07/19/2013 10:15 AM, Thomas Goirand wrote: Popcon however speaks a completely different language: Even if that was truth (Russ showed it might not), I don't see how this is a counter argument to what I wrote. Besides this, this is not a voting system: if we were governed only by a majority of users, we would all be running Windows. Jeez, and I was honestly thinking all the time that Debian was a community project which has a democratic organization and larger decisions are primarily made with our users in mind. We try to have technical reasoning, which is (one of) the reason this list exists. This has nothing to do with voting. I thought we were making software which is to be useful for our users in the end,... That is the case, but not using popcon as a metric to our technical decisions. ...but it turns out that according to your line of arguments, Debian is primarily made to fuel the egos of its developers. Now you are crossing the line. 1/ Don't put words in my mouth which I never used. 2/ Try to write more useful things. Doing personal attacks doesn't help. Guess, I am in the wrong project then. Definitively, if you continue to express yourself this way, you are. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51e95e95.2030...@debian.org
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 07/19/2013 06:12 PM, Mathieu Parent wrote: As the recommended way to install systemd is using init= and not installing systemd-sysv, maybe the popcon vote count is the correct metric? Plus, systemd isn't pulled in by anything else which means when it's there it's there because it was actively installed. I don't think it magically lands onto a user's hard disk or someone installs it just in order to not use it actually. systemd is used regulardly on about 1200 popcon submiters, upstart on about 600 (this is even less than 100 from 2013-07-04, but what happened!). Like several people pointed out before, the popcon entries for the Ubuntu upstart package pointed to Debian which at a particular time which resulted in wrong data being sent to popcon. The data that we have now is the actual data and it shows upstart isn't very popular. Cheers, Adrian -- .''`. 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51e96ae4.5050...@physik.fu-berlin.de
modern features and OpenRC (was: Re: Survey answers part 3: systemd is not portable and what this means for our ports)
Dear all, John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de writes: Says the guy who posted this to back up his chain of arguments: http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems Excuse me for hijacking this reply. On the wiki page. I revised it into present form last year, after a *shadow* survey (using each to see its interface and features, by performing service add/remove/start/stop) of various init systems, including sysvinit + sysv-rc, Upstart, systemd, OpenRC, SMF and launchd. It is biased, not mature and started from the biased http://0pointer.de/blog/projects/why.html to counter-argue Lennart's points. For the '??' in Device-based Activation, sorry, at that time I didn't know what it was so just copy-n-pasted. Because of the bias, It was soon moved into Talk for archieving purpose. For a objective version have a look at the main page, http://wiki.gentoo.org/wiki/Comparison_of_init_systems. For the features that people care most in OpenRC (openrc herd, correct me if I am wrong): a. process supervising: no. But OpenRC can be integrated with runit (unofficial yet), my personal effort is targeting to use s6[1] together with OpenRC. b. event-driven, mostly hotplug events OpenRC provides a HOTPLUG virtual runlevel. to keep features minimal, it relies on udev to trigger it. An example of iPhone hotplugging[2]. I forgot if inotify could fit into this. If you need more info I can dig it out. c. socket activation no. At present no solution yet. Cheers, Benda 1. http://www.skarnet.org/software/s6/why.html 2. http://wiki.gentoo.org/wiki/Iphone_USB_Tethering#udev_trigger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ob9ycgml.fsf...@proton.in.awa.tohoku.ac.jp
Re: Survey answers part 3: systemd is not portable and what this means for our ports
Scott Kitterman deb...@kitterman.com writes: On Friday, July 19, 2013 06:35:48 PM John Paul Adrian Glaubitz wrote: The data that we have now is the actual data and it shows upstart isn't very popular. sysvinit 148865 99.83% Neither is systemd. The numbers for either are small enough to be meaningless. However no popcon number is quite as meaningless as the number for a package that is Essential: yes. I'd guess most systems that run either upstart or systemd still have sysvinit installed (mine do, for another useless example). -- Arto Jantunen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y592mpix@iki.fi
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On Fri, Jul 19, 2013 at 10:43:33PM +0200, David Kalnischkies wrote: But we have also gnome-settings-daemon in experimental which depends without an alternative on it. Now, if you look really close on the popcon data for systemd you see that in March 2013 there is a plateau reached for systemd, which suddenly at the end of the month is followed by the constant up – which neatly alines with the upload of the previously mentioned gnome-settings-daemon to experimental with a systemd dependency. So, what do you think: More people wanting to testdrive GNOME 3.8 or systemd? Ha ha... So why do we even discuss popcon data here, with it being messed with so badly? Instead, there should be a repeat of the network-manager brouchacha. -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130719233953.ga7...@angband.pl
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On Fri, Jul 19, 2013 at 9:35 AM, John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de wrote: On 07/19/2013 06:12 PM, Mathieu Parent wrote: As the recommended way to install systemd is using init= and not installing systemd-sysv, maybe the popcon vote count is the correct metric? Plus, systemd isn't pulled in by anything else which means when it's there it's there because it was actively installed. I don't think it magically lands onto a user's hard disk or someone installs it just in order to not use it actually. On the contrary, in experimental, gnome-shell depends on gnome-settings-daemon, which in turn depends on systemd. I wouldn't be surprised if this is one of the reasons sid still has version 3.4 of the shell, rather than the latest upstream version (3.8). If/when gnome-shell 3.8 hits unstable and systemd gets forced on end users as well...I dare say that the general outcry here on debian-devel would make the past network-manager related threads look tame in comparison. I offer my deepest condolences to the gnome maintainers in advance (I doubt that they're looking forward to dealing with all this). Regards, Vincent -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tC4acLy=Ant-0KsHCz-g0UsW5vO8Qx2O6=tpmj6nfk...@mail.gmail.com
[OT] Re: Survey answers part 3: systemd is not portable and what this means for our ports
Le Fri, Jul 19, 2013 at 07:14:31PM -0700, Vincent Cheng a écrit : If/when gnome-shell 3.8 hits unstable and systemd gets forced on end users as well...I dare say that the general outcry here on debian-devel would make the past network-manager related threads look tame in comparison. I offer my deepest condolences to the gnome maintainers in advance (I doubt that they're looking forward to dealing with all this). What do you offer in case you are wrong and the people who are upgrading to GNOME 3.8 do not mind having systemd installed on their computer ? Bets are funnier if there is a concrete consequence with both outcomes. How about triaging 100 bugs of your choice for instance ? The problem is that, if it is too cheap to predict bad things on that list and be wrong, then the proportion of relevant messages on this list will decrease... Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130720034322.gd23...@falafel.plessy.net
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 07/20/2013 12:43 AM, John Paul Adrian Glaubitz wrote: On 07/19/2013 05:43 PM, Thomas Goirand wrote: We try to have technical reasoning, which is (one of) the reason this list exists. This has nothing to do with voting. If we actually did, the choice would have already been made for systemd long time ago. For many reasons, the choice isn't that easy. It has been explained to you by many people before that OpenRC isn't fit for the purpose at all and I really don't think upstart will meet the criteria either. The problem isn't that OpenRC isn't fit. The problem is that *NONE* of the projects are fitting *ALL* of our requirements. All of the 3 solutions have problems. And this is probably what we should focus on: make it so that at least one of the projects becomes a perfect fit. The main issue there is with Systemd, is that it doesn't seem like we may have a chance to make it evolve the way we need (for example, make it compatible with non-Linux ports). I believe it is possible to enhance OpenRC, which is why I worked on it. Maybe it can be possible to do that with Upstart as well (though I never heard about anyone working on a non-Linux port of Upstart yet). ...but it turns out that according to your line of arguments, Debian is primarily made to fuel the egos of its developers. Now you are crossing the line. No, I am not. When talking about egos, you are. How often do I have to read people claiming that systemd is a bad project because they don't like their upstream authors? Again, this was *not* my point. 1/ Don't put words in my mouth which I never used. 2/ Try to write more useful things. Doing personal attacks doesn't help. Says the guy who posted this to back up his chain of arguments: http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems I posted this to show OpenRC does more than just enhancing the init.d scripts, which Steeve claimed. You are the one who took on the hostile upstream part of the page, when this wasn't part of my argumentation at all. Also, you can't make me responsible for a page which I didn't write, or for the fact that many people think this way about Systemd upstream. So I stand by point point 1 and 2 above. This goes nowhere again... Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51ea22d5.20...@debian.org
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 07/18/2013 01:29 AM, Steve Langasek wrote: - Reliable, low-maintenance system startup (no races / ordering bugs) Could you point at these bugs? - Reliable service supervision Have you tried using rc-status? Or do you mean restarting crashed daemons? - Fast startup I thought everyone claimed (including systemd supporters) that this was a teenager side effect which we didn't care much about. - Sensible dynamic service management in response to post-boot events (network up/down, device add/remove, etc). Isn't this the role of udev? - Simple, declarative syntax My understanding is that OpenRC only addresses the last of these points, and adds nothing over sysv-rc for the rest. I don't agree with this view, and I believe that indeed, you miss-understood. This wiki page (which has been posted here before) doesn't agree with your view either: http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems Reducing OpenRC improvements to only the syntax of init scripts is just not right. Cgroups support and the rc-status command alone are nice features that you discarded/forgot/didn't know about. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51e79600.1060...@debian.org
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On Thu, Jul 18, 2013 at 03:15:12PM +0800, Thomas Goirand wrote: On 07/18/2013 01:29 AM, Steve Langasek wrote: - Reliable, low-maintenance system startup (no races / ordering bugs) Could you point at these bugs? - Reliable service supervision Have you tried using rc-status? Or do you mean restarting crashed daemons? Having not used OpenRC, I have no comment on the real world advantages or disadvantages of either init system. However, I don't think that the rc-status command has anything to do with this (though systemctl is nice). What is mostly being brought up is the service tracking, socket activation, cgroups and more. - Fast startup I thought everyone claimed (including systemd supporters) that this was a teenager side effect which we didn't care much about. Yes, but it is also a benefit of using systemd. - Sensible dynamic service management in response to post-boot events (network up/down, device add/remove, etc). Isn't this the role of udev? - Simple, declarative syntax My understanding is that OpenRC only addresses the last of these points, and adds nothing over sysv-rc for the rest. I don't agree with this view, and I believe that indeed, you miss-understood. This wiki page (which has been posted here before) doesn't agree with your view either: http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems Reducing OpenRC improvements to only the syntax of init scripts is just not right. Cgroups support and the rc-status command alone are nice features that you discarded/forgot/didn't know about. I seriously can't tell if you're simply trolling here. If you read this page, it's quite easy to notice that whoever wrote this had some serious issues with systemd. Just a few things that catch my eye: * 'Hurting feature of systemd' in the header * 'Timer based application: proprietary': What? That doesn't even make sense. * 'Graphical UI: yes': Nope. * All of the 'OpenRC bonus features', which mostly just seem to be wrong. * Saying that they have parallel startup and then at the end saying that it should be removed from config files entirely because it just doesn't work. If you're going to cite something showing that OpenRC is good, please don't show something that is so obviously biased it's not even funny anymore. Thanks, -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgplCRWRtTzOM.pgp Description: PGP signature
Re: Survey answers part 3: systemd is not portable and what this means for our ports
2013/7/18 William Giokas 1007...@gmail.com: Having not used OpenRC, I have no comment on the real world advantages or disadvantages of either init system I'm a user of Gentoo and Debian. I do not care of what to type: 'emerge -avuND world' or 'apt-get upgrade' I do not care of which init system is used: both just work. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/call-q8yqeb3vwqo32uhs8dxqsovkakuytekzowkqkuzww_v...@mail.gmail.com
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 07/18/2013 04:30 PM, William Giokas wrote: If you're going to cite something showing that OpenRC is good, please don't show something that is so obviously biased it's not even funny anymore. I agree that this wiki page is obviously biased, and that is to be expected at the wiki.gentoo.org site. It's about the same on the other side when Lennart tells about Systemd debunking myths. I believe everyone in this list is smart enough to detect that. Though it still shows OpenRC has more feature than what Steve listed, which was my point. OpenRC really does more than just enhancing the init scripts and making them declarative. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51e7c464.8090...@debian.org
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On Thu, Jul 18, 2013 at 06:33:08PM +0800, Thomas Goirand wrote: It's about the same on the other side when Lennart tells about Systemd debunking myths. If this wasn't about systemd, I'd ask for some arguments here. But as all systemd discussions are full of FUD anyway, it won't help much here. -- WBR, wRAR -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130718110031.ga25...@belkar.wrar.name
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 07/18/2013 09:15 AM, Thomas Goirand wrote: http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems friendly upstreamyes no NO YES Really? You put something like this in a technical comparison chart? And systemd has a graphical user interface? Wow, I don't even... Adrian -- .''`. 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51e7cd8a.5020...@physik.fu-berlin.de
Re: Survey answers part 3: systemd is not portable and what this means for our ports
John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de writes: On 07/18/2013 09:15 AM, Thomas Goirand wrote: http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems friendly upstream yes no NO YES Really? You put something like this in a technical comparison chart? A friendly upstream *is* important in a comparsion chart. Working with an unfriendly, or even hostile upstream is not something you want to have in a core component of an operating system. (Though, the table is obviously biased, and in my experience, highly incorrect, but such is the nature of most comparsions) -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d2qgnl5h.fsf@algernon.balabit
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 07/18/2013 01:48 PM, Gergely Nagy wrote: A friendly upstream *is* important in a comparsion chart. Working with an unfriendly, or even hostile upstream is not something you want to have in a core component of an operating system. Friendliness has nothing to do with accepting every single patch that people sent in. Just because an upstream project doesn't take your patches doesn't mean they don't like you but rather it should give you a hint to check whether your changes make sense. Adrian -- .''`. 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51e7dd5a.7070...@physik.fu-berlin.de
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 18/07/13 12:12, John Paul Adrian Glaubitz wrote: And systemd has a graphical user interface? Yes, systemadm(1) in systemd-ui. It was recently split into a separate (upstream and Debian source) package. It's hardly comprehensive, but it exists. S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51e7df56.6050...@debian.org
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 07/18/2013 07:00 PM, Andrey Rahmatullin wrote: On Thu, Jul 18, 2013 at 06:33:08PM +0800, Thomas Goirand wrote: It's about the same on the other side when Lennart tells about Systemd debunking myths. I'd ask for some arguments here. This has already been discussed. You can look in the archive. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51e7e3df.7010...@debian.org
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 07/18/2013 02:28 PM, Simon McVittie wrote: On 18/07/13 12:12, John Paul Adrian Glaubitz wrote: And systemd has a graphical user interface? Yes, systemadm(1) in systemd-ui. It was recently split into a separate (upstream and Debian source) package. It's hardly comprehensive, but it exists. Which is as optional as any GUI for System V Init or other init daemons. I had something like that (ksysvrc) ages ago for System V Init, too. Adrian -- .''`. 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51e7e4d6.8060...@physik.fu-berlin.de
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 07/18/2013 07:12 PM, John Paul Adrian Glaubitz wrote: On 07/18/2013 09:15 AM, Thomas Goirand wrote: http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems friendly upstream yes no NO YES Really? You put something like this in a technical comparison chart? I wasn't the one who wrote it. You're only trolling, just like the person who wrote this in that wiki page. This adds nothing to the discussion. My original point was only that there is more to OpenRC than enhanced init scripts. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51e7e489.7080...@debian.org
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On Thu, Jul 18, 2013 at 08:50:17PM +0800, Thomas Goirand wrote: http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems friendly upstream yes no NO YES Really? You put something like this in a technical comparison chart? I wasn't the one who wrote it. You linked it. You're only trolling, just like the person who wrote this in that wiki page. My original point was only that there is more to OpenRC than enhanced init scripts. And you used a page that you now seem to dislike to prove that. -- WBR, wRAR -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130718135251.ga5...@belkar.wrar.name
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On Thu, Jul 18, 2013 at 08:47:27PM +0800, Thomas Goirand wrote: It's about the same on the other side when Lennart tells about Systemd debunking myths. I'd ask for some arguments here. This has already been discussed. You can look in the archive. I don't think so. -- WBR, wRAR -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130718135846.gb5...@belkar.wrar.name
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 07/18/2013 08:19 AM, John Paul Adrian Glaubitz wrote: On 07/18/2013 01:48 PM, Gergely Nagy wrote: A friendly upstream *is* important in a comparsion chart. Working with an unfriendly, or even hostile upstream is not something you want to have in a core component of an operating system. Friendliness has nothing to do with accepting every single patch that people sent in. Just because an upstream project doesn't take your patches doesn't mean they don't like you but rather it should give you a hint to check whether your changes make sense. The trouble with that is, it's entirely possible to simply disagree about whether a particular set of changes make sense. If upstream wants development to go in one direction, and you want it to go in a conflicting direction, then your patches taking it in that other direction will not be accepted - even though they may make sense in the context of that other direction. Similarly, if upstream wants to make a particular set of changes, and you think those changes don't make sense, but rather than wanting to change things in a different way you want to leave things alone, you can't even submit patches to support your preferred outcome (since your preferred outcome is no changes) - and you certainly can't keep them from making the changes. The upstream is not required to accept your preferred changes or to hold back the changes they want because you don't like them, of course. But you aren't required to use the code the upstream produces, either. ...except when you need its functionality, and there's lock-in preventing you from (sufficiently easily) switching to some alternative. Which may be relevant to the case at hand. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51e7f5a7.7040...@fastmail.fm
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On Thu, Jul 18, 2013 at 03:15:12PM +0800, Thomas Goirand wrote: On 07/18/2013 01:29 AM, Steve Langasek wrote: - Reliable, low-maintenance system startup (no races / ordering bugs) Could you point at these bugs? No. Look, Thomas, you asked what the goals of event-based init systems are, and I thought that was a fair question to answer from the upstart POV because there are many Debian developers who have never used Ubuntu in production and so don't have an appreciation of the scope of the problems that upstart addresses. But I'm not going to go point-by-point with you arguing about how OpenRC fails in addressing these points, because that's a waste of your time and mine. It's not going to change the fact that OpenRC *doesn't* address these fundamental problems with sysvinit and isn't a modern init option. But unless you've only ever used Debian on systems with a flat partition:filesystem structure, with no network filesystem mounts, no LVM/RAID/LUKS, and no networks more complicated than a single interface, you've either been affected by these race conditions, or you've been relying on the chewing-gum-and-baling-wire workarounds that Debian has in place to paper over these races. The problems are pervasive and systemic, and have become progressively more severe over time as hardware becomes faster. An init system that has not *fundamentally* addressed this class of problem with its design is not bringing anything interesting to the table. - Fast startup I thought everyone claimed (including systemd supporters) that this was a teenager side effect which we didn't care much about. http://blip.tv/ubuntu-developers/ubuntu-uds-q-tuesday-pm-google-ubuntu-derivatives-and-community-6188491 3:07: a reboot costs [Google] a million dollars. The people who have dismissed boot speed as a matter for toy systems are being naive. It is not the number one priority for upstart or for anyone else; but downtime costs money, just as inefficient power control on systems costs money; and time spent booting is downtime. Time spent improving the boot speed for the millions of systems that run Debian is time well spent. My understanding is that OpenRC only addresses the last of these points, and adds nothing over sysv-rc for the rest. I don't agree with this view, and I believe that indeed, you miss-understood. This wiki page (which has been posted here before) doesn't agree with your view either: http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems I got as far as this: sysvinitUpstart systemd OpenRC SMF [...] Device-based Activation no no[4] yes ?? ?? ... and stopped reading. Not only does it reproduce Lennart's deceptive claim that Upstart doesn't support device-based activation without bothering to include the footnote, but the author of this page doesn't even *know* if OpenRC supports it? This is such a fundamental gap it's not even funny. -- 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
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 07/18/2013 08:21 PM, Steve Langasek wrote: But unless you've only ever used Debian on systems with a flat partition:filesystem structure, with no network filesystem mounts, no LVM/RAID/LUKS, and no networks more complicated than a single interface, you've either been affected by these race conditions, or you've been relying on the chewing-gum-and-baling-wire workarounds that Debian has in place to paper over these races. The problems are pervasive and systemic, and have become progressively more severe over time as hardware becomes faster. An init system that has not *fundamentally* addressed this class of problem with its design is not bringing anything interesting to the table. I fully agree with you here, Steve. NFS mounts (with or without autofs) don't cope very well with fast booting machines as well as machines with several (virtual or physical) interfaces. I don't know how often I ended up with a machine on the network where half of the NFS automounts weren't there until I restarted the autofs daemon simply because autofs was initialized prior the network was properly working. And, yes, the LSB init scripts contain the correct dependencies and yet it doesn't work properly. An init daemon which makes sure that a certain resource is properly configured or a daemon is really running, is essential nowadays to boot sophisticated systems reliably. I have also seen the need for resource management ala cgroups on our large compute clusters. When dozens of users are using a very large cluster simultaneously, you want to have the possibility to limit the resources per user such that a single user won't be able to bring down the whole cluster or have the OOM killer kick in. I have seen users bring down a central login node because they were smart enough to start a huge calculation on the login node instead of actually queuing their job onto the cluster itself. The people who have dismissed boot speed as a matter for toy systems are being naive. It is not the number one priority for upstart or for anyone else; but downtime costs money, just as inefficient power control on systems costs money; and time spent booting is downtime. Time spent improving the boot speed for the millions of systems that run Debian is time well spent. systemd (and upstart) actually show their fast booting in virtual machines which are very common nowadays on server farms. I have virtual machines running Debian unstable with systemd which boot in less than 4 seconds. Adrian -- .''`. 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51e83ba5.5070...@physik.fu-berlin.de
Re: Survey answers part 3: systemd is not portable and what this means for our ports
Thomas Goirand zigo at debian.org writes: You have to define what problem we are trying to solve. And this still hasn't been defined yet in this list. What for? Seriously. There are a whole lot of features in systemd which I, for one, do NOT want to do without any longer. Decent process state reporting. Decent and comprehensive logging. Service termination that works reliably. The ability to run processes in their own namespace without jumping through hoops and spending a day debugging the stuff. Socket activation. Udev activation. Replacing a whole heap of somewhat-buggy sysvinit scripts. I could go on. systemd's feature list is impressive, and so is the list of distros which have adopted it. Ship basic sysvinit scripts for the handful of non-Linux-kernel Debian users if you have to, but otherwise transition to systemd, dammit. Any other option makes no sense whatsoever. IMHO. Among the heap of computers I own, every single one runs with systemd (even the outdated v44 in Wheezy is better than sysvinit), and I'd rather switch distros than going back. Seriously. -- -- Matthias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130718t212613-...@post.gmane.org
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 07/19/2013 02:21 AM, Steve Langasek wrote: But unless you've only ever used Debian on systems with a flat partition:filesystem structure, with no network filesystem mounts, no LVM/RAID/LUKS, and no networks more complicated than a single interface, you've either been affected by these race conditions, or you've been relying on the chewing-gum-and-baling-wire workarounds that Debian has in place to paper over these races. The problems are pervasive and systemic, and have become progressively more severe over time as hardware becomes faster. An init system that has not *fundamentally* addressed this class of problem with its design is not bringing anything interesting to the table. [...] I got as far as this: sysvinitUpstart systemd OpenRC SMF [...] Device-based Activation no no[4] yes ?? ?? ... and stopped reading. [...] This is such a fundamental gap it's not even funny. Hi Steve! This is one of the rare posts that does make sense to me. I do agree with that fixing race conditions is a major issue. Though I remember having a discussion with Patrick Lauer about OpenRC support for socket / device activation. I'm CC-ing him, maybe he can reply about this specific point. If OpenRC isn't what we need (I still believe it does address a bunch of problems and that the fact it can work for non-Linux port is a key factor), then I'd be for Upstart. I do maintain my packages so that they work for both Ubuntu and Debian, having to write things for 2 init systems would be useless added work. So that brings me to ask: do you have an idea of how much work it would be to have Upstart ported to kFreeBSD or Hurd (even if that would mean loosing some of the functionality (obviously cgroups comes to mind))? Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51e845d1.4040...@debian.org
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On Fri, Jul 19, 2013 at 03:45:21AM +0800, Thomas Goirand wrote: So that brings me to ask: do you have an idea of how much work it would be to have Upstart ported to kFreeBSD or Hurd (even if that would mean loosing some of the functionality (obviously cgroups comes to mind))? As for cgroups, even if required functionality is missing, poking upstream BSD kernel guys might be a good idea: jails already have all needed parts, it's a matter of being able to cherry-pick them. [Disclaimer: I know these parts only from an user's point of view.] -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130718200844.ga12...@angband.pl
Re: Survey answers part 3: systemd is not portable and what this means for our ports
❦ 18 juillet 2013 21:45 CEST, Thomas Goirand z...@debian.org : So that brings me to ask: do you have an idea of how much work it would be to have Upstart ported to kFreeBSD or Hurd (even if that would mean loosing some of the functionality (obviously cgroups comes to mind))? Upstart doesn't support cgroups. -- Use uniform input formats. - The Elements of Programming Style (Kernighan Plauger) pgpm355uGYsGg.pgp Description: PGP signature
Re: Survey answers part 3: systemd is not portable and what this means for our ports
Thomas Goirand (2013-07-19): So that brings me to ask: do you have an idea of how much work it would be to have Upstart ported to kFreeBSD or Hurd (even if that would mean loosing some of the functionality (obviously cgroups comes to mind))? Surely, you could have tried “porting upstart kfreebsd” in your favorite search engine, and you would have found Scott's mail from 2009 addressing that particular question. Right? http://lists.debian.org/debian-bsd/2009/07/msg00122.html KiBi. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130718201426.gb4...@mraw.org
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 18 July 2013 21:14, Cyril Brulebois k...@debian.org wrote: Thomas Goirand (2013-07-19): So that brings me to ask: do you have an idea of how much work it would be to have Upstart ported to kFreeBSD or Hurd (even if that would mean loosing some of the functionality (obviously cgroups comes to mind))? Surely, you could have tried “porting upstart kfreebsd” in your favorite search engine, and you would have found Scott's mail from 2009 addressing that particular question. Right? http://lists.debian.org/debian-bsd/2009/07/msg00122.html And this was pondered again not that long ago: http://lists.debian.org/debian-devel/2013/05/msg01227.html I see that 9.1 and 10 kernels are available in experimental so an upstart port to kfreebsd can be approached. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluhukrq4ixxpptbvvhhgcqtf8jsk3pxi4ai7kgauffo...@mail.gmail.com
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 07/18/2013 09:45 PM, Thomas Goirand wrote: If OpenRC isn't what we need (I still believe it does address a bunch of problems and that the fact it can work for non-Linux port is a key factor), then I'd be for Upstart. I do maintain my packages so that they work for both Ubuntu and Debian, having to write things for 2 init systems would be useless added work. Popcon however speaks a completely different language: http://qa.debian.org/popcon.php?package=upstart http://qa.debian.org/popcon.php?package=systemd Currently 64 counted installations for upstart versus 1604 counted installations for systemd with a significant drop for upstart shortly after it surged just when upstart in Debian was updated to 1.6. On a sidenote: Anyone can explain what could probably have caused this sharp drop in installations? Were there any significant problems with the current version of upstart in Debian? Cheers, Adrian -- .''`. 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51e88916.5000...@physik.fu-berlin.de
Re: Survey answers part 3: systemd is not portable and what this means for our ports
John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de writes: Popcon however speaks a completely different language: http://qa.debian.org/popcon.php?package=upstart http://qa.debian.org/popcon.php?package=systemd Currently 64 counted installations for upstart versus 1604 counted installations for systemd with a significant drop for upstart shortly after it surged just when upstart in Debian was updated to 1.6. I believe the equivalent systemd package to the upstart package is the systemd-sysv package, so 174 rather than 1604 is perhaps the better number to use. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r4ev5pwg@windlord.stanford.edu
Re: Survey answers part 3: systemd is not portable and what this means for our ports
John Paul Adrian Glaubitz (2013-07-19): On a sidenote: Anyone can explain what could probably have caused this sharp drop in installations? Were there any significant problems with the current version of upstart in Debian? Probably that? http://lists.alioth.debian.org/pipermail/popcon-developers/2013-May/002255.html Mraw, KiBi. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130719011106.ge4...@mraw.org
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 07/19/2013 02:55 AM, Russ Allbery wrote: I believe the equivalent systemd package to the upstart package is the systemd-sysv package, so 174 rather than 1604 is perhaps the better number to use. I'm not sure whether I can follow. I am using systemd on both my desktop and my laptop and neither of them has the systemd-sysv package installed which, AFAIK, is required for compatibility reasons only. Adrian -- .''`. 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51e892fa.2070...@physik.fu-berlin.de
Re: Survey answers part 3: systemd is not portable and what this means for our ports
2013/7/19 Russ Allbery r...@debian.org: John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de writes: Popcon however speaks a completely different language: http://qa.debian.org/popcon.php?package=upstart http://qa.debian.org/popcon.php?package=systemd Currently 64 counted installations for upstart versus 1604 counted installations for systemd with a significant drop for upstart shortly after it surged just when upstart in Debian was updated to 1.6. I believe the equivalent systemd package to the upstart package is the systemd-sysv package, so 174 rather than 1604 is perhaps the better number to use. This is just for people who dropped SysV-Init for systemd, since systemd-sysv provides compatibility symlinks for a sd-only install. People who tried systemd will obviously need the systemd package (and then adjust GRUB to boot using sd). So, 1604 would be a valid number. (But I also don't understand the massive drop in upstart installs - did something happen?) Cheers, Matthias -- I welcome VSRE emails. See http://vsre.info/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caknhny-u2jmapfsaf+o1sdldivgverzfp25_ocpyt0zehvr...@mail.gmail.com
Re: Survey answers part 3: systemd is not portable and what this means for our ports
Matthias Klumpp m...@debian.org writes: 2013/7/19 Russ Allbery r...@debian.org: John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de writes: Popcon however speaks a completely different language: http://qa.debian.org/popcon.php?package=upstart http://qa.debian.org/popcon.php?package=systemd Currently 64 counted installations for upstart versus 1604 counted installations for systemd with a significant drop for upstart shortly after it surged just when upstart in Debian was updated to 1.6. I believe the equivalent systemd package to the upstart package is the systemd-sysv package, so 174 rather than 1604 is perhaps the better number to use. This is just for people who dropped SysV-Init for systemd, since systemd-sysv provides compatibility symlinks for a sd-only install. People who tried systemd will obviously need the systemd package (and then adjust GRUB to boot using sd). So, 1604 would be a valid number. If you're looking for a number of people who have tried systemd and then not removed it, 1604 is fine for that purpose, but that wasn't how the number was being used. The original poster was comparing with the upstart package in an attempt to determine relative popularity. The upstart package replaces sysvinit with upstart (notice Conflicts: sysvinit). This is equivalent to the systemd-sysv package. Comparing installation counts of the systemd package to the upstart package is comparing apples to kumquats. It's unsurprising that a package that does not replace sysvinit has a higher install count than one that does. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ip075ols@windlord.stanford.edu
Re: Survey answers part 3: systemd is not portable and what this means for our ports
Russ Allbery wrote: John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de writes: Popcon however speaks a completely different language: http://qa.debian.org/popcon.php?package=upstart http://qa.debian.org/popcon.php?package=systemd Currently 64 counted installations for upstart versus 1604 counted installations for systemd with a significant drop for upstart shortly after it surged just when upstart in Debian was updated to 1.6. The surge was likely Ubuntu popcon bug sending reports to Debian (so in fact it's never been popular in Debian). I believe the equivalent systemd package to the upstart package is the systemd-sysv package, so 174 rather than 1604 is perhaps the better number to use. I don't think so - the documentation I've seen has always recommended changing kernel command-line to say init=/bin/systemd instead of installing systemd-sysv. In fact I'm somewhat surprised at the fact that according to those numbers more than one tenth of people (or at least popcon users) using systemd must have installed systemd-sysv. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1374198232.21442.19.camel@glyph.nonexistent.invalid
Re: Survey answers part 3: systemd is not portable and what this means for our ports
John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de writes: On 07/19/2013 02:55 AM, Russ Allbery wrote: I believe the equivalent systemd package to the upstart package is the systemd-sysv package, so 174 rather than 1604 is perhaps the better number to use. I'm not sure whether I can follow. I am using systemd on both my desktop and my laptop and neither of them has the systemd-sysv package installed which, AFAIK, is required for compatibility reasons only. I see no sign that installing systemd replaces init or takes over process 1. All of the symlinks to do so are in the systemd-sysv package, and that's the only package that conflicts with sysvinit and thereby removes the other init system. Am I missing something? checks Ah, here we go: | systemd can be installed alongside sysvinit and will not change the | behaviour of the system out of the box. This is intentional. To test | systemd, add: | | init=/bin/systemd | | to the kernel command line and then rebooting, or install the | systemd-sysv package. I didn't know about the init= method and was assuming the systemd-sysv method. Anyway, my point is that I suspect the vast majority of the systems with the systemd package installed are not actually using it as process 1. The upstart package takes over process 1, so 100% of the systems with the upstart package installed are using it as process 1. The same is true of systemd-sysv, of course. I don't think there's a way to do a straight apples to apples comparison on adoption based on the current popcon numbers. The number of people running systemd is more than the install count of systemd-sysv, but less (and I suspect much less) than the install count of systemd. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d2qf5ngg@windlord.stanford.edu
Re: /usr (was: Re: Survey answers part 3: systemd is not portable and what this) means for our ports
On Tue, Jul 16, 2013 at 08:06:27PM +0100, Roger Leigh wrote: On Tue, Jul 16, 2013 at 11:25:42AM -0700, Steve Langasek wrote: On Tue, Jul 16, 2013 at 05:07:39PM +0100, Roger Leigh wrote: - using the same infrastructure, it's also possible to mount /etc in the initramfs so that you can have e.g. a separately encrypted /etc filesystem. This is a separate feature though and can be split out. This reflects poorly on the infrastructure in question. I'm merely referring to the generalisation of the local/nfs scripts to allow mounting of arbitrary filesystems. There's nothing wrong with this this support code. Yes. This shouldn't be generalized. There are only two filesystems that should be handled from the initramfs: the rootfs, and (optionally) /usr. Handling /etc as a separate filesystem from /, aside from not being a feature anyone else has asked for and not being a requirement for reducing deltas with upstreams / other distros, implies that the initramfs has to have a copy of the information from /etc/fstab. This is *not* how this should be handled. I certainly didn't mean to imply this, because this is not what is being done here. Nothing is stored in the initramfs. For the /etc-as-separate-mount case, you must be storing this information either in the kernel boot options or in the initramfs itself. I don't think either of these options is a reasonable course of action. This same problem is *already solved* by moving the static contents to /usr, making the toplevel directories symlinks, and keeping /etc on the root filesystem so that you are not duplicating information between /etc/fstab and the initramfs (or kernel commandline). Having /etc as a separate filesystem adds complexity and introduces inconsistency, without actually expanding the set of use cases. Note that this part was merely added as a proposal only as a demonstration of what could be done /if this was desirable to have/. If not, then it can be dropped. It was included solely that it could be reviewed. As you may be able to tell, I feel very strongly that this part should be dropped. 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
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 19/07/13 11:48, Russ Allbery wrote: I didn't know about the init= method and was assuming the systemd-sysv method. Anyway, my point is that I suspect the vast majority of the systems with the systemd package installed are not actually using it as process 1. The upstart package takes over process 1, so 100% of the systems with the upstart package installed are using it as process 1. The same is true of systemd-sysv, of course. I don't think there's a way to do a straight apples to apples comparison on adoption based on the current popcon numbers. The number of people running systemd is more than the install count of systemd-sysv, but less (and I suspect much less) than the install count of systemd. The wiki page[0] (first hit on google for debian systemd) recommends installing the systemd package and adding the init= line. That would probably explain the popcon numbers. [0] https://wiki.debian.org/systemd -- Regards, Scott Leggett. signature.asc Description: OpenPGP digital signature
Re: Pulseaudio (was ... Re: Survey answers part 3: systemd is not portable and what this means for our ports)
On Wed, Jul 17, 2013 at 6:29 AM, Chris Bannister cbannis...@slingshot.co.nz wrote: On Mon, Jul 15, 2013 at 10:44:21AM -0400, The Wanderer wrote: My most recent experience with PulseAudio came when I noticed that WoW (run through Wine) was producing crackling, stuttering sound again; this was during the late months before the wheezy release. I tried half-a-dozen things, without noticeable change (except for the things which led to no sound at all); eventually I noticed that some PulseAudio packages had been installed, apparently as recommendations or dependencies of other things. I tried a few things to disable use of PulseAudio without removing it, without affecting the problem; I then removed all *pulse* packages I could, and the problem was gone. Me too, and I don't even use a DE! One day sound just stopped working. Removing all of the *pulse* packages I could got sound working again. I didn't mess with anything either. If there _suddenly_ appears a bad smell in your house and you find the cause, do you a) Remove the cause? b) Waste time by trying to find out why it smells? I recommend reading up on what 'anecdotal evidence' is, and filling the bug report on PA next time when you encounter a problem instead of pilling up PA issues in debian-devel in order to bash systemd. O. -- Ondřej Surý ond...@sury.org
PulseAudio (was: Survey answers part 3: systemd is not portable and what this means for our ports)
On Mon, 15 Jul 2013 15:43:32 +0200, John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de wrote: Some older versions prior 1.0.x were broken or had exposed bugs in ALSA drivers which needed to be fixed. These days, however, PulseAudio is rock-stable. It usually breaks only for people who tinker too much with it without understanding the concept behind it. Where are the end-user docs that explain the concept? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1uzm7c-0002h2...@swivel.zugschlus.de
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On Mon, 15 Jul 2013 14:09:20 +0200, Josselin Mouette j...@debian.org wrote: What I find rude is that a minority of idiots is taking the project hostage of their ridiculous demands, preventing a quick switch to a decent init systems, for reasons that are anything but technical. Once more, I find your wording utterly offensive and thus inacceptable. This is not helping. You are doing harm to your causes. Grüße Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1uzm61-0002gu...@swivel.zugschlus.de
