systemd-free Devuan Linux hits version 1.0.0

Devuan, the effort to build a systemd-free version of Debian, has released Devuan Jessie 1.0.0, a release candidate felt to be just about the finished article. In a mail sent to the project's followers the self-proclaimed “Veteran Unix Admins” behind Devuan say “This Devuan Jessie release candidate is as close as we can get to …

[Anonymous Coward]

The code is also junk. For example, rather than working off proper parameterization, systemd checks for hard-coded paths (/proc, /sys) to handle them differently. I imagine Poettering's main contributions now are reviewing pulls and reformatting XML files.

[DrXym]

They missed a trick

Should have called their dist Amix after the Amish. Technology should go this far and no further.

[Graham Dawson]

Re: They missed a trick

Not every change is for the better. systemd changes a whole bunch of things for absolutely no purpose, to the detriment of users and developers. It isn't any form of progress. This idea that new is always better is a fallacy.

systemd is a regression - a reduction in quality and maintainability. Rejecting regression is a good thing.

[Charles 9]

Re: They missed a trick

You forget. The Amish are technophobes. They're very much against using electricity; computers are essentially taboo to them.

What you probably intend to coin is perhaps "Luddix" on the belief that technology isn't the answer to everything.

PS. Back to the discussion. If we do have to go back to square one, how DO we better handle dynamic hardware configurations where even basic things like displays can come and go on a moment's notice?

[HieronymusBloggs]

Re: They missed a trick

"how DO we better handle dynamic hardware configurations where even basic things like displays can come and go on a moment's notice?"

By making a solution that doesn't break things for users who don't require that. Most of the (rational) criticism of systemd is that it makes things unnecessarily difficult for those who don't need it.

[CrazyOldCatMan]

Re: They missed a trick

By making a solution that doesn't break things for users who don't require that.

*DING* *DING* *DING* *DING*

