This isn’t a very good article IMHO. I think I agree (strongly) with what it’s trying to say, but as it’s written, it just isn’t it.

Wrappers and VMs and bytecodes and runtimes are bad: they make life easier but they are less efficient and make issues harder to troubleshoot.

Runtimes/“VMs” like the JVM also allow nice things like stack traces. I don’t know about the author but I much prefer looking at a stack trace over “segmentation fault (core dumped)”. Having a runtime opens new possibilities for concurrency and parallelism too.

The COSMIC desktop looks like GNOME, works like GNOME Shell, but it’s smaller and faster and more customisable because it’s native Rust code.

This just doesn’t make any sense. COSMIC is more configurable because it wants to be, this has absolutely nothing to do with Rust vs Javascript.

Dennis Ritchie and Ken Thompson knew this. That’s why Research Unix evolved into Plan 9, which puts way more stuff through the filesystem to remove whole types of API. Everything’s in a container all the time, the filesystem abstracts the network and the GUI and more.

And here the author just contradicts themselves. So wrappers, runtimes and VMs are bad, except when it’s Ken Thompson doing it in which case adding containers and a language runtime into a kernel is a great idea actually?

Lastly, I didn’t address the efficiency arguments in the quotes because it’s mostly just true… but I do think it requires some more careful consideration than “JS bad Rust good”. Consider this unscientific sample of different apps on my PC and how much of my (expensive!) RAM they use:

• Spotify (Electron): 1G
• Ghostty (Zig/GTK): 235M
• Decibels (Typescript/GTK): 140M
• Anyrun (Rust/GTK): 110M

Note that Electron, and only Electron, is a supermassive black hole of bloat. Whatever is going on here, it’s not Javascript.

The GNU utils vs BSD utils issue should be easy to work around with a bit of symlinking and PATH modification:

> type find
find is /bin/find

> type gfind
gfind is /usr/local/bin/gfind

> sudo mkdir -p /usr/local/opt/gnuutils/bin/
> sudo ln -s /usr/local/bin/gfind /usr/local/opt/gnuutils/bin/find

> PATH="/usr/local/opt/gnuutils/bin:$PATH" type find
find is /usr/local/opt/gnuutils/bin/find

or in script form:

#!/bin/sh
# install as /usr/local/bin/gnu-run
# invoke as gnu-run some-gnu-specific-script script-args
export PATH="/usr/local/opt/gnuutils/bin:$PATH"
exec "$@"

/usr/local/opt/... is probably not the best place to put this but you get the idea, you can make it work with POSIX tools. I don’t know that much about Chimera Linux but I’d be very surprised if nobody has thought of doing this systematically, e.g. as part of a distributable package.

This is probably the main reason every mainboard has TPMs now, since all common operating systems (Android, iOS/MacOS and Windows) do it.

From what I heard the Ubuntu installer offers a version that doesn’t suck (if secure boot is enabled at install time) so using that is probably fine, but I would beware of trying to DIY it since it’s easy to do incorrectly, most guides are wrong, and you will likely end up with easily bypassable encryption.