Hard Rust requirements for APT from may next year

HardSun · 2025-11-02 01:58:23

Because ubuntu's coreutils being rewritten in rust is totally working out!

https://lists.debian.org/debian-devel/2 … 00285.html

Hi all,
I plan to introduce hard Rust dependencies and Rust code into
APT, no earlier than May 2026. This extends at first to the
Rust compiler and standard library, and the Sequoia ecosystem.
In particular, our code to parse .deb, .ar, .tar, and the
HTTP signature verification code would strongly benefit
from memory safe languages and a stronger approach to
unit testing.
If you maintain a port without a working Rust toolchain,
please ensure it has one within the next 6 months, or
sunset the port.
It's important for the project as whole to be able to
move forward and rely on modern tools and technologies
and not be held back by trying to shoehorn modern software
on retro computing devices.
Thank you for your understanding.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en

Last edited by HardSun (2025-11-02 02:05:35)

golinux · 2025-11-02 02:12:52

@HardSun . . . you are just such a ray of sunshine . . . NOT. I am so sick and tired of the "we need modern tools and technologies" bullshit. Nothing good comes of it. It has been all downhill for decades . . .

Would be nice if you shared some good news . . .

HardSun · 2025-11-02 02:46:28

Good news is hard to come by these days, but i will try next time.
Im sure Julian would tell you this is great news however!

Last edited by HardSun (2025-11-02 02:48:18)

Altoid · 2025-11-02 11:49:27

Hello:

debian developer wrote:

... and not be held back by trying to shoehorn modern software on retro computing devices.

Of course ... 8^°

--->

Tech *bros* have to make a living. 
Make ends meet, if you will.
Have you not been observing?
There are still many landfills to fill.

<---

Hard Sun wrote:

... would tell you this is great news ...

Yes, he would.

I take small confort in the fact that Civilisation (in general) has always had an incredibly over-abundant supply of [braindead / stupid / DHs / AHs]*.
That little snippet from the debian_dev only confirms it.

* choose one, a combination of two or even three. But a combination of four is not an option, lest depression set in.

Best,

A.

Last edited by Altoid (2025-11-02 11:50:27)

tux_99 · 2025-11-02 12:54:56

Julian Andres Klode wrote:

rely on modern tools and technologies

Because "modernity" is all that matters to some folks these days... regardless whether "modern" is actually better or worse.

blackhole · 2025-11-02 13:18:44

debian developer
ubuntu core developer

And there it is...

So guess who is really forcing in rust?

HardSun · 2025-11-02 22:36:48

blackhole wrote:

So guess who is really forcing in rust?

Oxidization of Linux == converting everything to MIT or BSD licenses.
The corpos want ownership of the plantation, and they can't have that with GPL, so it has to go.
They've got Ubuntu. Is Debian on the same path?

zapper · 2025-11-03 00:59:28

The only reason this could make sense is if they want to enable mediocre developers to make code that doesn't suck.

greenjeans · 2025-11-03 01:23:03

It's important for the project as whole to be able to
move forward and rely on modern tools and technologies
and not be held back by trying to shoehorn modern software
on retro computing devices.

Translation: "OMG WTF is this 'end-of-10' bullshit? You peasants need to buy new computers and throw that old shit away, we know what's best for you and what's best for you is to spend 1000's of dollars you can't afford every couple years to buy new shit as is the will of your overlords!".

stargate-sg1-cheyenne-mtn · 2025-11-03 03:44:38

reminded of this gentleman's functionable laptop:

https://imgur.com/gallery/functionable-wsDdXEN

or perhaps an old thread about old pc:

https://forum.tinycorelinux.net/index.php/topic,3216.0.html

also:

ewaste

blackhole · 2025-11-03 08:39:26

HardSun wrote:

Oxidization of Linux == converting everything to MIT or BSD licenses.
The corpos want ownership of the plantation, and they can't have that with GPL, so it has to go.
They've got Ubuntu. Is Debian on the same path?

Actually they can and they have. You should refer to the licences of the Linux kernel and systemd in particilar, both corporate funded and managed projects.

By contrast, look at projects like OpenBSD, NetBSD and FreeBSD where there are donations, but zero or far less corporate reps steering things. All of those are permissive licenced. The main difference is that when e.g. Apple wanted to use code from any of those and include it in their OS, they just did that - they had no need to implant their own people, pay for things and take control - as the likes of MS, facebook, IBM, Microsoft, etc have done with the Linux Foundation.

