Re: [DNG] OpenRC and Devuan

[Didier Kryn]

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 have to do '/etc/openrc/myservice start'.  Not a
really big deal, but I think it's undesirable to make Devuan's openrc
procedures different (especially when it could be addressed with a
simple symlink).

 Normally the admin invokes the service command,

 sudo service ssh restart
 sudo service nginx status

 etc.

 service could probably be modified to talk to the init system in
charge.

Normally *this* admin never uses the service command because:
I always use it. With some experience you know the service names as 
well as the basic Unix command names.


1) it is not available on all distros or may not be installed


Talking of Debian/Devuan

2) tab completion doesn't always work with the service command (depending
on the distro, I suppose)
3) tab completion always works when you specify the path to the script
and you are running a bash shell

Is the service called 'smb' or 'samba'?  Is it 'network' or 'networking'?
That's why tab completion is important to me.  I'm surprised that I seem
to be the only one who thinks this way.


Bash tab completion does work - I agree it's rather sophisticated.

Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[poitr pogo]

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
also cannot coexist.

so openrc is not an init subsystem on its own.

deamontools  are IMHO helpers for broken software like java application
which cannot daemonize itself under unix becaouse of java desing. trying to
convince people that writing unix daemons the old way is badthing(tm).

maybe i should go back to sls.
--
regards
piotr
04-05-2016 18:49, "Steve Litt"  napisał(a):

> 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.  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 init systems may
> > >> expect to own /etc/init.d. For instance, openrc puts all its
> > >> scripts in /etc/init.d (at least on Funtoo it does).
> > >
> > > I don't remember any other init wanting to use /etc/init.d, EXCEPT
> > > OpenRC, or EXCEPT when they want to use the sysvinit init scripts,
> > > and the only one I know that wants to do that is systemd.
> > >
> > > I wouldn't change sysvinit's expected files one little bit. Everyone
> > > assumes that /etc/init.d belongs exclusively to sysvinit. Any
> > > change to sysvinit would require lots of testing, and who needs
> > > that headache?
>
> > Then you would be designing under the assumption that sysvinit is the
> > "one true way"
>
> Not "one true way", but "it's what we have right now, let's not mess
> with it.
>
> > and that all others must be modified to work around
> > sysvinit -- an init system that you/we are actively attempting to make
> > obsolete (eventually) by way of providing all these alternatives.
>
> The other inits should have had the good sense not to entangle
> themselves with sysvinit, and in fact most of them did have that good
> sense, so for them this is a moot point.
>
> At this point I'm not sure that *any* init system other than sysvinit
> puts its daemon starting code/config under /etc/init.d. But if there is
> such an init system putting its stuff under/etc/init.d, that's some
> serious hubris. They could have taken their own namespace, but no,
> they polluted the namespace used by sysvinit for 30 years. If there is
> such an init system, moving their script/config storage is actually
> correcting a problem caused by the init system.
>
> SteveT
>
> Steve Litt
> April 2016 featured book: Rapid Learning for the 21st Century
> http://www.troubleshooters.com/rl21
> ___
> 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] OpenRC and Devuan

[Steve Litt]

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.  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 init systems may
> >> expect to own /etc/init.d. For instance, openrc puts all its
> >> scripts in /etc/init.d (at least on Funtoo it does).  
> > 
> > I don't remember any other init wanting to use /etc/init.d, EXCEPT
> > OpenRC, or EXCEPT when they want to use the sysvinit init scripts,
> > and the only one I know that wants to do that is systemd.
> > 
> > I wouldn't change sysvinit's expected files one little bit. Everyone
> > assumes that /etc/init.d belongs exclusively to sysvinit. Any
> > change to sysvinit would require lots of testing, and who needs
> > that headache? 

> Then you would be designing under the assumption that sysvinit is the
> "one true way" 

Not "one true way", but "it's what we have right now, let's not mess
with it.

> and that all others must be modified to work around
> sysvinit -- an init system that you/we are actively attempting to make
> obsolete (eventually) by way of providing all these alternatives.

The other inits should have had the good sense not to entangle
themselves with sysvinit, and in fact most of them did have that good
sense, so for them this is a moot point.

At this point I'm not sure that *any* init system other than sysvinit
puts its daemon starting code/config under /etc/init.d. But if there is
such an init system putting its stuff under/etc/init.d, that's some
serious hubris. They could have taken their own namespace, but no,
they polluted the namespace used by sysvinit for 30 years. If there is
such an init system, moving their script/config storage is actually
correcting a problem caused by the init system.

SteveT

Steve Litt 
April 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[poitr pogo]

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 running on my box. I would not wait for Devuan to get
something with sysvinit.

So if I'm stick to sysvinit why I am to use 'service'? Why learn
another wrapper name which does one thing more if I can always do

env /etc/init.d/blabla start

If I want to have clean environment when starting this script.

But I cannot imagine why should I even use 'env' command (in ideal
world). The init script should use it if it is important that the
environment is cleaned up before starting the application daemon ( or
service if you want to call it this way). This is responsibility of
application maintainer to provide 'idiot proof' starting script.  The
assumption that 'service' command will prepare environment is IMHO  a
mistake, cause the init script _can_ be executed directly as it was
done for a long time, before 'service' command was introduced.

Yes, I think it was bad design decision to make 'service' command to
cleanup environment, not leaving this task to  init script, because of
legacy of /etc/init.d , and because the init.d scripts  can be
executed directly anyway.

If 'service' command  was running scripts from other
folder/schema/subsystem, but not from well known /etc/init.d, than I
would say I should obey the rules of the new command, once decided i
want to use it.

So, please make the system suit your needs, but do not assume what are mine. :)

--
regards
piotr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Stephan Seitz]

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 not be installed


It is available in SLES11 and Debian (since 6?). Which distro doesn’t 
have service?
Besides, as far as I know the service command is independant from the 
init system, so it works with systemd or sysvinit.



2) tab completion doesn't always work with the service command (depending
  on the distro, I suppose)
3) tab completion always works when you specify the path to the script
  and you are running a bash shell


These are valid points. SLES doesn’t have bash completion in 11. IIRC tab 
completion with service works in SLES 12 which uses systemd.
In Debian or debian based distros you have to install bash-completion and 
activate it in /etc/bash.bashrc.



That's why tab completion is important to me.  I'm surprised that I seem
to be the only one who thinks this way.


No, but with bash-completion this works with service in Debian as well.

Shade and sweet water!

Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Rob Owens]

- 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 a link to /etc/sysvinit/init.d.
>> The reason is that other init systems may expect to own /etc/init.d.
>> For instance, openrc puts all its scripts in /etc/init.d (at least on
>> Funtoo it does).
> 
> I don't remember any other init wanting to use /etc/init.d, EXCEPT
> OpenRC, or EXCEPT when they want to use the sysvinit init scripts, and
> the only one I know that wants to do that is systemd.
> 
> I wouldn't change sysvinit's expected files one little bit. Everyone
> assumes that /etc/init.d belongs exclusively to sysvinit. Any change to
> sysvinit would require lots of testing, and who needs that headache?
> 
Then you would be designing under the assumption that sysvinit is the
"one true way" and that all others must be modified to work around
sysvinit -- an init system that you/we are actively attempting to make
obsolete (eventually) by way of providing all these alternatives.  This 
doesn't make a lick of sense.

>> Even though sysvinit is our default init system these days, we should
>> not design Devuan such that it is difficult to change that in the
>> future.  So put sysvinit stuff in its own directory just like all the
>> other inits.
> 
> If you leave sysvinit's directories exactly as they exist now,
> switching back and forth between sysvinit and runit is trivial. Same is
> true of s6 and Epoch.
> 
It is also trivial to do with a symlink.

> 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.
> 
I have only used openrc on Funtoo, but there is no intermixing with 
sysvinit there.  It is exclusively openrc in /etc/init.d.  Are you using
a distro where /etc/init.d contains both openrc scripts and sysvinit 
scripts?

-Rob
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Rainer Weikusat]

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 simplicity.

The main attraction of the sysvinit-based system is its simpliciy: While
init has a few features it could do without (eg, process management), it
mostly just invokes (configurable) external programs with certain
arguments in response to system state change requests. By itself, that's
flexible enough to implement anything on top of it (including the
'historically grown' init.d script thicket).
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Rob Owens]

- 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 start'.  Not a
>> really big deal, but I think it's undesirable to make Devuan's openrc
>> procedures different (especially when it could be addressed with a
>> simple symlink).
> Normally the admin invokes the service command,
> 
> sudo service ssh restart
> sudo service nginx status
> 
> etc.
> 
> service could probably be modified to talk to the init system in
> charge.

Normally *this* admin never uses the service command because:

1) it is not available on all distros or may not be installed
2) tab completion doesn't always work with the service command (depending
   on the distro, I suppose)
3) tab completion always works when you specify the path to the script
   and you are running a bash shell

Is the service called 'smb' or 'samba'?  Is it 'network' or 'networking'?
That's why tab completion is important to me.  I'm surprised that I seem
to be the only one who thinks this way.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan (and Windows)

[Hendrik Boom]

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 routinely used because they make speech and writing less 
> verbose. I did my apprenticeship in an engineering (plenty of acronyms there) 
> firm that was also a supplier to the UK's navy - the defence field is a sea 
> of acronyms* :-)
> 
> But back to our world, "pen testing" is a common term. A few seconds with 
> ${preferred_search_engine} would come up with a definition.

