https://www.devuan.org/os/announce/chimaera-release-announce-2021-10-14
Dear Friends and Software Freedom Lovers,
Devuan Developers are pleased to announce the release of Devuan Chimaera
4.0 as the project's newest stable release. This is the result of lots of
painstaking work by the team and extensive testing by the wider Devuan
community.What's new in Chimaera 4.0?
* Based on Debian Bullseye (11.1) with Linux kernel 5.10.
* Your choice of init: sysvinit, runit, and OpenRC.
* Improved desktop support - virtually all desktop environments available
in Debian are now part of Devuan, systemd-free.
* New boot, display manager and desktop theming.
* Enhanced accessibility: installation via GUI or console can now be
accomplished via software or hardware speech synthesis, or using a
refreshable braille display, and Devuan Chimaera has the ability to
install desktop environments without PulseAudio, allowing speech
synthesis in both console and GUI sessions at the same time.
"without PulseAudio", eh? Speculations on the reason for that are welcome, he asked them knowingly... -- Ed.
(Score: 5, Insightful) by Anonymous Coward on Friday October 15 2021, @05:51AM (25 children)
Pulseaudio introduces distortion in both recording and playback. This makes any system with it installed unusable for professional grade audio work.
(Score: 4, Insightful) by Rosco P. Coltrane on Friday October 15 2021, @07:06AM (1 child)
Pulseaudio mostly introduces lag, bugs, permission problems and extreme complication to do anything simple that's a little bit out of the ordinary.
Fun exercise: try to get two users to play sound simultaneously (or, for extra fun, try to get root and another user to play sound simultaneously) when the second user or root has logged in from another console (i.e. not sudo). Honestly, try it: you'll waste a few hours on that one if you don't know how to do it.
(Score: 2) by bzipitidoo on Friday October 15 2021, @11:17PM
Yes, my experience with pulseaudio is that it is also a huge resource hog. How can it possibly need 150M of RAM, and over 50% CPU? Probably because it leaks memory like a holy FSM colander leaks water. Except the colander is supposed to. That's what pulseaudio will do on older computers. Makes them completely unusable.
(Score: 3, Insightful) by Anonymous Coward on Friday October 15 2021, @11:35AM (7 children)
I wish I could get rid of PulseAudio, which only exists to cause problems. The problem isn't physically getting rid of it - I use Gentoo which allows that - but that not having it causes problems with software that has hard dependencies on it. I can't, for example, get Discord sound to work without it. At all. I ended up launching a Windows VM once to use it. A few games (mostly those about three years old and using Unity) have hard dependencies. Of course, PulseAudio itself just causes audio problems and occasionally falls over and just spews static, which forces me to relogin.
Everything is horrible and it's all PulseAudio's fault.
(Score: 4, Insightful) by acid andy on Friday October 15 2021, @01:14PM (2 children)
In my book if a piece of software has a hard dependency on PulseAudio, then it's probably a piece of software I can do without. I don't like Unity very much either. If it's a killer app that won't run but it's open source, I might have a go at commenting out all the dependencies I don't want until the code will run, then look at replacing them if they're features I badly need. That's the joy of open source.
If a cat has kittens, does a rat have rittens, a bat bittens and a mat mittens?
(Score: 4, Funny) by Marand on Friday October 15 2021, @08:30PM (1 child)
You might find pipewire interesting. It's intended to be a unification of sorts of the ideas of JACK and PulseAudio, with the added bonus of not being managed by Poettering. I've heard it's quite good as a PA replacement, but I haven't had the opportunity to try it myself. Basically a way to finally bring a lot of the benefits of JACK to more mainstream use, which I approve of beause JACK is by far superior but it's just annoying enough to use that it never really got much adoption outside of pro audio type use cases.
Also, regarding Unity, it's interesting, because stuff created with Unity works a lot better on Linux than Unity itself. The editor was such a nightmare to use on Linux a year or so ago when I checked it out; I've heard it's improved some, but it'll take a lot to make it actually nice to use. Not that it's awesome anywhere else but it had so many basic broken things about it on Linux, I got frustrated and abandoned it almost immediately. By contrast, stuff made with Unity tends to at least work pretty well, though there's a tendency for minor Unity updates to break things. Likely because Unity editor itself is such a clusterfuck.
Godot's a way better experience. The editor's built in the engine itself, so it runs just as well on Linux as the engine does, and gives a lot of confidence in the engine. It's a good sign when the engines being dogfooded like that. The current stable versions aren't quite as good in 3d stuff, but it's a better 2d engine by far, actually has some use for non-game applications, and the next major release is supposed to bring a lot of 3d improvements.
Just sucks waiting for Godot 4. (Sorry, not sorry.)
(Score: 0) by Anonymous Coward on Sunday October 17 2021, @08:36PM
Frankly Pipewire is gross. It has no reason to exist except that Wayland, unlike X11, can't by default be remotely operated.
So Pipewire has come about to allow network access of Wayland DEs.
For audio, it would have been better if effort was focused on the software mixer in Alsa, and Jack for advanced needs.
The only real "problem" with Alsa is the handling of transitory audio devices like Bluetooth and USB headphones.
And that could be handled by software mixers that can reroute the audio as needed as devices show up and vanish.
But as JWZ put it, CADT. Linux will never get anywhere without strong guidance because programmers will always want to work on something new if left alone.
(Score: 5, Informative) by DarkMorph on Friday October 15 2021, @08:52PM (1 child)
(Score: 0) by Anonymous Coward on Friday October 15 2021, @09:34PM
Ooh, cool, I have to check that out. Currently I have to run PA for Zoom.
(Score: 2) by corey on Friday October 15 2021, @10:36PM
Gentoo here as well. I had to install PA when I installed signal-desktop-bin from memory. Otherwise have managed to avoid it.
(Score: 2) by hendrikboom on Monday October 18 2021, @04:12AM
There's a software package that provides a pulseaudio interface for software that demand it, but uses ALSA to emit the sound. An adapter, if you will.
(Score: 5, Informative) by acid andy on Friday October 15 2021, @01:15PM (13 children)
P*ettering.
If a cat has kittens, does a rat have rittens, a bat bittens and a mat mittens?
(Score: 3, Touché) by FatPhil on Friday October 15 2021, @01:31PM
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 3, Informative) by Anonymous Coward on Friday October 15 2021, @04:57PM (11 children)
Yes and no. Most people wouldn't even know who he was if not for problems with PulseAudio and SystemD, but those problems and the resistance to fixing them are universally his fault. Many of the worst PulseAudio bugs were fixed right after he and his team left the project, because the new devs accepted patches that had been rejected years before.
(Score: 5, Interesting) by Marand on Friday October 15 2021, @08:20PM (10 children)
My favourite example of this, because it affected me personally in quite a bad way, is Poettering's insistence that pulseaudio's "flat volumes" misfeature was a good thing that should be enabled by default for everyone, stubbornly ignoring complaints and arguments against it. Flat volumes is a poor imitation of something Microsoft did to audio in Windows Vista; if a new sound source plays at a certain volume, having it enabled causes all other sound sources to change their volume level to match it. Hence "flat", because everything will play at the same volume level. Sounds fine until you realise that it will raise the volume. Anyone reading can already see how this is a very bad idea, but just to elaborate on it, here's what my introduction ot the "feature" was like:
I mostly avoided and ignored Pulse Audio for years, but at some point I had to give in and install it to deal with bluetooth audio and some PA-only software. Everything seemed okay, had it all configured and I carefully made sure all my mixer settings were at low volume before playing any sounds. I use headphones directly connected to the sound card, no speakers at all, so I rely on the system volume primarily, and didn't want to blast my ears. A comfortable volume level with that setup is something like 10-15%, and I got everything just right. So I was minding my own business, listening to some music, when a notification sound in another program played.
This notification sound played at 100% volume, which was very loud since, as I just said, comfortable volume is something like 10-15%. That wouldn't have been anything more than a minor annoyance, except that flat volumes exists. When the notification played at 100%, PA decided to "helpfully" crank up my media player's audio to 100% to match it, blasting the fuck out of my ears. I ripped the headphones off ASAP and killed the sound as quick as I could, but the damage was done. The headphones were fine, but I still have a subtle ringing in my ears years later.
This led me down a rabbit hole of complaints and bug reports about the flat volumes setting, because people had been complaining about precisely this risk of causing physical damage to user and hardware for years. Lennart dismissed every complaint, saying that if 100% volume is too loud, it's a problem with your hardware, so you should replace that instead of wasting his time with bug reports when pulseaudio was working perfectly fine. Thanks, Lennart, you caused me ear damage by being a stubborn cunt.
After he got bored and moved on to systemd, other devs finally listened and changed the default to having flat volumes disabled, years after most distros had already disabled it downstream in their default configurations. But good change could only happen after Poettering left, because as long as he's involved in a project, everything is NOTABUG WONTFIX.
Systemd might eventually become a decently usable piece of software with its worst issues dealt with, but it won't happen until Poettering gets bored and finds something else to work on. There's arguably some benefit to his work because he does tend to be a catalyst for work in areas that need it, but his attitude and ego makes it impossible to really progress until after he leaves and others can come in and clean up the mess. That same ego is probably beneficial in getting things started, but it's horrible for fixing the problems with his ideas because he refuses to even consider that there might be problems with the things he does.
(Score: 3, Touché) by Runaway1956 on Saturday October 16 2021, @02:00AM (3 children)
Not in my lifetime. Certainly not in Poettering's lifetime. He's going to ride that horse to hell.
(Score: 2) by Marand on Saturday October 16 2021, @03:39AM (2 children)
There are some good things about how it works, so it's possible, I just wouldn't expect it any time soon. We just need Poettering to move on so better devs can fix things. I'd still rather have had just about any of the other sysv-init alternatives, but whatever, I don't hate it. I just don't trust it to be reliable yet.
One thing about systemd that I will say is just unequivocally better than other options is systemd-nspawn [archlinux.org]. It's basically a super simple and convenient way of doing chroots, except it does better/more than chroots and is closer to being a dead-simple way of doing containers. I use it alongside qemu-user-static [debian.org] (which does user-mode binary translation, e.g. translating armhf Linux binaries to amd64 on-the-fly) to mount a raspberry pi disk image to a directory, containerise it with systemd-nspawn, and then run the ARM binaries via qemu-user-static. Beats trying to set up a proper VM (which is a pain in the ass for ARM stuff) and is great for compiling shit to put on a low-powered Pi Zero later.
Point is, it's a better replacement for old-school chroot creation with better results and less ceremony. Can't say much good about other systemd-foo projects, but that one is actually good.
(Score: 0) by Anonymous Coward on Saturday October 16 2021, @06:40PM
i won't try to argue with people about the possible security risks of systemd, but i haven't had any reliability problems with it once it's been set up correctly and known working. Most of it is nice to use too. That being said, i'm liking OpenBSD lately.
(Score: 0) by Anonymous Coward on Sunday October 17 2021, @08:49PM
Basic problem is that systemd, unlike say pulseaudio or avahi, is that it is a unbounded project. Anything can potentially be made a sub-project of systemd, up to and including the kernel itself (watch it happen after GKH is formally handed control by Torvalds, as he already allowed his butter Sievers to fold udev into it).
(Score: 2) by bzipitidoo on Saturday October 16 2021, @07:43PM
Your story is another example of why systems need hard limits, shutoffs, kill switches, and the like, that are not subject to software manipulation. You know of the Therac-25? To save money, they removed hardware limiters, relying solely on the software to keep things at sane levels. But the software was seriously flawed. There could have been a final sanity check in the software, but there wasn't even that. A few patients received 1000x the radiation dose they should have been given, and died.
Many headphones do have a volume control, independent of the extremely complicated system that, as you learned the hard way, did have a booby trap. Yes, there's lots of bad work by Poettering, but this could have easily happened with any complicated system and another bad developer. This sort of stuff is why people look side-eyed at IoT.
(Score: 0) by Anonymous Coward on Sunday October 17 2021, @08:46PM
For some reason the guy has as much a hard-on for Apple as Icaza has for MS, yet keep creating software that ends up being a lesser clone of MS junk.
His first major project outside of some random Gnome mangling was Avahi. Went over like a lead balloon.
Pulseaudio was a direct result of him using usb headphones on a macbook (that in typical Apple fashion do not have anything sensible like 2.5MM jacks).
Systemd is basically him trying to clone launchd, but had become something akin to svchost.
Frankly at this point the Linux community would be better of ignoring him, Gnome, and most everything in userspace that is maintained by someone on RH payroll.
(Score: 2) by wirelessduck on Friday October 29 2021, @01:21AM (3 children)
Once the new service manager s6-rc from Laurent Bercot (skarnet) is developed it should beat systemd in every aspect, including speed. And without the "cheating" too!
https://skarnet.com/projects/service-manager.html [skarnet.com]
(Score: 3, Interesting) by Marand on Friday October 29 2021, @02:23AM (2 children)
That's an interesting read, thanks for the link.
One thing that it mentions being a shortcoming of s6-rc is, on the subject of "declarative service files", it lists s6 as currently unacceptable because "Service configuration files are scripts, no syntactic sugar is provided to the user."
I just wanted to point out that that, since it uses scripts for service files, that issue doesn't actually need to be covered by s6 itself. In order to maintain flexibility and modularity, it would make more sense IMO to create a an interpreter for a declarative syntax and then operate them as "scripts" using the traditional shebang notation for making text files executable. That way you could have something like "#!/bin/s6-service" at the start of the file, and the remaining contents (which could be written in a declarative format) would get passed to the s6-service interpreter by the kernel's usual binary handling mechanism, with no need to make it part of s6-rc directly. That way, you could either write a script by hand if you need for some reason (like perhaps the declarative files don't quite do what you want), but for most things you'd just write something like this (borrowing systemd's basic style for example purposes):
That would make the "unit file" get passed to the s6-service interpreter, which would then do whatever's appropriate for s6 in the same way the shell scripts currently do. Just without writing code directly. I've actually mentioned and suggested this approach in the past as an example of why the pro-systemd argument of "declarative files are better, script files suck" was a poor argument for removal of sysvinit, because if that's the only goal, someone could have made a systemd unit file interpreter and then just added a shebang on top of the files. The use of shell scripts with init is more of a convention than a requirement, and you can just as easily replace them with declarative scripts parsed by an interpreter, or even compiled binaries, because the kernel handles them all the same.
Anyway, no idea why I'm saying this since it's unlikely the author reads SN and would see this in an older topic. Figured maybe if you happen to know the author you could pass it on or something I guess.
(Score: 2) by wirelessduck on Saturday October 30 2021, @09:44AM (1 child)
Similar to how /lib/init/init-d-script on Debian systems used to be a binary but is now a shell script?
I don't know the author. I just stumbled upon it while reading the irc logs for the new eudev project development which was recently dropped by Gentoo and now picked up by Devuan, Alpine, and other interested parties. The s6 author, skarnet, was/is a participant on that irc channel as he has developed mdevd.
http://reisenweber.net/irclogs/freenode/_devuan-eudev/ [reisenweber.net]
http://reisenweber.net/irclogs/freenode/_eudev/ [reisenweber.net]
https://github.com/eudev-project/eudev [github.com]
https://skarnet.org/software/mdevd/ [skarnet.org]
(Score: 2) by Marand on Tuesday November 02 2021, @10:35PM
I'm not familiar with that so I don't know if it's similar or not. Let me explain it in the context of sysvinit for a more concrete example of what I mean.
First off, on Linux and other *nix-like systems, files are considered executable based on a permission bit you can change for user/group/all (e.g. chmod u+x foo). If a file is a native binary (ELF32 or ELF64, among others) the kernel knows how to handle that immediately. If it's marked executable but *not* a known binary format, there are a couple ways it can deal. One that is interesting (but not actually relevant here) is to use binfmt_misc, which allows you to define handlers for a type of file, based on magic bytes somewhere in the file. This is how you can make Java .jar files automatically run on the JVM on Linux, for example, because you install a package that adds a binfmt_misc handler. There are also tricks to do things like make ARM executables run through qemu-user-static, etc.
Anyway, the other thing the kernel does is, if a file is marked executable and is text, it looks for a specific combination of characters on the first line, called the "shebang", and if it exists, it parses that line to determine an interpreter to run, then passes the contents of the file to that interpreter. So if you have a Python script named foo.py and put "#!/usr/bin/python" as the first line, and you 'chmod u+x foo.py', you can now run it without invoking python directly, e.g "./foo.py" or by putting it on your $PATH and calling "foo.py". It doesn't know anything about Python to make this happen, it works by reading the shebang and then running the interpreter (/usr/bin/python), then passing the contents of the file to it, along with any command-line arguments. If you do the same thing with #!/usr/bin/perl and a text file that happens to have Perl code it'll work as well, and if you tried calling the wrong intepreter you'd get syntax errors because it'd send Ruby code to the Python interpreter, or whatever you did wrong.
That's what sysvinit uses to work. There's nothing inherently special about the use of shell scripts in /etc/init.d there, what happens is it reads the contents of certain folders corresponding to runlevels (like /etc/rc5.d) and attempts to execute the files in order. If a file starts with S it sends a command-line argument of "start", if it starts with K it sends "stop" instead. So a file in /etc/rcS.d/ named S01foo would run as "/etc/rcS.d/S01foo start". For management purposes and to avoid redundancy, everything in /etc/rc*.d/ is symlinked to another location (like /etc/init.d), but it's still the same thing happening.
All the files there are scripts, but that's essentially a historical quick because shell script was the lowest common denominator and always on every system, not because there's a requirement for them to be shell scripts. You could write an "init script" in C and compile it, and it would work as long as it can take understand "start" and "stop" as the first argument to ARGV. (Irrelevant side note: there are some extra quirks needed in later sysvinit due to the introduction of parallel startup that favours text files because 'strings' is used to read some dependency info stuff, but you can still use a compiled binary as long as you provide a multi-line string with the appropriate information.)
The point of all this is to explain the parts and how they work together. If you wanted to replace shell scripts, you could choose instead to compile them with Common Lisp, C, or OCaml it would work as well as long as you handle "start" and "stop" , because it's really just telling the kernel to run specific files marked executable. And, because of how text files can be made executable, that means you could also replace shell scripts with Python, Perl, Ruby, Lua, Scheme, etc. if you wanted. You could even mix and match, because it doesn't matter, it just reads the shebang and loads the interpreter you tell it to.
Now, while shebang-based execution typically is used to parse program code (like Perl or Python scripts) it doesn't have to be the case. You could write an interpreter that takes configuration data (like the declarative systemd unit files) instead. Because all that matters is that the resulting "program" be able to handle start/stop arguments and then do something useful. A normal init script is really just taking "sh foo start" and launching a process for you; and in the same way that you could replace that with a Perl script capable of understanding "perl foo.pl start" to launch a process, you could likewise do the same with a declarative interpreter. So if you had an interpreter named "unit-reader" that takes a foo.unit and does different things in response to start/stop arguments based on the contents of foo.unit, you have a valid sysvinit "init script". So you'd write your foo.unit file with #!/bin/unit-reader, chmod u+x foo.unit, and then the init system would call "foo.unit start" and everything works.
Since s6 is using shell scripts in a similar sort of way as sysvinit, same idea applies: instead of using a Turing-complete programming language as the interpreter, create a custom interpreter for a declarative file format that handles whatever commands the shell scripts are expected to handle.
As a side note, this isn't something that is only useful for init systems. You could use the same idea to make configuration files executable if you wanted. Like say you're making a server that needs to be configurable for things like port, IP address, whitelisted users, etc. Instead of `foo-server -c foo.conf` you could approach it differently by making `foo-server` take a .conf file as an argument and then adding a `#!/bin/foo-server` shebang to foo.conf. It's not typically done like this but it's possible, and occasionally useful.
(Score: 3, Informative) by Anonymous Coward on Friday October 15 2021, @04:00PM
Pulse was always garbage, the correct solution was a frontend for jackd. The problem still would have been video sync which is why we now have pipewire. [pipewire.org]
(Score: 1, Interesting) by Anonymous Coward on Friday October 15 2021, @05:53AM (2 children)
I really like Devuan and put it on my systems at home and work. It is like the Debian I used to love.
On my work systems I stay on stable, so this year I have been transitioning to Beowulf; I have some systems still on ASCII. My personal systems will probably go to Chimera soon.
(Score: 2) by Runaway1956 on Friday October 15 2021, @08:06AM (1 child)
Should I look at Devuan again? My first go-around with it seemed rough around the edges. Looked at a couple more, and ended up with MX Linux. Maybe it's time to test drive it again . . .
They have a fine assortment of ISOs available. AMD64 desktop live is 1.15 gig, netinstall at 405 meg, desktop iso at 3 gig, server iso at 642 meg, and a set of CD images. I would presume that you can install from the desktop live image, but it's only 1/3 the size of the desktop iso, which probably packages several desktop environments.
A guy has to do some research before he even downloads.
(Score: 5, Informative) by Runaway1956 on Friday October 15 2021, @09:18AM
Downloaded and installed the desktop live ISO. Smooth install, really, I took defaults all along the way. It comes with the XFCE desktop, looks nice. Meaning, no superfluous eye candy. Everything works as expected. The rough edges I mentioned have been knocked off of it, but maybe it's not really polished yet. I'd have to install some different DEs to say how much polish there is.
I think that based on what I've seen, I could recommend it. I don't see any option for a dark theme desktop, that's something I'll have to investigate.
In contrast, I downloaded and installed Elementary OS earlier. Very pretty - it's a macOS-alike. But, you have to search for everything, and a lot of it is unavailable. Here, in Devuan, I find all the applications I expect to find, and apt-get, aptitude, and synaptic all work like they are supposed to work. I've just installed all the plugins for Thunar, effortlessly.
Nice.
(Score: 3, Funny) by Rosco P. Coltrane on Friday October 15 2021, @07:02AM (16 children)
Are we still supposed to hate it? I thought that particular streak of online outrage was out of fashion by now.
Oh well, whatever floats your boat. I guess choice is good.
(Score: 3, Insightful) by Mockingbird on Friday October 15 2021, @07:15AM (4 children)
I am curious how you can ask this, after you laid out the problems with pulseaudio, which after all is the mother of systemd.
(Score: 3, Informative) by Rosco P. Coltrane on Friday October 15 2021, @07:55AM (3 children)
Well, I find systemd rather pleasant to work with and fairly stable. I mean sure, it has features that I dislike - chief of which are the non-plain-text logging and Poettering himself - but on the whole, I like the way it journals things, I like service files... I'm probably not enough of a power user to have a real informed opinion about it, but for what I do and the few packages I maintain, it's flexible and it just works.
Pulseaudio on the other hand... I don't care about it. I just needed it to do one trivial thing and it got in my way and wasted an entire afternoon. And yes... Poettering.
It goes to show that the same guy can code something I rather like and another thing I profoundly dislike. What a concept eh? :)
Bear in mind that I have nothing for or against either of those software packages. This is just my experience.
(Score: 5, Funny) by srobert on Friday October 15 2021, @03:51PM
"sure, it has features that I dislike - chief of which are the non-plain-text logging and Poettering himself"
LOL. I didn't know that Poettering was a "feature" of systemd. Some might say he was the bug of it.
(Score: 4, Interesting) by Anonymous Coward on Friday October 15 2021, @05:07PM
I've never had an interaction with SystemD that was pleasant. I've had plenty that were decidedly not. Diagnosing an unbootable system wasn't fun with initd, but it is nearly impossible with SystemD, happens much more frequently, and always turns out to be SystemD's fault.
(Score: 2) by edIII on Monday October 18 2021, @07:01PM
To each his own I guess, but SystemD introduces a whole lot of bullshit that just isn't necessary. I'm looking for security first, so I can't find a whole lot of trust in SystemD at this time. Maybe in 20 years if the code base was thoroughly vetted, but I doubt that will happen and keep up with all the new code.
That's why I like OpenBSD, because of the philosophy, the relative security provided by the code.
It's not that I hate SystemD, it's that I can't trust it for mission critical systems, infrastructure, and security. For a desktop OS being protected by all of that? Maybe.
Technically, lunchtime is at any moment. It's just a wave function.
(Score: 5, Insightful) by MadTinfoilHatter on Friday October 15 2021, @08:14AM (2 children)
Yes. Because it's still an abonination. :-)
Here is a pretty long but informative write-up of, both the kind-of-good ideas behind systemd, as well as why it ended up the way it did. systemd 10 years later; a historical and technical retrospective [darknedgy.net]
(Score: 1, Disagree) by shrewdsheep on Friday October 15 2021, @10:13AM
TLDR so maybe some of my points are not relevant. I believe it is important to distinguish concepts from implementation. A lot of criticism around systemd focusses on particular implementation. Conceptually at the time, it was very important to formalize and supervise the boot process. Also, performance improvements became important when a lot of daemons invaded the desktop. Finally, centralized logging is advantageous in many situations. Systemd ran fasted with these ideas (stealing from Mac among others) IIRC with alternatives coming in late. Systemd rightfully deserves crticism based on its architecture but which piece of software doesn't? It's a matter of fact that systemd has solved the mentioned problems to a satisfying degree and time has told. Making systemd more modular and configurable (e.g. format of logging files) is desirable and could be achieved within the systemd project. Or an alternative would come along, but it would have to be conceptually very similar.
(Score: 3, Interesting) by Runaway1956 on Friday October 15 2021, @10:45AM
Uh, wow. I've seen and/or used more than half the inits mentioned. Seldom interacted with them, TBH, but now and then, one of them stood between me, and something I wanted to do. And, each time, I had to search for documentation to figure out how to do what I wanted. Mission accomplished, I forgot everything I knew about each of them. It's surprising to see how many of them I've poked at!
(Score: 5, Insightful) by Anonymous Coward on Friday October 15 2021, @08:47AM (1 child)
SysVinit is old and creaky, and a new improved startup/init system is not a bad thing -- upstart, runit and openrc were/are all noble efforts to improve it.
But, all the usual systemd whining and complaints aside, I believe systemd (and Chrome/Firefox/Webkit as well) represents a significant and unforgivable sin: the forcible usurping of FOSS by corporate, profit-driven interests from technical passion/elegance-driven interests (I call them 'old-school itch-scratchers' here.)
Systemd is more than just a new startup/init system. It's nothing less than a needlessly comprehensive rewrite of the glue between the Linux kernel and userland, providing a full-employment program for a bunch of resume-burnishing for-profit developers and support-contract salesmen. Old-school itch-scratchers would *never* have attacked the startup/init problem in this way.
The big boys (except for Google/Android) can't make Linux proprietary, so this is how they take control. IIRC the Pale Moon guy has basically gone on record saying that it's no longer possible for old-school itch-scratchers to build a new browser from the ground up due to the corporate-induced accelerating growth in the standard's size and complexity.
I salute the Devuan itch-scratchers for their herculean efforts, but I'm certain they will falter once enough systemd-dependent features are infused through the Linux app ecosystem. Users like the new shiny and will never care what it looks like under the hood. Of course I hope I'm wrong about this prediction. [/rant]
(Score: 0) by Anonymous Coward on Saturday October 16 2021, @12:11PM
(Score: 0, Interesting) by Anonymous Coward on Friday October 15 2021, @09:31AM
People have moved on/away. Hating on systemd is no longer sexy, but I'm sure it will come back into fashion one day. Meanwhile, Debian still ships sysvinit, Gentoo has elogind, Guix uses shepherd. Some run Devuan/MxLinux/Antix, and some have moved to FreeBSD.
Personally, I use s6 as service manager, but it does mean writing my own service files. That's not that big of a problem, because I already have everything stored as code, and storing a runscript along with the package/service configuration isn't that much of a problem. I mostly like how s6's use of exec chaining plays wonderfully with Selinux' concept of type transitions.
(Score: 0, Troll) by FatPhil on Friday October 15 2021, @01:33PM (2 children)
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 5, Insightful) by maxwell demon on Friday October 15 2021, @02:00PM
The systemd version of Devuan is known as Debian. You do have the choice.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2, Touché) by Anonymous Coward on Friday October 15 2021, @02:00PM
Isn't Devuan with systemd just regular Debian though? There's already that choice.
(Score: 4, Funny) by Anonymous Coward on Friday October 15 2021, @01:35PM
>> Are we still supposed to hate it?
Not necessary any more... Poettering's added self-loathing functionality to systemd as part of his neverending feature creep.
(Score: 1, Touché) by Anonymous Coward on Friday October 15 2021, @03:50PM
Those of us who hate systemd have moved to systems that give us an alternative.
(Score: 0) by Anonymous Coward on Friday October 15 2021, @03:02PM (1 child)
Devuan dropping Wicd caused some hiccups with the WiFi until I removed Network Manager. cmst seems to work now. The other glitch was Pale Moon running really slowly after the Chimaera update. Disabling Hardware Acceleration fixed the slowness. Not sure why it worked fine on Beowulf.
(Score: 2) by hendrikboom on Tuesday October 19 2021, @02:28AM
Wicd disappeared from Devuan because Debian dropped it.
Debian dropped it because no one had ever gone to the trouble of rewriting it from Python 2 to Python 3.
There is a project to do that rewrite, but there are snags. When that's finished, Devuan will probably become the upstream provider for wicd.
-- hendrik
(Score: 0) by Anonymous Coward on Friday October 15 2021, @05:40PM (1 child)
My beowulf .iso torrent is stuck, ratio'd at 0.9, so I guess that's the end of that dream.
(Score: 2) by hendrikboom on Wednesday October 20 2021, @03:35AM
Download the smallest .iso you can get away with, and use the package manager to install whatever else you decide you need. That way you'll only be downloading what you actually need, and not what other people expect you to need.