13 ms·

APT Rust requirement raises questions

266 points by todsacerdoti 11mo ago

bakugo 11mo ago
[flagged]
- elteto 11mo ago
  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.
  - donkeybeer 11mo ago
    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.
  - bakugo 11mo ago
    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.
    - lagniappe 11mo ago
      The endless crusades are indeed tiresome.
      - bryanlarsen 11mo ago
        Yes, the immediate and endless backlash we get whenever anybody says the word "Rust" is quite tiresome.
        lagniappe 11mo ago
        Ah yes, the signature snark from the Rust community. This is the type of thing that repels people.
        bryanlarsen 11mo ago
        Most of the repelling is happening on the anti-Rust side. The hate and vitriol has chased away Wedson Almeida Filho, Alex Gaynor, Hector Martin and Christoph Hellwig from the Rust in Linux project. And it's happening here too. https://news.ycombinator.com/item?id=46048336 https://news.ycombinator.com/item?id=46048336 makes clear that most of the commentary here is just plain wrong, yet it's not upvoted to top.
        lagniappe 11mo ago
        And for each of those names there are 100 rust zealots tainting their legacy with their behavior.
    - simonask 11mo ago
      That’s also not something anybody has actually said.
      - bakugo 11mo ago
        Are you serious? It's basically impossible to discuss C/C++ anymore without someone bringing up Rust. If you search for HN posts with C++ in the title from the last year, the top post is about how C++ sucks and Rust is better. The fourth result is a post titled "C++ is an absolute blast" and the comments contain 128 (one hundred and twenty eight) mentions of the word "Rust". It's ridiculous.
        simonask 11mo ago
        Lots of current and former C++ developers are excited about Rust, so it’s natural that it comes up in similar conversations. But bringing up Rust in any conversation still does not amount to a personal attack, and I would encourage some reflection here if that is your first reaction.
      - lkjdsklf 11mo ago
        While no one has explicitly said that, it is the implied justification of rewriting so much stuff in rust
        simonask 11mo ago
        I disagree very strongly that a suggestion to change something is also a personal attack on the author of the original code. That’s not a professional or constructive attitude.
    - woodruffw 11mo ago
      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.)
      - yjftsjthsd-h 11mo ago
        > Julian appears to be the APT maintainer, so there's no compulsion except what he applies to himself. To who is this addressed? > If you maintain a port without a working Rust toolchain, please ensure it has one within the next 6 months, or sunset the port. Because that sure reads as a compulsion to me.
    - anarki8 11mo ago
      > 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 https://youtu.be/WiPp9YEBV0Q?t=1529
- jvanderbot 11mo ago
  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.
  - bakugo 11mo ago
    > 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 11mo ago
      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?
      - bakugo 11mo ago
        I won't be real for a second, because this isn't about that. Arguing that support for certain architectures should be removed because they see very little real world use is totally valid. But it's possible to do so in a respectful way, without displaying such utter contept for anyone who might disagree.
    - jvanderbot 11mo ago
      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"
  - NetMageSCW 11mo ago
    “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.
- chillfox 11mo ago
  [flagged]
  - simonask 11mo ago
    And just like vegans, their detractors are far more vocal in reality.
    - kitsune1 11mo ago
      >reality In reality everyone eats meats because it's what the human body evolved to consume. There's nothing to detract
    - OptionX 11mo ago
      Untrue.
      - yoyohello13 11mo ago
        As evidenced by this very comment chain. I've seen, by far, way more comment from people annoyed by vegans. I can't even remember the last time I've heard a vegan discuss it outside of just stating the food preference when we got out to eat.
        OptionX 11mo ago
        If I don't see it it doesn't happen is the definition of anedoctal.
        yoyohello13 11mo ago
        Why is your anecdote more valid than mine?
  - tcfhgj 11mo ago
    actually a vegan has to preach to some degree, otherwise it would be like a human rights advocate looking away when humans are tortured
- fn-mote 11mo ago
  > 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.
  - estimator7292 11mo ago
    [flagged]
  - tbrownaw 11mo ago
    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.
- portly 11mo ago
  Is it the borrow checker? Normally rust had your back when it comes to memory oopsies. Maybe we need a borrow checker for empathy..
- amarant 11mo ago
  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.
petcat 11mo ago
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.
- sidewndr46 11mo ago
  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 11mo ago
    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 11mo ago
      > 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?
      - adwn 11mo ago
        For one, signed integer overflow is allowed and well-defined in Rust (the result simply wraps around in release builds), while it's Undefined Behavior in C. This means that the LLVM IR emitted by the Rust compiler for signed integer arithmetic can't be directly translated into the analogous C code, because that would change the semantics of the program. There are ways around this and other issues, but they aren't necessarily simple, efficient, and portable all at once.
