IMHO, Rust is not mature until it decides on a stable ABI, and starts being able to use non-static linking, and therefore able to produce dynamically linked binaries.
Hard Rust requirements from May onward
651–660 of 797 posts
Re: Hard Rust requirements from May onward
#652Earlier quoted context omitted.
> Or change / improve the status [quo] uutils/coreutils is MIT-licensed and primarily hosted on GitHub (with issues and PRs there) whereas GNU coreutils is GPL-licensed and hosted on gnu.org (with mailing lists). EDIT: I'm not expressing a personal opinion, just stating how things are. The license change may indeed be of interest to some companies.
So a change to the worse. The GPL protects the freedom of the users while MIT-licensed software can be easily rug-pulled or be co-opted by the big tech monopolists. Using GitHub is unacceptable as it is banning many countries from using it. You are excluding devs around the world from contributing. Plus it is owned by Microsoft. So we replaced a strong copyleft license and a solid decentralized workflow with a centra…
> The GPL protects the freedom of the users while MIT-licensed software can be easily rug-pulled or be co-opted by the big tech monopolists.
That is not at all true. If someone were to change the license of a project from MIT to something proprietary, the original will still exist and be just as available to users. No freedom is lost.
Re: Hard Rust requirements from May onward
#653Rust is a great language for devs. They love it and how developer centric everything about it is. But for end users on Debian trying to compile rust stuff is a nightmare. They do breaking changes in the compiler (rustc) every 3 months. This is not a joke or exaggeration. It's entirely inappropriate to use such a rapidly changing language in anything that matters because users on a non-rolling distro, LIKE DEBIAN, wil…
> They do breaking changes in the compiler (rustc) every 3 months. This is not a joke or exaggeration.
That is, in fact, a gross exaggeration. Breaking changes to rustc are extremely rare.
Re: Hard Rust requirements from May onward
#654Earlier quoted context omitted.
Right now, there are approximately five languages that are presumed to be acceptable for core applications in the base system: C, C++, Shell (which probably means specifically bash), Perl, and Python. The most recent language to be added to that list is Python, about 20 years ago. That's not to say that everybody likes those languages (indeed, there's quite a few commenters here who I think would be surprised to lear…
> there are approximately five languages that are presumed to be acceptable for core applications in the base system: [...] Python I don't know if you've tried to get someone else's Python running recently, but it has devolved into a disaster effectively requiring containers to accurately replicate the exact environment it was written in. Core system applications should be binaries that run with absolutely minimal de…
It really, really isn't. I wish this would stop being repeated so much.
Re: Hard Rust requirements from May onward
#655One of the follow up messages is interesting: https://lists.debian.org/debian-devel/2025/10/msg00288.html > Rust is already a hard requirement on all Debian release architectures and ports except for alpha, hppa, m68k, and sh4 (which do not provide sqv). Wonder what this means for those architectures then?
Here’s Debian’s “Supported Architectures”: https://wiki.debian.org/SupportedArchitectures . These platforms are all in ‘unofficial’ status (like, they work, but are not officially supported by the core Debian project). Who is actually _running_ Debian Trixie on these platforms now? It is counter-intuitive to me that these platforms are still unofficially supported, but 32-bit x86 [edit: and all MIPS architectures!] a…
I was running Debian unstable on my 64-bit SPARC up until I moved a few months ago and haven't set the system back up again while unpacking.
It's been somewhat useful for finding weird edge cases in software where for whatever reason, it doesn't reproduce easily on AArch64 or x86, but does there. (Or vice-versa, sometimes.)
I don't know that I'd say that's sufficient reason to motivate dozens of people to maintain support, but it's not purely academic entertainment or nostalgia, for that.
Re: Hard Rust requirements from May onward
#656Earlier quoted context omitted.
Recently the rust coreutils had a bug and this essentially disabled auto-updates on Ubuntu. :) Seeing this tone-deaf message from an Ubuntu employee would be funny if I didn’t actually use Ubuntu. Looks like I have to correct that…
Isn't it also funny that all of these things are done by the same person? In all seriousness though, let me assure you that I plan to take a very considerate approach to Rust in APT. A significant benefit of doing Rust in APT rather than rewriting APT from scratch in Rust means that we can avoid redoing all our past mistakes because we can look at our own code and translate it directly.
Honestly having seen trainwreck after trainwreck after trainwreck come out of Canonical for the last decade, I'm sure I'm not the only one that has strong doubts about anyone associated being able to "avoid redoing past mistakes" or to make things not suck.
Re: Hard Rust requirements from May onward
#657Earlier quoted context omitted.
Right now, there are approximately five languages that are presumed to be acceptable for core applications in the base system: C, C++, Shell (which probably means specifically bash), Perl, and Python. The most recent language to be added to that list is Python, about 20 years ago. That's not to say that everybody likes those languages (indeed, there's quite a few commenters here who I think would be surprised to lear…
> Shell (which probably means specifically bash) Debian has ongoing efforts to make many shell scripts (like postinst Scripts in packages etc.) non-bash-specific. A minimal Debian installation doesn't contain bash, but rather dash, which doesn't support bash extensions.
Whether with a base install via the installer, or debootstrap, I've never seen bash missing.
For clarity, 'sh' is what is softlinked to dash. Not bash.
Re: Hard Rust requirements from May onward
#658One major point of heartburn with Rust is that it comparatively lacks the diversity of ISA targets that C broadly does. I know some of this is because C is both relatively simple to write a basic compiler for that more or less just works (in comparison to something crazy like C++), and that's it's been around for a long time, but why isn't there more of a push to add at least all of the supported Debian ISAs to the Rust compiler?
Re: Hard Rust requirements from May onward
#659One major point of heartburn with Rust is that it comparatively lacks the diversity of ISA targets that C broadly does. I know some of this is because C is both relatively simple to write a basic compiler for that more or less just works (in comparison to something crazy like C++), and that's it's been around for a long time, but why isn't there more of a push to add at least all of the supported Debian ISAs to the R…
Most people don't write a basic compiler for C either, "relatively simple" or no. Most people would rather add a new target to an existing compiler, which is much easier.
It's also "relatively easy" to add a new backend to Rust.
There's a policy document for Rust here: https://doc.rust-lang.org/rustc/target-tier-policy.html
There are a lot of things that can go wrong. You want to be able to test. Being able to test requires that someone has test hardware.
Re: Hard Rust requirements from May onward
#660Earlier quoted context omitted.
I find Rust much easier to write than C. Its types let me be reasonably sure I’ve written appropriate code before I even get to the point of running tests, and I don’t have to memorize the flow of the whole program to have that assurance. For instance, struct Feet(i32); struct Meters(i32); fn hover(altitude: Meters) { println!("At {} meters", altitude.0); } fn main() { let altitude1 = Meters(16); hover(altitude1); le…
All you're doing is passing an argument of the incorrect type to your function. The exact same thing fails to compile in C: ``` #include typedef struct { int value; } Feet; typedef struct { int value; } Meters; void hover(Meters altitude) { printf("At %i meters\n", altitude.value); } int main() { Meters altitude1 = {.value = 16}; hover(altitude1); Feet altitude2 = {.value = 16}; hover(altitude2); } ``` ``` error: pas…
[deleted]