The trouble is with abbreviations that are common words in their own 
right, with the result that people not knowing it's an abbreviation 
will get a quite different meaning, and not know they've 
misunderstood.

-- hendrik
.
> 
> * I was involved in software, and one day for a bit of light amusement 
> decided to fully expand the acronym of something I was working on. Thing is, 
> some of the letters in the acronym were in fact initial of other acronyms, 
> and by the time I'd fully expended all the levels I think a 6 letter acronym 
> became a whole paragraph !
> 
> ___
> 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] OpenRC and Devuan

[Noel Torres]

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 be
incorporated into the packages after they've been proven correct.


Better expressed that way :)


What I was trying to do is shelter the poor maintainers from having a
brand new job thrown at them, and having to learn about every init
system out there (conspicuously excluding systemd).


Agreed


At this point let me say this: It's way premature to speak of any
change in the default init system. What I'm personally speaking of is
alternate inits you can lay down on Devuan, for that minority of people
who care what their init system is (as long as it's not an entangled
monolith).


Yes, but Devuan packagers can (almost blindly) copy scripts from wiki  
to packages, slowly, to allow that happen in a proper way.


[some things about how to package, with which I don't agree but that  
aren't priority]


Anyway, none of this is top priority: We're doing just fine with
sysvinit, and the people who *really* want to alt-init already know how
to do so, with or without Devuan packages to help them. Let those
people do the pioneering work.


Agreed

Noel
er Envite


bin1LIy6CVg5O.bin
Description: Clave PGP pública


pgp_bAm5Q0Yuz.pgp
Description: Firma digital PGP
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Steve Litt]

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 rewritten.  
> [...]
> > It's a documentation task. If we had a wiki upon which users could
> > write their successful init scripts/run scripts/EpochConfigs etc,
> > this task would be removed from upstream developers, who never
> > should have had this responsibility in the first place.  
> 
> We can use a wiki for collecting this, but the scripts should be in  
> packages, and should be installed, so maybe this wiki might help  
> creating bug reports for the maintainers to just add these files to  
> their packages.
> 
> It is not conceivable that a user that wants a
> different-than-default init system must copy scripts from the wiki
> while the machine can not yet access the wiki as it is still being
> installed!

Oh yeah, that issue :-)

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 be
incorporated into the packages after they've been proven correct.

What I was trying to do is shelter the poor maintainers from having a
brand new job thrown at them, and having to learn about every init
system out there (conspicuously excluding systemd).

At this point let me say this: It's way premature to speak of any
change in the default init system. What I'm personally speaking of is
alternate inits you can lay down on Devuan, for that minority of people
who care what their init system is (as long as it's not an entangled
monolith). 

Let's talk about a person who is partial enough to a specific init
system to alt-init Devuan. Their system installation is sysvinit, and
then later they install OpenRC or runit or s6 or Epoch. Let's take
runit as an example, as it's the only one I know a lot about. They
install the runit package, which comes with run scripts for tty1-tty6,
sshd, wpa_supplicant, dhcpcd, ntpd, httpd. Then, as they need software
without included run scripts, they write the run scripts. Because
they're enthusiasts of that init system, they probably do it well. Then
they put the run scripts on the wiki, others test them, and over time
they become tested enough to go in the runit package. Nobody has an
undue amount of work, and nobody's working on something they don't give
a flying flamingo about. 

Over time each init will end up with init scripts/run scripts,
EpochConfs for lots and lots of daemons. Maybe at some point the
scripts for a given init system will be complete enough that they can
be transferred to the daemon's package, but I don't see a need to rush
that.

Anyway, none of this is top priority: We're doing just fine with
sysvinit, and the people who *really* want to alt-init already know how
to do so, with or without Devuan packages to help them. Let those
people do the pioneering work.

SteveT

Steve Litt 
April 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Joel Roth]

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 common use case.

> The main issue with switching from sysvinit to something else is just
> finding someone willing to do the work.

As I wrote before, hundreds of scripts could be involved.
Daniel Reurich observed that bug reports could be filed
with each package, and then resolved as scripts are added.

The upstream software developer may not care about multiple
init systems, so the burden would be on the Devuan package
developer to support them. It would be great if some
automated tools could do this, but programmatically parsing
and transforming shell scripts is a task that will be
fraught with complexity. Perhaps some examples to follow for
each init system will be enough for packagers,
or init system advocate teams to write the necessary
scripts.

cheers,

-- 
Joel Roth
  

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan (and Windows)

[Simon Hobson]

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 apprenticeship in an engineering (plenty of acronyms there) 
firm that was also a supplier to the UK's navy - the defence field is a sea of 
acronyms* :-)

But back to our world, "pen testing" is a common term. A few seconds with 
${preferred_search_engine} would come up with a definition.

* I was involved in software, and one day for a bit of light amusement decided 
to fully expand the acronym of something I was working on. Thing is, some of 
the letters in the acronym were in fact initial of other acronyms, and by the 
time I'd fully expended all the levels I think a 6 letter acronym became a 
whole paragraph !

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Noel Torres]

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 their successful init scripts/run scripts/EpochConfigs etc, this
task would be removed from upstream developers, who never should have
had this responsibility in the first place.


We can use a wiki for collecting this, but the scripts should be in  
packages, and should be installed, so maybe this wiki might help  
creating bug reports for the maintainers to just add these files to  
their packages.


It is not conceivable that a user that wants a different-than-default  
init system must copy scripts from the wiki while the machine can not  
yet access the wiki as it is still being installed!


Regards

Noel
er Envite


binVWvKQgNw1c.bin
Description: Clave PGP pública


pgpWRVmrSNERQ.pgp
Description: Firma digital PGP
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[KatolaZ]

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 analogous to /bin and /usr/sbin but they contain
> programs for administrative purposes such as adduser which require privileges
> and are not needed by user logins or might not be expected for ordinary user
> access.
> 
> On some distros ifconfig is in one of these and isn't visible to the user, 
> even
> though it might be useful.
> 

This is just a mishap. You might include /sbin in your PATH and
ifconfig automagically becomes available to you. Not all the
executables in /sbin and /usr/sbin require root privilege to run...

PDSCE

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] OpenRC and Devuan

[Noel Torres]

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 call
these use-cases. By placing the init systems in /var we again remove
another choice for admins/users.  If we are about choice, then /var
may not be the best place to put inits.

[...]

For sure my installations have /var separated, to avoid  
/var/log/syslog growing enough to fill / and thus causing the system  
to fail.


The only things I consider to be on root filesystem are:
/ (obviously)
/etc
/lib
/bin
/sbin

Not even /boot, which I use to have in a separated partition  
independently in each hard disk, while all the others are in a  
replicated RAID among all disks.


From this, I derive that init system files should be in /etc  
(configuration) and /sbin (executables). For the sake of keeping  
things as they are, shell scripts could continue in /etc as in  
/etc/init.d so I strongly raise hand for /etc/orc or /etc/wtf-is .


Regards

Noel
er Envite


bin7zwZdCxPow.bin
Description: Clave PGP pública


pgpfq2MMHqQCU.pgp
Description: Firma digital PGP
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[emninger]

Am Tue, 03 May 2016 08:27:05 +
schrieb dng-requ...@lists.dyne.org:

> From: parazyd <para...@dyne.org>
> To: Hendrik Boom <hend...@topoi.pooq.com>
> Cc: dng@lists.dyne.org
> Subject: Re: [DNG] OpenRC and Devuan
> Message-ID: <20160503071226.GA10101@hansolo>
> Content-Type: text/plain; charset="utf-8"
> 
> 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_systems

http://www.troubleshooters.com/linux/init/manjaro_experiments.htm
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Robert Storey]

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
disdain systemd is because it's a mass of incomprehensible spaghetti code
with dependencies up the ying-yang, and all that entails (ie a huge
potential attack surface, dependency on Red Hat's "good will" for
maintenance, etc).

The main issue with switching from sysvinit to something else is just
finding someone willing to do the work. I don't feel very qualified myself.
I'm not sure if SteveL was volunteering or suggesting we organize
something, but anyway, the idea of S6, Epoch, Runit or similar simple and
comprehensible init systems appeals to me.

cheers,
Robert
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Peter Olson]

> 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 purposes such as adduser which require privileges
and are not needed by user logins or might not be expected for ordinary user
access.

On some distros ifconfig is in one of these and isn't visible to the user, even
though it might be useful.

Peter Olson
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Joel Roth]

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 either.
> > > 
> > > init is supposed to be able to read /etc/fstab to find the others.  
> > > That's why /etc has to be on the root filesystem.
> > > 
> > > So it is available for init-time configuration files.  
> > 
> > /etc is the right place for config files, and init scripts
> > have historically lived there. I hope we can agree on at
> > least this part!
> 
> No doubt about it. /etc is the tree where init scripts, run scripts,
> EpochConfig files belong.
> 
> I think the nonobvious thing comes from the daemontools-inspired inits,
> which at a minimum have a /service directory somewhere that contains
> symlinks to the actual service directories. No reason that can't be
> somewhere under /etc. Daemontools, and maybe some other ones, also have
> a /command directory, directly off the root, that houses executables
> specific to themselves. It's possible this odd placement is to
> guarantee they're available the minute the root partition is mounted.

