Probably because your distro purposefully keeps software out of date because it is too fragile otherwise. I don't think that is reasonable at all for desktop use.

Arch?...

Yes. Premature optimisation when it comes to dynamic linking is the reason for why the year of the Linux desktop is far away in my opinion

I just remember Jonathan Blow mentioning this in one of his streams.

This would only work if you use dynamic linking. Updating dependencies in a statically built distribution would have no effect.

That's why I don't think Ubuntu is a newbie distro. You never have to compile for source on arch-based distros. Obviously plain arch isn't fit for beginners, but I would argue that something like endeavouros or cachyos is easier to use than Ubuntu. If you want to install something, you just run one command, and then it is installed, 99.99% of the time.

It absolutely is not awful. You are doing something wrong then. It's not as good as on macOS of course but it's still great. I get 8-10 hours.

Exactly. This myth keeps being perpetuated, for some reason.

I'm typing this from a ThinkPad X1 Carbon Gen 13 running Void Linux, and UPower is reporting 99% battery with ~15h left. I do have TLP installed and running, which is supposed to help. Realistically, I won't get around 15h with my usage patterns, but I do get around 10-12 hours. It's a new laptop with a fresh battery, so that plays a big role as well.

This might not be as good as the battery life on a Macbook, but it's pretty acceptable to me. The upcoming Intel chips also promise to be more power efficient, which should help even more.

Eh it's pretty awful. I get 8 hours, yes, but in Linux, those 8 hours are ticking whether my laptop is sleeping in my bag or on my desk with the lid closed or I'm actively using it. 8 hours of active use is pretty good, but 8 hours in sleep is absolutely dreadful.

It's not. What makes you say this?

I used my homemade shell language last year, called elk shell. It worked surprisingly well, better than other languages I've tried, because unlike other shell languages it is just a regular general purpose scripting language with a standard library that can also run programs with the same syntax as function calls.

Native AOT compiled code is not necessarily faster than JIT compiled code. The Java JIT engine can do a lot of optimisations that would not be possible with AOT compilation. In the end it's compiled down to machine code anyway.

You don't have to implement some big new feature. I found a layout rendering problem when I tested it on my own website and could quite easily go and fix it without having any prior experience with browser development.

Well that's why they're going to rewrite parts of the code where those things are more likely in Swift