Ubuntu Considers Replacing initramfs-tools WIth Dracut

[Espionage724]

What systemd ? Dracut is not systemd-dracut

Yet™

I'm sure systemd-boot would take its role if it were feasible though

[CommunityMember]

Soon the only difference is the distribution of packages and the package manager.

And who is making how much money. Doing the same thing as others can reduce your development and support costs, which means increased profit (and possibly surviving until the next quarter).

There are things to like about initramfs-tools, and things to like about dracut, but in the end most customers of most distros don't care about the choice a distro makes, as it is not relevant to how they use the system.

[reba]

Just quickly tried dracut and I am not impressed.

Resulting init image is quite larger, even when using hostonly. Looking at sysloglvl only few modules get used, as intended.

Boot times are the same or at least not noticeable different, even with compression cat and lz4.

Screen resolution is not set to very high but stays at 80x25 or something alike.

Last set screen brightness is also not restored on boot.

Overall nothing is better and there are regressions. Maybe there is more.
It's possible I did things wrong but at least it worked completely out of the box, which is quite a feat in itself.

I don't see the point, tbh, but maybe I just expected something different.

[cakeisamadeupdrug]

I've started to wonder about this. Distros are unifying and the line between them blurs more and more. Soon the only difference is the distribution of packages and the package manager.

The main difference for me (other than highly specialised distros like openwrt) is the update cadence and stability: what you want on the continuum between Debian and Arch, as well as political decisions like your stance on snaps. You can do more or less anything on more or less any distro. I don't think it makes sense to choose a distro because of something like dracut.

[F.Ultra]

Yet™

I'm sure systemd-boot would take its role if it were feasible though

that would most likely only be them embracing Dracut and renaming it systemd-initrd which is what they did with Gummiboot that became systemd-boot. However it would be more likely that they would use mkosi-initrd for this than Dracut.

I've started to wonder about this. Distros are unifying and the line between them blurs more and more. Soon the only difference is the distribution of packages and the package manager.

It's a sign of maturity, on the road to here we had to test out tons of competing ideas and projects.

Just quickly tried dracut and I am not impressed.

Resulting init image is quite larger, even when using hostonly. Looking at sysloglvl only few modules get used, as intended.

Boot times are the same or at least not noticeable different, even with compression cat and lz4.

Screen resolution is not set to very high but stays at 80x25 or something alike.

Last set screen brightness is also not restored on boot.

Overall nothing is better and there are regressions. Maybe there is more.
It's possible I did things wrong but at least it worked completely out of the box, which is quite a feat in itself.

I don't see the point, tbh, but maybe I just expected something different.

One nice feature of dracut is that it has an emergency shell.

[Daktyl198]

I've started to wonder about this. Distros are unifying and the line between them blurs more and more. Soon the only difference is the distribution of packages and the package manager.

It's always mostly been ideology that separated distros. Back in the day, all distros were united behind GNU tools so much that the GNU/Linux name and meme was actually viable. Then there was a weird period for the last 10 or so years where everything has slowly been shifting away from GNU tools to more modern versions of everything. Distros actually got a lot more "dynamic" and varied during this time, but it's slowly going back to the way it was before, with most distros being 99% the same software just with different configs and defaults.

[Britoid]

that would most likely only be them embracing Dracut and renaming it systemd-initrd which is what they did with Gummiboot that became systemd-boot. However it would be more likely that they would use mkosi-initrd for this than Dracut.



It's a sign of maturity, on the road to here we had to test out tons of competing ideas and projects.



One nice feature of dracut is that it has an emergency shell.

Not sure it's worth advertising that as a feature when dracuts emergency shell has been broken on Fedora Workstation (yet still enabled?!?) for at least a decade.

[NotMine999]

Good. Anything that makes Ubuntu more similar to EL is good.

Yes, let's improve the diversity of the Linux ecosystem by ... being more like another Linux distro

[NotMine999]

Wow!

It will unify configuration commands with other distributions. Great.

And when do all of those Linux distros merge into one single unified MEGA-common distro powered by SystemDeath?

It sure would save me lots of time doing Linux distro testing.

[NotMine999]

The main difference for me (other than highly specialised distros like openwrt) is the update cadence and stability: what you want on the continuum between Debian and Arch, as well as political decisions like your stance on snaps. You can do more or less anything on more or less any distro. I don't think it makes sense to choose a distro because of something like dracut.

I would think the entire snaps & flatpaks and whatever else is like them would want to disassociate from any given Linux distro. After all, I thought those tools/applications were intended to "liberate" (maybe not the best word, but it came to mind) an application from the underlying OS, resulting in "OS neutral" applications. Thus, the application only has to work within that snaps/flatpaks/whatever environment.

If Linux distros were smart, and some are while some are not, they should just make the snaps/flatpaks/whatever tools available within the limits of their maintainer workload. Leave the applications to the outside snaps/flatpaks/whatever developers/maintainers to handle.

But then there is the entire world of distro packaging to contend with. Just when I thought there was a reasonable solution the Linux ecosystem has to throw a curve ball.

And here I thought the 2 dozen or so different disk formats of CP/M were crazy way back when.