Interesting, I thought /sbin was historically for statically
linked executables needed at boot time, or for system
recovery.
 
> Bizarrely, Runit on Void Linux has a directory at /run/runit that has
> all sorts of oddball symlinks. I believe this is so, if /etc/ is
> mounted read-only, parts of Runit that need to change file conttents
> can still operate. I think this is usually placed at /var/run/runit,
> but on Void it's just /run/runit.
> 
> I did a little runit experimentation during my Manjaro Experiments, and
> have found that Void's runit implementation is much more complex and
> full of chained symlinks than was my Manjaro alt-initted runit.

Well, all of these sources can be patched to suit the
policies of Devuan, if it can be agreed what these policies
are :-)
 
> SteveT
> 
> Steve Litt 
> April 2016 featured book: Rapid Learning for the 21st Century
> http://www.troubleshooters.com/rl21

-- 
Joel Roth
  

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Steve Litt]

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 either.
> > 
> > init is supposed to be able to read /etc/fstab to find the others.  
> > That's why /etc has to be on the root filesystem.
> > 
> > So it is available for init-time configuration files.  
> 
> /etc is the right place for config files, and init scripts
> have historically lived there. I hope we can agree on at
> least this part!

No doubt about it. /etc is the tree where init scripts, run scripts,
EpochConfig files belong.

I think the nonobvious thing comes from the daemontools-inspired inits,
which at a minimum have a /service directory somewhere that contains
symlinks to the actual service directories. No reason that can't be
somewhere under /etc. Daemontools, and maybe some other ones, also have
a /command directory, directly off the root, that houses executables
specific to themselves. It's possible this odd placement is to
guarantee they're available the minute the root partition is mounted.

Bizarrely, Runit on Void Linux has a directory at /run/runit that has
all sorts of oddball symlinks. I believe this is so, if /etc/ is
mounted read-only, parts of Runit that need to change file conttents
can still operate. I think this is usually placed at /var/run/runit,
but on Void it's just /run/runit.

I did a little runit experimentation during my Manjaro Experiments, and
have found that Void's runit implementation is much more complex and
full of chained symlinks than was my Manjaro alt-initted runit.

SteveT

Steve Litt 
April 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan (and Windows)

[Nate Bargmann]

* 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, bikes, and more: http://www.n0nb.us
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Joel Roth]

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 find the others.  
> That's why /etc has to be on the root filesystem.
> 
> So it is available for init-time configuration files.

/etc is the right place for config files, and init scripts
have historically lived there. I hope we can agree on at
least this part!
 
> -- hendrik
> 
> > 
> > Perhaps LSB should add a directory called /mustnotbemountpoint directly
> > off the root, for stuff that must be available immediately upon
> > mounting the root partition for the first time.
> 
> There are already several suuch directories.
> 
> -- hendrik
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

-- 
Joel Roth
  

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Steve Litt]

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
> > OpenRC be kept somewhere besides /etc/init.d.
> >   
> 
> Hi Steve,
> 
> We had a patch where openrc in debian was openrc.postrm and
> openrc.preinst was used to to divert update-rc.d + invoke-rc.d files
> to not conflict with the init- system-helpers scripts: update-rc.d
> and invoke-rc.d, see dpkg-divert. That is the solution used
> by file-rc. Currently systemd, sysvinit-core and openrc use the
> method of cooperating with the scripts update-rc.d and invoke-rc.d in
> the init-system-helpers package. Which is your preferred solution, we
> can go either way.

:-)

Hi Svante,

I don't understand a single word of your preceding paragraph, which
isn't surprising given my lack of knowledge of packaging systems. I
also know very little about OpenRC. So I have no opinion on the choice
you give in the preceding paragraph.

An opinion I *do* have is that for s6, runit and Epoch, the Devuan
package as much as possible mimic the idiomatic way that the program's
developer says to install it. I don't think that will be particularly
hard to do, and in another post I outlined how sysvinit, s6, runit and
Epoch can coexist simply by naming their PID1's sysvinit.pid1, s6.pid1,
runit.pid1 and epoch.pid1, and then switching inits is as simple as
copying one of those .pid1 files to /sbin/init.

SteveT

Steve Litt 
April 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Svante Signell]

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 about replacing the LSB initscripts, one by one in a suitable pace,
starting from the current state (they can be mixed, right?) And of course we
should replace the init-system-helpers package with a init-freedom package, as
pointed out before ;-)

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan (and Windows)

[Steve Litt]

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.

"Pen testing" My Aunt's Hat!

Thanks Stephanie,

SteveT



On Tue, 03 May 2016 18:05:41 +
Stephanie Daugherty  wrote:

> 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 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://www.troubleshooters.com/rl21
> > ___
> > 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] OpenRC and Devuan

[parazyd]

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 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 a patch where openrc in debian was openrc.postrm and openrc.preinst
> > > was
> > > used to to divert update-rc.d + invoke-rc.d files to not conflict with the
> > > init-
> > > system-helpers scripts: update-rc.d and invoke-rc.d, see dpkg-divert. That
> > > is
> > > the solution used by file-rc. Currently systemd, sysvinit-core and openrc
> > > use
> > > the method of cooperating with the scripts update-rc.d and invoke-rc.d in
> > > the
> > > init-system-helpers package. Which is your preferred solution, we can go
> > > either
> > > way.
> > invoke-rc.d and update-rc.d will NOT be used with OpenRc.
> 
> In Debian openrc they are.
> 

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

-- 
~ parazyd
0333 7671 FDE7 5BB6 A85E  C91F B876 CB44 FA1B 0274



pgpb3NgSXd0KV.pgp
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Svante Signell]

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 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 a patch where openrc in debian was openrc.postrm and openrc.preinst
> > was
> > used to to divert update-rc.d + invoke-rc.d files to not conflict with the
> > init-
> > system-helpers scripts: update-rc.d and invoke-rc.d, see dpkg-divert. That
> > is
> > the solution used by file-rc. Currently systemd, sysvinit-core and openrc
> > use
> > the method of cooperating with the scripts update-rc.d and invoke-rc.d in
> > the
> > init-system-helpers package. Which is your preferred solution, we can go
> > either
> > way.
> invoke-rc.d and update-rc.d will NOT be used with OpenRc.

In Debian openrc they are.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[parazyd]

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 kept somewhere besides /etc/init.d.
> > 
> 
> Hi Steve,
> 
> We had a patch where openrc in debian was openrc.postrm and openrc.preinst was
> used to to divert update-rc.d + invoke-rc.d files to not conflict with the 
> init-
> system-helpers scripts: update-rc.d and invoke-rc.d, see dpkg-divert. That is
> the solution used by file-rc. Currently systemd, sysvinit-core and openrc use
> the method of cooperating with the scripts update-rc.d and invoke-rc.d in the
> init-system-helpers package. Which is your preferred solution, we can go 
> either
> way.

invoke-rc.d and update-rc.d will NOT be used with OpenRc.

-- 
~ parazyd
0333 7671 FDE7 5BB6 A85E  C91F B876 CB44 FA1B 0274



pgppiqAXuDHjn.pgp
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Svante Signell]

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 a patch where openrc in debian was openrc.postrm and openrc.preinst was
used to to divert update-rc.d + invoke-rc.d files to not conflict with the init-
system-helpers scripts: update-rc.d and invoke-rc.d, see dpkg-divert. That is
the solution used by file-rc. Currently systemd, sysvinit-core and openrc use
the method of cooperating with the scripts update-rc.d and invoke-rc.d in the
init-system-helpers package. Which is your preferred solution, we can go either
way.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[parazyd]

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 link to /etc/sysvinit/init.d.
> > The reason is that other init systems may expect to own /etc/init.d. 
> > For instance, openrc puts all its scripts in /etc/init.d (at least on 
> > Funtoo it does).
> 
> I don't remember any other init wanting to use /etc/init.d, EXCEPT
> OpenRC, or EXCEPT when they want to use the sysvinit init scripts, and
> the only one I know that wants to do that is systemd. 
> 
> I wouldn't change sysvinit's expected files one little bit. Everyone
> assumes that /etc/init.d belongs exclusively to sysvinit. Any change to
> sysvinit would require lots of testing, and who needs that headache?
> 
> > 
> > Even though sysvinit is our default init system these days, we should
> > not design Devuan such that it is difficult to change that in the
> > future.  So put sysvinit stuff in its own directory just like all the
> > other inits.
> 
> If you leave sysvinit's directories exactly as they exist now,
> switching back and forth between sysvinit and runit is trivial. Same is
> true of s6 and Epoch.
> 
> 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.

The problem with this is Debian itself. They insist on using LSB init
scripts and in my opinion that they are somewhat different than what OpenRC
wants.

(For me at least) openrc initscripts are simpler, and also
for respecting the openrc way(?) I wish to keep it in /etc/openrc. This
way, with or without debhelper scripting OpenRC should work much more
easily. The only thing then is that the package maintainers would have
to include new initscripts in their packages, which might or might not
be cumbersome for them.

sysvinit should and will just stay where it already is. There is really
no point in changing it's current configuration when other alternatives
offer very easy ways to work around it.

-- 
~ parazyd
0333 7671 FDE7 5BB6 A85E  C91F B876 CB44 FA1B 0274



