systemd begrudgingly drops a safety net while a challenger appears, GNU Shepherd 1.0 Everyone's favorite Linux component has hit a milestone, while a fresh contender comes of age – with a touch of Lisp. In news that is sure to delight the Linux world, version 257 of systemd has arrived. Just a day before its release, a major new version of another Linux init system came out, GNU Shepherd version 1.0. They're …
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.
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.
"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.
As regards Windows servers, I'm sure there are plenty of old hands out there who learned how to do the job and do it well without powershell - given how late to the party Microsoft were with that one - but I've spent god knows how much time cleaning up messes caused by giving people who can't be trusted with it shell access. It does rather feel like if someone doesn't want to learn the basics, giving them the power to do real damage is a bad idea, and that's a problem that is most definitely not solved by getting them to understand less.
Naaah, it's more than that.
GUI and helper UI's can be written that simply modify underlying config files. If there are capabilities lacking, new subsystems can be written that use config files that the GUI can then modify - I.e. separate the os-configuration code from the actually os-running code.
There's no need for one big monolithic(*) slop to stick its tentacles into everything, including restricting access ability of logfiles.
(*) To the pedantic, I know systemd runs as a number of processes, and span many modules, but they are still designed to be used together in a monolithic lump.
"someone who doesn't know Powershell should be administering Windows servers"
Not a great example...WIntel folks were point and click long before Powershell existed...before we had Powershell we had VBS...and back then, if you suggested solving problems with a VBS script, you'd be burned at the stake for herecy.
I worked with a customer of the place I worked at who had many international offices and workers would travel between all of these locations all the time which made hooking up printers and file shares (each location had it's own local replica of the company data), the sites were all linked with site to site VPN connections...but it was a fucking mess, some users would end up connecting to file servers over the VPN connections or getting the printers from another site etc etc...anyway, I resolved the issue with a fairly complicated VBS script, which I wrote and deployed just because I was getting sick of the same problems over and over again...it worked flawlessly, but the head sysadmin laid a fucking brick when he saw it...I'd only been there a month, and I figured techies should just techie, thought they'd be pleased with it...well I've never seen anyone rant quite like that before or since.
I can't recall exactly what it is he was ranting about, I'm a millennial, so I'm only 50% present at the best of times, plus I was quite young back then, late teens early twenties, so I was laid back as fuck, people used to think I was a pothead I was that laid back, but I wasn't (even now people freak out when the shit is hitting the fan and I have zero concern on my face, I just fix things it's all good, I did a ransomware rescue / clean up for a company that is now a client, but wasn't at the time, I was just enjoying it but people thought I wasn't taking it seriously...I was, I just don't panic)...anyway, the rant went on for quite a while...they did ultimately keep the script, but they made someone else responsible for maintaining it...it never worked properly after that presumably because nobody else knew anything about VBS. At one point I discovered that the script appeared in multiple GPOs, presumably because they couldn't find the GPO where I'd put the original script, even though I'd documented it...there were like, 3 different versions of the same script running which took us essentially back to square one with all the random incorrect mapping bullshit...they took my privileges away so I couldn't do fuck all about it.
"It's a complete and absolute nightmare."
Your use case is not the usual ones and I don't recall Miguel Van S's initscripts guaranteeing anything either. OpenRC and initscripts? Nope (maybe with some twiddling). Daemontools - lol!. Upstart - yes ... lol. I've seen a lot of inits. *BSD too (I won't bore the audience).
Synchronous boot is basically dump everything and run everything from rc.local or autoexec.bat and config.sys. That is not what my laptop or desktop or servers needs.
However, I do know but have not played much with it, that systemd units do have a very rich set of dependency semantics - if there are bugs then report them politely. I have found the systemd mob pretty decent to talk to and responsive.
You do have a valid use case (obviously) but is is not the usual one. Systemd is really well documented and I do know that if you find behaviour that deviates from the docs they will either fix the docs or the code! There are quite a few tools provided too to profile what happens during boot, including things that will spit out unit orderings and timings and flame graphs and the rest. Their docs are vast and wide ranging and well worth reading.
At least one of the devs (some German bloke) hangs out on Masto and is quite approachable.
> There are quite a few tools provided too to profile what happens during boot, including things that will spit out unit orderings and timings and flame graphs and the rest.
I've tried to use some of those profiling tools way back when, and maybe if one is very knowledgeable about systemd structure and inner workings, they can be helpful.
Or maybe they've come a long way since I first tried to dig into them circa CentOS 7.9 and RHEL 8.1 .
But at the time, the syntax was convoluted and the results were not at all illuminating or helpful towards solving the problems.
The docs felt similar. Yes, there were a lot of things written, about multiple topics, but at the time it was kinda all over the place; examples were sometimes either scarce, or too simple/trivial. Common problems that people in many online forums and mailing lists asked about back then seemed to not have clear or definitive answers, e.g. "how to start XYZ after the network is up", and whole blogs were written about why systemd would not do that.
Again, maybe systemd has come a long way since then. Maybe these days bugs are met with more helpful responses than "you're doing it wrong". I hope so, for others' sake, at least.
> Your use case is not the usual ones
AKA "you're not using it right"
That right there is the problem with systemd (and rust, from what I can tell)
I asked how to have my photos downloaded and renamed when I plugged in my camera, which masquerades as USB mass storage.
The answer was "why would you want to do that?"
Err...Holding the sharp end of a knife to hammer in a nail with the handle is both the wrong use case and using it wrong, but they are not the same thing.
If I hold the sharp end of the knife and try and cut something with the handle, then I have the correct use case, but I'm using it wrong.
If I pick up a fork by the handle and try and eat soup with it, I'm using the fork correctly but I have the wrong use case.
Using it wrong and incorrect use case are not interchangeable.
This is totally irrelevant when you consider that you didn't even ask the right question. I can see what you're trying to do, because I am not 24/7 in systemd land...I'm a real boy...but people that live 24/7 inside their own tech bubble might not be able to see beyond the bubble.
"I asked how to have my photos downloaded and renamed when I plugged in my camera, which masquerades as USB mass storage"
The problem with that request is that systemd can absolutely automate that, but you need a script first in order to automate it...what you're asking here is a shell scripting question with some lightweight systemd stuff to wrap around it, not an entirely systemd related question. You probably came off as someone that wanted everything done for them, not a solution to a specific problem or request.
If you had asked "How do I trigger a script when a device is plugged in?" you might have got a better response. The difference is, you've already done the legwork and got a working script and all you need is a quick intro to creating a systemd service that executes the script when a udev rule is triggered...two very valid systemd related things...copying files, renaming them etc...that's shell scripting dude has nothing do with systemd.
What you implied with your question is that you didn't even want to go as far as shell scripting, you wanted systemd to do everything internally without any external scripts...which is mental and not what it is designed for...hence "why the fuck would you want that?".
That would be something which the dev team could-and-did imagine when designing/implementing/modifying Systemd. As they lack omniscience, there are cases where Systemd won't work properly for its users.
As I, too, lack omniscience, I try not to put needlessly-limiting things in my programs.
My experience with Systemd was in a used laptop which came with the latest version of Mint Linux. Systemd worked invisibly for me until the day it refused to boot. The console message indicated Systemd was trying to access my disc, but could not, and there it hung (I was not using encryption).
I booted Knoppix from external media, copied off all my data, installed a non-Systemd distro, and went on from there.
All sysdtemD does for ME is get in the way, especially on embedded things (like devices with an RPi as the controller). it's WORST feature is the default config, when you spend HOURS trying to figure out what it did that causes your serial port to get noise on the line (turned out some stupid MODEM SERVICE started and fornicated the serial connection and if I recall correctly I had to disable MORE THAN ONE THING to FIX it).
In any case if you are doing something OTHER than setting up Poettering's personal laptop (alluding to a similar comment in another post in this thread) it's QUITE POSSIBLE that something easily done with SysV init weil take bastardized workarounds or not be possible at ALL...
[try setting up the network to be either an AP *OR* a client, support scanning to set it up, AND optionally use an ethernet port instead of OR along with it, and see if you can leave systemD and it's minion processors to do it... so I shut them OFF and use the remnants of SysV networking and shell scripting invoked by rc.local]
Still I should have a look at the new GNU thing, find a distro that has it, test in a VM, etc.
> 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
This is something I usually expect to see from German programmers and is bad enough that it has a name: "The Teutonic blind spot"
Defined as "We don't see why you need/want to do that, so we won't do it" (See: Cupholders - and when they DO implement it, the results tend to be baroque overcomplication rather than utilitarian)
> Some times it absolutely does matter - especially when dealing with embedded systems
Oh yes, tel me about it.
systemd was written to make a mans laptop boot faster, not written to actually run an OS that does real back office stuff.
Where I work we have some reall old datalogging hardware mixed with newer stuff etc and the old hardware is very, VERY strict about how it should connect to things and WHEN. Having systemd run stuff before its supposed to, even when WE CONFIGIRED IT NOT TO can end up in the dataloggers internally getting into a state where they will not talk anymore, as basically the connected computer started talking what the datalogger thought was gobledegook and it was never coded to handle asyncronous errors like that.
I used to work on a batch processing system, running IBM i. There I learned the value of having a totally REPEATABLE and PREDICTABLE boot process.
Indeed, especially with all the crap systemd does now it means that OpenRC on Gentoo and especially Alpine boots in a fraction of the time.
Plus if many systemd users took a chance to run systemctl and try to work out exactly what each one of those units was for, why and what its doing, they would soon realize they are over their heads with complexity.
How can the majority consistently always be so wrong when it comes to computers...
"Eleven seconds"
What does dmesg imply your boot time from OS start really is?
I replaced OpenRC on my Gentoo boxes with systemd. I used to love the flexibility of a symlink or two and conf.d/net. Back in the day, I had quite a funky set up on my laptop which used a sort of multi link ppp through my and my wife's mobiles to get to the internet if they came within range and wifi was not available.
Roy Marples (Uberlord) was a lovely chap (RIP).
I get to write units that will work badly but consistently badly on all nearly all Linux distros these days.
"Roy Marples (Uberlord) was a lovely chap (RIP)."
Unless I've missed an announcement he is still alive (yes I'm aware of his ongoing health issues) - his GitHub dhcpcd repo shows a comment made by him last week: https://github.com/NetworkConfiguration/dhcpcd/pull/383#discussion_r1874393561
> if many systemd users took a chance to run systemctl and try to work out exactly what each one of those units was for, why and what its doing, they would soon realize they are over their heads with complexity.
Can confirm, at least somewhat. I've been through that, along with various systemctl blame/analyze/whatever incantations, to try to understand what systemd was actually doing, and why, in some specific boot config setups we used a couple $JOB ago.
Suffice to say it was an exercise in frustration, not quite futility. Things that just worked for us in RHEL 6 got more complicated in RHEL 7, and broke altogether in RHEL 8 until we cobbled together some workarounds. That was admittedly a complicated config, but done out of necessity, and I'm glad to have moved on from it. But systemd and its components, plus networkmanager, generally conspired (against us, and each other at times) to turn a solid setup into something fragile and not well understood.
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.
The mainframes *I* used always booted completely after a crash. In four years, I experienced five crashes (all on the biggest system). After each one, when the system came back up, my terminal session came back just as it had been, with no data loss.
The Honeywell DPS/66 system they brought in for the freshmen and Business department to use was far-less reliable, and it had lost data -- but that was not a mainframe *I* ever had to use! :-)
It wasn't just big iron. The first computer I programmed, a DEC PDP-8/e, took about 30 minutes to boot to BASIC.
1. Toggle in the RIM ("Read-In Mode") loader via front panel switches.
2. Read in the BIN ("Binary Input Mode") loader via a short paper tape in the Teletype's paper tape reader. (< 30 seconds)
3. Read in the DEC BASIC interpreter program via TTY paper tape reader. (~25 minutes from start to the prompt, "DELETE TRIG FUNCTIONS?" [an option to free memory core space]) Start over with a backup BASIC paper tape if someone steps on the tail of the tape and tears it as it snakes across the linoleum floor.
(A) Yes, our original 4KW, all-core memory -8/e could be safely shut down to poweroff, and later restarted, without the need to reload BASIC each time. After we got our 8KW of MOSTEK static RAM additional memory, we could not. DEC BASIC stored something(s) important in the highest accessible, non-I/O-space memory, which after our upgrade, was in volatile RAM.
(B) Despite a large sign I had put up, reading, "DO NOT UNPLUG!!!", the janitor would each night invariably pull the wheeled audio/visual equipment the -8/e sat on, away from the wall so that he could dust-mop behind the cart. Of course, he pulled it far enough that the power plug came out of the wall socket.
> Did you know that you can implement SysV init in systemd using Before= and After=?
Did you know that the way systemd runs it can not actually guarantee that those parameters are honoured?
Did you know that each boot you get a different result?
With a real init system, things should start and stop in-sequence as defined. It must be repeatable, every time. Things like systemd were written to identify and parallelise what CAN be parallelised. ANd many of them can do that. But systemd didnt even get that right.
I mean when shutting down my PC I get the following behaviours:
1. it shutsdown really quickly.
2. It starts shutting down, but for some reason systemd wants to wait 5 mins for a process to exit.
3. It starts shutting down, tells me that systemd wants to wait 5 mins, so I mash the three fingered salute to FORCE systemd into submission but instead of KILLING the errant process that systemd obviously cant be assed to actually manage it decides to ADD MORE TIME as I mash the salute over and over, like its trying to punish me for wanting to tell it what I say it should do.
I installed Debian 12 on my laptop recently and switched it to openrc. No problems whatsoever.
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.
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.
Putting systemd aside, my simple selection criteria for a Linux desktop is if after I remove flatpak, snapd and pulseaudio (and it doesnt install jack instead ***) then it's a candidate. And a recent criteria is it runs under X11.
Lots of desktop's cant survive the removal of pulseaudio so I am currently very happy with Zorin.
My tested backstop once all desktops fail all these steps/criteria is Debian server, Fluxbox and tint2. Or if systemd becomes intolerable, Devuan server, Fluxbox and tint2
Peter
**** sure you can just brute force delete pulseaudio and jack binaries (if jack is installed instead) but to me it a philosophical test of the desktop developers.... can I get a pure ALSA only environment without getting nasty
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.
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.
> 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.
Try figuring out the crazy config locations for systemd.
Any normal admin would expect it all to be in /etc but nooooo, each distro lumps the unit files in strange places, like /usr/lib I mean wth?
With SysV init scripts you know exactly what happens in each runlevel, simply by listing a directory, weras with systemd you have to tralw through its output to try and put it all together.
Oh and as for journald, wow, how to re-invent the wheel. Simply running a standard grep over /var/log was simple enough, but now we have to trawl through the journaled output and learn its re-implementation of text string searching.
> Try figuring out the crazy config locations for systemd.
Take a look at https://uapi-group.org/specifications/specs/configuration_files_specification/ , which is the specification implemented by systemd. TL;DR: /etc takes precedence, then /run, then /usr/lib. This is also documented in the synopsis of the systemd.unit manpage.
> Any normal admin would expect it all to be in /etc but nooooo, each distro lumps the unit files in strange places, like /usr/lib I mean wth?
This allows package managers to install a default, vendor configuration file for a package, and then for a user to override it without having to deal with conflicts when upgrading the package. And /run is for transient configuration.
> With SysV init scripts you know exactly what happens in each runlevel, simply by listing a directory, weras with systemd you have to tralw through its output to try and put it all together.
`systemctl list-dependencies <UNIT>` can be used to get a nice dependency tree of a unit, for example: `systemctl list-dependencies graphical.target` shows every unit that is required for graphical.target (which I believe is the equivalent of runlevel 5).
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 (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 *XT*", just to hammer the strangeness home.
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.
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.
Yes I have. Overall I like it but I would prefer to use something I am much more familiar with. It's philosophy for doing things is just too different from the two Linux distributions I already use to have to keep up with. I also tried Slitaz which is similar to Tiny Core but it currently only officially supports the Pi 1. At least the AMD64 versions are up to date.
For network connections I use udev's 70-persistent-net.rules to keep everything the same between power ups and reboots. Not easy to use but with a few helpers like rules templates and a better way to get MAC addresses that could be fixed, and it requires sudo/root privileges to modify the rules file. I need to find out what it will take rules wise to get my secondary storage to do the same. I'm not sure it can be done due to BIOS fiddling with those bits. I assume UEFI has a method to deal with this and that using UUIDs in a rule like GRUB does might allow it to work with BIOS too.
And off topic but something I've been wondering about for quite a while now, can somebody explain to me how sudo using - user_name ALL=(ALL) ALL which seems to be how it is currently configured in most distros is more secure than root? The only thing I see is that sudo will eventually kick you out and you will have to reenter your password where as root is forever or logout which ever comes last(?).
"can somebody explain to me how sudo using - user_name ALL=(ALL) ALL which seems to be how it is currently configured in most distros is more secure than root?"
Or just how the hell only having to crack one password instead of two for full control is more secure either.
Well therein lies the problem. It started as an alternative init system. And since then, it has grown like a cancer to replace stuff that never needed replacing and fix stuff that never needed fixing. And bringing a whole tanker of shit with it.
It is an ego project for some wanker that just can’t leave stuff alone.
What’s infinitely more fucking annoying is that almost all the Linux distributions jumped on the wank wagon and decided to use it. Fuck-knows why! Maybe the maintainers got back-handers to do so, or they’re just bloody morons. I don’t know
Yes I did. I wasn't thrilled with it using busybox. I have used and even compiled busybox before for other, older ARM SBCs and found it to be useful but lacking some things I use. And I much prefer BASH over ash. My NFS file server uses BASH for the file backup program mainly for the user interface and overall operation with rsync doing the heavy lifting. There are several BASH "features" that I use and I just find it a better fit. I have(had?) a bigger problem with musl which I have also used albeit more than a few years back. Still, I might end up looking into Alpine although I will need to write a BASH program to sync the portable NFS server with the home one when needed.
$ ls -la /bin/bash /bin/dash
-rwxr-xr-x 1 root root 1234376 Mar 27 2022 /bin/bash
-rwxr-xr-x 1 root root 125560 Dec 10 2020 /bin/dash
Pretty similar situation with memory usage. All that extra code is for interactive features, none of which is useful for batch processing (plus one or two trivial syntactic "features" to convince you that you need it).
My _shell_ is bash, all my batch scripts are run in dash.
"And I much prefer BASH over ash. My NFS file server uses BASH for the file backup program mainly for the user interface and overall operation with rsync doing the heavy lifting. There are several BASH "features" that I use and I just find it a better fit."
You are aware that Bash is packaged for Alpine? You don't have to use ash as the shell...
"I have been using Linux since the 0.99 release from a Linux Systems Laboratory distribution (circa 1999 I think)"
Wondering exactly which distro that was as the name's not famiiliar, and why it had a 0.99.x kernel in circa 1999.
I remember using the 0.99.x kernel but that was back with SLS or Slackware distros in 1992/93, by 1999 the 2.2.x kernel was out.
It was one of the first full Linux distributions, even before Debian. It had the 0.99 version because that was what was available at the time. It came on nearly 50 - 3.5" double sided/double density floppies (I still have one or two lying around somewhere) and the Adaptec AHA-1542 SCSI controller driver sucked. It would randomly insert 16 0xFFs which just happened to be the size of the boards data FIFO into the buffer. I know it was the driver because I had written DOS and DOS extender (Phar Lap) drivers for the same controller (as well as the WD7000) and my drivers did not have that problem. You probably don't remember it because it wasn't around that long. After a year or so it was supplanted by SLS Linux which is still around and started at about the same time. Ah, those were the days.
Your earlier reference of "circa 1999 I think" seems to be completely misleading based on your other comments.
"It was one of the first full Linux distributions, even before Debian."
Debian first came out in 1995. AFAIK the 1st Linux distro was MCC (Manchester Computer Centre) Linux in 1992, SLS Linux also came out in 1992, Slackware followed in 1993. I used all of those distros at the time.
Your description of "It came on nearly 50 - 3.5" double sided/double density floppies" makes me think you're referring to either SLS or Slackware in 1992/93 rather than 1999.
> As far as I can tell there are no other versions of Linux that run on the Pi that do not use systemd.
MX Linux runs on the Pi 5 and indeed I have it on mine.
So does Alpine Linux and it's high on my list to try, since I like Alpine, and most of the stuff that won't run on x86 Alpine doesn't exist for Arm anyway.
> the 0.99 release from a Linux Systems Laboratory distribution (circa 1999 I think)
I really doubt that.
Kernel 0.99 was _very_ early: it was out in 1992.
I started experimenting when the kernel got to version 2.0 in 1996, with Lasermoon Linux/FT and Slackware, and by 1999 the kernel was on version 2.2 and SMP was starting to work well and scale properly to 4+ CPUs.
Looking for info about "Linux System Laboratory" one of the only posts I can find is also you!
https://www.linuxjournal.com/content/big-thanks-our-subscribers
Otherwise I can't find any references to this distro.
Could you be inverting the acronym and then back-forming a nonexistent expansion of the name?
Instead of LSL, could you really be thinking of SLS? The Softlanding Linux System was the first ever
distro that I know of. Wikipedia is more cautious.
https://en.wikipedia.org/wiki/Softlanding_Linux_System
SLS came with kernel 0.99 so that fits too.
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.
> to rewrite something someone else didn't like (or thought he could do better)
Yes, this is absolutely why I have stayed on Linux for the last several decades. Tried and trusted stuff suddenly works even better, I don't find it pulled and replaced by some dumb "smart" shit all the time.
And if some retard does try that trick on me, there's always the forks of what just works - like Devuan from Debian, and MATE from GNOME 2. I just wish someone would fork a Firefox that defaults to Classic skin.
A slight variation on that would be OpenOffice to LibreOffice. In that case the owner of the original OO had more or less lost interest in it. A more recent development in the ....Office world is to provide a ribbon interface for those severely bran-damaged by exposure to Microsoft products, the latter, of course, being a prime example of a dubious re-write although, I've always suspected, for quite nefarious reasons.
whaaaa? Maybe it's more stable now, but Linux is the worst Unix variant for trying the "new shiny shiny" for no reason.
Rather than fix the broken OSS implementation, lets start a new one from scratch! ALSA
Shove a few pulseaudios on top, sprinkle in a systemd,
devfs -> udev
IP / ip2 bollocks
And so many "open" API's are made totally linux-centric.
etc.
I've occasionally wondered if poettering started systemd at least partly because he couldn't be arsed to understand how to do some things that Linuxes had already been doing for a while.
Admittedly that's likely a better explanation for the non-init-related things that have been bolted on the side of systemd since it was first inflicted.
Yes, that, and also sometimes NIH "look what I did!" syndrome. Ego, essentially.
Plus, the perception that fixing / improving something is harder than starting from scratch.
Combine the two ideas, and you get "well I don't know how XYZ works but it obviously sucks and the people who wrote it are idiots; it'll be much easier for me to write a whole new thing because I'm a genius and everyone will love it."
"better tools for the job already existed."
Yes. I'll allow there could be a discussion to be had about improving Linux init/startup method, and daemon/service management. But I don't agree there was a need to rip & replace the whole smack with something entirely different.
I like sysVinit fine, as I'm comfortable with shell scripts, and the rc[runlevel].d structure is easy to understand, K & S symlinks and so on; likewise the tools (chkconfig, service, et al) are not complex and their syntax is pretty consistent.
I could say similar things about OpenRC and BSD rc, for essentially the same reasons.
The other trait they share is fundamental: they haven't lost the plot. OpenRC isn't trying to synchronize time, BSD rc isn't managing home dirs, replacing nameservice, cron, what have you.
And that's where "better tools existed" applies most, I think. Not that e.g. ntpd/chrony are "done" or perfect, likewise named/unbound/etc. But they (and others in their respective spaces) are good tools, with active maintainers and a user community relying on them.
I don't know or understand what kind of thinking leads someone to believe "oh, all these other things should be replaced, and my hammer is the only tool for all the nails"
My first systemd red flag was after keying 'init 0' and having to look up 'shutdown -h now' - "Uh-oh!", I thought "Verbiage - Earwig O!"
Most recently, having to revive rsyslogd - text logs are perfectly up to task, thank you very much. All the tools are there and solid, I don't want your journeld shite at all. SystemD has to be the most antithetic POS in the Linux realm. I use it as Debian's stability is a huge pull, and although I use(d) Devuan it was a bit too far downstream, probably due a revisit in-depth. I'll probably accept any downstream lag of Devuan purely to avoid systemd.
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)
Yep. When it is done for the right reasons - like the multiple rewrites of the Linux scheduler to work better on machines with more and more CPUs - it is a great thing. When it is done for the wrong reasons, because "I hate all the window managers so I'm gonna write yet another one" it is as best not actively improving things for anyone but yourself and at worst (like in systemd's case) actively making things worse for a lot of people when major distros like e.g. Fedora/RHEL decide to use it.
If someone wants to write something someone else doesn't like, might I suggest systemd? You don't need to rewrite the whole thing, just the part about parallel startup and enabling/disabling startup scripts. You can ignore all the rest, as 98% of it doesn't make anyone's life any better (except people like Poettering whose mission in life is to make Linux administration suck as badly as Windows administration)
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).
My last conflict with anything `systemd` was when I ran in to repeated problems on my development desktop. The box kept falling over, at random intervals but `sudo` also ceased working. `sudo` was failing because `systemd-homed` was falling over and I couldn't fix anything because, yeah, `sudo` wasn't doing the `do` part at the end. THAT was the final straw. That pushed me to migrate my desktop to (really: "back to") Gentoo, on OpenRC, which is the same thing that runs on all my servers. Alpine runs in all my containers (none of them have an init but some had `tini` in the past) and no boxen I maintain use `systemd`, today.
Since that point in time, the `xz` Thing came and went and I watched on, bemused and amused. Schadenfreude is apparently a healthy and necessary part of our human psychology. I can't imagine handing `sudo`'s responsibilities to the same supply-chain that let the `xz` Thing happen. I certainly can't imagine replacing the Kernel's SUID mechanics with their crap.
Not only because `sudo` and SUID, in general, do a whole lot more than *just* run commands as user 0. There's a reason why `sudo` became ubiquitous and the fact that `root` passwords no longer need to be shared (or even be set at all!) is only the very beginning of the very tip of an iceberg-sized point.
I read the news about Shepherd 1.0 and I do sigh, a little, and wish more journalists were mentioning it as an alternative to OpenRC and Sys.V Init instead of holding it up to `systemd`, though. Both of the latter actually are init. systems (and stay in their lanes) and I'm sure that Shepherd is intended to be init., too, not some sprawling, redmondian behemoth that also does a spot of init. by-the-by. (I'd say `systemd` contains an init. system but it seems to contain multiple components that all do some init. stuff, along with multiple mini-inits. Inits-within-inits. It's truly an oroboros. I'd say it's a misguided, cynical attempt to make an Eierlegende Wollmilchsau if I didn't love that German phrase too much to sully it with the association.)
So, dear Register: can we anticipate a good technical deep-dive into Shepherd 1.0 in which you tell me how and why it might, or should, one day replace my perfectly-fine-thank-you scripts in `/etc/init.d`? Those perfectly-fine-thank-you scripts just sit there and do their thing at init. time. I haven't had to "maintain" a single one in ages -- at least, not since the last time Wayland fell over and I had to sort of wrangle some things to get dbus+kwin starting, again. I can't really see the appeal of porting them all to something new: they're prefectly fine, thank you.
> tell me how and why it might, or should, one day replace my perfectly-fine-thank-you scripts in `/etc/init.d`?
They lost me at "Shepherd uses a dialect of Lisp for its configuration". Oh, bye.
Alas, the systemd base-system is actually something of a minority. It's really only on Redhat, Debian, and Arch Linux -- which might be a little bit of "most of them", though. Void doesn't use it, Gentoo presents the option, Devuan doesn't, Alpine doesn't.. there may be some others like suse, idk. Most of the other things people list that "do" are derivatives of one of these. The majority of distinct distros: don't use a systemd base-system. That's a bit of a comfort. (If you're creating docker images, don't `FROM ubuntu:latest`; do FROM devuan, alpine, or whatever else. Save yourself the headache.)
If you *do* need to use a Debian thing, then use Devuan. You might even be able to use those packages as a base for Ubuntu, or add the Ubuntu repos on top of devuan, but I honestly haven't tried.
"They lost me at "Shepherd uses a dialect of Lisp for its configuration". Oh, bye."
I've seen an example of a Shepherd init script and yeah, I don't see any advantage it has over shell syntax scripts.
"It's really only on Redhat, Debian, and Arch Linux"
Most of the "other" distributions are based on/forked off of the first two.
As I posted earlier, I went to Devuan as soon as it was released. I tried an early version of Debian's attempt to go systemdless and it failed to boot so that was the end of Debian. If I want to torture myself with systemd I boot up Linux Mint (based on Ubuntu based on at least originally Debian) which I quite like except for the systemd part of course.
I've been using a compromise of sorts with my Debian systems. That is, I haven't tried to do away with systemd altogether -- it seems at this point the patient would likely not survive the operation, as you discovered.
Rather, I've settled for mostly only using the systemd-as-init-replacement bits. E.g. if necessary, I remove or disable the systemd modules (units, whatever they're called) for time sync and resolved, and while I let journald continue, I typically install rsyslogd and rely on that.
I'm not entirely happy with this arrangement, but as I otherwise like Debian, I've learned to live with it. Over time I've gotten familiar enough with systemctl to query and manipulate services and such, in spite of the backwards verb-noun syntax, though I confess my fingers still tend to type 'service' rather than 'systemctl' as often as not.
My fear is this tenuous arrangement may not last, as systemd spreads further. But I've already migrated Red Hat-flavored Linuxes to Debian, and while I would be sad to leave Debian behind, I can move on from there too, if/when the day comes.
"Not only because `sudo` and SUID, in general, do a whole lot more than *just* run commands as user 0. There's a reason why `sudo` became ubiquitous and the fact that `root` passwords no longer need to be shared (or even be set at all!) is only the very beginning of the very tip of an iceberg-sized point.
As I'm sure you know sudo has been around for a very long time but the way it is used today in most distributions has nothing to do with it's original use. When you set the users permissions to ALL=(ALL) : ALL like most of them do you are for all intents and purposes making the user root and have completely negated the reason for using it in the first place.
> dear Register: can we anticipate a good technical deep-dive into Shepherd 1.0 in which you tell me how and why it might, or should, one day replace my perfectly-fine-thank-you scripts in `/etc/init.d`?
TBH: no.
If "config in Lisp" makes you think of a positive adjective, then go for it.
If it doesn't, as I suspect it won't for most people, don't even try.
If you are happy with what you have, then don't try to fix it. ;-)
No need for another init, really. No need becuase:
1- sysvinit works (workED because it's dead)
2- systemd has won the init wars, has become a global cancer, and no newcomer will succeed (*)
(*) at least until someone will manage to make a WORSE newcomer than systemd, then it wiil become the new standard. Maybe Oracle could try to outshit systemd?
I was a Devuan user, I have reverted back to Debian because nowadays anything that's not part of the standard Devuan repo NEEDS systemd, so no way to install third party software made for Debian/ubuntu on Devuan.
"I was a Devuan user, I have reverted back to Debian because nowadays anything that's not part of the standard Devuan repo NEEDS systemd, so no way to install third party software made for Debian/ubuntu on Devuan."
This is not my experience. Possibly the list of non-standard stuff we've tried to install differs.
I didn't miss them at the time, and I still don't miss them at all. :-)
From a pretty practical (operational) standpoint, my systems don't reboot that frequently. And perhaps more significantly, the system POST time (BIOS/UEFI initialization, device probing, etc.) for some of them is (sometimes much) longer than OS boot time.
The only time boot times _might_ be a genuine issue is if you have an autoscaling group in cloud ; if your boot time is too long, by the time you scale up, the spike in traffic has gone (yes Windows Server, I'm looking at you). Chances are though, if you are scaling that dynamically you would be better off using something cloud native instead of VMs to do the task.
But otherwise, my laptop gets rebooted in two situations: 1, I forgot to plug it in and the battery went flat, 2. Bios updates. Probably about once a month, I can live with that.
It contains an init subsystem, sure. But much, much more of the included functionality (sic) is doing other things. The article mentions that the new release "offloaded some old keyboard handling code to X.org". What? Is this the only "init system" in the world that wants to handle your keyboard?
Seems to me this tower of Babel mayhem is pretty much the last dyke of resistance holding-off the RotM. Standardize everything on Guile and we're toast ... GUIX, Hoot, Guile-Emacs, whiffle, guile-CLIPS, and then guile-Abel's* deliberative-reactive cognitive humanoid architecture for social control of the ▇▇▇▇▇ ▇▇▇▇▇▇▇!
*(check out Figs 1-6 and refs 79, 82 on page 9 of that mdpi pdf, but only if not faint of heart ... )
Yep! GUIX already combines GNU Mes bootstrap and Shepherd init IIRC. The Mes Scheme interpreter concisely replaces GNU Binutils, GNU GCC and the GNU C Library, self-consistently, making for a trustworthy bootstrap. Liam probably came across those at FOSDEM 2020 Brussels.
Mes implements Maxwell's Equations of Software, resulting in a clean, elegant, and fundamental first principles bootstrap process, with no fuss, no mess, and no dependencies (except HW-specific I guess). It seems better than software development performed as a linoleum laying process, over concrete, wood, or linoleum, imperatively, or with object-oriented camouflage.
Not sure how much of guile currently builds straight from Mes' Maxwell eqs though ... but it should be feasible to get it there. After that, we'll finally have the trustworthy, reproducible, homoiconic RotM we deserve! (eh-eh-eh!)
Well "systemd is an init system" has not been remotely accurate for ever now, so why would anyone think Pottering and his gang of Microsoft sleeper agents would care about systemd-tmpfiles not being a good enough name.
I'm surprised they even care about deletion of files, given their track record on response to user feedback.
The plan was never to port all the emacs-lisp code to guile. The guile VM is multi-language so the idea was to place the Emacs lisp VM with guile. The C layer would get called as it does now just by guile. The big advantage of this is guile is a compiled VM rather than a interpreted (but byte compiled) language like Emacs lisp. So a lot faster, in theory. Although as Emacs now also supports native compilation through a JIT (being used ahead-of-time, if that makes any terminological sense) that is perhaps less of an advantage than in the past.
I think you mean "third". OpenRC solves all of the problems with sysvinit that systemd was allegedly designed to solve, but does so without being a metastatic cancer that is slowly subsuming every other part of the OS into itself — or introducing any of the other problems systemd does. I shit you not, I wait every day for the announcement of systemd-kerneld (or some name like that) with which systemd borgs the Linux kernel. It seems like it's all just incremental steps towards PoetteringOS, the future OS that might actually be worse than Windows. If Poettering has his way, one day systemd will BE your OS.
IMO one of the most telling comments about systemd ever made is that if sysvinit were as monolithic as systemd is, it would have been impossible to develop systemd.
The Poettering group just made it with their CF of v256.
The short-sighted arrogance of that crew once again becomes obvious. I am completely dumb-founded how the Open Source communities and all of the distros still put up with their shite (especially now with the crap originating from within MS walls). Systemd should not be the default option and hopefully more people will start migrating towards distros that have alternatives as the primary approach. That would hopefully contain the virus that is systemd and minimize its influence in Open Source.
I am so glad that I stopped at CentOS/RHEL 6.7 (last version before systemd BS began) and went in a different direction (actually, several different directions) after that version for servers under my admin. (And I refuse to install, let alone use WSL on any Windows box that I am tortured to use - that's another CF just waiting to occur)
(For those not familiar with "CF" - ClusterF***)
Systemd is the product of a grudge Poetering seems to hold against Linus because Linus told Poetering to be consistent and improve his code quality. So we are saddled with an init system that expresses P's desire to destroy L, but which P does not appear to have the talent to actually push over the edge into being a kernel. It's more than an init system and it is less than an OS and it is slowly borging user space.
Many new init systems keep the script philosophy - just imagine! being able to just read what the system is doing - but use hard to read languages. Guile - FFS. ((Can (0)((((((()(())()())()actually)))read ((a(ny) of)this)?
What ever happened to Python?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
