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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
21 matches
Mail list logo
