Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hard Rust requirements from May onward

lists.debian.org

Post reply on HN
Print view View original

441–450 of 797 posts

Re: Hard Rust requirements from May onward

#441

Post by TuxSH »

larusso wrote: post #426

I really like to write programs in rust. But my stance has changed a bit over the years ever since other languages caught up a bit. On top of that I’m very skeptical if the rewrite of an ancient tool brings more less security. I don’t know the apt source code or how it actually works behind the cli interface so I leave this judgement to the pros. But there seems to be a very strong move to rewrite all core systems in…

> 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.

Re: Hard Rust requirements from May onward

#442

Post by cbmuser »

jrmg wrote: post #133
justinclift wrote: post #6

One 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…

They’re not going to fall to the wayside, we’re eventually getting Rust support on these.

It’s just a bit annoying that Rust proponents are being so pushy in some cases as if Rust was the solution to everything.

Re: Hard Rust requirements from May onward

#443

Post by cwzwarich »

woodruffw wrote: post #371
cwzwarich wrote: post #278

Earlier quoted context omitted.

The Rust specification you link is performative and only intended to satisfy requirements of certification processes. No one is actually using it to implement the language, as far as I am aware. There is other work on specifying Rust (e.g. the Unsafe Code Guidelines Working Group), but nothing approaching a real spec for the whole language. Honestly, it is probably impossible at this point; Rust has many layers of im…

“There’s a standard, but it’s performative” is a different argument than the top level one. But even if we accept that, it doesn’t seem like a good comparative argument: anybody who has written a nontrivial amount of C or C++ has dealt with compiler-defined behavior or compiler language extensions. These would suggest that the C and C++ standards are “performative” in the same sense, but repeated claims about the vir…

The original purpose of the C standard was to solve the problems created by the diversity of increasingly divergent implementations of C. They studied existing behavior across systems, proposed new language constructs, and it was generally a success (look at the proliferation of C in the 90s across many different systems and architectures).

The actual informal semantics in the standard and its successors is written in an axiomatic (as opposed to operational or denotational) style, and is subject to the usual problem of axiomatic semantics: one rule you forgot to read can completely change the meaning of the other rules you did read. There are a number of areas known to be ill-specified in the standard, with the worst probably being the implications of the typed memory model. There have since been formalized semantics of C, which are generally less general than the informal version in the standard and make some additional assumptions.

C++ tried to follow the same model, but C++ is orders of magnitude more complex than C and thus the standard is overall less well specified than the C++ standard (e.g. there is still no normative list of all the undefined behavior in C++). It is likely practically impossible to write a formal specification for C++. Still, essentially all of the work on memory models for low-level programming languages originates in the context of C++ (and then ported back to C and Rust).

Re: Hard Rust requirements from May onward

#445

Post by cbmuser »

curt15 wrote: post #130
zozbot234 wrote: post #42

Earlier quoted context omitted.

m68k has a LLVM port already, so Rust can be implemented for that platform.[0] It would be nice to have LLVM backends for alpha, hppa and sh4 - these older architectures tend to be quite simple so a working LLVM has plenty of value as a reference and for educational use. (LLVM even used to have an in-tree DEC Alpha backend, though that was back in 2011 and not relevant to any version of Rust.) [0] Looks like there is…

Shouldn't the codegen_gcc project[1] theoretically allow Rust to target backends that only GCC supports? [1] https://github.com/rust-lang/rustc_codegen_gcc

Yes, that is being worked on.

Re: Hard Rust requirements from May onward

#446

Post by jeroenhd »

j16sdiz wrote: post #302
rayiner wrote: post #285

Earlier quoted context omitted.

Can you use Rust without LLVM by using the Cranelift backend?

I meant, that email literally ask the fellow developer to either finish the Rust port or sunset the debian port in 6 months. I am asking if the former option is a practical one

I believe m68k already has a working Rust compiler of sorts, though it's not part of the default Rust chain. I think shaping that fork into something that will let it run and compile like normal is feasible.

