
Systemd-free Devuan announces its first stable release candidate 'Jessie' 1.0.0 - MilnerRoute
https://linux.slashdot.org/story/17/04/22/1822216/systemd-free-devuan-announces-its-first-stable-release-candidate-jessie-100
======
INTPenis
Actual announcement: [https://devuan.org/os/debian-fork/stable-candidate-
announce-...](https://devuan.org/os/debian-fork/stable-candidate-
announce-042017)

Reminds me of dragonfly bsd. Anyone still use that?

I stayed on 4.x until 6.x came out and later Scott Long actually admitted that
5.x was a bad release.

So Devuan now wants to continue Debian with tons of shell scripts to maintain
while most other major distros move to systemd. That means package maintainers
are moving to systemd. So Devuan will have to maintain separate init scripts
for their distro mostly on their own.

I mean who in their right mind would write a 27 line init script when they
could write a 7 line systemd unit?

~~~
SwellJoe
_" I mean who in their right mind would write a 27 line init script when they
could write a 7 line systemd unit?"_

27 lines is horribly optimistic. Complex services like Apache, MySQL, etc.
could have initscripts hundreds of lines long, plus the library of support
scripts that most distros ship to make the initscripts shorter and more
manageable. Most initscripts are like 50%, or more, boilerplate that's the
same across all services, but, it's still a pain in the ass to maintain them.

I will not miss initscripts, even if I might have some occasional complaints
about systemd.

