

No. Valve (the biggest offender) will have to make native 64-bit Steam before then, as will the remaining holdouts, so Linux distros will be able to remove 32-bit packages in a timely manner.
Removing then now will break too much to be worth doing.
Hello, tone-policing genocide-defender and/or carnist 👋
Instead of being mad about words, maybe you should think about why the words bother you more than the injustice they describe.
Have a day!
No. Valve (the biggest offender) will have to make native 64-bit Steam before then, as will the remaining holdouts, so Linux distros will be able to remove 32-bit packages in a timely manner.
Removing then now will break too much to be worth doing.
The same could be said about iOS and Android. We just gotta help people when we can.
The same could be said about Windows. It’s a bad idea for people to use Windows without installing it themselves because they are dependent on MS and the OEM that installed it for them.
Better that they’d be dependent on someone that cares about them than soulless corps that just want to exploit them.
The new indirect GPU driver is AMAZING. I’ve previously suffered through getting GPU passthrough on one of my systems before, but I no longer need to because Linux flawlessly plays every game that I could ever want.
But I never liked that the VMs that I used for more general purpose stuff had choppy display performance. The indirect GPU driver sounds like it’s as easy as installing the driver in the VM and you’ll get much smoother graphical performance without the headache of configuring GPU pass through, which is awesome! I’d love to see that functionality baked in to stuff like Virt Manager and GNOME Boxes.
Yeah. This is useless.
Can someone explain why, and what to use them for?
I’m a (mediocre) Rust dev, and I use GPL licenses for my projects. There’s nothing preventing you from doing so. I think the answer to your question is that it’s largely cultural.
HelixWiki when 😭
Unfortunately, from trying this myself, I don’t think you can forward port 53 to the Android host, so that won’t work (easily). It seems that privileged ports aren’t allowed to be forwarded.
This is literally the only humane way to keep everyone safe.
I’m very firmly in the Rust for Linux camp because I am in the “make Linux better” camp, and I don’t see why eventually getting Zig in the kernel would be a problem. If Zig solves problems that C and Rust don’t, by all means, it should be brought in.
However, one of the primary reasons Rust was chosen is that it is memory-safe by default. Zig, on the other hand, has opt-in safety. So unsafe Zig should probably only go in very specific places where C and Rust can’t do the job. And ideally, there would be some rules that require the usage of safe Zig everywhere else.
Ignoring Zig, the language, Zig’s compiler toolchain is hands-down, the best I’ve ever seen, and I think introducing Zig to the kernel by making “Zig-built Linux” a thing, would be a really natural way to get that process going.
After reading the lkml, it really does seem like the C dev just being hostile to Rust. The C dev just outright refuses to accept any of the compromises from the Rust dev, and is pretty rude about it.
Idk why, but some of these people need to hear that languages are not a team sport and fighting and being hostile to people about it just makes the Linux kernel worse.
You can also fork proprietary code that is source available (depending on the specific terms of that particular proprietary license), but that doesn’t make it open source.
Fair point about llama not having open weights though. So it’s not as proprietary as llama. It still shouldn’t be called open source if the training data that it needs to function is proprietary.
Call it “open weight” if you want, but it’s not “fully open”. The training data is still proprietary, and the model can’t be accurately reproduced. It’s proprietary in the same way that llama is proprietary.
Has anyone here tried Rust dev on Haiku OS? I love these “niche” OSes, and it’d be cool to write some utilities for it. I assume that a lot of the syscalls might be completely different, so it’d be more challenging as well?
Nah. Even if the Snapstore backend were FOSS, you should still avoid Snaps because the way they implemented sandboxing subtly breaks many applications.
Not to mention, they dishonestly co-opt your apt install
invocations to sneakily install the Snap version. Actual Microsoft behavior. If a company is that eager to deceive you and shove their tech down your throat, you should avoid it at all costs.
“Banned” used to mean “you’re done”. Now every little time-out is a “ban”. Can we use words correctly instead of lying for clicks?
Can you just fucking render the graphics as they were made?
Operation Pastaclip
Same. If most of my games stopped working, I would be very annoyed, especially because it was entirely preventable.
Thankfully, the Fedora project and community agree.