- cross-posted to:
- [email protected]
- [email protected]
- [email protected]
- cross-posted to:
- [email protected]
- [email protected]
- [email protected]
After a few conversations with people on Lemmy and other places it became clear to me that most aren’t aware of what it can do and how much more robust it is compared to the usual “jankiness” we’re used to.
In this article I highlight less known features and give out a few practice examples on how to leverage Systemd to remove tons of redundant packages and processes.
And yes, Systemd does containers. :)
systemd is cancer.
Ah yes, a piece of software that people can choose to use or not use is just like an unexpected, devastating disease that no one in their right mind would ever choose to have and that causes huge amounts of suffering and can be incredibly difficult or impossible to treat.
Yep, cancer patients and survivors totally think having cancer is just like using systemd. 🤦🏻♀️
How on earth can you say that? Systemd, while not perfect, creates a system that helps newbies come in and understand Linux, helps Linux grow. Afterwards they can shift to a non systemd distro, but systemd provides a valuable tool.
Hmm that’s an interesting take on systemd. Not sure if anyone would be pivoting to a non-systemd distro after experiencing it… Well I’ve been using Linux before systemd and I wouldn’t switch back to what we had before simply because it makes my life easier in so many ways.
But yes, I see how less fragmented and more approachable a systemd distro will look for a beginner.
Not sure about this.
A new user probably don’t care (and rightly so) about how a certain service is started or stopped, it just need to work, which was true even before systemd.
Actually, its an opaque system that makes it much harder to understand what is going on because it’s a declarative file that is consumed in a non-obvious way by code written in c which is not going to be remotely comprehensible to them. Most people are apt to google for the magic incantation that appears to match their problem without understanding anything.
Not only are simple and easy not the same they are opposing interests in most actual practices.
I had an extremely simple Funtoo (Gentoo derived) installation it had bios boot -> 4 line grub.cfg with explicitly specified kernel and initrd. Making a kernel involved cding to the directory where the new kernel was making it copying a file and changing a text file to point to the new kernel. Understanding how software was built was work because you actually have to specify things you want vs don’t want but it was extremely simple. In fact everything was like that from boot, build, services. Anyone who took a few hours could probably trace it from the first line of grub.cfg to the last service starting up.
I have a more complicated void install that uses rEFInd -> zfsbootmenu . When a new kernel is installed dkms rebuilds modules and dracut handles preparing the boot up, updating automatically creates a snapshot and zfsbootmenu makes it possible to boot into a prior version of your OS. I set none of it up it was configured by an installer and when I messed something up it was a LOT more work to understand how it works and it was impossible to trace it from end to end without googling and reading documentation.
I have a single board computer running a derivative of Ubuntu. The official installation procedure that you are supposed to be able to do remotely doesn’t work at all so I plugged a monitor and keyboard to it loaded the image to a sd card and booted and ran the commands it said to run and it works without issue. It’s opaque but easy to use and if it ever doesn’t I’ll probably just reinstall the image from scratch and run the commands it said to run.
I would recommend Ubuntu/Mint if you just want to do things. If you actually want to understand it for its own sake I would recommend something simple instead of easy.
And it would be cancer because…?
Same reason as for all those years these old people are holding a grudge for…
It is not Unix philosophy (nothing is these days), it does not solve any problem they ever had (it does), it is no improvement over what we had before (it is) and even makes some broken and moronic things harder (it does), it is insecure (it improves overall system security), and it is one monolithic blob (it is not). Before systemd nothing depended on the init system (true, but then it did nothing useful that made having such a dependency worthwhile), and before systemd we were all free to use other init systems and distributions did not pick one for their users (they always did, offering additional inits only as unsupported iption just likenthey do now).
That’s the typical list you get.
Oh, and it was shoved down all our throats by the mighty Lennart himself, backed by several multi billion dollar companies that brided thousands of distribution developers to destroy Linux (it was not).
Funnily enough it is pretty much the same BS we had when that monster of complexity called sysv init was introduced into distributions, replacing a simple script with a forest of symlinks. Of course the community was much smaller then and so we had a loser number of idiots to shout at everybody else.
It seems that, in many people’s view, it’s better to have janky scripts starting systems, having to delegate logging management and service monitorization to the services themselves or cumbersome tools poorly used by most distros such as logrotate? Systemd offers a good thing, easy configuration and IT DOES fix a LOT of issues. People who never tried it won’t see how better it is, just try it… like I did 10 years ago.
One of the moments where we see the true power of systemd is when we use it for containers and suddenly realize that the tools used to manage the system such as
systemctl
andjournalctl
can be used to inspect and affect a container without even having to enter it. Another equally interesting moment in the systemd journey is when you’ve an ARM system with 512MB of RAM or even less and you figure out that it will save you precious resources for other things.The person you replied to is not criticizing systemd he’s criticizing systemd detractors.
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.
I also updated my reply to make it more clear. It wasn’t “aimed at you”.
http://web.archive.org/web/20140428103624/http://boycottsystemd.org/
Just to name a few reasons.
No need to drag that BS from the archives. It was never correct nor convincing.
Wow wonder what happened to those guys?:)