Here we go: devuan

[Michael Paoli]

Thanks,

I also like Ian's well calling out the point (which I'm quite aware of
but failed to mention): "If" ... "this was just an init system"[1].

For better or worse, systemd has its hooks/fingers into the operating
system well beyond being an init system, and conversely, many major
software packages/systems are, for better or worse, making themselves
highly and even inherently dependent upon systemd.

So, in addition to all the major technical implications of going, or not
going with systemd, there are also major design/philosophical issues[2]
and differences, and feelings tend to run high on these matters.  Not
saying that Unix or GNU/Linux (or GNU/kFreeBSD or GNU/Hurd) necessarily
always nor consistently sticks with such a design (e.g. Perl, Python,
Linux kernel - many might argue those are significant counter-examples,
at least in significant part), but such design, and/or lack thereof, or
more specifically different design/approach - well, it's not only
different in that regard, but a quite significant place for it to be in
the operating system.  Not necessarily saying that it's good nor bad -
lots of valid pro/con arguments for going either direction, but either
way, it's either a quite significant change, with various advantages and
disadvantages, or something else - with another significant set of
various advantages and disadvantages.

And it's not been just Linux looking at and/or using significantly
different init systems.  Has also happened in the Unix/BSD space as
well.  I keep hoping this would just all "work itself out" more
smoothly, and with less animosity and "battles".  But, alas, sometimes
hard decisions have to be made, and sometimes those are just about
guaranteed to seriously ruffle some feathers.

So, I "anxiously"/patiently anticipate what the longer-term future, 5 to
10 or more years out on this, will show us and what we will have learned
by then.  I also tend to wonder if we can usefully apply lessons from
history to this, and avoid or reduce sub-optimal actions and choices.

I'd also think/anticipate that some/many of devuan's early choices and
infrastructure may be subject to quite significant change - as it seems
(at least certainly compared to Debian) that they've really just barely
started - quite to be expected of a new project/fork/distribution.

Footnotes/references/excerpts:
1. http://bad.debian.net/pipermail/bad/2014-November/003655.html
2. http://en.wikipedia.org/wiki/Unix_philosophy


> From: "Elizabeth K. Joseph" <lyz at princessleia.com>
> Subject: Re: Here we go: devuan
> Date: Sun, 30 Nov 2014 10:24:44 -0800

> On Sat, Nov 29, 2014 at 3:13 PM, Ian Zimmerman <itz at buug.org> wrote:
>> https://devuan.org/
>
> My sentiments echo Michael's.
>
> Also, I'm very surprised and disappointed they chose to use a closed
> source tool (GitHub) for a code repository when so many open source
> tools for this exist. One of the things I really love about Debian's
> infrastructure is that it's all open source and largely managed in the
> open (anyone can apply to be part of the Debian System Administrators
> (DSA) team[0]). At least jenkins-debian-glue is open source.
>
> [0] https://dsa.debian.org/
>
> --
> Elizabeth Krumbach Joseph || Lyz || pleia2