geerlingguy 11mo ago
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.
- reidrac 11mo ago
  > 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.
  - Onavo 11mo ago
    > Canonical paying Devs and all, it isn't a great way of influencing a community. That's kind of the point of modern open source organizations. Let corporations fund the projects, and in exchange they get a say in terms of direction, and hopefully everything works out. The bigger issue with Ubuntu is that they lack vision, and when they ram things through, they give up at the slightest hint of opposition (and waste a tremendous amount of resources and time along the way). For example Mir and Unity were perfectly fine technologies but they retired it because they didn't want to see things through. For such a successful company, it's surprising that there technical direction setting is so unserious. https://www.reddit.com/r/linux/comments/15brwi0/why_canonical_projects_except_ubuntu_failed_to/ https://www.reddit.com/r/linux/comments/15brwi0/why_canonica...
  - tremon 11mo ago
    I agree. It's sad to see maintainers take a "my way or the highway" approach to package maintenance, but this attitude has gradually become more accepted in Debian over the years. I've seen this play before, with different actors: gcc maintainers (regarding cross-bootstrapping ports), udev (regarding device naming, I think?), systemd (regarding systemd), and now with apt. Not all of them involved Canonical employees, and sometimes the Canonical employees were the voice of reason (e.g. that's how I remember Steve Langasek). I'm sure some will point out that each example above was just an isolated incident, but I perceive a growing pattern of incidents. There was a time when Debian proudly called itself "The Universal Operating System", but I think that hasn't been true for a while now.
maeln 11mo ago
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.
- cogman10 11mo ago
  What? Opensource software doesn't have 1 governance model and most of it starts out as basically a pure authoritarian run. It's only as the software ages, grows, and becomes more integral that it switches to more democratic forms of maintenance. Even then, the most important OS code on the planet, the kernel, is basically a monarchy with King Linus holding absolute authority to veto the decision of any of the Lords. Most stuff is maintained by the Lords but if Linus says "no" or "yes" then there's no parliament which can override his decision (beyond forking the kernel).
fn-mote 11mo ago
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.
- stonemetal12 11mo ago
  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 11mo ago
    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.
  - mikepurvis 11mo ago
    Historically apt hasn't had much of a "solver". It's basically take the user's upgrade/install action, if there's some conflict or versioned requirement, go to the candidate (≈newest barring pinfile shenanigans) of the involved packages, and if there's still a conflict, bail. It was always second-tier utilities like Aptitude that tried to search for a "solution" to conflicting packaging constraints, but this has always been outside of the core functionality, and if you accepted one of Aptitude's proposed paths, you would do so knowing that the next apt dist-upgrade was almost certainly going to hose everything again. I think the idea in Apt-world is that it's the responsibility of the archive maintainer to at all times present a consistent index for which the newest versions of everything can coexist happily together. But this obviously breaks down when multiple archives are active on the same apt conf.
dv35z 11mo ago
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.
- tcfhgj 11mo ago
  what makes it unreadable for you?
  - deleted 11mo ago
    [deleted]
  - forgotpwd16 11mo ago
    Legit question really. A comparative study on language readability using codes doing the same thing written idiomatically in different languages will be interesting. Beyond syntax, idioms/paradigm/familiarity should also play role.
  - thousand_nights 11mo ago
    nta you're replying to, but as someone who doesn't know rust, on first glance it seems like it's littered with too many special symbols and very verbose. as i understand it this is required because of the very granular low level control rust offers maybe unreadable is too strong of a word, but there is a valid point of it looking unapproachable to someone new
    - yoyohello13 11mo ago
      People often misuse unreadable when they mean unfamiliar. Rust really isn't that difficult to read when you get used to it.
mrob 11mo ago
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 11mo ago
  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
  - SAI_Peregrinus 11mo ago
    > It is possible the deb package is parsed to extract some metadata before being installed and before verifying signature. Yes, .deb violates the cryptographic doom principle[1] (if you have to perform any cryptographic operation before verifying the message authentication code (or signature) on a message you’ve received, it will somehow inevitably lead to doom). Their signed package formats (there are two) add extra sections to the `ar` archive for the signature, so they have to parse the archive metadata & extract the contents before validating the signature. This gives attackers a window to try to exploit this parsing & extraction code. Moving this to Rust will make attacks harder, but the root cause is a file format violating the cryptographic doom principle. [1] https://moxie.org/2011/12/13/the-cryptographic-doom-principle.html https://moxie.org/2011/12/13/the-cryptographic-doom-principl...
    - move-on-by 11mo ago
ChrisArchitect 11mo ago
Related: Hard Rust requirements from May onward https://news.ycombinator.com/item?id=45779860 https://news.ycombinator.com/item?id=45779860
scotty79 11mo ago
Maybe there's a place for Future Debian distro that could be a place for phasing out old tech and introducing new features?
- powerclue 11mo ago
  Or maybe old devices and tech should expect a limited support window, or be expected to fork after some time?
  - ForHackernews 11mo ago
    It sounds like all of the affected Debian ports are long since diverged from the official Debian releases anyway: > The sh4 port has never been officially supported, and none of the other ports have been supported since Debian 6.0. Wikipedia tells me Debian 6 was released on 6 February 2011
  - yjftsjthsd-h 11mo ago
    Some of us abandoned commercial OSs for Debian precisely to escape that mentality.
    - powerclue 11mo ago
      I think that's reasonable, but surely there's a limit? Like, if one user exists on an old piece of tech, does Debian need to support them forever? I think this is a nuanced call, personally, and I think there's some room for disagreements here. I just happen to believe that maybe the right decision is to fork at some point and spin off legacy forks when there's a vanishingly small suite of things that cause friction with progress.
      - yjftsjthsd-h 11mo ago
        That's fair. There's even precedent in the form of e.g. https://archlinux32.org/ https://archlinux32.org/ , though I personally view that kind of fracturing as undesirable. Personally I'd rather lean the other way; if folks want to be forward-thinking at the expense of breaking compatibility, they could just go work on Fedora or Arch or any other distro that wants to be the future instead of "the universal operating system". In this particular case, though, I would specifically argue that it's a poor trade-off; AIUI, the whole thing comes down to a tiny bit of functionality that shouldn't even be in core apt, that is of little use to most of the community, and that really should be factored out into an optional additional package anyways, at which point it need not affect less popular ports.
leoh 11mo ago
I hate learning new things. It sucks. Also, I hate things that make my knowledge of C++ obsolete. I hate all the people that are getting good at rust and are threatening to take away my job. I hate that rust is a great leveler, making all my esoteric knowledge of C++ that I have been able to lord over others irrelevant. I hate that other people are allowed to do this to me and to do whatever they want, like making the decision to use rust in apt. It’s just sad and crazy to me. I can’t believe it. There are lots of people like me who are scared and angry and we should be able to control anyone else who makes us feel this way. Wow, I’m upset. I hope there is another negative post about rust I can upvote soon.
- Havoc 11mo ago
  Think tech space isn’t for you if you hate learning new things.
  - stodor89 11mo ago
    It's sarcasm.
- tucnak 11mo ago
  Can you confirm these C++ fascists you speak of are in the room with you right now?
- malcolmgreaves 11mo ago
  Nice /s
- temptemptemp111 11mo ago
  [dead]
- leoh 11mo ago
  https://en.wikipedia.org/wiki/Poe%27s_law https://en.wikipedia.org/wiki/Poe%27s_law
gorgoiler 11mo ago
”[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 it 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 It’s like arguing about the bike shed when everyone takes the bus except for one guy who cycles in every four weeks to clean the windows.
- rrmm 11mo ago
  If this could be done it seems like the ideal compromise. Everyone gets what they want. That said eventually more modern languages will be dependencies of the tools one way or another (and they should). So probably Debian as a whole should come to a consensus on how that should happen, so it can happen in some sort of standard and fair fashion.
GuB-42 11mo ago
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.
dathinab 11mo ago
Why is this still a discussion? > was no room for a change in plan yes, pretty much at least the questions about it breaking unofficial distros, mostly related to some long term discontinued architectures, should never affect how a Distro focused on current desktop and server usage develops. if you have worries/problems outside of unsupported things breaking then it should be obvious that you can discuss them, that is what the mailing list is for, that is why you announce intend beforehand instead of putting things in the change log > complained that Klode's wording was unpleasant and that the approach was confrontational its mostly just very direct communication, in a professional setting that is preferable IMHO, I have seen too much time wasted due to misunderstandings due to people not saying things directly out of fear to offend someone through he still could have done better > also questioned the claim that Rust was necessary to achieve the stronger approach to unit testing that Klode mentioned: given the focus on Sequoia in the mail, my interpretation was that this is less about writing unit tests, and more about using some AFIK very well tested dependencies, but even when it comes to writing code out of experience the ease with which you can write tests hugely affects how much it's done, rust makes it very easy and convenient to unit test everything all the time. That is if we speak about unit tests, other tests are still nice but not quite at the same level of convenience. > "currently has problems with rebuilding packages of types that systematically use static linking" that seems like a _huge_ issue even outside of rust, no reliable Linux distros should have problems with reliable rebuilding things after security fixes, no matter how it's linked if I where to guess there this might be related to how the lower levels of dependency management on Linux is quite a mess due to requirements from 90 no longer relevant today, but which some people still obsess over. To elaborate (sorry for the wall of text) you can _roughly_ fit all dependencies of a application (app) into 3 categories: 1. programs the system provides (opt.) called by the app (e.g. over ipc, or spawning a sub process), communicating over well defined non language specific protocols. E.g. most cmd-line tools, or you systems file picker/explorer should be invoked like that (that it often isn't is a huge annoyance). 2. programs the system needs to provide, called using a programming language ABI (Application Binary Interface, i.e. mostly C ABI, can have platform dependent layout/encoding) 3. code reused to not rewrite everything all the time, e.g. hash maps, algorithms etc. The messy part in Linux is that for historic reasons the later two parts where not treated differently even through they have _very_ different properties wrt. the software live cycle. For the last category they are for your code and specific use case only! The supported versions usable with your program are often far more limited: Breaking changes far more normal; LTO is often desirable or even needed; Other programs needing different incompatible versions is the norm; Even versions with security vulnerabilities can be fine _iff_ the vulnerabilities are on code paths not used by your application; etc. The fact that Linux has a long history of treating them the same is IMHO a huge fuck up. It made sense in the 90th. It doesn't anymore since ~20 years. It's just completely in conflict with how software development works in practice and this has put a huge amount of strain on OSS maintainers, due to stuff like distros shipping incompatible versions potentially by (even incorrectly) patching your code.... and end users blaming you for it. IMHO Linux should have a way to handle such application specific dependencies in a all cases from scripting dependencies (e.g. python), over shared object to static linking (which doesn't need any special handling outside of the build tooling). People have estimated the storage size difference of linking everything statically, and AFIK it's irrelevant in relation to availability and pricing on modern systems. And the argument that you might want to use a patched version of a dependency "for security" reasons fails if we consider that this has lead to security incidents more then one time. Most software isn't developed to support this at all and bugs can be subtle and bad to a point of a RCE. And yes there are special cases, and gray areas in between this categories. E.g. dependencies in the 3rd category you want to be able to update independently, or dependencies from the 2nd which are often handled like the 3rd for various piratical reasons etc. Anyway coming back the the article Rust can handle dynamic linking just fine, but only for C ABI as of now. And while rust might get some form of RustABI to make dynamic linking better it will _never_ handle it for arbitrary libraries, as that is neither desirable nor technical possible. --- EDIT: Just for context, in case of C you also have to rebuild all header only libraries using pre-processor macros, not doing so is risky as you now mix different versions of the same software in one build. Same (somewhat) for C++ with anything using template libraries. The way you can speed it up is by caching intermediate build artifacts, that works for rust, too.
theoldgreybeard 11mo ago
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/discussions in small hobby projects I released as open source - I just ban them immediately because there is no reasoning with them and they never give up. Open source terrorists.
- tucnak 11mo ago
  "Open source terrorism" is a hilarious designation for Rust-like traditions and customs. I wonder what other programming language/software communities may fall under this definition?
- aeve890 11mo ago
  Username checks out. >Open source terrorists Rust users and evangelism rubs me the wrong way. Yes it's safe, yes it's ergonomic but why the weird aura around the people that insist in "Rewrite it in Rust, Deus Vult"? It eludes me.
koakuma-chan 11mo ago
[dead]
monegator 11mo ago
Sometimes you do wonder if those 4chan memes about those who push rust rewrites are just memes or what..
- steveklabnik 11mo ago
  A maintainer of a project making a decision about their project is not someone pushing a re-write.
tyfon 11mo ago
I have a dual pentium pro 200 that runs gentoo and openbsd, but rust doesn't ship i586 binaries, only i686+. So I would need to compile on a separate computer to use any software that is using rust. There is already an initrd package tool I can't use since it is rust based, but I don't use initrd on that machine so it is not a problem so far. The computer runs modern linux just fine, I just wish the rust team would at least release an "i386" boostrap binary that actually works on all i386 like all of the other compilers. "We don't care about retro computers" is not a good argument imho, especially when there is an easy fix. It was the same when the Xorg project patched out support for RAMDAC and obsoleted a bunch of drivers instead of fixing it easily. I had to fix the S3 driver myself to be able to use my S3 trio 64v+ with a new Xorg server. /rant off
- ondra 11mo ago
  Pentium Pro is the first i686 CPU, so you should be fine.
- ForHackernews 11mo ago
  I mean... Pentium Pro is 30 years old at this point. I don't think it's unreasonable that modern software isn't targeting those machines.
  - yjftsjthsd-h 11mo ago
    So anyways, here's the netbsd docs for running the latest release on VAX: https://wiki.netbsd.org/ports/vax/ https://wiki.netbsd.org/ports/vax/
    - ForHackernews 11mo ago
      Obscure retro OS runs on obscure retro hardware you say?
      - yjftsjthsd-h 11mo ago
        NetBSD isn't a retro OS, nor is it particularly obscure. (For that matter, VAX isn't obscure, though it's very retro.)
MisterTea 11mo ago
""and not be held back by trying to shoehorn modern software on retro computing devices"" Nice. So discrimination of poor users who are running "retro" machines because that is the best they can afford or acquire. I knew of at least two devs who are stuck with older 32 bit machines as that is what they can afford/obtain. I even offered to ship them a spare laptop with a newer CPU and they said thanks but import duties in their country would be unaffordable. Thankfully they are also tinkering with 9front which has little to no issues with portability and still supports 32 bit.
- aaronblohowiak 11mo ago
  Rust works fine on 32 bit, (and 16 bit) that’s not what they mean…
  - quux 11mo ago
    Rust even works on 8-bit via the LLVM-MOS backend for MOS 6502 :)
- chc4 11mo ago
  No one is using an Alpha, Motorola 680x0, PA-RISC, or SuperH computer because that's the only thing they can afford. Rust supports 32bit x86.
- quux 11mo ago
  Looking at the list of affected architectures: Alpha (alpha), Motorola 680x0 (m68k), PA-RISC (hppa), and SuperH (sh4) I think these are much much more likely to be run by enthusiasts than someone needing an affordable computer.
- cogman10 11mo ago
  The last 32bit laptop CPU was produced nearly 20 years ago. Further, there are still several LTS linux distros (including the likes of Ubuntu and Debian) which don't have the rust requirement and won't until the next LTS. 24.04 is supported until 2029. Meaning you are talking about a 25 year old CPU at that point. And even if you continue to need support. Debian based distros aren't the only ones on the plant. You can pick something else if it really matters.
ethin 11mo ago
This is just one reason I'm not the biggest fan of Rust. The language is good (as well as what it solves), but this tendency to force it into everything (even where it would provide no benefit whatsoever) is just mind-boggling to me. And the Rust evangelists then wonder why there are so many anti-rust folk.
creatonez 11mo ago
I have never seen a program segfault and crash more than apt. The status quo is extremely bad, and it desperately needs to be revamped in some way. Targeted rewrites in a memory safe & less mistake-prone language sounds like a great way to do that. If you think this is a random decision caused by hype, cargo culting, or a maintainer's/canonical's mindless whims... please, have a tour through the apt codebase some day. It is a ticking time bomb, way more than you ever imagined such an important project would be.
- sherr 11mo ago
  I've been using apt regularly on Debian for a long time and never seen it crash or segfault. Very strange that you do. All software has bugs of course, but apt is so heavily used that I expect it gets attention. It just works for me.
  - dontlaugh 11mo ago
    I’ve seen in segfault once. I don’t know how common that is, but it would be nice to make that less likely.
- pmarin 11mo ago
  20 years on Debian. Not a single crash with apt
  - roryirvine 11mo ago
    Almost 30 years for me, both on my personal machines and at work. I went through a period about 25 years ago where apt crashed on my (rather janky) desktop almost every other run, and sometimes left my system in a state so inconsistent that I had to fall back on 'dpkg-reconfigure --force' and the like to fix it. Turns out that it was due to a bad interaction between a failing stick of RAM and reiserfs' tail-packing feature, which was causing frequent silent corruption in /var/lib/dpkg/status and friends. I don't think I've seen any similar issues since, across what must be many millions of apt runs I've been responsible for. Perhaps gp is suffering from some similar underlying problem?
ekjhgkejhgk 11mo ago
This thing gets everywhere.
phkahler 11mo ago
I don't think programs should use mixed languages if its at all avoidable. Linux would be an exception because I think it can benefit from oxidation and it'll be decades before RedoxOS is ready.
renewiltord 11mo ago
Overall, I think Rust is probably too dangerous to introduce into core software. Every time there is a donation to the Rust Foundation, the Rust community is in an uproar that it is not a large enough fraction of gross revenue. Linux, apt, are all currently both free as in speech and free as in beer. If we have to start donating to the Rust Foundation a percentage of gross revenue for every tool that we use written in Rust, it will cost a lot. Probably much better to just not put Rust in the kernel or in apt. It's a Trojan horse language. There are no demands from C users that anyone donate to C non-profits. Much better, safer language to use from an ecosystem perspective.
- steveklabnik 11mo ago
  > Every time there is a donation to the Rust Foundation, the Rust community is in an uproar that it is not a large enough fraction of gross revenue. Where are you seeing this happen? I'm curious because I never have, which means that I'm missing out on discussions somewhere.
  - renewiltord 11mo ago
    Sure, it's on Reddit /r/rust. I'll provide links at the end, but it happens every time there is a donation. > > > Multi trillion dollar conglomerate invests a minuscule fraction of a fraction of their monthly revenue into the nonprofit foundation that maintains the tool that will save them billions > > 115 Billion / 365 days / 1440 minutes = ~ 220k > > So they make around 220k per minute, 350k in under 2 minutes. Still, any amount is better than nothing at all. > I genuinely hate the thought of "Better than nothing". We should be saying "go big or go home." Pretty popular thread. Approximate 900 upvotes over those three comments. > That's like a millisecond of Google revenue. and separately > I mean thats nice. But in all honesty, is 1 Million still a lot? That's from a while ago so it's smaller. But you can tell the sentiment is rising because these expressions of "it's not enough" are becoming more popular. Just a matter of time before the community tries to strong-arm other orgs with boycotts and this and that. We've seen this before. > > Cool, but also depressing how relatively small these “huge” investments in core technologies actually are. > Yeah, seriously. This is comparatively like me leaving a penny in the “take a penny leave a penny” plate at the gas station. and separately > Ah yes, the confidence displayed by allocating 0.0004% of your yearly revenue. > Satya alone earns that in a 40 hr work week. It's a pretty old playbook to use free-software language to get one's technology entrenched, then there's murmurs about how not enough money is being sent back to the people making it, the organization then uses the community as the stalking horse to promote this theory, and then finally comes the Elastic License relicensing. Elastic did it. MongoDB did it. Hashicorp did it. Redis did it. I get the idea, but we should pre-empt the trojan horse when we see it coming. I know I know. You can fork when it happens etc. but I'm not looking forward to switching my toolchain to "Patina" or whatever they call the fork. And if you think I'm some guy with an axe to grind, I have receipts for Rustlang enthusiasm: https://news.ycombinator.com/item?id=24127438 https://news.ycombinator.com/item?id=24127438 https://news.ycombinator.com/item?id=24328686 https://news.ycombinator.com/item?id=24328686 https://news.ycombinator.com/item?id=30756184 https://news.ycombinator.com/item?id=30756184 https://news.ycombinator.com/item?id=37573389 https://news.ycombinator.com/item?id=37573389 https://news.ycombinator.com/item?id=41639619 https://news.ycombinator.com/item?id=41639619 List of donation posts follows: https://old.reddit.com/r/rust/comments/1noyqak/media_google_continues_to_invest_350k_in_rust/nfvf6mc/ https://old.reddit.com/r/rust/comments/1noyqak/media_google_... https://old.reddit.com/r/rust/comments/1ajm56w/google_donates_1m_to_the_rust_foundation_to/ https://old.reddit.com/r/rust/comments/1ajm56w/google_donate... https://old.reddit.com/r/rust/comments/1cnehqt/microsofts_1m_vote_of_confidence_in_rusts_future/ https://old.reddit.com/r/rust/comments/1cnehqt/microsofts_1m...
leo_e 11mo ago
As someone fighting the C++ toolchain daily, there is a painful irony in seeing APT—the tool supposed to solve dependency hell—creating its own dependency crisis. I sympathize with the maintainers of retro hardware. But honestly? Holding back the security and maintainability of a modern OS base layer just so an AlphaStation from 1998 can boot feels backwards. The transition pain is real, and Canonical handled the communication poorly. But the 'legacy C tax' is eternal. We have to move critical infrastructure off it eventually.
major505 11mo ago
IS funny because thanks to efforts from companies like Valve, Linux seens to finally been receiving the recognition it deserves, Rust evangelists and weirdos who claim morality superiority to the rest of mortals, are going to put everything to loose, because of this obsession of rewriting tools that actually work for many years without bigger issues, just so they can say their language is superior. IF there was some glaring problems with tools like sudo, sort, apt, and you have a superior version, sure, go ahead. But this is clearly not the case. Sometimes the rust version is just the same, or even inferior, but people are ready to plunge into destruction just to say their distro have the latest and greatest. Its just vanity. Maybe the conspiracy theories that big tech finance the crazy incopetent people from in position of power in open source projects that they no longer can compete, in order to destroy them from the inside, is not that far fetched.
Surac 11mo ago
my biggest problem with rust is. i can't read it. i never know what this symbol means. is it a keyword? a type, a variable, a constant or a macro? Sure loading it into a IDE with a language server may help understanding the code.
- xiej 11mo ago
  There are only a few common keywords. Types are PascalCase. Variables are snake_case. constants are SCREAMING_CASE. macros have an exclamation point !
- pornel 11mo ago
  That's just your lack of familiarity with the foreign-to-you language (you may be unable to read Korean too, despite Korean being pretty readable). Syntactically, Rust is pretty unambiguous, especially compared to C-style function and variable definitions. You get fn and let keywords, and definitions that are generally read left-to-right, instead of starting with an arbitrary identifier that may be a typedef, a preprocessor macro, or part of a type that is read in so-called "spiral" order (which isn't even a spiral, but more complex than than).
