Post AyjGlYCAxLYJ36sO2K by AnachronistJohn@zia.io
(DIR) More posts by AnachronistJohn@zia.io
(DIR) Post #AyhXSdwcfOiIHZFfDU by harrysintonen@infosec.exchange
2025-09-28T15:11:10Z
1 likes, 2 repeats
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/
(DIR) Post #AyhXkAUstFOyAJdMOW by lanodan@queer.hacktivis.me
2025-09-29T14:39:25.040553Z
0 likes, 0 repeats
@harrysintonen Yeah, specially as that's for a core feature rather than a somewhat nice one like the perl scripts git has which you can entirely live without.
(DIR) Post #AyhY7OBWALX7HFeE88 by newt@stereophonic.space
2025-09-29T14:43:34.621145Z
0 likes, 0 repeats
@harrysintonen you can always use gothttps://gameoftrees.org/index.html
(DIR) Post #AyhYpnsxyL4XjE9IZ6 by lanodan@queer.hacktivis.me
2025-09-29T14:51:36.549396Z
0 likes, 0 repeats
@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.
(DIR) Post #AyjGijEbSMVoPxfM1Y by kornel@mastodon.social
2025-09-28T16:39:25Z
0 likes, 0 repeats
@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.
(DIR) Post #AyjGikPd4qvU4Rpfqi by harrysintonen@infosec.exchange
2025-09-28T16:57:04Z
0 likes, 0 repeats
@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.
(DIR) Post #AyjGilJzhI0qtGCghk by chainq@mastodon.social
2025-09-29T11:52:28Z
1 likes, 0 repeats
@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.
(DIR) Post #AyjGiqYMFJTP7FxjHs by chainq@mastodon.social
2025-09-29T12:02:24Z
0 likes, 0 repeats
@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."
(DIR) Post #AyjGkhic410WIMe2jo by kornel@mastodon.social
2025-09-29T13:07:44Z
1 likes, 0 repeats
@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.
(DIR) Post #AyjGlVkS3SBfSXtDXs by AnachronistJohn@zia.io
2025-09-29T16:12:16.669897Z
0 likes, 0 repeats
@kornel @chainqLack of obscure/legacy things is immaturity only if you assume having them is a goal, but Rust prioritized other thingsYou 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”.
(DIR) Post #AyjGlX7AyRxVhJWsbY by AnachronistJohn@zia.io
2025-09-29T16:21:08.863312Z
0 likes, 0 repeats
@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.
(DIR) Post #AyjGlYCAxLYJ36sO2K by AnachronistJohn@zia.io
2025-09-29T16:24:29.778491Z
0 likes, 0 repeats
@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.
(DIR) Post #AyjGlZIwpeZ0UP3JEO by kornel@mastodon.social
2025-09-29T18:15:50Z
0 likes, 0 repeats
@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.
(DIR) Post #AyjGlaKl0PbZgIuGgq by AnachronistJohn@zia.io
2025-09-29T23:06:14.985702Z
1 likes, 0 repeats
@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.
(DIR) Post #AyjIRJpGs6CWbFdwbA by Suiseiseki@freesoftwareextremist.com
2025-09-30T10:57:24.659110Z
0 likes, 0 repeats
@js @harrysintonen @kornel >how dare they use anything other than modern macOS, Linux or Windows?Yes, you will run either a 100% proprietary OS or run a proprietary kernel with BusyBox on the latest, most proprietary computers and you will be happy!>I am sure there will not be mentions of gccrs. It still can't compile hello world after 7+ years of development.The gccrs developers are clearly braindead, as they develop on github, but there's clearly something severely wrong with a language if you can't even compile hello world correctly after nearly a decade of development time.>by introducing Rust to librsvg, so I can no longer run a desktopYou can just use the old C version and GIMP v2.1 - too bad proprietary distros don't package that anymore.
(DIR) Post #AyjIfYZsozYUPEEchk by Suiseiseki@freesoftwareextremist.com
2025-09-30T11:00:01.993028Z
0 likes, 0 repeats
@AnachronistJohn @kornel >npm moment when crates get backdooredWhat if I told you that it is almost guaranteed that the rust compiler itself has been backdoored multiple times?