frontpage.
newsnewestaskshowjobs

Made with ♥ by @iamnishanth

Open Source @Github

fp.

Show HN: The Copilot for Engineering Leaders

https://eliuai.com/
1•lohii•1m ago•0 comments

Show HN: Yet another free LaTeX OCR tool for STEM/AI learners, run in browser

https://texocr.netlify.app/
1•alephpi•6m ago•1 comments

Wall Street's Elite Are Turning Marathon Times into a Status Symbol

https://www.bloomberg.com/news/articles/2025-10-31/marathon-times-are-a-status-symbol-for-wall-st...
1•helsinkiandrew•8m ago•1 comments

'Nobody owns the sand': The 12-metre fence dividing an affluent beach town

https://www.bbc.co.uk/news/articles/cgkznrjme1po
3•mellosouls•26m ago•0 comments

Show HN: The Best Tools To Ever Exist

https://github.com/GithubAnant/toolss
1•anant_who•30m ago•1 comments

Ask HN: Data analyst and software engineering? Is there a role like this?

1•mettamage•31m ago•0 comments

Flux Kontext AI

https://flux1kontext.ai/
1•zhaomeng•37m ago•0 comments

Chopdi AI

https://www.chopdi.ai/
1•Hamid213•43m ago•1 comments

Yzer – Learn About Bitcoin, Finance and Economics

https://yzer.io/
1•janandonly•46m ago•0 comments

.arpa, rDNS and a few magical ICMP hacks

https://sdomi.pl/weblog/24-arpa-hacks/
2•caminanteblanco•47m ago•0 comments

Challenging the Fastest OSS Workflow Engine

https://obeli.sk/blog/challenging-fastest-workflow-engine/
1•birdculture•49m ago•0 comments

Show HN: Newsmap - See Articles on a World Map

https://newsmap.info/
16•marinoluca•51m ago•0 comments

Show HN: PostForgeHub – Turn 1 content into 50 social posts with AI

https://postforgehub.com
1•liangguangtong•56m ago•0 comments

Current ETL/ELT tools solve one problem, but seems lacking on E2E solution

2•vivekburman•1h ago•2 comments

Scientists look to genetics to explain why GLP-1 drugs work only for some people

https://www.scientificamerican.com/article/why-ozempic-and-wegovy-dont-cause-weight-loss-for-ever...
1•bookofjoe•1h ago•1 comments

The holes in the map: England's unregistered land

https://whoownsengland.org/2019/01/11/the-holes-in-the-map-englands-unregistered-land/
4•fanf2•1h ago•0 comments

My Micro Portfolio

https://mohddanish.com/open
1•mddanishyusuf•1h ago•0 comments

19: Richard Hipp, SQLite [video]

https://www.youtube.com/watch?v=2SGCX0Dl-74
1•atomicnature•1h ago•1 comments

Show HN: One Halloween Night" – Free Story-Driven Horror for Spooky Quick Plays

https://onehalloweennight.app/
1•aishu001•1h ago•0 comments

Space Exploration Logo Archive

https://spaceexplorationlogoarchive.webflow.io
1•graposaymaname•1h ago•0 comments

Show HN: An ergonomic metrics crate for Rust

https://github.com/chainbound/prometric
1•mempirate•1h ago•0 comments

Claude-Workflow

https://www.npmjs.com/package/claude-workflow
1•fullstacktard•1h ago•0 comments

GitHub PR Graph Generator

https://github.com/hnarayanan/pr-graph-generator
2•hnarayanan•1h ago•0 comments

Genetically Engineered Fungus Could Help Fix Your Mosquito Problem

https://www.nytimes.com/2025/11/01/science/fungus-mosquitoes-genetic-engineering.html
1•quapster•1h ago•0 comments

The purported benefits of effect systems

https://typesanitizer.com/blog/effects-convo.html
2•Bogdanp•1h ago•0 comments

Show HN: Masonry-AR – A Location-Based AR Game Built with Three.js

https://demensdeum.com/demos/masonry-ar/client/
1•demensdeum•1h ago•0 comments

Dictionary.com's 2025 Word of the Year is 67

https://www.dictionary.com/e/word-of-the-year-2025/
1•fodmap•1h ago•0 comments

You Can't Refuse to Be Scanned by ICE's Facial Recognition App, DHS Document Say

