Chimera Linux

Yes.

I wrote a history of this stuff in 2011:

https://www.theregister.com/Print/2011/07/18/brief_history_o...

FreeBSD jails first, then Solaris Zones, then Linux containers.

Linux VServer came first but is not really a normal container implementation, although it has similarities.

HP-UX 10.24 seems to be 1996:

http://www.bitsavers.org/pdf/hp/9000_hpux/HPUX_Versions.txt

I know next to nothing about it though.

> That doesn't refute my statement that BSD pioneered containers with jails

I'd say that was a fair call.

> I had thought IBM did VMs rather than OS-level virtualization

It does both.

AIX calls its containers WPARs:

https://www.ibm.com/docs/en/spectrum-lsf/10.1.0?topic=tips-o...

> (wasn't Gene Amdahl the one who came up with the rules for classically virtualizable architectures?)

No, Popek and Goldberg.

https://en.wikipedia.org/wiki/Popek_and_Goldberg_virtualizat...

FWIW I wrote a history of that, too:

https://www.theregister.com/Print/2011/07/14/brief_history_o...

> musl is just a mandatory choice [due to the toolchain]

interesting; i didn't realise that.

> most software does not involve any porting in the first place, upstreams are not that reluctant

perhaps; it seems to me that the majority of patches in alpine's aports (otherwise a rather vanilla distribution) are fixing glibc assumptions.

> as for firefox having a specific crash, have you reported it?

as i understand it, mozilla wouldn't accept a musl-specific bug report; and neither the old nor new alpine firefox maintainers were able to reproduce these two crashes, weirdly enough, so i gave up and started using the upstream build, hence using this as an example of a musl (or non-bog-standard-gnu-tooclhain at any rate; at least one of these crashes seem to be on a c++/rust boundary) annoyance.

> slowness is typically a default allocator issue and that does not apply to us

i didn't know about your using a different allocator either. i'll investigate.

to end on a more positive note, from the end-user point of view there are also some joys to having an incompatible userland: in principle, not being able to natively run upstream builds prepares me for when i decide to jump ship to e.g. arm or riscv.

i had a few nice 'aha' moments: i switched to a different music streaming service because the old one wanted widevine which wouldn't work in a musl build of firefox; a random electron app i downloaded, unpacked and ran with distribution-provided electron (assuming it's just a bunch of html and javascript) didn't work because it shipped, amid other resources, shared libraries (with filenames helpfully ending in '.node').

> Until systemd, there wasn’t anything else that would really do the trick (djbware and stuff derived from djbware does not count, as it’s lacking too much stuff that even various hacked together rc implementations on top of sysvinit added eventually)

There was Canonical's upstart, used in Ubuntu. systemd was created to address upstart's shortcomings

> That’s why one of the goals in Chimera is to implement the actual useful systemd functionality, but independently and in our own way, without the shortcomings.

This is amazing! The greatest value of systemd is that there are many service files written for it (my own ~/.config/systemd directory has a dozen of services) and I think there is value in being compatible with it