6 ms·

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 wa

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.
  - mschuster91 11mo ago
    > 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. It's frankly the only way to maintain a distribution relying almost completely on volunteer work! The more different options there are, the more expensive (both in terms of human cost, engineering time and hardware cost) testing gets. It's one thing if you're, say, Red Hat with a serious amount of commercial customers, they can and do pay for conformance testing and all the options. But for a fully FOSS project like Debian, eventually it becomes unmaintainable. Additionally, the more "liberty" distributions take in how the system is set up, the more work software developers have to put in. Just look at autotools, an abomination that is sadly necessary.
gorgoiler 11mo ago
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 11mo ago
  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 11mo ago
    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!)
  - eichin 11mo ago
    Mmm, apt-ftparchive is pretty useful for cooking up repos for "in-house" distros (which we certainly thought was serious...) but those tools are already a separate binary package (apt-utils) so factoring them out at the source level wouldn't be particularly troublesome. (I was going to add that there are also nicer tools that have turned up in the last 10 years but the couple of examples I looked at depend on apt-utils, oops)
    - mikepurvis 11mo ago
cvcfdd 11mo ago
[dead]
Aurornis 11mo ago
> 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.
- miladyincontrol 11mo ago
  Not just really, really old, but they in fact have long since been depreciated in any semblance of official support. I get the friction especially for younger contributors, not that this is the case here. However there are architectures that havent even received a revision in their lifetime which old heads will take as personal slights for which heads must roll when presented with even the slightest of inconvenience for their hobbyist port.
  - Aurornis 11mo ago
    I haven't seen any complaints from anyone who uses those ports personally. I would bet there's someone out there who uses Debian on those platforms, but 100% of the complaining I've seen online has been from people who don't use those ports. It's the idea that's causing the backlash, not the impact.
- jancsika 11mo ago
  > The wording could have been better, but I don’t see it as a dig. He created (or at least re-activated) a dichotomy for zero gain, and he vastly increased the expectations for what a Rust rewrite can achieve. That is very, very bad in a software project. The evidence for both is in your next paragraph. You immediately riff on his dichotomy: > 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. (My emphasis.) He wants to do a rewrite in Rust to replace old, craggy C++ that is so difficult to reason about that there's no chance of attracting new developers to the maintenance team with it. Porting to Rust therefore a) addresses memory safety, b) gives a chance to attract new developers to a core part of Debian, and c) gives the current maintainer a way to eventually leave gracefully in the future. I think he even made some these points here on HN. Anyone who isn't a sociopath sympathizes with these points. More importantly, accidentally introducing some big, ugly bug in Rust apt isn't at odds with these goals. It's almost an expected part of the growing pains of a rewrite plus onboarding new devs. Compare that to "holding up progress for everyone." Just reading that phrase makes me force sensitive like a Jedi: I can feel the spite of dozens HN'ers tingling at that and other phrases in these HN comments as they sharpen their hatred, ready to pounce at the Rust Evangelists the moment this project hits a snag. (And, like any project, it will hit snags.) 1. "I'm holding on for dear life here, I need help from others and this is the way I plan to get that help" 2. "Don't hold back everyone else's progress, please" The kind of people who hear "key party" and imagine clothed adults reciting GPG fingerprints need to comprehend that #1 and #2 are a) completely different strings and b) have very different-- let's just say magical-- effects on the behavior of even small groups of humans.
razighter777 11mo ago
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.
- foota 11mo ago
  *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." Imo this is true for going from one to a handful, but less true when going from a handful to more. Afaict there are 6 official ports and 12 unofficial ports (from https://www.debian.org/ports/ https://www.debian.org/ports/).
  - wtallis 11mo ago
    It really comes down to which architectures you're porting to. The two biggest issues are big endian vs little endian, and memory consistency models. Little endian is the clear winner for actively-developed architectures, but there are still plenty of vintage big endian architectures to target, and it looks like IBM mainframes at least are still exclusively big endian. For memory consistency, Alpha historically had value as the weakest and most likely to expose bugs. But nobody really wants to implement hardware like that anymore, almost everything falls somewhere on the spectrum of behavior bounded by x86 (strict) and Arm (weaker), and newer languages (eg. C++ 11) mean newer code can be explicit about its expectations rather than ambiguous or implicit.
