Init system

Status
Not open for further replies.
Systemd is not needed either for Wayland nor for Gnome. The use of systemd nowadays results from a mix of herd instinct, convenience and power play by REHL.
Desktop users for most part will not notice any difference.
Please don't start a flame war here and calling people sheep, we are all Linux users no need to hate on each because some use systemV, some use OpenRC and some use SystemD, etc. If it wasn't for corporations like RHEL Linux wouldn't be where it is today, if you don't like it you can move to BSD or Windows.
 
Last edited:


Agreed but toned down a little. ;)

Wizard
 
Please don't start a flame war here and calling people sheep, we are all Linux users no need to hate on each because some use systemV, some use OpenRC and some use SystemD, etc. If it wasn't for corporations like RHEL Linux wouldn't be where it is today, if you don't like it you can move to BSD or Windows.
If I offended you, then I am sorry. This was not my intention.
My comment was not about users, but about distros. It does not matter what user decides to test. It is all about experience and freedom. Post #32 wishes that all init but systemd will be gone. I don't. It is more difficult to mantain systemd and non-systemd init and this is linux freedom spirit. This is what linux embodies for me: the freedom of choice.

I don't have any preferences but I appreciate the work done and hope that it stays this way.
 
If I offended you, then I am sorry. This was not my intention.
My comment was not about users, but about distros.
All good then! :) Your word choice made it seem like that because how it was phrased it gave it a negative tone, that's why my response about it.
The use of systemd nowadays results from a mix of herd instinct, convenience and power play by REHL.
Post #32 wishes that all init but systemd will be gone. I don't. It is more difficult to mantain systemd and non-systemd init and this is linux freedom spirit.
Doesn't seem like it to me.
I personally couldn't disagree more. I find systemd easier, more powerful, and more flexible, not to mention
generally more reliable. But to each his own.

Up until recently, a lot of distro's supported both. So I'm still not sure why you would need one mode or the other.
@dos2unix saying that whatever works for you. Seems more like he said he doesn't get why you would need both available on the system or my English is getting rusty? Or maybe he meant something different?
 
As I mentioned above, I doubt that majority of users, select distro based on init system. There are many factors involved but init is not one of them.
I don't even understand why this question popped up here: either ask MX Linux developers or assume that they want to provide the best experience for all... if one wants to learn intricacies of init system.

Now, the interpretation of someone's thoughts is prone to errors as we observe here. ;)

I started using linux in the late 90'. Red Hat was the first (or second) distro I tested. At that time this was a different company. It is now (small) Big Corporate. As much as I can appeciate RHEL nowadays, I appreciate Microsoft for popularizing home computing.

In early 2000' I was enjoying Arch Linux. Great distro. At some point Arch devs decided to make everything Gnome dependent. I wanted pure KDE, and got KDE and most of Gnome. This was arbitrary and not very smart decision (in my opinion). After enquiring about the issue, I decided to go with another distro. This is the freedom of choice. This is why I hope that different init systems will stay so if someone wants to test there are options.
 
n early 2000' I was enjoying Arch Linux. Great distro. At some point Arch devs decided to make everything Gnome dependent. I wanted pure KDE, and got KDE and most of Gnome. This was arbitrary and not very smart decision (in my opinion).
I used to use KDE Plasma but now I run Gnome, I actually just installed vm with KDE Plasma but it looks like they came back from that decision since there are only three Gnome packages installed with KDE Plasma installed.
Code:
[tux@archlinux ~]$ pacman -Qqs gnome
adwaita-cursors
adwaita-icon-theme
libsoup3
Now, the interpretation of someone's thoughts is prone to errors as we observe here.
Agreed, it's also hard to interpret someones emotional intent by just text in a post ;)
 
Mxlinux does allow both init sytems to run. My mxlinux runs sysvinit be default but there is a shim that starts the login process. As I stated you find in the operating system " /lib/systemd/systemd-logind" as one example and it is a running process on my sysvinit system. This is done by a process I have not identified.

Can anyone explain why a systemD shim would be running on a default sysvinit system ?
 
Question for you, OP.

Are you using Pulseaudio, Pipewire, ALSA or other?

Wizard
 
shim is needed for secure boot. Does not matter if init is systemd or not.

Maybe this will help:
ps -p 1 -o comm=
I would think that above command should identify currently running init
 
From chatGPT.

User


advantages of systemd over sysV init


