Le 04/05/2016 15:44, Rob Owens a écrit :
- Original Message -
From: "Didier Kryn"
Le 03/05/2016 19:10, Rob Owens a écrit :
Yes, but then when an openrc user wants to start/stop a service, he
cannot do '/etc/init.d/myservice start' like he could do on any other
OS using openrc. He'd ha
upstart is init subsystem which is using same names for binaries; commands
as sysvinit probably to be a drop in replacement, not ment to coexist with
sysvinit.
sysv-rc,openrc , file-rc all depend on init binary daemon and are
replacements for init.d/rc(S) files which init binary executes. so they
On Wed, 4 May 2016 09:54:37 -0400 (EDT)
Rob Owens wrote:
> - Original Message -
> > From: "Steve Litt"
>
> > On Tue, 3 May 2016 10:06:07 -0400 (EDT)
> > Rob Owens wrote:
> >
> >> I agree with putting each init in its own directory, but sysvinit
> >> should not own /etc/init.d. sy
If I had to be and admin of mixture of linux distributions I would
probably use 'service', instead of remembering all commands suited for
different init flavours and checking on which box I'm about to run a
command.
But in such a case I probably would not care what kind of init
subsystem is runnin
On Wed, May 04, 2016 at 09:44:30AM -0400, Rob Owens wrote:
Normally *this* admin never uses the service command because:
You should because the service command cleans the environment. If you do
„/etc/init.d/ start” you can have strange results.
1) it is not available on all distros or may n
- Original Message -
> From: "Steve Litt"
> On Tue, 3 May 2016 10:06:07 -0400 (EDT)
> Rob Owens wrote:
>
>> I agree with putting each init in its own directory, but sysvinit
>> should not own /etc/init.d. sysvinit stuff should go in /etc/sysvinit
>> and by default /etc/init.d should be
Robert Storey writes:
> For whatever it's worth, I'm fully supportive of the idea of defaulting to
> a simpler init system such as S6, Epoch, Runit, you-name-it. I can't speak
> for anyone else, of course, but I tend to think the sort of people who are
> attracted to Devuan see the virtue of simpl
- Original Message -
> From: "Didier Kryn"
> Le 03/05/2016 19:10, Rob Owens a écrit :
>> Yes, but then when an openrc user wants to start/stop a service, he
>> cannot do '/etc/init.d/myservice start' like he could do on any other
>> OS using openrc. He'd have to do '/etc/openrc/myservice
On Wed, May 04, 2016 at 08:10:40AM +0100, Simon Hobson wrote:
> Steve Litt wrote:
>
> > There's a special place in hell for people using ambiguous
> > abbreviations, acronyms, and nicknames.
>
> You mean, like the whole IT industry - and in fact pretty well any industry ?
> Such terms are routi
Steve Litt escribió:
[...]
I think the only daemons you really need in an installer are the
gettys, sshd, wpa_supplicant and dhcpcd. And you'll probably want
the display manager too. Those obviously must be included in packages.
The more obscure stuff can exist first on the Wiki, and gradually b
Le 04/05/2016 05:43, Joel Roth a écrit :
nteresting, I thought /sbin was historically for statically
linked executables needed at boot time, or for system
recovery.
I think the 's' stands for "System-critical", not "Statically-linked".
Didier
___
Le 03/05/2016 19:10, Rob Owens a écrit :
Yes, but then when an openrc user wants to start/stop a service, he
cannot do '/etc/init.d/myservice start' like he could do on any other
OS using openrc. He'd have to do '/etc/openrc/myservice start'. Not a
really big deal, but I think it's undesirable
On Wed, 04 May 2016 06:47:06 +
Noel Torres wrote:
> Steve Litt escribió:
>
> > On Mon, 2 May 2016 22:15:44 -1000
> > Joel Roth wrote:
> >
> >
> >> The problem with supporting multiple init systems is that
> >> there is an init script for each service that has to be
> >> ported or rewritt
On Wed, May 04, 2016 at 01:03:08PM +0800, Robert Storey wrote:
> For whatever it's worth, I'm fully supportive of the idea of defaulting to
> a simpler init system such as S6, Epoch, Runit, you-name-it.
Many people agree that sysvinit with its symlinks and run
levels is overly complex for the com
Steve Litt wrote:
> There's a special place in hell for people using ambiguous
> abbreviations, acronyms, and nicknames.
You mean, like the whole IT industry - and in fact pretty well any industry ?
Such terms are routinely used because they make speech and writing less
verbose. I did my appre
Steve Litt escribió:
On Mon, 2 May 2016 22:15:44 -1000
Joel Roth wrote:
The problem with supporting multiple init systems is that
there is an init script for each service that has to be
ported or rewritten.
[...]
It's a documentation task. If we had a wiki upon which users could
write the
On Wed, May 04, 2016 at 12:55:09AM -0400, Peter Olson wrote:
> > On May 3, 2016 at 11:43 PM Joel Roth wrote:
>
> [...]
>
> > Interesting, I thought /sbin was historically for statically
> > linked executables needed at boot time, or for system
> > recovery.
>
> The /sbin and /usr/sbin are anal
On Tue, May 03, 2016 at 03:24:47PM -1000, Joel Roth wrote:
> Hendrik Boom wrote:
> > There's a small number of directories that are supposed to be on the
> > root filesystem, or otherwise available during boot. I believe /etc
> > and /bin are two of these.
> >
> > /usr is not. I suspect /var i
Jim Murphy escribió:
[...]
UNIX and lookalikes have been able to boot into single user mode
with a small root filesystem without the need for /usr, /var or ...
There are still admins that have split any number of these directories
into their own filesystems for various reasons. I guess you can c
Am Tue, 03 May 2016 08:27:05 +
schrieb dng-requ...@lists.dyne.org:
> From: parazyd
> To: Hendrik Boom
> Cc: dng@lists.dyne.org
> Subject: Re: [DNG] OpenRC and Devuan
> Message-ID: <20160503071226.GA10101@hansolo>
> Content-Type: text/plain; charset="utf-8"
For whatever it's worth, I'm fully supportive of the idea of defaulting to
a simpler init system such as S6, Epoch, Runit, you-name-it. I can't speak
for anyone else, of course, but I tend to think the sort of people who are
attracted to Devuan see the virtue of simplicity. The main reason why we
d
> On May 3, 2016 at 11:43 PM Joel Roth wrote:
[...]
> Interesting, I thought /sbin was historically for statically
> linked executables needed at boot time, or for system
> recovery.
The /sbin and /usr/sbin are analogous to /bin and /usr/sbin but they contain
programs for administrative purpos
Steve Litt wrote:
> Joel Roth wrote:
>
> > Hendrik Boom wrote:
> > > There's a small number of directories that are supposed to be on
> > > the root filesystem, or otherwise available during boot. I
> > > believe /etc and /bin are two of these.
> > >
> > > /usr is not. I suspect /var isn't eit
On Tue, 3 May 2016 15:24:47 -1000
Joel Roth wrote:
> Hendrik Boom wrote:
> > There's a small number of directories that are supposed to be on
> > the root filesystem, or otherwise available during boot. I
> > believe /etc and /bin are two of these.
> >
> > /usr is not. I suspect /var isn't eit
* On 2016 03 May 16:38 -0500, Steve Litt wrote:
> "Pen testing" My Aunt's Hat!
I thought it was trying different Linux distributions from a USB pen.
Shrug.
- Nate
--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Ham radio, Linux
Hendrik Boom wrote:
> There's a small number of directories that are supposed to be on the
> root filesystem, or otherwise available during boot. I believe /etc
> and /bin are two of these.
>
> /usr is not. I suspect /var isn't either.
>
> init is supposed to be able to read /etc/fstab to fin
On Tue, 03 May 2016 23:07:05 +0200
Svante Signell wrote:
> On Tue, 2016-05-03 at 16:32 -0400, Steve Litt wrote:
> > On Tue, 3 May 2016 10:06:07 -0400 (EDT)
> >
> > Because OpenRC has seen fit to intermix their init scripts
> > with sysvinit's in /etc/init.d, I'd suggest that any files needed by
On Tue, 2016-05-03 at 23:24 +0200, parazyd wrote:
> On Tue, 03 May 2016, Svante Signell wrote:
>
> As I've stated at the beginning of this whole thread, debian-openrc is
> irrelevant and a bad way to solve the whole issue of using OpenRC
> properly, becase they keep using LSB initscripts...
What
Thanks Stephanie!
There's a special place in hell for people using ambiguous
abbreviations, acronyms, and nicknames. I mean really, do they think
this makes them sound more "in the know?"
That author is a WAD. Now I get to feel superior as the word WAD rolls
glibly and effortlessly off my tongue.
On Tue, 03 May 2016, Svante Signell wrote:
> On Tue, 2016-05-03 at 23:05 +0200, parazyd wrote:
> > On Tue, 03 May 2016, Svante Signell wrote:
> >
> > >
> > > On Tue, 2016-05-03 at 16:32 -0400, Steve Litt wrote:
> > > >
> > > > On Tue, 3 May 2016 10:06:07 -0400 (EDT)
> > > >
> > > > Because Op
On Tue, 2016-05-03 at 23:05 +0200, parazyd wrote:
> On Tue, 03 May 2016, Svante Signell wrote:
>
> >
> > On Tue, 2016-05-03 at 16:32 -0400, Steve Litt wrote:
> > >
> > > On Tue, 3 May 2016 10:06:07 -0400 (EDT)
> > >
> > > Because OpenRC has seen fit to intermix their init scripts
> > > with sy
On Tue, 03 May 2016, Svante Signell wrote:
> On Tue, 2016-05-03 at 16:32 -0400, Steve Litt wrote:
> > On Tue, 3 May 2016 10:06:07 -0400 (EDT)
> >
> > Because OpenRC has seen fit to intermix their init scripts
> > with sysvinit's in /etc/init.d, I'd suggest that any files needed by
> > OpenRC be k
On Tue, 2016-05-03 at 16:32 -0400, Steve Litt wrote:
> On Tue, 3 May 2016 10:06:07 -0400 (EDT)
>
> Because OpenRC has seen fit to intermix their init scripts
> with sysvinit's in /etc/init.d, I'd suggest that any files needed by
> OpenRC be kept somewhere besides /etc/init.d.
>
Hi Steve,
We had
On Tue, 03 May 2016, Steve Litt wrote:
> On Tue, 3 May 2016 10:06:07 -0400 (EDT)
> Rob Owens wrote:
>
>
> > I agree with putting each init in its own directory, but sysvinit
> > should not own /etc/init.d. sysvinit stuff should go in /etc/sysvinit
> > and by default /etc/init.d should be a lin
On Tue, 3 May 2016 10:06:07 -0400 (EDT)
Rob Owens wrote:
> I agree with putting each init in its own directory, but sysvinit
> should not own /etc/init.d. sysvinit stuff should go in /etc/sysvinit
> and by default /etc/init.d should be a link to /etc/sysvinit/init.d.
> The reason is that other
Steven W. Scott wrote:
> Wow. Funny that, my view is:
> Windows: Gaming
> Linux: everything else
I am kind of a "hardcore" gamer,
nowadays especially in Sauerbraten
and Urban Terror, back then in RedEclipse,
I actually think that the situation with
games is good.
Count here 0 A.D., Battle for
On Tue, May 03, 2016 at 02:16:55PM -0400, Steve Litt wrote:
> On Tue, 3 May 2016 13:00:39 +0100
> KatolaZ wrote:
>
> > On Tue, May 03, 2016 at 06:32:41AM -0500, Jim Murphy wrote:
> >
> > [cut]
> >
> > >
> > > I know this is in the very early stages and where things go is
> > > still open to di
> Windows? Lol!
>
> SWS
> On May 3, 2016 5:05 AM, "Go Linux" wrote:
>
>> On Tue, 5/3/16, Mitt Green wrote:
>>
>> Subject: Re: [DNG] OpenRC and Devuan
>> To: dng@lists.dyne.org
>> Date: Tuesday, May 3, 2016, 1:51 AM
>>
>> >>
5/3/16, Mitt Green wrote:
>
> Subject: Re: [DNG] OpenRC and Devuan
> To: dng@lists.dyne.org
> Date: Tuesday, May 3, 2016, 1:51 AM
>
> >> The current init system is old. Ancient.
> >> We should all agree on it. Devuan is looking
> >> for a new init system t
On Tue, 3 May 2016 13:00:39 +0100
KatolaZ wrote:
> On Tue, May 03, 2016 at 06:32:41AM -0500, Jim Murphy wrote:
>
> [cut]
>
> >
> > I know this is in the very early stages and where things go is
> > still open to discussion, but consider this.
> >
> > UNIX and lookalikes have been able to boot
On Tue, 3 May 2016 12:18:13 +0100
KatolaZ wrote:
> Ideally, switching between init systems (e.g., reverting back to an
> init system which is known to work) should be achievable from a
> single-user root shell spawned as an emergency "init", using only a
> few executables in /bin and /sbin. Anyt
I assume "penetration testing", and seems like a shortsighted view.
On Tue, May 3, 2016 at 1:57 PM Steve Litt wrote:
> On Tue, 3 May 2016 09:05:03 + (UTC)
> Go Linux wrote:
>
>
> >
> >
> > Linux = Pen testing
> > Windows = everything else
>
> What is pen testing? Am
On Tue, 3 May 2016 09:05:03 + (UTC)
Go Linux wrote:
>
>
> Linux = Pen testing
> Windows = everything else
What is pen testing? Am I out of touch, or is this guy making up words?
SteveT
Steve Litt
April 2016 featured book: Rapid Learning for the 21st Century
http
On Tue, 3 May 2016 11:24:01 +0200
Didier Kryn wrote:
> Le 03/05/2016 08:51, Mitt Green a écrit :
> >> The current init system is old. Ancient.
> >> We should all agree on it. Devuan is looking
> >> for a new init system that is not systemd and my
> >> personal choice for this task from now on is
On Tue, May 03, 2016 at 07:31:35PM +0200, parazyd wrote:
> On Tue, 03 May 2016, Rob Owens wrote:
>
> > - Original Message -
> > > From: "parazyd"
> >
> > > On Tue, 03 May 2016, Rob Owens wrote:
> > >
> > >> - Original Message -
> > >> > From: "KatolaZ"
> > >>
> > >> > But do w
On Tue, 3 May 2016 09:59:40 +0100
KatolaZ wrote:
> On Tue, May 03, 2016 at 08:50:20PM +1200, Daniel Reurich wrote:
>
> [cut]
>
> >
> > This can all be handled in each package with the package triggers
> > enabled easily with a debhelper script similar to dh-systemd which
> > makes it easy to d
On Tue, 03 May 2016, Rob Owens wrote:
> - Original Message -
> > From: "parazyd"
>
> > On Tue, 03 May 2016, Rob Owens wrote:
> >
> >> - Original Message -
> >> > From: "KatolaZ"
> >>
> >> > But do we really need all that complication? Couldn't we just leave
> >> > the initscri
On Mon, 2 May 2016 22:15:44 -1000
Joel Roth wrote:
> The problem with supporting multiple init systems is that
> there is an init script for each service that has to be
> ported or rewritten.
>
> Launching Devuan while maintaining the sysvinit status quo
> has already stressed the pool of volu
On Tue, 3 May 2016 09:12:26 +0200
parazyd wrote:
> On Mon, 02 May 2016, Hendrik Boom wrote:
>
> > Is there a summary of some sort explaining the various init
> > systems, how they're put together, how they work, and especially
> > the salient points on which they differ?
>
> Perhaps this as a
- Original Message -
> From: "parazyd"
> On Tue, 03 May 2016, Rob Owens wrote:
>
>> - Original Message -
>> > From: "KatolaZ"
>>
>> > But do we really need all that complication? Couldn't we just leave
>> > the initscript of each init system in a different directory and *tell
>
Assuming Piotr means "sysvinit" when he says "init", I agree 100%.
Unless you're a Debian Dev, Lennart Poettering, or a Red Hat
stockholder, there's no rush to move away from sysvinit, which has been
serving us very well for what, three decades?
On Tue, 3 May 2016 08:41:37 +0200
poitr pogo wrot
On Tue, May 03, 2016 at 05:19:19PM +0200, parazyd wrote:
[cut]
>
> This is unnecessary. In OpenRC you can easily specify $SYSCONFDIR and
> set it to /etc/openrc. Then all will be found inside, and the system
> will already know what to do, without symlinking.
>
Great. It would b ideal if all t
On Tue, 03 May 2016, Rob Owens wrote:
> - Original Message -
> > From: "KatolaZ"
>
> > But do we really need all that complication? Couldn't we just leave
> > the initscript of each init system in a different directory and *tell
> > the init system* where they are to be found? This will
On Tue, 2016-05-03 at 10:06 -0400, Rob Owens wrote:
> - Original Message -
> >
> > From: "KatolaZ"
> >
> > But do we really need all that complication? Couldn't we just leave
> > the initscript of each init system in a different directory and *tell
> > the init system* where they are to
parazyd writes:
> The current init system is old. Ancient. We should all agree on it.
The current init system is younger than me. Despite I'm 43 (and will be
44 in a few months), people still want to see a proof of me being
already 18 with annoying regularity (although the frequency has
decreased
- Original Message -
> From: "KatolaZ"
> But do we really need all that complication? Couldn't we just leave
> the initscript of each init system in a different directory and *tell
> the init system* where they are to be found? This will allow a much
> easier coexistence of different conf
On 03/05/16 21:43, KatolaZ wrote:
> On Tue, May 03, 2016 at 09:24:42PM +1200, Daniel Reurich wrote:
>
> [cut]
>
>>
>> Absolutely, but for the average user, having /etc/init.d and
>> /etc/openrc and /etc/wtf all there when using sysvinit (and not
>> changing between init systems) is only going
On Tue, 2016-05-03 at 12:44 +, hellekin wrote:
> On 05/03/2016 12:00 PM, KatolaZ wrote:
> >
> >
> > I definitely agree with you Jim, and this is certainly one aspect to
> > be taken into account seriously. We should strive to allow the maximum
> > flexibility in choosing an init system, ensur
On 05/03/2016 12:00 PM, KatolaZ wrote:
>
> I definitely agree with you Jim, and this is certainly one aspect to
> be taken into account seriously. We should strive to allow the maximum
> flexibility in choosing an init system, ensuring that the set of
> constraints remains as small as possible.
>
IMHO i would expect package init scripts for default init system to be part
of a package (binary,base, etc) and scripts for alternate systems to be in
separate package(s).
Of course all residing in single src package maintained by the devuan
package maintainer.
Someone who decides to use alternat
On Tue, May 03, 2016 at 06:32:41AM -0500, Jim Murphy wrote:
[cut]
>
> I know this is in the very early stages and where things go is
> still open to discussion, but consider this.
>
> UNIX and lookalikes have been able to boot into single user mode
> with a small root filesystem without the nee
On Tue, May 3, 2016 at 4:43 AM, KatolaZ wrote:
--- cut ---
> Why we don't just ship the init scripts for each system with the
> corresponding service, install them "somewhere else" (e.g.,
> /var/cache/sysvinit, /var/cache/openrc, /var/cache/wtf, as has been
> already suggested by others) and the
On Tue, May 03, 2016 at 12:18:37PM +0200, parazyd wrote:
> On Tue, 03 May 2016, KatolaZ wrote:
>
[cut]
> > Why we don't just ship the init scripts for each system with the
> > corresponding service, install them "somewhere else" (e.g.,
> > /var/cache/sysvinit, /var/cache/openrc, /var/cache/wtf,
On Tue, 03 May 2016, KatolaZ wrote:
> > The bonus is that each init system can be implemented independently and
> > the service packages have support built-in as people wanting their fav
> > init system get it added in to the package. This will in most cases be
> > a small patch adding the necess
On Tue, May 03, 2016 at 09:24:42PM +1200, Daniel Reurich wrote:
[cut]
>
> Absolutely, but for the average user, having /etc/init.d and /etc/openrc
> and /etc/wtf all there when using sysvinit (and not changing between
> init systems) is only going to lead to confusion. Being able to have
> them
On 03/05/16 17:24, Didier Kryn wrote:
Le 03/05/2016 08:51, Mitt Green a écrit :
The current init system is old. Ancient.
We should all agree on it. Devuan is looking
for a new init system that is not systemd and my
personal choice for this task from now on is
Gentoo's OpenRC.
Unix is old. Anc
On 03/05/16 20:59, KatolaZ wrote:
> On Tue, May 03, 2016 at 08:50:20PM +1200, Daniel Reurich wrote:
>
> [cut]
>
>>
>> This can all be handled in each package with the package triggers
>> enabled easily with a debhelper script similar to dh-systemd which makes
>> it easy to deploy init scripts/uni
Le 03/05/2016 08:51, Mitt Green a écrit :
The current init system is old. Ancient.
We should all agree on it. Devuan is looking
for a new init system that is not systemd and my
personal choice for this task from now on is
Gentoo's OpenRC.
Unix is old. Ancient. We should all agree on it.
Devuan
On Tue, 5/3/16, Mitt Green wrote:
Subject: Re: [DNG] OpenRC and Devuan
To: dng@lists.dyne.org
Date: Tuesday, May 3, 2016, 1:51 AM
>> The current init system is old. Ancient.
>> We should all agree on it. Devuan is looking
>> for a new init system that is not systemd and my
On Tue, May 03, 2016 at 08:50:20PM +1200, Daniel Reurich wrote:
[cut]
>
> This can all be handled in each package with the package triggers
> enabled easily with a debhelper script similar to dh-systemd which makes
> it easy to deploy init scripts/unit files/runscripts etc in their own
> namespa
On 03/05/16 20:15, Joel Roth wrote:
> Steve Litt wrote:
>> On Mon, 2 May 2016 21:05:18 -0400
>> Hendrik Boom wrote:
>>
>>> Is there a summary of some sort explaining the various init systems,
>>> how they're put together, how they work, and especially the salient
>>> points on which they differ?
On Tue, 03 May 2016, Simon Hobson wrote:
> Jaromil wrote:
>
> >> Instead of an openRC effort at this point, I'd rather see a hook
> >> for apt-get / aptitude / etc, to move all files specific to init
> >> systems not being used to their own file hierarchies, eg.
> >>
> >> /var/cache/init-syste
to all, very important, perhaps to be set on the homepage:
On Tue, 03 May 2016, poitr pogo wrote:
> I vote for init to be default for at least few years.
> Devuan might consider switching to something else few years after
> wheezy lts will be dead.
>
> Meantime, all other init systems should be
Jaromil wrote:
>> Instead of an openRC effort at this point, I'd rather see a hook
>> for apt-get / aptitude / etc, to move all files specific to init
>> systems not being used to their own file hierarchies, eg.
>>
>> /var/cache/init-systems
>>/sysvinit
>> /etc
>> /lib
>> /us
On Mon, May 02, 2016 at 10:15:44PM -1000, Joel Roth wrote:
[cut]
>
> The problem with supporting multiple init systems is that
> there is an init script for each service that has to be
> ported or rewritten.
>
> Launching Devuan while maintaining the sysvinit status quo
> has already stressed
On Mon, 02 May 2016, Boruch Baum wrote:
> Instead of an openRC effort at this point, I'd rather see a hook
> for apt-get / aptitude / etc, to move all files specific to init
> systems not being used to their own file hierarchies, eg.
>
> /var/cache/init-systems
> /sysvinit
> /etc
>
Steve Litt wrote:
> On Mon, 2 May 2016 21:05:18 -0400
> Hendrik Boom wrote:
>
> > Is there a summary of some sort explaining the various init systems,
> > how they're put together, how they work, and especially the salient
> > points on which they differ?
>
> I've tried. See
> http://troublesh
On Tue, 03 May 2016, poitr pogo wrote:
> I vote for init to be default for at least few years.
> Devuan might consider switching to something else few years after
> wheezy lts will be dead.
>
> Meantime, all other init systems should be optional in Devuan.
>
Then there is just enough time to ma
On Tue, 03 May 2016, Brad Campbell wrote:
> On 03/05/16 07:19, parazyd wrote:
> >The current init system is old. Ancient. We should all agree on it.
>
> >Devuan is looking for a new init system that is not systemd and my
> >personal choice for this task from now on is Gentoo's OpenRC.
>
> Withou
On Mon, 02 May 2016, Hendrik Boom wrote:
> Is there a summary of some sort explaining the various init systems,
> how they're put together, how they work, and especially the salient
> points on which they differ?
Perhaps this as a short intro:
https://wiki.gentoo.org/wiki/Comparison_of_init_sys
Mitt Green wrote:
>> The current init system is old. Ancient.
>> We should all agree on it. Devuan is looking
>> for a new init system that is not systemd and my
>> personal choice for this task from now on is
>> Gentoo's OpenRC.
>
> Unix is old. Ancient. We should all agree on it.
> Devuan is
> The current init system is old. Ancient.
> We should all agree on it. Devuan is looking
> for a new init system that is not systemd and my
> personal choice for this task from now on is
> Gentoo's OpenRC.
Unix is old. Ancient. We should all agree on it.
Devuan is looking for a new base system t
I vote for init to be default for at least few years.
Devuan might consider switching to something else few years after
wheezy lts will be dead.
Meantime, all other init systems should be optional in Devuan.
--
Regards
Piotr
On 5/3/16, Steve Litt wrote:
> On Mon, 2 May 2016 21:05:18 -0400
> Hen
On Mon, 2 May 2016 21:05:18 -0400
Hendrik Boom wrote:
> Is there a summary of some sort explaining the various init systems,
> how they're put together, how they work, and especially the salient
> points on which they differ?
I've tried. See
http://troubleshooters.com/linux/init/features_and_b
On Tue, 3 May 2016 01:19:40 +0200
parazyd wrote:
> The current init system is old. Ancient. We should all agree on it.
> Devuan is looking for a new init system that is not systemd and my
> personal choice for this task from now on is Gentoo's OpenRC.
I'd love to see OpenRC as an option. I'd hat
Original Message
From: Daniel Reurich
Sent: 3 May 2016 1:54:36 PM NZST
To: parazyd
Subject: Re: [DNG] OpenRC and Devuan
On 3 May 2016 11:19:40 AM NZST, parazyd wrote:
>The current init system is old. Ancient. We should all agree on it.
Sure but it just works.
>
On 03/05/16 07:19, parazyd wrote:
The current init system is old. Ancient. We should all agree on it.
Devuan is looking for a new init system that is not systemd and my
personal choice for this task from now on is Gentoo's OpenRC.
Without getting specific, I just want to flag this as the sor
On 2016-05-03 01:19, parazyd wrote:
> The current init system is old. Ancient. We should all agree on it.
> Devuan is looking for a new init system that is not systemd and my
> personal choice for this task from now on is Gentoo's OpenRC.
> ...
I use a version of Manjaro linux built for openRC, and
On Tue, May 03, 2016 at 01:19:40AM +0200, parazyd wrote:
> The current init system is old. Ancient. We should all agree on it.
> Devuan is looking for a new init system that is not systemd and my
> personal choice for this task from now on is Gentoo's OpenRC.
>
> In Debian, years ago, effort was m
The current init system is old. Ancient. We should all agree on it.
Devuan is looking for a new init system that is not systemd and my
personal choice for this task from now on is Gentoo's OpenRC.
In Debian, years ago, effort was made to get OpenRC running. Utter fail.
The developers kept the old
90 matches
Mail list logo
