So, I just spotted an article mentioning that Ubuntu is moving to dracut. I am aware of it, and that's about all--Fedora/RHEL has used it for some time, and I never had a problem with it on Nobara. I also never interacted with it on Nobara, so I know it exists and creates the ramdisk from which the system boots, and that's about the end. I'm bringing it up simply to ask if this is one more slip toward more integrated, less modular distributions, like systemd creates, having seen some of the headaches systemd causes.
In the article, they claim dracut is more modular in the same breath they say it integrates with systemd, which... I confess I'm out of my depth, but I've been around just long enough for that to make me raise an eyebrow and want actual information as opposed to assertions.
I only read the first two lines of that article in despair. Another distribution leaving accessibility behind. I think I will stick with only those distributions still using X11 or XLibre, like Artix community release. Oh, and no systemd thank you.
It seems that it offers better Support for more modern Setups and Encryption as far as I understand it. And the modual Aspect seems to relate to the needed Driver if I understand that right. So, You only use what You need.
Before the kernel fully loads, you still need initialization performed at lower levels.
That is init and for this, you need something to pass helper modules, drivers and other necessary actions/tools to the system before the full root file system is mounted.
For example, if using LVM, you need that to be able to perform before the kernel has fully mounted.
InitRAMFS - Initial RAM FileSystem - Debian and Ubuntu and therefor Zorin OS, use Initramfs-tools which is actually a bit more akin to SystemD, than dracut is.
Dracut is built to integrate with SystemD not out of support for SystemD, but because of how widespread and pervasive systemD is.
But it is leaner, more modular and more generalized (Currently, Ubuntu must rely on its own scripting using initramfs-tools) which gives it portability and a much more modular approach than initramfs-tools. You can include Dracut without the systemd-initrd module which allows it to fallback to a non-systemd-initramfs, using its own shell scripts.
Other distros like Devuan can use its own init system with Dracut, instead of relying on the shell scripts included.
So, it can work with Sysvinit or others.
SystemD support is a module in Dracut - you can use it - or choose not to and use something else - which is a good thing and nice to see something in line with the FOSS philosophy for a change.
If using Dracut on a systemD system, it must be integrated into SystemD due to SystemD's feature creep and far-stretching tentacles.
But it does not need to be - is built to be modular and this is a quirk of dealing with SystemD, not of Dracuts build and function.
