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

301–310 of 797 posts

Re: Hard Rust requirements from May onward

#301

Post by wk_end »

thesuperbigfrog wrote: post #138
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?

Who is still using these machines? Genuine question, not trolling. It looks like the last machines of each architecture were released: Alpha in 2007 HP-PA in 2008 m68k in pre-2000 though derivatives are used in embedded systems sh4 in 1998 (though possible usage via "J2 core" using expired patents) This means that most are nearly 20 years old or older. Rust target triples exist for: m68k: https://doc.rust-lang.org/ni…

There’s hobbyists using m68k Macs, Amigas, and Atari STs. Definitely a small niche, and those running Linux on those machines more so.

Re: Hard Rust requirements from May onward

#302

Post by j16sdiz »

rayiner wrote: post #285
j16sdiz wrote: post #279

Never tried to port LLVM. Is 6 months a reasonable timeframe to bring LLVM to a new architecture to production quality?

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

Re: Hard Rust requirements from May onward

#303

Post by illuminator83 »

01HNNWZ0MV43FF wrote: post #263
krater23 wrote: post #235

Earlier quoted context omitted.

Memory safety is mostly a issue of the past. Clearly, there are new code bases with memory issue too. But we have tools to prevent that. The new security issues are supply chain attacks. And Cargo is the way to have exactly this.

What part of C package management defends against supply chain attacks? Does it audit third-party code for you?

I think it's mostly the fact that C dependencies are much rarer and much harder to add and maintain.

The average C project has at most a handful of other C dependencies. The average Rust, Go or NodeJS project? A couple hundred.

Ironically, because dependency management is so easy in modern languages, people started adding a lot of dependencies everywhere. Need a leftpad? Just add one line in some yaml file or an "Alt-Enter" in an IDE. Done.

In C? That is a lot more work. If you do that, you do it for advanced for stuff you absolutely need for your project. Because it is not easy. In all likelihood you write that stuff yourself.

Re: Hard Rust requirements from May onward

#304

Post by tacker2000 »

pezezin wrote: post #220
kortilla wrote: post #216

Earlier quoted context omitted.

Think about any time a computer is used in something designed to last 30+ years. Cars, airplanes, construction equipment, etc.

I am pretty sure that those machines are not running Debian.

Why not? How do you know that? Debian is used pretty widely

Re: Hard Rust requirements from May onward

#305

Post by krater23 »

amelius wrote: post #171

Can we please also have the hard requirement that code should run without warnings under Valgrind? Because that saves a lot of headaches down the line.

Would be good for memory safety and wouldn't need a rewrite of all software in a hyped language. No, we shouldn't do that ;)

Re: Hard Rust requirements from May onward

#306

Post by stackskipton »

3eb7988a1663 wrote: post #209
thesuperbigfrog wrote: post #138

Earlier quoted context omitted.

Who is still using these machines? Genuine question, not trolling. It looks like the last machines of each architecture were released: Alpha in 2007 HP-PA in 2008 m68k in pre-2000 though derivatives are used in embedded systems sh4 in 1998 (though possible usage via "J2 core" using expired patents) This means that most are nearly 20 years old or older. Rust target triples exist for: m68k: https://doc.rust-lang.org/ni…

Debian just cut i386, Wikipedia says the i386 was discontinued in 2007. These systems are all of the same vintage, so it does not seem a huge leap to be culled from the support list. [0] https://en.wikipedia.org/wiki/I386

i386 (32 bit) only processors we discontinued but 64bit processors can operate in 32bit mode so toolchain was still widely available and there was still demand for i386 OS that would run on modern hardware in i386 mode for some ancient software.

Re: Hard Rust requirements from May onward

#309

Post by Avamander »

s20n wrote: post #187

> This extends at first to the Rust compiler and standard library, and the Sequoia ecosystem. By Sequoia, are they talking about replacing GnuPG with https://sequoia-pgp.org/ for signature verification? I really hope they don't replace the audited and battle-tested GnuPG parts with some new-fangled project like that just because it is written in "memory-safe" rust.

When was GnuPG audited and by whom?

Re: Hard Rust requirements from May onward

#310

Post by Xylakant »

dvtkrlbs wrote: post #250
Antibabelic wrote: post #26

Earlier quoted context omitted.

Ada and SPARK fulfilled the promise of a safe systems language decades ago without making most of the mistakes Rust does. Rust has its strong sides, sure, but it's far from the only shop in town. The GCC happens to include an Ada compiler as well.

The problem is they forgot about making the language approachable so it lives in its bubble for safety criticial usage (which Rust kinda starting to eat its lunch from with the certified Rust fork)

If you’re referring to Ferrocene with the certified Rust fork, then I’d like to make the minor correction that we don’t consider Ferrocene a true fork, but rather a downstream distribution of the Rust projects compiler. There are very little changes to the compiler itself. Most relevant changes are documentation, build process and different test coverage - we do test architectures that upstream does not.
Post reply on HN