~~~
JdeBP
As I pointed out at
[https://news.ycombinator.com/item?id=14169188](https://news.ycombinator.com/item?id=14169188)
, there's a discussion of MySQL on the systemd-devel mailing list right now.
Clearly some people in that discussion are not familiar with MySQL. Clearly
some of the people in _this_ discussion are not familiar with MySQL either.

To help combat this ignorance, here are some actual systemd units:

* [https://github.com/MariaDB/server/blob/10.1/support-files/ma...](https://github.com/MariaDB/server/blob/10.1/support-files/mariadb%40.service.in) \-- MariaDB's official systemd service unit, 173 lines long

* [https://github.com/mysql/mysql-server/blob/5.7/scripts/syste...](https://github.com/mysql/mysql-server/blob/5.7/scripts/systemd/mysqld.service.in) \-- MySQL's official systemd service unit, 60 lines long

* [https://github.com/percona/percona-server/blob/5.7/scripts/s...](https://github.com/percona/percona-server/blob/5.7/scripts/systemd/mysqld.service.in) \-- Percona's official systemd service unit, 61 lines long

* [https://sources.debian.net/src/apache2/2.4.25-3/debian/apach...](https://sources.debian.net/src/apache2/2.4.25-3/debian/apache2.service/) \-- Debian's third party systemd service unit for Apache2, 15 lines long

So these figures that people are pulling out of thin air are erroneous by
anywhere from half the actual length to an order of magnitude too small. And,
ironically, the Apache systemd service unit _is using a System 5 rc shell
script_ under the covers to do all of the work. The apachectl program is in
fact a System 5 rc script from 1997, complete with start/stop/restart/status
verbs.

~~~
vacri
Counting empty lines and comments is hardly the way to make your point. The
mariadb unit file you linked to is only 34 actual lines, the mysql unit file
only 22, percona 23.

And if you're writing your own unit files rather than ones for public
consumption, you probably won't include lines like "Documentation=" and some
other minor args.

~~~
JdeBP
Actually, counting lines, whether empty, comment, or otherwise, very much _is_
the way to make the point. The reality of actual service units that people
write is not anything like the picture that was being painted. You erroneously
think that the point is that short is good and long is bad, rather than what
it actually is, which is _learn the subject and don 't make facile arguments
based upon rubbish numbers plucked from thin air_. Actually looking at reality
and counting, rather than pulling the number 7 from a hat, is part of that
point.

I recommend reading the design of the Mewburn rc system,
[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)
, and some of the entries in the systemd House of Horror. This whole "It's
just writing 7 lines and it's easy!" argument falls apart when one looks at
the reality of short service units that are either grossly wrong or turn out
to be underpinned by the very things that their lengths are being compared to
(which also means that it is still those rc scripts that are being used and
maintained by software authors -- from 1997 in the example of apachectl), real
world service units that are not short, other systems of long standing that
are equally concise, and -- yes -- the reality that people _include
commentary_ for maintainability.

One of the amusing things about this argument that is of particular relevance
to the Devuan release is that back when Devuan was announced someone put up a
"fork Fedora" WWW page criticizing the Devuan people, with a systemd service
unit side by side with a van Smoorenburg rc script. It is sad to note that few
people observed that the systemd unit described just one service, whereas the
van Smoorenburg rc script ran _two_. Since you are on the subject of
commentary, I invite you to observe which of the twain included comments and
which did not, as well, and determine what point the "fork Fedora" people were
in fact demonstrating. (-:

~~~
mdekkers
Thank you for putting this argument across so succinctly and with such good
research behind it. Everytime I hear the arguments in favor of systemd, I
wonder when these people actually come down from their ivory towers to do some
real life work, where the rubber meets the road.

The argument of "lines of code" in a startup script is such a stupid strawman,
it defies belief. I design and build large scale production system, and have
exactly zero interest in the size (or complexity) of a startup script. I am
interested in being secure in the knowledge that a control script handles all
possible cases, including edge cases, that might present themselves during the
forseeable lifecycle of the service/application in a predictable and
understandable manner. If it takes a bit more time and work to understand
these scripts, so be it - what are a few extra hours (which, incidentally,
force you into a better understanding of the thing your working on - always a
good thing) when seen across the timeline fo the service lifecycle?

systemd does a few cool things, and many blindingly retarded things. It is
probably _really nice_ to have on your laptop, what with the fast boot times
and all, but many of the things touted as "advantages" really do not hold up
for server work. What do I care if my boot time is a few seconds less on a
server? rebooting a prod server is usually a scheduled event, with (depending
on the context) can call for anywhere between a 30 to 120 minute maintenance
window.

The systemd people should be made to work building and maintaining a real-life
backend environment for a while.

------
faragon
Systemd has cool things, but it is a monster. I'm glad this alternative
exists.

~~~
lomnakkus
Are you going to use it? Just curious.

~~~
aerique
I've been using Void Linux for a couple of weeks now on my new machine at work
and I've been enjoying it a lot. It brings a BSD'ish elegance to Linux.

No issues hardware-wise either so far:

\- Intel Core i7-7700K

\- MSI Z270 Gaming Pro Carbon

\- Gigabyte GeForce GTX 1060 WINDFORCE OC 6G

\- Samsung 960 EVO 1TB (M.2, NVME)

~~~
slau
I've been a Void user for a year and some months now. It's a great system.
Xbps (the package manager) is so ridiculously fast, it puts zypper, apt and
dnf to shame.

The base system is extremely light and nimble. Getting FDE up and running was
a breeze, even with the fairly barebones installer, and it being a rolling
release makes it very nice as well. It's maybe a bit too bleeding edge to run
on servers, but as a workstation distribution, I can't fault it.

Disclaimer: I'm donating monthly to the project, and am currently trying to
contribute a few servers to the build farm, so I'm probably very biased.

~~~
mdekkers
this looks interesting. I have been looking to replace ubuntu as my weapon of
choice for servers for some time now. I am hesitant of the rolling release
idea though. I _like_ the idea that my servers remain in a specific state, but
remain up to date with security patches, and don't like the idea of spending
time fixing update issues. How is that handled in Void?

------
e12e
Previous thread on link to actual announcement:

[https://news.ycombinator.com/item?id=14173666](https://news.ycombinator.com/item?id=14173666)

------
dijit
I'm glad the project exists and I hope it's stable enough to be adopted by
companies in the future - my fear is that debian/rhel are entrenched now
though.

Sidenote- So far this is not necessary, debian still has pluggable init
systems as long as you don't add something which hard depends on systemd (like
gnome)

I have done this one 5 of my own servers used for various things (including
virtualhost/docker host) and it hasn't been an issue for over a year now.

[http://without-
systemd.org/wiki/index.php/How_to_remove_syst...](http://without-
systemd.org/wiki/index.php/How_to_remove_systemd_from_a_Debian_jessie/sid_installation)

~~~
jnbiche
> I'm glad the project exists and I hope it's stable enough to be adopted by
> companies in the future - my fear is that debian/rhel are entrenched now
> though.

It's not just debian/ubuntu/rhel, almost _everyone_ has moved to systemd, even
Arch Linux and Gentoo. As much as I agree with the ideas behind Devuan,
knowing and understanding all the intricacies of systemd is now required
knowledge for anyone doing Linux-based software development or devops. After
putting it off for a while, I've moved on and have learned systemd. It's not
the way I would have liked for the Linux ecosystem to have moved (I thought
upstart was a decent base to build on), but I'm clearly in the minority here.

What's bothering most at this point are the binary log formats. But that
changes from week to week. But it's here to stay, so I'm getting used to it.

~~~
dijit
I have a standing policy regarding systemd.

It's fine for my desktop and laptop, it's not fine for my server.

My servers (generally speaking) do one thing and that thing absolutely can't
be mucked with, systemd does a lot of what I would consider _mucking_.. binary
complexity and weird integration I seriously dislike.

But it's actually beneficial on a desktop system.

My friends who have learned systemd are basically the same as you- "Eh, it's
alright when it works.. and it's where everyone has gone so I guess I'll live
with it"

I take exception to that statement entirely, this is open source, the land
where you can replace your kernel with a BSD one and continue trucking with
GNU ultilities as if nothing happened basically- why do we have to go
backwards in usability for someones ego.

(and it's hard for me not to see it as one mans ego given his repeated
hostility and arrogance regarding how other people use computers
professionally)

~~~
jnbiche
> I take exception to that statement entirely, this is open source, the land
> where you can replace your kernel with a BSD one and continue trucking with
> GNU ultilities

Fair enough. And to be fair to me, I've been thinking seriously about moving
my workstation over to a BSD. But even if I do that, I'd still have to deal
with Linux for work at times.

------
yladiz
As someone out of the loop with any of this (I've always just been content
with using Debian as-is, and I haven't done much work with systemd), can
someone explain why systemd is as bad as it seems to be? As in, why is it so
bad that an entire major Linux distro was forked and created with the
seemingly sole purpose of removing this program?

~~~
anonbanker
> why do people hate it?

Poorly-designed, poorly-implemented, half-baked ideas, legendary feature creep
that presents a corollary to Zawinsky's Law, awful developers, clear political
agendas in the devteam, Embrace-Extend-Extinguish tactics, against the basic
UNIX concept of "many small apps that do one thing and do it well", an
informal adoption of Windows service/logging techniques, political lobbying by
the developers, and a literal RPC-based backdoor into the enforceability of
the GPL.

~~~
mdekkers
_a literal RPC-based backdoor into the enforceability of the GPL_

Oh, I didn't hear that one before - any more info?

~~~
ilwtekuysd
Some of the 4chan people trolling about systemd try to make people believe
that communicating over tcp sockets, pipes or dbus with other processes is a
"backdoor" around the GPL. Because a non-free program could talk to a GPL
progam. Shocking!

------
jwildeboer
Oh? Took em that long?

~~~
duskwuff
And why did they have to call it "Jessie"? That's the code name Debian used
for their 8.0 release in 2015.

Come on... if you're going to fork a distribution, use different release
names.

~~~
tgragnato
> [https://git.devuan.org/devuan/devuan-project/wikis/devuan-
> co...](https://git.devuan.org/devuan/devuan-project/wikis/devuan-codenames)

They call Jessie a "Matching release", I guess the intention is to stress the
fact that you can safely migrate from Debian without a reinstall.

~~~
lomnakkus
They missed an opportunity there. Should have been "jessie-j".

... but I actually agree with duskwuff. It's hugely confusing and possibly
even disingenuous to call it "jessie".

~~~
dane-pgp
Devuan "jessie" is designed to match Debian "jessie" as much as possible, and
is a one-off copying of the release name in order to mark the branching point
in the histories of the two distros as they diverge slightly over time.

As the release announcement says:

"Devuan is the Debian that was and could have been. Our goal is to provide a
viable and sustainable alternative. It is a new path, nurtured with your help
and support."

so Devuan could be considered the true inheritor of the "jessie" name, and of
the name "Debian", for that matter, although keeping that would obviously be
too confusing.

~~~
lomnakkus
Well, yes, I think we all got that point. It's just that Google's search bot
may not. I'd be absolutely fine with something mechanically derived from
"Jessie" (etc).

