Re: Planned obsolescence ? (*BSD, Rust)
Man, I really hate to chime in on a big email chain as a random user, but... I'm part of the Sega Dreamcast homebrew community and the bigger SH4 scene, and while sure, we're relatively ancient, there are actually a lot of us, and there is a LOT of love left for the target. We have had many, many people express interest in using Rust on the Dreamcast and SH4, and we have done everything in our power to personally help facilitate getting Rust support for our target in any way possible, including supporting the early work of GCCRS and have done a LOT of testing and experimenting with rustc_codegen_gcc on SH4, and even got it far enough along to run the Tokio async runtime and whole stdlib on the Dreamcast. While I fully understand wanting to use Rust or not wanting to be held back by legacy hardware, I do wonder if the timeframe given is a bit aggressive given the fact that there are TWO avenues which would open up support for Rust to our platform which are both in the works... On Tue, Nov 4, 2025 at 6:35 AM Dr. Arne Babenhauserheide wrote: > > David Starner writes: > > The developer has decided to do a rewrite in Rust instead of some > > other memory safe language. There are certain advantages to going with > > the language more people know and use. Part of it is that systems that > > don't support Rust are going to be less and less capable of using > > modern software. (For a counter example, look at CVSup, written in > > This sounds awful. Especially since it is a software issue: the hardware > is capable of running Rust, it’s just LLVM that doesn’t support it. > > Riccardo Mottola writes: > > Perhaps if rust on GCC gives "enough rust" do compile the needed > > tools, it might be enough to support also architectures whic gcc > > supports, that is for now 68k, PPC, Alpa, HP-PA... > > [1] https://rust-gcc.github.io/ > > I asked in #gccrust IRC on oftc.net GCCrs about the state and sam > pointed me to a recent timeline update: > > > We still think we'll be able to compile libcore before the end of the > > summer > … > > We expect to be able to compile some 1.49 code correctly next year > … > > The next targeted version will probably be rust 1.78 as we want to > > keep up with rust for linux. This shouldn't be too long > > -- > https://lore.kernel.org/git/[email protected]/ > > So maybe not kill support for old hardware when a solution may be > available next summer. > > At that point it would be viable to ask people to test their projects > against GCCrs, too. > > Best wishes, > Arne > -- > Unpolitisch sein > heißt politisch sein, > ohne es zu merken. > draketo.de >
Re: Planned obsolescence ? (*BSD, Rust)
Am 03.11.25 um 23:20 schrieb Jan-Daniel Kaplanski: Yes, 20 year old hardware is looking ancient and retro. To specify, I was refering to x86-64-v1 hw when I said "reasonably large amount of users". As I wrote already, that hw is still in mainstream use in the form of used Core2Duo-era office PCs that gained a second life as someone's home PC. There is no practical reason to use Linux on any of those [...] Except for homelabers, in enterprise environments (legacy software!) or lab environments (specialised hardware peripherals), etc. FYI: CERN has started to look into replacing RHEL with Debian on the Front End Computers of the Large Hadron Collider (LHC) especially *because* ~ 50% of the installed hardware does only provide support for x86_64-v1 and cannot be operated with RHEL9 and above. This hardware is essential for keeping the LHC running (at least until 2035?) and operating it with RHEL 7 until then is apparently not feasible. See https://indico.cern.ch/event/1477299/contributions/6363918/attachments/3044399/5378883/20250403-HEPiX-cern-els7.pdf (esp. slide 7 and slide 34) So dropping x86_64-v1 would be a bummer for them – and probably also for Debian? Best Christopher smime.p7s Description: Kryptografische S/MIME-Signatur
Re: Planned obsolescence ? (*BSD, Rust)
David Starner writes: > The developer has decided to do a rewrite in Rust instead of some > other memory safe language. There are certain advantages to going with > the language more people know and use. Part of it is that systems that > don't support Rust are going to be less and less capable of using > modern software. (For a counter example, look at CVSup, written in This sounds awful. Especially since it is a software issue: the hardware is capable of running Rust, it’s just LLVM that doesn’t support it. Riccardo Mottola writes: > Perhaps if rust on GCC gives "enough rust" do compile the needed > tools, it might be enough to support also architectures whic gcc > supports, that is for now 68k, PPC, Alpa, HP-PA... > [1] https://rust-gcc.github.io/ I asked in #gccrust IRC on oftc.net GCCrs about the state and sam pointed me to a recent timeline update: > We still think we'll be able to compile libcore before the end of the > summer … > We expect to be able to compile some 1.49 code correctly next year … > The next targeted version will probably be rust 1.78 as we want to > keep up with rust for linux. This shouldn't be too long > -- > https://lore.kernel.org/git/[email protected]/ So maybe not kill support for old hardware when a solution may be available next summer. At that point it would be viable to ask people to test their projects against GCCrs, too. Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de signature.asc Description: PGP signature
Re: Planned obsolescence ? (*BSD, Rust)
Hi Jan-Daniel, Jan-Daniel Kaplanski wrote: Also, let's not forget that while Rust is memory safe per default, it isn't a bug-free paradise. You can still have logic bugs. Of which there was one recently in the Rust implementation of coreutils, specifically '"date -r file" returns a wrong date'[4], which directly caused unattended upgrades to break in Ubuntu 25.10 [5] (or any other program that relied on a date check of a file for that matter). It goes to show that a rewrite introduces a potential for new bugs that are unrelated to the original implementation, even if that rewrite happens to be in Rust. nice example where a tool is the issue, certain tools are sold for their safety and might give a false sense of safety when using them. It feels like the movement to introduce Rust everywhere is more because Rust has become such a buzzword that everyone must use it now and less because of the capabilities of Rust. Not to throw shade, but if the only benefit is memory safety you might as well do a rewrite in any other memory safe language that provides I/O access (e.g. Haskell) instead. I stand to this analysis... rust has now an aura of safety beyond its own merit, it is clearly a buzz or hype. I would rather keep it out of a "core" system and leave the language issue to user applications. However, we might soon disagree what "core" is and today it becomes rapidly complex (e.g. you may want to expect both a SSH and a command line package manager which connects through various network options, a framebuffer... ). Perhaps if rust on GCC gives "enough rust" do compile the needed tools, it might be enough to support also architectures whic gcc supports, that is for now 68k, PPC, Alpa, HP-PA... Riccardo [1] https://rust-gcc.github.io/
Re: Planned obsolescence ? (*BSD, Rust)
On Mon, Nov 3, 2025 at 4:20 PM Jan-Daniel Kaplanski wrote: > > > Yes, 20 year old hardware is looking ancient and retro. > To specify, I was refering to x86-64-v1 hw when I said "reasonably large > amount of users". Which works just fine with Rust. It's strictly unhelpful to confound the two issues. > > There is no practical reason to use Linux on any of those [...] > Except for homelabers, in enterprise environments (legacy software!) or > lab environments (specialised hardware peripherals), etc. In what cases would you use Linux on any of the four systems I mentioned for legacy software or specialized hardware peripherals? As for homelabers, yes, it's fun to make an old Mac run Linux/m68k, but that doesn't mean it's practical. > > a Pi 5 soundly beats any of those systems ever made > And a Threadripper PRO 9995WX based system soundly beats any Pi 5. So > going by your logic there isn't a practical reason to run Linux on a Pi > 5, because there is a more capable system out there. That logic isn't > very sound, yk? No, a Threadripper PRO 9995WX is way more expensive than a Pi 5, it draws way more power, it's way louder and takes way more space. You will save the cost of the Raspberry Pi in a year on electrical costs alone. There is no practical reason to run Linux on HPPA or Alpha or SH4 or m68k. > That only means that in the future you'd have to have a highly > specialised Rust-dev team in any major OS-related project. And for what > purpose? Just because everyone does it. Is this just a grousing session? -- The standard is written in English . If you have trouble understanding a particular section, read it again and again and again . . . Sit up straight. Eat your vegetables. Do not mumble. -- _Pascal_, ISO 7185 (1991)
Re: Planned obsolescence ? (*BSD, Rust)
Yes, 20 year old hardware is looking ancient and retro. To specify, I was refering to x86-64-v1 hw when I said "reasonably large amount of users". As I wrote already, that hw is still in mainstream use in the form of used Core2Duo-era office PCs that gained a second life as someone's home PC. There is no practical reason to use Linux on any of those [...] Except for homelabers, in enterprise environments (legacy software!) or lab environments (specialised hardware peripherals), etc. a Pi 5 soundly beats any of those systems ever made And a Threadripper PRO 9995WX based system soundly beats any Pi 5. So going by your logic there isn't a practical reason to run Linux on a Pi 5, because there is a more capable system out there. That logic isn't very sound, yk? There are certain advantages to going with the language more people know and use. Yup, that's the reason OS code is usually written in C. Part of it is that systems that don't support Rust are going to be less and less capable of using modern software. That only means that in the future you'd have to have a highly specialised Rust-dev team in any major OS-related project. And for what purpose? Just because everyone does it. It is what is going to happen eventually, so yes, Rust should be supported, but for what it's worth it should only be used if it actually makes sense to use it IMHO. Use it to write a suid binary? Sure, memory safety! Use it to write a program that only handles data streams, have 17 times slower performance and close the bug because now it's only 1.x to 2.x times slower than the C implementation? Eh.[1] Cheers, JD [1]: https://github.com/uutils/coreutils/issues/8573 smime.p7s Description: Kryptografische S/MIME-Signatur
Re: Planned obsolescence ? (*BSD, Rust)
On 11/3/25 16:16, David Starner wrote: On Mon, Nov 3, 2025 at 12:35 AM Jan-Daniel Kaplanski wrote: That said, 20 year old hardware that is still in-use today by a reasonably large amount of users isn't something I'd consider ancient or retro. Yes, 20 year old hardware is looking ancient and retro. Firstly a RPi5 is cute and hardly able to compete with a server that has 256G of memory and many processor cores. So if you are thinking just plain raw computational throughput the RPi5 is what it is. Cute. Building RUST from source is a bit of a sham. A cute trick. Watch this as I pull a rabbit from my hat. Based on my observations with the latest top-of-the-line cadillac hardware for RISC-V one must fetch a static binary built somewhere magic in order to build rust. Then the hardware will thrash for four days. Maybe six days[1]. The same would be true on any hardware that is ten years old. I can demonstrate that test easily enough. So the "Great RUST Invasion" into source code all over the place[2] will demand that rust be built all over the place. Planned obsolescence? More like enforced obsolescence and hey you! Pay up more money and buy more hardware! -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken [1] on the horrific SiFive UnMatched RevB board : ===> Cleaning for rust-1.89.0 build of lang/rust | rust-1.89.0 ended at Fri Sep 12 19:09:59 UTC 2025 build time: 6D:01:19:22 [2] emacs ? yes emacs wants a bit of rust. When trying to build some packages I see that a ton of them need rust. The Great RUST Invasion is everywhere chafa-1.16.2_1 emacs-30.2,3 fastfetch-2.53.0 gnome-themes-extra-3.28_5 gtk3-3.24.51 ImageMagick7-7.1.1.45_4 imlib2-1.12.5_1,2 librsvg2-rust-2.60.0_6 lxappearance-obconf-0.2.3_8 lxde-common-0.99.2_3 lxde-meta-1.0_8 obconf-2.0.4_7 openbox-3.6_14 qt6-base_sqldriver-sqlite-6.9.3 qt6-base-6.9.3_1 qt6-declarative-6.9.3 qt6-languageserver-6.9.3 qt6-shadertools-6.9.3 qt6-svg-6.9.3 qt6-tools-6.9.3 sddm-0.21.0.36_1 xscreensaver-6.12
Re: Planned obsolescence ? (*BSD, Rust)
On Mon, Nov 3, 2025 at 12:35 AM Jan-Daniel Kaplanski wrote: > That said, 20 year old hardware that is still in-use today by a reasonably > large amount of users isn't something I'd consider ancient or retro. Yes, 20 year old hardware is looking ancient and retro. There seem to be four architectures at issue: Alpha, HPPA, m68k and SH4. There is no practical reason to use Linux on any of those instead of a Raspberry Pi; a Pi 5 soundly beats any of those systems ever made. SH4 (Dreamcast) and m68k are reasonably available, but Alpha and HPPA always had limited availability. > It feels like the movement to introduce Rust everywhere is more because Rust > has become such a buzzword that everyone must use it now and less because of > the capabilities of Rust. Not to throw shade, but if the only benefit is > memory safety you might as well do a rewrite in any other memory safe > language that provides I/O access (e.g. Haskell) instead. The developer has decided to do a rewrite in Rust instead of some other memory safe language. There are certain advantages to going with the language more people know and use. Part of it is that systems that don't support Rust are going to be less and less capable of using modern software. (For a counter example, look at CVSup, written in Modula-3. An essential tool in FreeBSD, it was rewritten in C, because while Modula-3 is a nice language, it's also a dead one.) -- The standard is written in English . If you have trouble understanding a particular section, read it again and again and again . . . Sit up straight. Eat your vegetables. Do not mumble. -- _Pascal_, ISO 7185 (1991)
Re: Planned obsolescence ? (*BSD, Rust)
OpenBSD has the express goal of supporting ancient hardware. As has NetBSD for that matter: "*Continuing stable support * for a wide range of "legacy" hardware and ABIs. There's long-term backwards compatibility to even the earliest NetBSD releases without compromising on feature like 64-bit time. We intend to keep these systems running long after Year 2038. "[1] That said, 20 year old hardware that is still in-use today by a reasonably large amount of users isn't something I'd consider ancient or retro. There is disagreement between OpenBSD's view on Rust's cost/benefit with a stable, reviewed and maintained C codebase and most of the rest of the industry, (and within apt) -- but again, that's not important here. It's not limited to OpenBSD to be sceptic about Rust implementations. For one, Linus Torvalds has recently expressed his frustration on the Linux kernel mailing list with the borked rust format checking which may result in unnecessary merge conflicts. [2][3] Also, let's not forget that while Rust is memory safe per default, it isn't a bug-free paradise. You can still have logic bugs. Of which there was one recently in the Rust implementation of coreutils, specifically '"date -r file" returns a wrong date'[4], which directly caused unattended upgrades to break in Ubuntu 25.10 [5] (or any other program that relied on a date check of a file for that matter). It goes to show that a rewrite introduces a potential for new bugs that are unrelated to the original implementation, even if that rewrite happens to be in Rust. It feels like the movement to introduce Rust everywhere is more because Rust has become such a buzzword that everyone must use it now and less because of the capabilities of Rust. Not to throw shade, but if the only benefit is memory safety you might as well do a rewrite in any other memory safe language that provides I/O access (e.g. Haskell) instead. Cheers, JD [1]: https://www.netbsd.org/about/ [2]: https://lore.kernel.org/lkml/CAHk-=wgo7s_fzusbbngg5vtejwopzdfttbkvvp3_yjjmfdd...@mail.gmail.com/ [3]: https://news.itsfoss.com/linus-torvalds-criticizes-drm-merge/ [4]: https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bug/2127970 [5]: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/2129660 smime.p7s Description: Kryptografische S/MIME-Signatur
