I think any projects that are run by people that see themselves as "X-people" (like Python-people, Perl-people) always have a bit "ick" reaction to new languages being added to projects they might see as part of a language's community.

So say you're a C++ developer, contributed to APT over the years, see all of it linked to the C++ community which you are part of too, and someone wants to start migrating parts of it to Rust/$NewLang. I think it might sometimes affect more for these people than just the code, might even be "attacking" (strong word perhaps) their sense of identity, for better or worse.

Debian has ongoing efforts to make many shell scripts (like postinst Scripts in packages etc.) non-bash-specific.

A minimal Debian installation doesn't contain bash, but rather dash, which doesn't support bash extensions.

I don't know if you've tried to get someone else's Python running recently, but it has devolved into a disaster effectively requiring containers to accurately replicate the exact environment it was written in.

Core system applications should be binaries that run with absolutely minimal dependencies outside of default system-wide libraries. Heck, I would go as far as to say applications in the critical path to repairing a system (like apt) should be statically linked since we no longer live in a storage constrained world.

    > indeed, there's quite a few commenters here who I think would be surprised to learn that not only is C++ on this list, but that it's been on it for at least 25 years

After all the library wasn't designed around safety, we assumed the .debs you pass to it are trusted in some way - because you publish them to your repository or you are about to install them so they have root maintainer scripts anyway.

But as stuff like hosting sites and PPAs came up, we have operators publishing debs for untrusted users, and hence suddenly there was a security boundary of sorts and these bugs became problematic.

Of course memory safety here is only one concern, if you have say one process publishing repos for multiple users, panics can also cause a denial of service, but it's a step forward from potential code execution exploits.

I anticipate the rewrites to be 1 to 1 as close as possible to avoid introducing bugs, but then adding actual unit tests to them.

Not necessarily. The "HTTP signature verification code" sounds like it's invoking cryptography, and the sense I've had from watching the people who maintain cryptographic libraries is that the "foundational code" is the sort of stuff you should run away screaming from. In general, it seems to me to be the cryptography folks who have beat the drum hardest for moving to Rust.

As for other kind of parsing code, the various archive file formats aren't exactly evolving, so there's little reason to update them. On the other hand, this is exactly the kind of space where there's critical infrastructure that has probably had very little investment in adversarial testing either in the past or present, and so it's not clear that their age has actually led to security-critical bugs being shaken out. Much as how OpenSSL had a trivially-exploitable, high criticality exploit for two years before anybody noticed.

Additionally, the fact that this comes across as so abrasive and off-putting is on brand for online Rust evangelicalism.

No: a little less than 5 years ago there was CVE-2020-27350, a memory safety bug in the tar/ar implementations.

Seeing this tone-deaf message from an Ubuntu employee would be funny if I didn’t actually use Ubuntu. Looks like I have to correct that…

- It's not an option for debian core infrastructure until it supports at least the same platforms debian does (arm, riscv, etc) and it currently only supports x86_64.

- It doesn't turn C into a modern language, since it looks like there's active development here getting the productivity benefits of moving away from C is likely still worth it.

If all the entry-level jobs are C or C++, do you think companies would have a hard time filling them? Would the unemployed new graduates really shun gainful employment if Rust wasn't part of the equation?

Meanwhile, hiring managers left and right are reporting that within hours of a job being posted, they are flooded with hundreds of applications. And you can't find a single person because of the programming language of your stack? And to remedy this, you're going to rewrite your stack in an unproven language? Have you considered that if you can't find anyone that it might not be a programming language or tech stack problem?

A lot of the C code used in python is calling out to old, battle tested and niche libraries so it is unlikely that someone is going to replace those any time soon but Rust is definitely increasing as time goes on for greenfield work.

All (current) languages eventually have a compiler/runtime that is memory unsafe. This is basically fine because it's a tiny amount of surface area (relative to the amount of code that uses it) and it exists in a way that the input to is relatively benign so there's enough eyes/time/... to find bugs.

There's also nothing stopping you from re-implementing python/ruby/... in a safer way once that becomes the low hanging fruit to improve computer reliability.

as in that "isn't the style of code you are used too"

I don't think "how well people not familiar with you language can read it" is a relevant metric for most languages.

