Re: init-select
On Thu, Jan 2, 2014 at 8:31 PM, Michael Gilbert wrote: Now, I certainly don't want all that weight solely on my shoulders, so I would very much prefer this choice to be team-maintained, and I think the installer/boot team has the expertise and clout to make the right choice when the time is really right to change the default Debian init. Based on the direction the discussion went yesterday and a night to sleep on it, I've decided that I am going to maintain this myself. Thanks a lot for all of the constructive feedback. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mosbqafwb0p1cjby5cn7eef5o9qktokwog4skfe-u3...@mail.gmail.com
Re: init-select
Hi, On 03.01.2014 04:24, Michael Gilbert wrote: So, I suppose this isn't immediately obvious, but there is another solved problem here. Say the TC ultimately does not choose systemd as the default, and one day gnome entirely drops compatibility with the other inits. The gnome maintainers can take advantage of init-select to automatically move their users from whatever that default is to systemd. If GNOME would only work with systemd as PID 1, the correct thing to do is adding a dependency on systemd-sysv, or is there a problem with that? This is simpler than calling another script, that only works for grub. Best regards, Andreas -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52c6779d.1030...@googlemail.com
Re: init-select
Hi Michael Gilbert mgilb...@debian.org writes: Hi :) The TC init discussion has diverged significantly from Debian's usual ideals of freedom and meritocracy, so I decided to do something about it. So, today I wrote init-select. It's a small tool that empowers users to freely and simply choose among all of the available init systems. It also empowers Debian contributors to devote their energy toward their favorite init knowing that users can easily swap inits to try the new features they are working on. IMO you are solving the wrong problem. Or how would you ensure that while the user can easily switch the init system, when doing so half of the daemons installed won't start because they don't support the alternative. And if he switches back, the other half does not start because the only support the other alternative. IMO the hard problem is mostly about which systems must be supported by all packages. init-select does not help to solve this. But most importantly, it provides a path for eliminating the politicization of the init system problem. That would be achieved if Debian's default init were to simply become init-select's default. Now, I certainly don't want all that weight solely on my shoulders, so I would very much prefer this choice to be team-maintained, and I think the installer/boot team has the expertise and clout to make the right choice when the time is really right to change the default Debian init. The initial package is up for review at: http://people.debian.org/~mgilbert/other I've set the maintainer to debian-boot now in the hope that this proposal sounds reasonable. There is of course more work to do, which is documented in a TODO file in the source, which will make the package better, but the existing functionality, I think, is already useful. I can switch inits on a whim in seconds now. I don't see why the installer team should be in any better position to choose the default init system for Debian than any other team. At least since I'm involved (~ 10 years) the mailinglist name for the installer was a bit of a misnomer. The team has nothing to do with everyday booting of the system. It probably comes from the fact that the installer before d-i was called boot-floppies. So IMHO this should not be maintained by debian-boot. But then I'm not really active here any more at the moment, so if people actually active on debian-boot want to maintain it, I won't oppose any further. Gaudenz Anyway, that is my modest proposal. I hope this doesn't sound too overly idealistic, intrusive, or I suppose out of the blue :) Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MPLNu6-ss4uOtv+kSF8bPyGOvBC4FjeNYaOVr=pf6g...@mail.gmail.com -- Ever tried. Ever failed. No matter. Try again. Fail again. Fail better. ~ Samuel Beckett ~ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87a9fdl91p@meteor.durcheinandertal.bofh
Re: init-select
Michael Gilbert mgilb...@debian.org (2014-01-02): So, I suppose this isn't immediately obvious, but there is another solved problem here. Say the TC ultimately does not choose systemd as the default, and one day gnome entirely drops compatibility with the other inits. The gnome maintainers can take advantage of init-select to automatically move their users from whatever that default is to systemd. That is simply # init-select /bin/systemd # update-grub somewhere appropriate in their maintainer scripts. TC is supposed to take decisions with rationales, and suggesting a path forward for everyone involved. I suppose they're going to have a plan for Gnome vs. systemd if systemd isn't chosen. I'm not sure why just waiting for a decision wouldn't be the right thing to do right now. Mraw, KiBi. signature.asc Description: Digital signature
Re: init-select
Hi, On 03.01.2014 10:16, Gaudenz Steinlin wrote: Michael Gilbert mgilb...@debian.org writes: So, today I wrote init-select. It's a small tool that empowers users to freely and simply choose among all of the available init systems. It also empowers Debian contributors to devote their energy toward their favorite init knowing that users can easily swap inits to try the new features they are working on. IMO you are solving the wrong problem. Or how would you ensure that while the user can easily switch the init system, when doing so half of the daemons installed won't start because they don't support the alternative. And if he switches back, the other half does not start because the only support the other alternative. IMO the hard problem is mostly about which systems must be supported by all packages. init-select does not help to solve this. I think this would not be a problem (at least until jessie+1), because both systemd and upstart have a compatibility layer for sysvinit scripts, which all daemons have to provide according to policy. But I fail to see, why initsel would be better than: sudo apt-get install systemd-sysv/upstart/sysvinit-core Best regards, Andreas -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52c68656.9070...@googlemail.com
Re: init-select
On Fri, Jan 3, 2014 at 4:43 AM, Andreas Cadhalpun wrote: Hi, On 03.01.2014 10:16, Gaudenz Steinlin wrote: Michael Gilbert mgilb...@debian.org writes: So, today I wrote init-select. It's a small tool that empowers users to freely and simply choose among all of the available init systems. It also empowers Debian contributors to devote their energy toward their favorite init knowing that users can easily swap inits to try the new features they are working on. IMO you are solving the wrong problem. Or how would you ensure that while the user can easily switch the init system, when doing so half of the daemons installed won't start because they don't support the alternative. And if he switches back, the other half does not start because the only support the other alternative. IMO the hard problem is mostly about which systems must be supported by all packages. init-select does not help to solve this. I think this would not be a problem (at least until jessie+1), because both systemd and upstart have a compatibility layer for sysvinit scripts, which all daemons have to provide according to policy. But I fail to see, why initsel would be better than: sudo apt-get install systemd-sysv/upstart/sysvinit-core Because it makes it possible for all of them to coexist peacefully. Right now all of those packages conflict with one-another. Thus, currently switching init systems that way can be a scary process for the average user. Finally, there is no way to select anything other than the default init in during the installation process (note that init-select doesn't currently implement that yet, but will be rather straightforward). Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mpqxdkgkadzi3tegwgad8rrouy8z-3rgahdtmjp4hn...@mail.gmail.com
Re: init-select
On Fri, Jan 3, 2014 at 4:40 AM, Cyril Brulebois wrote: Michael Gilbert mgilb...@debian.org (2014-01-02): So, I suppose this isn't immediately obvious, but there is another solved problem here. Say the TC ultimately does not choose systemd as the default, and one day gnome entirely drops compatibility with the other inits. The gnome maintainers can take advantage of init-select to automatically move their users from whatever that default is to systemd. That is simply # init-select /bin/systemd # update-grub somewhere appropriate in their maintainer scripts. TC is supposed to take decisions with rationales, and suggesting a path forward for everyone involved. I suppose they're going to have a plan for Gnome vs. systemd if systemd isn't chosen. I'm not sure why just waiting for a decision wouldn't be the right thing to do right now. It is often far more ideal when the TC chooses to not act. TC action means that the project is somehow dysfunctional. init-select is a very simple technical solution to a very large social problem. Why would we not solve the problem here and totally diffuse the political fallout and unhappiness that the TC mandate is going to cause? Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MNUirDGbHp55xzzzGr-7epMUU=20rq-14kqyhtdjen...@mail.gmail.com
Re: init-select
Michael Gilbert mgilb...@debian.org (2014-01-03): It is often far more ideal when the TC chooses to not act. TC action means that the project is somehow dysfunctional. init-select is a very simple technical solution to a very large social problem. Having to pick an init system is *not* a social problem. Trying to support several init systems is *not* in the best interest of a distribution. Having a fully functional one (and a transition from the former if it's different) is what we need to work on. Mraw, KiBi. signature.asc Description: Digital signature
Re: init-select
On Fri, Jan 3, 2014 at 4:16 AM, Gaudenz Steinlin wrote: Or how would you ensure that while the user can easily switch the init system, when doing so half of the daemons installed won't start because they don't support the alternative. And if he switches back, the other half does not start because the only support the other alternative. IMO the hard problem is mostly about which systems must be supported by all packages. init-select does not help to solve this. I completely agree that is entirely outside the scope of the problem init-select is meant to solve. Getting the individual init systems into a fully usable state is ultimately the responsibility of the various teams working on their favorite init. I've set the maintainer to debian-boot now in the hope that this proposal sounds reasonable. There is of course more work to do, which is documented in a TODO file in the source, which will make the package better, but the existing functionality, I think, is already useful. I can switch inits on a whim in seconds now. I don't see why the installer team should be in any better position to choose the default init system for Debian than any other team. At least since I'm involved (~ 10 years) the mailinglist name for the installer was a bit of a misnomer. The team has nothing to do with everyday booting of the system. It probably comes from the fact that the installer before d-i was called boot-floppies. For the same reason that the installer team reluctantly chooses the default desktop environment: that is the first path which the user actually needs to make a choice (or non-choice of course). Plus I think the project very much respects the unbiased decision-making process of the d-i team. This is why the TC decision will be troublesome: there was no way to keep bias and politicization out of the process, so a lot of the project will ultimately not respect the decision. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MP2K=1jinroch6adc4wt0z4lghtxd_wmndw6ft8fan...@mail.gmail.com
Re: init-select
On Fri, Jan 3, 2014 at 11:00 AM, Cyril Brulebois k...@debian.org wrote: Michael Gilbert mgilb...@debian.org (2014-01-03): It is often far more ideal when the TC chooses to not act. TC action means that the project is somehow dysfunctional. init-select is a very simple technical solution to a very large social problem. Having to pick an init system is *not* a social problem. All TC decisions are attempts at the resolution of social problems. They only consider issues that involve the social disagreement between at least two people. The fact that the disagreement is happens to be over a technical topic does not eliminate the social aspect. Trying to support several init systems is *not* in the best interest of a distribution. Having a fully functional one (and a transition from the former if it's different) is what we need to work on. Following that logic, supporting multiple packaging helpers, desktop environments, text editors, compilers, kernels, so on and so on are also *not* in the best interest of a distribution. Let's pick the most functional ones, that is what we need to work on. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=moaqfsm+toh6eh5b7jqb5pg807wwftne62ofufrjxk...@mail.gmail.com
Re: init-select
Michael Gilbert mgilb...@debian.org (2014-01-03): On Fri, Jan 3, 2014 at 11:00 AM, Cyril Brulebois k...@debian.org wrote: Michael Gilbert mgilb...@debian.org (2014-01-03): It is often far more ideal when the TC chooses to not act. TC action means that the project is somehow dysfunctional. init-select is a very simple technical solution to a very large social problem. Having to pick an init system is *not* a social problem. All TC decisions are attempts at the resolution of social problems. They only consider issues that involve the social disagreement between at least two people. The fact that the disagreement is happens to be over a technical topic does not eliminate the social aspect. Having a social aspect doesn't mean it's primarily a social problem. Trying to support several init systems is *not* in the best interest of a distribution. Having a fully functional one (and a transition from the former if it's different) is what we need to work on. Following that logic, supporting multiple packaging helpers, desktop environments, text editors, compilers, kernels, so on and so on are also *not* in the best interest of a distribution. Let's pick the most functional ones, that is what we need to work on. False analogy. Anyway, not going to play on words because there are so many efforts wasted with this topic already. Again, my position on the topic: No, this doesn't belong to the installer. Mraw, KiBi. signature.asc Description: Digital signature
Re: init-select
On Fri, Jan 3, 2014 at 11:19 AM, Cyril Brulebois k...@debian.org wrote: Michael Gilbert mgilb...@debian.org (2014-01-03): On Fri, Jan 3, 2014 at 11:00 AM, Cyril Brulebois k...@debian.org wrote: Michael Gilbert mgilb...@debian.org (2014-01-03): It is often far more ideal when the TC chooses to not act. TC action means that the project is somehow dysfunctional. init-select is a very simple technical solution to a very large social problem. Having to pick an init system is *not* a social problem. All TC decisions are attempts at the resolution of social problems. They only consider issues that involve the social disagreement between at least two people. The fact that the disagreement is happens to be over a technical topic does not eliminate the social aspect. Having a social aspect doesn't mean it's primarily a social problem. Trying to support several init systems is *not* in the best interest of a distribution. Having a fully functional one (and a transition from the former if it's different) is what we need to work on. Following that logic, supporting multiple packaging helpers, desktop environments, text editors, compilers, kernels, so on and so on are also *not* in the best interest of a distribution. Let's pick the most functional ones, that is what we need to work on. False analogy. Evidence and/or logic would be nice, otherwise there is no reason to conclude this. Anyway, not going to play on words because there are so many efforts wasted with this topic already. Again, my position on the topic: No, this doesn't belong to the installer. Thanks for taking the time to think about it. I very much respect your opinion. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MOpZUmS-b=bzdX0=h_+wu-9pwptrcmzatnmyblhk0-...@mail.gmail.com
Re: init-select
On Fri, Jan 3, 2014 at 11:44 AM, Michael Gilbert wrote: On Fri, Jan 3, 2014 at 11:19 AM, Cyril Brulebois wrote: Anyway, not going to play on words because there are so many efforts wasted with this topic already. Again, my position on the topic: No, this doesn't belong to the installer. Thanks for taking the time to think about it. I very much respect your opinion. I should clarify. I very much respect your opinion, but I do disagree, so it would be nice to hear thoughts from other d-i people than outright abandoning the idea. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MNhythfieDqNyKgiQJMC9Lsp_iB=bszampashnntqw...@mail.gmail.com
Re: init-select
Hi Michael, Le vendredi, 3 janvier 2014, 12.00:27 Michael Gilbert a écrit : On Fri, Jan 3, 2014 at 11:44 AM, Michael Gilbert wrote: On Fri, Jan 3, 2014 at 11:19 AM, Cyril Brulebois wrote: Anyway, not going to play on words because there are so many efforts wasted with this topic already. Again, my position on the topic: No, this doesn't belong to the installer. Thanks for taking the time to think about it. I very much respect your opinion. I should clarify. I very much respect your opinion, but I do disagree, so it would be nice to hear thoughts from other d-i people than outright abandoning the idea. For what is worth (as I've only been marginally involved with d-i-n-i and win32-loader), I also totally disagree that this fits within the installer team umbrella. It's not something that is needed for (or wanted by) the Debian installer at all. Also, I concur very Cyril here: we all need to wait (patiently, arguably) until the TC decides which init Debian will use as default . From there on (unless challenged by a GR of course), it is my opinion that we need to stand behind the decision. I think people should also stop building on the fallacy that supporting multiple init systems permanently on Linux is anywhere close to a good idea. Let's spare our energies and make Debian work as best as possible with one single init system that the TC (and/or the developers' body) will have chosen. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Re: init-select
Michael Gilbert mgilb...@debian.org writes: On Fri, Jan 3, 2014 at 11:00 AM, Cyril Brulebois k...@debian.org wrote: Michael Gilbert mgilb...@debian.org (2014-01-03): It is often far more ideal when the TC chooses to not act. TC action means that the project is somehow dysfunctional. init-select is a very simple technical solution to a very large social problem. Having to pick an init system is *not* a social problem. All TC decisions are attempts at the resolution of social problems. They only consider issues that involve the social disagreement between at least two people. The fact that the disagreement is happens to be over a technical topic does not eliminate the social aspect. Trying to support several init systems is *not* in the best interest of a distribution. Having a fully functional one (and a transition from the former if it's different) is what we need to work on. Following that logic, supporting multiple packaging helpers, desktop environments, text editors, compilers, kernels, so on and so on are also *not* in the best interest of a distribution. Let's pick the most functional ones, that is what we need to work on. As Cyril already said these are false analogies. Supporting multiple packageing helpers does not place a burden on maintainers that only use one of them. It's also invisible to users. Similar arguments can be made for your other examples. On the other hand supporting several init systems places a burden onto every daemon maintainer. Every init system is only usefull if it's supported by all packages. The option of just useing the init script compatibility layer that most (all) init systems currently provide is IMO just not an option because it does not let us use most of the benefits of the newer systems. It's just sysv-init in new cloths. Gaudenz P.S.: This is my last mail to this thread. I don't think we have to reiterate this debate over and over on different lists. -- Ever tried. Ever failed. No matter. Try again. Fail again. Fail better. ~ Samuel Beckett ~ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877gagly1c@meteor.durcheinandertal.bofh
Re: init-select
On Fri, Jan 3, 2014 at 1:29 PM, Gaudenz Steinlin wrote: Michael Gilbert mgilb...@debian.org writes: On Fri, Jan 3, 2014 at 11:00 AM, Cyril Brulebois k...@debian.org wrote: Michael Gilbert mgilb...@debian.org (2014-01-03): It is often far more ideal when the TC chooses to not act. TC action means that the project is somehow dysfunctional. init-select is a very simple technical solution to a very large social problem. Having to pick an init system is *not* a social problem. All TC decisions are attempts at the resolution of social problems. They only consider issues that involve the social disagreement between at least two people. The fact that the disagreement is happens to be over a technical topic does not eliminate the social aspect. Trying to support several init systems is *not* in the best interest of a distribution. Having a fully functional one (and a transition from the former if it's different) is what we need to work on. Following that logic, supporting multiple packaging helpers, desktop environments, text editors, compilers, kernels, so on and so on are also *not* in the best interest of a distribution. Let's pick the most functional ones, that is what we need to work on. As Cyril already said these are false analogies. Supporting multiple packageing helpers does not place a burden on maintainers that only use one of them. It's also invisible to users. Similar arguments can be made for your other examples. On the other hand supporting several init systems places a burden onto every daemon maintainer. Every init system is only usefull if it's supported by all packages. So, somehow I think this keeps getting misunderstood, or maybe not contemplated at a deeper level. Support for multiple inits means each island in debian gets to choose the init that suites them best. gnome and kde lands can choose systemd since it enables them to be closest to upstream. kfreebsd, hurd, xfce, and whatever else lands can choose upstart due to is portability, so on and so forth. Ultimately, debian is going to have multiple inits. It is simple matter of fact. gnome will need systemd. kfreebsd needs something more portable. Let's think about how we get to the state where we support that dynamism in a user-friendly manner. The option of just useing the init script compatibility layer that most (all) init systems currently provide is IMO just not an option because it does not let us use most of the benefits of the newer systems. It's just sysv-init in new cloths. My arguments have never been for that. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mppbdslo41pdsmp7hbddtek8jvppwhn9cne5hnp0rf...@mail.gmail.com
Re: init-select
Michael Gilbert mgilb...@debian.org (2014-01-02): Hi :) The TC init discussion has diverged significantly from Debian's usual ideals of freedom and meritocracy, so I decided to do something about it. So, today I wrote init-select. It's a small tool that empowers users to freely and simply choose among all of the available init systems. It also empowers Debian contributors to devote their energy toward their favorite init knowing that users can easily swap inits to try the new features they are working on. But most importantly, it provides a path for eliminating the politicization of the init system problem. That would be achieved if Debian's default init were to simply become init-select's default. Now, I certainly don't want all that weight solely on my shoulders, so I would very much prefer this choice to be team-maintained, and I think the installer/boot team has the expertise and clout to make the right choice when the time is really right to change the default Debian init. The initial package is up for review at: http://people.debian.org/~mgilbert/other I've set the maintainer to debian-boot now in the hope that this proposal sounds reasonable. There is of course more work to do, which is documented in a TODO file in the source, which will make the package better, but the existing functionality, I think, is already useful. I can switch inits on a whim in seconds now. Anyway, that is my modest proposal. I hope this doesn't sound too overly idealistic, intrusive, or I suppose out of the blue :) Best wishes, Mike Even if what's happening on tech-ctte isn't exactly ideal, I don't think letting users choose their init system is a service to them. Editing a kernel command line is enough for those who want to play. Others don't need to bother. Mraw, KiBi. signature.asc Description: Digital signature
Re: init-select
On Thu, Jan 2, 2014 at 8:39 PM, Cyril Brulebois wrote: Even if what's happening on tech-ctte isn't exactly ideal, I don't think letting users choose their init system is a service to them. Editing a kernel command line is enough for those who want to play. Others don't need to bother. So, I suppose this isn't immediately obvious, but there is another solved problem here. Say the TC ultimately does not choose systemd as the default, and one day gnome entirely drops compatibility with the other inits. The gnome maintainers can take advantage of init-select to automatically move their users from whatever that default is to systemd. That is simply # init-select /bin/systemd # update-grub somewhere appropriate in their maintainer scripts. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mo99nvxycbcp6gubqfzl484wk3rn8bav0hhgizsgrb...@mail.gmail.com
