Announcement
Collapse
No announcement yet.
The Dracut Initramfs Generator Is Slow - Could Be Much Faster As Shown By Distri's Minitrd
Collapse
X
-
Originally posted by johannesburgel View Postinitrd generation has been the slowest part of the whole package management infrastructure since forever. Every time I've seen this step during an Ubuntu update I've asked myself why it would take so long.
- Likes 2
Comment
-
Originally posted by BwackNinja View Post
Having initrd gives the flexibility to have the rootfs in many different configurations. It could be encrypted, remote, selectable, require drivers not in the kernel, or not even exist. it isn't strictly necessary, particularly in a standard desktop system, but is normally easier and more generic than the alternatives.
/srv traditionally included files for services, like /srv/http or /srv/ftp, the former is /var/www in debian-based systems.
As for big changes to the filesystem hierarchy, you'll have a good amount of software to patch. To start with:- /etc/passwd, /etc/hosts, /etc/resolv.conf and a few others are hardcoded into the libc and other programs
- #!/bin/sh or #!/bin/bash is often the shebang in shell scripts, and you'd have similar problems with python whether you use #!/usr/bin/env python or #!/usr/bin/python
- /etc/mtab is often used because it's not Linux-specific like it's normal symlink end, /proc/mounts
- /var/run is similarly used by software, and normally a symlink to /run on the filesystem
- You'll need to set your include dir for building software because its normally expected in /usr/include by the compiler
- /lib/ld-linux.so.2 is the linker hardcoded in most binaries, so no 3rd-party binaries can be expected to work without it
Beyond that there's also deeper philosophical questions like:- Where is the line between data and configuration? - This is more visibly blurred where software has its default configuration in /usr/share, and overrides (by the distro or user) in /etc
- How do you organize configuration and other data? Particularly in the case where it is shared by multiple programs. (again, /etc/resolv.conf and others come to mind)
- Is there a separation between the base system and applications? As it is with the FHS, there isn't really a notion of a core system -- all packages installed are integrated into the system rather than being treated as an addon to the system.
The big changes to the file system hierarchy and the software to patch...I'm not saying it wouldn't be a big pain in the ass, because it would, but, there are the options of shims, legacy compat layers, symlink fustercluck, and more. The scripts are more of a non-issue and you know it because system scripts would be changed and non-system legacy Linux scripts maybe covered by the previous sentence or they may be considered dropped from support.
/etc is the hard one to deal with because so much decided to use it...wait a minute...
Before I go any farther, I'd think I should say that if one wanted to do that then they should pull an Android and say "screw legacy Linux and let's try to become standardized Linux 1.0". When you think about it, distributions are the Wild, Wild West and Android is the closest thing to Standardized Linux 1.0 and that's because they said "screw Legacy compatibility" and I'm fine with that because we can chroot into Legacy and it works so people who need Legacy are already covered. Saying "screw Legacy Linux" is the only way to define your own FSH. From there you'd want to just use containers, chroots, and VMs for traditional Linux systems like we do for Windows or BSD on current Linux systems.
Trying to redefine the FSH while supporting the traditional/current FSH would be a riddled with nightmares like you point out. Unless one really wanted to redefine the traditional GNU/Linux into New/Linux like Google did with Android/Linux, I don't think it would be worth doing.
The line between data and configuration isn't so bad. Defaults under /usr/share and overrides under /etc or $HOME/.config never bothered me nor have I ever considered stuff under /usr/share to even be writable in that context or even to be used as system-wide configuration files. Defaults that shouldn't ever be used go here, root/system wide goes here, per user goes here, with permissions to define config precedence makes sense to me. IMHO, that's pretty simple to define...but I'm also assuming a clear separation and distinction between the base system and applications.
On your conclusion -- which is really why only Google has ever pulled it off with Android. They were able standardize a way to monazite their changes to the FSH.
I think Steam could team up with Red Hat and Lennart to pull off systemd/Linux which, in a way as a systemd user, is sort of what I'm advocating for and is how I think that I'd do it if I had the money, time, and resources.
Comment
-
Originally posted by skeevy420 View Post
A standardized /boot/whatever would offer the same flexibility for the rootfs as an initramfs would. Instead of a duplication of efforts by placing everything into the initramfs for every kernel installed, only the kernel & modules would need to be copied over to the boot volume since the rest of the tools would be standardized and already be there on the file system.
The big changes to the file system hierarchy and the software to patch...I'm not saying it wouldn't be a big pain in the ass, because it would, but, there are the options of shims, legacy compat layers, symlink fustercluck, and more. The scripts are more of a non-issue and you know it because system scripts would be changed and non-system legacy Linux scripts maybe covered by the previous sentence or they may be considered dropped from support.
/etc is the hard one to deal with because so much decided to use it...wait a minute...
Before I go any farther, I'd think I should say that if one wanted to do that then they should pull an Android and say "screw legacy Linux and let's try to become standardized Linux 1.0". When you think about it, distributions are the Wild, Wild West and Android is the closest thing to Standardized Linux 1.0 and that's because they said "screw Legacy compatibility" and I'm fine with that because we can chroot into Legacy and it works so people who need Legacy are already covered. Saying "screw Legacy Linux" is the only way to define your own FSH. From there you'd want to just use containers, chroots, and VMs for traditional Linux systems like we do for Windows or BSD on current Linux systems.
Trying to redefine the FSH while supporting the traditional/current FSH would be a riddled with nightmares like you point out. Unless one really wanted to redefine the traditional GNU/Linux into New/Linux like Google did with Android/Linux, I don't think it would be worth doing.
The line between data and configuration isn't so bad. Defaults under /usr/share and overrides under /etc or $HOME/.config never bothered me nor have I ever considered stuff under /usr/share to even be writable in that context or even to be used as system-wide configuration files. Defaults that shouldn't ever be used go here, root/system wide goes here, per user goes here, with permissions to define config precedence makes sense to me. IMHO, that's pretty simple to define...but I'm also assuming a clear separation and distinction between the base system and applications.
On your conclusion -- which is really why only Google has ever pulled it off with Android. They were able standardize a way to monazite their changes to the FSH.
I think Steam could team up with Red Hat and Lennart to pull off systemd/Linux which, in a way as a systemd user, is sort of what I'm advocating for and is how I think that I'd do it if I had the money, time, and resources.
I'll push harder on the work necessary to change the filesystem layout because I explicitly want to avoid legacy shims. From the list of issues I've presented and even more that i haven't, I'd say I'm further along with those changes because I'm on the implementation stage, not the brainstorming stage.
Android still has some legacy paths. MacOS also has /bin, /sbin, /usr, and others. Both succeeded as far as they did because they had the resources and no need for compatibility. Starting with your own libc, everything starts by being incompatible and you have to build a userspace on top of that yourself.
People joke about systemd/Linux, but I think the goals are generally expressed poorly. It isn't an init system, its literally THE "system daemon" -- abstracting away details, centralizing access to resources, and generally operating as the interface to the system. I think the most legitimate arguments against it are disagreeing with the definition of "system" that it presents, or disagreeing that an expansive standard should be created at all. We're already talking here about how difficult it is to move away from one standard and how everything previously represented needs a place. I don't like rigid standards because they are stifling. I'm also not a fan of layers of abstraction because you need to understand how something works at the core in order to create a better replacement or even believe that replacement is possible at all. This is again supported by the effort needed and code read to create that partial list of things that need to change in order to move away from the FHS without maintaining compatibility layers.
Comment
-
I don't get the fuss. We're talking about a few seconds. And only when there's something kernel-related going on, which isn't too often, more like once a week. I mean it's great if they can improve it, but if not, I won't have any sleepless nights.
Comment
-
Originally posted by anarki2 View PostI don't get the fuss. We're talking about a few seconds. And only when there's something kernel-related going on, which isn't too often, more like once a week. I mean it's great if they can improve it, but if not, I won't have any sleepless nights.
- Likes 2
Comment
Comment