pgpbfnv5FOub3.pgp
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[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 a link to /etc/sysvinit/init.d.
> The reason is that other init systems may expect to own /etc/init.d. 
> For instance, openrc puts all its scripts in /etc/init.d (at least on 
> Funtoo it does).

I don't remember any other init wanting to use /etc/init.d, EXCEPT
OpenRC, or EXCEPT when they want to use the sysvinit init scripts, and
the only one I know that wants to do that is systemd. 

I wouldn't change sysvinit's expected files one little bit. Everyone
assumes that /etc/init.d belongs exclusively to sysvinit. Any change to
sysvinit would require lots of testing, and who needs that headache?

> 
> Even though sysvinit is our default init system these days, we should
> not design Devuan such that it is difficult to change that in the
> future.  So put sysvinit stuff in its own directory just like all the
> other inits.

If you leave sysvinit's directories exactly as they exist now,
switching back and forth between sysvinit and runit is trivial. Same is
true of s6 and Epoch.

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.

SteveT

Steve Litt 
April 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan (and Windows)

[Mitt Green]

‎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 Wesnoth,
Quake(s), OpenArena, AssaultCube,
Speed Dreams and its parent, TORCS.

On Steam Dota 2 and CS 1.6, CS:GO
are available. Probably some other very
popular games too. Some claim
that performance in Linux is better
due to the quality of the drivers.

So, in my opinion:
Windows - I couldn't find FreeDOS/Linux
pre-installed;
Linux - everything;
OS X - I am gay.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Hendrik Boom]

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 discussion, but consider this.
> > > 
> > > 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 call these use-cases. By placing the init systems in /var
> > > we again remove another choice for admins/users.  If we are about
> > > choice, then /var may not be the best place to put inits.
> > > 
> > > Something to consider and discuss, I hope.
> > >   
> > 
> > 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.
> 
> Interesting point. Perhaps that's why Daniel J Bernstein (djb) put
> the /service directory directly off the root. He also put his
> executables in, IIRC, /command directly off the root. I always thought
> he was crazy, but Jim's point brings some sense to what djb did.
> 
> One distro I saw (perhaps Debian) put the /service directory
> under /etc. At the time I thought the packager was psychotic, but Jim's
> point makes me wonder if the real truth is I was a little shortsighted. 

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 find the others.  
That's why /etc has to be on the root filesystem.

So it is available for init-time configuration files.

-- hendrik

> 
> Perhaps LSB should add a directory called /mustnotbemountpoint directly
> off the root, for stuff that must be available immediately upon
> mounting the root partition for the first time.

There are already several suuch directories.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan (and Windows)

[Linux O'Beardly]

Actually, since Valve released a native Steam client for Linux, I've even
abandoned Windows for gaming.  Yes, I'm quite limited to what I can play,
but it has enough titles to keep me busy.

Linux O'Beardly
@LinuxOBeardly
http://o.beard.ly
linux.obear...@gmail.com

On Tue, May 3, 2016 at 3:00 PM, Steven W. Scott <codekra...@gmail.com>
wrote:

> Wow. Funny that, my view is:
>
> Windows: Gaming
> Linux: everything else
>
> Linux for pentest, hell yes, mostly because it lends itself extremely well
> to quickly implementing a prototype and automating it in a reliable manner.
> Windows scheduler is a joke, Windows development is a masochist's dream.
> Poweshell is an indicator that MS has only recently come to the
> understanding that automation is more than just a room full of low-skilled
> operators reacting to pop-up dialogs. Where does the cloud live, on
> Windows? Lol!
>
> SWS
> On May 3, 2016 5:05 AM, "Go Linux" <goli...@yahoo.com> wrote:
>
>> On Tue, 5/3/16, Mitt Green <mitt_gr...@riseup.net> 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
>> >> 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 that
>> > is not Unix and my personal choice for this
>> > task from now is Microsoft's Windows.
>> >
>>
>> 
>>
>> Mitt's response reminded me of a post that was made to the forum earlier
>> today in the topic "Windows explained to Devuan supporters" at
>> https://talk.devuan.org/t/windows-explained-to-devuan-supporters/139/10 :
>>
>> 
>>
>> Linux = Pen testing
>> Windows = everything else
>>
>> There are no advantages in using any linux distros other than pen testing
>> and that it can be installed on a USB key(and I think that's very cool).
>> Even Software Defined Radio (SDR) with maybe the exception of GMS
>> intercepting and decoding, has more development under Windows. Night and
>> day. One works extremely well on all PCs and permits the User to actually
>> be productive and do things. The other one is a clunky Windows wannabe with
>> a couple of specialized advantages that most don't care about. So..
>>
>> YES
>> I like its functionality, its popularity(more software dev and hardware
>> support), its clarity and ease of use.
>> The only thing wrong with my Windows is its lack of pen testing
>> capability, and that is why I'm here (KL2 using Debian8 and now looking for
>> an alternative with Dev-one as a base), otherwise I would >> n e v e r <<
>> bother with anything linux, life is too short
>>
>> 
>>
>> I'll spare you my personal thoughts on this evaluation of Linux but
>> looking forward to all of yours.  :)
>>
>> golinux
>>
>>
>>
>>
>> ___
>> 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
>
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan (and Windows)

[Steven W. Scott]

Wow. Funny that, my view is:

Windows: Gaming
Linux: everything else

Linux for pentest, hell yes, mostly because it lends itself extremely well
to quickly implementing a prototype and automating it in a reliable manner.
Windows scheduler is a joke, Windows development is a masochist's dream.
Poweshell is an indicator that MS has only recently come to the
understanding that automation is more than just a room full of low-skilled
operators reacting to pop-up dialogs. Where does the cloud live, on
Windows? Lol!

SWS
On May 3, 2016 5:05 AM, "Go Linux" <goli...@yahoo.com> wrote:

> On Tue, 5/3/16, Mitt Green <mitt_gr...@riseup.net> 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
> >> 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 that
> > is not Unix and my personal choice for this
> > task from now is Microsoft's Windows.
> >
>
> 
>
> Mitt's response reminded me of a post that was made to the forum earlier
> today in the topic "Windows explained to Devuan supporters" at
> https://talk.devuan.org/t/windows-explained-to-devuan-supporters/139/10 :
>
> 
>
> Linux = Pen testing
> Windows = everything else
>
> There are no advantages in using any linux distros other than pen testing
> and that it can be installed on a USB key(and I think that's very cool).
> Even Software Defined Radio (SDR) with maybe the exception of GMS
> intercepting and decoding, has more development under Windows. Night and
> day. One works extremely well on all PCs and permits the User to actually
> be productive and do things. The other one is a clunky Windows wannabe with
> a couple of specialized advantages that most don't care about. So..
>
> YES
> I like its functionality, its popularity(more software dev and hardware
> support), its clarity and ease of use.
> The only thing wrong with my Windows is its lack of pen testing
> capability, and that is why I'm here (KL2 using Debian8 and now looking for
> an alternative with Dev-one as a base), otherwise I would >> n e v e r <<
> bother with anything linux, life is too short
>
> 
>
> I'll spare you my personal thoughts on this evaluation of Linux but
> looking forward to all of yours.  :)
>
> golinux
>
>
>
>
> ___
> 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] OpenRC and Devuan

[Steve Litt]

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 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 call these use-cases. By placing the init systems in /var
> > we again remove another choice for admins/users.  If we are about
> > choice, then /var may not be the best place to put inits.
> > 
> > Something to consider and discuss, I hope.
> >   
> 
> 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.

Interesting point. Perhaps that's why Daniel J Bernstein (djb) put
the /service directory directly off the root. He also put his
executables in, IIRC, /command directly off the root. I always thought
he was crazy, but Jim's point brings some sense to what djb did.

One distro I saw (perhaps Debian) put the /service directory
under /etc. At the time I thought the packager was psychotic, but Jim's
point makes me wonder if the real truth is I was a little shortsighted. 

Perhaps LSB should add a directory called /mustnotbemountpoint directly
off the root, for stuff that must be available immediately upon
mounting the root partition for the first time.

Steve

Steve Litt 
April 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Steve Litt]

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. Anything more complicated than that
> risks to become not that useful or even harmful in the long run, IMHO.

I was going to mention that. My understanding is that in Debian if you
install one init it removes the others. I like having multiple inits
for much the same reason many people have multiple kernels: You might
need to switch, you might need to A/B test, etc.

IMHO the package should install everything, and from what I understand
each init has completely different files than the others, and then
compile the pid1 to be runit.pid1 or s6.pid1 or epoch.pid1.

If so, then switching to, let's say, epoch, would be as simple as this:

cp -p /sbin/epoch.pid1 /sbin/init
 
SteveT

Steve Litt 
April 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan (and Windows)

[Stephanie Daugherty]

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 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://www.troubleshooters.com/rl21
> ___
> 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] OpenRC and Devuan (and Windows)

[Steve Litt]

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://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Steve Litt]

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
> >> Gentoo's OpenRC.  
> > ‎
> > Unix is old. Ancient. We should all agree on it.
> > Devuan is looking for a new base system that
> > is not Unix and my personal choice for this
> > task from now is Microsoft's Windows.
> >  
> 
>  Debian-potato was systemd-free. OK it's old now, but still less 
> than Unix. Why not still use it? No need for Devuan.
> 
>  Didier