BDMug 11mo ago
[dead]

266 points by todsacerdoti 11mo ago

bakugo 11mo ago

[flagged]

elteto 11mo ago
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.
- donkeybeer 11mo ago
  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.
- bakugo 11mo ago
  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.
  - lagniappe 11mo ago
    The endless crusades are indeed tiresome.
    - bryanlarsen 11mo ago
      Yes, the immediate and endless backlash we get whenever anybody says the word "Rust" is quite tiresome.
      - lagniappe 11mo ago
        Ah yes, the signature snark from the Rust community. This is the type of thing that repels people.
        bryanlarsen 11mo ago
        Most of the repelling is happening on the anti-Rust side. The hate and vitriol has chased away Wedson Almeida Filho, Alex Gaynor, Hector Martin and Christoph Hellwig from the Rust in Linux project. And it's happening here too. https://news.ycombinator.com/item?id=46048336 https://news.ycombinator.com/item?id=46048336 makes clear that most of the commentary here is just plain wrong, yet it's not upvoted to top.
        lagniappe 11mo ago
        And for each of those names there are 100 rust zealots tainting their legacy with their behavior.
  - simonask 11mo ago
    That’s also not something anybody has actually said.
    - bakugo 11mo ago
      Are you serious? It's basically impossible to discuss C/C++ anymore without someone bringing up Rust. If you search for HN posts with C++ in the title from the last year, the top post is about how C++ sucks and Rust is better. The fourth result is a post titled "C++ is an absolute blast" and the comments contain 128 (one hundred and twenty eight) mentions of the word "Rust". It's ridiculous.
      - simonask 11mo ago
        Lots of current and former C++ developers are excited about Rust, so it’s natural that it comes up in similar conversations. But bringing up Rust in any conversation still does not amount to a personal attack, and I would encourage some reflection here if that is your first reaction.
    - lkjdsklf 11mo ago
      While no one has explicitly said that, it is the implied justification of rewriting so much stuff in rust
      - simonask 11mo ago
        I disagree very strongly that a suggestion to change something is also a personal attack on the author of the original code. That’s not a professional or constructive attitude.
  - woodruffw 11mo ago
    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.)
    - yjftsjthsd-h 11mo ago
      > Julian appears to be the APT maintainer, so there's no compulsion except what he applies to himself. To who is this addressed? > If you maintain a port without a working Rust toolchain, please ensure it has one within the next 6 months, or sunset the port. Because that sure reads as a compulsion to me.
  - anarki8 11mo ago
    > 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 https://youtu.be/WiPp9YEBV0Q?t=1529
