
Devuan “ASCII” 2.0 Release Candidate is now available - tgragnato
https://dev1galaxy.org/viewtopic.php?id=2047
======
kbumsik
Why they use "ASCII" for a distro release? This is so confusing name for
people who don't know what Devuan is. I firstly thought some wierd guys
created their own character encoding and claimed 2.0 version of ASCII.

~~~
JdeBP
As mentioned, the release codenames are those of minor planets. It was how the
Devuan people chose to synchronize with "Jessie" when they forked, since there
is an asteroid (discovered in 1979) with the same name as the Toy Story
character, and then branch onto a new naming system.

* [https://ssd.jpl.nasa.gov/sbdb.cgi?sstr=2003568](https://ssd.jpl.nasa.gov/sbdb.cgi?sstr=2003568)

* [https://ssd.jpl.nasa.gov/sbdb.cgi?sstr=10464](https://ssd.jpl.nasa.gov/sbdb.cgi?sstr=10464)

* [https://devuan.org/os/releases](https://devuan.org/os/releases)

------
nextos
Devuan is basically Debian without systemd.

While I still prefer to run Linux distributions with systemd (NixOS and Arch
in particular), I'm increasingly worried about the complexity systemd brings
in.

I like how clean and standardized the init process is now. I don't like the
bloat prize we've paid, though. I've been stracing my workstation for a few
days. Journald starts eating a ton of RAM, ~100 MB upon boot, and keeps
growing.

I'm annoyed because systemd developers claim 100 MB is normal. It's not,
that's my biggest process on startup. And on my other Arch machine it stays at
25 MB, and they have a long history of memory leaks.

~~~
craftyguy
see newnewpdro's comment.

I just built a headless armv7h system (using Arch Linux ARM) with 1GB of RAM,
and after being up for 3 days running nginx, ssh, and some other bare
services, the total RAM usage, for all applications, is 70-100MB. Systemd is
complex, but it really doesn't seem to add a lot of resource drain for the
power it give you... I'm happy with that tradeoff.

~~~
tannhaeuser
Out of curiosity, to start nginx and sshd you need like 2 lines of shell code
in a BSDish rc.conf - one for starting each service. Why do you think systemd
bringing in 10s and 100s of megabytes of black magic binary code is a trade-
off worth making, especially on a non-desktop without a need for reacting on
up/down events of network interfaces?

~~~
pmden
Systemd isn't one component, so you'd be mistaken assuming everything in the
systemd project is necessary to start a service. But second to that, I'm not
sure why you think nginx_enable='YES' is fundamentally less opaque than an
nginx.service file. Both are parsed by another application. As for why someone
would make that 'trade-off' \- I much prefer being able to add "Restart=on-
failure" than using daemontools, and I don't have the luxury of working with
one single distribution and remember the faff involved with initscripts
differing between CentOS and Debian.

My reasons aside, I'd think a more sensible question would be "why would you
actively avoid using the init system that's shipping by default on what
constitutes at least 90% of the Linux server market when you're using Linux?".
I don't think eyes equate to quality and stability, but I do think Red Hat,
and SUSE, and Canonical and Oracle selling server solutions using it will.

~~~
dozzie
> I'm not sure why you think nginx_enable='YES' is fundamentally less opaque
> than an nginx.service file. Both are parsed by another application.

My guess: because the "another application" that parses nginx_enable=YES is a
(rc) shell script instead of an ELF blob, so you can track its execution.

~~~
andrewshadura
But do you need to?

~~~
dozzie
Yes, when something goes awry with the initscripts system. And systemd is not
exactly famous for its transparency of execution and stability of options'
behaviour.

------
hedora
I’ve been running the beta on my desktop. In this release, they have also
established sane defaults for a wider range of window managers and desktop
environments.

The rough edges I’ve hit can all be attributed to systemd brain damage (like
the fact that the linux kernel no longer has a working, synchronous, “probe
the network cards and create a logical interface for each one” primitive).

My only beef with devuan is that the beta install I have runs systemd’s
elogind. It seems stable enough under devuan, but routinely broke under back
when this machine was actually running systemd, and I plan to cleanse it with
fire if it is still there after I update to stable 2.0.

I highly recommend devuan. Unlike Ubuntu, debian regularly rebuilds everything
from source, and ~95% of their packages have reproducible builds.

For me, this, plus pre-systemd levels of stability and debuggability is a
winning combination.

~~~
danpalmer
(Obligatory, this is honestly not trolling, but...)

> For me, this, plus pre-systemd levels of stability and debuggability is a
> winning combination.

As a developer who uses a Mac every day, and has experience with Linux only at
a distance, administrating servers a little, using Ansible, debugging the odd
production failure...

I actually find it easier to debug a system using systemd. I'm not sure why
this is. Some ideas I have are:

\- It could be that I never learnt the old way?

\- I find the config files easier to grok than the scripts, and I don't think
I've ever had an issue with systemd itself, so never needed to go further down
that path than the config files.

\- I find it a bit more consistent between different parts of the system.

~~~
alxlaz
> I don't think I've ever had an issue with systemd itself

You've been very lucky :-).

My favourite gem, which I haven't been able to figure out by the time I'd
finally decided I've had enough and ditched the damn thing, was not being able
to reboot my computer if I had some filesystems mounted over the network. It
irked me considerably, because I was running a rolling-release distro at the
time and I rebooted fairly often.

(Edit: to be clear -- I'm sure there are tons of valid use cases that systemd
serves much better than any other init system. I know a lot of very
knowledgeable people who use it. My computers just don't seem to have those
use cases :-) )

------
self_awareness
Don't want to troll or anything, just a question from curiosity: don't you
think that massive popularity of systemd is a result of a massive demand for
software like systemd?

~~~
tannhaeuser
On the desktop where you need to deal with WLAN interfaces going up and down,
maybe a monstrosity like systemd has its place, but even there my opinion is
systemd just isn't worth fragmenting and polarizing the whole Unix ecosystem
with systemd's total lack of mental discipline and attitude of wrapping each
and everything under the sun including binary logging, mandatory systemd-only
APIs for loggin in, cron replacement, etc.

On the server-side where Linux has its mainstay, using systemd is even more
pointless IMHO since services and network interfaces don't come and go.
Loosing portability for saving a couple lines of shell code for
starting/stopping services is IMHO a trade-off that just doesn't make sense
from an engineering PoV. All the more so since systemd doesn't shield you from
the intricacies of dealing with demon programs; if something is going south on
your server, have fun with systemd binary logs to analyze what has happened.

Now RedHat (who are shouldering a large part of Linux development anyway) sure
aren't stupid; therefore I have to conclude that they're playing the Embrace,
Extend, Extinguish game here to subvert Linux into SystemD-OS.

Devuan has become a very important key project to prevent that from happening
to the Debian code base. Btw congrats to the Devuan project! I wasn't quite
sure they'd be able to deliver a couple years ago when they started; now I
think Devuan (along with Gentoo, Slackware, Alpine) is going to save Linux'
ass as a "real" F/OSS community effort going forward, no less. My hope is Arch
Linux with its great community and documentation gets a systemd-less fork as
well.

~~~
digi_owl
Systemd exist for two groups, macbook packing cypherpunks and devops "cattle
farms".

All the rest have to grin and bear it until Pottering and crew gets bored, run
into those corner cases that made the older systems so gnarly to maintain, and
move on.

~~~
tannhaeuser
I hope you're wrong on systemd on a Mac. I have to assume its being used for
systemd-under-(systemd-infested-linux)-under-virtualbox or systemd-under-
docker (or even systemd-under-docker-under-<systemd-infested-linux>-under-
virtualbox). systemd-under-docker is particularly pointless IMHO if it's even
possible. Could someone using systemd on a Mac chime in and explain the use
case?

~~~
digi_owl
Macs seems to be right behind Thinkpads in terms of Linux support, thanks to
having fairly static hardware between models.

End result seems to be that quite a few either single or dual boot Linux on
Mac.

------
_jal
Great timing for me. Just got the last of the parts in to build a network
audio player, waiting for the weekend to start on it. I'll use this instead of
Raspian.

~~~
freedomben
Why do you want to use sysvinit over systemd? Do you have init scripts already
written that you don't want to port?

~~~
frankharv
Well binary logs seem to be a good enough reason for me.

I use FreeBSD and Devuan feels like I am in control. Some commercial software
won't work on FreeBSD so I have to use some Linux.

I also use Alpine because it uses OpenRC. With gLibc missing it is tough to
compile some software.

Compared, Devuan seems to be very software compatible and offers the
familiarity of Debian.

Over at FreeBSD we have loads of new users thanks to systemd.

Keep up the great work RedHat.

~~~
iforgotpassword
That's why I have a wildcard redirect to rsyslogd, the journal is pretty much
mirrored in text form in /var/log.

I still think systemd is by far the best init system around. Service files are
a trillion times cleaner, easier to understand and maintain than those bloated
90% copy and past init scripts with the retarded archaic run level concept.

Really, if I had a reasonable amount of free time left I'd start something
like systemd lite which is just the init part and none of the other bullshit.
You could already just use that part but there is still quite a bit of crap
around that could just be removed.

~~~
JdeBP
You need to learn about uselessd. And you need to stop committing the fallacy
of allowing for only two systems in the world, systemd and van Smoorenburg
init+rc. This fallacy was called out by the author of uselessd.

* [http://uselessd.darknedgy.net/ProSystemdAntiSystemd/](http://uselessd.darknedgy.net/ProSystemdAntiSystemd/)

* [http://jdebp.eu./FGA/run-scripts-and-service-units-side-by-s...](http://jdebp.eu./FGA/run-scripts-and-service-units-side-by-side.html)

------
dvfjsdhgfv
Devan is an useful and important distro. I just hope they integrate back with
Debian at some point (I don't know how, but I'd love o see that happen.)

~~~
sverige
That seems unlikely unless Debian drops systemd or the ecosystem becomes so
dependent on systemd's ever-expanding reach that it becomes impossible to
build a Linux distro without it.

~~~
irl_
Debian doesn't actually have anything against sysvinit or OpenRC. Those are
just not the defaults. Both sysvinit and OpenRC are available in Debian.

It probably would be easier to have a non-systemd system were the Devuan
developers to upstream their packaging and patches to Debian.

As Devuan has a stated goal of not using systemd though, I would guess they
take the easy route of not maintaining systemd compatibility. The longer it
remains a fork without effort to upstream changes, the more it would diverge
and the more work it would be. It would also be more work to keep the fork
going, so I guess at some point it would either have to be a hard fork or it
would die.

~~~
sverige
From 2014-06-11 systemd news:

> * The support for SysV and LSB init scripts has been removed from the
> systemd daemon itself. Instead, it is now implemented as a generator that
> creates native systemd units from these scripts when needed. This enables us
> to remove a substantial amount of legacy code from PID 1, following the fact
> that many distributions only ship a very small number of LSB/SysV init
> scripts nowadays.

At the earliest possible opportunity, systemd removed everything they could
that supported alternative init systems. So no, it is not trivial to take a
Debian release and make it run SysVinit or OpenRC. In fact, it was so much
work that the Devuan devs expended the effort to fork, including setting up a
website, mailing lists, IRC channels, a bug-tracker, and all the other
infrastructure necessary to maintain a serious, well-supported distro.

And as far as "upstreaming" to Debian, how is Debian upstream for SysVinit or
OpenRC? Both of those are separate projects not owned by Debian.

~~~
vbernat
> So no, it is not trivial to take a Debian release and make it run SysVinit
> or OpenRC.

It is: "apt install sysvinit-core". For some reason, we still carry the burden
of maintaining compatibility with many init systems while the "pro-choice"
players don't.

> And as far as "upstreaming" to Debian, how is Debian upstream for SysVinit
> or OpenRC? Both of those are separate projects not owned by Debian.

Until recently, sysvinit was maintained by Debian.

------
ryanpcmcquen
Thank goodness for Slackware and Devuan.

~~~
krylon
If you dislike systemd, Void Linux might be worth looking into as well.

And of course, Gentoo is still around, for those of us with too much time and
too many spare CPU cycles on their hands. ;-)

~~~
olakease
Been using void for a couple of years. I could not be happier with it. I also
need a non-systemd distro for production, found this project
[https://github.com/cloux/aws-devuan](https://github.com/cloux/aws-devuan)
it's devuan + runit for aws.

------
trollian
I appreciate that they named their release after a no longer suitable
character encoding. It does seem like a lot of trouble to go to to troll the
systemd haters though.

~~~
sanxiyn
Devuan is serving a need. It is not trolling.

~~~
jdoss
What exact need?

~~~
sanxiyn
A need to run Debian system without systemd.

~~~
jhkaghjkga
That need is already fulfilled by Debian? Just install sysvinit. (edit:) Also
consider that if Debian would stop supporting sysvinit, a distribution adding
support for it again would be a real effort compared to just installing a
different init system by default.

Some desktop environments might want systemd-logind+systemd-shim, but that's
really not different from installing systemd-elogind in Devuan...

------
minieggs
Couples week since I distro hopped.... Guess it's about time...

------
digi_owl
It is really sad how quickly this was voted off the front page...

