the proof is right there in all the discussion about rust in the linux kernel too.

Not sure if you mean proof of changing too fast …or not fast enough?

Linux has a wishlist of features they want for kernel development, and Rust has been working towards adding them.

Here's the paradox: Rust is very careful about compatibility and stability, the stable releases are changing slowly. But the Rust for Linux project wants to use the newly prototyped features right away, so they depend on not-yet-released features from unstable nightly versions of Rust.

> the Rust for Linux project wants to use the newly prototyped features right away > they depend on not-yet-released features from unstable nightly versions of Rust

This is not true. Since kernel 6.11 they have specified a minimum version that is already stable. The strategy for the Rust kernel is to use the version of Rust that ships with Debian Stable. That is very far from using "the newly prototyped features right away".

https://rust-for-linux.com/rust-version-policy

Of course, the kernel continues to inform Rust evolution. But you do not need an unstable version of Rust to compile Linux.

That not true is not true.

Rust For Linux has a hard dependency on unfinished Rust features that were not released as stable in the Rust version that Debian has.

However, every build of rustc also needs to be able to build its own standard library and a future version of itself. To do this, rustc recognizes a special private env var that exposes compiler-internal language extensions and not-yet-stabilized features meant for the compiler itself, and not for end users.

Rust for Linux relies on using this private env var to bypass feature stability checks and trick the "stable" compiler from Debian into allowing use of compiler-private and experimental features that were suppressed to stay disabled.

RfL uses an old Rust binary from Debian, but still depends on experimental features that haven't officially shipped yet in any Rust version.

The the whole thing can be summed up as "Paying taxes sucks, but if paying the taxes saves more money down then line, then we should do it"

Games use plenty of other win32 APIs. Creating windows, running processes, opening files are all APIs.

Something like wine is needed to do that translation too.

right but some games like CS have native linux clients. Is it that hard to recompile the game to run under linux?

It often is hard. If you’re using win32 APIs extensively, you’ll have to port your code to Linux counterparts.

There’s also the issue of forward compatibility. Sometimes you just can’t run an old Linux game on a newer distro, while it works fine in Wine. Or it might partially work: for example, I’ve managed to run a Linux build of Heroes of Might and Magic III, but didn’t get any sound, because it relied on some ancient sound API (pre-ALSA; perhaps OSS?). Windows version works great in Wine to this day.

For some game engines though, porting is really easy. There are some piracy groups releasing Linux ports of Unity games (that don’t have an official Linux version) by just replacing the game executable with a compatible one from another game.

Run under which display server protocol?

probably because meson doesn't have a lot of play outside certain ecosystems.

I like wrapdb, but I'd rather have a real package manager.

It is in freebsd's official handbook, and the openbsd folks have been playing around with it since 2023 at least https://xenocara.org/Wayland_on_OpenBSD.html

I'm not sure how much farther along they are than that post though.

I like the GPL for the kernel, so I wouldn't switch.

What should I do if I like AGPLv3 kernels?

then you'd have a write a new kernel

> Assuming critics are just reflexively resistant is a convenient way to avoid asking whether the criticism has merit. "They'd get it if they were more curious" is unfalsifiable.

I don't know if it can be proven or whatever, but I do know it has changed me.

There have been many events where I thought "hey, why is everybody whining about X thing?". "things are fine the way they are". Until I read more about it and changed my mind.

If it was purely online, I wouldn't take it so seriously.

So whether it can proven empirically or not, I know it changed me.

I assume most of them are just grabbing qt

not the same thing at all. Different userspace that may or may not be that efficient at power, as well as well tested power management in the kernel for specific devices.

because they care about ABI/API stability.

And have an ever decreasing market share, in desktop, hypervisor and server space. The API/ABI stability is probably the only thing stemming the customer leakage at all. It's not the be all and end all.

Decreasing market share in the desktop?

Yes, but Windows is even so bad, it's been decreasing market share of desktops.