Debian is the base system for Ubuntu, shares many of the same "developers" and maintainers, culture, etc.

Last edited by blackhole (2025-11-03 08:41:59)

exponentialmatrix · 2025-11-04 20:39:01

if rust apt excludes certain architecture, rust in the kernel doesn't exclude those same architectures? What's the difference?

steve_v · Yesterday 04:28:15

Sweet sod all. The only way rust "excludes" anything is where there is no compiler for a particular arch... Which is to say architectures that aren't supported by current kernels or current Debian anyway.
If you want to run a current GNU/Linux distro on 25 year old 32bit hardware you're SOL, rust or no rust. Did we all moan so loudly about Linux not supporting 16bit? Or drivers for OAK VLB video cards being dropped? Or when we needed more than 4MB RAM and our 386 wasn't fast enough to run GNOME 1.1?

Does anyone here actually run GNU/Linux on a DEC Alpha or an Amiga? That covers most of the "old shit" that won't be able to compile rust code (at least not with LLVM)... Or are we just complaining for the sake of complaining?

Beyond the inevitable deprecation of ancient hardware, what language a program is written in means nothing to the end user of a binary distro at all. It's all machine code by the time you get it.

Compiler licences (i.e. clang/LLVM/rustc not being GPL) have nothing to do with the language itself. Language spec licences don't transfer to programs written in that language either.

If you never work on or even compile the code in question (neatly covering most of the chronic "new == bad" "young == stupid" "we're all doomed" whiners and conspiracy theorists around here), the language or compiler used is irrelevant... So long as the implementation isn't a mess.

IOW, Ubuntu's coreutils replacement didn't go sideways because it's a rewrite in rust, it went sideways because it's a rewrite that didn't get tested properly.
If APT with rust is maintained to the same code-quality standards as APT without rust has been, the only thing that changes for users is maybe some different libraries being installed. Any issues pertaining to language or compiler toolchains is for the developers and packagers to deal with, and they're mostly the same people wanting this to begin with.

Last edited by steve_v (Yesterday 04:45:30)

HardSun · Yesterday 06:05:17

steve_v wrote:

Does anyone here actually run GNU/Linux on a DEC Alpha or an Amiga? That covers most of the "old shit" that won't be able to compile rust code (at least not with LLVM)... Or are we just complaining for the sake of complaining?
Beyond the inevitable deprecation of ancient hardware, what language a program is written in means nothing to the end user of a binary distro at all. It's all machine code by the time you get it.

What in your opinion does Julian mean by retro devices?
How far back do we go, how future proof is my computer 5 years from now?
Is it holding back progress to keep using my 15 year old toshiba laptop even though it still works?
The way it reads to me is that rust may change the type of computer debian can run on in the not too distant future in favor of newer spec computers and iot stuff, which kind of falls in line with the AI hype and how microsoft treats its customers.
But yeah sod it all if that is the way debian is going, not much I can do except try to run something else like netbsd.

It's important for the project as whole to be able to
move forward and rely on modern tools and technologies
and not be held back by trying to shoehorn modern software
on retro computing devices.

Maybe debian wants to become like fedora and archlinux, maybe they should just pivot toward the bleeding edge and be done with stability.

Last edited by HardSun (Yesterday 06:14:33)

EDX-0 · Yesterday 07:27:52

man, i gotta agree with steve_v, more than half of the forum seems to be people who have never coded and whose hobby is to complain about anything and everything with the utmost learned helplessness that there is and there will never be anything they can do other than give up, really something refreshing and pleasant to read every time.

steve_v · Yesterday 08:11:00

HardSun wrote:

What in your opinion does Julian mean by retro devices?

Hardware only supported by ports which do not have a working rust toolchain, obviously. That's right there in the quote from your OP, no "opinion" needed.
If you can't be bothered to check out which ports those are and which architectures they target, why would I bother to opine on the matter?

HardSun wrote:

how future proof is my computer 5 years from now?

Crystal ball is out on loan.

HardSun wrote:

Is it holding back progress to keep using my 15 year old toshiba laptop even though it still works?

Is your 15 year old laptop reliant on a Debian port that doesn't have a working rust toolchain?

HardSun wrote:

The way it reads to me is that rust may change the type of computer debian can run on in the not too distant future

Read harder. Rust is just a programming language. Rust has sweet bugger all to do with what Debian does or does not run on.

