Linux greybeards release beta of systemd-free Debian fork

The effort to create a systemd-free Debian fork has borne fruit, with a beta of “Devuan Jessie” appearing in the wild. Devuan came into being after a rebellion by a self-described “Veteran Unix Admin collective” argued that Debian had betrayed its roots and was becoming too desktop-oriented. The item to which they objected …

[ckdizz]

I love Linux, but I hate the boring, predictable responses to changes major or minor that pervade the mindset of a whole bunch of my fellow enthusiasts. Systemd is a positive for me. Sorry (not sorry), but it is.

I'm not a massive fan of Lennart or his attitude, and I dislike the tendency toward feature creep (but I turn those features off), but a supported init system that has at least the intention of integrating well, and which has support and inertia is a good thing for Linux. Sorry (not sorry), but that's how I, and obviously a majority of maintainers, feel. Let's face it, systemd isn't just popular because of Red Hat. It's popular because it works better than anything else.

From my perspective, the systemd situation exemplifies one of the major advantages and two of the major problems with Linux and other FLOSS. The major advantage is that anything can be forked. Which is great, and how it should be.

But then, moving to the problems, anything can be forked, and people use that freedom to try and fork things at the slightest provocation (like LibreSSL, which was founded with a stated purpose and has arguably failed to live up to that intent). Alright, an in init system is a big change and therefore not technically "the slightest provocation", and Devuan will probably just fall into the category of minor distros that have crappy maintenance and flounder for a while before failing. But the failure of a minority to get on board with changes that distros have made because the maintainers see the benefit highlights the other problem with Linux and other FLOSS: the almost Luddite resistance to change that we see now, and we saw in PulseAudio, that has you banging your head on the table and wondering if everyone who refuses to use anything new still walks around with a Nokia 5110 in their pocket and has a rotary phone on their landline. You know what I put this down to? I don't want to change and I don't want to learn.

But yeah. Enjoy your "freedom".

[Preston Munchensonton]

It's popular because it works better than anything else.

If this were true, I would expect the BSD distros to consider it and they couldn't be bothered with systemd. In my view, it's "right tool for the right job" and systemd certainly makes some sense on desktops (especially if using GNOME) but I can hardly understand how it could be considered as "working better than anything else" for servers. Specifically, my biggest gripe is the lack of feedback/console logging after issuing a service start/stop/restart/reload action. There are others to be sure (like the NTP tirade that some have voiced).

As you point out, choice is a good and healthy thing and I'm glad that some choices are still available. But those choices are shrinking with so many distros on the systemd train. It's not about not wanting to learn, but far more about suitability and there should NEVER EVER EVER be a one-size-fits-all solution. If I wanted that, I would use Windows.

[wolfetone]

"...there should NEVER EVER EVER be a one-size-fits-all solution. If I wanted that, I would use Windows."

At the moment the one size fits all Windows isn't fitting anyone.

[ckdizz]

BSD isn't a great example of how an OS should progress. It has neither the market share or manpower to even maintain the kernel for new hardware, let alone make a change as drastic as an init system. Let's face it, Linux rules the server market, Red Hat rules the Linux server market, and as much as you might dislike Poettering or systemd, Red Hat aren't going to start taking something as drastic from upstream as an init system change without it benefiting their core market. They know where the majority of their money comes from.

Most of the problems with systemd stem from not knowing or not caring about how to use it. I don't have issues with the amount of information I can get from journalctl. I haven't not been able to debug any issues with systemd. In fact, it's been a lot easier, because I only have to look in one place, and I get relevant targeted information.

There's actually about 70 Linux distros that don't use systemd. But they will all have key software in common to which there is no alternative. And even if a distro does use systemd, that's just the init system - and a lot of work has gone into backward and cross compatibility. Look at the way Debian has implemented it. It's actually awesome. It'll only be like Windows when a single company maintains a single solution incompatible with other distros that uses only its own closed source, proprietary software to do the job.

[ckdizz]

FWIW you can downvote me all you like. Just because you disagree with what I said, that won't affect either the truth of what I'm saying, systemd's market share or its position as the default init system, Red Hat's popularity or massive contribution to FLOSS, or the fact that no other init system - not OpenRC, Upstart, Runit - has garnered the support or gained enough inertia to take SysV's place as the standard.

[Anonymous Coward]

Perhaps you were downvoted

because you mentioned RedHat rather than Ubuntu?

To the hard core anti-redHat (because they make money from free software??? or because systemd came from them?) brigade only Ubuntu or for the really hard core, Debian are where it is at.

Some will even say that there are more Ubuntu servers on the internet than RedHat ones.

Personally, I got fed up with Canonical some years ago and have not bothered with anything they release since. So, for me, the goto distro of choice is CentOS 6 (no systemd) and will remain so for a few years yet.

and, my beard and hair are very grey.

[cyberdemon]

Re: Perhaps you were downvoted

Blarg. I knew that Ubuntu were the reason that systemd got forced into Debian, but I wasn't aware they were part of the whole LSB madness. I'd have thought that would be shooting themselves in the foot, given that their strength comes from Debian. If they really threw their weight behind LSB, then they would have to ditch APT/DPKG in favour of Yum/RPM.

But I wouldn't put that past Shuttleworth & co.

Personally I've only ever used Debian, since before Ubuntu was a thing, but neither my beard nor my hair are grey (yet).

Hard-core anti red-hat not just for systemd, but for LSB as a whole. The money from free-software thing only partially - everyone has to make a living - but I tend to distrust those with an axe to grind, especially when it has negative impacts on MY software @:

And that applies just as much to Canonical too.

[Ken Hagan]

Re: Perhaps you were downvoted

"I knew that Ubuntu were the reason that systemd got forced into Debian, "

S'funny what different people know. I knew that Ubuntu wanted to stick with upstart but were strong-armed into adopting systemd because the Debian community had a big vote and systemd got more votes than either upstart or "stick with the present system".

Mind you, I also knew that Devuan posted a formal notice around March time that they were abandoning the whole project because of lack of interest, so this article surprises me too.

[John Hughes]

Re: Perhaps you were downvoted

I knew that Ubuntu were the reason that systemd got forced into Debian,

But that is the opposite of the truth. Ubuntu (as represented by Ian Jackson) wanted Debian to use upstart. When Debian chose systemd that forced Ubuntu's hand.

[Doctor Syntax]

Re: Perhaps you were downvoted

"But that is the opposite of the truth. Ubuntu (as represented by Ian Jackson) wanted Debian to use upstart."

And the systemd promoters couldn't allow that to happen. Not that a choice between systemd and upstart is one I'd want.

[Chika]

FWIW you can downvote me all you like.

OK.

[Aaron Kulkis]

