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

131–140 of 797 posts

Re: Hard Rust requirements from May onward

#131

Post by mouse_ »

0x000xca0xfe wrote: post #110
cmm11 wrote: post #54

If anyone has a problem with the language used in the email, I would remind you that this is the same person who is maintainer for debian's keepassxc packages. Here's a thread of them insulting upstream developers & users of the Debian packages. https://github.com/keepassxreboot/keepassxc/issues/10725

What a horrible mindset. I'll never understand this "security" argument. It is our responsibility to our users to provide them the most secure option possible as the default. Removing features is not the most secure option possible. Go all the way then and remove everything. Only when your computer cannot do anything it will be 100% secure.

You misunderstand, see; these people are corporate saboteurs.

Re: Hard Rust requirements from May onward

#132

Post by fanf2 »

einpoklum wrote: post #40

That seems like a bad idea to me: Dependencies will be added, for very basic system utilities, on (parts of) a software ecosystem which is still a "moving target", not standardized, and IIANM itself has further dependencies. I wonder whether platform compatibility won't be jeopardized, either. I would be worried if even C++ dependencies were added for basic system utilities, let alone something like Rust. Now, grante…

Before apt, the main user interface for dpkg was dselect, which was written in C++

Re: Hard Rust requirements from May onward

#133

Post by jrmg »

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!] are not!

I am emotionally sad to see them fall by the wayside (and weirdly motivated to dig out a 68k Amiga or ‘very old Macintosh’ and try running Trixie…) but, even from a community standpoint, I find it hard to understand where and how these ports are actually used.

Re: Hard Rust requirements from May onward

#134

Post by dicytea »

noosphr wrote: post #34
Antibabelic wrote: post #29

Earlier quoted context omitted.

Many programmers feel the same way about Lispers. It's best to set aside your gut feelings about the community and think primarily about the technical and organizational merits and disadvantages of the technology.

Yes, but we're not making a push to make everything a bilingual c/lisp code base. Rust people for some reason are.

One of the most iconic lisp saying is literally about how every other languages are supposedly inferior to lisp, so I don't think it's a particularly good example here.

Re: Hard Rust requirements from May onward

#135

Post by forgetfulness »

viraptor wrote: post #121
troupo wrote: post #21

Earlier quoted context omitted.

> Wonder what this means for those architectures then? They will be rebranded as "retro computing devices"

Most don't need to be rebranded. Alpha and hppa are retro computing and haven't been available to buy for 18 and 15 years respectively. Sh4 died this year. Only m68k is still holding on, but is a rounding error in the number is users.

Aren’t m68k computers only a few models from the 1990s and 1980s, and some more recent hobby projects? That’s squarely in the retro computing enthusiasts category.

I’m not in the Debian world, but those do seem to me like the types of systems that could use their own specialized distros rather than being a burden to the mass market ones. It’s not as if you could run a stock configuration of any desktop environment on them anyway.

Re: Hard Rust requirements from May onward

#136

Post by cmm11 »

0x000xca0xfe wrote: post #110
cmm11 wrote: post #54

If anyone has a problem with the language used in the email, I would remind you that this is the same person who is maintainer for debian's keepassxc packages. Here's a thread of them insulting upstream developers & users of the Debian packages. https://github.com/keepassxreboot/keepassxc/issues/10725

What a horrible mindset. I'll never understand this "security" argument. It is our responsibility to our users to provide them the most secure option possible as the default. Removing features is not the most secure option possible. Go all the way then and remove everything. Only when your computer cannot do anything it will be 100% secure.

Just annoys me that he calls features "crap" just because he likely doesn't use them personally and ends that post with a random sentence claiming such a version "increases the risk of drive-by attacks" with zero evidence. The developer explains the features aren't plugins and aren't even enabled by default. Arrogance from maintainers like this from within Debian is what will hurt it far more than any external entity.

Re: Hard Rust requirements from May onward

#137

Post by MangoToupe »

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

> but as long as the real money is made in c it is not ready

People selling slop does not imply much about anything other than the people making the slop

Re: Hard Rust requirements from May onward

#138

Post by thesuperbigfrog »

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/nightly/rustc/platform-support/m68... and https://doc.rust-lang.org/nightly/rustc/platform-support/m68... both at Tier 3.

(Did not find target triples for the others.)

If you are using these machines, what are you using them for? (Again, genuinely curious)

Re: Hard Rust requirements from May onward

#139

Post by nicce »

0x000xca0xfe wrote: post #110
cmm11 wrote: post #54

If anyone has a problem with the language used in the email, I would remind you that this is the same person who is maintainer for debian's keepassxc packages. Here's a thread of them insulting upstream developers & users of the Debian packages. https://github.com/keepassxreboot/keepassxc/issues/10725

What a horrible mindset. I'll never understand this "security" argument. It is our responsibility to our users to provide them the most secure option possible as the default. Removing features is not the most secure option possible. Go all the way then and remove everything. Only when your computer cannot do anything it will be 100% secure.

Some people don't have actual understanding of the meaning of security.

Security is there to keep the features usable without interruptions or risks.

E.g. plugging the computer off the network is not about security if the service needs to be accessible.

Post reply on HN