I'm so tired of all of this complexification that I'm pulling my
Kaypro 2x out of the closet and going back to CPM.
 
SteveT

Steve Litt 
April 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Hendrik Boom]

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 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 confs.
> > >> > 
> > >> > Basically, everything related to sysvinit, stays in /etc/init.d, and
> > >> > sysvinit knows it has to look there. OpenRC stuff stays in
> > >> > /etc/openrc, and openrc knows it has to look there for its scripts.
> > >> > WFTinit stuff will stay in /etc/wtf, and WTFInit knows it has to look
> > >> > there for its stuff. We add the next-init-system, it will have its
> > >> > scripts in /etc/.
> > >> 
> > >> 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 init systems may expect to own /etc/init.d.
> > >> For instance, openrc puts all its scripts in /etc/init.d (at least on
> > >> Funtoo it does).
> > >> 
> > >> Even though sysvinit is our default init system these days, we should
> > >> not design Devuan such that it is difficult to change that in the
> > >> future.  So put sysvinit stuff in its own directory just like all the
> > >> other inits.
> > >> 
> > > 
> > > 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.
> > 
> > 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 to make Devuan's openrc
> > procedures different (especially when it could be addressed with a 
> > simple symlink).
> 
> With OpenRC one actually has to do: `rc-service foo start`

So what we probably want is a 'service' command that checks what init 
was running as process 1 and issues the proper command for that init.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Steve Litt]

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 deploy init scripts/unit files/runscripts etc in
> > their own namespace and /etc/ and only deploy them
> > when the init system is installed and removes them when it is
> > removed.  This shifts the burden to package maintainers, but that
> > is the right place for them and we can make it easy to add
> > additional init-scripts by filing bugs with patches.  
> 
> 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 confs.

As you read my response, please keep in mind my biases. I tend to break
away from the package manager at the first hint of trouble...

If katolaz was saying "hey, it doesn't have to be that difficult", then
I agree with him. Having installed Runit, s6, and Epoch direct from
upstream developer source code, I find that the upstream developers had
the best ideas about where to put which kinds of files. To the extent
that the Devuan package conforms to what the init's developer used, you
KNOW where its files go.

I see one instance in which Devuan should depart from upstream ideas,
and that's in situations where the init's developer saw fit to create a
new directory off of the root, such as /service in daemontools.
Changing that to /var/service isn't difficult at all.

Anyway, including extra inits needn't be a big effort (except for
creating runscripts/EpochConfigs: the original developers pretty much
got everything right.

SteveT

Steve Litt 
April 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Steve Litt]

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 volunteer manpower to the
> limit.
> 
> So the practical way forward is to leave the task of 
> developing init scripts for the alternative init systems
> to the users of those systems. 

Yes yes yes yes YES!!!

It's a documentation task. If we had a wiki upon which users could
write their successful init scripts/run scripts/EpochConfigs etc, this
task would be removed from upstream developers, who never should have
had this responsibility in the first place.


> 
> If someone would volunteer to coordinate the infrastructure
> needed to collect, systematize, debug and distribute the the
> tens or hundreds of scripts involved (one for each service),
> multiplied by the number of init systems to be supported,

I think the preceding can be accomplished by a wiki. The user clicks on
the desired init, then on the desired (for want of a better word)
daemon, and sees the proper init script/run script/EpochConfig. There
would be a place to edit a given init/daemon combination.

This wiki should be passworded so neither systemd fanatics nor whacko
out of control anti-systemd crazies can sabotage it. Perhaps give edit
rights by init system. For instance, you'd want me to have edit rights
for Runit, s6 and Epoch, but not for OpenRC, perp or nosh.

> I'm sure the Devuan project leads could consider in future
> ways to bring them into the Devuan package ecosystem.

Yes, and it could be done slowly, with no pressure.

> 
> For those with time to invest, I would suggest the
> following:
> 
> * determine a subset, those esssential services that, if supported,
>   would allow a user to get a usable base system:
> 
> * choose one or two best-of-breed init systems to work on,
>   and provide infrastructure for collecting contributions
>   for *all* init systems, even less popular ones.
> 
> With cheers for the volunteers,

I might volunteer for Runit.

SteveT

Steve Litt 
April 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Steve Litt]

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 short intro:
> https://wiki.gentoo.org/wiki/Comparison_of_init_systems

For some reason I can't begin to fathom, the preceding link ignores the
existence of all the daemontools-inspired inits:

* Runit
* S6, s6-rc
* nosh
* perp
* Suckless init + daemontools-encore

I can't help this reminding me of Lennart Poettering's statement that
systemd is better than Upstart and sysvinit, as if no other
alternatives existed.

SteveT

Steve Litt 
April 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Steve Litt]

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  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.
> 
> --
> Regards
> Piotr
> 
> On 5/3/16, 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://troubleshooters.com/linux/init/features_and_benefits.htm#init_system_feature_matrix
> >
> > Keep in mind these two things:
> >
> > 1) I'm an order of magnitude less knowledeable on init systems than
> > the average person on the supervis...@list.skarnet.org mailing list.
> >Those guys found several mistakes in my matrix, and I'm not sure
> > I corrected all of them.
> >
> > 2) Like everyone else, I have likes, dislikes and maybe an agenda.
> > I'm a huge fan of daemontools-inspired inits, and I have a
> > significant dislike of systemd.
> >
> > SteveT
> >
> > Steve Litt
> > April 2016 featured book: Rapid Learning for the 21st Century
> > http://www.troubleshooters.com/rl21
> > ___
> > 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] OpenRC and Devuan

[KatolaZ]

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 the init systems would do the same,
i.e. providing a configurable option to specify where their scripts
are located. This will enforce isolation, and avoid moving around
files or symlinks unnecessarily.

PDSCE

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] OpenRC and Devuan

[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
> > the init system* where they are to be found? This will allow a much
> > easier coexistence of different confs.
> > 
> > Basically, everything related to sysvinit, stays in /etc/init.d, and
> > sysvinit knows it has to look there. OpenRC stuff stays in
> > /etc/openrc, and openrc knows it has to look there for its scripts.
> > WFTinit stuff will stay in /etc/wtf, and WTFInit knows it has to look
> > there for its stuff. We add the next-init-system, it will have its
> > scripts in /etc/.
> 
> 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 init systems may expect to own /etc/init.d. 
> For instance, openrc puts all its scripts in /etc/init.d (at least on 
> Funtoo it does).
> 
> Even though sysvinit is our default init system these days, we should
> not design Devuan such that it is difficult to change that in the
> future.  So put sysvinit stuff in its own directory just like all the
> other inits.
> 

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.

-- 
~ parazyd
0333 7671 FDE7 5BB6 A85E  C91F B876 CB44 FA1B 0274



pgp8gAxom6MNU.pgp
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Svante Signell]

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 be found? This will allow a much
> > easier coexistence of different confs.
> > 
> > Basically, everything related to sysvinit, stays in /etc/init.d, and
> > sysvinit knows it has to look there. OpenRC stuff stays in
> > /etc/openrc, and openrc knows it has to look there for its scripts.
> > WFTinit stuff will stay in /etc/wtf, and WTFInit knows it has to look
> > there for its stuff. We add the next-init-system, it will have its
> > scripts in /etc/.
> 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 init systems may expect to own /etc/init.d. 
> For instance, openrc puts all its scripts in /etc/init.d (at least on 
> Funtoo it does).

So does Debian openrc.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Rainer Weikusat]

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). Further, I'm still being put down as "too young to be taken
seriously" by a lot of people

=> I'm apparently not old and certainly not ancient.

=> 'The current init system' is then obviously neither old nor ancient.

However, what was this now supposed to communicate from a technical
point of view>?
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Rob Owens]

- 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 confs.
> 
> Basically, everything related to sysvinit, stays in /etc/init.d, and
> sysvinit knows it has to look there. OpenRC stuff stays in
> /etc/openrc, and openrc knows it has to look there for its scripts.
> WFTinit stuff will stay in /etc/wtf, and WTFInit knows it has to look
> there for its stuff. We add the next-init-system, it will have its
> scripts in /etc/.

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 init systems may expect to own /etc/init.d. 
For instance, openrc puts all its scripts in /etc/init.d (at least on 
Funtoo it does).

Even though sysvinit is our default init system these days, we should
not design Devuan such that it is difficult to change that in the
future.  So put sysvinit stuff in its own directory just like all the
other inits.

-Rob
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Daniel Reurich]

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 to lead to confusion.
>>  Being able to have them only installed when the init system is 
>> installed reduces the cruft left around - and the only way to do 
>> that is with triggers ala init-system-helpers and deb-helper shim 
>> for each init that's added to a package.
>> 
> 
> Agreed. But still, it would me much easier to maintain the whole
> mess if each init system is isolated from the others, with no
> interactions whatsoever. Different inits, separate scripts, separate
> directories.

That's what I'm saying also - keep them separate but only install those
parts when their respective init systems are installed.
> 
>> 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 necessary init scripts and
>> adding dh- into debian/rules.  No extra cruft will be
>> installed on the end users system unless the user installs that
>> init system.
>> 
> 
> This might become a bit of a mess, if I understood correctly, since 
> we would have to maintain either a package of scripts for each init 
> system, or thousands packages like "apache-scripts-sysv", 
> "apache-scripts-openrc", "apache-scripts-wtf".
> 
No.  The init scripts for all inits go directly in the package - apache.
 But they should be deployed to (or removed from) the filesystem by a