Systemd doesn't have enough popular support to replace SysVInit, either. It has a more widely installed base, at the moment, but only because RedHat's goons strategically placed dependencies in completely unrelated software so as to cause systemd to be brought in at system installation time.

The vast majority of Linux machines are run and/or owned by people who wish systemd had never been written... and frankly, that Lennart the vandal had never got his hands on a computer, ever.

[Doctor Syntax]

"Red Hat rules the Linux server market, and as much as you might dislike Poettering or systemd, Red Hat aren't going to start taking something as drastic from upstream as an init system change without it benefiting their core market."

That would be the core market which they can supply with the systemd-free RH6 and earlier. AFAIK pre-systemd SEL is coming to the end of support. That leaves Red Hat with the only commercially supported systemd-free product. Having your cake and eating it?

[Ilsa Loving]

"Most of the problems with systemd stem from not knowing or not caring about how to use it. I don't have issues with the amount of information I can get from journalctl. I haven't not been able to debug any issues with systemd. In fact, it's been a lot easier, because I only have to look in one place, and I get relevant targeted information."

I find it hilarious that people are downvoting you to hell when you are completely right. Redhat wouldn't have done this if there wasn't an identified need and desire.

I can't yet use systemd as fluidly as I can init scripts, but as you said, that's just due to lack of familiarity. As a concept, I consider systemd to be infinitely simpler and cleaner than a cacophony of init scripts, that need to be manually debugged when something strange goes on.

Other people claim to have run into problems getting systemd to handle logging 'n whatnot. I dunno what they're doing, but I have so far moved the majority of our linux servers to systemd based distros, and I haven't had a single problem yet.

Individual daemons should not be responsible for maintaining their own security contexts. That's why things like SELinux exists (although the vast majority of people find it "too hard" and just shut it off). Yet daemon-provided init scripts have to manage things like making sure the daemon runs as a non-privileged user. With systemd, this kind of management is now a core part of the OS, like it should have been to begin with.

[John Hughes]

Other people claim to have run into problems getting systemd to handle logging 'n whatnot. I dunno what they're doing,

Mostly they're just lying trolls.

[ElReg!comments!Pierre]

Re: Mostly they're just lying trolls. (@Ken)

I rid all my (personal) Debian machines of systemd (then later switched them to Devuan when it became available, a year ago or so) because I ran into a flurry of problems, mostly with hardware. Most of the problems were caused by systemd itself (some were, notably on older hardware) but what was caused by systemd is that a wonky USB peripheral could bring the whole system down by crashing the init system, which is, simply put, unacceptable in this day and age.

[John Hughes]

Re: Mostly they're just lying trolls. (@Ken)

Ok, that sounds frightening.

What's the bug report#, I'd like to see what was happening.

[ElReg!comments!Pierre]

Re: Mostly they're just lying trolls. (@Ken)

> What's the bug report#, I'd like to see what was happening.

I filed a few, back in the days (that was a few years back). On older hardware systemd was just assuming too much, that _could_ have been dealt with by configuring it better perhaps, too much effort for no added value compared to just wiping the whole damned thing. On more modern machines, touchpad or mouse transcient misbehaviour would cause a system freeze for example. Power supply wonkiness, idem (on machines with built-in batteries!). Slightly wonky network adapter? Down she goes! Etc...

Basically having PID1 take charge of extremely high-level roles is the stupidest design choice ever. Gremlins do happen, and when they do the last thing you want is PID1 dealing directly with them. Specialised tools designed by experts in that precise area with well-documented error codes is the way to go. "look 'ma, I can do it all, no hands" clusterfucks like systemd are the way to downtime.

[asdf]

>That's why things like SELinux exists (although the vast majority of people find it "too hard" and just shut it off).

Funny how that happens after you spend nearly a day diagnosing why a user can't run X apps remotely through ssh and then find out SELinux is silently not allowing sshd access to .Xauthority (not an admin but do help users around my workplace alot). Failing shit silently and in weird ways and wasting users time is why SELinux sucks balls. Yes maybe for an out of the box internet facing server I can see its use but even then you are most certainly better off using OpenBSD whose developers also believe code correctness in a tightly audited base along with proper UNIX permissions and best practices beat the shit out of bolted on RBAC systems which generally just end up locking the door after the horse as bolted and fsck over normal users 1000x more often than the baddies.

[Ben Tasker]

> Most of the problems with systemd stem from not knowing or not caring about how to use it

I think that's a little unfair, but, that said, the very presence of systemd on a system can also lead to a systemd blinker coming down when troubleshooting.

I actually spent some time dealing with an issue earlier. For some reason systemd-udevd had started deciding to rename a NIC from it's configured name to "rename2".

I'm sure Lennart's ears were burning for a little while, until I looked a little closer and remembered what fuckwits Realtek are.

The NIC in question is part of a bond, and on the reboot just before the issue, systemd got impatient waiting for the network to come down cleanly, so just shut it off. On boot, the RTL driver reads the MAC from the NICs volatile storage (instead of the PHY) so got the bond's IP instead, which of course matches the other slave. So two NICs matched the same udev rule...oops

Blaming the (sometimes) clusterfuck that is systemd is too easy and rarely solves the problem itself.

But systemd isn't faultless either, just as some distros managed to ship flawed selinux configs (apache context? Nah, won't need /var/www/html). It's got it's problems and journalctl is a fair example (system hung and want to know why? Sorry the binary log is corrupted). Being able to pass through to rsyslogd is a bandaid not a fix for the issue

Or, as others have pointed out, the NTP issues.

[Mark 65]

@ Ilsa Loving: Doesn't systemd make log files binary, in which case it is not a lack of familiarity but rather it does stupid useless shit. grep or awk your binary log file? Tail it? No, chances are there's some reinvented wheel command to perform each action.

[Aaron Kulkis]

"I can't yet use systemd as fluidly as I can init scripts, but as you said, that's just due to lack of familiarity."

And you never will. SysVInit is easily comprehended with less than a page of documentation. It does ONE THING -- it stops and starts deamons.

In contrast, systemd requires HUNDREDS of pages of documentation, and Poettering and his crew of asshole vandals presume that they know how to do EVERYTHING, such as mountd, better than the mountd subject-matter experts. And whenever their code causes some problems, the excuse is always the same --- "XYZ's code is broken" -- not only with system, but with earlier projects these jerks have worked on as well.

I am so glad that Linux called them out on that bullshit, when they were doing incredibly STUPID things in the kernel to cover up for the fact that systemd was spazzing out.

There is some very serious Narcissistic Personality Disorder, if not full blown Borderline Personality Disorder going on with that crew.

[Aaron Kulkis]

"I don't have issues with the amount of information I can get from journalctl."