Systemd and SysV init are both init systems for Unix-like operating systems, responsible for initializing and managing system processes. Systemd, introduced as a replacement for SysV init, has several advantages over its predecessor. Here are some of the key advantages of systemd:
  1. Faster Boot Times:
    • Systemd is designed to parallelize the startup of system services, leading to faster boot times. It can start services concurrently, taking advantage of modern hardware capabilities.
  2. Dependency-Based Initialization:
    • Systemd uses a dependency-based approach to manage services, allowing better control over the order in which services start. This can result in more efficient and predictable system initialization.
  3. Enhanced Service Management:
    • Systemd provides a more sophisticated and centralized way to manage services compared to SysV init. It offers features like service activation on-demand, automatic restarts, and dependency tracking.
  4. Improved Logging:
    • Systemd includes its own logging system, known as the journal (journald). It provides centralized and structured logging, making it easier to analyze and troubleshoot system events.
  5. Unified Configuration Files:
    • Systemd adopts a unified configuration file format (INI-style) for service units, making it simpler to write and understand service configurations. In contrast, SysV init often requires separate and sometimes complex scripts for each service.
  6. Resource Control:
    • Systemd allows for fine-grained control over system resources through features like cgroups (control groups). This enables administrators to manage resource allocation and isolation for services.
  7. Support for Socket Activation:
    • Systemd supports socket activation, where services are started only when they receive a connection on a particular socket. This can lead to more efficient resource utilization.
  8. Transaction-Based Operation:
    • Systemd performs operations in a transaction-based manner, ensuring that if there is an issue during service initialization, the system can roll back to a previous state. This enhances system reliability.
  9. Built-in Compatibility:
    • Systemd is designed to maintain compatibility with traditional SysV init scripts. It can run SysV init scripts without modification, easing the transition for systems that were originally configured with SysV init.
  10. Active Development:
    • Systemd is actively developed and maintained, with ongoing improvements and updates. This ensures that the init system keeps pace with evolving hardware and software technologies. The latest version of SysVinit was 2.98, released on December 25, 2014.
It's important to note that opinions on systemd vs. SysV init may vary, and the choice of init system often depends on factors such as personal preference, system requirements, and distribution policies.
 
I know this thread is specifically about sysVinit and systemd. But it does expand into a larger philosophy here.
There are have been a lot of changes in Linux over last 7 or 8 years. I would say more has changed in Linux
in the last seven years, than the entire 23 years before that. Systemd is just one of those things.
NetworkManager is another. Wayland vs X11.org is another. xhci vs ohci/uhci. Pipewire vs pulseaudio.

There is the "if it ain't broke, don't fix it" crowd. That's fine I get it. If it's doing the job, then there's really
no need to change anything. But to me, the main reason Linux exists, is because we can do it better, faster,
more securely, more stable. Not only better than the WindowsXP of a generation ago, but even the Windows
11 of the current generation.

Newer, faster CPUs and GPUs, SSD and NVME drives are way faster than old spindle type hard drives.
ac and ax Wifi, USB 3.2 vs 2.0, multi-core processors. DDR5 RAM. Hardware changes, software changes.
There are very few old PCs with 286 and 386 cpus still running around. I remember 1200 baud dial
up modems, matrix millenia graphix cards, and 32meg (not gig) of RAM. Software often has to change
to keep up with the new hardware. New drivers are written every day. New Linux kernels come out
two or three times a week.

Sometimes there is a blancing act, for example Wayland is technically superior to X11, but currently it's
less compatible with everything. It seems that pipewire isn't 100% there yet. But it blows pulseaudio
out of the water when comparing technical specifications.

Now I don't believe in new, just for the sake of being new and different, but if it really is better.. why fight it?
There are things you can do with systemd service files, you just can't do ( certainly not as easily ) with
rc.init files.
 
I was just thinking, a lot of you young guys will look back one day and say things like...
a 2Terrabyte VNME hard drive? Really? A Intel 12th gen i9 processor? Really? 32GB of DDR5 RAM? Really.
An nVidia 4090RTX GTi? How did you guys every get by with all that ancient stuff.

It may sound silly now, but mark my words, it'll happen.
 
It may sound silly now, but mark my words, it'll happen.

Showing your age, Marvin. BTW, VNME? NVME?

On a more serious note I will likely be locking this thread soon, will explain more then.

Last chances for comments / input.

Wizard
 
The "sysvinit" seems to work well for Slackware, but this is what I've seen and my opinion. That said, I can't help a couple of things it does that perhaps could be left out. Such as this "haveged" thing because I've read somewhere such support was directly incorporated into the Linux kernel. On Slackel v7.7 64-bit it looks like it does an "fsck" on the ESP as well as on the root partition, which holds up for a couple of seconds. Then there's another stick-up that I have to read into more carefully while it's enabling "Network Manager" or something like that.