jvanderbot 11mo ago
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.
- bakugo 11mo ago
  > 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 11mo ago
    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?
    - bakugo 11mo ago
      I won't be real for a second, because this isn't about that. Arguing that support for certain architectures should be removed because they see very little real world use is totally valid. But it's possible to do so in a respectful way, without displaying such utter contept for anyone who might disagree.
  - jvanderbot 11mo ago
    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"
- NetMageSCW 11mo ago
  “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.
chillfox 11mo ago
[flagged]
- simonask 11mo ago
  And just like vegans, their detractors are far more vocal in reality.
  - kitsune1 11mo ago
    >reality In reality everyone eats meats because it's what the human body evolved to consume. There's nothing to detract
  - OptionX 11mo ago
    Untrue.
    - yoyohello13 11mo ago
      As evidenced by this very comment chain. I've seen, by far, way more comment from people annoyed by vegans. I can't even remember the last time I've heard a vegan discuss it outside of just stating the food preference when we got out to eat.
      - OptionX 11mo ago
        If I don't see it it doesn't happen is the definition of anedoctal.
        yoyohello13 11mo ago
        Why is your anecdote more valid than mine?
- tcfhgj 11mo ago
  actually a vegan has to preach to some degree, otherwise it would be like a human rights advocate looking away when humans are tortured