You've never had a system get horked so badly that journalctl wasn't available, resulting in having to parse the damned thing using od(1), more(1) and much much much more wall-clock time than was in any way reasonable.

Clue for the clueless -- BINARY SYSTEM LOGS ARE BAD, M'KAY.

G o d d a m n, some of the people posting here are utterly fucking stupid and too short for this ride.

[asdf]

systemd is all about making GNU/Linux the new POSIX

>If this were true, I would expect the BSD distros to consider it

Uh no. Red Hat went out its way to make systemd Linux only and through very strategic placement in some major projects (the udev dependency changed everything) got it in the dependency web so it will make more and more FOSS over time largely Linux only which guess who sells the most maintenance contracts for? Take a look at how much work it is already to port Gnome (another project Red Hat has their hooks in deep) to any other POSIX.

[asdf]

Also systemd is the svchost.exe for Linux

Title says it all.

[asdf]

Re: Also systemd is the svchost.exe for Linux

Systemd and the rest of the Freedesktop.borg is basically making Linux windows lite. Honestly I don't like it but have accepted it as Red Hat write a lot more code than I do. It does play much better on most hardware for non server roles than say FreeBSD (laptop suspend and resume good luck with that one) and Linux one killer feature for many home users is Steam which runs like shit emulated on FreeBSD. More and more it just works even for Grandma. That said I still do my banking using OpenBSD and do what I can at work to discourage its use in mission critical server roles (fsck SELinux also which exists to silently fsck you over instead of the bad guys). POSIX is all but dead with proprietary UNIX dead. Sigh.

[Aaron Kulkis]

Re: Also systemd is the svchost.exe for Linux

Sad, but true. RedHat and Shuttleworth are basically trying to destroy any non-commercial Linux distros.

[John Hughes]

Re: Also systemd is the svchost.exe for Linux

Title says that you don't understand what systemd is.

Please give one feature that is the same between svchost.exe and systemd.

[asdf]

Re: Also systemd is the svchost.exe for Linux

>Please give one feature that is the same between svchost.exe and systemd.

Written by someone much more elegant than me - http://www.infoworld.com/article/2608798/data-center/systemd--harbinger-of-the-linux-apocalypse.html . Basically its less about features and more about similarity in design and philosphy. The apocalypse came and still kind of sucks but far less than using the spyware pretending to be an OS that is Win10.

[John Hughes]

Re: Also systemd is the svchost.exe for Linux

And, if you read that screed you find that the similarity is "I don't like systemd, svchost is bad, therefore they are the same":

While systemd has succeeded in its original goals, it's not stopping there. systemd is becoming the Svchost of Linux -- which I don't think most Linux folks want.

A totally unsupported fact-free assertion.

What is the similarity of design between systemd and svchost.exe?

[asdf]

Re: Also systemd is the svchost.exe for Linux

>What is the similarity of design (and philosophy) between systemd and svchost.exe?

Sorry in advance for length. Stolen from http://forums.funtoo.org/topic/626-my-2-cents-on-systemd/page-5 but hits my points better than I could.

"It's simple really: systemd is wrong for Linux.

It may be right for something else, but not (default) Linux.

It violates the "UNIX Philosophy", which is best summarized by the famous quote from the inventor of the UNIX-pipe, McIlroy:

Quote

This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

This is important for very many reasons.

If one non-critical functions fails, it should not mean that the entire system becomes unusable as it has been on Windows where svchost.exe is used to run almost any arbitrary process and each of those svchost.exe processes can "host" several sub-functionalities. This results in that if any of those sub-functionalities "goes nuts", even if it's one that the user does not care about at all, the entire process with all its hosted sub-functionality is immediately affected. Also made obvious by the svchost.exe example is how it makes granular permissions management impossible even with third party tools like anti-virus and firewalls as if you have even ONE svchost.exe sub-functionality requiring network access to do its job, you must grant network access to the entire process and thus to everything else hosted by the same binary and this can lead to very undesirable security implications.

I use svchost.exe as the example because we Linux- (and UNIX- in general) users used to laugh at Windows' poor design in this regard for these reasons... but now when Windows is moving more and more away from this design, Linux is moving to it.

What's even worse is that there used to be several alternatives to chose from regarding system init provider, but now there are only two main ones and one that is being migrated away from, so if any major flaw is discovered in for example systemd, there is now effectively only ONE choice left.

With software now increasingly being made specifically designed for systemd, they build bi-directional dependencies so that the user can not really choose individual components anymore, which again can cause very bad security results as well as very much waste in system resources.

Imagine for example if there is a bug that causes the boot process to take half an hour each time using systemd and OpenRC can't be used because the core functionality of the system specifically depends on systemd... This can cause very expensive fines for corporations with Service Level Agreements to honor.

The migration to systemd results in user-unfriendly, bloated, unnecessarily restricted and potentially very costly systems.

It could be AN option, but should definitely not become the ONLY option as it is becoming now.

If you want a Windows/Mac-like system where the user is put out of control through the assumption that the programmers will be able to predict every usage scenario and never write flawed code so no options are needed, then it should be considered as an option.

I could go on, but I fear I have already passed the wall-of-text/TL;DR-threshold.

P.S.: The example scenarios in this post are all ones that I have personally encountered, so not at all hypothetical."

[asdf]

Re: Also systemd is the svchost.exe for Linux

>If one non-critical functions fails, it should not mean that the entire system becomes unusable as it has been on Windows where svchost.exe is used to run almost any arbitrary process and each of those svchost.exe processes can "host" several sub-functionalities. (ie - Grouping multiple services into a single process conserves computing resources However, if one of the services causes an unhandled exception, the entire process may crash.)