dpkg-trigger that is tripped by the installation or removal of the
respective init-system to which those packages belong.

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

Yes I agree about this too!

> and then copy (or symlink) the corresponding directory in /etc/ only
> when the user selects "wtf" as init system?
No this is wrong.. because the user will have all this cruft installed
for all possible init systems which will be confusing.

The dpkg-triggers way means that only when "wtf" init is installed does
dpkg-trigger install the scripts for "wtf" from each services package
into /etc/wtf.

> This could be managed much more easily by update-alternatives, which
> has just to update two symlinks, e.g. he one corresponding to
> /sbin/init and the one corresponding to it's bloody scripts
> directory

I'm not sure the first is best managed that way and the second is
entirely superfluous as each respective init should point to it's own
binary and directory of init scripts directly.

I'd prefer to have a -base and  package with:

-base being installed/removed triggering deployment/removal
of all the service scripts (and any work arounds for services without
scripts for that specific init system)

 providing the init binary and pre-depending on
-base (so  can't be installed without
-base, and -base can't be installed without
first changing the initsystem.  As already is the case 
depends on the package "init" which is a meta-package that enforces one
 to be installed and also sets the default 

Anyway this is pie in the skie  talk until we have a final release out.

Regards,
Daniel.

-- 
Daniel Reurich
Centurion Computer Technology (2005) Ltd.
021 797 722



signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[hellekin]

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

I like Dan's proposal to use update-alternatives to manage which init
system to run.  Usually choosing an init for a given system only happens
once during the install phase, unless you're actually testing setup of
inits.

What about an init-freedom meta-package working like mail-server and
linking to various working combinations of init + process manager +
device manager?  It could provide a choice at install time, and be
changeable using dpkg-reconfigure init-freedom.

In passing, are there init script converters between various approaches?

Maintaining compatibility of a given package with various init systems
should be easy to track ("hey, your package is compatible with the
default init system [currently: sysvinit], but lacks support for:
openrc, systemd").  At least automatically create issues for this so
that package maintainers can add the relevant scripts.

That way, when we decide to switch the default init system away from
sysvinit, it's because we know most or all packages support the new
default system, *and* flipping back and forth from new to old default in
case anything goes wrong.  Lotsa werk ahead.

==
hk

-- 
 _ _ We are free to share code and we code to share freedom
(_X_)yne Foundation, Free Culture Foundry * https://www.dyne.org/donate/
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[poitr pogo]

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 alternate init is in some sense on his own, but
has all available scripts in packages so can install them.
Or the package for alternate init system can provide helper tools to
install available packages and even inform the user which packages have
missing scripts for selected alternate init system and have to be provided
manually.

So several init systems can coexist with one beeing more priviledged than
others.

Some enthusiast may even provide single package with all available optional
init scripts for all applications. Whatever suits.
Several options, one default with strict rules.

Regarding handling init scripts for different inits, the only hard moment i
can imagine is the time when devuan comes to decision to select new init
system as a default one.

But even then it will probably happen with a new release.
So all packages will be recreated including by default init scripts for new
system. And moving old sysvinit into separate, additional package, making
sysvinit optional.

--
Regards
piotr
written using my smartphone
03-05-2016 13:18, "KatolaZ"  napisał(a):

> 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, as has been
> > > already suggested by others) and then copy (or symlink) the
> > > corresponding directory in /etc/ only when the user selects "wtf" as
> > > init system?  This could be managed much more easily by
> > > update-alternatives, which has just to update two symlinks, e.g. he
> > > one corresponding to /sbin/init and the one corresponding to it's
> > > bloody scripts directory...
> >
> > This is very much a hack. Not really a good way to do it. As Dan says,
> > submitting patches to the already existing packages is a much more
> > elegant way. I think Dan proposed a very good thing, almost a complete
> > solution.
> >
>
> I am not against submitting patches to existing packags to include
> init scripts.
>
> Only, whatever smart solution you come up with guys, please try as
> hard as possible to keep it as *simple* as possible, not a single bit
> more, not a single bit less. The fewer interactions we have among sets
> of init scripts belonging to different init systems (ideally, no
> interaction whatsoever), the easier maintaining them in the long run,
> and plugging in new init systems as yet unforeseen.
>
> 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. Anything more complicated than that
> risks to become not that useful or even harmful in the long run, IMHO.
>
> PrimoDevuanStabilisCreandaEst
>
> 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
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[KatolaZ]

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 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 call
> these use-cases. By placing the init systems in /var we again remove
> another choice for admins/users.  If we are about choice, then /var
> may not be the best place to put inits.
> 
> Something to consider and discuss, I hope.
> 

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.

PDSCE

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] OpenRC and Devuan

[KatolaZ]

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, as has been
> > already suggested by others) and then copy (or symlink) the
> > corresponding directory in /etc/ only when the user selects "wtf" as
> > init system?  This could be managed much more easily by
> > update-alternatives, which has just to update two symlinks, e.g. he
> > one corresponding to /sbin/init and the one corresponding to it's
> > bloody scripts directory...
> 
> This is very much a hack. Not really a good way to do it. As Dan says,
> submitting patches to the already existing packages is a much more
> elegant way. I think Dan proposed a very good thing, almost a complete
> solution.
> 

I am not against submitting patches to existing packags to include
init scripts.

Only, whatever smart solution you come up with guys, please try as
hard as possible to keep it as *simple* as possible, not a single bit
more, not a single bit less. The fewer interactions we have among sets
of init scripts belonging to different init systems (ideally, no
interaction whatsoever), the easier maintaining them in the long run,
and plugging in new init systems as yet unforeseen.

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. Anything more complicated than that
risks to become not that useful or even harmful in the long run, IMHO.

PrimoDevuanStabilisCreandaEst

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] OpenRC and Devuan

[KatolaZ]

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 only installed when the init system is installed reduces the cruft
> left around - and the only way to do that is with triggers ala
> init-system-helpers and deb-helper shim for each init that's added to a
> package.
>

Agreed. But still, it would me much easier to maintain the whole mess
if each init system is isolated from the others, with no interactions
whatsoever. Different inits, separate scripts, separate directories.

> 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 necessary init scripts and adding
> dh- into debian/rules.  No extra cruft will be installed on
> the end users system unless the user installs that init system.
> 

This might become a bit of a mess, if I understood correctly, since we
would have to maintain either a package of scripts for each init
system, or thousands packages like "apache-scripts-sysv",
"apache-scripts-openrc", "apache-scripts-wtf".

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 then copy (or symlink) the
corresponding directory in /etc/ only when the user selects "wtf" as
init system?  This could be managed much more easily by
update-alternatives, which has just to update two symlinks, e.g. he
one corresponding to /sbin/init and the one corresponding to it's
bloody scripts directory...

PrimoDevuanStabilisCreandaEst

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] OpenRC and Devuan

[Brad Campbell]

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. Ancient. We should all agree on it.
Devuan is looking for a new base system that
is not Unix and my personal choice for this
task from now is Microsoft's Windows.



 Debian-potato was systemd-free. OK it's old now, but still less
than Unix. Why not still use it? No need for Devuan.


I am still using it in several locations, but for net connected systems 
security updates are nice.



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Daniel Reurich]

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/unit files/runscripts etc in their own
>> namespace and /etc/ and only deploy them when the init
>> system is installed and removes them when it is removed.  This shifts
>> the burden to package maintainers, but that is the right place for them
>> and we can make it easy to add additional init-scripts by filing bugs
>> with patches.
> 
> 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 confs.

Actually yes it will be much easier and cleaner that way and make
transitioning from one to another much simpler.
> 
> Basically, everything related to sysvinit, stays in /etc/init.d, and
> sysvinit knows it has to look there. OpenRC stuff stays in
> /etc/openrc, and openrc knows it has to look there for its scripts.
> WFTinit stuff will stay in /etc/wtf, and WTFInit knows it has to look
> there for its stuff. We add the next-init-system, it will have its
> scripts in /etc/.

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 only installed when the init system is installed reduces the cruft
left around - and the only way to do that is with triggers ala
init-system-helpers and deb-helper shim for each init that's added to a
package.

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 necessary init scripts and adding
dh- into debian/rules.  No extra cruft will be installed on
the end users system unless the user installs that init system.




-- 
Daniel Reurich
Centurion Computer Technology (2005) Ltd.
021 797 722



signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Didier Kryn]

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 is looking for a new base system that
is not Unix and my personal choice for this
task from now is Microsoft's Windows.



Debian-potato was systemd-free. OK it's old now, but still less 
than Unix. Why not still use it? No need for Devuan.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan (and Windows)

[Go Linux]

On Tue, 5/3/16, Mitt Green <mitt_gr...@riseup.net> 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
>> 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 that
> is not Unix and my personal choice for this
> task from now is Microsoft's Windows.
> 



Mitt's response reminded me of a post that was made to the forum earlier today 
in the topic "Windows explained to Devuan supporters" at 
https://talk.devuan.org/t/windows-explained-to-devuan-supporters/139/10 :