fn-mote 11mo ago
> 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.
- estimator7292 11mo ago
  [flagged]
- tbrownaw 11mo ago
  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.
portly 11mo ago
Is it the borrow checker? Normally rust had your back when it comes to memory oopsies. Maybe we need a borrow checker for empathy..
amarant 11mo ago
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.

petcat 11mo ago

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.

sidewndr46 11mo ago
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 11mo ago
  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 11mo ago
    > 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?
    - adwn 11mo ago
      For one, signed integer overflow is allowed and well-defined in Rust (the result simply wraps around in release builds), while it's Undefined Behavior in C. This means that the LLVM IR emitted by the Rust compiler for signed integer arithmetic can't be directly translated into the analogous C code, because that would change the semantics of the program. There are ways around this and other issues, but they aren't necessarily simple, efficient, and portable all at once.

geerlingguy 11mo ago

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.

reidrac 11mo ago
> 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.
- Onavo 11mo ago
  > Canonical paying Devs and all, it isn't a great way of influencing a community. That's kind of the point of modern open source organizations. Let corporations fund the projects, and in exchange they get a say in terms of direction, and hopefully everything works out. The bigger issue with Ubuntu is that they lack vision, and when they ram things through, they give up at the slightest hint of opposition (and waste a tremendous amount of resources and time along the way). For example Mir and Unity were perfectly fine technologies but they retired it because they didn't want to see things through. For such a successful company, it's surprising that there technical direction setting is so unserious. https://www.reddit.com/r/linux/comments/15brwi0/why_canonical_projects_except_ubuntu_failed_to/ https://www.reddit.com/r/linux/comments/15brwi0/why_canonica...