https://www.404media.co/you-cant-refuse-to-be-scanned-by-ices-facial-recognition-app-dhs-document...
7•nh43215rgb•1h ago•0 comments

GTA developer accused of sacking 30 staff in 'union-busting' move

https://www.itv.com/news/2025-10-31/gta-developer-allegedly-sacked-30-staff-in-union-busting-move
3•recursion•1h ago•0 comments

Fed 'Chorus' Comes Out Against Latest Cut, Citing Inflation

https://www.bloomberg.com/news/articles/2025-10-31/fed-s-logan-says-didn-t-want-rate-cut-with-inf...
1•moose_man•1h ago•0 comments
Open in hackernews

Hard Rust requirements from May onward for all Debian ports

https://lists.debian.org/debian-devel/2025/10/msg00285.html
72•rkta•3h ago

Comments

CartwheelLinux•2h ago
The language is tough love, and I think it's important despite what the first respondent has said.

Much of the language used seems to stem from nauseating interactions that have occured in kernel world around rust usage.

I'm not a big fan of rust for reasons that were not brought up during the kernel discussions, but I'm also not an opponent of moving forward. I don't quite understand the pushback against memory safe languages and defensiveness against adopting modern tooling/languages

lelanthran•2h ago
The pushback is against the acolytes not the language.

If you could separate the language from the acolytes it would have seen much faster adoption.

kaoD•1h ago
In my experience from these threads, there are more people polluting the discussion by complaining about Rust "acolytes" than actual acolytes.

Rust haters seem strangely obsessed.

lelanthran•41m ago
> Rust haters seem strangely obsessed.

Well, this is a great example. People complaining about the community are labeled as people complaining about the language.

Do you not see the problem here?

testdelacc1•1h ago
Acolytes being the people talking positively about their experience using a language and the strengths they think it has. So the people with positive opinions should say nothing at all, and the people with negative opinions should be free to share. And somehow, you think this will lead to faster adoption.

That’s an interesting thought. It would run counter to everything we know about human nature, but interesting nevertheless.

Rust is already pretty successful adoption wise. It’s powering significant parts of the internet, it’s been introduced in 3 major operating systems (Windows, Linux, Android), many successful companies in a variety of domains have written their entire tech stack in it. Adoption as measured by crates.io downloads has doubled every year for the last 10 years.

Now I’m imagining how much more widely Rust would be used if they had adopted your visionary approach of never saying anything positive about it.

lelanthran•34m ago
> Acolytes being the people talking positively about their experience using a language and the strengths they think it has.

No, it's the people who have given rise to the multiple Rust memes over the years.

I'm battling to think of any other about-to-go-mainstream language that had the reputation of a hostile community. Scala? Kotlin? Swift? Zig? None of those languages have built such poor reputations for their communities.

After all, for quite a few years every thread on forums that mentioned C or C++ was derailed by Rust proponents. I didn't see C++ users jumping into Rust threads posting attacks, but there are many examples of Rust users jumping into C++ or C threads, posting attacks.

> That’s an interesting thought. It would run counter to everything we know about human nature, but interesting nevertheless.

Well, the fact that Rust is an outlier in this sample should tell you everything you need to know; other up-and-coming languages have not, in the past, gotten such a reputation.

testdelacc1•27m ago
> I'm battling to think of any other about-to-go-mainstream language that had the reputation of a hostile community.

Because you’re young or you weren't around in 2010 when Go was gaining adoption. Same shit back then. People said “I like the language, it’s quite useful” followed by tirades from people who thought it was the end of human civilisation. It had exactly the reputation you speak of. (“DAE generics???”)

Eventually the haters moved on to hating something else. That’s what the Rust haters will do as well. When Zig reaches 1.0 and gains more adoption, the haters will be out in full force.

uecker•2h ago
I think the spin that Rust is necessarily the way forward is what is wrong. IMHO Rust has severe problems and what is considered "modern" is mostly taste. We have seen the same thing in the past with a push towards C++, Java, managed languages. What is new is that the free software movement is now controlled so much by corporate interests that some of these changes are pushed through aggressively against the interests of other parts of the community. In the past, if you wanted something changed and there was no agreement, you created a fork and if it was truly better it was eventually adopted by the majority. Nowadays, the companies which fund most of the development aggressively pursue their interests and the part of the community that disagrees is forced out. This justified by with suitable propaganda "not willing to adapt", etc. The whole point of free software should be that I do not have to adapt to some companies's idea of what is modern, if I do not want to. This is why I fled from Microsoft.
Mond_•1h ago
> IMHO Rust has severe problems and what is considered "modern" is mostly taste.

