Systemd-Free Devuan 2.0 'ASCII' Officially Released (devuan.org)

"Dear Init Freedom Lovers..." begins the announcement at Devuan.org: We are happy to announce that Devuan GNU+Linux 2.0 ASCII Stable is finally available. Devuan is a GNU+Linux distribution committed to providing a universal, stable, dependable, free software operating system that uses and promotes alternatives to systemd and its components.

Devuan 2.0 ASCII runs on several architectures. Installer CD and DVD ISOs, as well as desktop-live and minimal-live ISOs, are available for i386 and amd64. Ready-to-use images can be downloaded for a number of ARM platforms and SOCs, including Raspberry Pi, BeagleBone, OrangePi, BananaPi, OLinuXino, Cubieboard, Nokia and Motorola mobile phones, and several Chromebooks, as well as for Virtualbox/QEMU/Vagrant. The Devuan 2.0 ASCII installer ISOs offer a variety of Desktop Environments including Xfce, KDE, MATE, Cinnamon, LXQt, with others available post-install. The expert install mode now offers a choice of either SysVinit or OpenRC as init system...

We would like to thank the entire Devuan community for the continued support, feedback, and collaboration....
The release notes include information on Devuan's new network of package repository mirrors, and they're also touting their "direct and easy upgrade paths" from Devuan Jessie, Debian Jessie and Debian Stretch.

Comments

This distro

[93 Escort Wagon]

... is a Poettering-Free Zone!

Re:No one cares

[greenwow]

Except for losing log messages and not providing a proper exit status. It's really hard to troubleshoot problems without log messages.

Re:Not universal until it includes systemd

[Bruce Perens]

I've had my own ideas about how to "better" engineer Devuan, but there are so many things to do and so little Bruce. :-)

With respect, I think your argument is mooted by the fact that Debian itself exists and is a viable alternative if you want to load SystemD. However, it is entirely possible for you to create what you believe is missing in Devuan, and provide it. You can ignore the fact that such a thing would be more for a ritual definition of universality than for anyone to practically use it - since you have stated your own belief that fulfilling that definition is important.

Thanks

Bruce

Re: Not universal until it includes systemd

[lkcl]

Thanks for the bit on mother Theresa. You seem to have your brains together so can you explain what the problems with ststemd are?

caveat: my brain is known to be made of mush, sometimes. as in, some form of dyslexia / delay means i get basic boolean logic wrong, ok? :)

* the first clue is this: https://cve.mitre.org/cgi-bin/... which contains 27 separate and distinct entries, three of them for this year alone. by contrast try searching for "sysvinit" and you get *ONE* entry dating back to 1999. you'd need to start searching for "bash" and start doing a bit more investigation (a bash search refers to several variants) to get a proper comparison.

* the systemd team have been known to ignore bugreports, closing them arbitrarily. not just once but repeatedly. i've seen posts made by people on here which gave references. basically they don't listen to constructive feedback.

* the scope creep on systemd is very insidious and dangerous. there's no consultation about the impact of the changes being made: they're just blithely "handed out" and if you don't like it go fuck yourself is the general attitude. management of firewall rules, fstab, networking, process control: all these things are completely insane to be managed exclusively by PID 1. one mistake and your entire system is compromised (or falls over).

so basically it's down to abdication of responsibility of developers and users to a team that has repeatedly demonstrated a total lack of willingness to recognise and take seriously the responsibility of their role... or more to the point that the distro maintainers *CHOSE WITHOUT CONSULTATION* to forcibly abdicate responsibility on BEHALF of users, the maintenance and running of their system to systemd's developers. if you are not familiar with what happened with the debian "vote": systemd was the absolute worst and least-favoured choice by far and above... and absolutely no explanation as to why that vote was completely and utterly ignored has ever been given.

there are many many articles and examples of why systemd is an extremely dangerous *technical* choice, but mainly it's down to the fact that the users haven't been given any choice - right across the board - due to all major GNU/Linux distros swapping over all at the same time like a flock of birds / shoal of fish. try doing "apt-get --purge remove libsystemd1" and see what happens (or equivalent on fedora, or archlinux). that there *is* no choice is in itself a dangerous precedent (a monoculture).

basically it's really hard to describe.

Re: No one cares

[Bing Tsher E]

"You're not paying for this racoon we are setting loose in your kitchen, so you have no place to make demands of someone who is giving you a raccoon for free."

Re: No one cares

[Anonymous Coward]

Their product is crap of no value to me. I will ignore your whiny suggestion that I help improve it.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re: Not universal until it includes systemd

[mvdwege]

management of firewall rules, fstab, networking, process control: all these things are completely insane to be managed exclusively by PID 1.

Sorry, but if you don't understand why a service manager should know about which file systems are mounted and whether or not the network is up before starting services, you have absolutely no authority to talk about these things.

As for process control: that's been a badly implemented part of init since its very beginning, as the ultimate ancestor process on a *nix machine. That systemd in its role as init and cgroup manager allows more fine-grained process control is a good thing.