For my use-case (and yes, I'm aware that that my use-case might not be the same as others, but it's pretty standard - it's a headless server VM with a fixed, unchanging and non-dynamic hardware set), systemd introduces a whole set of cruft and services I DON'T NEED!

At least one of which means that I can't boot the VM in anything other than recovery mode.

[Graham Dawson]

Re: They missed a trick

Udev handled that just fine... which is why they rolled it into systemd I guess.

[HieronymusBloggs]

Re: They missed a trick

"Should have called their dist Amix after the Amish. Technology should go this far and no further."

Rejection of a flawed new technology does not indicate a rejection of all that is new. It indicates a rejection of flaws. (I suspect you already know that).

[DrXym]

Re: They missed a trick

Except systemd is for the better. Virtually all of the objections about it are absurd.

[Charles 9]

Re: They missed a trick

Really? Then perhaps you can list and rebut all the objections to it, including boring things like ntp and udev best kept separate, not using an ASCII log that can be read easily even if you're forced to read a crashed drive by raw sectors, and especially the attitude coming from up top of "my way or the highway," and no, Linus is better than Pottering in this regard. Linus objects to stupid stuff. Pottering objects to stuff that isn't his.

[Anonymous Coward]

Re: They missed a trick

Is Poettering related to Daniel J. Bernstein - they seem to share the same basic beliefs?

[Tom 38]

Re: They missed a trick

djb and Poettering are very different. djb is an exceptionally smart cryptographer that no distro trusts, and Poettering is an exceptionally naive developer that every distro trusts.

The only similarity between the two is that they both have the firmly held belief that they are right; when it comes to security, I'm inclined to trust djb on that regard.

[CrazyOldCatMan]

Re: They missed a trick

Is Poettering related to Daniel J. Bernstein - they seem to share the same basic beliefs?

No - Dan knows what he's doing and is a capable developer..

(I've used his stuff for years - can be a steep learning curve but, once installed, it Just Works(tm))

[DrXym]

Re: They missed a trick

You can have ASCII logging. A simple Google would show you how to set it up, assuming your dist doesn't already. It would also explain the rationale for binary logging (e.g. forward secure sealing, capturing extra information, better indexing, tamper detection etc.).

I have no idea what you mean about ntp and udev being kept separate. Perhaps you're referring to the fact that systemd package contains a lot of low-level commands that you are free to use or not use as your requirements dictate. Systemd provides a SNTP (S for simple) client called timesync. You are completely free to install a full blown client-server ntpd if you desire but many deployments don't need that complexity and a simple NTP client means they can avoid installing ntpd altogether.

But hey, systemd is evillll!!! Let the dance of derp continue.

[Charles 9]

Re: They missed a trick

Anything that involves a translation means things can get LOST in translation, especially if a system is heavily used. START with an ASCII log, THEN work from there on an AUXILIARY basis. Until you can prove yourself able to dig through a mangled journal on a crashed drive using a raw sector editor (because the system you're using for the post-mortem may not even be a Linux machine, so forget about one that groks a binary log to say nothing of an extended filesystem), don't even get started.

Why MUST the log be binary for forward-secure sealing? Why not encode a TEXT log and append the Hex-encoded hash to the log? You get your signature AND maintain an ASCII log that can still be read in the event of a disaster. It's nothing more than a blockchain, and you don't need to use binary formats to create a blockchain.

As for enclosing those utilities, remember the old Microsoft mantra? The three E's? Embrace, Extend, and Extinguish. This seems like a blatant attempt to usurp baseline utilities and take over their control so that no one else can keep up? Look at what happened to udev, which was working pretty well all by itself. Between it and the existing init systems, you'd be well on your way to solving most of the existing problems with dynamic hardware, containerization, and so on while still keeping things distinct.

And what about Bug #5644? In any other circles, this would be a Drop Everything because it breaks a cardinal rule of Linux (Don't allow easy tampering of the root). Here it's a WONTFIX. And not because it's a non-issue, because no real reason is given for ignoring the issue. Where I come from, we call that "taking the ball out of spite" and consider this a sign the project is Not Ready for Prime Time and the head to be blackballed.

Frankly, if they could demonstrate one clear and present need that systemd AND ONLY systemd solves by its particular methodology, we'd probably pay at least some attention to it. But until then...

[HieronymusBloggs]

Re: They missed a trick

"You can have ASCII logging. A simple Google would show you how to set it up, assuming your dist doesn't already."

Unfortunately it doesn't tell me how to turn off binary logging, only mask it or redirect it to /dev/null. I don't want the extra processing overhead of generating a redundant set of logging data only to dispose of it.

The problem here isn't that alternatives can't be used, but that a lot of the stuff built into systemd can't be _removed_ .

[DrXym]

Re: They missed a trick

"Unfortunately it doesn't tell me how to turn off binary logging, only mask it or redirect it to /dev/null. I don't want the extra processing overhead of generating a redundant set of logging data only to dispose of it."

You can turn off the storage in journald by adding Storage=none to the conf file and it logs nothing. Set a flag and it sends the text to someplace else if you like or the console. It isn't as though logging takes much resources in the first place though.

The reality is the binary logs are there so they can be journaled, indexed, tamper resistent, searchable and all the rest. Things that administrators want or should want. It doesn't even stop you extracting the journal as text. It does allow you to tell if somebody has deleted lines from your journal. It does allow you to efficiently search between two date ranges on a particular event.

It's just an example of the knee jerk reactions that people hate on it without bothering to check if supports what they're trying to do.

[HieronymusBloggs]

Re: They missed a trick

"You can turn off the storage in journald by adding Storage=none to the conf file and it logs nothing. Set a flag and it sends the text to someplace else if you like or the console. It isn't as though logging takes much resources in the first place though."

I've had a system hang due to journald generating absurd amounts of data. It was fixable, but that's not the point. I don't want that data generated in the first place.

"It's just an example of the knee jerk reactions that people hate on it without bothering to check if supports what they're trying to do."

I don't hate systemd; I'm happy it exists for those who want to use it. I've made what I consider to be a sensible engineering decision to remove it from my own systems. Don't take it personally.

[Charles 9]

Re: They missed a trick

"The reality is the binary logs are there so they can be journaled, indexed, tamper resistent, searchable and all the rest. Things that administrators want or should want. It doesn't even stop you extracting the journal as text. It does allow you to tell if somebody has deleted lines from your journal. It does allow you to efficiently search between two date ranges on a particular event."

EVERYTHING you describe can be done with an all-text journal.

The kernel log can be timestamp and is frequently already timestamped.

If you really need indexing, you can generate an external file. I know video editors that use this technique for interframe videos.

You don't need a binary format to create a blockchain as they tend to be format-agnostic.

And logs are already searchable. Since most log searches are textual in nature, a simple linear search remains the most practical. A text log is easier to perform a textual linear search.

Now tell me how you extract a text journal from a crashed drive when it was housing your only systemd-based system? As Spike Milligan put it, it's like trying to open a box with the crowbar you will find inside.

[Kiwi]

Re: They missed a trick

It isn't as though logging takes much resources in the first place though.

And here is one of the big problems with systemd's development. "We're not willing/to arrogant/to dumn to see how it can be problem to us so why should we bother fixing it?".

I don't care if it uses few resources. If I don't want it turned on then it should be turned off. My lavalamp uses very few resources, but I am quite happy to hit the off switch when I don't want it on. Those "few resources" can add up to quite a bit when enough of it is going on. And the arrogance, ignorance and sheer stupidity that is a problem with systemd and it's is apparent in your post... "It's not our fault/problem, other people don't have a problem with it, so we won't bother with it".

If people want binary logging then let them turn it on. If they don't want it then let them turn it off completely. MS can figure out ways that their extraneous services can be turned off completely, I'm sure that someone even as feeble-minded as a systemd supporter can at least work that much out.

The reality is the binary logs are there so they can be journaled, indexed, tamper resistent, searchable and all the rest.

Are you really that thick? Do you truly believe that these things have not been long fixed? Hang on, lets fire up an old VM and check... "grep -ir mika /var/log/*".. Yup, gets results back. Like it has done since grep was invented (or /var/log, depending on which came last). So we have searchable. Indexed... Is that worthwhile? If so, trivial to build an index file for it then. Strange, I know, but I think you could actually use a computer to index stuff. It might be a whole new concept but.... Journaled.. What problem does this solve? How many problems and how much unnecessary complexity does this create? Tamper-resistant may be nice, but looking at the attitude of that Potty thing at the head of systemd, I would not trust it to work. Charles 9 suggests a quite workable solution to this. How much intrusion detection is done just through logs anyway?

Does systemd actually log anything that would really be relevant when someone is trying to break in or change stuff? Does it log anything over and above what would be logged by a normal system? Again, given the attitudes of the leadership, I doubt it would log anything relevant or helpful. More likely a hindrance. After all just writing a single byte to the log journal in the wrong place would be enough to trash it. Write a single byte to a 5 byte log entry and you can probably still make sense of it.

So why introduce something that is unnecessarily complex and far more susceptible to file corruption? How does it help any one?

[Kiwi]

Re: They missed a trick

capturing extra information,

On a few occasions I've written programs/scripts that have a logging element to them. As the programmer, I decide what and how much is being logged. If I decide that my program will log stuff-all (if anything) then you have little or no chance of seeing this. How can the addition of binary logging change this? How can it change this in a way that cannot be done with other tools? And is the extra information it captures worthwhile information, or is it like the system error logs that "Microsoft Internet Services" so love to point elderly ladies to when they're trying to steal their money "fix the viruses on their computer internet"? Sometimes "extra information" can be a problem and can lead someone away from a solution.

better indexing,

And when the index gets corrupted at the time of a major failure? You know, when sequential logs are quite important? How would a binary index help anyway? Seriously. I've spent a lot of time with my head buried in piles of logs seeking answers to problems. Either they're there quickly and a glance can see what is going on (eg a web page not displaying, Apache's log shows that there's a permissions problem and I can go in and fix it) or they're something that can require a lot more reading. Being able to scroll down a file is much faster than having to load in a record each time you want to read a new line.

Grep or search functions have been the only "index" I've needed when things go wrong. Well them and Google, but google is for finding answers to why I am seeing the content in the log, not for reading the log. And the content of the logs have always been plenty enough, often excessive. I can't recall a time when I've had insufficient logs to fix a problem (insufficient knowledge, sure, but not insufficient logs!). Caveat : I've not had to fix a lot of Linux stuff, which is a huge reason why I use it and love it.

[GrumpenKraut]

How about an interview with Devuan folks?

I'd be very much interested to hear their thoughts!

[rtfazeberdee]

geez, the ignorance about systemd here is astounding

no point in trying to rebut all lies and misunderstandings, too many of them. go do some research, might cure some of the ignorance demonstrated here of posters who get the info from other troll posters

[HieronymusBloggs]

Re: geez, the ignorance about systemd here is astounding

"no point in trying to rebut all lies and misunderstandings"

Please make the effort to do so, if they are indeed misunderstandings. There are some angry comments here about systemd, but I'd be very interested in your rebuttal of the more rational comments from those of us who have what we believe are sound technical objections to systemd's design.

[Charles 9]

Re: geez, the ignorance about systemd here is astounding

"Please make the effort to do so, if they are indeed misunderstandings. There are some angry comments here about systemd, but I'd be very interested in your rebuttal of the more rational comments from those of us who have what we believe are sound technical objections to systemd's design."

I think what they're saying is that you can't fix Stupid. And you can't stop people ignoring things they WANT to ignore.

[Bodge99]

Re: geez, the ignorance about systemd here is astounding

Yep, some "lies and misunderstandings".. but many, many truths.

Systemd. A solution to a non-existent problem.

Please let it die before a major F.U. occurs.

[Anonymous Coward]

Re: geez, the ignorance about systemd here is astounding (rtfazeberdee)

"no point in trying to rebut all lies and misunderstandings"

"might cure some of the ignorance demonstrated here of posters who get the info from other troll posters"

OK, so can we go direct to a reliable source then?

E.g. https://github.com/systemd/systemd/issues/5644 takes a minute or two to read and doesn't require much technical knowledge at all.

Is there much ignorance and misunderstanding apparent there in those few short posts? Where's it coming from?

Me, I'm just a mildly interested bystander. Or I had been, till I saw that github thread. I suspect many others might react the same way.

[John Hughes]

Re: geez, the ignorance about systemd here is astounding (rtfazeberdee)

E.g. https://github.com/systemd/systemd/issues/5644 takes a minute or two to read and doesn't require much technical knowledge at all.

Yes? What's to understand? There was a bug. It's fixed.

That some people came charging along to shout about the bug after it was fixed, forcing the locking of the bug report says more about the people who complain about systemd than the people who write it.

[HieronymusBloggs]

Re: geez, the ignorance about systemd here is astounding (rtfazeberdee)

"some people came charging along to shout about the bug after it was fixed"

True. The bug itself illustrates the developers' disdain for (and ignorance of) POSIX standards, however. That's enough on its own to make me reluctant to use systemd, regardless of other problems.

[Graham Dawson]

Re: geez, the ignorance about systemd here is astounding (rtfazeberdee)

First among them: poettering, to declare his ignorance.

[Kiwi]

Re: geez, the ignorance about systemd here is astounding

no point in trying to rebut all lies and misunderstandings, too many of them. go do some research, might cure some of the ignorance demonstrated here

Yep. Not like there's people here who live and breath Linux/Security etc, who have had to work at rebuilding systems after a failure, and work hard at figuring out what happened in the process (made so much easier with binary logs that are so easy to read with a crashed system! So much better than plain, and so very old, text!). Why, I doubt even one reader on El Reg would have a clue about what Linux is, let alone any of them ever having had experience in development of any sort!

</sarc>

[DrXym]

Re: geez, the ignorance about systemd here is astounding

Sadly nobody raging about systemd is interested answers.

[HieronymusBloggs]

Re: geez, the ignorance about systemd here is astounding

"Sadly nobody raging about systemd is interested answers."

Nice straw man. The few "raging" comments here are outnumbered by comments from those who have had genuine problems with systemd. Got any answers for them?

[nauved]

Re: geez, the ignorance about systemd here is astounding

We knew this day was coming.

Want to know where systemd is headed? Take a look at this:

https://in.waw.pl/systemd-github-state/systemd-issues.svg

That graph is linked from:

https://www.freedesktop.org/wiki/Software/systemd/

If the 'wontfix' bugs were included, the numbers would be even worse. systemd is sinking under its own weight. May it disappear to the bottom of the ocean of software failures where it belongs!!

[DrXym]

Re: geez, the ignorance about systemd here is astounding

"Nice straw man. The few "raging" comments here are outnumbered by comments from those who have had genuine problems with systemd. Got any answers for them?"

No, they're outnumbered by a lot of whining, a handful of anecdotes, a mass of misconceptions and a various statements that are false or distorted. If you have a specific problem, go look up your problem on superuser.com or a similar site because chances are it's already been answered more than adequately.

I've already dealt with a share of issues here - text logging (just configure it), timesync client (a small SNTP client adequate for 95% of uses vs a full blown 20x larger NTP client/server) et al.

It's funny how for all the people whining about systemd Red Hat and other major dists manage to use it without the world collapsing around them.

[HieronymusBloggs]

Re: geez, the ignorance about systemd here is astounding

"No, they're outnumbered by a lot of whining, a handful of anecdotes..."

One person's "anecdote" is another's practical experience.

"If you have a specific problem, go look up your problem on superuser.com or a similar site..."

Some on this forum might consider such advice patronising.

"It's funny how for all the people whining about systemd Red Hat and other major dists manage to use it without the world collapsing around them."

Not funny at all. Those people have made their own decisions about their own systems. I've made mine. I don't see why anyone would have a problem with that.

[Grumpy Rob]

Re: geez, the ignorance about systemd here is astounding

Well, let's see what Linus thinks about the Red Hat developers working on systemd (back in 2014).

http://lkml.iu.edu//hypermail/linux/kernel/1404.0/01331.html

Oh, sorry - Linus must be an ignorant troll too </sarc>

[Anonymous Coward]

Why not switch to FreeBSD?

Systemd sucks and created tons of issues in practice.

It is hooked into a lot of software piece in Linux.

Why not switch to FreeBSD, which is simple & elegant.

Yes, not that fashion, but enough for most of work.

[Charles 9]

Re: Why not switch to FreeBSD?

Hardware support stinks, especially for end users.

[HieronymusBloggs]

Re: Why not switch to FreeBSD?

"Hardware support stinks, especially for end users."

Hardware support for desktop/laptop systems isn't as good as in Linux, but I don't see it being a problem for most servers.

Judging by the number of commenters here who have problems with systemd (who I suspect represent the tip of quite a large iceberg) I expect *BSD use to increase substantially if it becomes impractical to avoid systemd on Linux. That should provide some incentive for better hardware support.

[wolfetone]

I've used Debian 8 with SYSTEMD installed on it for a while now, and I'll be honest I don't see any sort of improvement. And I mean that. It's like finding a screw in a bag of spanners trying to do things with it.

I held fire on looking at Devuan until I saw more progress with it. I'm glad it's coming along nicely, and it'll be on my laptop over the course of the May Bank Holiday.

We should be given the choice about whether we want systemv (which just works) or systemd (which will soon have a word processor attached to it). Neither should be forced on us.

[Peter Christy]

But, of course, Slackware, one of the oldest and most stable distros out there, has never adopted systemd - nor does it show any inclination to.

Sysvinit may not be the most elegant system, but it works, and is easy to understand.

"If it ain't broke, don't "fix" it!!"

[wolfetone]

Patrick Volkerding said in 2012 that Slackware may be forced to use Systemd in the future. Granted, we're 5 years on from that and 14.2 doesn't include it, but that doesn't mean it won't happen.

If Systemd solved a problem and was the obvious better choice compared to Sysvinit then there'd be no issue with adoption. But Systemd doesn't solve any problems, not to any great extent or benefit.

[sawatts]

What problem systemd suppose to solve anyway?

Recently ported a large legacy application suite from 32-bit Linux to 64-bit and a systemd distro.

The systemd bit was the thing that caused the most headaches and pain.

It was never clear what problem systemd was suppose to be solving. The only thing I've seen touted was that it streamlined boot times - when was this a problem? How often are servers rebooted? (Perhaps once a year?)

In fact, it is far more common to *reboot* a system - and in this systemd seemed to be appallingly bad compared to the "old" way. Unravelling dependencies in reverse - either not much thought or effort has been put into this, or no adequate solution has been found. Rebooting went from under a minute to 15+ minutes or "infinity" (power button).

I really wouldn't mind if systemd actually did something useful. But so far it seems like a big steaming pile of regression.

[MonsieurTM]

Congrats Devuan!

I happen to use Gentoo/Linux and still use init, not systemd. There are other OS that allow the user to choose.

[Mr.Bill]

amazing

"Gnuinos, Refracta, Exe GNU/Linux, Nelum-dev1, Star, heads, good-life-linux and Crowz."

The sheer # of obscure distros. I'm wondering how many have essentially 0 regular users outside of the developer(s) themselves. They use the distro to develop the user-less distro. At best many probably have users who install, test, wipe and move on to the next in the distrowatch list, for fun.

[Jim-234]

Someone should do a Devuan Linux Mint Cinnamon clone.

Now if we could just get somebody to basically make a Devuan based clone of Linux Mint Cinnamon that would be excellent.

I wonder how much in the way of donations it would take to get the Mint guys interested in a version.

(Because unfortunately with the 18.xx versions they went the way of the systemd darkside).

[wolfetone]

Re: Someone should do a Devuan Linux Mint Cinnamon clone.

"(Because unfortunately with the 18.xx versions they went the way of the systemd darkside)."

Well if you choose to sleep with dogs you'll get fleas.

[jake]

Re: Someone should do a Devuan Linux Mint Cinnamon clone.

My dogs don't have fleas, thank you very much. Better living through chemistry.

[Jim-234]

Re: Sleeping with dogs will not give you fleas

Yes, thanks to the wonders of modern veterinary medicine the dogs have been sleeping on the same bed as me for years & there has been no insect problems whatsoever.

Tip: If you like having the dogs sleep on the bed with you, get a large square bed, so whatever angle you get pushed into, your head and feet are still on the bed.