RustOut : Solutions for dealing with corrosive software

Are you tired of bloated snakeoil sold with the promise of "Memory Safety", "security" or everlasting life? The RustOut project provides scripts, patches and forks for popular Free Software that removes corrosive or non-free parts. The focus is to put the user in charge of the software they depend upon; not overbearing corporations whose goals no longer align with many in the community. If you are happy with the way things are, you can safely ignore this...everything is fine.

Why is this "project" a thing?

Many in the community are not happy with the direction that things are going. Many F/OSS projects have become so bloated or taken it upon themselves to abuse their users that something needs to be done. Issues with trust, telemetry, privacy, security and bloat have all become ubiquitous in the realm of F/OSS. With more threats on the horizon and resources becoming scarce, this trend can't continue forever. Respect for those who chose to use your software is the most important thing; it can't be commanded or asserted.

What's wrong with Rust?

The Rust programming language is bloated, run by untrustworthy entities and lacks stability that is needed with any coherent programming language. There is no formal spec, standard or guarantee that your software will build tomorrow or a decade from now. The reason that many languages became popular is because they were backed by standards and choice of tooling. Because the language changes too often, in practice, there is no third-party tooling for Rust. The lack of third-party tooling means that those using it are at the mercy of those running the show. Standards and stability matter significantly more than "Memory Safety" in a landscape where corporations are abusing F/OSS and trying to take away a user's freedom to control the software running on their computer.

Outside of tooling and standards, Cargo is plagued by the same security deficiencies that plague NPM. Sure, "cargo vendor" is a thing but is at best a "Band-Aid" that does not fix trust issues and leaky infrastructure. Individual projects should be addressing this issue but they don't in any meaningful way.

Software and programming languages should not be evangelized like the Jehovah's Witness. If a programming language or piece of software is "good", people will use it. The hand of the user should never have to be forced to use or trust the developers of a piece of software.

How are these [nonexistent] issues going to be addressed?

• The Linux Kernel : With the push for more Rust in the kernel, the tooling required to build the Linux kernel has gotten way out of hand. The tooling required to build many other operating systems is quite a bit more reasonable and usually does not depend on opaque features pushed by hostile entities (Microsoft Compiler flags ring a bell?). For long-term stability and security, it's important that people can continue to build the software well into the future.

  To address this, a series of configurations, scripts and patches can temporarily address these issues[1] but it does not solve the issue of a "tainted" kernel. A long-term (hard) fork, from a more desirable epoch, is going to be needed to fully address this. Another option is to simply walk away.

• Use alternatives that have not drunk the "Kool-Aid" : It's important to support projects that have similar values, that focus on reducing bloat where possible and to fully put the user in control of their computing. The great thing about F/OSS is the freedom of choice. It's one thing to add a cool new thing to a project but it's another when the project chooses to leave people in the cold because they choose to remove things that real people depend upon.

How can I help?

• First and foremost, speak out! Open your window and yell "I'm mad as hell and I'm not going to take it anymore!" Howard Beale - The Network Seriously, it's important to speak out about issues that are important to you and find projects that align with you. A project should never assert that they are in control. The Free Software movement has always asserted that it's the user who should be in control over their computing; not the developer.
• Check back for more developments : this is early in this endeavor and will need support from those who care about these same issues. Sending a message to INFO (AT) RUST OUT (DOT) ORG against or in support of this endeavor will go along way.

[1] It may not be viable or worthwhile to fork / continue to use the Linux kernel. The entities who control and maintain the kernel are no longer, were they ever, trustworthy. Using OpenBSD is more of an appealing option because of their correctness / proactive approach to security but too many things are married to the Linux (kernel / SystemD)