Re: [DNG] We Must be Prepared ....

Clarke Sideroad writes: 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, "ju

Re: [DNG] We Must be Prepared ....

Forking the kernel will be difficult, but honestly, it's the sane choice. I'm often reminded of the story of the pig who tried to eat everything. He popped and got turned into bacon after he ate too much. Sent from my Windows Phone From: Clarke Sideroad

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 wrote: [snip] > > And if each of those -*-init packages depended on their > > respective init system, and each of those init systems provide the > > virtual package "init" (as is the

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 a

Re: [DNG] Packages aren't the only path to alternate inits

On Thu, 18 Jun 2015 17:06:17 +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 MA

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

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,

Re: [DNG] Packages aren't the only path to alternate inits

On 18/06/15 17:37, Hendrik Boom wrote: On Thu, Jun 18, 2015 at 05:26:28PM +0200, Anto wrote: 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 the

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

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 h

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 wrote: > "The job of keeping kernel development moving isn't

Re: [DNG] Packages aren't the only path to alternate inits

On Thu, Jun 18, 2015 at 05:26:28PM +0200, Anto wrote: > > > 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 specif

[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

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

Re: [DNG] Packages aren't the only path to alternate inits

On Thu, Jun 18, 2015 at 04:22:15PM +0100, KatolaZ wrote: > > I agree that maintaining all the init scripts in a single package is > not just crazy but practically impossible. A quick: Just like maintaining all the printer drivers in one cups. -- hendrik __

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 wrote: On 18/06/15 10:43, Steve Litt wrote: On Wed, 17 Jun 2015 21:27:21 +0200 Anto wrote: On 17/06/15 17:37, Steve Litt wrote: Hi all, After the recent discussions, I'd like to point out that packa

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 computation

Re: [DNG] Packages aren't the only path to alternate inits

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 c

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: > >> depends on: init, -sysv-init | -epoch-init | > >>-systemd-init | -openrc-init | -upstart-init > > > >Who, too much for me! To

Re: [DNG] Packages aren't the only path to alternate inits

On Thu, 18 Jun 2015 16:06:00 +0200 Laurent Bercot 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 th

Re: [DNG] Packages aren't the only path to alternate inits

On 18/06/2015 15:47, Steve Litt wrote: I expect the dependency chain should be something like: depends on: init, -sysv-init | -epoch-init | -systemd-init | -openrc-init | -upstart-init Who, too much for me! Too much for most people. Entangled. Still, it is an accurate representation of

Re: [DNG] Packages aren't the only path to alternate inits

On Thu, 18 Jun 2015 21:29:36 +1200 Daniel Reurich wrote: > On 18/06/15 10:43, Steve Litt wrote: > > On Wed, 17 Jun 2015 21:27:21 +0200 > > Anto wrote: > > > >> > >> > >> On 17/06/15 17:37, Steve Litt wrote: > >>> Hi all, > >>> > >>> After the recent discussions, I'd like to point out that packag

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

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 thes

Re: [DNG] Packages aren't the only path to alternate inits

On 19/06/15 00:04, Noel Torres wrote: Didier Kryn escribió: [...] I expect the dependency chain should be something like: depends on: init, -sysv-init | -epoch-init | -systemd-init | -openrc-init | -upstart-init And if each of those -*-init packages depended on their respective init system, a

Re: [DNG] Packages aren't the only path to alternate inits

Didier Kryn escribió: [...] I expect the dependency chain should be something like: depends on: init, -sysv-init | -epoch-init | -systemd-init | -openrc-init | -upstart-init And if each of those -*-init packages depended on their respective init system, and each of those init systems pr

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 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 pe

Re: [DNG] Packages aren't the only path to alternate inits

On 18/06/15 10:43, Steve Litt wrote: On Wed, 17 Jun 2015 21:27:21 +0200 Anto 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+da

Re: [DNG] [Dng] A nice candidate substitute to network-manager

> That depends entirely on one's level of paranoia -- in this case, that > the option of not using systemd may disappear with later releases. You can always ask the dev for their plans regarding dependencies on systemd instead of just instantly dropping the project :D signature.asc Description: