Re: [DNG] Packages aren't the only path to alternate inits
On 19/06/15 00:04, Noel Torres wrote: Didier Kryn k...@in2p3.fr escribió: [...] I expect the dependency chain should be something like: daemon depends on: init, daemon-sysv-init | daemon-epoch-init | daemon-systemd-init | daemon-openrc-init | daemon-upstart-init And if each of those daemon-*-init packages depended on their respective init system, and each of those init systems provide the virtual package init (as is the case in Debian and Devuan Jessie), then apt should be able to work out that when installing daemon that because sysvinit-core is the package providing init that it must also install daemon-sysv-init in order to satisfy the dependency. The problem is whether changing init systems would result in pulling in the new daemon-*-init dependency required for the new init system. Thoughts?? This is the normal way of implementing this kind of multiple alternative dependencies in Debian, AFAIU. The only reason I did not advocate this before is that it would bring in a bunch of new packages each containing only one small file. But this might not be a big deal after all, considering it solves the problem completely, allows to get rid of the irritating systemd service files, and treats all other init systems equally. I support this idea. Didier I support it as well, but this implies the extra work of putting the sysvinit scripts in separate packages, and that's quite a lot of work, and deepens the Delta with our Upstream (a.k.a. Debian), so when they fix something (e.g. a bug in Apache) we will need to port that to our package, instead of just copying their package. It's just a change in the control file and install files in debian/ for the package. No big deal really. Maybe a compromise solution is to do this for all init systems but sysvinit, for Jessie, and work on the fully hairy dependency chain for Jessie+1 a.k.a Ascii. That could work, but there is nothing stop starting that work in ascii now (except all the work needed to get Jessie out the door). -- Daniel Reurich Centurion Computer Technology (2005) Ltd. 021 797 722 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
Le 18/06/2015 11:29, Daniel Reurich a écrit : On 18/06/15 10:43, Steve Litt wrote: On Wed, 17 Jun 2015 21:27:21 +0200 Anto arya...@chello.at wrote: On 17/06/15 17:37, Steve Litt wrote: Hi all, After the recent discussions, I'd like to point out that packages aren't the ONLY path to alternate inits. I've personally demonstrated that with SucklessInit+daemontoolsEncore, SucklessInit+s6, runit, and Epoch, it's quite doable to download, build, and install these things in parallel to each other. I fully endorse the effort to put alternative inits in packages. It would be wonderful to have, for instance, an Epoch package that just works. I also endorse those individuals who go the out-of-package route. Thanks, SteveT Steve Litt June 2015 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key Hello Steve, I agree with you that packaging epoch init system is not the only way to have it as alternate init. However, that depends on the type of PC which we would use epoch init system on. What I plan to do is to have epoch init system on a regular PC which I am using everyday. So not on a test PC where I can do a lot of crazy things then just bin the idea if I am not happy and wipe the whole hard disk. On a regular PC, I want to be able to *easily* install and uninstall packages as I normally do, including switch back to sysvinit. And I want epoch init to be able to manage the daemons which might come from those packages, e.g. wicd package to manage my WiFi connection. For this purpose, I think the only way to be able to use epoch init system is to have it as a package, especially on Debian based distros. From what I have gathered and understood so far, I have 4 options to use epoch init system: 1. As I want to use Devuan, I have to patch all packages containing daemons that I want to use with epoch init configuration, build epoch package according to the packaging rules, compile them and install them as standard package. 2. If I still insisted to use Devuan but I don't want to go through all troubles on option 1, I compile epoch using the upstream build script, manually install the compiled bin files, manually add the daemons init configurations into epoch.conf. Along the time, I will have to manually add epoch init configuration into epoch.conf, for every packages with daemons that I install. And I will have to deal with all issues related to those packages due to the incompatibilities between epoch and sysvinit. 3. I don't want to keep following Debian rules, so I develop my own distro with my own rules and my own package manager. The works for that will possibly be more than for both previous options, but I will have control over everything. 4. Or I just use LFS with epoch init system. Seriously, with my current knowledge and experience, you can be sure that I will fail if I would do any of the first 3 options. So the only feasible option is the last one. But why am I here making noise if I didn't want to use Devuan? So what am I going to do about this now a part from to forget about this and move on? Do you or anyone else have suggestions? Yes. I have a suggestion. I suggest we just start assembling a group of Epoch object descriptions for the top 30 most used daemons. Then, as people request them of other daemons, we add those. I suggest we keep these as a group of scripts, *not* as anything the upstream has to worry about. Look how this works: In 3 weeks we can have 30 Epoch daemon object recipes. sshd, ntpd, crond, httpd, all the usual suspects. In 3 weeks we've satisfied 80% of the people, with no help from the upstreams. We let people know that if they need an Epoch object description for a given daemon we don't yet support, we'll treat that like a bug report and make such a Epoch object description. As time goes on we'll have a big library of these things, and people will notice that Epoch object descriptions are an order of magnitude easier to understand, and therefore to DIY, as sysvinit scripts. Probably easier than systemd unit files too, given that I've never heard any person describe how systemd actually works. You can have most of your easy Epoch installation, on Devuan, in 3 weeks. I have virtual machines, so I can help. It will be fun. And you know what? I might just take each of those Epoch object descriptions, and make a daemontools/daemontools-encore/runit/s6 run file based on it. I wonder if now is the time to start separating out the init specific configuration files, initscripts or service files, libraries and binaries out into separate packages so that any particular init can be supported without treading on the toes of others. The only issue I can see with this is the dependency chain can get a bit hairy. I expect the dependency chain should be something like: daemon depends on: init, daemon-sysv-init | daemon-epoch-init | daemon-systemd-init | daemon-openrc-init | daemon-upstart-init And if each of those daemon-*-init
Re: [DNG] Packages aren't the only path to alternate inits
Didier Kryn k...@in2p3.fr escribió: [...] I expect the dependency chain should be something like: daemon depends on: init, daemon-sysv-init | daemon-epoch-init | daemon-systemd-init | daemon-openrc-init | daemon-upstart-init And if each of those daemon-*-init packages depended on their respective init system, and each of those init systems provide the virtual package init (as is the case in Debian and Devuan Jessie), then apt should be able to work out that when installing daemon that because sysvinit-core is the package providing init that it must also install daemon-sysv-init in order to satisfy the dependency. The problem is whether changing init systems would result in pulling in the new daemon-*-init dependency required for the new init system. Thoughts?? This is the normal way of implementing this kind of multiple alternative dependencies in Debian, AFAIU. The only reason I did not advocate this before is that it would bring in a bunch of new packages each containing only one small file. But this might not be a big deal after all, considering it solves the problem completely, allows to get rid of the irritating systemd service files, and treats all other init systems equally. I support this idea. Didier I support it as well, but this implies the extra work of putting the sysvinit scripts in separate packages, and that's quite a lot of work, and deepens the Delta with our Upstream (a.k.a. Debian), so when they fix something (e.g. a bug in Apache) we will need to port that to our package, instead of just copying their package. Maybe a compromise solution is to do this for all init systems but sysvinit, for Jessie, and work on the fully hairy dependency chain for Jessie+1 a.k.a Ascii. Just my one-and-a-half cents Envite from beneath the forgotten binJ1xeSuyOGL.bin Description: Clave PGP pública pgpnnt8z9CK3V.pgp Description: Firma digital PGP ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
On 18/06/15 11:29, Daniel Reurich wrote: On 18/06/15 10:43, Steve Litt wrote: Yes. I have a suggestion. I suggest we just start assembling a group of Epoch object descriptions for the top 30 most used daemons. Then, as people request them of other daemons, we add those. I suggest we keep these as a group of scripts, *not* as anything the upstream has to worry about. Look how this works: In 3 weeks we can have 30 Epoch daemon object recipes. sshd, ntpd, crond, httpd, all the usual suspects. In 3 weeks we've satisfied 80% of the people, with no help from the upstreams. We let people know that if they need an Epoch object description for a given daemon we don't yet support, we'll treat that like a bug report and make such a Epoch object description. As time goes on we'll have a big library of these things, and people will notice that Epoch object descriptions are an order of magnitude easier to understand, and therefore to DIY, as sysvinit scripts. Probably easier than systemd unit files too, given that I've never heard any person describe how systemd actually works. You can have most of your easy Epoch installation, on Devuan, in 3 weeks. I have virtual machines, so I can help. It will be fun. And you know what? I might just take each of those Epoch object descriptions, and make a daemontools/daemontools-encore/runit/s6 run file based on it. I wonder if now is the time to start separating out the init specific configuration files, initscripts or service files, libraries and binaries out into separate packages so that any particular init can be supported without treading on the toes of others. The only issue I can see with this is the dependency chain can get a bit hairy. I expect the dependency chain should be something like: daemon depends on: init, daemon-sysv-init | daemon-epoch-init | daemon-systemd-init | daemon-openrc-init | daemon-upstart-init And if each of those daemon-*-init packages depended on their respective init system, and each of those init systems provide the virtual package init (as is the case in Debian and Devuan Jessie), then apt should be able to work out that when installing daemon that because sysvinit-core is the package providing init that it must also install daemon-sysv-init in order to satisfy the dependency. The problem is whether changing init systems would result in pulling in the new daemon-*-init dependency required for the new init system. Thoughts?? Hello Daniel, That would be really great, especially if the *now is the time* that you mentioned is for Devuan jessie. But I think you and other Devuan developers have already a lot on your plates. And I believe releasing Devuan jessie with sysvinit was the initial plan and it has the highest priority. That is why I always use the subject *I* on my emails here, instead of *we*, because *we* usually implies we would like to have that and could *you* please implement that for us :) Perhaps after Devuan jessie gains popularity, *we* could start diverting further from the road that Debian takes. Cheers, Anto ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
On Thu, 18 Jun 2015 21:29:36 +1200 Daniel Reurich dan...@centurion.net.nz wrote: On 18/06/15 10:43, Steve Litt wrote: On Wed, 17 Jun 2015 21:27:21 +0200 Anto arya...@chello.at wrote: On 17/06/15 17:37, Steve Litt wrote: Hi all, After the recent discussions, I'd like to point out that packages aren't the ONLY path to alternate inits. I've personally demonstrated that with SucklessInit+daemontoolsEncore, SucklessInit+s6, runit, and Epoch, it's quite doable to download, build, and install these things in parallel to each other. I fully endorse the effort to put alternative inits in packages. It would be wonderful to have, for instance, an Epoch package that just works. I also endorse those individuals who go the out-of-package route. Thanks, SteveT Steve Litt June 2015 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key [snip] Yes. I have a suggestion. I suggest we just start assembling a group of Epoch object descriptions for the top 30 most used daemons. Then, as people request them of other daemons, we add those. I suggest we keep these as a group of scripts, *not* as anything the upstream has to worry about. Look how this works: In 3 weeks we can have 30 Epoch daemon object recipes. sshd, ntpd, crond, httpd, all the usual suspects. In 3 weeks we've satisfied 80% of the people, with no help from the upstreams. We let people know that if they need an Epoch object description for a given daemon we don't yet support, we'll treat that like a bug report and make such a Epoch object description. As time goes on we'll have a big library of these things, and people will notice that Epoch object descriptions are an order of magnitude easier to understand, and therefore to DIY, as sysvinit scripts. Probably easier than systemd unit files too, given that I've never heard any person describe how systemd actually works. You can have most of your easy Epoch installation, on Devuan, in 3 weeks. I have virtual machines, so I can help. It will be fun. And you know what? I might just take each of those Epoch object descriptions, and make a daemontools/daemontools-encore/runit/s6 run file based on it. I wonder if now is the time to start separating out the init specific configuration files, initscripts or service files, libraries and binaries out into separate packages so that any particular init can be supported without treading on the toes of others. The only issue I can see with this is the dependency chain can get a bit hairy. Why not leave sysvinit just how it is? It works. It's been working for 20 years. My suggestion was a big box of Epoch defs, and a big box of Daemontools[-encore] runscripts, and a big box of s6 runscripts, and a big box of runit runscripts. apt-get install epoch-scripts The preceding just lays down the Epoch defs somewhere from which you can copy and paste them. Or, if somebody is cool enough to write a program, the program can copy and paste them. The same would be true, respective of init system, for s6-scripts, daemontools-scripts, and runit-scripts. Amount of work: Minimal Amount of rework: Zero Toes stepped on: None Extra work for upstreams: Zero This might start out as a 100% user driven thing, with the user copying and pasting according to a README file. Later, as we have success with it and understand the nature of automation needed by the user, we can provide programs to automate it, right alongside the big box of scripts. By slowly progressing from user-driven to automated, we can get *something* out there quickly. Think of it as agile packaging :-) I expect the dependency chain should be something like: daemon depends on: init, daemon-sysv-init | daemon-epoch-init | daemon-systemd-init | daemon-openrc-init | daemon-upstart-init Who, too much for me! Too much for most people. Entangled. Leave OpenRC, Upstart, systemd and sysvinit alone: They already work (well, except for systemd). If the user wants Epoch, just give him the tools for Epoch, and leave the rest where it sits. Same with daemontools-encore, s6 or runit. And if each of those daemon-*-init packages depended on their respective init system, and each of those init systems provide the virtual package init (as is the case in Debian and Devuan Jessie), then apt should be able to work out that when installing daemon that because sysvinit-core is the package providing init that it must also install daemon-sysv-init in order to satisfy the dependency. The problem is whether changing init systems would result in pulling in the new daemon-*-init dependency required for the new init system. Thoughts?? My thought is there are some packaging tasks better done by a five step README doc. All this package dependency described in this email is an example. Instead, just have one package that installs Epoch, with the epoch program in /sbin. Have another package
Re: [DNG] Packages aren't the only path to alternate inits
On Thu, Jun 18, 2015 at 12:04:33PM +, Noel Torres wrote: Maybe a compromise solution is to do this for all init systems but sysvinit, for Jessie, and work on the fully hairy dependency chain for Jessie+1 a.k.a Ascii. Devuan jessie will not see anything like that. For jessie we need to focus to release as early as possible and to stay more close to debian as we can, just removing systemd and using sysvinit and few other non critical changes. We can think about change anything we want to do starting from ascii, so, amy proposition is welcome to be experimented and tested following the usual path experimental - if accepted going to ceres - after 10 day in ceres with no critical bugs can migrate to ascii. -- Franco (nextime) Lanza Lonate Pozzolo (VA) - Italy SIP://c...@casa.nexlab.it web: http://www.nexlab.net NO TCPA: http://www.no1984.org you can download my public key at: http://danex.nexlab.it/nextime.asc || Key Servers Key ID = D6132D50 Key fingerprint = 66ED 5211 9D59 DA53 1DF7 4189 DFED F580 D613 2D50 --- echo 16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D212153574F444E49572045535520454D20454B414D204F54204847554F4E452059415020544F4E4E4143205345544147204C4C4942snlbxq | dc --- signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
On 18/06/15 15:47, Steve Litt wrote: On Thu, 18 Jun 2015 21:29:36 +1200 Daniel Reurich dan...@centurion.net.nz wrote: On 18/06/15 10:43, Steve Litt wrote: On Wed, 17 Jun 2015 21:27:21 +0200 Anto arya...@chello.at wrote: On 17/06/15 17:37, Steve Litt wrote: Hi all, After the recent discussions, I'd like to point out that packages aren't the ONLY path to alternate inits. I've personally demonstrated that with SucklessInit+daemontoolsEncore, SucklessInit+s6, runit, and Epoch, it's quite doable to download, build, and install these things in parallel to each other. I fully endorse the effort to put alternative inits in packages. It would be wonderful to have, for instance, an Epoch package that just works. I also endorse those individuals who go the out-of-package route. Thanks, SteveT Steve Litt June 2015 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key [snip] Yes. I have a suggestion. I suggest we just start assembling a group of Epoch object descriptions for the top 30 most used daemons. Then, as people request them of other daemons, we add those. I suggest we keep these as a group of scripts, *not* as anything the upstream has to worry about. Look how this works: In 3 weeks we can have 30 Epoch daemon object recipes. sshd, ntpd, crond, httpd, all the usual suspects. In 3 weeks we've satisfied 80% of the people, with no help from the upstreams. We let people know that if they need an Epoch object description for a given daemon we don't yet support, we'll treat that like a bug report and make such a Epoch object description. As time goes on we'll have a big library of these things, and people will notice that Epoch object descriptions are an order of magnitude easier to understand, and therefore to DIY, as sysvinit scripts. Probably easier than systemd unit files too, given that I've never heard any person describe how systemd actually works. You can have most of your easy Epoch installation, on Devuan, in 3 weeks. I have virtual machines, so I can help. It will be fun. And you know what? I might just take each of those Epoch object descriptions, and make a daemontools/daemontools-encore/runit/s6 run file based on it. I wonder if now is the time to start separating out the init specific configuration files, initscripts or service files, libraries and binaries out into separate packages so that any particular init can be supported without treading on the toes of others. The only issue I can see with this is the dependency chain can get a bit hairy. Why not leave sysvinit just how it is? It works. It's been working for 20 years. My suggestion was a big box of Epoch defs, and a big box of Daemontools[-encore] runscripts, and a big box of s6 runscripts, and a big box of runit runscripts. apt-get install epoch-scripts The preceding just lays down the Epoch defs somewhere from which you can copy and paste them. Or, if somebody is cool enough to write a program, the program can copy and paste them. The same would be true, respective of init system, for s6-scripts, daemontools-scripts, and runit-scripts. Amount of work: Minimal Amount of rework: Zero Toes stepped on: None Extra work for upstreams: Zero This might start out as a 100% user driven thing, with the user copying and pasting according to a README file. Later, as we have success with it and understand the nature of automation needed by the user, we can provide programs to automate it, right alongside the big box of scripts. By slowly progressing from user-driven to automated, we can get *something* out there quickly. Think of it as agile packaging :-) Hello Steve, I don't think we can leave sysvinit as it is now if we want to treat it the same as other inits. I think we need to remove sysvinit specific files from all daemon packages, otherwise they will pull sysvinit specific files as well when we install them under other inits. I expect the dependency chain should be something like: daemon depends on: init, daemon-sysv-init | daemon-epoch-init | daemon-systemd-init | daemon-openrc-init | daemon-upstart-init Who, too much for me! Too much for most people. Entangled. Leave OpenRC, Upstart, systemd and sysvinit alone: They already work (well, except for systemd). If the user wants Epoch, just give him the tools for Epoch, and leave the rest where it sits. Same with daemontools-encore, s6 or runit. What Daniel explains is actually I think the same as what I had in mind. I would imagine by doing that, only files specific to the init that is currently running will be pulled when we install the daemon package. And if each of those daemon-*-init packages depended on their respective init system, and each of those init systems provide the virtual package init (as is the case in Debian and Devuan Jessie), then apt should be able to work out that when installing daemon that because sysvinit-core is the package providing init that it must also install daemon-sysv-init in order to
[DNG] We Must be Prepared ....
The job of keeping kernel development moving isn't so much about technical know-how these days, he said. Running the core of arguably the world's most important operating system is now about being trusted and being available. GREG (AKA GREG KROAH HARTMAN) IS THE OBVIOUS NUMBER TWO. HE COULD TAKE IT UP, and then there are a couple of other people. Linus Torvalds Guy, that's the guy who wants by all means, kdbus in the kernel. That's the systemd guy in the linux kernel community. http://www.theregister.co.uk/2015/06/17/now_i_can_die_happy_what_linus_didnt_iquitei_say/ -- Stop slacking you lazy bum! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
On Thu, 18 Jun 2015 16:06:00 +0200 Laurent Bercot ska-de...@skarnet.org wrote: I think the original point was to spread the maintenance burden. If you gather all the service definitions for one service manager in one package, then you centralize the maintenance burden - who will want to be responsible for that package ? Even as the author of s6, with a strong desire to have s6 be widely used in a mainstream distribution, I am *not* going to write and maintain s6-compatible service definitions for every daemon under the sun - this is crazy work. On the other hand, if every daemon has its service definition for whatever service manager in a separate package, it all becomes much more manageable. I was envisioning Devuan people making the defs and runscripts, not the authors of the init systems. It would be crazy for us to think you, or someone in your position, would write AND MAINTAIN between 30 and 200 run scripts. That's crazy. What wouldn't be crazy would be for two or three Devuan people to write and maintain a fleet of s6 run scripts. Truth be told, I was envisioning *myself* as one of those people. SteveT Steve Litt June 2015 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
On Thu, Jun 18, 2015 at 04:06:00PM +0200, Laurent Bercot wrote: On 18/06/2015 15:47, Steve Litt wrote: I expect the dependency chain should be something like: daemon depends on: init, daemon-sysv-init | daemon-epoch-init | daemon-systemd-init | daemon-openrc-init | daemon-upstart-init Who, too much for me! Too much for most people. Entangled. Still, it is an accurate representation of the dependencies. Now I presume the various init-script packages depend on the init systems. And if the various init systems mutually exclude each other, then presumably aptitude has to thread its way through a maze to find the particular initsystem that's already installed and hence daemon-initsystem package that's needed. Don't want another init system installed just because aptitude picked the wrong choice in the daemon-sysv-init | daemon-epoch-init | ... list. I assume that aptitude has enough algorithmic capacity to do this, but when things get complicated there may not be enough computational power to carry out this analysis in available time and space. Bow, since its possible to have seeral init systems installedd, and even to have different subsytems started by different init systems (not all running as PID 1, of course), perhaps the mutual exclusion among the init systems is a bad idea. What is perhaps needed for the daemon-initsystem packages is for the package manager do recognise a request that the daemon-initsystem package be installed if and only if the daemon package has been installed and the initsystem package has also been installed. This would require changes in the package manager and would likely delay the devuan jessie release. Such cojunctive reverse dependencies would bw useful in a lot of other cases, such as bindings between programming languages and libraries. But I can't recommend this be done for davuan jessie. Too soon, and it would make jessie too late. -- hendrik If it is too complex, then we need to figure out a way to make it look simpler. The average user doesn't need to know what the whole graph is, and the packager is supposed to be able to understand something as simple as the separation between the mechanism (daemon) and the policy (how to start the daemon). snip -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
On 18/06/2015 16:57, Hendrik Boom wrote: I assume that aptitude has enough algorithmic capacity to do this, but when things get complicated there may not be enough computational power to carry out this analysis in available time and space. My experience is that we have way more computational power than we think, and most inefficiencies come from the implementation, not the amount of work there is to perform. I'm working on a dependency manager. At some point, I have to do some operation in O(n^2), n being the number of services; there's no other choice. But it's still blazingly fast, and you can have up to thousands of services with sub-second execution times. Modern computers are powerful, and data size is nothing to be afraid of - as opposed to program size, which must be handled by humans. So, yeah, if aptitude can handle package dependencies, just feed it, make it work. Even if you have disjunctions - and disjunctions are algorithmically expensive - it's not what will take the most time. Unless, of course, the engine is written in Python or something equally unsuited. Bow, since its possible to have seeral init systems installedd, and even to have different subsytems started by different init systems (not all running as PID 1, of course), perhaps the mutual exclusion among the init systems is a bad idea. Absolutely. Why enforce exclusion when you can have a choice ? Make a currently active vs. inactive switch, I don't know the Debian/Devuan terminology, and allow users to install both. But I can't recommend this be done for davuan jessie. Too soon, and it would make jessie too late. I think we're all planning for the future, here - get Jessie out first, and then small steps, one at a time. :) -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
On Thu, Jun 18, 2015 at 05:06:17PM +0200, Laurent Bercot wrote: On 18/06/2015 16:15, Steve Litt wrote: I was envisioning Devuan people making the defs and runscripts, not the authors of the init systems. It would be crazy for us to think you, or someone in your position, would write AND MAINTAIN between 30 and 200 run scripts. That's crazy. What wouldn't be crazy would be for two or three Devuan people to write and maintain a fleet of s6 run scripts. But my point is that it's crazy no matter who does it! Devuan people aren't superhuman. How do you expect to give every script the attention it requires and deserves if you're maintaining 200 of them? If I, an upstreamer, make a small change to a daemon's interface, the change has to be reflected in the service scripts; if I make one such change a month, it's definitely manageable for you, packager, as long as I'm the only one doing it - but if every upstreamer you have is doing the same thing, you'll go bonkers in no time. You were complaining about the difficulty of managing the VimOutliner package; well, if the package maintainer was responsible for a hundred other upstreamers, it's really no wonder. And you're suggesting that two or three poor Devuan maintainers take up a fleet of s6 - or other - scripts in one unique package, while making sure things are kept clean and simple and don't become as overloaded as Debian init scripts did? In one year they'll flip tables and go raise goats in Africa in order to never have to touch a computer again. +1 I agree that maintaining all the init scripts in a single package is not just crazy but practically impossible. A quick: enzo@kaa:~$ apt-file -x search /etc/init.d/ | wc -l 1201 enzo@kaa:~$ should clarify any remaining doubt HND KatolaZ -- [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ] [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ] [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ] [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We Must be Prepared ....
I'm not worried. Linus won't accept kdbus until he thinks it's in a position where it will be stable and easily supported for the foreseeable future. Watching kdbus get refactored a few times over this past year, I'd wager a guess that they're going to end up keeping as much of dbus in userspace as possible, and only add the parts that absolutely must run in kernel space to the kernel (as kdbus). Thus far, this has been limited to the memfd API, which is needed for zero-copy memory transfers. They'll probably also end up adding a specialized kdbusfs (akin to devpts) that offers namespaced and permissioned access to dbus endpoints, represented as a hierarchy of character device files. Remember, kdbus isn't dbus, anymore than a UNIX domain socket is dbus. The reason they're working on kdbus at all is because they have discovered that it's costly to pipe a lot of data between dbus endpoints, and it's hard to control capabilities, visibility, and access to them (since there are usecases where endpoints may not trust each other). Arguably, these problems can be addressed by using a combination of existing IPC mechanisms, but the argument that Greg KH and company put forth over and over again is that there's too much legacy code using dbus at this point (namely, from the IVI community and desktop communities) that we can't just tell them to refactor everything. It might be true--I don't know how big the IVI codebases are, for example. However, I don't really sympathize with the desktop communities--they built dbus to their specifications from their experiences with DCOP and Bonobo, and still managed to get it wrong. My $0.02. -Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We Must be Prepared ....
Does seem to be true, that he is a systemd supporter: http://kroah.com/log/blog/2014/01/15/kdbus-details/ Anybody have a crystal ball? Will a kernel fork be required to not use systemd? On Thu, Jun 18, 2015 at 10:59 AM, Marlon Nunes nu...@openmailbox.org wrote: The job of keeping kernel development moving isn't so much about “technical know-how” these days, he said. Running the core of arguably the world's most important operating system is now about “being trusted and being available. *Greg (aka Greg Kroah Hartman) is the obvious number two. He could take it up*, and then there are a couple of other people.” Linus Torvalds Guy, that's the guy who wants by all means, kdbus in the kernel. That's the systemd guy in the linux kernel community. http://www.theregister.co.uk/2015/06/17/now_i_can_die_happy_what_linus_didnt_iquitei_say/ -- Stop slacking you lazy bum! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We Must be Prepared ....
The problem is, kdbus isn't just an IPC, it's proprietary to systemd, and is the only software capable of utilizing it. Greg Hartman as the lead-takeover for Linus? Hell no. He'd give it to Lennart and Kay without batting an eye, and then shut out every developer save their own. Dare I say it, but Peter Griffin or Homer Simpson would be better choices... If Hartman takes over, the kernel will have to be forked. His track record of kissing Lennart's ass is too obvious. No no and no. Sent from my Windows Phone From: Jude Nelsonmailto:jud...@gmail.com Sent: 6/18/2015 9:20 AM To: Richardmailto:richard.h...@gmail.com Cc: dng@lists.dyne.orgmailto:dng@lists.dyne.org Subject: Re: [DNG] We Must be Prepared I'm not worried. Linus won't accept kdbus until he thinks it's in a position where it will be stable and easily supported for the foreseeable future. Watching kdbus get refactored a few times over this past year, I'd wager a guess that they're going to end up keeping as much of dbus in userspace as possible, and only add the parts that absolutely must run in kernel space to the kernel (as kdbus). Thus far, this has been limited to the memfd API, which is needed for zero-copy memory transfers. They'll probably also end up adding a specialized kdbusfs (akin to devpts) that offers namespaced and permissioned access to dbus endpoints, represented as a hierarchy of character device files. Remember, kdbus isn't dbus, anymore than a UNIX domain socket is dbus. The reason they're working on kdbus at all is because they have discovered that it's costly to pipe a lot of data between dbus endpoints, and it's hard to control capabilities, visibility, and access to them (since there are usecases where endpoints may not trust each other). Arguably, these problems can be addressed by using a combination of existing IPC mechanisms, but the argument that Greg KH and company put forth over and over again is that there's too much legacy code using dbus at this point (namely, from the IVI community and desktop communities) that we can't just tell them to refactor everything. It might be true--I don't know how big the IVI codebases are, for example. However, I don't really sympathize with the desktop communities--they built dbus to their specifications from their experiences with DCOP and Bonobo, and still managed to get it wrong. My $0.02. -Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We Must be Prepared ....
Richard writes: Will a kernel fork be required to not use systemd? Perhaps if Linus dies any time soon. But I think not even in that case — don't forget that android is the biggest linux distribution. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We Must be Prepared ....
I hoping the Kernel Developers as a combined whole would see the bigger Linux picture well beyond the desktop. I can't see the Kernel being made to swallow something that would poison the whole multifaceted structure in the way that the various distros swallowed the, just another init, what's all the fuss about?, ever expanding systemd. The other day I was watching Monty Python's Mr. Creosote sketch from The Meaning of Life movie and I came to realization that at some point the same fate will surely befall the systemd conglomeration. It is rapidly becoming the only thing an average Linux distro needs other than a desktop and the kernel and continues to swallow up tempting morsels left and right. I await the day that somebody gives the project a thin mint. In the meantime there still exists the parallel no-systemd universe, if it all goes to hell in a hand basket and it comes down to forking the Kernel, I think that would be the time to go to another restaurant entirely. Clarke ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
On Thu, Jun 18, 2015 at 09:47:21AM -0400, Steve Litt wrote: On Thu, 18 Jun 2015 21:29:36 +1200 Daniel Reurich dan...@centurion.net.nz wrote: [snip] And if each of those daemon-*-init packages depended on their respective init system, and each of those init systems provide the virtual package init (as is the case in Debian and Devuan Jessie), then apt should be able to work out that when installing daemon that because sysvinit-core is the package providing init that it must also install daemon-sysv-init in order to satisfy the dependency. The problem is whether changing init systems would result in pulling in the new daemon-*-init dependency required for the new init system. Thoughts?? My thought is there are some packaging tasks better done by a five step README doc. All this package dependency described in this email is an example. Instead, just have one package that installs Epoch, with the epoch program in /sbin. Have another package that puts common Epoch daemon defs in a directory, ready for copying and pasting. Just because one installs Epoch doesn't mean he wants to blow off sysvinit. One more thing: There are *huge* benefits of being able to choose your init, at runtime, just by changing your Grub or LILO init= value. I agree on that last point; booting with init=/bin/sh has helped me fix a system more than once. Also, it can be handy to switch between a known-good init and an experimental one. Honestly, the overhead of simply having another package is probably going to be at least as great as the overhead of installing scripts for all init systems, and will be paid in part by everyone: * the repository index gets larger - more disk space and bandwidth from the mirrors - more disk space and bandwidth required for the systems * the dpkg/apt package database gets larger * it gets harder to manually upgrade/downgrade packages * it gets harder to switch inits, due to the maze of initscripts that will need to be installed for each new package I see some comments that seem to assume that every init script should imply a dependency on the corresponding init system. A dependency is for a package without which the package would be unusable for its normal use (IIRC). If you use runit with a daemon that supports upstart, runit, and sysvinit, running /etc/init.d/script is not part of your normal use; there is no reason to depend on sysvinit except perhaps this way: Recommends: sysv-rc | upstart | runit As far as quantity of work goes, you may need to do more than just 30 daemons to get a moderately featureful desktop going. But maintaining the scripts separately is probably going to be easier than adopting each of the packages. You won't be maintaining scripts for all 1000+ packages: epoch users probaly won't want heartbeat, or the three UPS packages. If you do maintain scripts for separately maintained daemons, mark your packages as enhancing them. HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
On Thu, 18 Jun 2015 17:06:17 +0200 Laurent Bercot ska-de...@skarnet.org wrote: On 18/06/2015 16:15, Steve Litt wrote: I was envisioning Devuan people making the defs and runscripts, not the authors of the init systems. It would be crazy for us to think you, or someone in your position, would write AND MAINTAIN between 30 and 200 run scripts. That's crazy. What wouldn't be crazy would be for two or three Devuan people to write and maintain a fleet of s6 run scripts. But my point is that it's crazy no matter who does it! Devuan people aren't superhuman. How do you expect to give every script the attention it requires and deserves if you're maintaining 200 of them? If I, an upstreamer, make a small change to a daemon's interface, the change has to be reflected in the service scripts; if I make one such change a month, it's definitely manageable for you, packager, as long as I'm the only one doing it - but if every upstreamer you have is doing the same thing, you'll go bonkers in no time. You could make a million changes a day, but unless the changes were to the program's interface as seen from the command prompt, no init action is needed. If I were the run script maintainer and a project started making *interface* changes once a month or even twice a year, I'd code my run script to throw up a screen saying sorry, project x changes too much, get the run script from the upstream. With the possible exception of dbus, I don't see many interface changes over the years. SteveT Steve Litt June 2015 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We Must be Prepared ....
On 2015-06-18 14:13, James Powell wrote: The problem is, kdbus isn't just an IPC, it's proprietary to systemd, and is the only software capable of utilizing it. Greg Hartman as the lead-takeover for Linus? Hell no. He'd give it to Lennart and Kay without batting an eye, and then shut out every developer save their own. Dare I say it, but Peter Griffin or Homer Simpson would be better choices... If Hartman takes over, the kernel will have to be forked. His track record of kissing Lennart's ass is too obvious. No no and no. Even linus called him a kay sievers babysitter ... - From: Jude Nelson Sent: 6/18/2015 9:20 AM To: Richard Cc: dng@lists.dyne.org Subject: Re: [DNG] We Must be Prepared I'm not worried. Linus won't accept kdbus until he thinks it's in a position where it will be stable and easily supported for the foreseeable future. Watching kdbus get refactored a few times over this past year, I'd wager a guess that they're going to end up keeping as much of dbus in userspace as possible, and only add the parts that absolutely must run in kernel space to the kernel (as kdbus). Thus far, this has been limited to the memfd API, which is needed for zero-copy memory transfers. They'll probably also end up adding a specialized kdbusfs (akin to devpts) that offers namespaced and permissioned access to dbus endpoints, represented as a hierarchy of character device files. Remember, kdbus isn't dbus, anymore than a UNIX domain socket is dbus. The reason they're working on kdbus at all is because they have discovered that it's costly to pipe a lot of data between dbus endpoints, and it's hard to control capabilities, visibility, and access to them (since there are usecases where endpoints may not trust each other). Arguably, these problems can be addressed by using a combination of existing IPC mechanisms, but the argument that Greg KH and company put forth over and over again is that there's too much legacy code using dbus at this point (namely, from the IVI community and desktop communities) that we can't just tell them to refactor everything. It might be true--I don't know how big the IVI codebases are, for example. However, I don't really sympathize with the desktop communities--they built dbus to their specifications from their experiences with DCOP and Bonobo, and still managed to get it wrong. My $0.02. -Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng -- Stop slacking you lazy bum! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
On 18/06/15 00:43, Steve Litt wrote: On Wed, 17 Jun 2015 21:27:21 +0200 Anto arya...@chello.at wrote: On 17/06/15 17:37, Steve Litt wrote: Hi all, After the recent discussions, I'd like to point out that packages aren't the ONLY path to alternate inits. I've personally demonstrated that with SucklessInit+daemontoolsEncore, SucklessInit+s6, runit, and Epoch, it's quite doable to download, build, and install these things in parallel to each other. I fully endorse the effort to put alternative inits in packages. It would be wonderful to have, for instance, an Epoch package that just works. I also endorse those individuals who go the out-of-package route. Thanks, SteveT Steve Litt June 2015 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key Hello Steve, I agree with you that packaging epoch init system is not the only way to have it as alternate init. However, that depends on the type of PC which we would use epoch init system on. What I plan to do is to have epoch init system on a regular PC which I am using everyday. So not on a test PC where I can do a lot of crazy things then just bin the idea if I am not happy and wipe the whole hard disk. On a regular PC, I want to be able to *easily* install and uninstall packages as I normally do, including switch back to sysvinit. And I want epoch init to be able to manage the daemons which might come from those packages, e.g. wicd package to manage my WiFi connection. For this purpose, I think the only way to be able to use epoch init system is to have it as a package, especially on Debian based distros. From what I have gathered and understood so far, I have 4 options to use epoch init system: 1. As I want to use Devuan, I have to patch all packages containing daemons that I want to use with epoch init configuration, build epoch package according to the packaging rules, compile them and install them as standard package. 2. If I still insisted to use Devuan but I don't want to go through all troubles on option 1, I compile epoch using the upstream build script, manually install the compiled bin files, manually add the daemons init configurations into epoch.conf. Along the time, I will have to manually add epoch init configuration into epoch.conf, for every packages with daemons that I install. And I will have to deal with all issues related to those packages due to the incompatibilities between epoch and sysvinit. 3. I don't want to keep following Debian rules, so I develop my own distro with my own rules and my own package manager. The works for that will possibly be more than for both previous options, but I will have control over everything. 4. Or I just use LFS with epoch init system. Seriously, with my current knowledge and experience, you can be sure that I will fail if I would do any of the first 3 options. So the only feasible option is the last one. But why am I here making noise if I didn't want to use Devuan? So what am I going to do about this now a part from to forget about this and move on? Do you or anyone else have suggestions? Yes. I have a suggestion. I suggest we just start assembling a group of Epoch object descriptions for the top 30 most used daemons. Then, as people request them of other daemons, we add those. I suggest we keep these as a group of scripts, *not* as anything the upstream has to worry about. Look how this works: In 3 weeks we can have 30 Epoch daemon object recipes. sshd, ntpd, crond, httpd, all the usual suspects. In 3 weeks we've satisfied 80% of the people, with no help from the upstreams. We let people know that if they need an Epoch object description for a given daemon we don't yet support, we'll treat that like a bug report and make such a Epoch object description. As time goes on we'll have a big library of these things, and people will notice that Epoch object descriptions are an order of magnitude easier to understand, and therefore to DIY, as sysvinit scripts. Probably easier than systemd unit files too, given that I've never heard any person describe how systemd actually works. You can have most of your easy Epoch installation, on Devuan, in 3 weeks. I have virtual machines, so I can help. It will be fun. And you know what? I might just take each of those Epoch object descriptions, and make a daemontools/daemontools-encore/runit/s6 run file based on it. SteveT Steve Litt June 2015 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key Thanks Steve, It looks like that you suggested to go for option 2. I actually tend to go for option 3 especially that I have already cleaned up more than what Devuan does and recompiled all packages on my PC that I am using now to write this email. But I have to be realistic as I need a lot more than that to build a new distro. My knowledge and experience on this is also still quite thin so I have very high chance to fail. I must do this slowly step by step if I want to succeed, starting