Linux = Pen testing
Windows = everything else

There are no advantages in using any linux distros other than pen testing and 
that it can be installed on a USB key(and I think that's very cool). Even 
Software Defined Radio (SDR) with maybe the exception of GMS intercepting and 
decoding, has more development under Windows. Night and day. One works 
extremely well on all PCs and permits the User to actually be productive and do 
things. The other one is a clunky Windows wannabe with a couple of specialized 
advantages that most don't care about. So..

YES
I like its functionality, its popularity(more software dev and hardware 
support), its clarity and ease of use.
The only thing wrong with my Windows is its lack of pen testing capability, and 
that is why I'm here (KL2 using Debian8 and now looking for an alternative with 
Dev-one as a base), otherwise I would >> n e v e r << bother with anything 
linux, life is too short



I'll spare you my personal thoughts on this evaluation of Linux but looking 
forward to all of yours.  :)

golinux




___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[KatolaZ]

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
> namespace and /etc/ and only deploy them when the init
> system is installed and removes them when it is removed.  This shifts
> the burden to package maintainers, but that is the right place for them
> and we can make it easy to add additional init-scripts by filing bugs
> with patches.

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 confs.

Basically, everything related to sysvinit, stays in /etc/init.d, and
sysvinit knows it has to look there. OpenRC stuff stays in
/etc/openrc, and openrc knows it has to look there for its scripts.
WFTinit stuff will stay in /etc/wtf, and WTFInit knows it has to look
there for its stuff. We add the next-init-system, it will have its
scripts in /etc/.

No files to be moved around. No need to update any symlink.

I am sure it is a too naive proposal, for reasons that I don't
understand.

PrimoDevuanStabilisCreandaEst

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] OpenRC and Devuan

[Daniel Reurich]

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?
>>
>> I've tried. See
>> http://troubleshooters.com/linux/init/features_and_benefits.htm#init_system_feature_matrix
>>
>> Keep in mind these two things:
>>
>> 1) I'm an order of magnitude less knowledeable on init systems than the
>>average person on the supervis...@list.skarnet.org mailing list.
>>Those guys found several mistakes in my matrix, and I'm not sure I
>>corrected all of them.
>>
>> 2) Like everyone else, I have likes, dislikes and maybe an agenda. I'm
>>a huge fan of daemontools-inspired inits, and I have a significant
>>dislike of systemd.
> 
> The problem with supporting multiple init systems is that
> there is an init script for each service that has to be
> ported or rewritten. 

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
namespace and /etc/ and only deploy them when the init
system is installed and removes them when it is removed.  This shifts
the burden to package maintainers, but that is the right place for them
and we can make it easy to add additional init-scripts by filing bugs
with patches.
> 
> Launching Devuan while maintaining the sysvinit status quo
> has already stressed the pool of volunteer manpower to the
> limit.

Only because of the prolific infestation of packages with systemd
dependencies.  Other pure init systems suggested won't carry the same
problems once we have systemd eradicated.

> 
> So the practical way forward is to leave the task of 
> developing init scripts for the alternative init systems
> to the users of those systems. 
> 
Yeah, with a little help in places.  For ascii we should have atleast 2
init systems possible and sysvinit also able to be properly cleansed too.

> If someone would volunteer to coordinate the infrastructure
> needed to collect, systematize, debug and distribute the the
> tens or hundreds of scripts involved (one for each service),
> multiplied by the number of init systems to be supported,
> I'm sure the Devuan project leads could consider in future
> ways to bring them into the Devuan package ecosystem.
> 
> For those with time to invest, I would suggest the
> following:
> 
> * determine a subset, those esssential services that, if supported,
>   would allow a user to get a usable base system:
> 
> * choose one or two best-of-breed init systems to work on,
>   and provide infrastructure for collecting contributions
>   for *all* init systems, even less popular ones.

* implement the debhelper script in the source package init-system-helpers.

Sounds like a reasonable plan.

Regards,
Daniel.
-- 
Daniel Reurich
Centurion Computer Technology (2005) Ltd.
021 797 722



signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[parazyd]

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-systems
> >>/sysvinit
> >>  /etc
> >>  /lib
> >>  /usr
> >>/openrc
> >>  /etc
> >>  /lib
> >>  /usr
> >>/systemd
> >>  /etc
> >>  /lib
> >>  /usr
> 
> > This is an important suggestion, which parazyd himself was evaluating
> > yesterday, noting that among the errors made in the previous openrc
> > packages was this one: put the files of each init system in the same
> > /etc/init.d directory, basically making them overlap.
> > 
> > I agree we should adopt the policy you are proposing in Devuan.
> 
> How does that work in terms of getting the right files into place ? Is it a 
> case of the switching process will copy the files into /etc and so on ? Or 
> will they be symlinked, or what ? And possibly more important, what's the 
> process for removing them when switching to another init ? And what about 
> having two systems installed for those who want to try one but leave the 
> other selectable at boot time (for if it doesn't work out ?)
> I'm thinking back to the "debate" over /bin and /usr/bin and the discussions 
> related to what needs to be mounted early during boot - /var isn't typically 
> mounted until relatively late.
> 
> From that basis, would it be better to perhaps put openrc scripts in 
> /etc/init-orc or something like that ?
> 

/var/cache/init-systems ?? Yes, I know it's just an example, but is a
very wrong one.

All OpenRC specific files/dirs like init.d, conf.d, runlevels and such
simply go to /etc/openrc/ , much like systemd with /etc/systemd. It is
really the correct way to do it.
Also, if one switches to OpenRC, you should forget about helper scripts
like update-rc.d.

If one switches to OpenRC from sysvinit, the install script would just
have to look for the enabled initscripts and their runlevels, and enable
them accordingly with OpenRC. Provided the initscripts are included in
the packages already installed. On that note, Gentoo's package
repositories might be a valuable resource.

On what could/could be removed, IMHO the old sysvinit scripts can stick
around because they will not overlap with OpenRC's scripts. The only
thing that comes to mind is the inittab and how it will be handled?
Perhaps just a symlink to /etc/openrc/inittab ...

-- 
~ parazyd
0333 7671 FDE7 5BB6 A85E  C91F B876 CB44 FA1B 0274



pgpTZ_udPcP6E.pgp
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Jaromil]

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 optional in Devuan.

this is what is going to happen and $years is a variable between
releases. Our release cycle is clear: packages get in unstable
(Ceres), then in testing (Ascii) which will have them in once
released. The openrc package proposed is not taking any shortcut.
So people willing to help maintaining it should run Ceres.
People willing to use it as soon as its ready: Ascii.

We have no interest in changing the default sysvinit, but we have
interest in having other init options working, especially considering
in Debian they have made a dog's breakfast of them.  Therefore we can
expect Ascii to have more options ready for use and possibly not even
overlapping between one and another.

I'm not sure update-alternatives is the best way to make them
co-exist. I suspect we can simply leave them coexist in different
directories and at full stop on install. The re-making of the openrc
package should be a good testing ground for more generic solutions.

ciao

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Simon Hobson]

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
>>  /usr
>>/openrc
>>  /etc
>>  /lib
>>  /usr
>>/systemd
>>  /etc
>>  /lib
>>  /usr

> This is an important suggestion, which parazyd himself was evaluating
> yesterday, noting that among the errors made in the previous openrc
> packages was this one: put the files of each init system in the same
> /etc/init.d directory, basically making them overlap.
> 
> I agree we should adopt the policy you are proposing in Devuan.

How does that work in terms of getting the right files into place ? Is it a 
case of the switching process will copy the files into /etc and so on ? Or will 
they be symlinked, or what ? And possibly more important, what's the process 
for removing them when switching to another init ? And what about having two 
systems installed for those who want to try one but leave the other selectable 
at boot time (for if it doesn't work out ?)
I'm thinking back to the "debate" over /bin and /usr/bin and the discussions 
related to what needs to be mounted early during boot - /var isn't typically 
mounted until relatively late.

From that basis, would it be better to perhaps put openrc scripts in 
/etc/init-orc or something like that ?

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[KatolaZ]

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 the pool of volunteer manpower to the
> limit.
> 
> So the practical way forward is to leave the task of 
> developing init scripts for the alternative init systems
> to the users of those systems. 
>

+1

The ideal thing would be for Devuan to be able, in the long run, to
seamlessly support different init systems + supervisors, so that the
user might be able to choose among them during installation, or even
to switch betweem them after the install.

However, that would be a massive effort, as we have seen that staying
with sysvinit is already quite complex, so that in practice we might
be better off supporting just one of them atm (sysvinit), and adding
more meat as long as the energy put in the project will allow it.

[cut]

> 
> For those with time to invest, I would suggest the
> following:
> 
> * determine a subset, those esssential services that, if supported,
>   would allow a user to get a usable base system:
> 
> * choose one or two best-of-breed init systems to work on,
>   and provide infrastructure for collecting contributions
>   for *all* init systems, even less popular ones.
> 

That's a wise suggestion, indeed.

Primo Devuan Stabilis Creanda Est

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] OpenRC and Devuan

[Jaromil]

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
>   /lib
>   /usr
> /openrc
>   /etc
>   /lib
>   /usr
> /systemd
>   /etc
>   /lib
>   /usr
> 
> With something like this, devuan could remain true to init-system
> freedom, keep cruft out of the way, and make it easy for
> sysadmins to switch amongst init systems.
> 
> The idea could be developed further, to use debian's proven
> 'update-alternatives' method for switching amongst init-systems.



