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: 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.