The "type of computer" Debian can run on is a function of the "type of computer" Debian can be built on. That means having a working compiler toolchain for every required component and language involved, which can produce code that will run on the target architecture.
Adding rust to APT simply moves the rust toolchain from "recommended" (i.e. needed for some optional software) to "required" (needed for core Debian utilities) - alongside C, C++, and a whole bunch of other stuff.

HardSun wrote:

in favor of newer spec computers and iot stuff, which kind of falls in line with the AI hype and how microsoft treats its customers.

Yes yes, Big Bad Evil Tech, yada yada. What does Microsoft, AI, or IoT have to do with using rust for parts of APT?

HardSun wrote:

pivot toward the bleeding edge and be done with stability

"Stability" in the sense Debian practices it is about code maturity and testing. It has nothing whatsoever to do with what languages are used in that code.
If Debian releases untested unstabilised versions of APT to the stable channel, that's breaking with stability. If they rewrite it entirely in brainfuck, then put it through the full testing and stabilisation cycle before release... That's pretty annoying, but still "stable".

EDX-0 wrote:

more than half of the forum seems to be people who have never coded and whose hobby is to complain about anything and everything with the utmost learned helplessness

This whole place is a rage-against-the-machine echo-chamber for the terminally stubborn and wilfully uninformed... Which is why I rarely post here and usually get into a fight when I do.
This thread is a fine example: Ragebait OP, bunch of whinging about how bad "modern" software is and how stupid "modern" developers are, tangent rants about evil corporations and world domination... And zero technical analysis.

Now, again, million dollar question: Are any of you who are complaining actually running an affected port?

Last edited by steve_v (Yesterday 08:20:35)

HardSun · Yesterday 09:11:40

@steve
Fair enough on the ports understanding, to me it just seemed vague to point out retro devices.
Im just a lay person using an old computer trying to understand whats going on, I will try to stay better informed.
Thanks for sharing your knowledge and my apologies if I come across as a whinging stubborn ragebait complainer.

steve_v · Yesterday 09:44:27

HardSun wrote:

it just seemed vague to point out retro devices.

That's just a bit of pre-emptive defence from the knee-jerk rust-hater horde (and the 3 people who might actually loose support).
The real message and the answer to "who is affected / what do I need to do" is the preceding paragraph, and it's for port maintainers rather than end-users, because if it's done sensibly end-users probably won't even notice.

HardSun wrote:

apologies if I come across as a whinging stubborn ragebait complainer.

Less your OP (though the sarcasm WRT coreutils does make it fairly bait-ey), more the oh-so-predictable "them crooked vultures is out to get us again, woe is us, stupid nasty vultures" dogpile that followed.

Had anyone thought to investigate what "a port without a working Rust toolchain" actually means before popping off, we could have had some interesting discourse here...
But hey, nevermind, lets just rant at each other about the Evil of Man and demise of civilised society some more.

Last edited by steve_v (Yesterday 09:46:28)

chris2be8 · Yesterday 17:54:33

The best way to introduce rust would be to wait until gcc rust support is ready for prime time. Then all that would be needed would be the gcc rust front end.

blackhole · Yesterday 18:13:33

Be aware: https://lists.debian.org/debian-devel/2 … 00288.html

Rust is already a hard requirement for all except those obscure architectures that are referenced

Rust is a fad and it's adoption has slowed, but "memory safe" is now a thing, regardless of what happens with rust in the future.

zapper · Yesterday 20:07:10

@steve_v I don't know about you, but I don't want coding newbies developing my software.

That's what rust enables to happen.

Like javascript and java, they are a bloated mess.

Of course you can say that about python I suppose too.

This being said, I prefer my software not being written by newbies especially system components.

Also, some code is battle tested so to speak and doesn't need to be replaced by some stupid rust rewrite.

PS, I haven't seen you on here for a while, I thought you were gone for good.

steve_v · Yesterday 20:56:28

zapper wrote:

newbies developing my software.
That's what rust enables to happen.

This kind of unsubstantiated, over-generalised speculation is exactly why

zapper wrote:

I haven't seen you on here for a while

Do you code in rust? How about java? What have you written in python?
Do you personally know these "newbies" you claim are "enabled" by rust? Do you have the expertise to critique their code, or are you just talking out your arse on subjects you have no experience with (again)?

Last edited by steve_v (Yesterday 20:58:52)

zapper · Yesterday 21:22:44

@steve_v
Do you code in rust? How about java? What have you written in python?
Do you personally know these "newbies" you claim are "enabled" by rust? Do you have the expertise to critique their code, or are you just talking out your arse on subjects you have no experience with (again)?