I will have to find someplace else to install MX Linux if I want to keep it, because it is starting up very slowly. This keeps happening after three times I tried to fix it, including backing it up with Clonezilla, zeroing the disk and then restoring. It has happened to me with Manjaro KDE and with one Debian in the past, and it's happening to me as well with Freespire "Focal Fossa" but I guess I will have to deal with it.

Otherwise I have two or three examples of systems with "systemd" that start up faster than the "non-systemd" ones. I have Slackel 64-bit starting up twice as long as Debian XFCE, recently installed with "Bookworm" v12.2 base. In turn, this latter one lags compared to at least one which is the same thing, but with "Bullseye" v11.8 base. But this is bragging poorly.
 
Here is an example of MX-linux running a systemd process that should be running under sysvinit.

/lib/systemd/systemd-udevd is a process used to control USB or other external storage.

This process runs concurrently on an active sysvinit system. Why ?
 
I's probably worth spending a little time trying to get some understanding of the way in which sysVinit and systemd systems work, and in particular, how elements of the two systems can interact.

Before systemd existed, sysVinit systems ran most distros. When systemd appeared, it didn't necessarily eliminate all elements of sysVinit, rather it subsumed and integrated them in many cases.

Since systemd's birth, amongst the distros that have adopted it, many, if not most, have included sysVinit elements in their systems. The example that follows uses a debian systemd installation. The sysVinit elements are apparent if you look into the /etc/init.d directory, and see output such as:
Code:
[tom@min /etc/init.d]$ ls
alsa-utils  bluetooth         cups-browsed  keyboard-setup.sh  ofono                        speech-dispatcher
anacron     connman           dbus          kmod               procps                       ssh
apparmor    console-setup.sh  dundee        lightdm            pulseaudio-enable-autospawn  sudo
atop        cron              glances       lm-sensors         rsync                        sysstat
atopacct    cups              gpm           networking         saned                        x11-common
And then check the output of the sysVinit style runlevel directories:
Code:
[tom@min /etc]$ ls -lR rc*
rc0.d:
total 0
lrwxrwxrwx 1 root root 20 Nov 15 08:29 K01alsa-utils -> ../init.d/alsa-utils
lrwxrwxrwx 1 root root 14 Nov 19 15:19 K01atop -> ../init.d/atop
lrwxrwxrwx 1 root root 18 Nov 19 15:19 K01atopacct -> ../init.d/atopacct
lrwxrwxrwx 1 root root 19 Nov 15 08:29 K01bluetooth -> ../init.d/bluetooth
lrwxrwxrwx 1 root root 17 Nov 15 08:29 K01connman -> ../init.d/connman
lrwxrwxrwx 1 root root 22 Nov 15 08:29 K01cups-browsed -> ../init.d/cups-browsed
<snip of large output>
All that output is pure sysVinit filesystem arrangement in a fully systemd functioning system.

What's worth understanding is that each of the sysVinit scripts in the /etc/init.d directory, are converted by systemd on this system, into systemd service units, and then implemented with original intended outcomes of the scripts given effect just the same as if they were run natively as sysVinit scripts. It's quite clear that they are sysVinit scripts if you inspect the contents of any of the files in /etc/init.d. They comply with the necessary sysVinit formatting.

Systemd can thus run a sysVinit style system, and actually does so in the case above, but the reverse is not necessarily the case. A sysVinit system that doesn't have the software to run a systemd system, cannot do it unless it includes the systemd software. Many sysVinit style systems don't do that because of the overheads, redundancy and policy of the creators.

Systemd accomplishes it's conversion of sysVinit scripts to systemd services by the use of what it calls "generators", and sets them up in a tmpfs to run making them available transparently to the user. Systemd has many services that are not in the sysVinit format which is apparent if you inspect the /lib/systemd/system directory which houses many other services.

The notion of what a distro "should" or "should not" do, is a subjective matter and it's a questionable discussion to have without an examination and explanation of the original intentions, justifications and rationalisations of the developers. Not all opinions have the same value. Those that are more informed are likely to carry more weight.
 
Question for you, OP.

Are you using Pulseaudio, Pipewire, ALSA or other?

Please answer my question. You can give us the output (and delete your username if you wish) with

Code:
pactl info

The clock is ticking

TIA

Wizard
 
Systemd can thus run a sysVinit style system, and actually does so in the case above, but the reverse is not necessarily the case.

Exactly! I would say 99% of my user processes are controlled by systemd. But I can still add an init.d file if I really want to.
No need for two separate distro installs in order to do this.
 
The point of this post is that only one Init system should ever being running on any O.S. but on mxlinux I have 2.
 
Status
Not open for further replies.

Members online


Top