Conversation

Notices

1. Embed this notice
   Harry Sintonen (harrysintonen@infosec.exchange)'s status on Monday, 29-Sep-2025 02:39:54 JST Harry Sintonen

   If #git makes #Rust mandatory it will block future git versions to be ported to our niche platform. While this would not immediately lock us out of repos (the current version will likely continue to work fine some time) it eventually would complicate access (all git work would need to be circulated via some proxy setups or similar).

   Needless to say I'm not thrilled by this idea.

   I am not against Rust. I am against breaking change that leaves everyone not embracing Rust behind.

   https://lore.kernel.org/git/20250904-b4-pks-rust-breaking-change-v1-0-3af1d25e0be9@pks.im/

   • Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Peter Krefting (nafmo@social.vivaldi.net)'s status on Monday, 29-Sep-2025 02:39:54 JST Peter Krefting

     in reply to

     @harrysintonen Maybe have a look at got - Game if Trees - the OpenBSD reimplementation?

     https://gameoftrees.org/index.html

   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Monday, 29-Sep-2025 23:45:54 JST Haelwenn /элвэн/ :triskell:

     in reply to
     @harrysintonen Yeah, specially as that's for a core feature rather than the optional ones like the perl scripts git has which you can entirely live without.
   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Monday, 29-Sep-2025 23:52:02 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • Haelwenn /элвэн/ :triskell:
     @harrysintonen And even if you ignore the ancient parts of niche systems, making it hard to get git could pretty much destroy osdev.
     
     And hopefully not impossible due to circular dependencies. Like cargo could end up creating, as it directly depends on 3 git crates (among others) while that git patchset depends on cargo. Thankfully at least one of those three deps is libgit2 which doesn't plans to get Rust.
   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Tuesday, 30-Sep-2025 20:02:21 JST 翠星石

     in reply to

     • Kornel
     • Bitslingers-R-Us
     @AnachronistJohn @kornel >npm moment when crates get backdoored
     What if I told you that it is almost guaranteed that the rust compiler itself has been backdoored multiple times?
   • Embed this notice
     Kornel (kornel@mastodon.social)'s status on Tuesday, 30-Sep-2025 20:02:22 JST Kornel

     in reply to

     • Bitslingers-R-Us

     @AnachronistJohn it's cool that it's possible, and I don't have anything against it. But if I'm forced to choose between writing software that might run on SuperH (but probably won't due to speed & RAM requirements) vs being able to write more reliable software that runs better on still-manufactured CPUs, I choose the latter. I also gain access to thousands of new libraries, with better interfaces, and painless support for Windows. I can do more things in practice, and find them more valuable.

   • Embed this notice
     Bitslingers-R-Us (anachronistjohn@zia.io)'s status on Tuesday, 30-Sep-2025 20:02:22 JST Bitslingers-R-Us

     in reply to

     • Kornel

     @kornel That’s the thing - you’re not asked to choose between “writing software that might run on SuperH (but probably won’t due to speed & RAM requirements) vs being able to write more reliable software that runs better on still-manufactured CPUs”.

     You invented those limitations. If you received a problem report about running on SuperH, it sounds like you’d focus more on how “irrelevant” it is, how support is a waste of time, perhaps, rather than focusing on the idea that fixing something, even something that’s an edge case, generally means code is better.

     The Rust ecosystem is nice and all, and nobody is saying that anyone should abandon it. Of course you’ll all have your npm moment when crates get backdoored, but that’s just how these things work.

     The real issue is that people in the Rust community want to replace everything with Rust versions while dismissing fallout as unimportant because “obscure/legacy”.

     Sorry, but no.

   • Embed this notice
     Bitslingers-R-Us (anachronistjohn@zia.io)'s status on Tuesday, 30-Sep-2025 20:02:23 JST Bitslingers-R-Us

     in reply to

     • Kornel
     • Charlie Balogh
     • Bitslingers-R-Us

     @chainq @kornel Here’s a good example. How many people are even aware of the existence of SuperH? Do you know about SuperH? People who advocate for the dropping of i386 make claims of “cost” and “developer time” - of course they’d advocate for dropping support for processors they’re not even aware exist. Yet if you have a working (non Rust) toolchain, you can compile thousands of open source packages that were written by people of whom a vast majority probably know little or nothing of SuperH:

     https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/sh3el/

     It’s somehow viable in 2025 to have something like this with a modern toolchain, a modern OS, and thousands of compiled packages. So should people like you, who would most certainly consider SuperH to be “obscure/legacy”, be listened to when you advocate for Rust and the exclusion of what you somewhat dismissively consider to be “obscure/legacy”?

     Rust is fine, but the advocacy is a bit exhausting, especially from people who show little awareness of the implications of getting what you claim to want.

   • Embed this notice
     Bitslingers-R-Us (anachronistjohn@zia.io)'s status on Tuesday, 30-Sep-2025 20:02:24 JST Bitslingers-R-Us

     in reply to

     • Kornel
     • Charlie Balogh
     • Bitslingers-R-Us

     @kornel @chainq This is bad for the planet. We should make good use of our computing resources and not intentionally landfill them. m68k is an example of how we can maintain support for non-mainstream if we want, yet people who know nothing about m68k would love to kill it for emotional reasons. We don’t need this at all. We’re already seeing this with Debian and i386.

     So when people want to lump things in to an “obscure/legacy” category and suggest that the problem isn’t Rust, that just means you’re cheerleading for reducing sustainability.

   • Embed this notice
     Kornel (kornel@mastodon.social)'s status on Tuesday, 30-Sep-2025 20:02:25 JST Kornel

     in reply to

     • Charlie Balogh

     @chainq There's definitely a mismatch of values, and Rust is future-looking rather than backwards-looking.

     Rust is 10 years past 1.0 release. The implementation is quite mature in what it targets.

     Lack of obscure/legacy things is immaturity only if you assume having them is a goal, but Rust prioritized other things, like safe multithreading, early WASM support, modules, error handling, metaprogramming, UB prevention/detection. From Rust's perspective these are woefully immature hacks in C.

   • Embed this notice
     Bitslingers-R-Us (anachronistjohn@zia.io)'s status on Tuesday, 30-Sep-2025 20:02:25 JST Bitslingers-R-Us

     in reply to

     • Kornel
     • Charlie Balogh

     @kornel @chainq

     Lack of obscure/legacy things is immaturity only if you assume having them is a goal, but Rust prioritized other things

     You illustrate the problem perfectly here: thinking that it’s either / or is a broken way of thinking.

     Even if it were the case that prioritizing certain things precludes others (which it most certainly isn’t, unless you’re doing things incorrectly), this is precisely why Rust is inappropriate for universal adoption.

     If a certain corporate led group gets to decide what is “obscure/legacy”, then people either have to maintain their own forks of Rust, or we just have to blindly accept that things that aren’t popular enough or that don’t get enough attention by corporations will be deemed, “obscure/legacy”.

   • Embed this notice
     Charlie Balogh (chainq@mastodon.social)'s status on Tuesday, 30-Sep-2025 20:02:26 JST Charlie Balogh

     in reply to

     • Kornel

     @harrysintonen @kornel A couple of years back, there was a even proposal to change the m68k Linux ABI to cater for the internal limitations of Rust and LLVM that was ill equipped to deal with the requirements of this - admittedly, historic - architecture.

     Being a compiler hacker myself, to me this meant: it is seriously immature, not ready for prime time. But for people pushing Rust, throwing away 4 decades of compatibility was completely justified, because fixing the world was more important.

   • Embed this notice
     Charlie Balogh (chainq@mastodon.social)'s status on Tuesday, 30-Sep-2025 20:02:26 JST Charlie Balogh

     in reply to

     • Kornel

     @harrysintonen @kornel I think the problem was that it was a 32bit platform that had a less than 4 byte natural alignment - 2 byte in case of m68k - and this needed very deep changes to accommodate. But don't quote me on this. Maybe this was fixed since, no idea, I stopped caring.

     We obviously do not speak the same languages nor share most values with these people. I tried to have an open mind, but the way it is pushed just makes me resent the whole thing. Maybe "I'm too old for this shit."

   • Embed this notice
     Kornel (kornel@mastodon.social)'s status on Tuesday, 30-Sep-2025 20:02:27 JST Kornel

     in reply to

     @harrysintonen A platform that needs to run dev tools itself (rather than being a compilation target), but isn't supported by LLVM seems to be a niche of niches.

   • Embed this notice
     Harry Sintonen (harrysintonen@infosec.exchange)'s status on Tuesday, 30-Sep-2025 20:02:27 JST Harry Sintonen

     in reply to

     • Kornel

     @kornel We of course employ cross-compiling. But still, being left out in that manner is still unfortunate, as we try to offer as complete and modern native SDK as possible.

     I fully acknowledge that this is something we just have to live with. We are doing our own thing, and we can't possibly expect everyone else to cater for our platform quirks.

     However, there are other platforms far from being this obscure that will be hit as well: Various legacy Debian platforms (alpha, hppa, m68k and sh4) and NonStop, AIX and Solaris come to mind at least. There are likely more.