See the release notes: we now have experimental support for using any prefix shorter than the Linux default. We are aiming to eventually fully support (Tier 1) any prefix under 64 bytes long.

▲

mort96 2 hours ago | parent [-]

Wait what? Why prefix length limits? Linux paths can be 4096 bytes long, I can't imagine y'all are hitting that?

▲

akerl_ 2 hours ago | parent | next [-]

I’d imagine they’re live updating the library paths in the binary headers, so anything shorter or equal to what they’re using is a simple rewrite, but longer is more complex.

▲

mort96 2 hours ago | parent [-]

Ah. That makes sense.

It's so annoying how deeply UNIX packaging philosophy assumes that installation directories are something you hard-code at build time.

▲

akerl_ an hour ago | parent [-]

The present is built mostly on layers of the long-past :)

It makes me think of when Arch merged /usr/bin and sbin with /bin and sbin. Having them split made sense in a ton of scenarios that used to be very common, but increasingly the split was vestigial for most users.

▲

mort96 an hour ago | parent [-]

Yea, my understanding is that the split between / and /usr used to be more or less: the drive they used for / ran out of space, so they mounted another drive as /usr. As a consequence, / became where you put stuff that was essential during early boot, while /usr was where you put everything else.

But these days, "early boot" is handled by initramfs and we've all got drives large enough to not need the split anyway.

	▲	yjftsjthsd-h 33 minutes ago \| parent [-]
		It was also useful for many machines to share a single /usr over NFS

▲

orf 2 hours ago | parent | prev [-]

Pouring a bottle requires rewriting paths embedded in binaries, which results in a cap.

Postgres is an example of this: the various directories are set at build time.