- tremon 11mo ago
  I agree. It's sad to see maintainers take a "my way or the highway" approach to package maintenance, but this attitude has gradually become more accepted in Debian over the years. I've seen this play before, with different actors: gcc maintainers (regarding cross-bootstrapping ports), udev (regarding device naming, I think?), systemd (regarding systemd), and now with apt. Not all of them involved Canonical employees, and sometimes the Canonical employees were the voice of reason (e.g. that's how I remember Steve Langasek). I'm sure some will point out that each example above was just an isolated incident, but I perceive a growing pattern of incidents. There was a time when Debian proudly called itself "The Universal Operating System", but I think that hasn't been true for a while now.

maeln 11mo ago

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.

cogman10 11mo ago
What? Opensource software doesn't have 1 governance model and most of it starts out as basically a pure authoritarian run. It's only as the software ages, grows, and becomes more integral that it switches to more democratic forms of maintenance. Even then, the most important OS code on the planet, the kernel, is basically a monarchy with King Linus holding absolute authority to veto the decision of any of the Lords. Most stuff is maintained by the Lords but if Linus says "no" or "yes" then there's no parliament which can override his decision (beyond forking the kernel).

fn-mote 11mo ago

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.

stonemetal12 11mo ago
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 11mo ago
  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.
- mikepurvis 11mo ago
  Historically apt hasn't had much of a "solver". It's basically take the user's upgrade/install action, if there's some conflict or versioned requirement, go to the candidate (≈newest barring pinfile shenanigans) of the involved packages, and if there's still a conflict, bail. It was always second-tier utilities like Aptitude that tried to search for a "solution" to conflicting packaging constraints, but this has always been outside of the core functionality, and if you accepted one of Aptitude's proposed paths, you would do so knowing that the next apt dist-upgrade was almost certainly going to hose everything again. I think the idea in Apt-world is that it's the responsibility of the archive maintainer to at all times present a consistent index for which the newest versions of everything can coexist happily together. But this obviously breaks down when multiple archives are active on the same apt conf.

dv35z 11mo ago

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.

tcfhgj 11mo ago
what makes it unreadable for you?
- deleted 11mo ago
  [deleted]
- forgotpwd16 11mo ago
  Legit question really. A comparative study on language readability using codes doing the same thing written idiomatically in different languages will be interesting. Beyond syntax, idioms/paradigm/familiarity should also play role.
- thousand_nights 11mo ago
  nta you're replying to, but as someone who doesn't know rust, on first glance it seems like it's littered with too many special symbols and very verbose. as i understand it this is required because of the very granular low level control rust offers maybe unreadable is too strong of a word, but there is a valid point of it looking unapproachable to someone new
  - yoyohello13 11mo ago
    People often misuse unreadable when they mean unfamiliar. Rust really isn't that difficult to read when you get used to it.

mrob 11mo ago

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 11mo ago
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
- SAI_Peregrinus 11mo ago
  > It is possible the deb package is parsed to extract some metadata before being installed and before verifying signature. Yes, .deb violates the cryptographic doom principle[1] (if you have to perform any cryptographic operation before verifying the message authentication code (or signature) on a message you’ve received, it will somehow inevitably lead to doom). Their signed package formats (there are two) add extra sections to the `ar` archive for the signature, so they have to parse the archive metadata & extract the contents before validating the signature. This gives attackers a window to try to exploit this parsing & extraction code. Moving this to Rust will make attacks harder, but the root cause is a file format violating the cryptographic doom principle. [1] https://moxie.org/2011/12/13/the-cryptographic-doom-principle.html https://moxie.org/2011/12/13/the-cryptographic-doom-principl...
  - move-on-by 11mo ago

ChrisArchitect 11mo ago

Related: Hard Rust requirements from May onward https://news.ycombinator.com/item?id=45779860 https://news.ycombinator.com/item?id=45779860

scotty79 11mo ago

Maybe there's a place for Future Debian distro that could be a place for phasing out old tech and introducing new features?

powerclue 11mo ago
Or maybe old devices and tech should expect a limited support window, or be expected to fork after some time?
- ForHackernews 11mo ago
  It sounds like all of the affected Debian ports are long since diverged from the official Debian releases anyway: > The sh4 port has never been officially supported, and none of the other ports have been supported since Debian 6.0. Wikipedia tells me Debian 6 was released on 6 February 2011
- yjftsjthsd-h 11mo ago
  Some of us abandoned commercial OSs for Debian precisely to escape that mentality.
  - powerclue 11mo ago
    I think that's reasonable, but surely there's a limit? Like, if one user exists on an old piece of tech, does Debian need to support them forever? I think this is a nuanced call, personally, and I think there's some room for disagreements here. I just happen to believe that maybe the right decision is to fork at some point and spin off legacy forks when there's a vanishingly small suite of things that cause friction with progress.
    - yjftsjthsd-h 11mo ago
      That's fair. There's even precedent in the form of e.g. https://archlinux32.org/ https://archlinux32.org/ , though I personally view that kind of fracturing as undesirable. Personally I'd rather lean the other way; if folks want to be forward-thinking at the expense of breaking compatibility, they could just go work on Fedora or Arch or any other distro that wants to be the future instead of "the universal operating system". In this particular case, though, I would specifically argue that it's a poor trade-off; AIUI, the whole thing comes down to a tiny bit of functionality that shouldn't even be in core apt, that is of little use to most of the community, and that really should be factored out into an optional additional package anyways, at which point it need not affect less popular ports.

leoh 11mo ago

I hate learning new things. It sucks. Also, I hate things that make my knowledge of C++ obsolete. I hate all the people that are getting good at rust and are threatening to take away my job. I hate that rust is a great leveler, making all my esoteric knowledge of C++ that I have been able to lord over others irrelevant. I hate that other people are allowed to do this to me and to do whatever they want, like making the decision to use rust in apt. It’s just sad and crazy to me. I can’t believe it. There are lots of people like me who are scared and angry and we should be able to control anyone else who makes us feel this way. Wow, I’m upset. I hope there is another negative post about rust I can upvote soon.

Havoc 11mo ago
Think tech space isn’t for you if you hate learning new things.
- stodor89 11mo ago
  It's sarcasm.
tucnak 11mo ago
Can you confirm these C++ fascists you speak of are in the room with you right now?
malcolmgreaves 11mo ago
Nice /s
temptemptemp111 11mo ago
[dead]
leoh 11mo ago
https://en.wikipedia.org/wiki/Poe%27s_law https://en.wikipedia.org/wiki/Poe%27s_law

gorgoiler 11mo ago

”[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 it 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 It’s like arguing about the bike shed when everyone takes the bus except for one guy who cycles in every four weeks to clean the windows.

rrmm 11mo ago
If this could be done it seems like the ideal compromise. Everyone gets what they want. That said eventually more modern languages will be dependencies of the tools one way or another (and they should). So probably Debian as a whole should come to a consensus on how that should happen, so it can happen in some sort of standard and fair fashion.

GuB-42 11mo ago

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.

dathinab 11mo ago

Why is this still a discussion? > was no room for a change in plan yes, pretty much at least the questions about it breaking unofficial distros, mostly related to some long term discontinued architectures, should never affect how a Distro focused on current desktop and server usage develops. if you have worries/problems outside of unsupported things breaking then it should be obvious that you can discuss them, that is what the mailing list is for, that is why you announce intend beforehand instead of putting things in the change log > complained that Klode's wording was unpleasant and that the approach was confrontational its mostly just very direct communication, in a professional setting that is preferable IMHO, I have seen too much time wasted due to misunderstandings due to people not saying things directly out of fear to offend someone through he still could have done better > also questioned the claim that Rust was necessary to achieve the stronger approach to unit testing that Klode mentioned: given the focus on Sequoia in the mail, my interpretation was that this is less about writing unit tests, and more about using some AFIK very well tested dependencies, but even when it comes to writing code out of experience the ease with which you can write tests hugely affects how much it's done, rust makes it very easy and convenient to unit test everything all the time. That is if we speak about unit tests, other tests are still nice but not quite at the same level of convenience. > "currently has problems with rebuilding packages of types that systematically use static linking" that seems like a _huge_ issue even outside of rust, no reliable Linux distros should have problems with reliable rebuilding things after security fixes, no matter how it's linked if I where to guess there this might be related to how the lower levels of dependency management on Linux is quite a mess due to requirements from 90 no longer relevant today, but which some people still obsess over. To elaborate (sorry for the wall of text) you can _roughly_ fit all dependencies of a application (app) into 3 categories: 1. programs the system provides (opt.) called by the app (e.g. over ipc, or spawning a sub process), communicating over well defined non language specific protocols. E.g. most cmd-line tools, or you systems file picker/explorer should be invoked like that (that it often isn't is a huge annoyance). 2. programs the system needs to provide, called using a programming language ABI (Application Binary Interface, i.e. mostly C ABI, can have platform dependent layout/encoding) 3. code reused to not rewrite everything all the time, e.g. hash maps, algorithms etc. The messy part in Linux is that for historic reasons the later two parts where not treated differently even through they have _very_ different properties wrt. the software live cycle. For the last category they are for your code and specific use case only! The supported versions usable with your program are often far more limited: Breaking changes far more normal; LTO is often desirable or even needed; Other programs needing different incompatible versions is the norm; Even versions with security vulnerabilities can be fine _iff_ the vulnerabilities are on code paths not used by your application; etc. The fact that Linux has a long history of treating them the same is IMHO a huge fuck up. It made sense in the 90th. It doesn't anymore since ~20 years. It's just completely in conflict with how software development works in practice and this has put a huge amount of strain on OSS maintainers, due to stuff like distros shipping incompatible versions potentially by (even incorrectly) patching your code.... and end users blaming you for it. IMHO Linux should have a way to handle such application specific dependencies in a all cases from scripting dependencies (e.g. python), over shared object to static linking (which doesn't need any special handling outside of the build tooling). People have estimated the storage size difference of linking everything statically, and AFIK it's irrelevant in relation to availability and pricing on modern systems. And the argument that you might want to use a patched version of a dependency "for security" reasons fails if we consider that this has lead to security incidents more then one time. Most software isn't developed to support this at all and bugs can be subtle and bad to a point of a RCE. And yes there are special cases, and gray areas in between this categories. E.g. dependencies in the 3rd category you want to be able to update independently, or dependencies from the 2nd which are often handled like the 3rd for various piratical reasons etc. Anyway coming back the the article Rust can handle dynamic linking just fine, but only for C ABI as of now. And while rust might get some form of RustABI to make dynamic linking better it will _never_ handle it for arbitrary libraries, as that is neither desirable nor technical possible. --- EDIT: Just for context, in case of C you also have to rebuild all header only libraries using pre-processor macros, not doing so is risky as you now mix different versions of the same software in one build. Same (somewhat) for C++ with anything using template libraries. The way you can speed it up is by caching intermediate build artifacts, that works for rust, too.

theoldgreybeard 11mo ago

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/discussions in small hobby projects I released as open source - I just ban them immediately because there is no reasoning with them and they never give up. Open source terrorists.

tucnak 11mo ago
"Open source terrorism" is a hilarious designation for Rust-like traditions and customs. I wonder what other programming language/software communities may fall under this definition?
aeve890 11mo ago
Username checks out. >Open source terrorists Rust users and evangelism rubs me the wrong way. Yes it's safe, yes it's ergonomic but why the weird aura around the people that insist in "Rewrite it in Rust, Deus Vult"? It eludes me.

koakuma-chan 11mo ago

[dead]

monegator 11mo ago

Sometimes you do wonder if those 4chan memes about those who push rust rewrites are just memes or what..

steveklabnik 11mo ago
A maintainer of a project making a decision about their project is not someone pushing a re-write.

tyfon 11mo ago

I have a dual pentium pro 200 that runs gentoo and openbsd, but rust doesn't ship i586 binaries, only i686+. So I would need to compile on a separate computer to use any software that is using rust. There is already an initrd package tool I can't use since it is rust based, but I don't use initrd on that machine so it is not a problem so far. The computer runs modern linux just fine, I just wish the rust team would at least release an "i386" boostrap binary that actually works on all i386 like all of the other compilers. "We don't care about retro computers" is not a good argument imho, especially when there is an easy fix. It was the same when the Xorg project patched out support for RAMDAC and obsoleted a bunch of drivers instead of fixing it easily. I had to fix the S3 driver myself to be able to use my S3 trio 64v+ with a new Xorg server. /rant off

ondra 11mo ago
Pentium Pro is the first i686 CPU, so you should be fine.
ForHackernews 11mo ago
I mean... Pentium Pro is 30 years old at this point. I don't think it's unreasonable that modern software isn't targeting those machines.
- yjftsjthsd-h 11mo ago
  So anyways, here's the netbsd docs for running the latest release on VAX: https://wiki.netbsd.org/ports/vax/ https://wiki.netbsd.org/ports/vax/
  - ForHackernews 11mo ago
    Obscure retro OS runs on obscure retro hardware you say?
    - yjftsjthsd-h 11mo ago
      NetBSD isn't a retro OS, nor is it particularly obscure. (For that matter, VAX isn't obscure, though it's very retro.)

MisterTea 11mo ago

""and not be held back by trying to shoehorn modern software on retro computing devices"" Nice. So discrimination of poor users who are running "retro" machines because that is the best they can afford or acquire. I knew of at least two devs who are stuck with older 32 bit machines as that is what they can afford/obtain. I even offered to ship them a spare laptop with a newer CPU and they said thanks but import duties in their country would be unaffordable. Thankfully they are also tinkering with 9front which has little to no issues with portability and still supports 32 bit.

aaronblohowiak 11mo ago
Rust works fine on 32 bit, (and 16 bit) that’s not what they mean…
- quux 11mo ago
  Rust even works on 8-bit via the LLVM-MOS backend for MOS 6502 :)
chc4 11mo ago
No one is using an Alpha, Motorola 680x0, PA-RISC, or SuperH computer because that's the only thing they can afford. Rust supports 32bit x86.
quux 11mo ago
Looking at the list of affected architectures: Alpha (alpha), Motorola 680x0 (m68k), PA-RISC (hppa), and SuperH (sh4) I think these are much much more likely to be run by enthusiasts than someone needing an affordable computer.
cogman10 11mo ago
The last 32bit laptop CPU was produced nearly 20 years ago. Further, there are still several LTS linux distros (including the likes of Ubuntu and Debian) which don't have the rust requirement and won't until the next LTS. 24.04 is supported until 2029. Meaning you are talking about a 25 year old CPU at that point. And even if you continue to need support. Debian based distros aren't the only ones on the plant. You can pick something else if it really matters.

ethin 11mo ago

This is just one reason I'm not the biggest fan of Rust. The language is good (as well as what it solves), but this tendency to force it into everything (even where it would provide no benefit whatsoever) is just mind-boggling to me. And the Rust evangelists then wonder why there are so many anti-rust folk.

creatonez 11mo ago

I have never seen a program segfault and crash more than apt. The status quo is extremely bad, and it desperately needs to be revamped in some way. Targeted rewrites in a memory safe & less mistake-prone language sounds like a great way to do that. If you think this is a random decision caused by hype, cargo culting, or a maintainer's/canonical's mindless whims... please, have a tour through the apt codebase some day. It is a ticking time bomb, way more than you ever imagined such an important project would be.

sherr 11mo ago
I've been using apt regularly on Debian for a long time and never seen it crash or segfault. Very strange that you do. All software has bugs of course, but apt is so heavily used that I expect it gets attention. It just works for me.
- dontlaugh 11mo ago
  I’ve seen in segfault once. I don’t know how common that is, but it would be nice to make that less likely.
pmarin 11mo ago
20 years on Debian. Not a single crash with apt
- roryirvine 11mo ago
  Almost 30 years for me, both on my personal machines and at work. I went through a period about 25 years ago where apt crashed on my (rather janky) desktop almost every other run, and sometimes left my system in a state so inconsistent that I had to fall back on 'dpkg-reconfigure --force' and the like to fix it. Turns out that it was due to a bad interaction between a failing stick of RAM and reiserfs' tail-packing feature, which was causing frequent silent corruption in /var/lib/dpkg/status and friends. I don't think I've seen any similar issues since, across what must be many millions of apt runs I've been responsible for. Perhaps gp is suffering from some similar underlying problem?

ekjhgkejhgk 11mo ago

This thing gets everywhere.

phkahler 11mo ago

I don't think programs should use mixed languages if its at all avoidable. Linux would be an exception because I think it can benefit from oxidation and it'll be decades before RedoxOS is ready.

renewiltord 11mo ago

Overall, I think Rust is probably too dangerous to introduce into core software. Every time there is a donation to the Rust Foundation, the Rust community is in an uproar that it is not a large enough fraction of gross revenue. Linux, apt, are all currently both free as in speech and free as in beer. If we have to start donating to the Rust Foundation a percentage of gross revenue for every tool that we use written in Rust, it will cost a lot. Probably much better to just not put Rust in the kernel or in apt. It's a Trojan horse language. There are no demands from C users that anyone donate to C non-profits. Much better, safer language to use from an ecosystem perspective.

steveklabnik 11mo ago
> Every time there is a donation to the Rust Foundation, the Rust community is in an uproar that it is not a large enough fraction of gross revenue. Where are you seeing this happen? I'm curious because I never have, which means that I'm missing out on discussions somewhere.
- renewiltord 11mo ago
  Sure, it's on Reddit /r/rust. I'll provide links at the end, but it happens every time there is a donation. > > > Multi trillion dollar conglomerate invests a minuscule fraction of a fraction of their monthly revenue into the nonprofit foundation that maintains the tool that will save them billions > > 115 Billion / 365 days / 1440 minutes = ~ 220k > > So they make around 220k per minute, 350k in under 2 minutes. Still, any amount is better than nothing at all. > I genuinely hate the thought of "Better than nothing". We should be saying "go big or go home." Pretty popular thread. Approximate 900 upvotes over those three comments. > That's like a millisecond of Google revenue. and separately > I mean thats nice. But in all honesty, is 1 Million still a lot? That's from a while ago so it's smaller. But you can tell the sentiment is rising because these expressions of "it's not enough" are becoming more popular. Just a matter of time before the community tries to strong-arm other orgs with boycotts and this and that. We've seen this before. > > Cool, but also depressing how relatively small these “huge” investments in core technologies actually are. > Yeah, seriously. This is comparatively like me leaving a penny in the “take a penny leave a penny” plate at the gas station. and separately > Ah yes, the confidence displayed by allocating 0.0004% of your yearly revenue. > Satya alone earns that in a 40 hr work week. It's a pretty old playbook to use free-software language to get one's technology entrenched, then there's murmurs about how not enough money is being sent back to the people making it, the organization then uses the community as the stalking horse to promote this theory, and then finally comes the Elastic License relicensing. Elastic did it. MongoDB did it. Hashicorp did it. Redis did it. I get the idea, but we should pre-empt the trojan horse when we see it coming. I know I know. You can fork when it happens etc. but I'm not looking forward to switching my toolchain to "Patina" or whatever they call the fork. And if you think I'm some guy with an axe to grind, I have receipts for Rustlang enthusiasm: https://news.ycombinator.com/item?id=24127438 https://news.ycombinator.com/item?id=24127438 https://news.ycombinator.com/item?id=24328686 https://news.ycombinator.com/item?id=24328686 https://news.ycombinator.com/item?id=30756184 https://news.ycombinator.com/item?id=30756184 https://news.ycombinator.com/item?id=37573389 https://news.ycombinator.com/item?id=37573389 https://news.ycombinator.com/item?id=41639619 https://news.ycombinator.com/item?id=41639619 List of donation posts follows: https://old.reddit.com/r/rust/comments/1noyqak/media_google_continues_to_invest_350k_in_rust/nfvf6mc/ https://old.reddit.com/r/rust/comments/1noyqak/media_google_... https://old.reddit.com/r/rust/comments/1ajm56w/google_donates_1m_to_the_rust_foundation_to/ https://old.reddit.com/r/rust/comments/1ajm56w/google_donate... https://old.reddit.com/r/rust/comments/1cnehqt/microsofts_1m_vote_of_confidence_in_rusts_future/ https://old.reddit.com/r/rust/comments/1cnehqt/microsofts_1m...

leo_e 11mo ago

As someone fighting the C++ toolchain daily, there is a painful irony in seeing APT—the tool supposed to solve dependency hell—creating its own dependency crisis. I sympathize with the maintainers of retro hardware. But honestly? Holding back the security and maintainability of a modern OS base layer just so an AlphaStation from 1998 can boot feels backwards. The transition pain is real, and Canonical handled the communication poorly. But the 'legacy C tax' is eternal. We have to move critical infrastructure off it eventually.

major505 11mo ago

IS funny because thanks to efforts from companies like Valve, Linux seens to finally been receiving the recognition it deserves, Rust evangelists and weirdos who claim morality superiority to the rest of mortals, are going to put everything to loose, because of this obsession of rewriting tools that actually work for many years without bigger issues, just so they can say their language is superior. IF there was some glaring problems with tools like sudo, sort, apt, and you have a superior version, sure, go ahead. But this is clearly not the case. Sometimes the rust version is just the same, or even inferior, but people are ready to plunge into destruction just to say their distro have the latest and greatest. Its just vanity. Maybe the conspiracy theories that big tech finance the crazy incopetent people from in position of power in open source projects that they no longer can compete, in order to destroy them from the inside, is not that far fetched.

Surac 11mo ago

my biggest problem with rust is. i can't read it. i never know what this symbol means. is it a keyword? a type, a variable, a constant or a macro? Sure loading it into a IDE with a language server may help understanding the code.

xiej 11mo ago
There are only a few common keywords. Types are PascalCase. Variables are snake_case. constants are SCREAMING_CASE. macros have an exclamation point !
pornel 11mo ago
That's just your lack of familiarity with the foreign-to-you language (you may be unable to read Korean too, despite Korean being pretty readable). Syntactically, Rust is pretty unambiguous, especially compared to C-style function and variable definitions. You get fn and let keywords, and definitions that are generally read left-to-right, instead of starting with an arbitrary identifier that may be a typedef, a preprocessor macro, or part of a type that is read in so-called "spiral" order (which isn't even a spiral, but more complex than than).

BDMug 11mo ago

[dead]