Also IMHO while C feels readable it isn't when it matters. Because it very often just doesn't include information you need when reading. Like looking at function header doesn't tell you if a ptr is nullable, or if a mut ptr is a changeable input value or instead is a out ptr. which is supposed to point to unitialized memory and if there is an error how that affects the state of the validity of any mutable ptrs passed in. To just name some example (lets not even get started about pre processor macros pretending to be C functions). In conclusion while C seems nice to read it is IMHO often a painful experience to "properly" read it e.g. in context of a code review.

As a side note: The seemingly verbose syntax of e.g. `chrono::DateTime` comes from there being 2 DateTime-types in use in the module, one from the internationalization library (icu) and one from a generic time library (chronos). Same for Sender, etc. That isn't a supper common issue, but happens sometimes.

If I wanted to tweak the Rust project, I’d feel pretty confident I was calling the right things with the right params.

Most of the code in that module is dedicated to the gui maintenance. The parts that do deal with time are perfectly legible.

I disagree. Both seem perfectly readable, assuming you know their preferred coding styles. As a non-C programmer, I absolutely despise running into #ifndef SOME_OBSCURE_NAME and `while (n) { if (g) {` but C (and in the latter case Go) programmers seem to love that style.

Comparing a bunch of small, barely integrated command line programs to a UI + calendar widget doesn't seem "of similar complexity" to me. Looking at a C clock widget (https://gitlab.freedesktop.org/xorg/app/xclock/-/blob/master...) the difference seems pretty minimal to me. Of course, the XClock code doesn't deal with calendars, so you have to imagine the extra UI code for that too.

I beg to differ.

Can you provide some evidence to support this? There’s a large body of evidence to the contrary, e.g. from Chrome[1].

> But we have tools to prevent that. The new security issues are supply chain attacks.

Speaking as a “supply chain security” person, this doesn’t really hold water. Supply chain attacks include the risk of memory unsafety lurking in complex dependency trees; it’s not an either-or.

[1]: https://www.chromium.org/Home/chromium-security/memory-safet...

Does it audit third-party code for you?

But Rust, you know, has one.

How many decades have we tried this? How many more to see that it just hasn't panned out like you describe?

History shows again and again that this statement is impossible..

Name a large C application that’s widely used, and I’ll show you at least one CVE that’s caused by a memory leak from the project

Are you really claiming that you can't design a language without an official standard? Not to mention that C itself has been designed long before its first ISO standard. Finally, the idea that a standard committee is a preconditionfor good language design is rather bold, I have to say. The phrase "design by committee" isn't typically used as a compliment...

> You've solved one class of bugs outside of "unsafe {}".

It's "only" the single most important class of bugs for system safety.

This kind of deflection and denialism isn't helping. And I'm saying this as someone who really likes C++.

For instance,

  struct Feet(i32);
  struct Meters(i32);
  
  fn hover(altitude: Meters) {
      println!("At {} meters", altitude.0);
  }
  
  fn main() {
      let altitude1 = Meters(16);
      hover(altitude1);
      let altitude2 = Feet(16);
      hover(altitude2);
  }

   12 |     hover(altitude2);
      |     ----- ^^^^^^^^^ expected `Meters`, found `Feet`
      |     |
      |     arguments to this function are incorrect

That’s one example. It’s not unique to Rust by a long shot. But it’s still a vast improvement over C, where that same signed 32 bit data type is the number of eggs in a basket, the offset of bytes into a struct, the index of an array, a UTF-8 code point, or whatever else.

This really shows up at refactoring time. Move some Rust code around and it’ll loudly let you know exactly what you need to fix before it’s ready. C? Not so much.

If people from that world complain about Rust, I surely wouldn't want them around a C codebase.

There's nothing wrong about memory-managed languages, if you don't need to care about memory. But being unfamiliar with memory and complaining about the thing that help you avoid shooting your foot isn't something that inspires trust.

The hardship associated with learning rust isn't going to go away if they do C instead. What's going to happen instead is that bugged code will be written, and they will learn to associate the hardship with the underlying problem: managing memory.

I think this is more true of C than it is of Rust if the bar is "code of sufficient quality to be included in debian"

