why would you care about a far away government collecting intelligence about you over the one that can (and will) actually hurt you?
Both of you are dangerous in truth. We don’t trust anyone. (ಠ_ಠ)>⌐■-■ Why do you think we use FOSS?
You really just compared “African leader” to “a monkey”. I can’t, I can’t believe it. The irony, the sheer irony, it’s delicious, so very delicious, keep feeding me more of this shit.
You’re completely miss understanding the entire thing. You’re dear lead is being compared to an iconic, childhood beloved, Disney, cartoon bear 🐻, and you think it’s racist? How foolish.
You’re the only one “comparing Chinese people to yellow animals” in truth. Your Irony is delicious to me.
False. “Chinese people” aren’t being compared to “yellow animals”. The only thing happening here is your dear leader looking like a cartoon Bear 🐻.
Removed by mod
123·2 months agoHell yeah!! So many needed fixes that have been bugging me for a while are finally fixed!!
Why should we have the same standard for two fundamentally different languages with distinct design philosophies and features?
Even if the C coding standard was used, it fundamentally will not make Rust more legible to C-only kernel devs. Imposing the C coding standard on Rust would be fundamentally counterproductive, as it would undermine Rust’s safety and productivity features. Rust’s coding guidelines align with its design principles, promoting idiomatic Rust code that leverages language features like ownership, borrowing, and lifetimes.
This ensures that Rust code in the kernel is safe, concurrent, and maintainable, while adhering to the language’s best practices. While the C coding standard served its purpose well for the procedural C language, it is ill-suited for a modern language like Rust, which has different priorities and language constructs. Having separate coding standards allows each language to shine in its respective domain within the kernel, leveraging their strengths while adhering to their respective design philosophies. Having separate coding standards for C and Rust within the kernel codebase is the sensible approach.
In any case, it’s the temporary file directory so it should be fine to delete them manually.
Just make sure that podman isn’t running while you’re deleting them, assuming it is podman.
This error is caused by a compatibility issue between Wine’s RandR (X11 display extension) implementation and the NVIDIA proprietary drivers.
a. Install winetricks and run
winetricks orm=backbuffer glsl=disableThis will configure Wine to use a different rendering method that is compatible with the NVIDIA drivers.&/Or
b. Use a tool like Q4Wine to configure the Wine prefix and set the “UseRandR” option to “N” This will disable Wine’s use of the RandR extension and use a fallback method instead.
That should fix it.
What’s the WINE error message you get with the proprietary driver?
Font rendering is complex and depends on several settings and features lining up perfectly. Anti-aliasing, DPI, fractional scaling, hinting, and subpixel rendering are all important factors that contribute to the quality and appearance of text on a digital display.
On KDE plasma the fractional scaling also plays a role in text rendering. Then there’s also the “Legacy Application Scaling” for X11 apps on the Wayland session.
Check your install paths when you uninstall them. Do the files from the packages still exist?
Are you perhaps accidentally booting from a system snapshot?
That’s a weird way of saying :