>>>>> Marco d'Itri <md@Linux.IT> writes:
>>>>> On Oct 11, Sven Joachim <svenjoac@gmx.de> wrote:
>> Rather complex, I'm afraid. Especially as not all architectures
>> even support an initramfs, AFAIK.
> I doubt this, since the initramfs can be embedded in the kernel image
> itself (and indeed it always contains one, it just is empty). But
> still, then these architectures would not support keeping /usr on a
> standalone file system, which may be an acceptable compromise.
I don't seem to understand. / is used to be self-contained; one
was still able run a “bare bones” system with just / (say, if
/usr was badly damaged somehow.) How an architecture could
/not/ support having /usr on a separate filesystem.
On the shore, I see no value in the whole idea of merging / and
/usr. Somehow, it reminds me a recent trend of moving graphical
mode support (for the architectures generally capable of a text
mode, as in: amd64, i386) from userspace (as in: X server) to
kernelspace (as in: fbcon, Wayland.)
Saving a dozen of bytes in ${PATH} doesn't seem like an
astonishing idea, anyway. What's the point, then?
[…]
--
FSF associate member #7257