And this is the crux of his argument (though I admit spelled out implicitly). PID 1 is special (it can't fail or your system shits itself) and should being doing as little as possible not as much as is possible. The following link shows what can go wrong with having a kitchen sink PID 1 - http://blog.darknedgy.net/technology/2015/10/11/0/

[asdf]

Re: Also systemd is the svchost.exe for Linux

Credit due to http://ewontfix.com/14/ - for the idea Do away with everything special about pid 1 by making pid 1 do nothing but start the real init script and then just reap zombies.

[asdf]

Re: Also systemd is the svchost.exe for Linux

In fact http://ewontfix.com/14/ for the high level overview and http://blog.darknedgy.net/technology/2015/10/11/0/ for the down and dirty details do more to explain why systemd design is fundamentally broken than almost anything out there.

[asdf]

Re: Also systemd is the svchost.exe for Linux

There you go John Hughes satisfied? Took a fair amount of work but I still stand by statement. Assuming no other post from you at this point so consider this the mic drop.

[Anonymous Coward]

@John Hughes - Re: Also systemd is the svchost.exe for Linux

Erm, feature creep for example ?

[John Hughes]

Specifically, my biggest gripe is the lack of feedback/console logging after issuing a service start/stop/restart/reload action.

It gives the same or more feedback as sysvinit.

[cyberdemon]

"systemd isn't just popular because of Red Hat...."

Actually, it's popular because of the so-called "Linux Standards Base", which was a circlejerk between RedHat, Intel, and Microsoft.

The intention was to create "binary-compatibility" within Linux, so that proprietary, closed-source software (and, presumably, malware) would have an easier time. It's completely contrary to what GNU are trying to do, and for this reason, Debian was late (or not invited) to the party.

LSB standardised a lot of things, and it all came from RedHat.

This is why, for example, that MeeGo (which is the abomination that replaced Nokia's Maemo OS) went with RPM instead of DPKG (deb/apt) for package-management, because RPM is specified by the LSB.

That doesn't mean that RPM/Yum is better than DPKG/Apt. It just got standardised by the LSB.

Consequently, Debian and Ubuntu are "non-compliant" until they adopt RPM format. They are fudging it with 'Alien', but eventually Debian will die thanks to the LSB.

Personally, I would love to go back to a time before Systemd. It has given me nothing but problems.

I also, for a while, used Trinity - a backport of KDE 3.5 onto QT4. I stopped using it when KDE4 became stable and usable.

Now that Plasma5 is being forced down my throat, with a shedload of bugs, I would love a backport of KDE4!

Next you'll be telling me to move from X11 to Wayland.

[kwhitefoot]

Re: "systemd isn't just popular because of Red Hat...."

>This is why, for example, that MeeGo (which is the abomination that replaced Nokia's Maemo OS) went with RPM instead of DPKG (deb/apt) for package-management, because RPM is specified by the LSB.

Pardon?

My N9 runs Meego and applications are installed from .deb files. Have I missed something fundamental about RPM and dpkg?

[HieronymusBloggs]

"It's popular because it works better than anything else."

For you, perhaps. It doesn't necessarily follow that it works better for everyone else. Linux server installations still outnumber desktops and laptops by a long shot. How popular is it with server admins? I suspect not so popular.

[Anonymous Coward]

Nokia 5110

As a matter of fact, I do still use a Nokia phone.

I never bought a smart phone, and now prices are tumbling while hardware specs have flat-lined.

But you know what, I'm going to put it off a little longer, because I feel smartphones are not quite "there yet".

[Anonymous Coward]

http://without-systemd.org/wiki/index.php?title=Arguments_against_systemd&oldid=778

[Aaron Kulkis]

Regarding Lennart

The man destroys more value than what he creates. He breaks things, and then blames everyone but himself. In short, he is nothing less than a vandal.

[Aaron Kulkis]

Yes, because when a well-understood, imperfect, but robust system is FORCIBLY replaced with a brittle, fragile, overly complicated, MORE IMPERFECT system which, which immediately commandeers cgroups for itself so that cgroups is unavailable for apps, and which fails to even meet a single one of its publicly announced design goals, run by a software team whose answer to anything is "you people suck!" and "you haven't read the 1000 pages of documentation" and "I'm not breaking things --- EVERYONE ELSE'S PROGRAMS ARE BROKEN! NOT MINE! NEENER NEENER NEENER!", yes, indeed, the response IS predictable.

Why would the response to this steaming pile of s h i t be any different? Why SHOULD it be any different.

A replacement for SysVInit should be an IMPROVEMENT, not shoehorning some Frankenstein's Monster sort of C:\Windows\svchost.exe into Linux

If you can't see the myriad problems with systemd, and don't understand how systemd is a step backwards on the level of going to the pre-MULTICS days of OS/360, then you're either too wet behind the ears to appreciate what's actually going on, or too stupid to ever comprehend what's really going on.

[Stites]

In days of yore

In days of yore I helped develop the initial version of OS/360. systemd

corresponds to the portion of OS/360 known as the Master Scheduler. All of the

rest of OS/360 had to conform to the specs laid down by the Master Scheduler

just as systemd tries to force the rest of GNU/Linux to conform to the systemd

specs. The difference is that the Master Scheduler was designed before the rest

of OS/360 and systemd is an add-on afterthought. That is why systemd is such a

design mess and why the systemd designers rail at the stupidity of

other GNU/Linux designers for not anticipating the systemd specs 10 years ago.

----------------------------------

Steve Stites

[Ian 55]

"because it works better than anything else"

Until it doesn't, when you are completely in the shit.

[gobaskof]

Init freedom

You have "init freedom" as demonstrated by your new distro, easily created with your favourite init system. Other people exercise their "init freedom" by choosing to use systemd. And others are aware they have an "init freedom" but are unsure how best to use it so they stuck to what they knew.

In short, some people didn't like a new feature so they used the free software to make a version they were comfortable with. This is perfect, however much you do or don't give a shite about systemd, you have to love that people have the tools to do what they want.

Not sure it is "news", but then El Reg has the freedom to decide what it calls news, not I.

[Anonymous Coward]

Re: Init freedom

Not sure it is "news"

Well, yes, but your comment wasn't a summary of the article.

The "news" aspect that you think is missing, was that they've released a beta version. The other fluff is for people who haven't kept up with these things.

[Bronek Kozicki]

Re: Init freedom

Well, to me it is news - I regularly give money to Devuan and it is good to see the fruit of this work.

[Sam Liddicott]

Re: Init freedom

I also regularly give a pittance to Devuan. It all adds up to the cost of a Windows DVD, so I'm glad they are succeeding.

[Doctor Syntax]

Re: Init freedom

"In short, some people didn't like a new feature so they used the free software to make a version they were comfortable with. This is perfect, however much you do or don't give a shite about systemd, you have to love that people have the tools to do what they want."

My concern is that although they've been able to achieve this now there'll be a time when so much of the GNU/Linux userland assumes systemd is there that it becomes impracticable to build a distro without it.

My other concern is that the whole approach of the systemd/opendesktop people is to gradually convert what was a Unix-like OS into one which won't be. So those of us who used Linux because of what it was will be looking elsewhere.

[Bronek Kozicki]

Re: Init freedom

@Doctor Syntax - exactly.

[Mike Moyle]

Re: Init freedom

...Well, innit?

[John Hughes]

Re: Init freedom

Devuan claim that their system, which does not allow you to install systemd, gives more freedom than Debian, which allows you to install systemd, upstart or sysvinit.

[ElReg!comments!Pierre]

Re: Init freedom

> Devuan claim that their system, which does not allow you to install systemd

Blatant lie. Nothing in Devuan prevents you from installing systemd. It just allows you to install a system _without_ systemd if you so wish, which (second blatant lie) Debian doesn't allow you to do anymore. udisk2 without systemd in Debian, for example?

Oh, you CAN install sysvinit or anything else in Debian. You just can't NOT install systemd. Anyone pretending otherwise is either a chill, or without any tech gorm.

[ElReg!comments!Pierre]

Re: Init freedom

Disclaimer: my beard is much greyer than I'd wish, thank you for asking.

[Tom 7]

Choice

you've got to love it. OK!

Will be trying this out on my new laptop - systemd would have been nice 10 years ago but I cant see much need for a system that is ready and waiting while the wlan is still trying to work out a little number.

[Tom Chiverton 1]

systemd is many things, but a bootloader ain't one

[NB]

https://wiki.archlinux.org/index.php/Systemd-boot

O rly?

[Anonymous Coward]

@Tom Chiverton 1

Well, it does contain systemd-boot now... Seriously though, no it is not. Also, technically speaking systemd-boot is a boot manager, not a bootloader.

[Steve Graham]

Re: @Tom Chiverton 1

I wouldn't call systemd a "boot manager". A boot manager should piss off once the system is booted, not carry on running, pretending to be a substitute operating system.

[Michael Wojcik]

Re: @Tom Chiverton 1

I wouldn't call systemd a "boot manager". A boot manager should piss off once the system is booted, not carry on running, pretending to be a substitute operating system.

Agreed. The proper term for such a thing is "MS-DOS".

[Doctor Syntax]

"systemd is many things"

Too many.

[hplasm]

nice-

is another thing that systemd is not..

[jake]

As a long-term (just under 23 years) Slackware user ...

... I am evaluating Devuan out of curiosity. So far, it looks like a good option :-)

[Anonymous Coward]

"Versions for the Raspberry Pi, Banana Pi and AMD64 are on offer, making it something of a niche offering."

Eh?

Doesn't someone know what AMD64 is?

[Anonymous Coward]

Given that some of the distros have dropped the 32 bit version of AMD64, (Because who'd want that?) it's quite amusing.

[Anonymous Coward]

Maybe Vulture South runs on i486s or those TV-tube-in-a-plastic-bubble iMacs? None of this newfangled 64bitness down under?

[nagyeger]

It must be niche

it doesn't run on my old 286.

[Tom 7]

Re: It must be niche

ELKS may be updated soon: https://github.com/jbruchon/elks

[Fibbles]

The more articles from Simon Sharwood that I read, the more I realise he knows very little about technology.

[nematoad]

Overload?

I'm getting a 502 Bad Gateway error when I go and try to get the torrent from the site.

Could this be a result of too much traffic?

Still, I'll try again later, it might be back then.

Popular, eh?

[Flocke Kroes]

systemd is not a boot loader

The sequence is firmware loads (part of) the boot loader, which is usually grub for x86 or U-Boot for everything else. The boot loader - using nothing but itself and some probably broken firmware - loads the rest of itself, then the kernel (and possibly a small disk image). The kernel mounts the root file system, and then runs something as process 1. That was usually sysvinit, or - if you are recovering a badly confused machine - bash. Systemd is a replacement for sysvinit.

When process 1 starts, it has the complete kernel and any modules the kernel requires, the root file system, and probably a few pseudo file systems like /dev. Sys[vt][ei][nm][di]t? starts almost everything else: all the permanently attached file systems, any strange configuration, various demons, login for each terminal and one of the gui login programs. When a process dies, its parent gets sent a signal. If the parent is dead, that signal goes to process 1. While running, systemd/sysvinit restarts any dead demons. During shutdown, sysvinit/systemd kills all the processes and unmounts all the file systems.

This makes sys{vinit,temd} very different from a boot loader - which self destructed when it handed control to the kernel within a few seconds of power on.

BTW: Debian architecture names make sense to techies, but not to computer illiterates. AMD64 is almost certainly what your Intel processor is pretending to be when it is not pretending to be an ancient pentium for 32-bit Windows users. It is the most common architecture on the planet. Raspberry pi is odd. The earliest ones are not quite armhf. The newest ones are ARM64, and the ones in the middle are armhf. Supporting raspberry pi means armhf with restrictive compiler flags. Banana pi is full armhf, and anything armhf should be able to use the same repository.

If we go through popcon in order of architecture, fist is AMD64. Second is i386 (probably AMD64 compatible machines, although some will be ancient / odd). Raspberry pi is not included in popcon, but is probably next in real life, then comes armel (arm older than the oldest pi), powerpc (old converted macs?), armhf (banana pi, and a pile of other arm based small cheap computers). All the remaining architectures supported by debian together are not as common as armhf. Devuan have chosen about three and a half of the most popular architectures. The most of the others are too old to run Debian Jessie anyway, have bigger problems than hatred of systemd if the maintainers want to upgrade.

[EvadingGrid]

One Man Distro !

If you are like me, and cook your own tiny micro distro - and by that I mean actually compile your own base system, not just re-brand some body else’s work . . . take a wild guess at how enthused people like me are about the pointless extra work load of dealing with system-d . . .

[Steve Graham]

News?

This is news to me, in that I migrated my repository settings to Devuan months ago, with no ill effects.

(On this machine, I seem to have 90 Devuan packages out of 2795 installed, but obviously that ratio will increase as I update them.)

[fortran]

bsd and systemd

Concensus I've seen, has it that BSD cannot run systemd. Lately on Debian/stable, I've noticed that bsdutils is not being upgraded. The reason? On Debian/stable, bsdutils now depends on systemd! I've downloaded the source package, and you can compile it with no inclusion of systemd.

I will be moving to Devuan. Including my failed attempt at understanding Gentoo.

[Justin Pasher]

Re: bsd and systemd

I have bsdutils installed on a Debian Jessie system running sysvinit. The package depends on libsystemd0, not the full systemd init system. In fact, running sysvinit is officially support in Debian Jessie. You just have to do some work yourself.

https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#systemd-upgrade-default-init-system

Whether this will still be the case when Debian Stretch becomes stable next year is anybody's guess.

[Anonymous Coward]

Bootloader?

SystemD has its own bootloader now? Or is that a mistake in the article.

[John Hughes]

Re: Bootloader?

Both, it's a mistake in the article -- systemd isn't a bootloader, and yes, systemd has it's own EFI bootloader, the package formerly known as gummiboot.

[td0s]

SystemD was imposed on the linux community by redhat and the same "engineer" who gave us the joy of pulse audio. I am a slackware user and I remember using pulse audio in the early days just after it was renamed from polyp audio and it was a mess - the response to my mailing list request for support was "thats a problem with alsa drivers take it up with them". We recently got pulse audio (7 years later) and it seems reasonably stable, I use centos at work and I have yet to see anything about systemD which is an improvement from my point of view as an administrator - an opaque log, "extras" needed for common pieces of software all to fix something which is not broken.

You can keep your systemD tyvm

[Chris King]

From http://alien.slackbook.org/blog/pulseaudio-comes-to-slackware-current-beta/

Yes, some people will be opiniated. We invited the Devil into our house and stuff. Well, PulseAudio is not maintained by Lennart anymore, and saner people took the helm. We expect no big mess as a result, just a learning curve to understand the new sound configuration. And truthfully, we were left no choice. The alternative would have been to say bye-bye to bluetooth in Slackware because already, major pieces of software are dropping or preparing to drop support the old and incompatible BlueZ 4.x API.

Note: Slackware is NOT going to add systemd. It’s too controversial and there is no need. Your sleep will be sound now.

[Doctor Syntax]

"The alternative would have been to say bye-bye to bluetooth in Slackware"

Pulseaudio incorporated Bluetooth?

[Chris King]

"Pulseaudio incorporated Bluetooth?"

No, BlueZ 5 dropped ALSA support.

[John Brown (no body)]

"Pulseaudio incorporated Bluetooth?"

No, BlueZ 5 dropped ALSA support.

And we have the same scenario to look "forward" to with systemd as it gets it's claws into ever more of the system.

[TJ1]

Problems with Systemd and Pulseaudio

I find the technical design, configuration flexibility, single syntax, and tooling for analysing configuration and actions to be far superior to the alternatives especially on more complex systems.

I say that as someone who was originally set against accepting systemd at all and resisted it for a long time.

I've come to discover that in the main the problems attributed to systemd are more due to distributions adopting it before it is ready to take over the duties of other daemons, in that it hadn't reached feature-equivalence with the disparate services it extinguished.

Pulseaudio suffered the same way - it was introduced by maintainers before its features were complete for many mainstream use-cases, even though it was doing more sophisticated things without user intervention (I recall one such being automatic up/down sampling to match bit-rates for sources and sinks). In the case of Pulseaudio many people tend to forget that before it arrived the ALSA tooling it replaced didn't support multiple applications using the sound output at the same time, and that issue was a very big cause of desktop user bug reports and complaints.

With systemd one example is not supporting key-files for encrypted file-systems but it replaces the working cryptsetup scripts. That's something the distro maintainers could avoid by not including the systemd-cryptsetup service.

The reasoning behind the missing feature is technical perfection. There have been several pushes to add functionality but Lennart has held out against band-aid solutions and wants a once-and-for-all design which utilizes the kernel key-ring for handling the encryption keys.

So part of the problem is systemd-cryptsetup not implementing the full set of what I'd call 'standard' features but the distro maintainers enabling it, therefore causing regressions in user experience.

It is possible for distro maintainers to build only selected modules of systemd so that where features are not yet comparable the original service could remain, but mostly they don't do that.

[td0s]

Re: Problems with Systemd and Pulseaudio

Yes, to be fair Lennart is a good engineer, I just don't think his approach (on systemD) is what people in the (my) community want. ASLA isn't great at all tasks, but there are other sound systems available for Linux which can provide the missing functionality - notably JACK which seems to have been treated as an afterthough by pulse audio.

I guess that systemD will improve over time and eventually we will have no choice but to use it as the software will start to depend on it - which is what bothers me - exactly the same as pulse audio which we now have because of broken bluez we will end up having to use systemD (unless we use BSD)

[Anonymous Coward]

Re: Problems with Systemd and Pulseaudio

PulseAudio never fails to fuck things up. Currently it's giving me STATIC - loud, obnoxious clipping noise - intermittently of course. On a brand new Mint 17.3 install, I spent an hour troubleshooting HDMI audio, only to discover Pulse actually wasn't starting automatically... what a total frickin' curveball after 5+ years of struggling to STOP the damn thing, lol. On the upside, now it cooperates with JACK just fine, at least with the help of KXStudio and Cadence, for now. I'm sure that's already broken in newer distros, though.

For all the effort sunk into the PulseAudio layer-upon-layer architecture, it would've been better to start over and build what ALSA was meant to be, a unified sound architecture with software mixing and optional JACK-style synchronous low-latency I/O.

[Jason Bloomberg]

Raspberry Pi

If they can churn out a 64-bit Devuan version for the Pi 3B, that could put the proverbial cat amongst the pigeons.

Though there might be a danger that a Pi 3B will burst into flames running a 64-bit OS.

[oldcoder]

Re: Raspberry Pi

I understand the P3 is a 64 bit system.

Shouldn't be any flames... unless you overclock it.

[Tom 7]

Re: Raspberry Pi

The P3 is a 64 bit system but the raspbian for it is currently 32bit. Not sure how much faster/more power it may take running a 64 bit version but I'd guess its could be a bit more than the 32bit and may run a bit warmer simply because the code will be a lot more optimised for the machine. I can get mine up to 70C (assuming I'm looking at the right thing) by doing some very silly maths so a heatsink could be required.

[Anonymous Coward]

Nice to see progress

It's nice to see progress on Devuan... but I never had high hopes. There are so many things wrong with Debian, and with the Linux ecosystem in general. Package systems, goofy packaging practices, the audio clusterfuck, X windows (man, I hated that shit in the 90s, and it has not improved much)... systemd is merely the latest trainwreck.

Still, if Devuan keeps Linux competitive with FreeBSD, and possibly serves as a new base for overlay distros like Mint, I guess it's a good thing.

[jerky_rs]

personally i think SystemD is overally complicated for what it achieves, sure it boots faster but on a server all i care about is that it comes up and things are simple. With Systemd there is no clear detail of how and what starts unless you reverse targets out of the systemd directory which is ridiculous as compared to "chkconfig --list | grep 3:on" . If we really needed something to start up different processes and manage(and dependencies) them in a simple way they should have just used SupervisorD and include files. Sadly SystemD is much more then what it needs to be.

This is another great example of why systemd is not very good

tcp6 0 0 :::9090 :::* LISTEN 1/systemd

Err so something with PID 1 is listening on 9090, wonder what that is? Start fgrep your systemd directory and hopefully it returns something with 9090 (happens to be cockpit socket..)

As an RHCE for over 10 years i think this is the biggest mistake Redhat has ever made, but i guess we must learn to love systemd. Its in my opinion as bad or worse then firewalld or networmanager both of which have no business being on a server. (desktop sure why not).

[Anonymous Coward]

Boots faster. Uh huh

Nope, it doesn't boot faster on my system. It's noticeably slower than Upstart.

Also restarting services is really slow. nginx used to restart instantly; with systemd it takes about 8 seconds.

[TJ1]

@jerky_rs read the documentation

systemctl status --state active

systemctl list-sockets

systemctl list-dependencies ssh.service {--before | --after}

journalctl -u ssh.service

systemd-analyze {critical-chain | blame}

systemd-analyze dump

As an employer of admins for over 30 years if those admins can't be bothered to read the documentation, in man-pages or other forms, then I consider them remiss in the *most* important skill any admin should be using constantly.

When something isn't familiar you read the documentation, explore the commands themselves, do some lab-work, and become familiar with the tools.

systemd in particular has provided some excellent consistent tooling for gaining insights into service state, configuration, dependencies, resources and more.

[Tom 7]

Re: @jerky_rs read the documentation

Read the documentation? Love to have time to do that. That also works really well when you stick to the original Unix ideology but having to read 30 odd documents to try and get a clue to why something is failing is too much for most. In fact I can safely say I've spent more time trying to sort out a systemd problem than it has saved me in boot time by a several orders of magnitude.

[Bronek Kozicki]

Re: @jerky_rs read the documentation

Right, systemd init takes the role of inetd. As "an employer of admins for over 30 years", now please explain why do you think this is actually good idea

[Aaron Kulkis]

Re: @jerky_rs read the documentation

Oh, B. S.

All of the necessary documentation for SysVInit contained in a 2-page document, which is clear, concise, and easy to understand in all of its nuances, because SysVInit is the epitome of elegance. The systemd documentation runs into the hundreds of pages, and is anything but clear and concise.

I've been using Unix since 1983, WROTE a unix-like operating system in a matter of weeks in a senior-class assignment, and have been administrating Unix and Linux machines since the early 1990's. When I say systemd is an over-complicated pile of rubbish, it's NOT due to an inability to comprehend, it's due to the fact that Poettering is not nearly as talented as he believes himself to be, and thinks that "more lines of code" == "better code" when, in fact, the exact opposite is generally true.

[rnturn]

Re: @jerky_rs read the documentation

I cannot recall ever having a sysvinit-based system toss me into single user mode because a filesystem mount took "too long" due to a forced fsck. Sure, I might have had a filesystem be unavailable for a time while a mount-time fsck completed but I never had the "entire system" be unavailable while I was running that fsck by hand. (In a pinch, I've commented out the filesystem entry in /etc/fstab, rebooted the system, and hoped systemd get confused by another big filesystem needing an fsck.) I'm sure there's a means of extending the time-out that systemctl imposes on mounts but I'll undoubtedly get burned again unless I make it ten times longer. (And will even /that/ be long enough? I haven't sat there with a stopwatch timing an fsck of a multi-terabyte filesystem.)

[Tom 64]

"tcp6 0 0 :::9090 :::* LISTEN 1/systemd"

That is pretty horrible. I've done a bit of network programming and one of the things I've learned is that you should never use your master process to talk to the network.

I'm not sure what will happen if process 1 blows up on Linux, but I AM sure its not what you want happening.

[John Hughes]

Re: "tcp6 0 0 :::9090 :::* LISTEN 1/systemd"

I've done a bit of network programming and one of the things I've learned is that you should never use your master process to talk to the network.M

Then you'll be happy with systemd -- the master process doesn't talk to the network, it only listens to it.

[Aaron Kulkis]

Systemd boots up faster? Since when.

That was the original reason that systemd was sold to the community -- that it would boot up faster... which has ALWAYS been a specious argument -- since NOBODY that I've ever heard of sits around rebooting their computer all day. If I reboot more than once/month, then something is seriously wrong -- and that's usually hardware. In any event, systemd has utterly FAILED in that stated objective -- I've never seen a systemd machine boot up faster than an init machine when the two are of comparable hardware and installed software with similar sets of deamons fired up.

On the other hand, sytemd has replaced a simple, robust system with some sort of brittle and fragile ball of code that's the software equivalent of a sculpture imitating and M.C. Escer painting... it's only works right when viewed from EXACTLY the right angle, otherwise, it's a f u c k i n g disaster, and even then, it takes up FAR FAR FAR more room than it should, And the binary system logging STILL sucks, forcing even more waste to run a second, text-only syslog so that you can have a system log that's reliable enough to count on when everything is falling to s h i t.

[Justin Clift]

Download site is super slow, use the .torrent file

The download site seems to be having capacity issues at the moment. There is a .torrent file available (on the download site, oops!):

https://files.devuan.org/devuan_jessie_1.0.0-beta.torrent

A working magnet hash instead is this, if that helps: 9b0fa597ab8bdd89a57434876947dbe378a79aad

The torrent download is 10.55GB, containing:

• SHA256SUMS (2.33 kB)
• SHA256SUMS.asc (1.51 kB)
• devuan_jessie_1.0.0-beta_amd64_CD.iso (675.3 MB)
• devuan_jessie_1.0.0-beta_amd64_CD.list.gz (13.57 kB)
• devuan_jessie_1.0.0-beta_amd64_DVD.iso (4.69 GB)
• devuan_jessie_1.0.0-beta_amd64_DVD.list.gz (42.59 kB)
• devuan_jessie_1.0.0-beta_amd64_NETINST.iso (222.3 MB)
• devuan_jessie_1.0.0-beta_amd64_NETINST.list.gz (4.53 kB)
• devuan_jessie_1.0.0-beta_amd64_cloud.qcow2 (727.7 MB)
• devuan_jessie_1.0.0-beta_amd64_opennebula.qcow2 (718.6 MB)
• devuan_jessie_1.0.0-beta_amd64_vagrant.box (683.6 MB)
• devuan_jessie_1.0.0-beta_armhf_bananapi.img.xz (194.1 MB)
• devuan_jessie_1.0.0-beta_armhf_bananapro.img.xz (194.0 MB)
• devuan_jessie_1.0.0-beta_armhf_beagleboneblack.img.xz (288.3 MB)
• devuan_jessie_1.0.0-beta_armhf_chromeacer.img.xz (278.6 MB)
• devuan_jessie_1.0.0-beta_armhf_cubieboard2.img.xz (261.1 MB)
• devuan_jessie_1.0.0-beta_armhf_cubietruck.img.xz (261.9 MB)
• devuan_jessie_1.0.0-beta_armhf_odroidxu.img.xz (210.7 MB)
• devuan_jessie_1.0.0-beta_armhf_raspi2.img.xz (203.6 MB)
• devuan_jessie_1.0.0-beta_i386_CD.iso (678.4 MB)
• devuan_jessie_1.0.0-beta_i386_CD.list.gz (12.77 kB)
• devuan_jessie_1.0.0-beta_i386_NETINST.iso (264.2 MB)
• devuan_jessie_1.0.0-beta_i386_NETINST.list.gz (4.74 kB)

[Anonymous Coward]

Re: Download site is super slow, use the .torrent file

Thanks for the link. Seems to be working very well now. I just torrented the whole 10.55GB in 27 minutes and am seeded it now. Averaged about 6.5MB/sec. That's pretty damned good over wifi to my service provider modem.

[Anonymous Coward]

Finally!

Yep, my Nan positively demanded, demanded I tell you, a distro without systemd. And rightly so.,

[Tom 7]

Re: Finally!

You should listen to your Nan. When you get to her age you too will squirm with embarrassment at how impetuous and wrong you were as a young turk adopting things that seemed so cool with the blinders of youth.

[davcefai]

Poettering Free Systems.

First we had Pulseaudio. When googling solutions to problems I almost always came across a post by Poettering raving about how wonderful Pulseaudio was and it didn't need fixing.

Pulseaudio went to the great bitbucket in the sky and my systems stabilised again.

Until SystemD. When I allowed SystemD on board it was like going back to the awful Windows days. Bugs, problems, opaqueness and no fixes.

Now I'm back to SysVinit and no longer have frustrating mornings getting the PCs to boot properly. The sad thing is that I cannot yet uninstall the the SystemD mess 'cos too many packages have dependencies on it.

If Debian stick with SystemD then, sadly, it's bye bye Debian.

[Sloppy Crapmonster]

Of the 90 Debian servers I'm responsible for, I've replaced systemd on zero of them. It's just not an issue. I'm not saying it's not an issue for *anyone*, but I personally have no problem with it. And it makes my laptop start up and shut down *really fucking fast*.

[jake]

@Sloppy Crapmonster

"Of the 90 Debian servers I'm responsible for, I've replaced systemd on zero of them. It's just not an issue. I'm not saying it's not an issue for *anyone*, but I personally have no problem with it. And it makes my laptop start up and shut down *really fucking fast*."

Uh ... your 90 Debian servers need to be restarted regularly, so you need "really fucking fast" restart times? Methinks you need to actually understand the underlying system ...

[Aaron Kulkis]

Consider yourself lucky.

Systemd only works properly if you don't have a need to customize anything. As soon as you do, systemd tries to hijack the system, and usually ends up shooting hostages resulting in a huge bloody mess.

[Bronek Kozicki]

Re: Consider yourself lucky.

... which is why Devuan is such a bloody good idea - simply do not let the f*er in. At all. As in "you have a choice of init, as long as it is not actively damaging the whole system". And that's why I support this distribution.

[rnturn]

Lucky you...

I haven't seen an appreciable shortening of the boot process after updating my laptop to a release that's full-on systemd. A few seconds less -- maybe -- but it's not as though I was timing my boots. (Does anyone?)

My understanding (please correct me if I'm wrong) was that systemd was intended to benefit the management of virtual machines by reducing boot times for those. Unfortunately for those folks who are /not/ running VMs, they're stuck with systemd anyway.

[Anonymous Coward]

OT - pulseaudio rant

it seems some re-engineering is a case of 'art for arts sake' i don't know much about startup scripts et al, but hopefully the BSDs won't include any of this poettering-soft (i havent checked in on BSD for a few years by now), as if desktop Linux isn't already losing it's way.

lets not pollute desktop OS with more layers of flaky software, pulseaudio sucks big time, always has, probably always will, it's a mess, but it does mix audio streams, something the Android Guys have only just noticed, but why not just fix ALSA instead.

Several years ago (on Linux) i regularly played multiple stereo simultaneous audio streams from one computer and one soundcard, it played perfectly well using ALSA - using DMIX - if your soundcard had hardware mixing. If the code was that bad by then, then tidy ALSA and support it, and work on another replacement, not just layer another fudge over the top. it's a complete bodge.

While we're at it, name the damn pulseaudio functions for human beings too eh ?

Why are distro's so eager to adopt flaky software (and flll the OS with other crap) nowadays ?

yes, there's often a better way to do things, but at what cost, Linux used to suck a lot less years ago, before *buntu & poettering got their meathooks on it, every day BSD looks more like the way to go.

Of course, if you're really serious about audio production, you'll be using coreaudio instead..

[Anonymous Coward]

Re: OT - pulseaudio rant

> but hopefully the BSDs won't include any of this poettering-soft (i havent checked in on BSD for a few years by now)

Unfortunately some of the pollution is spreading. Not systemd or pulse, but I've seen some crap like Dbus even on fairly minimal FreeBSD servers.

[Citizen99]

Being a desktop workstation user, the 64-bit version of ExeGNUlinux

http://www.exegnulinux.net/downloads/jessie/

which uses Devuan, and comes with (xfce and) Trinity, the fork of KDE3, suits me very well.

[Jim 59]

Fixing a problem on wheezy:

- look in text file. See error message. Take action

Fixing a problem in jessie (systemd):

- your main challenge here is in finding the error messages in the first place. This will usually be more complex a task than either the underlying problem or the remedial actions needed to fix it. Often you will just give up and take a series of guesses as to what the problem might be. Your third or fourth guess will be correct and so after trailing a number of solutions, a fix is at hand. Rather like trouble shooting Windows.

Got no axe to grind, just hate bad engineering.

[Bodge99]

If you wish to try the testing release...

Replace your /etc/apt/sources.list with this:

# This includes the non-free repositories

deb http://packages.devuan.org/merged/ ascii main contrib non-free

deb-src http://packages.devuan.org/merged/ ascii main contrib non-free

deb http://packages.devuan.org/merged/ ascii-security main contrib non-free

deb-src http://packages.devuan.org/merged/ ascii-security main contrib non-free

deb http://packages.devuan.org/merged/ ascii-updates main contrib non-free

deb-src http://packages.devuan.org/merged/ ascii-updates main contrib non-free

deb http://packages.devuan.org/merged/ ascii-backports main contrib non-free

deb http://packages.devuan.org/merged/ ceres main contrib non-free

# End

If you wish, add yourself to the sudoers group with

su

adduser <username> sudo

Logout & login again.

sudo apt-get update

sudo apt-get upgrade

sudo apt-get autoremove

sudo apt-get dist-upgrade

sudo apt-get autoremove

Now reboot to a systemd free system...

[crhylove]

Devuan is Awesome.

I built many, MANY debian servers in the last decade, and Debian 8 was unstable, crashed, used extra CPU/RAM, just a whole host of issues compared with 6/7.

I'm not sure it was systemd, but the binary log thing was too egregious for me to accept either. Plus, I'm familiar with Puttering's previous work, so....

I'm using Devuan exclusively now, and it is much closer in performance and stability to Debian 6/7 than Debian 8 has been for me. So, I highly recommend you give it a shot.

[freesoftware4lif]

Forum discussion on why ArchLinux moved to Systemd

Checkout a related discussion from r/archlinux:

https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/

2brainz comment in particular provides a good summary of why they thought it was a good move

https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/d3rhxlc

> I was the primary maintainer for Arch's init scripts for a while and I can share a couple of thoughts.