Don’t tell that to the kids in Finland 😉

https://santaclausvillage.info/activities/santa-claus-main-post-office/

You know, as a full-time Linux user, I think I rather have game developers continue to create Windows executables.

Unlike most software, games have a tendency to be released, then supported for one or two years, and then abandoned. But meanwhile, operating systems and libraries move on.

If you have a native Linux build of a game from 10 years ago, good luck trying to run it on your modern system. With Windows builds, using Wine or Proton, you actually have better chances running games from 10 or even 20 years ago.

Meanwhile, thanks to Valve’s efforts, Windows builds have incentive to target Vulkan, they’re getting tested on Linux. That’s what we should focus on IMO, because those things make games better supported on Linux. Which platform the binary is compiled for is an implementation detail… and Win32 is actually the more stable target.

Heh, I agree with everything you said, but I’m afraid such a framework is impossible to create, let alone implement. It’s impossible to foresee the infinite possibilities for people to screw themselves through bad decisions, so all you’d create is a lot of bureaucracy to still end up in the same place.

Yeah, here it is: https://lore.kernel.org/rust-for-linux/1f52fa44062e9395d54ed6733780aea0830ee6a5.camel@HansenPartnership.com/T/#m8f8599678bc864662eae28756cba25981fc2c0ac

But he did step in, albeit privately. I actually agree an earlier public statement would have helped, but we don’t know the specifics of what went on behind the scenes.

In any case, I don’t think it’s fair to assign blame for Marcan’s burnout to Linus, as the post above did. Marcan himself mentioned personal reasons too when he announced his departure. I think we should show understanding and patience with both sides, and assigning blame isn’t helping with that.

That now involves fixing Rust drivers, so you’re going to need to know Rust.

I also don’t think the latter follows from the former. You can continue to not know Rust as long as you’re willing to work with those that can. Problems only start if you’re unwilling to collaborate.

You’re implying that Linus is somehow responsible for burning out Marcan? I don’t think that’s a fair assessment.

So far, the only good argument I have really seen from the ones opposing the Rust4Linux effort comes down to: adding Rust to a C codebase introduces a lot of complexity that is hard to deal with.

But the argument offers no solution except to give up and not even attempt to address the real issues the kernel struggles with. It’s effectively a form of defeatism when you want to give up and don’t want to let others attempt to do what you don’t see as feasible.

Fair, just wanted to point out that the monarchy class I’m proposing is actually a communist class intended to keep the capitalist/socialist citizenry in check. So there may be more in it than you might have realised from the abstract alone.

in my case at least leads me to questioning how our political and social systems can change for the better.

Glad to see like-minded people here! I actually just finished a manifesto on this exact topic:

https://arendjr.nl/blog/2025/02/new-monarchy/

It’s quite the read, but I’d be happy to hear your feedback.

Sorry, but this mindset is hurting both Linux and security in general.

The reason we are seeing a lot of security vulnerabilities is because prior to about 10 years ago security wasn’t considered that important.

This is frankly quite obviously false. Microsoft started taking security more seriously around the release of Windows 2000. Are you saying the Linux kernel developers took another 15 years to realize security is important?

Security research shows that new code is more prone to common vulnerabilities than old code is. While old code may have been designed with weak (or no) security considerations, those are well-mitigated by now. On the contrary, new code still regularly contains exploitable memory safety issues that slip by review.

What we need is skilled programmers who understand security.

We have skilled programmers who understand security. Those also understand that we need more than that.

Continuing to use C doesn’t merely require skilled programmers, it requires programmers that never make any mistake ever. That’s an infeasible standard for any human to uphold, hence why C is considered a risk.

I agree the Linux kernel is just fine. But that’s only because despite the security risks of C, there’s no viable alternative kernel.

But development doesn’t stand still, so either Linux catches up, or gets replaced when a viable alternative arrives. Thankfully Linus sees the problem, so they’re working to make the kernel viable a while longer, but I also agree with the person you replied to that this work could definitely use a bit more help.

I use EndeavourOS and really enjoy it. It’s effectively Arch but without the fuss. You get a GUI with just a few steps to set it up and you’re good to go. I tend to upgrade once a week, while checking the forums to see nothing too bad broke. That’s basically the maintenance I have.

When I do a new install on a new device, I just clone a repo I keep with the most important config files. Then I copy them to where they belong. There’s really not much more to it.

I thought we were talking about gamers and Linux users? :p

I have a Framework laptop (Intel GPU) with Arch and KDE, and while I’ve never seen all windows crash when connecting an external monitor, I wouldn’t call it out of the ordinary for one or two to crash after I connect one, especially if I try to drag one to a new position right after.

The System76 scheduler helps to tune for better desktop responsiveness under high load: https://github.com/pop-os/system76-scheduler I think if you use Pop!OS this may be set up out-of-the-box.