Really? As opposed to e.g. C or C++ (as the most important languages which Rust is competing with)? Sure, taste plays into everything, but I think a lot of people work with Rust since it's genuinely a better tool.

I hear you on free software being controlled by corporate interests, but that's imo a separate discussion from how good Rust is as a language.

noosphr•1h ago
I'm very happy with common lisp for fast code.

Of course most people aren't smart enough for the language so they have to use inferior algol languages like rust.

AlotOfReading•1h ago
No need to sully CL with this kind of elitism. Any language you need to be a genius to use is a bad language. That's one of the fundamental issues with C. We're all imperfect idiots some of the time and one instance of undefined behavior breaks any guarantees the language gives you.
noosphr•1h ago
I find that languages with a high intellectual barrier to entry are much more pleasant places to be since people like the OP can't understand them and we never have people try to bully us into doing things _the right way_.

This is someone who says things like

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

While on company time.

Antibabelic•1h ago
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.
pjmlp•1h ago
And just recently Modula-2.
einpoklum•1h ago
That is a 'subtle whataboutism' reply, actually...

you see, GP did not speak in relative terms, but absolutely: They believe Rust has problems. They did not suggest that problems with programming languages are basically all fungible, that we should sum up all problems, compare different languages, and see which ones come out on top.

mirashii•1h ago
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 changes if you want. Thats the real point of free software, that you have the freedom to make that choice. The whole point of free software was never that the direction of the software should be free from corporate control in some way, the maintainers of a project have always had the authority to make decisions about their own project, whether individual or corporate or a mix.

throwingrocks•1h ago
> The whole point of free software should be that I do not have to adapt to some companies's idea of what is modern, if I do not want to.

This hasn’t changed.

crote•49m ago
> I think the spin that Rust is necessarily the way forward is what is wrong.

Well, what's the alternative? The memory safety problem is real, I don't think there is any doubt about that.

C/C++ is a dead end: the community has thoroughly rejected technical solutions like the Circle compiler, and "profiles" are nothing more than a mirage. They are yet again trying to make a magical compiler which rejects all the bad code and accepts all the good code without making any code changes, which of course isn't going to happen.

Garbage collection is a huge dealbreaker for the people still on C/C++. This immediately rules out the vast majority of memory-safe languages. What is left is pretty much only Zig and Rust. Both have their pros and cons, but Rust seems to be more mature and has better community adoption.

The way I see it, the pro-memory-safety crowd is saying "There's a giant hole in our ship, let's use Rust to patch it", and the anti-Rust crowd yells back "I don't like the color of it, we shouldn't repair the hole until someone invents the perfect solution". Meanwhile, the ship is sinking. Do we let the few vocal Rust haters sink the ship, or do we tell them to shut up or show up with a better alternative?

zozbot234•42m ago
Basically correct, but Zig is not a memory safe language. It may be an improvement wrt. syntax over C, and its standard library facilities may be genuinely better than Rust's wrt. writing unsafe code, but it's simply not interesting from a safety perspective. I'm sure that even the most rabid Zig advocates would readily acknowledge this point.

> Garbage collection is a huge dealbreaker for the people still on C/C++.

The problem is not so much GC itself, but more like pervasive garbage collection as the only memory management strategy throughout the program. Tracing GC is a legit memory management strategy for some programs or parts of a program.

mrkeen•16m ago
> if you wanted something changed and there was no agreement, you created a fork and if it was truly better it was eventually adopted by the majority.

This assumes there wasn't agreement.

And if so, what would 'eventually adopted by the majority' mean. Is this announcement not that?

tcfhgj•1h ago
I haven't either, until I read comments on Rust in Linux on social media outside HN.

Apparently, Rust is part of the "woke agenda"

hofrogs•1h ago
Yep, I noticed that under a lot of videos mentioning rust in kernel, or rust in general there's a high chance that the comment section will just be straight up lifted from 4chan pol or a similar place
alt187•49m ago
People are (understandably) sick of the fact that for whatever reason, the biggest proponents of Rust are insufferable.

