Why just cringe at the “toxic sludge cesspool” when you can compile it with CONFIG_RUST=n?

[shrekushka]

Rust adds new shit that clash sharply with Linux’s traditional freewheeling ptr arithmetic + “we’ll fix it if it breaks” philosophy. DMA in Rust means wrapping scattered dma_map_* calls behind safe abstractions, effectively duplicating/parallelizing entire chunks of kernel logic in another lang. That’s where the friction arises: changing (or even just extending) such a large, legacy C codebase unavoidably spooks entrenched subsystem maintainers. They see multiple langs as a fractal of “what if our future patches break Rust code and we have to care?”.

One could argue the toxicity stems from having no definitive governance stance on multilang kernel expansion.

LKML: Hector Martin: [PATCH] MAINTAINERS: Remove myself

 

[weaver]

Rust is an unsafe programming language. It also has memory corruption.

All this nonsense to rewrite one language to another. They do the right thing by hating Rust in Linux. Want to write code for Linux in Rust? Do Redox. It has no place in vanilla Linux.

 

[shrekushka]

“Rust had a bug, so it’s worthless” == condemn C to the netherworld.

The kernel community’s real debate is how to integrate Rust in a stable+ maintainable way, not whether mem safety has any merit.

I have many stories of sending simple one line driver fixes that never got merged. Maintainers disregard / forget patches w/o official trackers. It gets demoralizing to “send patches via email, hope someone notices”.
Con Kolivas withdrew his CPU scheduler 20 years ago over mainline friction, TuxOnIce was blocked from merge etc. A pattern that large changes often face unmovable maintainers...

Still:

Rust is an unsafe programming language. It also has memory corruption.

The exploit hinged on int math in a lib func, not a fundamental inability of Rust to ensure memsafety for normal usage.
+ quickly patched + triggered under absurdly large inputs (multigig allocas) that normal Rust code patterns typically prohibit/ panic on.
That’s a world away from the daily footguns in stdC.


Apple GPU drivers for asahi + Google’s android kernels. It’s not a purely hypothetical academic interest: major contributors are adopting it incrementally. No serious contributor wants a mass line by line rewrite. Instead, we need incremental modernization. Linux is large enough that mixing langs can provide real benefits in new code areas. Chrome has multilang components with minimal friction. A wellmaintained Rust driver boundary is not the apocalyptic scenario that alarmists predict.

 

[DimmuBurgor]

“Rust had a bug, so it's worthless” == condemn C to the netherworld.

The kernel community's real debate is how to integrate Rust in a stable+ maintainable way, not whether mem safety has any merit.

I have many stories of sending simple one line driver fixes that never got merged. Maintainers disregard / forget patches w/o official trackers. It gets demoralizing to “send patches via email, hope someone notices”.
Con Kolivas withdrew his CPU scheduler 20 years ago over mainline friction, TuxOnIce was blocked from merge etc. A pattern that large changes often face unmovable maintainers...

Still:

The exploit hinged on int math in a lib func, not a fundamental inability of Rust to ensure memsafety for normal usage.
+ quickly patched + triggered under absurdly large inputs (multigig allocas) that normal Rust code patterns typically prohibit/ panic on.
That's a world away from the daily footguns in stdC.


Apple GPU drivers for asahi + Google's android kernels. It's not a purely hypothetical academic interest: major contributors are adopting it incrementally. No serious contributor wants a mass line by line rewrite. Instead, we need incremental modernization. Linux is large enough that mixing langs can provide real benefits in new code areas. Chrome has multilang components with minimal friction. A wellmaintained Rust driver boundary is not the apocalyptic scenario that alarmists predict.

Is that you, Dildog? =))

 

[weaver]

What I'm getting at is that you should continue rewriting everything in Rust and praying to it. It won't help you. Although the author of the article said that this vulnerability is not an indicator, in fact it is an indicator. There are tons of such errors in Rust, there are just not enough exploits now. But there will come a time when everyone will be interested in Rust and then there will be a whole mountain of exploits. Poor Bjarne Stroustrup raised idiots to his own detriment... It's not his fault that you have to write a lot and faster. People who design a safe language say it will protect against memory corruption and then... It's just ridiculous.

 

[shrekushka]

Is that you, Dildog? =))

I never bothered with MS-DOS. The arts/journalism folks swore by System 6 and 7, while we lived on 4.4.

What I'm getting at is that you should continue rewriting everything in Rust and praying to it. It won't help you. Although the author of the article said that this vulnerability is not an indicator, in fact it is an indicator. There are tons of such errors in Rust, there are just not enough exploits now. But there will come a time when everyone will be interested in Rust and then there will be a whole mountain of exploits. Poor Bjarne Stroustrup raised idiots to his own detriment... It's not his fault that you have to write a lot and faster. People who design a safe language say it will protect against memory corruption and then... It's just ridiculous.

I don't know how I turned into the Rust supporter here but now that we're here

Absolutely, more Rust vulns will be found as it grows in popularity: that’s normal. But a fundamental diff: Rust’s defaults actively block entire classes of mem bugs + require explicitly quarantined code to do unsafe ops. That drastically reduces the scale + probability of catastrophic chain reactions in ptr baesed flaws.

The push by .govs + corps to adopt memsafe langs is not a marketing fad. It’s a response to the continuous stream of expensive attacks.

If anything, Stroustrup’s efforts highlight the “evolution or extinction” scenario for C/C++. We can’t rely on goodwill + nostalgia alone. This is not a condemnation of C++, but it's a stark admission from its fucking creator that the “status quo is untenable”. That’s not an own goal for Rust: it’s a vindication of Rust’s safetyfirst approach.

 

[shrekushka]

https://www.patreon.com/profile/creators?u=4557983

Fuckkk

 

[DimmuBurgor]

I never bothered with MS-DOS. The arts/journalism folks swore by System 6 and 7, while we lived on 4.4.

What is this in reference, or alluding to?

 

[shrekushka]

What is this in reference, or alluding to?

Long story short, I never really touched DOS (or later on 9x or for that matter even NT) enough to fit the ‘Dildog’ bill

 

[DimmuBurgor]

Long story short, I never really touched DOS (or later on 9x or for that matter even NT) enough to fit the 'Dildog' bill

I would say that his ardent support, and use of Rust is much more characteristic than those antiquities but recency bias might explain