This is an important suggestion, which parazyd himself was evaluating
yesterday, noting that among the errors made in the previous openrc
packages was this one: put the files of each init system in the same
/etc/init.d directory, basically making them overlap.

I agree we should adopt the policy you are proposing in Devuan.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[parazyd]

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 make it work properly :)

-- 
~ parazyd
0333 7671 FDE7 5BB6 A85E  C91F B876 CB44 FA1B 0274



pgpC7gbnp3ThE.pgp
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[parazyd]

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_systems

-- 
~ parazyd
0333 7671 FDE7 5BB6 A85E  C91F B876 CB44 FA1B 0274



pgpGHFS4lCa45.pgp
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Simon Hobson]

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 looking for a new base system that
> is not Unix and my personal choice for this
> task from now is Microsoft's Windows.

If there were a prize for the wittiest response, I think that should have it :-)

My 2d worth, I agree with earlier comments that the project probably doesn't 
have the resources yet for such a major undertaking. I'm not saying it's a bad 
idea, but it's a huge undertaking which means (probably) adding & maintaining a 
fork/derivative/add-on of every package that uses an init script - and I 
suspect that for many packages, asking the Debian maintainers if they would 
please add & maintain the extra init script will be met by "less than 
co-operative" responses.

Yes, certainly think about what's needed, and how best to do it, but for the 
moment I'd agree that a higher priority should be getting to a "production 
release" with (at least the appearance of) all the support tools that 
manglement expect to see behind something they allow on production servers.
IMO, at the moment Devuan isn't seen as a "serious" distro - Debian has a long 
history, plenty of resources behind it, etc, etc. RH and Suse have commercial 
backing. These things matter to manglement types. Get Devuan to a "complete" 
and stable (sans SystemD) distro, persuade people to come on-board, and once 
you've got those solid foundations, then is the time to be getting more 
adventurous.
Trying to do too much too soon risks diluting resources too far and never 
getting to that critical stage.

As I say, just my 2d worth. And written from the PoV of someone who never seems 
able to learn to not take on too much - and always having unfinished projects 
and unfulfilled promises :-(

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Mitt Green]

> 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 that
is not Unix and my personal choice for this
task from now is Microsoft's Windows.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[poitr pogo]

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
> 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_benefits.htm#init_system_feature_matrix
>
> Keep in mind these two things:
>
> 1) I'm an order of magnitude less knowledeable on init systems than the
>average person on the supervis...@list.skarnet.org mailing list.
>Those guys found several mistakes in my matrix, and I'm not sure I
>corrected all of them.
>
> 2) Like everyone else, I have likes, dislikes and maybe an agenda. I'm
>a huge fan of daemontools-inspired inits, and I have a significant
>dislike of systemd.
>
> SteveT
>
> Steve Litt
> April 2016 featured book: Rapid Learning for the 21st Century
> http://www.troubleshooters.com/rl21
> ___
> 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] OpenRC and Devuan

[Steve Litt]

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_benefits.htm#init_system_feature_matrix

Keep in mind these two things:

1) I'm an order of magnitude less knowledeable on init systems than the
   average person on the supervis...@list.skarnet.org mailing list.
   Those guys found several mistakes in my matrix, and I'm not sure I
   corrected all of them.

2) Like everyone else, I have likes, dislikes and maybe an agenda. I'm
   a huge fan of daemontools-inspired inits, and I have a significant
   dislike of systemd.

SteveT

Steve Litt 
April 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Steve Litt]

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 hate to see it become the
default.

1) OpenRC cannot respawn. The only way most OpenRC installations get
   respawning gettys is that their pid1 is still sysvinit, which can
   respawn via /etc/inittab.

2) From what I've seen in Gentoo/Funtoo, OpenRC init scripts are every
   bit as gruesome as those from sysvinit. Sure, the OpenRC ones don't
   have to be as complex, but truth be told, neither do the sysvinit
   ones.

3) As a Runit user for five months, and a guy who has experimented with
   s6, I believe that daemontools-inspired inits like Runit and s6 (or
   s6-rc) are much superior. They have tiny run scripts, they don't
   need all that LSB time machine garbage, their test points are easy
   to measure and strongarm, they make it trivial to make your own
   daemons (I've made daemons in Python and launched them via Runit).
   They can be installed by a mere mortal using make and gcc, and have
   almost no dependencies.

So, to summarize my opinion:

OpenRC as an option, heck yeah! Gentoo, Funtoo and Manjaro-OpenRC have
used it for years, and it works wonderfully if you don't care about
respawning.

OpenRC as the default, heck no! If we ever change the default init,
let's do so in a way that makes real progress, and progress in the
direction that most people believing in the Unix Philosophy would
appreciate.

[snip]

> While it may not seem much, this task is not a one-person-job and
> therefore I am looking for co-maintainers of the OpenRC package for
> Devuan. Please let me know if you are interested in co-maintaining a
> new init system for Devuan with me.

Heavens no it's not a one-person-job. OpenRC is fairly complex. And
shipping its init scripts would be a full time job. I'd say that
adapting Runit or Epoch, or maybe s6(rc) would be a one person job, but
not OpenRC.

SteveT

Steve Litt 
April 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Daniel Reurich]

 Original Message 
From: Daniel Reurich <dan...@centurion.net.nz>
Sent: 3 May 2016 1:54:36 PM NZST
To: parazyd <para...@dyne.org>
Subject: Re: [DNG] OpenRC and Devuan



On 3 May 2016 11:19:40 AM NZST, parazyd <para...@dyne.org> wrote:
>The current init system is old. Ancient. We should all agree on it.

Sure but it just works.

>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.
>
That's great.  We need to add more init system options and support easily 
switching between them.  But changinng the default would be something that 
would need to be agreeable to our whole community and not just the devs.  

>In Debian, years ago, effort was made to get OpenRC running. Utter
>fail.
>The developers kept the old LSB initscripts and made such an ugly job
>to
>make OpenRC work with them, while kicking out OpenRC initscripts from
>the way (which are, by the way, much more readable and elegant than
>LSB).
>
One thing that  came out of systemd - or rather highlighted by it is the 
ability to use install triggers to install/remove stuff conditional to when 
some other package is installed or removed.  The debhelper package dh_systemd 
from the init source package enables this nicely for systemd and we should use 
this same method for all init systems we support in Devuan ... including 
sysvinit.

>I would like to revive this effort, and this time do it properly,
>keeping OpenRC in /etc/openrc/ along with its own initscripts. Each
>package that has its initscript would have to include a new,
>OpenRC-specific initscript. There are really no good arguments to use
>LSB initscripts with OpenRC.

Agreed.  Combined with dh_openrc (or whatever we call it) this should be 
possible and allow each package to maintain a it's own openrc scripts or fall 
back on a boilerplate implementation.
>
>While it may not seem much, this task is not a one-person-job and
>therefore I am looking for co-maintainers of the OpenRC package for
>Devuan. Please let me know if you are interested in co-maintaining a
>new
>init system for Devuan with me.

-- 
Daniel
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Brad Campbell]

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 sort of 
"change for changes sake" that I moved to Devuan to get away from.



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Boruch Baum]

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 am happy
with it. However, it strikes me as misguided at this point for
any of devuan's limited development energy to focus on adopting
an openRC option instead of on resolving all outstanding systemd
issues and on establishing a solid release 1.0. Don't get me
wrong - I don't mean to be discouraging. I just don't think this
is appropriate timing.

What might be nice is some form of 'init-system-sentry' to keep
cruft of unused / unwanted init-systems out of the way. On a
Manjaro OpenRC system, there exists cruft from both sysvinit and
from systemd, if only because of the n>>1 packages that a user
will install at some point post-distro-iinstallation that include
scripts for those init systems. The presence of the cruft can
confuse one into making unnecessary changes in wrong places that
have no effect.

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
  /usr
/openrc
  /etc
  /lib
  /usr
/systemd
  /etc
  /lib
  /usr

With something like this, devuan could remain true to init-system
freedom, keep cruft out of the way, and make it easy for
sysadmins to switch amongst init systems.

The idea could be developed further, to use debian's proven
'update-alternatives' method for switching amongst init-systems.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Hendrik Boom]

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 made to get OpenRC running. Utter fail.
> The developers kept the old LSB initscripts and made such an ugly job to
> make OpenRC work with them, while kicking out OpenRC initscripts from
> the way (which are, by the way, much more readable and elegant than LSB).
> 
> I would like to revive this effort, and this time do it properly,
> keeping OpenRC in /etc/openrc/ along with its own initscripts. Each
> package that has its initscript would have to include a new,
> OpenRC-specific initscript. There are really no good arguments to use
> LSB initscripts with OpenRC.
> 
> While it may not seem much, this task is not a one-person-job and
> therefore I am looking for co-maintainers of the OpenRC package for
> Devuan. Please let me know if you are interested in co-maintaining a new
> init system for Devuan with me.

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?

-- hendrik

> 
> Cheers!
> 
> -- 
> ~ parazyd
> 0333 7671 FDE7 5BB6 A85E  C91F B876 CB44 FA1B 0274
> 



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