Personally, I'm simply bothered by the fact that (one of?) the most famous figure of Rust on Linux and Rust Forever consumes and advocates for pornography that's illegal in my country, without being held accountable by the community.

From what I could piece together, the only group who ever cried wolf about this is a forum full of contemptious little angry men who spend weeks researching people they hate on the internet. No one seems to want to touch the subject from fear of being associated with them.

I'll give it to you, this is not a great time.

TheChaplain•1h ago
I don't think it is the language that is the problem, even though the syntax is a vomit inducing child with worst traits from a loveaffair between perl and c++ metatemplates. The people surrounding it however, it's a like cult and a very weird one.
Ygg2•1h ago
Tell me you haven't used Rust without telling me you haven't used Rust.
mrweasel•1h ago
For me it actually is the language. While a little pushy at times I think the arguments for rewriting certain things in a safer language is well founded. If the apt tool chains is one of those places I'll leave for the Debian developers to determine, but for decompression tools I can see a benefit.

If Rust should be the language of choice, preferably not. The syntax is awful, the language is complicated and Rust programs seems to collect dependencies at the same rate as JavaScript. Where I might agree with you is that Rust seems to attract a certain type of people. They write absolutely brilliant software, but like the Rust compile, they are rather particular with what input they'll accept.

In the end I don't really care what apt is written in, I'm not the one writing the code. I just use the tool. It would be sad if some platforms are left behind, because the Rust developers don't care about them and not because they're no longer useful.

hulitu•50m ago
> While a little pushy at times I think the arguments for rewriting certain things in a safer language is well founded.

Yes. It is. Just write the code and show us that it is good.

bmicraft•58m ago
Ironically, the people hating on it (and usually without any technical arguments) act way more cultish.

At least it looks that way to my not-rust-using self

hulitu•51m ago
> I don't quite understand the pushback against memory safe languages

As far as i read on HN, the only memory safe language discused on HN is rust and mostly with childish pro arguments.

zozbot234•49m ago
Java and C# are memory safe languages, as are common interpreted languages like Python and Ruby. Even JavaScript is memory safe, barring the possibility of subtle JIT bugs that may practically impact such safety.
kaoD•3m ago
But op means memory safe, without a GC nor a runtime, so it can be used as a systems programming language. For "some reason" people only talk about Rust in this space!
littlestymaar•2h ago
> 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.

Rust is the present and the future and it's quite logical that it becomes a key requirement in Linux distributions, but I'm really not convinced by the wording here… This last sentence feels needlessly antagonistic.

jchw•1h ago
I suspect if this mailing list post doesn't go too under the radar, that last sentence will be a source of major regret.
noobermin•1h ago
And if it is it absolutely is indicative of their opinion and absolutely deserved.
IshKebab•1h ago
Feels accurate to me. He's clearly anticipating the "but how will I run Debian on my PDP-11??" naysayers that always try to derail things.
tialaramex•1h ago
Right. I do have some nostalgia for installing Linux on a brand new PC which had less total RAM than my computer today has cache, but we need to be clear eyed about what makes sense for a maintained piece of software. I also have feelings about steam trains, but burning coal is not a sensible way to power a train in 2025.

A nostalgia-fuelled Linux distro, maybe using a deliberately slimmed down or retro kernel, and chosen software could make a lot more sense than keep trying to squeeze Debian onto hardware that was already obsolete at the turn of the century while also promoting Debian as a viable choice for a brand new laptop.

DaSHacka•1h ago
Or those annoying nagging "well, what if I don't have an X86_64 CPU that was made in the last five years?", to which obviously our response should be: "get different hardware LOL, closedwontfix"
IshKebab•59m ago
No, supporting 5 year old mainstream hardware is a very reasonable thing to do. Supporting 20 year old hardware that barely anyone used even when it was new is not.
tialaramex•36m ago
Indeed. Four targets are identified as potentially affected:

alpha, hppa, m68k and sh4

To be fair, lots of people did use Motorola 68xxx CPUs when those were new, it's just that it was 40+ years ago in products like the Commodore Amiga. The SH4 is most popularly connected to the Dreamcast, Sega's video game console from back when Sega made video game consoles.

The Alpha and PA Risc were seen in relatively recent and more conventional hardware, but in much tinier numbers, and when I say relatively I mean early this century, these are not products anybody bought five years ago, and when they were on sale they were niche products for a niche which in practical terms was eaten by Microsoft.

