Devuan “ASCII” 2.0 Release Candidate is now available(dev1galaxy.org)
dev1galaxy.org
Devuan “ASCII” 2.0 Release Candidate is now available
https://dev1galaxy.org/viewtopic.php?id=2047
73 comments
Why they use "ASCII" for a distro release? This is so confusing name for people who don't know what Devuan is. I firstly thought some wierd guys created their own character encoding and claimed 2.0 version of ASCII.
As mentioned, the release codenames are those of minor planets. It was how the Devuan people chose to synchronize with "Jessie" when they forked, since there is an asteroid (discovered in 1979) with the same name as the Toy Story character, and then branch onto a new naming system.
* https://ssd.jpl.nasa.gov/sbdb.cgi?sstr=2003568
* https://ssd.jpl.nasa.gov/sbdb.cgi?sstr=10464
* https://devuan.org/os/releases
* https://ssd.jpl.nasa.gov/sbdb.cgi?sstr=2003568
* https://ssd.jpl.nasa.gov/sbdb.cgi?sstr=10464
* https://devuan.org/os/releases
That's like asking why use "Stretch" for a Debian release. Anyone who doesn't know what Debian is might think it's a new version of the Toy Story character it's named after. Linux distribution naming conventions are often weird, there's nothing new here.
Devuan aliases its releases using minor planet names as codenames.
Devuan is basically Debian without systemd.
While I still prefer to run Linux distributions with systemd (NixOS and Arch in particular), I'm increasingly worried about the complexity systemd brings in.
I like how clean and standardized the init process is now. I don't like the bloat prize we've paid, though. I've been stracing my workstation for a few days. Journald starts eating a ton of RAM, ~100 MB upon boot, and keeps growing.
I'm annoyed because systemd developers claim 100 MB is normal. It's not, that's my biggest process on startup. And on my other Arch machine it stays at 25 MB, and they have a long history of memory leaks.
While I still prefer to run Linux distributions with systemd (NixOS and Arch in particular), I'm increasingly worried about the complexity systemd brings in.
I like how clean and standardized the init process is now. I don't like the bloat prize we've paid, though. I've been stracing my workstation for a few days. Journald starts eating a ton of RAM, ~100 MB upon boot, and keeps growing.
I'm annoyed because systemd developers claim 100 MB is normal. It's not, that's my biggest process on startup. And on my other Arch machine it stays at 25 MB, and they have a long history of memory leaks.
> Journald starts eating a ton of RAM, ~100 MB upon boot, and keeps growing.
You must subtract shared from resident to determine how much memory has been "eaten".
Journald uses mmap() for random access within the journal files. These pages are accounted for as shared because they are file-backed and may be paged out by the kernel behind the scenes if memory is needed - they'll just be paged back in from the filesystem if accessed later by journald.
You must subtract shared from resident to determine how much memory has been "eaten".
Journald uses mmap() for random access within the journal files. These pages are accounted for as shared because they are file-backed and may be paged out by the kernel behind the scenes if memory is needed - they'll just be paged back in from the filesystem if accessed later by journald.
Systemd is still a mess.
I've currently one machine that hangs on reboots because systemd is unable to shut down some service and another that gets its journals corrupted periodically.
I've currently one machine that hangs on reboots because systemd is unable to shut down some service and another that gets its journals corrupted periodically.
see newnewpdro's comment.
I just built a headless armv7h system (using Arch Linux ARM) with 1GB of RAM, and after being up for 3 days running nginx, ssh, and some other bare services, the total RAM usage, for all applications, is 70-100MB. Systemd is complex, but it really doesn't seem to add a lot of resource drain for the power it give you... I'm happy with that tradeoff.
I just built a headless armv7h system (using Arch Linux ARM) with 1GB of RAM, and after being up for 3 days running nginx, ssh, and some other bare services, the total RAM usage, for all applications, is 70-100MB. Systemd is complex, but it really doesn't seem to add a lot of resource drain for the power it give you... I'm happy with that tradeoff.
Out of curiosity, to start nginx and sshd you need like 2 lines of shell code in a BSDish rc.conf - one for starting each service. Why do you think systemd bringing in 10s and 100s of megabytes of black magic binary code is a trade-off worth making, especially on a non-desktop without a need for reacting on up/down events of network interfaces?
Systemd isn't one component, so you'd be mistaken assuming everything in the systemd project is necessary to start a service. But second to that, I'm not sure why you think nginx_enable='YES' is fundamentally less opaque than an nginx.service file. Both are parsed by another application. As for why someone would make that 'trade-off' - I much prefer being able to add "Restart=on-failure" than using daemontools, and I don't have the luxury of working with one single distribution and remember the faff involved with initscripts differing between CentOS and Debian.
My reasons aside, I'd think a more sensible question would be "why would you actively avoid using the init system that's shipping by default on what constitutes at least 90% of the Linux server market when you're using Linux?". I don't think eyes equate to quality and stability, but I do think Red Hat, and SUSE, and Canonical and Oracle selling server solutions using it will.
My reasons aside, I'd think a more sensible question would be "why would you actively avoid using the init system that's shipping by default on what constitutes at least 90% of the Linux server market when you're using Linux?". I don't think eyes equate to quality and stability, but I do think Red Hat, and SUSE, and Canonical and Oracle selling server solutions using it will.
> I'm not sure why you think nginx_enable='YES' is fundamentally less opaque than an nginx.service file. Both are parsed by another application.
My guess: because the "another application" that parses nginx_enable=YES is a (rc) shell script instead of an ELF blob, so you can track its execution.
My guess: because the "another application" that parses nginx_enable=YES is a (rc) shell script instead of an ELF blob, so you can track its execution.
That is not actually true. It is of course parsed by a shell, not by a shell script, which is indeed an "ELF blob".
Moreover, that shell is, on some operating systems, only one of the parsers. OpenBSD, for example, introduced a rule a few versions ago that rc.conf is not shell script. It is a set of key=value assignments that can be written and read by other programs too, not just by a full shell parser and not requiring a shell script parser.
One such program is rcctl. Another is FreeBSD's sysrc.
Moreover, that shell is, on some operating systems, only one of the parsers. OpenBSD, for example, introduced a rule a few versions ago that rc.conf is not shell script. It is a set of key=value assignments that can be written and read by other programs too, not just by a full shell parser and not requiring a shell script parser.
One such program is rcctl. Another is FreeBSD's sysrc.
But do you need to?
Yes, when something goes awry with the initscripts system. And systemd is not
exactly famous for its transparency of execution and stability of options'
behaviour.
> But second to that, I'm not sure why you think nginx_enable='YES' is fundamentally less opaque than an nginx.service file. Both are parsed by another application.
That's true of both plain-text configuration files and Windows Registry keys ;-).
That's true of both plain-text configuration files and Windows Registry keys ;-).
> you need like 2 lines of shell code in a BSDish rc.conf
... and then 223 lines of actual scripts, since those two lines in rc.conf merely enable/disable the services and do not denote how to actually invoke them. (Equivalently, the systemd people could say that they need just two symbolic links, one for enabling each service.)
... and then 223 lines of actual scripts, since those two lines in rc.conf merely enable/disable the services and do not denote how to actually invoke them. (Equivalently, the systemd people could say that they need just two symbolic links, one for enabling each service.)
% wc -l /usr/local/etc/rc.d/nginx /etc/rc.d/sshd
136 /usr/local/etc/rc.d/nginx
87 /etc/rc.d/sshd
223 total
%
% wc -l /etc/rc.subr
2090 /etc/rc.subr
%
> Devuan is basically Debian without systemd.
You can already run Debian without systemd today. There's absolutely no need in the fragmentation Devuan creates.
You can already run Debian without systemd today. There's absolutely no need in the fragmentation Devuan creates.
I'm under the impression that Devuan's purpose is to actually progress into the future without systemd.
I am not under the impression that Debian strives to make progress on the systemd-less use case, it seems more like a minimally supported mode.
But it's not something I've investigated, so take that with a big grain of salt.
I am not under the impression that Debian strives to make progress on the systemd-less use case, it seems more like a minimally supported mode.
But it's not something I've investigated, so take that with a big grain of salt.
I’ve been running the beta on my desktop. In this release, they have also established sane defaults for a wider range of window managers and desktop environments.
The rough edges I’ve hit can all be attributed to systemd brain damage (like the fact that the linux kernel no longer has a working, synchronous, “probe the network cards and create a logical interface for each one” primitive).
My only beef with devuan is that the beta install I have runs systemd’s elogind. It seems stable enough under devuan, but routinely broke under back when this machine was actually running systemd, and I plan to cleanse it with fire if it is still there after I update to stable 2.0.
I highly recommend devuan. Unlike Ubuntu, debian regularly rebuilds everything from source, and ~95% of their packages have reproducible builds.
For me, this, plus pre-systemd levels of stability and debuggability is a winning combination.
The rough edges I’ve hit can all be attributed to systemd brain damage (like the fact that the linux kernel no longer has a working, synchronous, “probe the network cards and create a logical interface for each one” primitive).
My only beef with devuan is that the beta install I have runs systemd’s elogind. It seems stable enough under devuan, but routinely broke under back when this machine was actually running systemd, and I plan to cleanse it with fire if it is still there after I update to stable 2.0.
I highly recommend devuan. Unlike Ubuntu, debian regularly rebuilds everything from source, and ~95% of their packages have reproducible builds.
For me, this, plus pre-systemd levels of stability and debuggability is a winning combination.
(Obligatory, this is honestly not trolling, but...)
> For me, this, plus pre-systemd levels of stability and debuggability is a winning combination.
As a developer who uses a Mac every day, and has experience with Linux only at a distance, administrating servers a little, using Ansible, debugging the odd production failure...
I actually find it easier to debug a system using systemd. I'm not sure why this is. Some ideas I have are:
- It could be that I never learnt the old way?
- I find the config files easier to grok than the scripts, and I don't think I've ever had an issue with systemd itself, so never needed to go further down that path than the config files.
- I find it a bit more consistent between different parts of the system.
> For me, this, plus pre-systemd levels of stability and debuggability is a winning combination.
As a developer who uses a Mac every day, and has experience with Linux only at a distance, administrating servers a little, using Ansible, debugging the odd production failure...
I actually find it easier to debug a system using systemd. I'm not sure why this is. Some ideas I have are:
- It could be that I never learnt the old way?
- I find the config files easier to grok than the scripts, and I don't think I've ever had an issue with systemd itself, so never needed to go further down that path than the config files.
- I find it a bit more consistent between different parts of the system.
> I don't think I've ever had an issue with systemd itself
You've been very lucky :-).
My favourite gem, which I haven't been able to figure out by the time I'd finally decided I've had enough and ditched the damn thing, was not being able to reboot my computer if I had some filesystems mounted over the network. It irked me considerably, because I was running a rolling-release distro at the time and I rebooted fairly often.
(Edit: to be clear -- I'm sure there are tons of valid use cases that systemd serves much better than any other init system. I know a lot of very knowledgeable people who use it. My computers just don't seem to have those use cases :-) )
You've been very lucky :-).
My favourite gem, which I haven't been able to figure out by the time I'd finally decided I've had enough and ditched the damn thing, was not being able to reboot my computer if I had some filesystems mounted over the network. It irked me considerably, because I was running a rolling-release distro at the time and I rebooted fairly often.
(Edit: to be clear -- I'm sure there are tons of valid use cases that systemd serves much better than any other init system. I know a lot of very knowledgeable people who use it. My computers just don't seem to have those use cases :-) )
> The rough edges I’ve hit can all be attributed to systemd brain damage (like the fact that the linux kernel no longer has a working, synchronous, “probe the network cards and create a logical interface for each one” primitive).
Multithreaded device probing exists far before systemd. It was introduced around Linux 2.6.18.
Multithreaded device probing exists far before systemd. It was introduced around Linux 2.6.18.
It's your basic grand conspiracy theory setup. You see a bunch of sensible features that don't add up to any particular larger plan, they see a sprawling plot by innumerable enemies to destroy a status quo that never actually existed outside their imagination.
It is amusing to me that they call themselves "Veteran Unix Administrators" because an operating system needs _software engineers_ or at the very least _hackers_ and the last people you want doing this would be sysadmins I think all the very worst software I have to interact with was built by sysadmins who had the idea that programming wasn't that hard so they'd do a bit in their spare time...
It is amusing to me that they call themselves "Veteran Unix Administrators" because an operating system needs _software engineers_ or at the very least _hackers_ and the last people you want doing this would be sysadmins I think all the very worst software I have to interact with was built by sysadmins who had the idea that programming wasn't that hard so they'd do a bit in their spare time...
The main driver behind the initial fork isn't even a sysadmin, but an art student who initiated Devuan as part of an art project and his PhD thesis: https://pearl.plymouth.ac.uk/handle/10026.1/11101
As a fun fact the thesis is released under a Creative Commons license, but states "no quotation from the thesis and no information derived from it may be published without the author's prior consent". Forbidding quotations and building further work on it is also an interesting approach to the idea of science.
As a fun fact the thesis is released under a Creative Commons license, but states "no quotation from the thesis and no information derived from it may be published without the author's prior consent". Forbidding quotations and building further work on it is also an interesting approach to the idea of science.
That's boilerplate that Plymouth imposes, and not Denis Roio's choice. You'll find that this is fairly common, although the boilerplate varies from university to university. Here are some example rules from Durham, Brunel, Oxford, and Ulster, all with similar requirements to add such boilerplate.
* https://www.dur.ac.uk/graduate.school/current-students/submi...
* https://www.brunel.ac.uk/__data/assets/pdf_file/0014/213107/...
* https://www.ox.ac.uk/sites/files/oxford/field/field_document...
* http://www.ulster.ac.uk/academicservices/staff/PREPARATION%2...
* https://www.dur.ac.uk/graduate.school/current-students/submi...
* https://www.brunel.ac.uk/__data/assets/pdf_file/0014/213107/...
* https://www.ox.ac.uk/sites/files/oxford/field/field_document...
* http://www.ulster.ac.uk/academicservices/staff/PREPARATION%2...
Back in the old days, insmod and modprobe were synchronous. If you wanted concurrency during boot, you could use fork/join to get it (using the & line suffix and “join” command in bash, for instance).
In the brave new world, all kernel events are published over some wonky bus thing, so you need to write a daemon that listens for hardware events and replicates the kernel’s current state of the world in dram, and also is fault tolerant, and has a security subsystem that authenticates user requests before forwarding them to the kernel.
The new approach is fundamentally broken because it is too complicated to understand or implement correctly.
Also, it is gratuitously reimplmenting basic kernel functionality (security, process lifecycle) in user space, and in at least one case that has hit me personally (DriSetMaster) the systemd contingent has been blocking straightforward patches to the Linux kernel that make it possible for non systemd init systems to work without adding their own crappy shim processes.
I run Linux because I want a working unix environment. Systemd is turning it into something else.
I think it is telling that we’re seeing things like fuschia and renewed interest in the BSD’s specifically because Linux on the desktop / laptop is increasingly an unsupportable mess.
In the brave new world, all kernel events are published over some wonky bus thing, so you need to write a daemon that listens for hardware events and replicates the kernel’s current state of the world in dram, and also is fault tolerant, and has a security subsystem that authenticates user requests before forwarding them to the kernel.
The new approach is fundamentally broken because it is too complicated to understand or implement correctly.
Also, it is gratuitously reimplmenting basic kernel functionality (security, process lifecycle) in user space, and in at least one case that has hit me personally (DriSetMaster) the systemd contingent has been blocking straightforward patches to the Linux kernel that make it possible for non systemd init systems to work without adding their own crappy shim processes.
I run Linux because I want a working unix environment. Systemd is turning it into something else.
I think it is telling that we’re seeing things like fuschia and renewed interest in the BSD’s specifically because Linux on the desktop / laptop is increasingly an unsupportable mess.
"Back in the old days, insmod and modprobe were synchronous"
No, back in the old days, CONFIG_MODULES was scary and new and the Veterans would have been demanding it be removed because "I want a working unix environment" and if they buy a new hardware device obviously they would install a C compiler and rebuild the operating system kernel to support the new device properly.
Now get off my lawn.
No, back in the old days, CONFIG_MODULES was scary and new and the Veterans would have been demanding it be removed because "I want a working unix environment" and if they buy a new hardware device obviously they would install a C compiler and rebuild the operating system kernel to support the new device properly.
Now get off my lawn.
insmod and modprobe are still synchronous. Once you have loaded a network driver, you can be assured the corresponding devices have been created.
What's new (around 2006) is the kernel will probe buses in parallel and invoke modprobe in parallel to load the appropriate drivers if they match the driver's alias.
Introduction of userland components to populate /dev also largely predates systemd. devfs was introduced during 2.3.x. udev replaced it during 2.5.x.
What's new (around 2006) is the kernel will probe buses in parallel and invoke modprobe in parallel to load the appropriate drivers if they match the driver's alias.
Introduction of userland components to populate /dev also largely predates systemd. devfs was introduced during 2.3.x. udev replaced it during 2.5.x.
Is there an alternative to elogind? From what I can tell most software needs it.
I think elogind is used because at least Gnome and KDE are dependent on logind.
Thanks. I don’t use either of those. (Also, does “gnome” include “mate” in this context, I wonder?)
Don't want to troll or anything, just a question from curiosity: don't you think that massive popularity of systemd is a result of a massive demand for software like systemd?
As i understand it, systemd provides some functionality that some people wanted, but not everyone was happy with how this functionality was implemented and/or provided (which included people who didn't need tht functionality in the first place) and others were annoyed by how it was pushed/promoted and became a dependency on some popular projects (e.g. Gnome) without a technical necessity for being so, feeling like it was forced on people who didn't wanted it but also making it harder to use other init systems (this is especially important since, as i already wrote, the provided functionality is desired by some people and could be provided in a better way by another init system).
(note that with functionality here i do not refer to specific APIs or interfaces, but higher level functionality like "i want to be able to do XXX when YYY happens")
(note that with functionality here i do not refer to specific APIs or interfaces, but higher level functionality like "i want to be able to do XXX when YYY happens")
On the desktop where you need to deal with WLAN interfaces going up and down, maybe a monstrosity like systemd has its place, but even there my opinion is systemd just isn't worth fragmenting and polarizing the whole Unix ecosystem with systemd's total lack of mental discipline and attitude of wrapping each and everything under the sun including binary logging, mandatory systemd-only APIs for loggin in, cron replacement, etc.
On the server-side where Linux has its mainstay, using systemd is even more pointless IMHO since services and network interfaces don't come and go. Loosing portability for saving a couple lines of shell code for starting/stopping services is IMHO a trade-off that just doesn't make sense from an engineering PoV. All the more so since systemd doesn't shield you from the intricacies of dealing with demon programs; if something is going south on your server, have fun with systemd binary logs to analyze what has happened.
Now RedHat (who are shouldering a large part of Linux development anyway) sure aren't stupid; therefore I have to conclude that they're playing the Embrace, Extend, Extinguish game here to subvert Linux into SystemD-OS.
Devuan has become a very important key project to prevent that from happening to the Debian code base. Btw congrats to the Devuan project! I wasn't quite sure they'd be able to deliver a couple years ago when they started; now I think Devuan (along with Gentoo, Slackware, Alpine) is going to save Linux' ass as a "real" F/OSS community effort going forward, no less. My hope is Arch Linux with its great community and documentation gets a systemd-less fork as well.
On the server-side where Linux has its mainstay, using systemd is even more pointless IMHO since services and network interfaces don't come and go. Loosing portability for saving a couple lines of shell code for starting/stopping services is IMHO a trade-off that just doesn't make sense from an engineering PoV. All the more so since systemd doesn't shield you from the intricacies of dealing with demon programs; if something is going south on your server, have fun with systemd binary logs to analyze what has happened.
Now RedHat (who are shouldering a large part of Linux development anyway) sure aren't stupid; therefore I have to conclude that they're playing the Embrace, Extend, Extinguish game here to subvert Linux into SystemD-OS.
Devuan has become a very important key project to prevent that from happening to the Debian code base. Btw congrats to the Devuan project! I wasn't quite sure they'd be able to deliver a couple years ago when they started; now I think Devuan (along with Gentoo, Slackware, Alpine) is going to save Linux' ass as a "real" F/OSS community effort going forward, no less. My hope is Arch Linux with its great community and documentation gets a systemd-less fork as well.
Systemd exist for two groups, macbook packing cypherpunks and devops "cattle farms".
All the rest have to grin and bear it until Pottering and crew gets bored, run into those corner cases that made the older systems so gnarly to maintain, and move on.
All the rest have to grin and bear it until Pottering and crew gets bored, run into those corner cases that made the older systems so gnarly to maintain, and move on.
I hope you're wrong on systemd on a Mac. I have to assume its being used for systemd-under-(systemd-infested-linux)-under-virtualbox or systemd-under-docker (or even systemd-under-docker-under-<systemd-infested-linux>-under-virtualbox). systemd-under-docker is particularly pointless IMHO if it's even possible. Could someone using systemd on a Mac chime in and explain the use case?
Macs seems to be right behind Thinkpads in terms of Linux support, thanks to having fairly static hardware between models.
End result seems to be that quite a few either single or dual boot Linux on Mac.
End result seems to be that quite a few either single or dual boot Linux on Mac.
"Still beats dealing with airlines" - South Park
widespread use != massive popularity
Ask your average Windows user.
Ask your average Windows user.
No, it's because we, the users, have no other choice.
In short: no.
Great timing for me. Just got the last of the parts in to build a network audio player, waiting for the weekend to start on it. I'll use this instead of Raspian.
Why do you want to use sysvinit over systemd? Do you have init scripts already written that you don't want to port?
Well binary logs seem to be a good enough reason for me.
I use FreeBSD and Devuan feels like I am in control. Some commercial software won't work on FreeBSD so I have to use some Linux.
I also use Alpine because it uses OpenRC. With gLibc missing it is tough to compile some software.
Compared, Devuan seems to be very software compatible and offers the familiarity of Debian.
Over at FreeBSD we have loads of new users thanks to systemd.
Keep up the great work RedHat.
I use FreeBSD and Devuan feels like I am in control. Some commercial software won't work on FreeBSD so I have to use some Linux.
I also use Alpine because it uses OpenRC. With gLibc missing it is tough to compile some software.
Compared, Devuan seems to be very software compatible and offers the familiarity of Debian.
Over at FreeBSD we have loads of new users thanks to systemd.
Keep up the great work RedHat.
That's why I have a wildcard redirect to rsyslogd, the journal is pretty much mirrored in text form in /var/log.
I still think systemd is by far the best init system around. Service files are a trillion times cleaner, easier to understand and maintain than those bloated 90% copy and past init scripts with the retarded archaic run level concept.
Really, if I had a reasonable amount of free time left I'd start something like systemd lite which is just the init part and none of the other bullshit. You could already just use that part but there is still quite a bit of crap around that could just be removed.
I still think systemd is by far the best init system around. Service files are a trillion times cleaner, easier to understand and maintain than those bloated 90% copy and past init scripts with the retarded archaic run level concept.
Really, if I had a reasonable amount of free time left I'd start something like systemd lite which is just the init part and none of the other bullshit. You could already just use that part but there is still quite a bit of crap around that could just be removed.
You need to learn about uselessd. And you need to stop committing the fallacy of allowing for only two systems in the world, systemd and van Smoorenburg init+rc. This fallacy was called out by the author of uselessd.
* http://uselessd.darknedgy.net/ProSystemdAntiSystemd/
* http://jdebp.eu./FGA/run-scripts-and-service-units-side-by-s...
* http://uselessd.darknedgy.net/ProSystemdAntiSystemd/
* http://jdebp.eu./FGA/run-scripts-and-service-units-side-by-s...
I hear the binary logging argument very often. What is bad with it? Is the format not specified? Maybe it is more efficient to log this way.
Often it comes down to "it's not text, which I don't like, ergo binary is bad".
Often it comes down to "it's not text, which I don't like, ergo binary is bad".
Several reasons, the largest of which is that I dislike systemd. I'm not going to rehash the arguments that have been had thousands of times, just put me in 'that' bucket.
Other reasons include that I like to support alternate distros, I'm curious as to how they've done with it so far, and this is a low-resource device so I don't want unnecessary junk like journald wasting cycles.
Other reasons include that I like to support alternate distros, I'm curious as to how they've done with it so far, and this is a low-resource device so I don't want unnecessary junk like journald wasting cycles.
While I think it's great you have the option, it doesn't strike me as the best choice.
Thanks for sharing your carefully considered analysis.
Care to walk me through your minimax of the various tradeoffs that went into my design, including the janky custom software I'll run on it?
Care to walk me through your minimax of the various tradeoffs that went into my design, including the janky custom software I'll run on it?
Devan is an useful and important distro. I just hope they integrate back with Debian at some point (I don't know how, but I'd love o see that happen.)
That seems unlikely unless Debian drops systemd or the ecosystem becomes so dependent on systemd's ever-expanding reach that it becomes impossible to build a Linux distro without it.
Debian doesn't actually have anything against sysvinit or OpenRC. Those are just not the defaults. Both sysvinit and OpenRC are available in Debian.
It probably would be easier to have a non-systemd system were the Devuan developers to upstream their packaging and patches to Debian.
As Devuan has a stated goal of not using systemd though, I would guess they take the easy route of not maintaining systemd compatibility. The longer it remains a fork without effort to upstream changes, the more it would diverge and the more work it would be. It would also be more work to keep the fork going, so I guess at some point it would either have to be a hard fork or it would die.
It probably would be easier to have a non-systemd system were the Devuan developers to upstream their packaging and patches to Debian.
As Devuan has a stated goal of not using systemd though, I would guess they take the easy route of not maintaining systemd compatibility. The longer it remains a fork without effort to upstream changes, the more it would diverge and the more work it would be. It would also be more work to keep the fork going, so I guess at some point it would either have to be a hard fork or it would die.
From 2014-06-11 systemd news:
> * The support for SysV and LSB init scripts has been removed from the systemd daemon itself. Instead, it is now implemented as a generator that creates native systemd units from these scripts when needed. This enables us to remove a substantial amount of legacy code from PID 1, following the fact that many distributions only ship a very small number of LSB/SysV init scripts nowadays.
At the earliest possible opportunity, systemd removed everything they could that supported alternative init systems. So no, it is not trivial to take a Debian release and make it run SysVinit or OpenRC. In fact, it was so much work that the Devuan devs expended the effort to fork, including setting up a website, mailing lists, IRC channels, a bug-tracker, and all the other infrastructure necessary to maintain a serious, well-supported distro.
And as far as "upstreaming" to Debian, how is Debian upstream for SysVinit or OpenRC? Both of those are separate projects not owned by Debian.
> * The support for SysV and LSB init scripts has been removed from the systemd daemon itself. Instead, it is now implemented as a generator that creates native systemd units from these scripts when needed. This enables us to remove a substantial amount of legacy code from PID 1, following the fact that many distributions only ship a very small number of LSB/SysV init scripts nowadays.
At the earliest possible opportunity, systemd removed everything they could that supported alternative init systems. So no, it is not trivial to take a Debian release and make it run SysVinit or OpenRC. In fact, it was so much work that the Devuan devs expended the effort to fork, including setting up a website, mailing lists, IRC channels, a bug-tracker, and all the other infrastructure necessary to maintain a serious, well-supported distro.
And as far as "upstreaming" to Debian, how is Debian upstream for SysVinit or OpenRC? Both of those are separate projects not owned by Debian.
> So no, it is not trivial to take a Debian release and make it run SysVinit or OpenRC.
It is: "apt install sysvinit-core". For some reason, we still carry the burden of maintaining compatibility with many init systems while the "pro-choice" players don't.
> And as far as "upstreaming" to Debian, how is Debian upstream for SysVinit or OpenRC? Both of those are separate projects not owned by Debian.
Until recently, sysvinit was maintained by Debian.
It is: "apt install sysvinit-core". For some reason, we still carry the burden of maintaining compatibility with many init systems while the "pro-choice" players don't.
> And as far as "upstreaming" to Debian, how is Debian upstream for SysVinit or OpenRC? Both of those are separate projects not owned by Debian.
Until recently, sysvinit was maintained by Debian.
So changing an implementation detail how the support for sysvinit scripts for systemd works means they "removed everything they could"? That's a strange way to put it.
And if "apt-get install sysvinit-core" is not trivial for you, then yes, you might need a special distribution doing that for you.
And if "apt-get install sysvinit-core" is not trivial for you, then yes, you might need a special distribution doing that for you.
Thank goodness for Slackware and Devuan.
If you dislike systemd, Void Linux might be worth looking into as well.
And of course, Gentoo is still around, for those of us with too much time and too many spare CPU cycles on their hands. ;-)
And of course, Gentoo is still around, for those of us with too much time and too many spare CPU cycles on their hands. ;-)
Been using void for a couple of years. I could not be happier with it. I also need a non-systemd distro for production, found this project https://github.com/cloux/aws-devuan it's devuan + runit for aws.
I appreciate that they named their release after a no longer suitable character encoding. It does seem like a lot of trouble to go to to troll the systemd haters though.
Devuan is serving a need. It is not trolling.
What exact need?
A need to run Debian system without systemd.
That need is already fulfilled by Debian? Just install sysvinit. (edit:) Also consider that if Debian would stop supporting sysvinit, a distribution adding support for it again would be a real effort compared to just installing a different init system by default.
Some desktop environments might want systemd-logind+systemd-shim, but that's really not different from installing systemd-elogind in Devuan...
Some desktop environments might want systemd-logind+systemd-shim, but that's really not different from installing systemd-elogind in Devuan...
compare this to sysvinit, a no longer suitable init process.
I have yet to hear the argument that convinces me sysvinit (or openrc or runit) was "no longer suitable." In need of updating and revision? Sure. So broken that a completely new init that swallowed up a bunch of other processes and services was the best answer? Hardly.
Systemd was initially sold as providing faster boot times. Objections to its cancerous spread to other services beyond init were dismissed without providing any good reasons for why it was necessary or even desirable beyond "we're doing it, quit complaining." The changeover at Debian was handled so poorly and with such rancor that many from there still have a bad taste in their mouths.
Devuan was one response to that, and a good one. Artix was the response to Arch adopting systemd. Slackware and Gentoo and other older distros have stayed away from it. And as another commenter noted, lots of people have abandoned Linux for the BSDs.
The systemd fallout is demonstrating something I always thought was the weakest part of Linux compared to the BSDs, which is that the Linux userland is developed completely independently of the kernel. People do whatever the fuck they want, and frequently the relationships seem to be hostile.
I don't think systemd really solves that problem, either, but rather makes it much more complex and fragile. Hopefully the ecosystem will continue to support non-systemd distros in the long term.
Systemd was initially sold as providing faster boot times. Objections to its cancerous spread to other services beyond init were dismissed without providing any good reasons for why it was necessary or even desirable beyond "we're doing it, quit complaining." The changeover at Debian was handled so poorly and with such rancor that many from there still have a bad taste in their mouths.
Devuan was one response to that, and a good one. Artix was the response to Arch adopting systemd. Slackware and Gentoo and other older distros have stayed away from it. And as another commenter noted, lots of people have abandoned Linux for the BSDs.
The systemd fallout is demonstrating something I always thought was the weakest part of Linux compared to the BSDs, which is that the Linux userland is developed completely independently of the kernel. People do whatever the fuck they want, and frequently the relationships seem to be hostile.
I don't think systemd really solves that problem, either, but rather makes it much more complex and fragile. Hopefully the ecosystem will continue to support non-systemd distros in the long term.
> Systemd was initially sold as providing faster boot times.
Systemd was not about speed. Speed is a side-effect of correctly handling ordering. See http://0pointer.de/blog/projects/the-biggest-myths.
Systemd was not about speed. Speed is a side-effect of correctly handling ordering. See http://0pointer.de/blog/projects/the-biggest-myths.
Ah yes, systemd did promise the correct handling of start ordering (i.e. socket activation). Though this never happened in practice, you still need to manually specify dependencies in unit files, barring the very few daemons.
The init process is faster because they have by far the cleanest and most efficient way of managing and ordering dependencies.
Everything else that systemd brings is questionable to say the least. Combine that with a project founder with shitty personality and you get what systemd is today.
Everything else that systemd brings is questionable to say the least. Combine that with a project founder with shitty personality and you get what systemd is today.
> The systemd fallout is demonstrating something I always thought was the weakest part of Linux compared to the BSDs, which is that the Linux userland is developed completely independently of the kernel. People do whatever the fuck they want, and frequently the relationships seem to be hostile.
TBH i think this is its biggest strength because it makes easier for people to switch components that they dislike. After all, you can still use another init system, audio server, desktop environment, shell and other pieces of the userland if you dislike the defaults without having to change the entire OS. On the other hand with BSDs if you dislike something you have to switch to a fork that affects everything.
TBH i think this is its biggest strength because it makes easier for people to switch components that they dislike. After all, you can still use another init system, audio server, desktop environment, shell and other pieces of the userland if you dislike the defaults without having to change the entire OS. On the other hand with BSDs if you dislike something you have to switch to a fork that affects everything.
Couples week since I distro hopped.... Guess it's about time...
It is really sad how quickly this was voted off the front page...