Hell yeah!! So many needed fixes that have been bugging me for a while are finally fixed!!
Hell 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=disable
This 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.
I’d like to add that the current Cosmic DE in use is an ageing fork of Gnome and is going to be replaced with a Rust-based DE called Cosmic (Epoch) soon.
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?
BTRFS &/OR EXT4
sudo su; passwd
Super User Do Super User
It’s should definitely work then. MTP usually doesn’t leverage USB Gadget, but this one seems to.
Not sure if that’ll work for SteamDeck-to-LinuxPC connection, but I’m certain that works for SteamDeck-to-Android.
It is using USB gadgets, so it’s worth a shot at least.
I found some directions that might help.
Enabling USB-C OTG Device Mode :
Ensure the Linux device has a USB-C port that supports OTG functionality.
In the device tree, set thedr_mode
property of the USB OTG controller to “peripheral” or “otg” to enable device mode.
Configure the TUSB320 USB-C controller (or equivalent) to operate in UFP (Upstream Facing Port) mode, which allows the device to act as a USB peripheral.
Configuring USB Gadget Drivers :
Load the appropriate Linux USB gadget driver for the desired functionality, such asg_ether
for Ethernet over USB,g_serial
for a serial device, etc.
Manually configure the USB network interface, such as assigning an IP address tousb0
.
Connecting to a Host :
Use a USB-C to USB-C or USB-C to USB-A cable to connect the Linux device in OTG device mode to a host PC.
The host PC should then detect the Linux device as a USB peripheral, allowing file transfer, network connectivity, or other functionality depending on the configured gadget driver.
Gateworks.com Wiki Linux OTG
Kernel.org Driver-API USB Gadget
Collabora Blog Modern Linux USB Gadget integration with Systemd Part1
A tool :
gt
Rust library :
usb-gadget
C Library :
libusbgx
Possibly. But from my research it seems to really depend.
the USB-C ports on the two PCs need to support USB OTG (On-The-Go) functionality, which allows the ports to dynamically switch between host and device modes. This is what enables the direct PC-to-PC communication over the USB-C connection.
1. Monopolistic business practices to crush competition (Netscape, Java, web browsers, etc.).
2. Illegal bundling of Internet Explorer with Windows to eliminate browser rivals.
3. Keeping useful Windows APIs secret from third-party developers to disadvantage competitors.
4. Embracing proprietary software and vendor lock-in tactics to prevent users from switching.
5. “Embrace, Extend, Extinguish” strategy against open source software.
6. Privacy violations through excessive data collection, user tracking, and sharing data with third parties.
7. Complicity in enabling government surveillance and spying on user data (PRISM scandal).
8. Deliberately making hardware/software incompatible with open source alternatives.
9. Anti-competitive acquisitions to eliminate rivals or control key technologies (GitHub, LinkedIn, etc.).
10. Unethical contracts providing military technology like HoloLens for warfare applications.
11. Failing to address workplace issues like sexual harassment at acquired companies.
12. Forced automatic Windows updates that override user control and cause system issues.
13. Maintaining monopolistic dominance in productivity software and operating systems.
14. Vague and toothless AI ethics principles while pursuing lucrative military AI contracts.
15. Continued excessive privacy violations and treating users as products with Windows.
16. Restrictive proprietary licensing that stifles open source adoption.
This isn’t even anywhere near everything.