Apt Rust requirement raises questions
176 comments
·November 25, 2025geerlingguy
Aurornis
> I think the whole message would be more palatable if it weren't written as a decree including the dig on "retro computers", but instead positioned only on the merits of the change.
The wording could have been better, but I don’t see it as a dig. When you look at the platforms that would be left behind they’re really, really old.
It’s unfortunate that it would be the end of the road for them, but holding up progress for everyone to retain support for some very old platforms would be the definition of the tail wagging the dog. Any project that starts holding up progress to retain support for some very old platforms would be making a mistake.
It might have been better to leave out any mention of the old platforms in the Rust announcement and wait for someone to mention it in another post. As it was written, it became an unfortunate focal point of the announcement despite having such a small impact that it shouldn’t be a factor holding up progress.
razighter777
Agreed. I think that announcement was unprofessional.
This was a unilateral decision affecting other's hard work, and the author didn't provide them the opportunity to provide feedback on the change.
It disregards the importance of ports. Even if an architecture isn't widely used, supporting multiple architectures can help reveal bugs in the original implementation that wouldn't otherwise be obvious.
This is breaking support for multiple ports to rewrite some feature for a tiny security benefit. And doing so on an unacceptably short timeline. Introducing breakage like this is unacceptable.
There's no clear cost-benefit analysis done for this change. Canonical or debian should work on porting the rust toolchain (ideally with tier 1 support) to every architecture they release for, and actually put the cart before the horse.
I love and use rust, it is my favorite language and I use it in several of my OSS projects but I'm tired of this "rewrite it in rust" evangilism and the reputational damage they do to the rust community.
reidrac
> As an end user, it doesn't concern me too much ...
It doesn't concern me neither, but there's some attitude here that makes me uneasy.
This could have been managed better. I see a similar change in the future that could affect me, and there will be precedent. Canonical paying Devs and all, it isn't a great way of influencing a community.
cvcfdd
[dead]
gorgoiler
There are many high profile DDs who work or have worked for Canonical who are emphatically not the inverse — Canonical employees who are part of the Debian org.
The conclusion you drew is perfectly reasonable but I’m not sure it is correct, especially when in comparison Canonical is the newcomer. It could even be seen to impugn their integrity.
ndiddy
If you look at the article, it seems like the hard dependency on Rust is being added for parsing functionality that only Canonical uses:
> David Kalnischkies, who is also a major contributor to APT, suggested that if the goal is to reduce bugs, it would be better to remove the code that is used to parse the .deb, .ar, and .tar formats that Klode mentioned from APT entirely. It is only needed for two tools, apt-ftparchive and apt-extracttemplates, he said, and the only ""serious usage"" of apt-ftparchive was by Klode's employer, Canonical, for its Launchpad software-collaboration platform. If those were taken out of the main APT code base, then it would not matter whether they were written in Rust, Python, or another language, since the tools are not directly necessary for any given port.
gorgoiler
I understand, but the comment to which I was replying implied that this keeps happening, and in general. That’s not fair to the N-1 other DDs who aren’t the subject of this LWN article (which I read!)
theoldgreybeard
Rust developers are so dogmatic about their way being the best and only way that I just avoid it altogether. I've had people ask about Rust in issues in small hobby projects I released as open source - I just ban them immediately because there is no reasoning with them. Open source terrorists.
fn-mote
The most interesting criticism / idea in the article was that the parts that are intended for Rust-ification should actually be removed from core apt.
> it would be better to remove the code that is used to parse the .deb, .ar, and .tar formats [...] from APT entirely. It is only needed for two tools, apt-ftparchive and apt-extracttemplates [...]
Another interesting, although perhaps tangential, criticism was that the "new solver" currently lacks a testsuite (unit tests; it has integration tests). I'm actually kind of surprised that writing a dependency solver is a greenfield project instead of using an existing one. Or is this just a dig at something that pulls in a well-tested external module for solving?
Posted in curiosity, not knowing much about apt.
inetknght
> the "new solver" currently lacks a testsuite
To borrow a phrase I recently coined:
If it's not tested then it's not Engineered.
You'd think that core tools would have proper Software Engineering behind them. Alas, it's surprising how many do not.
nofunsir
Unit tests does not make Software Engineering. That's simply part of the development phase, which should be the smallest phase out of all the phases involved in REAL Software Engineering, which is rarely even done these days, outside of DO-178 (et al) monotony. The entire private-to-public industry has even polluted upper management in defense software engineering into accepting SCRUM as somehow more desirable than the ability to effectively plan your requirements and execute without deviation. Yes it's possible, and yes it's even plausible. SWE laziness turns Engineers into developers. Running some auto-documentation script or a generic non-official block diagram is not the same as a Civil PE creating blueprints for a house, let alone a mile long bridge or skyscraper.
cactusfrog
Could the rust code be transpired to readable C?
stonemetal12
Given that Cargo is written in Rust, you would think there would be at least one battle tested solver that could be used. Perhaps it was harder to extract and make generic than write a new one?
steveklabnik
Cargo's solver incorporates concepts that .debs don't have, like Cargo features, and I'm sure that .debs have features that Cargo packages don't have either.
catlifeonmars
Dependency solvers are actually an area that can benefit from updating IMO.
dv35z
Every time I consider learning Rust, I am thrown back by how... "janky" the syntax is. It seems to me that we ought to have a system-level language which builds upon the learnings of the past 20+ years. Can someone help me understand this? Why are we pushing forward with a language that has a Perl-esque unreadability...?
Comparison: I often program in Python (and teach it) - and while it has its own syntax warts & frustrations - overall the language has a "pseudocode which compiles" approach, which I appreciate. Similarly, I appreciate what Kotlin has done with Java. Is there a "Kotlin for Rust"? or another high quality system language we ought to be investing in? I genuinely believe that languages ought to start with "newbie friendliness", and would love to hear challenges to that idea.
movpasd
You might this blog post interesting, which argues that it's Rust semantics and not syntax that results in the noisiness, i.e.: it's intrinsic complexity:
https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html
I found it reasonably convincing. For what it's worth, I found Rust's syntax quite daunting at first (coming from Python as well), but it only took a few months of continuous use to get used to it. I think "Perl-esque" is an overstatement.
It has some upsides over Python as well, notably that the lack of significant whitespace means inserting a small change and letting the autoformatter deal with syntax changes is quite easy, whereas in Python I occasionally have to faff with indentation before Black/Ruff will let me autoformat.
I appreciate that for teaching, the trade-offs go in the other direction.
xscott
I'm not sure which of the dozen Rust-syntax supporters I should reply to, but consider something like these three (probably equivalent) syntaxes:
let mut a = Vec::<u32>::new();
let mut b = <Vec::<u32>>::new();
let mut c = <Vec<u32>>::new();
This is day one stuff for declaring a dynamic array. What you really want is something like:
let mut z = Vec<u32>::new();
Yes, I know there is a `vec!` macro. Will you require your coworkers to declare a similar macro when they start to implement their own generic types?
There are lots of other examples when you get to what traits are required to satisfy generics ("where clauses" vs "bounds"), or the lifetime signature stuff and so on...
You can argue that strong typing has some intrinsic complexity, but it's tougher to defend the multiple ways to do things, and that WAS one of Perl's mantras.
jandrese
I think Perl-esque is apt, but that's because I've done quite a bit of Perl and think the syntax concerns are overblown. Once you get past the sigils on the variables Perl's syntax is generally pretty straightforward, albeit with a few warts in places like almost every language. The other area where people complained about Perl's opaqueness was the regular expressions, which most languages picked up anyway because people realized just how useful they are.
mrweasel
That article is really good, because it highlight that Rust doesn't have to look messy. Part of the problem, I think, is that there's a few to many people who think that messy version is better, because it "uses more of the language" and it makes them look smarter. Or maybe Rust just makes it to hard to see through the semantics and realize that just because feature is there doesn't mean that you need it.
There's also a massive difference between the type of C or Perl someone like me would write, versus someone trying to cope with a more hostile environment or who requires higher levels of performance. My code might be easier to read, but it technically has issue, they are mostly not relevant, while the reverse is true for a more skilled developer, in a different environment. Rust seems to attract really skilled people, who have really defensive code styles or who use more of the provided language features, and that makes to code harder to read, but that would also be the case in e.g. C++.
echelon
That's it exactly.
Once you're writing Rust at full speed, you'll find you won't be putting lifetimes and trait bounds on everything. Some of this becomes implicit, some of it you can just avoid with simpler patterns.
When you write Rust code without lifetimes and trait bounds and nested types, the language looks like Ruby lite.
When you write Rust code with traits or nested types, it looks like Java + Ruby.
When you sprinkle in the lifetimes, it takes on a bit of character of its own.
It honestly isn't hard to read once you use the language a lot. Imagine what Python looks like to a day zero newbie vs. a seasoned python developer.
You can constrain complexity (if you even need it) to certain modules, leaving other code relatively clean. Imagine the Python modules that use all the language features - you've seen them!
One of the best hacks of all: if you're writing HTTP services, you might be able to write nearly 100% of your code without lifetimes at all. Because almost everything happening in request flow is linear and not shared.
carlmr
>When you write Rust code without lifetimes and trait bounds and nested types, the language looks like Ruby lite.
And once you learn a few idioms this is mostly the default.
SoftTalker
This honestly reads like the cliche "you just don't get it yet" dismissals of many rust criticisms.
enriquto
> I am thrown back by how... "janky" the syntax is.
Well if you come from C++ it's a breath of fresh air! Rust is like a "cleaned-up" C++, that does not carry the historical baggage forced by backwards compatibility. It is well-thought out from the start. The syntax may appear a bit too synthetic; but that's just the first day of use. If you use it for a few days, you'll soon find that it's a great, beautiful language!
The main problem with rust is that the community around it has embraced all the toxic traditions of the js/node ecosystem, and then some. Cargo is a terrifying nightmare. If you could install regular rust dependencies with "apt install" in debian stable, that would be a different story! But no. They want the version churn: continuously adding and removing bugs, like particle/anti-particle pairs at the boundary of a black hole.
Concerning TFA, adding rust to apt might be a step in the right direction. But it should be symmetric: apt depends on rust, that's great! But all the rust that it depends on needs to be installed by apt, and by apt alone!
tcfhgj
I am coming from C++ and think Cargo is a blessing.
I like that I can just add a dependency and be done instead of having to deal with dependencies which require downloading stuff from the internet and making them discoverable for the project specific tool chain - which works differently on every operating system.
Same goes for compiling other projects.
kataklasm
But that is the kind of convenience and ease of use that brings us another npm malware incident every other month at this point.
steveklabnik
Debian already builds Rust packages from apt, so it will satisfy that critera.
raincole
> Cargo is a terrifying nightmare
Really? Why? I'm not a Rust guru, but Cargo is the only part of Rust that gave me a great first impression.
freedomben
GP mostly answered that in the comment already:
> If you could install regular rust dependencies with "apt install" in debian stable, that would be a different story! But no. They want the version churn: continuously adding and removing bugs, like particle/anti-particle pairs at the boundary of a black hole.
superxpro12
As a c/c++ cmake user, cargo sounds like a utopia in comparison. It still amazes me that c/c++ package management is still spread between about 5 different solutions.
IMO, the biggest improvement to C/C++ would be ISO defining a package manager a.la pip or uv or cargo. I'm so tired of writing cmake. just... tired.
hedora
People that don't understand make are destined to recreate it poorly, and there's no better example than cmake, imho.
Here's my arc through C/C++ build systems:
- make (copy pasted examples)
- RTFM [1]
- recursive make for all sorts of non-build purposes - this is as good as hadoop up to about 16 machines
- autotools
- cmake
- read "recursive make considered harmful" [2]
- make + templates
Anyway, once you've understood [1] and [2], it's pretty hard to justify cmake over make + manual vendoring. If you need windows + linux builds (cmake's most-advertised feature), you'll pretty quickly realize the VS projects it produces are a hot mess, and wonder why you don't just maintain a separate build config for windows.
[1] https://www.gnu.org/software/make/manual/
[2] https://news.ycombinator.com/item?id=20014348
If I was going to try to improve on the state of the art, I'd clean up a few corner cases in make semantics where it misses productions in complicated corner cases (the problems are analogous to prolog vs datalog), and then fix the macro syntax.
If you want a good package manager for C/C++, check out Debian or its derivatives. (I'm serious -- if you're upset about the lack of packages, there's a pretty obvious solution. Now that docker exists, the packages run most places. Support for some sort of AppImage style installer would be nice for use with lesser distros.)
enriquto
cmake is a self-inflicted problem of some C++ users, and an independent issue of the language itself (just like cargo for rust). If you want, you can use a makefile and distribution-provided dependencies, or vendored dependencies, and you don't need cmake.
Aurornis
> Comparison: I often program in Python (and teach it) - and while it has its own syntax warts & frustrations - overall the language has a "pseudocode which compiles" approach, which I appreciate.
I think this is why you don’t like Rust: In Rust you have to be explicit by design. Being explicit adds syntax.
If you appreciate languages where you can write pseudocode and have the details handled automatically for you, then you’re probably not going to enjoy any language that expects you to be explicit about details.
As far as “janky syntax”, that’s a matter of perspective. Every time I deal with Python and do things like “__slots__” it feels like janky layer upon layer of ideas added on top of a language that has evolved to support things it wasn’t originally planned to do, which feels janky to me. All of the things I have to do in order to get a performant Python program feel incredibly janky relative to using a language with first class support for the things I need to do.
morshu9001
Both Python and JS evolved by building on top of older versions, but somehow JS did a way better job than Python, even though Py forced a major breaking change.
Agree about Rust, all the syntax is necessary for what it's trying to do.
jamespo
You mean typescript?
shmolyneaux
I would encourage you to give it a try anyways. Unfamiliar syntax is off-putting for sure, but you can get comfortable with any syntax.
Coming from Python, I needed to work on some legacy Perl code. Perl code looks quite rough to a new user. After time, I got used to it. The syntax becomes a lot less relevant as you spend more time with the language.
brettermeier
Sure... but you don't want to spend time if it's such a mess to read it.
pohl
Once one does spend some time to become comfortable with the language, that feeling of messiness with unfamiliar syntax fades away. That's the case with any unfamiliar language, not just Rust.
steveklabnik
Syntax tends to be deeply personal. I would say the most straightforward answer to your question is "many people disagree that it is unreadable."
Rust did build on the learnings of the past 20 years. Essentially all of its syntax was taken from other languages, even lifetimes.
handwarmers
Are the many who disagree that it is unreadable more than the people who agree? I have been involved with the language for a while now, and while I appreciate what you and many others have done for it, the sense that the group is immune to feedback just becomes too palpable too often. That, and the really aggressive PR.
Rust is trying to solve a really important problem, and so far it might well be one of the best solutions we have for it in a general sense. I 100% support its use in as many places as possible, so that it can evolve. However, its evolution seems to be thwarted by a very vocal subset of its leadership and community who have made it a part of their identity and whatever socio-political leverage toolset they use.
azdle
I've found the rust core team to be very open to feedback. And maybe I've just been using Rust for too long, but the syntax feels quite reasonable to me.
Just for my own curiosity, do you have an examples of suggestions for how to improve the syntax that have been brought up and dismissed by the language maintainers?
steveklabnik
> Are the many who disagree that it is unreadable more than the people who agree?
I have no way to properly evaluate that statement. My gut says no, because I see people complain about other things far more often, but I do think it's unknowable.
I'm not involved with Rust any more, and I also agree with you that sometimes Rust leadership can be insular and opaque. But the parent isn't really feedback. It's just a complaint. There's nothing actionable to do here. In fact, when I read the parent's post, I said "hm, I'm not that familiar with Kotlin actually, maybe I'll go check it out," loaded up https://kotlinlang.org/docs/basic-syntax.html, and frankly, it looks a lot like Rust.
But even beyond that: it's not reasonably possible to change a language's entire syntax ten years post 1.0. Sure, you can make tweaks, but turning Rust into Python simply is not going to happen. It would be irresponsible.
tayo42
> the sense that the group is immune to feedback
Is complaining about syntax really productive though? What is really going to be done about it?
simonask
This is such a weird take. What do you suggest? Should Rust’s syntax have been democratically decided?
stingraycharles
Seems like a fairly decent syntax. It’s less simple than many systems languages because it has a very strong type system. That’s a choice of preference in how you want to solve a problem.
I don’t think the memory safety guarantees of Rust could be expressed in the syntax of a language like C or Go.
mbel
> It’s less simple than many systems languages because it has a very strong type system.
I don’t think that’s the case, somehow most ML derived languages ended up with stronger type system and cleaner syntax.
yoyohello13
One of the design goals of rust is explicitness. I think if Rust had type elision, like many other functional languages, it would go a long way to cleaning up the syntax.
steveklabnik
Rust's most complained about syntax, the lifetime syntax, was borrowed from an ML: OCaml.
WD-42
I’ve been writing python professionally for over 10 years. In the last year I’ve been writing more and most Rust. At first I thought the same as you. It’s a fugly language, there’s no denying it. But once I started to learn what all the weird syntax was for, it began to ruin Python for me.
Now I begrudge any time I have to go back to python. It feels like its beauty is only skin deep, but the ugly details are right there beneath the surface: prolific duck typing, exceptions as control flow, dynamic attributes. All these now make me uneasy, like I can’t be sure what my code will really do at runtime.
Rust is ugly but it’s telling you exactly what it will do.
jjice
Maybe I've Stockholm'd myself, but I think Rust's syntax is very pleasant. I also think a lot of C code looks very good (although there is some _ugly_ C code out there).
Sometimes the different sets of angle and curly brackets adding up can look ugly at first, and maybe the anonymous function syntax of || {}, but it grows on you if you spend some time with the language (as do all syntaxes, in my experience).
gorgoiler
”[One] major contributor to APT suggested it would be better to remove the Rust code entirely as it is only needed by Canonical for its Launchpad platform. If those were taken out of the main APT code base, then it would not matter whether they were written in Rust, Python, or another language, since the tools are not directly necessary [for regular installations].”
Given the abundance of the hundreds of deb-* and dh-* tools across different packages, it is surprising that apt isn’t more actively split into separate, independent tools. Or maybe it is, but they are all in a monorepo, and the debate is about how if one niche part of the monorepo uses Rust then the whole suite can only be built on platforms that support Rust?
#!/bin/sh
build_core
if has_rust
then
build_launchpad_utils
fi
petcat
Interesting how instead of embracing Rust as a required toolchain for APT, the conversation quickly devolved into
"why don't we just build a tool that can translate memory-safe Rust code into memory-unsafe C code? Then we don't have to do anything."
This feels like swimming upstream just for spite.
forgotpwd16
>tool that can translate memory-safe Rust code into memory-unsafe C code
Fwiw, there're two such ongoing efforts. One[1] being an, written in C++, alternative Rust compiler that emits C (aka, in project's words, high-level assembly), the other[2] being a Rust compiler backend/plugin (as an extra goal to its initial being to compile Rust to CLR asm). Last one apparently is[3] quite modular and could be adapted for other targets too. Other options are continuing/improve GCC front-end for Rust and a recent attempt to make a Rust compiler in C[4] that compiles to QBE IR which can then be compiled with QBE/cc.
[1]: https://github.com/thepowersgang/mrustc [2]: https://github.com/FractalFir/rustc_codegen_clr [3]: https://old.reddit.com/r/rust/comments/1bhajzp/ [4]: https://codeberg.org/notgull/dozer
pbohun
That's not what the comment said. It said, "How about a Rust to C converter?..." The idea was that using a converter could eliminate the problem of not having a rust compiler for certain platforms.
epolanski
The problem is that rust is being shoved in pointless places with a rewrite-everything-in-rust mentality.
There's lunatics that want to replace basic Unix tools like sudo, etc, that are battle tested since ages which has been a mess of bugs till now.
Instead Rust should find it's niches beyond rewriting what works, but tackling what doesn't.
saghm
FWIW sudo has been maintained by an OpenBSD developer for a while now but got replaced in the base system by doas. Independent of any concerns about Rust versus C, I don't think it's quite as unreasonable as you're claiming to consider alternatives to sudo given that the OS that maintains it felt that it was flawed enough to be worth writing a replacement for from scratch.
mmastrac
sudo is not fully battle tested, even today. You just don't really see the CVEs getting press.
https://www.oligo.security/blog/new-sudo-vulnerabilities-cve...
jamespo
Neither of those vulnerabilities look like rust would necessarily help however
null
honeycrispy
Calling it pointless comes across as jaded. It's not pointless.
Supporting Rust attracts contributors, and those contributors are much less likely to introduce vulnerabilities in Rust when contributing vs alternatives.
rrmm
to introduce certain common vulnerabilities ...
not vulnerabilities in general.
anarki8
> The problem is that rust is being shoved in pointless places with a rewrite-everything-in-rust mentality.
> There's lunatics ...
I think the problem is people calling developers "lunatics" and telling them which languages they must use and which software they must not rewrite.
Battle tested is not bulletproof: https://cybersecuritynews.com/sudo-linux-vulnerability/
Applying strict compile time rules makes software better. And with time it will also become battle tested.
dralley
Converting parsers to Rust is not "pointless". Doing string manipulation in C is both an awful experience and also extremely fertile ground for serious issues.
dboon
It’s very easy to write a string library in C which makes string operations high level (both in API and memory management). Sure, you shouldn’t HAVE to do this. I get it. But anyone writing a parser is definitely skilled enough to maintain a couple hundred lines of code for a linear allocator and a pointer plus length string. And to be frank, doing things like “string operations but cheaply allocated” is something you have to do ANYWAY if you’re writing e.g. a parser.
This holds for many things in C
donkeybeer
apt is C++
epolanski
Issues that are battle tested from ages.
marcosdumay
Cue for all those battle tested programs that people keep finding vulnerabilities several decades after they got considered "done". You should try looking at the test results once in a while.
And by the way, we had to replace almost all of the basic Unix tools at the turn of the century because they were completely unfit for purpose. There aren't many left.
sidewndr46
I seem to remember going through this with systemD in Ubuntu. Lots of lessons learned seemed to come back as "didn't we fix this bug 3 years ago?"
genewitch
We need lisp, cobol, and java in apt, too. and firefox.
sidewndr46
All compilers do anyways is translate from one language specification to another. There's nothing magical about Rust or any specific architecture target. The compiler of a "memory safe" language like Rust could easily output assembly with severe issues in the presence of a compiler bug. There's no difference between compiling to assembly vs. C in that regard.
simonask
The assumption here is that there exists an unambiguous C representation for all LLVM IR bitcode emitted by the Rust compiler.
To my knowledge, this isn’t the case.
andsoitis
> The assumption here is that there exists an unambiguous C representation for all LLVM IR bitcode emitted by the Rust compiler.
> To my knowledge, this isn’t the case.
Tell us more?
tsimionescu
The gigantic difference is that assembly language has extremely simple semantics, while C has very complex semantics. Similarly, assembler output is quite predictable, while C compilers are anything but. So the level of match between the Rust code and the machine code you'll get from a Rust-to-assembly compiler will be much, much easier to understand than the match you'll get between the Rust code and the machine code produced by a C compiler compiling C code output by a Rust-to-C transpiler.
GuB-42
Shouldn't we wait until Rust gets full support in GCC? This should resolve the issue with ports without a working Rust compiler.
I don't have a problem with Rust, it is just a language, but it doesn't seem to play along well with the mostly C/C++ based UNIX ecosystem, particularly when it comes to dependencies and package management. C and C++ don't have one, and often rely on system-wide dynamic libraries, while Rust has cargo, which promotes large dependency graphs of small libraries, and static linking.
maeln
You know, it is easy to find this kind of nitpicking and seemingly eternal discussion over details exhausting and meaningless, but I do think it is actually a good sign and a consequence of "openness". In politics, authoritarianism tend to show a pretty façade where everyone mostly agrees (the reality be damned), and discussion and dissenting voice are only allowed to a certain extent as a communication tool. This is usually what we see in corporate development.
Free software are much more like democracy, everyone can voice their opinion freely, and it tends to be messy, confrontational, nitpicky. It does often lead to slowing down changes, but it also avoids the common pitfall of authoritarian regime of going head first into a wall at the speed of light.
mrob
The announcement says:
>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.
I can understand the importance of safe signature verification, but how is .deb parsing a problem? If you're installing a malicious package you've already lost. There's no need to exploit the parser when the user has already given you permission to modify arbitrary files.
Muromec
It is possible the deb package is parsed to extract some metadata before being installed and before verifying signature.
Also there is aspect of defence in depth. Maybe you can compromise one package that itself can't do much, but installer runs with higher priviledges and has network access.
Another angle -- installed package may compromise one container, while a bug in apt can compromise the environment which provisions containers.
And then at some point there is "oh..." moment when the holes in different layers align nicely to make four "bad but not exploitable" bugs into a zero day shitshow
marcosdumay
.deb is a packaging format like any other. There are plenty of reasons for parsing without running the code inside them.
scotty79
Maybe there's a place for Future Debian distro that could be a place for phasing out old tech and introducing new features?
powerclue
Or maybe old devices and tech should expect a limited support window, or be expected to fork after some time?
bakugo
[flagged]
fn-mote
> What is it about Rust fanatics [....]
The universalization from one developer's post to all Rust "fanatics" is itself an unwelcome attack. I prefer to keep my discussion as civilized as possible.
Just criticize the remark.
tbrownaw
I read that more as "here's a perfect example of something I'd noticed already" rather than "wow this is a terrible first impression your group is making".
Perhaps this reading is colored by how this same pair of sentiments seems to come up practically every single time there's a push to change the language for some project.
estimator7292
I'll stop criticising Rust fanatics when they stop trying to rewrite perfectly good code for no reason other than it isn't written in rust.
The disrespect is mutual.
jvanderbot
I think you'll experience some pushback on the assertion that that particular quote has a lot of arrogance or disdain in it.
Building large legacy projects can be difficult and tapping into a thriving ecosystem of packages might be a good thing. But it's also possible to have "shiny object" or "grass is greener" syndrome.
NetMageSCW
“If you maintain a port without a working Rust toolchain, please ensure it has one within the next 6 months, or sunset the port.”
If that’s not arrogant, I don’t know what is.
Cthulhu_
Is it arrogant or a clear and straightforward announcement that a Decision has been made and these are the consequences? I'm not seeing any arrogance in the message myself.
powerclue
How is this arrogant? Are open source developers now responsible for ensuring every fork works with the dependencies and changes they make?
This seems like a long window, given to ports to say, "we are making changes that may impact you, heads up." The options presented are, frankly, the two primary options "add the dependency or tell people you are no longer a current port".
jvanderbot
"Arrogant" does not mean "forceful" or "assertive" or "makes me angry".
This is forceful, assertive, and probably makes people angry.
Does the speaker have the authority to make this happen? Because if so, this is just a mandate and it's hard to find some kind of moral failing with a change in development direction communicated clearly.
bakugo
> I think you'll experience some pushback on the assertion that that particular quote has a lot of arrogance or disdain in it.
It's just a roundabout way of saying "anything that isn't running Rust isn't a REAL computer". Which is pretty clearly an arrogant statement, I don't see any other way of interpreting it.
simonask
Be real for a second. People are arguing against Rust because it supports fewer target architectures than GCC. Which of the target architectures do you believe if important enough that it should decide the future development of apt?
jvanderbot
I read it as a straightforward way of saying "support for a few mostly unused architectures is all that is holding us back from adopting rust, and adopting rust is viewed as a good thing"
amarant
from the outside it looks like a defense mechanism from a group of developers who have been suffering crusades against them ever since a very prolific c developer decided rust would be a good fit for this rather successful project he created in his youth.
portly
Is it the borrow checker? Normally rust had your back when it comes to memory oopsies. Maybe we need a borrow checker for empathy..
chillfox
They are the tech version of vegans.
(yes, I know it's not all of them just like not all vegans have to preach)
simonask
And just like vegans, their detractors are far more vocal in reality.
OptionX
Untrue.
kitsune1
>reality In reality everyone eats meats because it's what the human body evolved to consume. There's nothing to detract
tcfhgj
actually a vegan has to preach to some degree, otherwise it would be like a human rights advocate looking away when humans are tortured
powerclue
As a vegetarian on ethical grounds (mostly due to factory farming of meat) I politely disagree with your assessment.
I have to decline and explain in social settings all the time, because I will not eat meat served to me. But I do not need to preach when I observe others eating meat. I, like all humans, have a finite amount of time and energy. I'd rather spend that time focused on where I think it will do the greatest good. And that's rarely explaining why factory farming of meat is truly evil.
The best time is when someone asks, "why don't you eat meat?" Then you can have a conversation. Otherwise I've found it best to just quietly and politely decline, as more often than not one can be accommodated easily. (Very occasionally, though, someone feels it necessary to try and score imaginary points on you because they have some axe to grind against vegetarians and vegans. I've found it best to let them burn themselves out and move on. Life's too short to worry about them.)
Cthulhu_
That's a bit of a jump. Veganism is a personal lifestyle / dietary choice. Objecting to livestock is activism. You can do either without the other.
elteto
Maybe they are just really tired of having to deal with people who constantly object and throw every possible obstacle they can on the way.
bakugo
Maybe they wouldn't experience so much pushback if they were more humble, had more respect for established software and practices, and were more open to discussion.
You can't go around screaming "your code SUCKS and you need to rewrite it my way NOW" at everyone all the time and expect people to not react negatively.
anarki8
> You can't go around screaming "your code SUCKS and you need to rewrite it my way NOW"
It seems you are imagining things and hate people for the things you imagined.
In reality there are situations where during technical discussions some people stand up and with trembling voice start derailing these technical discussions with "arguments" like "you are trying to convince everyone to switch over to the religion". https://youtu.be/WiPp9YEBV0Q?t=1529
simonask
That’s also not something anybody has actually said.
woodruffw
To be clear, the "you" and "my" in your sentence refer to the same person. Julian appears to be the APT maintainer, so there's no compulsion except what he applies to himself.
(Maybe you mean this in some general sense, but the actual situation at hand doesn't remotely resemble a hostile unaffiliated demand against a project.)
lagniappe
The endless crusades are indeed tiresome.
donkeybeer
No, honestly Rust has just really crappy attitude and culture. Even as a person who should naturally like Rust and I do plan to learn it despite that I find these people really grating.
I remembered reading about this news back when that first message was posted on the mailing list, and didn't think much of it then (rust has been worming its way into a lot of places over the past few years, just one more thing I tack on for some automation)...
But seeing the maintainer works for Canonical, it seems like the tail (Ubuntu) keeps trying to wag the dog (Debian ecosystem) without much regard for the wider non-Ubuntu community.
I think the whole message would be more palatable if it weren't written as a decree including the dig on "retro computers", but instead positioned only on the merits of the change.
As an end user, it doesn't concern me too much, but someone choosing to add a new dependency chain to critical software plumbing does, at least slightly, if not done for very good reason.