Does that really matter?

Most people in the coding world use C and the best developed most secure OS is OpenBSD and most of that is in C.

So if they don't feel the need to use Rust, why should anyone else unless they are incompetent.

Also btw, java and javascript are known vectors and both are bloated. So I assume Rust has hidden problems similar that haven't been found yet. Not to mention they haven't stabilized the programming language yet. What works now, might not work later.

Rust is also very bloated another words.

Just in case that wasn't clear. and I meant vectors of weakness for malware to creep in

Last edited by zapper (Yesterday 21:24:18)

pcalvert · Yesterday 22:11:26

zapper wrote:

Most people in the coding world use C and the best developed most secure OS is OpenBSD and most of that is in C.

A university instructor once told me (I'm paraphrasing here) that, although C is very powerful, it also gives you enough rope to hang yourself. He was teaching a course on programming for Apple Macintosh computers, and the language he recommended for that purpose was Pascal. Some students, though, insisted on using C, and that was permitted. However, the students using C tended to have a lot more problems debugging their programs than the ones using Pascal.

steve_v · Yesterday 23:39:02

Does that really matter?

Only if you wish to be taken seriously.

Most people in the coding world use C

Bullshit.

the best developed most secure OS is OpenBSD

Citation needed.

So if they don't feel the need to use Rust, why should anyone else unless they are incompetent.

Speculation and baseless accusations. If you want to claim incompetence, provide example "bad" code.

java and javascript are known vectors

Citation needed.

both are bloated.

Code examples (demonstrating the language itself is at fault) or GTFO.

I assume

That's all you do... Besides talk smack about things you clearly don't understand.

There's an old adage, goes something like this: "Those who can, do. Those who can't, talk."
Which are you?

pcalvert wrote:

the language he recommended for that purpose was Pascal.

I started with pascal (Borland turbo pascal on DOS), and while I have forgotten much of what I once knew, I have nothing bad to say about the language. Pascal was created, at least in part, to teach good programming patterns. It did and still does (feat freepascal & Lazarus).

Last edited by steve_v (Today 00:01:32)

The officially official Devuan Forum!

#1 2025-11-02 01:58:23

Hard Rust requirements for APT from may next year

#2 2025-11-02 02:12:52

Re: Hard Rust requirements for APT from may next year

#3 2025-11-02 02:46:28

Re: Hard Rust requirements for APT from may next year

#4 2025-11-02 11:49:27

Re: Hard Rust requirements for APT from may next year

#5 2025-11-02 12:54:56

Re: Hard Rust requirements for APT from may next year

#6 2025-11-02 13:18:44

Re: Hard Rust requirements for APT from may next year

#7 2025-11-02 22:36:48

Re: Hard Rust requirements for APT from may next year

#8 2025-11-03 00:59:28

Re: Hard Rust requirements for APT from may next year

#9 2025-11-03 01:23:03

Re: Hard Rust requirements for APT from may next year

#10 2025-11-03 03:44:38

Re: Hard Rust requirements for APT from may next year

#11 2025-11-03 08:39:26

Re: Hard Rust requirements for APT from may next year

#12 2025-11-04 20:39:01

Re: Hard Rust requirements for APT from may next year

#13 Yesterday 04:28:15

Re: Hard Rust requirements for APT from may next year

#14 Yesterday 06:05:17

Re: Hard Rust requirements for APT from may next year

#15 Yesterday 07:27:52

Re: Hard Rust requirements for APT from may next year

#16 Yesterday 08:11:00

Re: Hard Rust requirements for APT from may next year

#17 Yesterday 09:11:40

Re: Hard Rust requirements for APT from may next year

#18 Yesterday 09:44:27

Re: Hard Rust requirements for APT from may next year

#19 Yesterday 17:54:33

Re: Hard Rust requirements for APT from may next year

#20 Yesterday 18:13:33

Re: Hard Rust requirements for APT from may next year

#21 Yesterday 20:07:10

Re: Hard Rust requirements for APT from may next year

#22 Yesterday 20:56:28

Re: Hard Rust requirements for APT from may next year

#23 Yesterday 21:22:44

Re: Hard Rust requirements for APT from may next year

#24 Yesterday 22:11:26

Re: Hard Rust requirements for APT from may next year

#25 Yesterday 23:39:02

Re: Hard Rust requirements for APT from may next year

Board footer