For other architectures currently unsupported by Rust, I doubt it'll happen. The CPU architectures themselves are long dead and often only used for industrial applications, so the probability of hobbyists getting their hands on them is pretty slim.

People still using these old architectures for anything but enthusiast hacking will probably not be using Debian Trixie, and if they do, they can probably find a workaround. It's not like the .deb format itself is changing, so old versions of apt and dpkg will keep working for quite a while.

Re: Hard Rust requirements from May onward

#447

Post by rcxdude »

no_wizard wrote: post #431
fweimer wrote: post #422

Earlier quoted context omitted.

The Debian base system is much, much smaller. I'm surprised that people consider Python to be part of it. However, APT depends on Perl and the C++ run-time library, so those two languages have been part of the base system for a very long time.

I wonder how much of that Perl support is simply regex and other parsing utilities. I’ve notice a lot of that in base OS systems Its a curiosity more than anything though

A substantial fraction of apt is written in perl. It's actually still pretty core to debian, even if applications are using it less.

Re: Hard Rust requirements from May onward

#448

Post by MerrimanInd »

larusso wrote: post #426

I really like to write programs in rust. But my stance has changed a bit over the years ever since other languages caught up a bit. On top of that I’m very skeptical if the rewrite of an ancient tool brings more less security. I don’t know the apt source code or how it actually works behind the cli interface so I leave this judgement to the pros. But there seems to be a very strong move to rewrite all core systems in…

I've heard two arguments for these rewrites that don't always come up in these discussions. There are fair counterpoints to both of these but I think they add valuable dimensions to the conversation, or perhaps may explain why a rewrite may not seem justified without them.

* It's becoming increasingly difficult to find new contributors who want to work with very old code bases in languages like C or C++. Some open source projects have said they rewrote to Rust just to attract new devs.

* Reliability can be proven through years in use but security is less of a direct correlation. Reliability is a statistical distribution centered around the 'happy path' of expected use and the more times your software is used the more robust it will become or just be proven to be. But security issues are almost by definition the edgiest edge cases and aren't pruned by normal use but by direct attacks and pen testing. It's much harder to say that old software has been attacked in every possible way than that it's been used in every possible way. The consequences of CVEs may also be much higher than edge case reliability bugs, making the justification for proactive security hardening much stronger.

Re: Hard Rust requirements from May onward

#449

Post by einpoklum »

rs186 wrote: post #198
Surac wrote: post #94

I think this is the wrong way to promote rust. For me rust is just a hype. I know nobody that programms or even thinks about rust. I’m from the embedded world an there c is still king. I understand that some will see rust as a good alternative, but as long as the real money is made in c it is not ready

> I know nobody that programms or even thinks about rust. That's you. At companies like Microsoft and Google, plenty of people think about and discuss Rust, with some products/features already using Rust.

Well, at Microsoft, plenty of people have thought about and discussed C#, with some products/features using it. Not that it's gone away, but it has not won the hearts and minds of the general (software-developing) public.

Re: Hard Rust requirements from May onward

#450

Post by throwaway7356 »

uecker wrote: post #289
mirashii wrote: post #18

Earlier quoted context omitted.

This whole it used to be different thing is looking back with rose tinted glasses. It’s always been the case that project maintainers were able to make choices that the community didn’t necessarily agree with, corporate backed contributors or not, and it’s still a possibility to fork and try to prove out that the other stance is better. Nobody is being forced out of the community, you can fork and not adopt the chang…

The point of freedom in software is certainly that I can create my own fork. And individual projects a maintainer can certainly do what he wants. But it is still worrying if in community projects such as Debian when decisions that come with a cost to some part of the community are pushed through without full consensus. It would be certainly not the first time. systemd was similar and for similar reasons (commercial i…

> systemd was similar and for similar reasons (commercial interests by some key stakeholders)

False claims don't really make the claims about the evils of Rust more believable.

Post reply on HN