astrobe_ 11mo ago
> I think the whole message would be more palatable if it weren't written as a decree including the dig on "retro computers" Yes, and more generally, as far as I am concerned, the antagonizing tone of the message, which is probably partly responsible for this micro-drama, is typical of some Rust zealots who never miss an occasion to remind C/C++ that they are dinosaurs (in their eyes). When you promote your thing by belittling others, you are doing it wrong.

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.
- mschuster91 11mo ago
  > 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. It's frankly the only way to maintain a distribution relying almost completely on volunteer work! The more different options there are, the more expensive (both in terms of human cost, engineering time and hardware cost) testing gets. It's one thing if you're, say, Red Hat with a serious amount of commercial customers, they can and do pay for conformance testing and all the options. But for a fully FOSS project like Debian, eventually it becomes unmaintainable. Additionally, the more "liberty" distributions take in how the system is set up, the more work software developers have to put in. Just look at autotools, an abomination that is sadly necessary.

gorgoiler 11mo ago

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 11mo ago
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 11mo ago
  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!)
- eichin 11mo ago
  Mmm, apt-ftparchive is pretty useful for cooking up repos for "in-house" distros (which we certainly thought was serious...) but those tools are already a separate binary package (apt-utils) so factoring them out at the source level wouldn't be particularly troublesome. (I was going to add that there are also nicer tools that have turned up in the last 10 years but the couple of examples I looked at depend on apt-utils, oops)
  - mikepurvis 11mo ago

cvcfdd 11mo ago

[dead]

Aurornis 11mo ago

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

miladyincontrol 11mo ago
Not just really, really old, but they in fact have long since been depreciated in any semblance of official support. I get the friction especially for younger contributors, not that this is the case here. However there are architectures that havent even received a revision in their lifetime which old heads will take as personal slights for which heads must roll when presented with even the slightest of inconvenience for their hobbyist port.
- Aurornis 11mo ago
  I haven't seen any complaints from anyone who uses those ports personally. I would bet there's someone out there who uses Debian on those platforms, but 100% of the complaining I've seen online has been from people who don't use those ports. It's the idea that's causing the backlash, not the impact.
jancsika 11mo ago
> The wording could have been better, but I don’t see it as a dig. He created (or at least re-activated) a dichotomy for zero gain, and he vastly increased the expectations for what a Rust rewrite can achieve. That is very, very bad in a software project. The evidence for both is in your next paragraph. You immediately riff on his dichotomy: > 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. (My emphasis.) He wants to do a rewrite in Rust to replace old, craggy C++ that is so difficult to reason about that there's no chance of attracting new developers to the maintenance team with it. Porting to Rust therefore a) addresses memory safety, b) gives a chance to attract new developers to a core part of Debian, and c) gives the current maintainer a way to eventually leave gracefully in the future. I think he even made some these points here on HN. Anyone who isn't a sociopath sympathizes with these points. More importantly, accidentally introducing some big, ugly bug in Rust apt isn't at odds with these goals. It's almost an expected part of the growing pains of a rewrite plus onboarding new devs. Compare that to "holding up progress for everyone." Just reading that phrase makes me force sensitive like a Jedi: I can feel the spite of dozens HN'ers tingling at that and other phrases in these HN comments as they sharpen their hatred, ready to pounce at the Rust Evangelists the moment this project hits a snag. (And, like any project, it will hit snags.) 1. "I'm holding on for dear life here, I need help from others and this is the way I plan to get that help" 2. "Don't hold back everyone else's progress, please" The kind of people who hear "key party" and imagine clothed adults reciting GPG fingerprints need to comprehend that #1 and #2 are a) completely different strings and b) have very different-- let's just say magical-- effects on the behavior of even small groups of humans.

razighter777 11mo ago

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.

foota 11mo ago
*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." Imo this is true for going from one to a handful, but less true when going from a handful to more. Afaict there are 6 official ports and 12 unofficial ports (from https://www.debian.org/ports/ https://www.debian.org/ports/).
- wtallis 11mo ago
  It really comes down to which architectures you're porting to. The two biggest issues are big endian vs little endian, and memory consistency models. Little endian is the clear winner for actively-developed architectures, but there are still plenty of vintage big endian architectures to target, and it looks like IBM mainframes at least are still exclusively big endian. For memory consistency, Alpha historically had value as the weakest and most likely to expose bugs. But nobody really wants to implement hardware like that anymore, almost everything falls somewhere on the spectrum of behavior bounded by x86 (strict) and Arm (weaker), and newer languages (eg. C++ 11) mean newer code can be explicit about its expectations rather than ambiguous or implicit.

astrobe_ 11mo ago

> I think the whole message would be more palatable if it weren't written as a decree including the dig on "retro computers" Yes, and more generally, as far as I am concerned, the antagonizing tone of the message, which is probably partly responsible for this micro-drama, is typical of some Rust zealots who never miss an occasion to remind C/C++ that they are dinosaurs (in their eyes). When you promote your thing by belittling others, you are doing it wrong.