NewsaHackO•48m ago
Is your point that rust doesn't run on a computer built in 2020?
DaSHacka•21m ago
No, but that if it did not, I am not so sure that would even be seen as a problem.
testdelacc1•47m ago
Has Linux dropped support for older x86 CPUs?
justinclift•2h ago
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?

uecker•1h ago
They are of no commercial interest to Ubuntu.
justinclift•1h ago
While that seems like it would be true, is that really relevant to Debian? :)
noosphr•1h ago
The person making the post is getting paid by Ubuntu.
apples_oranges•1h ago
Needs a perhaps with question mark or some proof.
noosphr•1h ago
You could just read his signiture in the mailing list.

https://mastodon.social/@juliank

>Senior Engineer at Canonical.

julian-klode•54m ago
Yes that's true and there's synergies but keep in mind I also have a personal mind
troupo•1h ago
> Wonder what this means for those architectures then?

They will be rebranded as "retro computing devices"

IshKebab•1h ago
Those all seem to be completely obsolete so I guess they can just stay on the latest version of Debian that supports them, or make their own distro. (Or add Rust support I guess but that's probably not realistic.)
zozbot234•1h ago
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 basic initial support but no 'core' or 'std' builds yet. https://doc.rust-lang.org/rustc/platform-support/m68k-unknow... This should potentially be fixable.

noosphr•1h ago
I don't get the need for Rust since I happily compile common lisp to machine code when I need fast binaries.

But the people who use the language have an amazing talent to make people on the fence hate them within half a dozen sentences.

They remind me of Christian missionaries trying to convert the savages from their barbarous religions with human sacrifice to the civilised religion with burning heretics.

noobermin•1h ago
I understand the instinct to downvote but the rust advocates themselves often are offputting to everyone else and we should be able to be honest about this.
kaoD•1h ago
Well, so far this thread has 0 people shilling Rust, a couple shilling Common Lisp and a bunch complaining about Rust shills (you included).

Makes you think, huh?

testdelacc1•35m ago
It’s a preemptive strike. By complaining about the Rust shills before they can show up, it prevents Rust shilling before it can happen. It’s a more humane approach and it saves lives. You don’t realise the social service the anti-Rust-shills are performing.
Antibabelic•1h ago
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.
noosphr•1h ago
Yes, but we're not making a push to make everything a bilingual c/lisp code base.

Rust people for some reason are.

mdhb•1h ago
Not a Rust or even a systems language guy but it’s not “for some reason”. The reason is actually incredibly clear and about removing the single largest surface area of security problems in the entire history of Linux.
hulitu•54m ago
> The reason is actually incredibly clear

There is no guarantee that other bugs do not flurish in the rust echosystem. There are no publicly known quality code checks of rust programs except a big "trust us"(see firefox with all its CVEs, despite "rust"). And combined with the Cargo echosystem, where every malicious actor can inject malware is a big warning sign.

bestouff•45m ago
There are guarantees that many types of bugs won't happen in Rust code. That alone is a great progress.
kaoD•44m ago
I might be misunderstanding here but... what you're saying is that Rust programs can still have bugs? Isn't that the same as other programs except Rust prevents the most disastrous and common bugs that lead to most CVEs?

If I got that right, how is "it's still not perfect" an argument?

Agree with the Cargo objection.

mdhb•42m ago
a bunch of major projects have conclusively shown that moving to memory safe languages without any doubt whatsoever results in more secure software.
tcfhgj•37m ago
Firefox is 29% Javascript, 28% C++, 22% HTML, 10% C, 3% Python, 2,6% Kotlin and 5% other

> There is no guarantee that other bugs do not flurish in the rust echosystem.

well, less likely than in C thanks to a advanced type system, e.g. allowing authors of abstractions make their API much more fool proof.

> where every malicious actor can inject malware is a big warning sign.

Very much doubt that is the case...

norman784•30m ago
AFAIK Linux is using rustc directly, without cargo.

And just an anecdote, Asahi Linux devs said that Rust made it very easy (maybe relative to working with C) to write the drivers for the Apple M1 and M2 series, so it seems that the language has his merits, even without the cargo ecosystem.

Also Rust will only minimize certain kinds of bugs, others are impossible, a few years ago (I believe was Microsoft) that said that 70% of the bugs found were memory related [0], it means that Rust would have prevented most of those.

Maybe Rust is not the best answer, but as for now it the most proven answer for this particular problem, who know of Zig or other language will replace both C and Rust in the future.

[0] https://www.zdnet.com/article/i-ditched-linux-for-windows-11...

codedokode•1h ago
How can lisp be fast if it doesn't have static typing and uses GC?
littlestymaar•7m ago
> Christian missionaries trying to convert the savages

Fast forward 5 centuries, it turns out they were in fact pretty successful as South America central Africa are the places where Catholicism is the most active today, far more than in Europe.

nikanj•1h ago
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

Antibabelic•1h ago
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.
mirashii•1h ago
No, it’s a valid question, and one that I’m sure will get some answers in the coming days and weeks as the discussion on adding this requirement continues, but in some sense, it’s beside the point.

The cost of supporting this old hardware for businesses or hobbyists isn’t free. The parties that feel strongly that new software continue to be released supporting a particular platform have options here, ranging from getting support for those architectures in LLVM and Rust, pushing GCC frontends for rust forward, maintaining their own fork of apt, etc.

tsimionescu•53m ago
It's much more common to find businesses running on very old hardware in developed countries, not in developing ones. Developing nations basically didn't use computers 20-30 years ago, there's no random remnants from that era beyond some extreme tail end. And, given how the PC & server market evolved in the 2000s and 2010s, it was cheaper to buy a then-current x86 than to import some ancient Alpha system from wherever. Especially so since software licenses didn't really exist in those days in developing countries - even government institutions often ran pirated software without a second thought.
mdhb•44m ago
Isn’t this the specific reason things like the raspberry pi were developed to solve?
einpoklum•41m ago
It is not retro-computing. New 32-bit and x86 CPUs are produced, sold, and used today.

See (relatively recent) list of manfuacturers here:

https://en.wikipedia.org/wiki/List_of_x86_manufacturers

and scroll down for other categories of x86 chip manufacturers. These have plenty of uses. Maybe in another 30 years' time they will mostly be a hobby, but we are very far from that time.

versteegen•1h ago
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.
julian-klode•1h ago
We're really talking about alpha, hppa, m68k and sh4
einpoklum•46m ago
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.

troupo•1h ago
> 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.

aka "hype-driven programming" where "retro computing devices" are defined as "all platforms our shiny new toys don't support".

einpoklum•1h ago
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, granted, I'm not an expert on distro management, bootstrapping etc. so maybe I'm over-reacting, but I am definitely experiencing some fear, uncertainty and doubt here. :-(

mirashii•49m ago
> Dependencies will be added, for very basic system utilities, on (parts of) a software ecosystem which is still a "moving target", not standardized,

This is the status quo and always has been. gcc has plenty of extensions that are not part of a language standard that are used in core tools. Perl has never had a standard and is used all over the place.

einpoklum•29m ago
If you're designing an OS distribution, you would have your base system written adhering strictly to language standards and without relying on flakey extensions (not that GCC C extensions are flakey, I'm guessing most/all of them are stable since the 1990s), and minimizing reliance on additional tools.

For example, IIUC, you can build a perl interpreter using a C compiler and GNU Make. And if you can't - GCC is quite bootstrappable; see here for the x86 / x86_64 procedure:

https://stackoverflow.com/a/65708958/1593077

and you can get into that on other platforms anywhere along the bootstrapping chain. And then you can again easily build perl; see:

https://codereflections.com/2023/12/24/bootstrapping-perl-wi...

teaearlgraycold•1h ago
Why do these matters often become such personal and ideological debates?
cmm11•55m ago
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

mid-kid•38m ago
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?

julian-klode•37m ago
Ports are not part of Debian and particularly don't release with Debian, they only ship unstable.
mid-kid•34m ago
changed the wording a little, thanks
krautburglar•34m ago
I think polyglot causes more problems than it solves. It is gross how many different toolchains and package managers it now takes to build a distro. One person wants python, another wants node, another wants go, and now this. with node we traded buffer overflows for supply chain attacks. If they don’t want C, it would be better to start fresh. Robert Morris re-wrote enough of Linux in golang to be usable, and the overhead was something like 5-15% slower than C. If the goal is Rust everywhere, contribute to Redox. They are further along that road.