hunger

SystemD replaced a variety of Linux init systems across different distros almost 10 years ago now but it is still resented by a significant and vocal section of the Linux community.

No, it is not. It is always the same few people that repeat the same slogans that failed to convince anyone ten years ago. But that does not really matter: In open source the system that can captures developer mind share wins. Systemd did, nothing else came even close.

That comparison is bad on several levels:

First off, systemd-the-repo does contain way more than an init system. But yes, I am pretty sure systemd-the-init is slightly bigger than runit.

Secondly: Systemd-init does set up some useful linux kernel features for the processes it manages in an easy and consistent way. That's why other services started to depend on systemd-the-init by the way: Systemd does linux-specific things developers find so useful that they prefer adding a dependency on systemd over not having the functionality.

Runit does not support any linux kernel specific features at all to stay portable to other unixes. Other alternative inits made the same design choice.

Thirdly: The overall attack surface of the system without systemd is bigger than a typical systemd system. That's because so much code run by the init system is way more locked down as systemd provides easy ways to lock down services in a cross-distribution way. Note that the lockdown functionality is 100% linux kernel features, so it involves little code in the init itself. Users of other inits can of course add the same lockdown features as service-specific startup code into the init scripts. We saw how well that works across distributions with sysv-init...

Finally lots of security features implemented outside systemd-the-init require a systemd system as they need the lockdown features offered by the systemd-init. One example is systemd-logind: That depends on systemd-init to be secure where the pre-systemd attempts all failed to archive that goal. Logind makes sure only the user sitting at a screen/keyboard can actually interact with the device interfaces of the kernel device files managing that hardware, so no other user but you can see ehat you type and take screenshots of your screen. Contrast that to devuans approach: Add all users allowed to start the UI to a group and make the devices controllable by that group. Much simpler, KISS and the Unix way... but it also allowes all users on the system that ssh into the machine somebody sits on can log what other users can type. Apparently that is not a problem, since no system ever will have more than one user in the age of personal laptops and desktops. That seriously isvtheir answer... and they even rejected to maintain the ubuntu-before-systemd logind replacement when canonical asked them, because such functionality is not needed im Devuan.

Librewolf

Maintaining a browser is a huge endeaver. Using some random browser that is maintained by a a lone person or maybe even a handful of developers basically guarantees that the whole thing is insecure. This is especially true when keeping functionality around that was removed in the "main" browser to improve security there. One example is the old plugin system that firefox replaced with a more secure one with less hooks into the core engine, breaking some old plugins.

Stay with mainstream browsers folks and install some plugins to improve them that way. At least you get patches asap.

supply chain attacks are a serious problem that needs addressing.

Last I checked: I am not a supplier. So I will not invest effort to secure some supply chain for people that I do not have any obligations to: The license clearly states "no warranty" for a reason. I do those projects for fun, not to bother me with security stuff, notifications about security problems some automatic thing "found" that do not really effect my code and bogus merge requests to upgrade dependencies for no reason... this are all cool things if you are a supplier, do not get me wrong, but I am not. No, I will not invest hours of my free time to sign binaries nobody uses either or to fill out security surveys for badges I can display on github.

If you want me to act like a supplier: Pay me like all the other suppliers you have. I doubt there is any interest to do so for the projects I have on my private github :-)

For your own projects, it might be worth considering a move away from GitHub. (I've been thinking about it since Microsoft bought them.) Codeberg looks like a good alternative.

That also has associated costs: Your project gets instantly much less visible, so you need to keep a mirror on github for visibility. Unfortunately that also means that you will also get interactions on github, so you will need to log in occasionally to not make people think the project is dead.

https://docs.rs/document-features/latest/document_features/ helps to document features.

But yes, features are under-documented.

Autsch! I would never do that... X11 is such a broken mess, but then my window management needs seem to be very different from yours.

Applications do have a say in how big they get rendered (typically by giving a min/max/preferred size), which window managers may or may not resepct/adjust for after the window comes up. Maybe it is just that.

Maybe you are running Wayland and not X11?

Where are those alternatives? I have not seen anything that is Baustoff convincing yet...

It is not a project owned by redhat... the lead guy not even works there anymore. So the more interesting question is: What happens if Microsoft closes down the project? The answer: It will be forked.

Not at all: I listed the arguments you will get for that question of yours. They all are bogus, as I tried to explain between the parens.

How is that different to when every distribution shoved their implementation of sysv-init into your face? You were never free to choose your init, it always came from the distribution. You could (and still can) replace the init system, if you are willing to do the work involved.

That's the whole point: Nobody is willing to do the work for one distribution, if they can just improve systemd and fix a whole bunch of distributions at once. That's why developers flock to the systemd umbrella project to implement their ideas there, which is why systemd keeps getting cool be features for the plumbing layer of Linux -- which is far more than just the init system.

No need to drag that BS from the archives. It was never correct nor convincing.