Yeah, ideas and projects are often dismissed due to coming from the systemd group.
For this very reason, I'm rather bothered that gummiboot was renamed into systemd-boot. It's a very simple, nice tool, that's usable in plenty of non-systemd environments... but the naming just makes it unpopular with the crowd that doesn't like systemd.
I didn't even realize you could use it outside of systemd. I never looked at it in detail, but if something is named systemd- then I think "part of the systemd suite and intended to be used with systemd" is a fairly reasonable assumption.
I'd still be hesitant to use it to be honest, as systemd has on several occasions broke people's systems and the response was "you're holding your phone^H^H^H^H^H systemd wrong". Well, maybe, but you broke my system and before it was perfectly fine, and that's kind of an issue for me. Especially with something as critical as booting my system, I want to be able to just rely on it without breakage "because I was using it wrong". Linus' "we don't break userland"-policy was a great piece of insight. I wish systemd had a similar attitude.
Some of the systemd criticism has gone off the rails (...and then some...), but there's a number of things one could reasonably criticize about the project and development style, IMHO.
Systemd-boot is a dream. Why anyone would tolerate or think grub2 is an acceptable piece of software is beyond my understanding.
grub.cfg used to be human editable, but has evolved & morphed into some massive gnarly twisted mess of inscrutible noise that only multiple layers of shell scripts can output. It's become a write-once-read-never disaster.
And if i recall it's not even live. You still have to install that config.
Systemd-boot (nee gummiboot).is such a huge breath of fresh air. Simple senisible plaintext entries that one cam modify in any old text editor, which have immediate effect. It's so pleasant & simple.
Alas debian doesnt seem to ship any hooks for updating systemd-boot with kernel updates. There's a shell-script to write/remove the entries but one has to go write their own hook & figure out the variables to marshal into the script's arguments. Please Debian!
Oh yes, grub is a pain; no argument there. I didn't even like grub 1 and in grub 2 it got several orders of magnitude worse.
I did almost use systemd-boot a few weeks ago though; I moved my SSD to a different laptop and that somehow accidentally booted some remanent of the Windows boot manager, which automatically and helpfully hijacked the lot and now it didn't boot in either the new or old laptop. I ended up using Grub as my distro doesn't provide systemd-boot at all (let alone update hooks), and aside from the hiccup a few weeks ago I haven't had to look at it in over a decade; so for all its ugliness it does "just work" for me, and I figured looking at alternatives would be a bit of a waste of time.
I miss the times where I used FreeBSD and the MBR bootloader they had (have?) just automatically detected things and it would always work without any keffufing about. Just dd these 512K to the start of your disk and presto!
I loved grub (1)--being able to fix a boot configuration issue during boot time was such a amazing upgrade over lilo. When I first saw grub2 and learned how it worked it struck me as the platonic ideal of the second system syndrome[1]. Everything about it was more complicated, expansive, configurable. The fact that they need `grub-mkconfig` is a sign that it went horribly wrong.
I had not heard of systemd-boot, I will check it out…
> I didn't even realize you could use it outside of systemd. I never looked at it in detail, but if something is named systemd- then I think "part of the systemd suite and intended to be used with systemd" is a fairly reasonable assumption.
The tight coupling of systemD is a popular criticism of it.
And this is another fine case demonstrating how very very wrong that criticism is.
All in all extremely few systemd subsystems require systemd. Systemd's pid1 requires only one subsystem, journald, which one can mostly disable/defang if they really dislike it.
It's much more like a monorepo than monolith. There's standard practices & libraries between the projects- unit files, ability to ask for machine readible outputs, others. But these cross cutting concerns mostly get compiled in. The actual interdependencies between subsystems are few & far between. Feels like the critics dont really understand what they are trying to criticize.
You say this, but systemd-udevd at one point would sigkill every process on the system if it was not started under systemd (or otherwise in its own cgroup).
Considering the massive amount of unnecessary and unjustifiable trouble that so many people have experienced over the years with systemd and PulseAudio, it's no wonder people would distrust everything coming from the developers and proponents responsible for such software.
That's really unfortunate naming then. Any systemd-foo that "works on it's own" is (rightly) assumed to be tightly coupled to the rest of the systemd ecosystem.
As somebody who really does not care either way, all this just sounds more like moving problems rather than solving a problems. At least, I don't think there are many Linux systems where you can safely remove /bin from the path just yet. I just checked. My Manjaro install has a /bin and it is full of files that look like I would not want to lose them. So, they fixed the /bin to /usr/bin thing for some packages but clearly not all packages in Arch. I bet/blindly assume that's true in Fedora as well.
I've always struggled with figuring out where stuff lives on the file system in different linux and unix derivatives. It's never where you expect/want it to be. I've used solaris, hp ux, mac os, and linux over the years. They all have similarly named directories, mostly for weird historic reasons. Is it /var/usr/god/knows/what or in /opt/foo/bar or in /usr/var/lib or /usr/share/lib. What about /etc, /usr/etc, /usr/local/etc?
You can take almost any 1,2,3, and 4 symbol permutations of share, lib, var, bin, opt, and sbin and probably find something that expects files to exist under that path. Reducing the number of permutations would probably be helpful.
People seem to just roll the dice and create some place where shit lives based on mostly just vague intentions, rules, heuristics, and interpretations of those associated with long dead unix variants from the nineteen eighties, weird naming conventions, and what not.
So, what's the rule here? Some 'special' packages should install to /bin and some other not 'special' packages should install to /usr/bin? Why? Is there any agreement about what constitutes a 'special' package? Is there a good functional reason for having both directories? And then the whole bin/sbin distinction is kind of arbitrary as well. Some binaries are statically linked, others are not and require libraries to exist in yet more shared directories on a library path. It all boils down to users requiring a PATH variables (and, inevitably, a lot of other/similarly named variables). And of course the order of paths is also super relevant and kind of the point. So you look in /usr/bin before or after you look in /sbin? It's all a house of cards. Brittle by design and convention.
The notion of taking a package and then fragmenting it over a multitude of shared directories is the problem that needs fixing. The role of a package maintainer is bridging those different notions of where stuff should live between different distributions with some convoluted scripts. It's a job that should not need doing and code that should not need to be written.
The main differences between linux distributions boil down how none of them actually having solved this problem that ended up doing only loosely similar but clearly different things for mostly obscure reasons. They don't agree on where stuff should live, how it should be moved/copied/linked there, where and how things are configured, etc. Most of these differences are kind of arbitrary and petty. /sbin, /usr/bin, /usr/sbin, /bin, /usr/local/bin, etc. who cares? I pretty much need all of these in my path for things to work as intended. I don't see a good reason for more than 1 of these to exist.
Apple kind of got this half right with the notion of mounting a package rather than installing it. Most applications install/uninstall via drag & drop. I always thought that was a neat idea. Of course, they then made it complicated by having /User/<uid>/Library/* and /Library/* directories anyway. So, most applications leave a lot of clutter there after you drag them to the trash-can. And they also have the usual contingent of unixy directories. And package managers like brew, macports, fink, and whatnot that sort of carved out different places in the filesystem where their stuff lives. So, I wouldn't go as far as saying that Apple solved the problem. But it does look like progress to me.
Mounting stuff rather than fragmenting it all over the place is progress. Docker does this. And so do Flatpak and Snap. Flatpak and Snap are kind of tedious in their own way (e.g. opencl support is a PITA with Darktable and other packages that need that). But at least I have some stuff that I installed with those that actually works without having to be customized for every linux distribution.
> My Manjaro install has a /bin and it is full of files that look like I would not want to lose them. So, they fixed the /bin to /usr/bin thing for some packages but clearly not all packages in Arch.
I didn't read the rest of your long comment because this is incorrect.
/bin is a symlink to /usr/bin on arch. There are no files in a folder /bin. Any package that tries to install a file in /bin will throw an error that it conflicts with the filesystem package.
Arch goes one step further, there is no /sbin or /usr/sbin either. Both are also symlinks to /usr/bin
Well that's a recipe for a long drawnout battle