That’s really neat.

It was a Unix. I believe the distinctive feature is not what it did, but what it didn’t - crash often.

It was a fascinating idea - programs were hidden behind a document template metaphor. It was not as neat as Windows “New” menu and its templates folder.

Xenix is the best operating system Microsoft ever shipped, but they gave up on it because there was no way they could use their PC leverage to corner the Unix market.

> That said, DIMMs and the whole bus idea is in dire need of getting a new type of bearing.

IBM has been using their own memory bus technology for both their POWER and Z machines. IIRC, it’s somewhat reminiscent of CXL, trading latency for bandwidth and size.

I think the reasoning is better thermals and signal stability. The physics of the first seem to be that there is more metal to capture and distribute heat, but the signal integrity part beats me. By having better thermals, they can increase the memory clock and, thus, bandwidth and reduce latency.

Solaris, AIX, and HP-UX also maintain excellent backwards binary compatibility, as do the less Unixy z/OS and OpenVMS.

Even though z/OS is officially a Unix.

For every version between 3.5 and 10.

> With Linux, you have to target specific distros, do something insane like a giant bundle of everything,

This is what you do for Flatpack, Steam, or Docker. All these are popular options.

> Oh and I almost forgot.. install scripts that detect distros, install dependencies.

Most distros offer tooling to make packages for their package managers. With them you declare the dependencies you want and the package manager does the rest.

> And god help you if you need to ship a kernel module.

The right way to do it is to open source it and let the installer compile the software against the kernel headers. Sysdig and VirtualBox do that.

> when you have only 32 GB for a 16 core/32 thread CPU, you must reduce the number of concurrent compilations

Also, depending on the architecture, avoiding odd(or even) virtual cores might free more L2 or L3 for the worker threads and speed up the process.

Canonical has a tradition of inventing something that’s ahead of its time only to see nobody else is going the same way as they are. Sometimes they realise it was a mistake and follow everyone else.

Juju had a different problem: it was big-bang rewritten in Go and that froze features for too long for them to keep their mindshare. Rewriting was the right decision, as Python had poor concurrency back then, but doing that while freezing features was a mistake.

> They told me I would to use both Ubuntu and Juju, and I couldn't use other tools if those two worked

Dogfooding is a valid strategy to improve their product, but you’d be heavily invested in Juju’s success.

I don’t remember it as particularly surreal. They did a remote programming interview over Zoom (in 2014 or so) and it was a really interesting problem - to make a PRNG for a specific range of integers using two other PRNGs. Their solution had a branch and mine was branchless and decently random. It was, at least then, a very personalistic company, centred around Shuttleworth, but his influence didn’t usually extend more than two org levels, and different parts of it behaved as different companies.