And firewalling isn't even handled by systemd. The closest thing is the IPAddressAllow directive in unit files, which is a direct re-implementation of tcpwrappers, not firewalling.

Re: Not universal until it includes systemd

[Barsteward]

"Uuuuuhhhh... Kinda need pick this one apart. They aren't managed by PID1:" - you are onto a loser there, the anti-systemd mob thinks everything in the systemd project is mandatory and runs PID1 - no amount of explanation will cure them of that.

Re:Not universal until it includes systemd

[Rosco P. Coltrane]

I've had my own ideas about how to "better" engineer Devuan, but there are so many things to do and so little Bruce. :-)

I've said for years that Bruce Perens is an insufferable narcissist with an ego the size of mount Everest. If that sentence doesn't convince you, I don't know what does...

Re: No one cares

[F.Ultra]

Neither claim which is true. No logs have ever been dropped by systemd and the exit on failure is because the daemon fails after systemd did it's thing and people not fully understanding how asynchronous starting works.

Re: No one cares

[F.Ultra]

But there is no evidence, just anonymous anecdotes from people who claim to have switched to BSD for ages ago but still seam to comment on every Linux article they find.

Re:No one cares

[F.Ultra]

They are talking about "systemctl start XXX" returning 0 when XXX fails to start. This is always due to XXX failing after it forks so systemctl does not see the failure before it has already done it's thing.

Lot's of the older sysv init scripts contains lots of pre-flight tests on daemons where the script writes knew that the daemon would fork first and look for configuration files etc later and then when the unit files where created these pre-flight checks where removed (but there is nothing that prevents a unit file from having pre-flight checks) by maintainers that didn't fully understand why these checks where there.

Re: Imagine this

[F.Ultra]

Since you pay a fixed price for the Red Hat support (with their subscription model). Wouldn't it be in RH:s best interest to keep the number of calls down in order to keep the profits up? Now if they would have charged per case then it would have been a completely different situation but they don't.

Re: No one cares

[drinkypoo]

"How do I know there is nothing better? All the major distros have adopted systemd. If there was a better alternative I'm sure they would adopt it."

Bollocks. They adopted it because it became a dependency of other software, because the devs of that software were lazy and/or incompetent, like gnome. All except redhat of course which did it deliberately to the rest of us.

Re: Not universal until it includes systemd

[Anonymous Coward]

and absolutely no explanation as to why that vote was completely and utterly ignored has ever been given.

After it became quite obvious that the NSA's selinux project was a little too obvious a vector for backdoors, an alternative method for introducing opaque, complex, unneeded, and bug riddled code as close to the kernel as possible was needed. Systemd is not so much a technical product as it is a social engineering one.

Re:No one cares

[emacs_abuser]

Agree completely.

I've been using a systemd system for years now. Not one problem related to systemd. Unless you call fast start up and shut down a problem. The old init scripts were a mess, each one slightly different with no easy way to tell what commands each one would accept, and no way to get something simple, like the human readable purpose of the script. Systemd is a big improvement, for some reason rejected by people that somehow feel empowered because they can hack startup/shutdown scripts.

Re: No one cares

[geoskd]

Too bad they had to make it so complicated to understand. It just worked before.

As someone who had to wring bootup performance out of server spinup instances, I can tell you that nothing about SysVInit or upstart "just worked". Getting them to spinup fast was an ugly mess. For many cases, this only had to be done once, but it was still a headache that nobody wanted or needed. Since the switch to systemd, startup times have been as fast or faster than before, and it requires zero maintenance on our part.

It should also be noted that hot swapping was a royal pain under the old architecture, and the code involved held many bugs related to the fact that the daemons that handled the hot swapping could not run as PID 1. This is the single biggest reason that systemd runs as PID 1, and hot swapping works a damn sight more reliably now, especially on more obscure hardware.

Early boot issues have always been a problem, and always will be. until you have enough OS in place to properly handle persistent media, there is no way to log anything, other than to keep the information in memory and hope there will be an opportunity to dump the data later. systemd has had little impact on this either way, and for the vast majority of users, early boot problems simply dont exist, or are a symptom of faulty/flaky hardware. If you are developing drivers for hardware that needs to spin up during early boot, then I will fully agree that you don't want systemd, but you should probably also have some specialty hardware (like a serial monitor) that gives you someplace to dump early boot diagnostics anyways.

For what it is worth, my experience with RAID devices has been that the controllers are mostly shit unless you are willing to drop 10k to get top of the line. Everything else tends to be under-tested junk that works with windows and nothing else. My last raid card from Dell fried all four hard drives attached to it when it failed.

Re: No one cares

[phantomfive]

The Unix philosophy is not "each piece does one thing." It's complex and you should understand it.

If I were designing it, the init system and the hot swapping system would completely separate, but the init system would call into the hot swapping system through a minimal interface when needed. That would give you maximal flexibility.