It might take some people months rather than days, but I think that is a desirable outcome.

Important low level software should be written by competent developers willing to invest the effort.

That could also be applied to C and C++ …

Time and time again, theoretically worse solutions that are easily accessible win

[0] https://en.wikipedia.org/wiki/I386

Either legacy systems (which are most certainly not running the current bleeding-edge Debian) or retro computing enthusiast.

These platforms are long obsolete and there are no practical reasons to run them besides "I have a box in the corner that's running untouched for the last 20 years" and "for fun". I can get a more powerful and power efficient computer (than any of these systems) from my local e-waste recycling facility for free.

Here is one famous example of a dude who’s managed to get PRs merged in dozens of packages, just to make them compatible with ancient versions of nodejs https://news.ycombinator.com/item?id=44831811

Well, there are so many things were you could argue about the relevance of a userbase.

If the size of a userbase would be the only argument, Valve could just drop support for the Linux userbase which is just 2-3% of their overall userbase.

Cars, airplanes, construction equipment, etc.

But yeah, those can figure out how to keep their own port

It’s just a bit annoying that Rust proponents are being so pushy in some cases as if Rust was the solution to everything.

It's been somewhat useful for finding weird edge cases in software where for whatever reason, it doesn't reproduce easily on AArch64 or x86, but does there. (Or vice-versa, sometimes.)

I don't know that I'd say that's sufficient reason to motivate dozens of people to maintain support, but it's not purely academic entertainment or nostalgia, for that.

[1] https://github.com/rust-lang/rustc_codegen_gcc

In fact not having it encourages copy and paste which reduces security.

Whats next? Strip javascript support from browsers to reduce the attack surface?

I don't get how this is even a discussion. Either he is paid by canonical to be a corporate saboteur or he is completely insane.

The one demanding it is the maintainer of keepassxc it would’ve been better to just close the issue that this is a Debian only problem and he should install it like that and just close it.

