systemd begrudgingly drops a safety net while a challenger appears, GNU Shepherd 1.0
- Reference: 1734091331
- News link: https://www.theregister.co.uk/2024/12/13/systemd_257_gnu_shepherd/
- Source link:
In news that is sure to delight the Linux world, [1]version 257 of systemd has arrived. Just a day before its release, a major new version of another Linux init system came out, [2]GNU Shepherd version 1.0 . They're very different ways of doing the same basic task, and we're happy to see more options in this particularly controversial role.
The last version of systemd, back in June, merited special attention from The Register – it received two separate articles. The first highlighted an impressively tone-deaf attempt at a joke, when the [3]Fediverse announcement proclaimed that [4]Version 256 of systemd boasts "42 percent less Unix philosophy." A week later, a point-release followed: [5]systemd 256.1: Now slightly less likely to delete /home .
[6]
To recap that fun little feature, if you run the systemd command to clear up temporary files, and you don't get it exactly right, it totally wipes the entire tree of user home directories. The headline feature of version 257 indicates to us that the repercussions of that hilarious incident are still being felt:
The –purge switch of systemd-tmpfiles (which was added in v256) has been reworked: it will now only apply to tmpfiles.d/ lines marked with the new "$" flag. This is an incompatible change, and means any tmpfiles.d/ files which shall be used together with –purge need to be updated accordingly. This change has been made to make it harder to accidentally delete too many files when using –purge incorrectly.
In summary, the developers have made a backwards-incompatible change to the format of one of its config files, which they're reluctant to do. The change in the file-format makes it less likely that unwary use of the command systemd-tmpfiles --purge will remove all data for all users on the computer. So that's good.
The gist is that the [7]systemd-tmpfiles tool was named so because originally it was designed to manage temporary files. Since then, it's grown to do much more. It manages many kinds of files that are created and removed in normal operation of a Linux computer. Its config file, which is called [8]tmpfiles.d (and that link will tell you everything you could ever want to know about what files it can manage) now has a new specifier:
If the dollar sign ("$") is used, the file becomes subject to removal when systemd-tmpfiles is invoked with the –purge switch. Lines without this character are unaffected by that switch.
In other words, you have to specifically mark lines that describe the files that the purge sub-command will remove. It's a small enough change, but it means that if that config file doesn't tell it to, the command systemd-tmpfiles --purge now will not delete everything in every folder created since the first user was added. So that's good.
It is an absolutely minimal sort of fix, though. The fact is that the name systemd-tmpfiles is not remotely accurate any more. The tool no longer just manages temporary files. The developers could have made a deeper, more generally helpful change, such as renaming the command – but that would cause more breakage. (We suspect this probably is not function that is used often or by many people, but that's a separate consideration.) Whether this minimal config-file-format change, which does make things safer, is a better course of action than a more drastic, breaking one such as renaming a command is a judgement call.
[9]
[10]
It's fair to say that making the minimum possible form of change is a typical Unix sort of attitude. On the other hand, Apple's macOS is [11]still a certified UNIX™ and it's made many far more sweeping changes than this – and yet it's by far the most successful commercial Unix in history.
The other changes are mostly far underneath the covers, so to speak, and will likely be invisible to anyone who isn't maintaining a Linux distribution. The tooling around the [12]new Unified Kernel Image format is improved, cgroups version 1 and System V service scripts inch close to being deprecated, it now understands volume button presses on mobile phones – showing how mainstream Linux is moving into more pockets – and it's offloaded some old keyboard handling code to X.org. The feature that made us smile is that during shutdown, systemd hands responding to the classic "three finger salute" back to the kernel. So if systemd crashes during shutdown, with any luck Ctrl+Alt+Delete will still reboot your computer. That one sounds handy.
[13]
( The Reg FOSS desk's top tip for rebooting balky systemd-controlled boxes is that if you [14]press Ctrl+Alt+Del seven times within two seconds, it tells systemd to reboot immediately whatever is going on. Only try this if the machine's not shutting down normally as it might do bad things if it's not an emergency. It's also worth remembering the [15]REISUB keystroke exists too.)
Shepherding services for Guix
The other new init system in the news this week is from the GNU Project, and it's called [16]Shepherd . Shepherd itself isn't new. In fact, [17]development started in 2003, so it's old enough to drink in the US. What is new is that the development team has [18]released version 1.0 . To go with this milestone in maturity, it also has a new logo and website.
[19]Linux 6.12 is the new long term supported kernel
[20]FreeBSD 14.2 wants to woo Docker fans, but still struggles with Wi-Fi
[21]Wubuntu: The lovechild of Windows and Linux nobody asked for
[22]Elementary OS 8 'Circe' conjures Wayland magic
The main distinctive thing about Shepherd is that it's implemented in [23]GNU Guile . Guile is the GNU implementation of the [24]Scheme programming language , and it was intended to be the GNU Project's standard extension language. Indeed, its original name was GEL, short for GNU Extension Language.
It is not a famous part of the story of the GNU project, but before Richard Stallman turned his hand to building a free Unix-like OS, [25]he was a Lisp hacker , working on [26]Lisp workstations , and he still retains his fondness for the language even now. That's why a Lisp dialect is a core official GNU language.
Scheme is a smaller, simpler version of Lisp, originally designed for educational use. As we quoted when talking about the [27]revival of Medley/Interlisp , there are three main branches of the Lisp family tree: the stripped-down Scheme; Emacs Lisp, which is the extension language of the 800 lb gorilla of text editors, Emacs; and the heavily standardized Common Lisp. As [28]Steve Yegge memorably put it :
Scheme is an exotic sports car. Fast. Manual transmission. No radio.
Emacs Lisp is a 1984 Subaru GL 4WD: "the car that's always in front of you."
Common Lisp is Howl's Moving Castle.
The slightly odd thing is that although it's been around for 31 years, Guile still isn't the basis of the GNU Project's flagship app, the GNU Emacs text editor. Emacs's long and tortuously complicated development history saw it move through five or six minicomputer OSes before the first rewrite for Unix [29]by Java creator James Gosling . (The story has a twist you won't see coming, and we recommend reading the section from about page 30, or watching [30]Gosling's 2019 interview from about the 2:52 mark.)
The lowest-level parts of GNU Emacs are implemented in C, but that C is used to implement Emacs Lisp, and [31]nearly 70 percent of GNU Emacs is implemented in Emacs Lisp. You could almost say that the bulk of Emacs is implemented in Emacs. Moving it to Scheme would mean a total rewrite that would break an awful lot more user code than, say, renaming one systemd sub-command. There is an effort to do that total rewrite, the [32]Guile-Emacs project , and it was [33]relaunched this year .
Its use of GNU Guile makes Shepherd something of a flag-bearer for the Guile language and project. Additionally, Shepherd is the default init system of the [34]GNU Guix distribution .
Guix is both a packaging tool and a distro built with that tool. Guix has closely [35]comparable goals to Nix , and to the [36]NixOS distro built with it . It aims to automate away manual package management. The key difference is that while Nix has its own, unique language for writing config files, Guix uses standard Guile Scheme, and so in theory it's more accessible to more people. We say "in theory" because Nix itself is really pretty niche even in the Linux world, and we hear far more about Nix than Guix.
Shepherd [37]defines services in a restricted subset of Scheme. That is probably enough to immediately either win over, or forever put off, many people. Scheme uses Lisp-style prefix notation (yes, with [38]lots of parentheses ), which tends to polarize techies. If you like Lisp and Lisp-based systems, you might enjoy [39]Enzuru's Lisp-centric Linux distro , which is still under construction.
We doubt that Shepherd is going to transform the Linux init system landscape, but it's good to see one of the [40]alternative init systems taking a step towards greater maturity. ®
Bootnote
If the rather obscure pun in our subheading isn't clear, "Guix" is pronounced like geeks. So, no, Nix and Guix do not rhyme. They just look like they should.
Get our [41]Tech Resources
[1] https://github.com/systemd/systemd/releases/tag/v257
[2] https://www.gnu.org/software/shepherd/news/
[3] https://fosstodon.org/@bluca/112600235561688561
[4] https://www.theregister.com/2024/06/13/version_256_systemd/
[5] https://www.theregister.com/2024/06/20/systemd_2561_data_wipe_fix/
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Z1xoOP9jyF4FcyWCI7WEgAAAAFM&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[7] https://www.freedesktop.org/software/systemd/man/latest/systemd-tmpfiles-setup.service.html
[8] https://www.freedesktop.org/software/systemd/man/latest/tmpfiles.d.html
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z1xoOP9jyF4FcyWCI7WEgAAAAFM&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[10] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Z1xoOP9jyF4FcyWCI7WEgAAAAFM&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[11] https://www.theregister.com/2024/10/11/macos_15_is_unix/
[12] https://www.theregister.com/2022/10/26/tightening_linux_boot_process_microsoft_poettering/
[13] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z1xoOP9jyF4FcyWCI7WEgAAAAFM&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[14] https://github.com/systemd/systemd/issues/11285#issuecomment-450353249
[15] https://gist.github.com/genyrosk/795541ecb8ae7be70948561966d48ebf
[16] https://www.gnu.org/software/shepherd/
[17] https://lists.gnu.org/archive/html/guile-user/2003-04/msg00007.html
[18] https://git.savannah.gnu.org/cgit/shepherd.git/tree/NEWS?id=dd911ac772989a7630b9f4d58f8b747cbc1c33fe
[19] https://www.theregister.com/2024/12/11/linux_612_lts/
[20] https://www.theregister.com/2024/12/05/freebsd_142/
[21] https://www.theregister.com/2024/12/05/wubuntu/
[22] https://www.theregister.com/2024/12/04/elementary_os_8/
[23] https://www.gnu.org/software/guile/
[24] https://www.scheme.org/schemers/
[25] https://www.gnu.org/gnu/rms-lisp.html
[26] https://www.theregister.com/2023/12/25/the_war_of_the_workstations/_
[27] https://www.theregister.com/2023/11/23/medley_interlisp_revival/
[28] https://steve-yegge.blogspot.com/2008/11/ejacs-javascript-interpreter-for-emacs.html
[29] https://archive.computerhistory.org/resources/access/text/2019/10/102781080-05-01-acc.pdf#page-30
[30] https://archive.computerhistory.org/resources/access/text/2019/10/102781080-05-01-acc.pdf#page-30
[31] https://openhub.net/p/emacs/analyses/latest/languages_summary
[32] https://guile-emacs.org/
[33] https://emacsconf.org/2024/talks/guile/
[34] https://guix.gnu.org/
[35] https://www.theregister.com/2024/03/23/flox_1_nix/_
[36] https://www.theregister.com/2022/12/13/nixos_2211_raccoon/
[37] https://www.gnu.org/software/shepherd/manual/html_node/Defining-Services.html
[38] https://xkcd.com/297/
[39] https://github.com/enzuru
[40] https://nosystemd.org/
[41] https://whitepapers.theregister.com/
Re: 42% less unix philosophy
Did you know that you can implement SysV init in systemd using Before= and After=? You too can relive the days of 1980s big iron and 30 minute boot times...
Re: 42% less unix philosophy
Eh...
Systemd 257 released
Support for System V service scripts is deprecated and will be removed in v258. Please make sure to update your software *now* to include a native systemd unit file instead of a legacy System V script to retain compatibility with future systemd releases.
Re: 42% less unix philosophy
Try it. Seriously. Try and actually force systemd to do genuinely, completely, synchronous boot up with hard guarantees on every single component coming up in exactly the order you asked for and providing a signal that proves it did it.
It's a complete and absolute nightmare. The response from the systemd dev team when trying to do this is oftentimes "Well, why would you do that?" when we've filed bug reports, but frankly that's not good enough. Some times it absolutely does matter - especially when dealing with embedded systems with really quirky hardware. Boot speed be damned I HAVE to have these services start in precisely this order, and signal that they have done so. Systemd will absolutely lie about this in some of the weirder edge cases - and yes, everything has edge cases - but the good thing about sysvinit is that they're all odd bashisms that we know about and are easy to work around. When systemd does it it's really, really hard to get to the bottom of why it did, and even if you do and can prove conclusively that it's a bug, the systemd team will sort of shrug at you and suggest that it's not their problem.
Re: 42% less unix philosophy
"the good thing about sysvinit is that they're all odd bashisms that we know about and are easy to work around."
That's the thing. We , you and I and plenty of other commentards, know shell scripting. AFAICS systemd was written for people who don't know Unix shells but want to administer servers. It's questionable whether someone who doesn't know Unix shell should be administering Unix-type systems any more than someone who doesn't know Powershell should be administering Windows servers. Ill include myself in that last group and add that I'm grateful I've never had to do that.
Re: 42% less unix philosophy
Some of you don't remember the fun that was waiting for your mainframes to boot completely after a crash, which they didn't always do on the first attempt...
Re: 42% less unix philosophy
Oh yes, making it asynchronous is _much_ better for debugging.
Boot time fetishism is the _cause_ of systemd.
Re: 42% less unix philosophy
It must be more than 50 years since I've been a main user and never an admin. I have, however, been a Unix admin back in the day and not found them slow to boot. In fact the only problem I've had with getting a Linux boot working* was with Ubuntu#s upstart, which, as far as I can see, came from the same line of thinking as systemd with nowhere to put in debugging. It still mis-boot sometimes by claiming a disk isn't ready.
* In fact is wasn't so much the boot as getting the video working properly. It took a long time to discover that the monitor was telling porkies by pretending its screen was a PDA.
Re: 42% less unix philosophy
"Did you know that you can implement SysV init in systemd using Before= and After=?"
What would be the point of that?
Just deploy SysV init - better still, BSD init - and completely avoid the systemd cancer.
Re: 42% less unix philosophy
The core part of systemd (faster boot times by doing startups in parallel) is a great idea and if it had stuck to that, everyone would love it. Its tendency to spread tendrils into places no-one expects it is the issue and one which Solaris did with SMF. Using a component called "tmpfiles" to create persistent files and folder is always going to ask for trouble. Added to that, the tendency for its author to dismiss any concerns doesn't help its image.
Re: 42% less unix philosophy
The same author also made quite a mess with pulseaudio, so... yeah.
Re: 42% less unix philosophy
Ah yes, pulseaudio.
You WILL run pulseaudio as a user account on login!! You will not run as root!! ... but my machine is headless ... (four years pass) ... You SHOULD run pulseaudio as a user account on login!!! But if you need to run it as a system daemon, here's some documentation on how to do it.
Re: 42% less unix philosophy
"Its tendency to spread tendrils into places no-one expects it is the issue"
This assumes it was ever meant solely to replace init. As I noted elsewhere, that was just the excuse the camel used to get its nose in the tent.
Re: 42% less unix philosophy
Given the almost religious fervour of the init system debate...
They launched The Shepherd one point nought
It maketh me code in Guile
It seems to be like SystemD
While garnering much less bile
Yet though I drown in syntax strange
No error shall occur
For brackets, left and right will, through
My righteous belief, concur.
Re: 42% less unix philosophy
For the second line, shouldn't that be "It Guile in code me maketh"?
Re: 42% less unix philosophy
To be fair, I'd say basically adding a new way to rm -rf /, then changing the default behaviour in the next release to something slightly more sane and adding something akin to the --no-preserve-root option to get the old functionality back, is very much in line with the 1980s Unix philosophy. It's just taking the *bad* bits of the philosophy, is all.
But at what point does adding weird bits to a widely-used software package stop being just the developers being assholes, and turn into purposefully laying the groundwork for introducing exploitable security vulnerabilities at some future date?
Kind of like implementing an insufficiently-reviewed heartbeat extension to a basic security library that, of course, ends up having a security vulnerability that is revealed a couple years later. I've always been a bit suspicious of that one.
Re: 42% less unix philosophy
Just warming my hands with this bonfire you started...
originally it was designed to manage temporary files. Since then, it's grown to do much more.
Sums up the whole systemd philosophy, really.
I hope you don't think they're finished...
Also, i think 'metastasized' is more appropriate than 'grown'
I like your sense of tumour.
You deserve one of these!
Systemd was never intended solely as a replacement for init. That was just the excuse the camel used to get its nose in the tent.
What on Earth does that quote about Lisps mean?
I know what Scheme, Emacs and Lisp are, I've even used all three, but don't think I knew what a Subaru was in 1984 and wtf is a "Howl's Moving Castle"?
It would help if quotes meant to illustrate a point were understandable and didn't mention an obscure 40 year old car.
Perhaps it means: "this is not for you - try OpenRC instead" ;)
Seriously though, I have a lot of respect for the GNU folks, but IMO they have hamstrung acceptance of their software in two ways:
* Clinging to Lisp - hardly anyone used it in the '90s either
* Info system - rival to man pages using an obscure mark-up, with obscure keystrokes, and all docs split up into tiny pages of about five lines each
Lol, was thinking the same thing. "How many people, especially Europeans, would recognize the reference to the 1984 Subaru GL ( [1]Leone )".
Of course I did but then there's something (ok, a lot) wrong with me :D After all, he could have said "like a 1985 Subaru * [2]XT *", just to hammer the strangeness home.
[1] https://en.m.wikipedia.org/wiki/Subaru_Leone
[2] https://en.m.wikipedia.org/wiki/Subaru_XT
"Howl's Moving Castle"... it's a castle. And it moves. It's originally a book by Diana Wynne Jones, and the Studio Ghibli (Japanese animation studio) made an excellent movie of it.
People call Studio Ghibli the Japanese Disney, but I think that's an insult to Ghibli, to be honest.
Doesn't affect me
I switched to devuan a long time ago, so no SystemD fuckups. I also delete the pulseaudio server (from the same numpty) whenever I make a new install, so I get proper control of audio, and no weird beeps and farts from software that feels entitled to splurt all over the audio.
Re: Doesn't affect me
I did too, as soon as it was available. However I also use Linux Mint, mainly for the latest version of KiCad, but also to have some familiarity with systemd (as much as I would like to I just can't ignore it). I also have fought with it in a project I am working on to use a Raspberry Pi 5 as a portable NFS server for my laptop. Unfortunately Devuan no longer officially supports any Raspberry Pi and the unofficial version is 32 bit only and does not properly support the Pi 5 hardware. The latter is important as I use a M.2 SSD for the NFS drive. As far as I can tell there are no other versions of Linux that run on the Pi that do not use systemd. One of the things I find to be annoying is that when you change fstab you have to tell systemd that you changed it and to make the changes permanent. Please correct me if I am wrong but I thought that was what config files were for. Another is that I want to completely disable the normal console (HDMI output and USB keyboard input) and use only a serial terminal instead. I can find many, many examples of turning on the serial console with a Google search but none that tell how to turn the normal console off. Both of these are at least easy to do with a SysV init system.
I have been using Linux since the 0.99 release from a Linux Systems Laboratory distribution (circa 1999 I think) and along the way have used Red Hat, SUSE, PCLinuxOS, Debian (favorite until last, and a few other minor distributions and have NEVER had to write or fix an init script. I have looked at a couple trying to figure out why something wasn't working but it was never an init script problem. And while shell script programming syntax leaves a lot to be desired, it is not in any way difficult to use. This from a 40+ year C and assembly with some Basic, Pascal, Fortran and APL programming thrown in the mix, on multiple microprocessors/microcontrollers and PCs programmer. The APL program was in an Introduction to Computer Science class I took and was supposed to maneuver a bot in a maze. I think they were trying to weed out the weaklings or were looking for CIA/NSA/NRO/other TLA recruits. Finally, I have never seen any tests or had any personal experience that have shown systemd to have any great advantage in boot times. With the prevalence of SSDs now in use it takes longer for BIOS (I still have a few Phenom II-X4 955 black computers) and UEFI to finish the voodoo that they do than it does to boot Linux with either init system.
"There is an effort to do that total rewrite"
Obviously.
From the outside, it seems that 90% of coding efforts in Linux-land is to rewrite something someone else didn't like (or thought he could do better).
Re: "There is an effort to do that total rewrite"
That's because, at least in userland (the kernel, by contrast, will always need new drivers and there's been extra stuff such as real-time) is because it was good enough years ago. In consequence we have a combination of perfect being the enemy of good enough and the devil making work for idle hands. This, of course, is not a problem unique to FOSS; far from it.
Re: "There is an effort to do that total rewrite"
That's the joy/curse of 'freedom'. ;-)
Running Void Linux on my home server now, and that means no more systemd or glibc as I'm running the variant that uses musl for the standard C library. I've also installed it on a battered laptop that work were going to throw away, and it's a very pleasant experience once installed with the xfce desktop. As it's a "rolling" distribution there's not the headaches that I've experienced with upgrades to newer Mint or Debian versions (the last Debian upgrade I did left me with some GCC libraries from the previous release that could not be uninstalled - over time that completely borked regular updates and prevented me installing stuff due to dependency conflicts).
What's the alternative, learning to work together? Pshaw!
42% less unix philosophy
Is hilarious, given all the whingers thoughts on it.
Honestly - not having to work out exactly how *this* new distro specifies it's start up and service scripts vs another has been a godsend.