Rustmilian

1. Monopolistic business practices to crush competition (Netscape, Java, web browsers, etc.).

• Microsoft was found guilty of maintaining an illegal monopoly and engaging in anti-competitive tactics against competitors like Netscape Navigator and Java in the 1990s antitrust case.

2. Illegal bundling of Internet Explorer with Windows to eliminate browser rivals.

• The U.S. government accused Microsoft of illegally bundling Internet Explorer with Windows to crush competition from other web browsers. Microsoft was found guilty of this tying arrangement.

3. Keeping useful Windows APIs secret from third-party developers to disadvantage competitors.

• Microsoft allegedly kept useful Windows APIs secret from third-party developers to give an advantage to their own applications, though this was not a central part of the antitrust case.

4. Embracing proprietary software and vendor lock-in tactics to prevent users from switching.

• Microsoft has been criticized for embracing proprietary software and vendor lock-in tactics that make it difficult for users to switch to alternatives, such as their failed attempts to establish OOXML as an open standard for Office documents.

5. “Embrace, Extend, Extinguish” strategy against open source software.

• Microsoft has been accused of using the “Embrace, Extend, Extinguish” strategy against open source software to undermine adoption of open standards. This is also shown in the leaked Halloween documents.

6. Privacy violations through excessive data collection, user tracking, and sharing data with third parties.

• Microsoft has faced scrutiny over privacy issues, such as the NSA surveillance scandal and their handling of user data with Windows 10.

7. Complicity in enabling government surveillance and spying on user data (PRISM scandal).

• The PRISM surveillance scandal revealed Microsoft’s complicity in enabling government spying on user data.

8. Deliberately making hardware/software incompatible with open source alternatives.

• Microsoft has been accused of deliberately making hardware and software incompatible with open source alternatives through restrictive licensing requirements.

9. Anti-competitive acquisitions to eliminate rivals or control key technologies (GitHub, LinkedIn, etc.).

• Microsoft has acquired many companies over the years, sometimes in an effort to eliminate competition or gain control over key technologies and platforms.

10. Unethical contracts providing military technology like HoloLens for warfare applications.

• Microsoft’s $480 million contract to provide HoloLens augmented reality tech for the military drew protests from employees and criticism over aiding warfare.

11. Failing to address workplace issues like sexual harassment at acquired companies.

• Microsoft’s failed acquisition of gaming company Activision Blizzard raised concerns about ignoring workplace issues like sexual harassment at the acquired company.

12. Forced automatic Windows updates that override user control and cause system issues.

• Microsoft has faced backlash for forcing automatic updates on Windows users, including major updates that have caused issues like deleted files and crashed systems. Users have little control over when updates install.

13. Maintaining monopolistic dominance in productivity software and operating systems.

• Microsoft has maintained its dominance in areas like productivity software (Office) and operating systems (Windows), making it difficult for competitors to gain market share. This monopolistic position allows them to exert control over the industry.

14. Vague and toothless AI ethics principles while pursuing lucrative military AI contracts.

• Microsoft’s AI ethics principles have been criticized as vague and toothless in light of their pursuit of lucrative military AI contracts.

15. Continued excessive privacy violations and treating users as products with Windows.

• Windows 10 has been criticized for excessive data collection and lack of user privacy controls, essentially treating users as products to be monetized.

16. Restrictive proprietary licensing that stifles open source adoption.

• Microsoft’s proprietary software licensing makes it difficult for open source alternatives to be adopted widely, as they have a history of undermining open source software and interoperability with Windows.

This isn’t even anywhere near everything.

There are a few candidates, the most prominent are probably :

• Greg Kroah-Hartman: Played a pivotal role in stabilizing the memory management subsystem and enhancing block I/O performance, both critical areas for system stability and performance.
• Sage Sharp (formally Sarah Sharp) : Instrumental in the development and maintenance of the networking subsystem and the ARM architecture code, ensuring compatibility and efficient networking for various ARM-based devices.
• Git Junio Hamano: Maintainer of Git, the version control system that underpins Linux development. His leadership in maintaining Git ensures smooth collaboration and efficient code management for the vast kernel developer community.

Greg Kroah-Hartman is speculated to be the most likely candidate, but it also depends on a few factors. Like, if Linus dies suddenly vs dying slowly or just stepping down, there’d be a big difference in selection process.

Ofc, things may change in the future and there’s many other talented developers who can be considered. Nothing is set in stone.

Linus hasn’t written kernel code in years at this point, however he still is the final gate keeper of what gets merged and an active code reviewer, he manages the entire direction of the project.

As of what will happen when Linus passes, that’s already been decided. The position of projects leader will go to his most trusted project co-maintainer, which we have a good idea of who that is.

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.

That’s the way Vaxry spun it to try making them look bad while he downplays his own behavior and malpractice. Basically he just lied and spread misinformation, he really needs to get his act together if he ever wants to work with them again.

That’s not what’s happening here. They are barring him from participating in their project, he can still say whatever the fuck he wants on his own project. They just don’t want to work with him.

If you walk into a job interview and they find your tweets of you saying the nword over and over, and you don’t get the job, that’s a you problem. Nobody wants to work with people who’ll bring negative PR.