now this is separate from being open for discussion if someone has some good arguments (which aren't "you break something which isn't supported and only nich used") and some claim he isn't open for arguments

and tbh. if someone exposes users to actual relevant security risk(1) because the change adds a bit of in depth security(2) and then implicitly denounces them for "wanting crap" this raises a lot of red flags IMHO.

(1): Copy pasting passwords is a very bad idea, the problem is phsishing attacks with "look alike" domains. You password manager won't fill them out, your copy past is prone to falling for it. In addition there are other smaller issues related to clip board safety and similar (hence why KC clears the clipboard after a short time).

(2): Removing unneeded functionality which could have vulnerabilities. Except we speak about code from the same source which if not enabled/setup does pretty much nothing (It might still pull in some dependencies, tho.)

but yes very unnecessary drama

If I have a program that encrypts and decrypts passwords, then the surface area is way smaller than if it also has browser integrations and a bunch of other features. Every feature has the potential to make this list longer: https://keepass.info/help/kb/sec_issues.html which applies to any other piece of software.

At the same time, people can make the argument that software that's secure but has no useful features also isn't very worthwhile. From that whole discussion, the idea of having a minimal package and a full package makes a lot of sense - I'd use the minimal version because I don't use that additional functionality, but someone else might benefit a bunch from the full version.

Security is there to keep the features usable without interruptions or risks.

E.g. plugging the computer off the network is not about security if the service needs to be accessible.

And regardless, my point is it would be more sensible to say "I'm going to introduce an oxidized fork of apt and a method to use it as your system apt if you prefer" and then over the next year or so he could say "look at all these great benefits!" (if there are any). At that point, the community could decide that the rust version should become the default because it is so much better/safer/"modern"/whatever.

On your second part. I wonder how aviation and space and car industry do it. They rely heavily on tested / proven concepts. What do they do when introducing a new type of material to replace another one. Or when a complete assembly workflow gets updated.

The GPL protects the freedom of the users while MIT-licensed software can be easily rug-pulled or be co-opted by the big tech monopolists.

Using GitHub is unacceptable as it is banning many countries from using it. You are excluding devs around the world from contributing. Plus it is owned by Microsoft.

So we replaced a strong copyleft license and a solid decentralized workflow with a centralized repo that depends on the whims of Microsoft and the US government and that is somehow a good thing?

[1] https://github.com/coreutils/coreutils

> Rust is a security nightmare. We'd need to add over 130 packages to main for sequoia, and then we'd need to rebuild them all each time one of them needs a security update.

What has changed? Why is 130 packages for a crypto application acceptable?

The dependency explosion is still a problem and I’m not aware of any real solution. It would have been interesting to to see why their opinion changed… I’m guessing it’s as simple as the perceived benefits overriding any concerns and no major supply-chain attacks being known so far.

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

(In my second-tier university at my developing country, the Sun workstation hadn’t been turned on in years by the late 2000s, and the the minicomputer they bought in the 1980s was furniture at the school)

Edit: As for big businesses, they have support plans from IBM or HP for their mainframes, nothing relevant to Debian.

See (relatively recent) list of manfuacturers here:

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

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

I haven't seen this from Rust. Obviously lots of us think that Rust is the way forward for us but I think the problem you're talking about is that nobody offered any alternatives you liked better and that's not on Rust.

If Bob is ordering pizza for everybody who wants one, it is not the case that "Pizza is necessarily the way forward", and it's not Bob's fault that you can't have sliders, I think if you want sliders you're going to need to order them yourself and "Pizza is the way forward" is merely the default when you don't and people are hungry.

Dave Abraham's Hylo is an example of somebody offering to order sushi in this analogy. It's not yet clear whether Dave knows a Sushi place that delivers here, or how much Sushi would be but that's what having another way forward could look like.

In C++ they've got profiles, which is, generously, "Concepts of a plan" for a way forward and in C... I mean, it's not your focus, but nobody is looking at this right? Maybe Fil-C is your future? I note that Fil-C doesn't work on these obsolete targets either.

Nobody is being forced out of the community, you can fork and not adopt the changes if you want. Thats the real point of free software, that you have the freedom to make that choice. The whole point of free software was never that the direction of the software should be free from corporate control in some way, the maintainers of a project have always had the authority to make decisions about their own project, whether individual or corporate or a mix.

This assumes there wasn't agreement.

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

This hasn’t changed.

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

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

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

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

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

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

I'll wait.

If you opt into something with as high a barrier to entry and necessary time commitment as a programming language, you naturally also opt into the existing community around that language, because that will be where the potential contributors, people to help you solve issues, and people you have to talk to if you need the language or ecosystem to move in some direction will hail from. In turn, the community will naturally get to impose its own values and aesthetic preferences onto you, whether by proactively using the position of relative power they have over you, or simply by osmosis. As it happens, the community surrounding Rust does largely consist of American progressives, which should not be surprising - after all, the language was created by an American company whose staff famously threatened mutiny when its own CEO turned out to offend progressive sensibilities.

As such, it is natural that bringing Rust into your project would over time result in it becoming more "woke", just like using Ruby would make it more likely that you attract Japanese contributors, or targeting Baikal CPUs would result in you getting pulled into the Russian orbit. The "woke" side themselves recognises this effect quite well, which is why they were so disturbed when Framework pushed Omarchy as a Linux distribution.

Of course, one needs to ask whether it is fair to insinuate premeditation by calling a mere expected effect an "agenda". Considering the endlessly navel-gazing nature of the culture wars, I would find it surprising if there weren't at least some people out there who make the same observation as above, and do think along the lines that driving Rust adoption is [also] a good thing because of it. Thus, Rust adoption does become, in a sense, part of the "woke agenda", just as Rust rejection becomes, perhaps even more clearly so, part of the "chud agenda".

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

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

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

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

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

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

Rust haters seem strangely obsessed.

Good news: you can. And that's why it has had fast adoption.

(those advocating for Rust in "meme-like" ways are not generally the same people actually developing the Rust compiler or the core parts of it's ecosystem)

Lack of drivers is prohibitive if your are a small/medium team or are using a lot of complicated peripherals or SoC. Compare to C where any MCU or embedded SoC or moderately complex peripheral normally comes with C driver code.

In this mindset, arguing against change is an argument on the merits. Because everything you spend time on has the opportunity cost of everything else you could spend time on.

Telling people they need to take their ball and go home if they're incapable or unable to maintain an entire compiler back-end seems like a, shall we say, 'interesting' lens for a major distro such as Debian.

Just to parse some files?

Sorry to double-reply, but this is actually a super important point in favor of Fil-C.

If you adopted Fil-C for apt, then you could adopt it optionally - only on ports that had a Fil-C compiler. Your apt code would work just as well in Fil-C as in Yolo-C. It's not hard to do that. I think about half the software I "ported" to Fil-C worked out of the box, and in those cases where I had to make changes, they're the sort of changes you could upstream and maintain the software for both Fil-C and Yolo-C.

So, with Fil-C, there would be no need to ruffle feathers by telling port maintainers to support a new toolchain!

That's easily fixable.

> It also doesn't help you to attract new contributors.

I don't understand this point.

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

I am asking if the former option is a practical one

Sure it would. Suppose a rust-based package has a security bug. Upstream has fixed it, but that fix depends on some new rust language feature that the frozen version of rust in Debian doesn't have yet.

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

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

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

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

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802778

10 years old. It never was a false positive. It was fixed a good few years ago. The fix did not involve suppressing the error.

Valgrind does need a lot of work, especially for missing CPU features and for Darwin. I’m not aware of many memcheck bugs that aren’t relatively obscure corner cases.

If you have encountered bugs please report them to https://bugs.kde.org.

It exits 0 when the verification failed, it exits 1 when it passed, and you have to ignore it all and parse the output of the status fd to find the truth.

It provides options to enforce various algorithmic constraints but they only work in some modes and are silently ignored in others.

Does Sequoia-PGP have similar credentials and who funds it?

        int[] foo
        |   |  |
        |   |  foo 
        |   is an array  
        of ints

The C programmers I know are certainly not deluded or overconfident. They don't even think "their" language is a perfect one, or even a very good one. They just avoid black-and-white thinking. They take a practical approach about memory issues, seeing them more like any other kind of bug. It's a different aesthetics than you would maybe see from many Rust folks. They want to be productive and want to be in control and want to understand what their code does. In turn, they accept that in some cases, bugs (possibly memory bugs) creep in, some of which could go unnoticed for some time. They tend to not see that as a huge issue, at least in general, because an issue that has gone unnoticed (or didn't manifest) is often less of a problem than one that is immediately obvious. (In case of data corruption, it _can_ be a huge issue, and you have to add safeguards to prevent it, and have to be accepting some residual risk).

They understand that everything is a trade off and that with experience and practice, good architecture, good tooling etc. you can prevent many bugs early, and detect them early. They have tried many approaches to prevent bugs, including fancy languages and constructs, and have concluded that in many cases, perfect safety is not possible, in particular it's not possible without seriously hurting other requirements, such as productivity.

As to valgrind, I can say that it was a bit of a mixed bag for me. It did help me finding bugs a number of times, but I also had to configure it a bit because it was producing a lot of noise for some external libraries (such as libc). I don't really understand the underlying issues.

Honestly, I am not even opposed to Rust. It has cool ideas. I do think it should care a lot more about being portable and properly defined and should have done so a lot earlier and I do deeply disagree with the opinion of some core team members that specification is meaningless.

C obviously always was a questionable choice for a tool like apt but Rust seems even worse to me. Apt has absolutely no need to be written in a low level language. At least you could argue that C was chosen because it’s portable but I don’t see what Rust has going for it.

https://news.ycombinator.com/newsguidelines.html

There is other work on specifying Rust (e.g. the Unsafe Code Guidelines Working Group), but nothing approaching a real spec for the whole language. Honestly, it is probably impossible at this point; Rust has many layers of implementation-defined hidden complexities.

Rust people for some reason are.

To add on to that, with declarations the programmer can tell the Lisp compiler that (for example) a variable can be stack allocated to help improve performance. The fact that Lisp code is just data is another benefit towards performance as it means macros are relatively easy to write so some computation can be done at compile time. There are also various useful utilities in the spec which can be used to help profile execution of a program to aid in optimization, such as time and trace.

Author quite literally said bcachefs-tools "is impossible to maintain in Debian stable", and the reason cited was Rust.