Hendrik Boom <hendrik@???> wrote:

> (1) Is initramfs so weird that only one or two people in the world can make one?

**AT THE MOMENT** no it isn't. AIUI (and I stand to be corrected) it's simply a CPIO archive that's been (optionally) compressed. So it can be uncompressed, extracted, modified, and rebuilt using standard tools.
Also ** at the moment** I can't see that changing since the process that needs to extract that archive at boot time isn't under Poettering's control.

As for the future - who knows.

Also, echoing another comment, I can't remember ever having to fiddle with the contents of one as a means of fixing a problem.


> (2) What is initramfs good for? Linux used to work just fine without it.

Yes, I remember the days of having to have either a) a huge kernel with everything including the kitchen sink linked in, or b) having to relink the kernel when the hardware changes. And back when I had SCO Openserver under my remit, making boot (hence placing a limit on kernel size) and root floppies for emergency booting - oh the fun of working out what I could leave off the root floppy to make space for CPIO ...

I can certainly see the use of initramfs : It allows the use of modular kernels (so non of this "you've changed something, lets relink" malarky), and gets round the catch 22 of needing to mount a filesystem before you can load the modules you need to mount the filesystems.
If you'd prefer not to use it, then you can manually link the modules you need to be able to mount the filesystems into your custom kernel and do it the old way.

Is it easier building initramfs images than statically linking kernel ? Dunno, but that's the way we've gone - and I'd say (see above) that an initramfs is less opaque than a statically linked kernel.


As to the original question ...
I have no strong feelings either way, but as has already been mentioned, once Debian goes merged, then it's inevitable that more and more packages will assume a merged system. The work required to maintain a derived distro keeping separate /usr/bin and /bin etc will keep increasing. Given the limited dev resource available to Devuan, one has to question whether it would be a good investment to maintain the split.