SoylentNews is people
SoylentNews
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.
Master of the science of the art of the science of art.
(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.
Master of the science of the art of the science of art.
(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.
Abortion is the number one killed of children in the United States.
(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]