Every day our computers become an increasingly important part of our lives; if they have any kind of problem, it affects our mood, our humor, haha. Of course, Windows users are more prone to panic attacks: viruses ( long live Linux! ), defragmenting the HDD, finding and installing Clean Master for PC ( although here in Linux we also need to clean the system; BleachBit is one of the preferred alternatives ). Recently, some Linux users have been experiencing a certain headache called systemd.
Anyway, to get to the point, I've read an interesting article about systemd , which seems to be all the rage these days.
Systemd , which some consider ( and I'll use a friend's words ) to be "one ring to rule them all "... to others, who are simply indifferent; as long as the computer works properly, they don't care if init does X or Y, or if systemd is used. As for me, well... let's just say I prefer init; I find it simpler.
I leave the article here:
Before I begin, I must say that I strongly dislike the decision to change things in Debian, but I have no intention of abandoning my beloved spiral. I'm simply trying to ensure that, if we're going to discuss a topic, we do so as prepared as possible, even though I myself don't consider myself pro-systemd. To demystify systemd, I'll rely on a website where developers share their perspectives , which came to my attention through a colleague who does seem to be pro-systemd, even though he's not a Debian user. With that said, I think I can proceed to try and demystify what's being said about systemd.
systemd is binary based
Perhaps this is one of the aspects that shock us the most, if everything is based on binary, how do we monitor the things we usually do through logs? I have no idea how this myth was born, but it is not absolutely true.
systemd is configured almost exclusively through plain text files. Some settings that can also be altered with the kernel command line and through environment variables. There is nothing binary in your configuration (not even XML). Just a simple, straightforward and easy to read text file.
That thing is monolithic and it controls everything
Before reaching the aforementioned website, I confess that I myself thought this way, but after reading what its developers say, my opinion has changed something ...
If you build systemd with all configuration options enabled, you will build 69 individual binaries . These binaries serve different tasks and are carefully separated for a number of reasons. For example, systemd was designed with security in mind; therefore, most daemons run with minimal privileges (using kernel capabilities, for example) and are responsible for only very specific tasks, minimizing their security surface and impact. Also, systemd parallelizes booting more than any previous solution. This "parallelization" is created by running multiple processes in parallel. Thus, it is clear that systemd is very well divided into many binaries and, consequently, processes. In fact, many of these binaries are so well separated that they are very useful outside of systemd.
A package containing 69 individual binaries could hardly be called monolithic. What differs from previous solutions, however, is that we ship more components in a single tarball and keep them chained together in a single repository with a unified release cycle.
That doesn't look like Unix
There is certainly some truth to that. The systemd source files do not contain a single line of code from the original UNIX lines. However, inspiration is derived from UNIX, and thus there is a lot of UNIX in systemd. An example would be the UNIX idea "everything is a file" which is reflected in that in systemd all services are exposed at runtime in a kernel file system, the cgroupfs. So, one of the original features of UNIX was multi-seat support, based on built-in terminal support. With systemd we brought multi-seat support natively again, but this time with full support for today's hardware, covering graphics, mice, audio, webcams, and more. In fact the design of systemd as a suite of integrated tools that each have their individual purposes but when used together are more than the sum of the parts, which is more or less at the core of the UNIX philosophy. So the way our project is handled (i.e. keeping most of the operating system kernel in a single git repository) is much closer to the BSD model (which is a true UNIX, as opposed to Linux) to get things done (where most of the core operating system is kept in a single CVS / SVN repository) which was never the case on Linux.
Ultimately, the question of whether something is UNIX or not matters very little. Being technically excellent it is hardly unique to UNIX. For us, UNIX is an important influence (in fact, the biggest), but we also have other influences. Hence, in some areas systemd will be very UNIX, and in others a little less.
That is very complex ...
There is certainly some truth to that. Modern computers are complex beasts and the operating system that runs on them will obviously be too, so they have to be complex. However, systemd is certainly no more complex than previous implementations of the same components. It's simpler, and has less redundancy. On the other hand, building a simple systemd-based operating system will involve far fewer packages than traditional Linux uses. Fewer packages makes it easier to build your system, it gets rid of interdependencies and much of the different behavior of all the components involved.
That won't let me use shell scripts
This is completely false. We simply don't use them for the boot process because we believe they aren't the best tool for that specific purpose, but that doesn't mean systemd was incompatible with them. You can easily run shell scripts as systemd services or daemons; you can run scripts written in any language as systemd services since systemd doesn't care in the slightest what's inside your executable. Moreover, we extensively use shell scripts for our own purposes: for installing, building, and testing systemd. And you can paste the scripts into the early startup process, use them for normal services, run them in the final shutdown—there are practically no limits.
At this point, I suppose some of the main beliefs may have been clarified. Although I don't consider myself a proponent of change and have my reservations about the " one demon to rule them all " idea, I think that in the end, no one will dare say that it doesn't work at all. I even know some users who notice that with systemd, "the PC runs faster," but that would be another matter for discussion. For now, I can only invite you to debate your points of view here on the init system that many distributions have adopted, although the strongest reactions are currently being seen within the Debian community, which has even spawned a new fork because of all this. Whether you like it or not is a personal matter; for my part, I just want to do my bit to demystify systemd, which will ultimately be present in Jessie, the next stable version of Debian.
I saw the article on GUTL (which in turn was taken from DesdeAbreus )
Systemd current?
I am one of those who does not read many news when something generates so much controversy, I prefer to stick to more technical details. It's just that... sometimes I feel that certain topics stop being a merely technical discussion or debate, and become like one of those gossips of the world
First, an open rant from a user about systemd called systemd VS intelligence , then Linus Torvalds saying that systemd isn't as bad as it's made out to be ( and he does have a point ), a fork called uselessd ... no comments... and to make a long story short, finally Devuan.
I won't say if it's as bad as they say, less bad, or worse. The system works fine for me, however, personally I'd prefer init, as I like its way of organizing various things (like logs, for example). But hey, if systemd is going to be called a racehorse and has to replace init ( would it be our workhorse, doing everything but slowly? ), well... as long as the change isn't too drastic, users can adapt without too much trouble, and the system works better (yes, better, maybe that won't be enough for me!), then welcome it! 😉