Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- It makes me uncomfortable that this mandate is coming from a Canonical employee. After all, if this switch was a good idea on merit alone, it would happen organically without requiring this kind of combative communication.
What's the long-term play for Canonical here?
by parliament32 - The long term play is to drive out community participation and bring in corporate control in the apt/Debian ecosystem.by sprash
- "What's the long-term play for Canonical here?"
Presumably it's rewriting critical parsing code in APT to a memory-safe language.
by simonw - It's hard to imagine their is some malicious financial incentive to choosing a different language to write the package manager with...
The obvious potential motivations are things like making a more reliable product, or making their employees more productive by giving them access to modern tools... I guess I could imagine preparing for some sort of compliance/legal/regulatory battle where it's important to move towards memory safe tooling but even there I rather imagine that microsoft is better placed to say that they are and any move on canonical's part would be defensive.
by gpm - Apt has just 3 listed maintainers, and judging by the git history this guy does 90% of the work. Him making the decision _is_ it happening organically.
Open source fundamentally is a do-ocracy (it's in literally all of the licenses). Those who do, decide; and more and more often those who do are just one or two people for a tool used by millions.
by Denvercoder9 - The language is incredibly frank, and I agree with it completely. The retro-computing hobby doesn't need the ability to run contemporary operating systems.
It's insane that x86 Debian is still compiling all software targeting Pentium Pro (from 1995!).
x64 Debian is a bit more modern, and you must splurge for a CPU from 2005 (Prescott) to get the plethora of features it requires
by nikanj - Wow, those are exactly the same targets I use for releasing x86 and x64 (Windows) builds, but even I think it's a little over the top for Debian to support Pentium Pro.by versteegen
- >retro-computing hobby doesn't need the ability to run contemporary operating systems
why not? I still want to run modern software on older machines for security and feature reasons
by Palomides - > targeting Pentium Pro (from 1995!).
BTW, today is Pentium Pro's 30 years anniversary.
by egorfine - If I was a blackhat, I'd surely value all pre-IntelME / AMD PSP *retro-computing* hardware that is still capable of running more or less modern software without a built-in hardware backdoor higher than its weight in gold.by wartywhoa23
- I'll first say that 32-bit CPUs, including x86-based ones, are not retro computing. They still carry the load of all sorts of important computing systems, today. They are still being produced (IIANM, also by Intel and AMD). Sure, with much more limited use cases, and it's definitely not the mainstream, but it's there. Not a hobby and not for a 'retro' experience.
But you are also completely ignoring limited-capabilities hardware, like embedded systems and micro-controllers. That includes newer offerings from ST Microelectronics, Espressif, Microchip Technology etc. (and even renewed 'oldies' like eZ80's which are compatible with Zilog's 8-bit Z80 from the 1970s - still used in products sold to consumers today). The larger ones are quite capable pieces of hardware, and I would not be surprised if some of them use Debian-based OS distributions.
by einpoklum - Is it just the "retro-computing hobby"? There could still be businesses who might need support for old machines, especially in developing countries. I don't know the actual situation though, I'm open to the idea that my suggestion is insane.by Antibabelic
- > It's insane that x86 Debian is still compiling all software targeting Pentium Pro (from 1995!).
Note that Debian no longer supports x86 as of Debian 13.
by ndiddy - > It's insane that x86 Debian is still compiling all software targeting Pentium Pro (from 1995!).
Debian 13 raised the x86 requirement to Pentium 4 because LLVM required SSE2 and Rust required LLVM.
The target before was not Pentium Pro in my understanding. It was Pentium Pro equivalent embedded CPUs. Servers and desktops since 2005 could use x86-64 Debian.
by pseudalopex - This is the same maintainer who broke KeePass on Debian and then flipped off everyone in the thread. Someone needs to pull him aside and let him know the world does not revolve around him and the problems he chooses to manufacture to justify his paycheck.
https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
- Interesting how a person's opinion can change: https://news.ycombinator.com/item?id=27594688by teh64
- I would much rather work with someone that other people find abrasive but who communicates much like myself and is clearly open-minded, than the opposite.by zahlman
- I assume it was a management decision to adopt Rust in APT similar to the decision to switch to the Rust version of coreutils.by cbmuser
- If only more people were willing to let their opinions be changed over time like that, rather than clinging onto them.by jeroenhd
- I'm happy for all developers programming in their favorite programming languages. Programming for over 30 years I have seen entire ecosystems come and go.
What I don't get is the burning need for Rust developers to insult others. Kind of the same vibes that we get from systemd folks and LP. Does it mean they have psychological issues and deep down in their heart they know they need to compensate?
I remember C vs Pascal flame back in the day but that wasn't serious. Like, at all. C/C++ developers today don't have any need to prove anything to anyone. It would be weird for a C developer to walk around and insult Rust devs, but the opposite is prevalent somehow.
by egorfine - The general problem is that there’s a lot of activists online nowadays. I used to call myself an activist, but now it’s a dirty word which I associate with obsessive behaviour, harassment, cancellation attempts and being generally obnoxious with the purpose of achieving some goal.
I think it’s a combination of religion decreasing in importance and social media driving people mildly nuts. Many undertakings are collecting “true believers”, turning into their religion and social media is how they evangelize.
Rust is a pretty mild case, but it still attracts missionaries.
So, the people are different, Western society’s different and social media’s giving everyone a voice while bringing out the worst in them.
by blub - Rust developers have corporate backing and therefore feel superior even though the language is an ugly OCaml knockoff.by bgwalter
- > What I don't get is the burning need for Rust developers to insult others
... where?
by thiht - Who is insulting others and where?by jamincan
- Wouldn't it make sense to wait for (or support) one of the rust-for-GCC ports to become viable? As far as I understand, rust in the kernel won't become mandatory either until it's supported by GCC, and as a boon, with multiple implementations you can be more certain that the language won't move as fast and break things anymore. There's already upstream rust support in GCC, so I don't reckon it's that far off from being usable, at least for projects choosing to target it specifically.
Furthermore, if these architectures are removed from further debian updates now, is there any indication that, once there's a rust toolchain supporting them, getting them back into modern debian wouldn't be a bureaucratic nightmare?
by mid-kid - There's already upstream rust support in GCC, so I don't reckon it's that far off from being usable, at least for projects choosing to target it specifically.
The GCCRS project can't even build libcore right now, let alone libstd. In addition, it is currently targeting Rust 1.50's feature set, with some additions that the Linux kernel needs. I don't see it being a useful general purpose compiler for years.
What's more likely is that rustc_codegen_gcc, which I believe can currently build libcore and libstd, will be stabilised first.
by Measter - Ports are not part of Debian and particularly don't release with Debian, they only ship unstable.by julian-klode
- non of the listed architectures have official Debian support anymore
i.e. they are only still around because they haven't caused any major issues and someone bothered to fix them up from time to time on their own free time
so yes, you probably won't get them back in once they are out as long as a company doesn't shoulder the (work time) bill for it (and with it I mean long term maintenance more then the cost of getting them in)
but for the same reason they have little to no relevance when it comes to any future changes which might happen to get them kicked out (as long as no company steps up and shoulders the (work time) bill for keeping them maintained
by dathinab - > Furthermore, if these architectures are removed from further debian updates now, is there any indication that, once there's a rust toolchain supporting them, getting them back into modern debian wouldn't be a bureaucratic nightmare?
These architectures aren't being removed from Debian proper now, they already were removed more than a decade ago. This does not change anything about their status nor their ability to get back into Debian proper, which had already practically vanished.
by Denvercoder9 - 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 rust. My issue with that is the fact that these tools don’t even invent anything new. Or change / improve the status co. I understand that it’s hard to introduce a new system without breaking other stuff. But our systems are still based on decisions from the telegraph age. Layers on top of layers on top of layers.by larusso