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?

The average C project has at most a handful of other C dependencies. The average Rust, Go or NodeJS project? A couple hundred.

Ironically, because dependency management is so easy in modern languages, people started adding a lot of dependencies everywhere. Need a leftpad? Just add one line in some yaml file or an "Alt-Enter" in an IDE. Done.

In C? That is a lot more work. If you do that, you do it for advanced for stuff you absolutely need for your project. Because it is not easy. In all likelihood you write that stuff yourself.

I think the problem started with the idea over language-level managers that are just github collections instead of curated distribution-level package managers. So my response "C has no good package manager" is: It should not have a packager manager and Cargo or npm or the countless Python managers should all not exist either.

Usually the hard bit with C libraries is having dependencies with dependencies all of which use their own complex build systems, a mix of Make, CMake, Autotools, Ninja, etc.

Then within that for e.g. a mix of using normal standard names for build parameters and not e.g. PROJECTNAME_COMPILER instead of CMAKE_C_COMPILER

So, yes, you do have to figure out how to build and package these things by yourself very often. There are also no "leftpad" or similar packages in C. If you don't want to write something yourself.

In constrast - virtually every software package of any version is available to you in cargo or npm.

But Rust, you know, has one.

I have been seeing hatred on this forum towards Rust since long time. Initially it didn't make any kind of sense. Only after actually trying to learn it did I understand the backlash.

It actually is so difficult, that most people might never be able to be proficient in it. Even if they tried. Especially coming from the world of memory managed languages. This creates push back against any and every use, promotion of Rust. The unknown fear seem to be that they will be left behind if it takes off.

I completed my battles with Rust. I don't even use it anymore (because of lack of opportunities). But I love Rust. It is here to stay and expand. Thanks to the LLMs and the demand for verifiability.

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.

[1] https://github.com/helsing-ai/sguaba

> An investigation attributed the failure to a measurement mismatch between two measurement systems: SI units (metric) by NASA and US customary units by spacecraft builder Lockheed Martin.[3]

There appears to be some tension between different conveniences you might afford yourself. If you have read(offset: offsetTypeForRead, address: addressTypeForRead), you can catch when someone accidentally passes an address where the offset should be and an offset where the address should be.

Or, you can say "hey, I'm always adding the offset to the address; it doesn't matter which one gets passed first" and relieve the programmer of needing to know the order in which two semantically distinct variables get passed to `read`.

But if you do provide that convenience -- and it's not unintuitive at all; there really is only one valid interpretation of a combination of an address and an offset, regardless of the order you mention them in -- you lose some of the safety that you wanted from the types. If your variables are declared correctly, everything is fine. If there's a mistake in declaring them, you'll wave through incorrect calls to `read` that would have been caught before.

  fn sub(a:LeftOp, b:RightOp)

ide_read ( &(struct ide_loc) { .byte_offset = 10, .block = 20 } )

> ... ground controllers ignored a string of indications that something was seriously wrong with the craft's trajectory, over a period of weeks if not months. But managers demanded that worriers and doubters "prove something was wrong," even though classic and fundamental principles of mission safety should have demanded that they themselves, in the presence of significant doubts, properly "prove all is right" with the flight

Dropping units on the NASA side also was problematic but really culture was the cause of the actual crash.

[0] https://spectrum.ieee.org/why-the-mars-probe-went-off-course

/s

In C++ you can even add overloaded operators to make using math on such structs ergonomical.

Compilers know of the idiom, and will optimize the struct away.

IIUC, rust would NOT let you do a type checked m/s * s => m, so using the type system for these kinds of games is silly and dangerous (I presume you would have to do the dumb thing and typeconvert to the same type -- e.g.

    (m) (speed * ((m/s) seconds))

``` #include <stdio.h>

typedef struct { int value; } Feet;

typedef struct { int value; } Meters;

void hover(Meters altitude) { printf("At %i meters\n", altitude.value); }

int main() { Meters altitude1 = {.value = 16}; hover(altitude1); Feet altitude2 = {.value = 16}; hover(altitude2); } ```

``` error: passing 'Feet' to parameter of incompatible type 'Meters' 20 | hover(altitude2); ```

Coming from a dynamically typed language (Python, etc), this might seem like a revelation, but its old news since the dawn of programming computers. A C language server will pick this up before compile time, just like `rust-analyzer` does: `argument of type "Feet" is incompatible with parameter of type "Meters"`.

Did you not know this? I feel like a lot of people on message boards criticizing C don't know that this would fail to compile and the IDE would tell you in advance...

I haven't written rust, but my impression is the benefit is more about deeper introspection of things like lifetime than basic typesafety, which already exists in C/C++ (and is likewise occasionally bypassed for convenience, so I wonder how often the same is done for Rust)

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

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.

The problem here is that C is too basic, dated, with inadequate higher-level abstractions, which makes writing robust and secure software extra difficult and laborious. "Learning underlying hardware" doesn't solve that at all.

Debian supports dozens of architectures, so it needs to abstract away architecture-specific details.

Rust gives you as much control as C for optimizing software, but at the same time neither Rust nor C really expose actual underlying hardware (on purpose). They target an abstract machine with Undefined Behaviors that don't behave like the hardware. Their optimisers will stab you in the back if you assume you can just do what the hardware does. And even if you could write directly for every logic gate in your hardware, that still wouldn't help with the fragility and tedium of writing secure parsers and correct package validation logic.

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

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

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.

From experience with this type of code you typically end up with a load of functions that take in a numpy array and its length/dimensions to a C function that works on that array in place or an output array that was also supplied. In terms of getting this wrong, it’s usually a crash caused by out of bounds memory access which would still be a runtime crash in Rust. So I’m not sure there’s a massive benefit for these types of code other than the fun of learning Rust. Other than that, you’re typically writing C/C++ to interface with C and Fortran libraries that are really battle tested, and for which it will take decades for Rust to have equivalents. So moving to Rust will just cause you to have lots of unsafe statements - not a bad thing necessarily if you are doing a lot of work at the C level in existing code but less of a benefit if you are doing a straight wrap of a library.

On the flip side, things on the web side of Python like uWSGI which is written in C are important for the security aspect but they’re a very small part of the Python ecosystem.

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.

How many type confusion 0 days and memory safety issues have we had in dynamic language engines again? I've really lost count.

My impression is that for the trusted code untrusted input case it hasn't been that many, but I could be wrong.

How is "type confusion" a security issue?

so cool to see people getting it!

Separation of concerns solves this because the compiler has minimal impact on the trustedness of the code the Rust compiler generates. Indeed, one would expect that all the ways that the LLVM compiler fails are ways any Rust implementation would fail too - by generating the wrong code which is rarely if ever due to memory safety or thread safety issues. There may be other reasons to write the compiler backend in Rust but I wouldn’t put the trust of compiled Rust code as anywhere near the top of reasons to do that.

I don't know about that. Look at the code for the COSMIC desktop environment's clock widget (the cosmic-applet-time directory under <https://github.com/pop-os/cosmic-applets>), for example. It's pretty much unreadable compared to a C code base of similar complexity (GNU coreutils, for example: <https://savannah.gnu.org/projects/coreutils/>).

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.

Java can potentially have the same problem. But because everyone uses an IDE and because it's rarely really an issue, everyone will simply import `Baz` rather than worry about the Foo::Baz and Bat::Baz collision. It does happen in java code, but I can't stress how infrequently it's actually a problem.

In java, I rarely pay attention to the `import` section (and I know most devs at my company).

You can look up `using namespace std;` in google and you'll find a lot of articles saying it's a bad practice in C++. Everyone recommends writing the full `std::cout` rather than `cout`.

I do think it’s down to personal preference. With the fully qualified names, I can look at the screen and follow the flow without having to mouse over the various names in play. For that matter, I could print it out if I wanted to and still have all the information.

I don’t think you’re objectively wrong. It’s more that we have different approaches to managing the complexity when it gets hairy.

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.

The easiest way to see this is in US locales, which use 12-hour clocks in GNU 'date' but not other implementations:

  $ date -d '13:00'
  Sat Nov  1 01:00:00 PM PDT 2025
  $ uu_date -d '13:00'
  Sat Nov  1 13:00:00 2025

[1] https://github.com/coreutils/coreutils/commit/1066d442c2c023...

There's other languages that are considered acceptable, even desirable, languages to write applications in (e.g., Java, PHP, Go), but Rust is really the first language to compete sufficiently close to C's competence for people to contemplate adding it to the base-system-languages list. I'd say only Go has ever come close to approaching that threshold, but I've never seen it contemplated for something like systemd.

Interestingly, I wonder if the debates over the addition of C++, Python, and Perl to the base system language set were this acrimonious.

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.

If APT were a hardcore C++ project surely we'd have like adopted namespaces everywhere by now.

I would say that Pythonistas are quite accustomed to "(other) languages being added" to the Python ecosystem. After all, NumPy relies on Fortran, as well as C.

Asserting that kind of "ownership" over code seems rather distasteful to me. Maybe there would be less acrimony if developers got paid for it somehow.

Some communities indeed are better at embracing multiple languages, Python, JavaScript and Java/JVM comes to mind, where it isn't uncommon to call out to other languages.

How is language relevant here? If someone just rewrote it in the same language instead of a different one, do you feel the reaction would be significantly better?

Rust has been the tool of choice for stealing GPL3 open source projects where some people have spent all their free time on at some point in their life.

In your view, was writing a BIOS re-implementation from scratch "stealing" from IBM? Are all of the vaguely Unix-compatible operating systems "stealing" from Unix (ATT/Bell)?

> Why is the "free time" of the original developer more sacrosanct than the "free time" of the re-implementer?

This has nothing to do with free time. It has to do with the fact that the former actually went through a ton of pain to get the project from its original conception and past bugs & design flaws into its current useful state, and the latter is merely translating the solution right in front of them. And not only is the latter going to deprive the former of the ability to even say "this is my project" (despite them having spent years or decades on its design etc.), but they're also probably going to be able to take the whole thing in a different direction, effectively leaving the original author behind.

Whether you feel this is a good or a bad thing for society aside, it should be obvious why this could be genuinely upsetting in some situations.

I happen to like living in a world where Pipewire can just be a drop in replacement for PulseAudio that can implement the same APIs and do everything that PulseAudio does but better. Or where I can play my games on Linux because Valve re-implemented DirectX and all the Windows platform libraries. Or where there are half a dozen "vim" clones to pick from if I want to. If there are broad, tangible benefits to rewriting a piece of software, then it ought to be rewritten, hurt feelings nonwithstanding.

I don't really understand the argument that the original author gets deprived of anything by a piece of free software being rewritten, certainly not credit. Obviously stealing the name would be a dick move but that's not really what happens 99.99% of the time.

Moreover, often these folks have rare expertise in those subjects, and/or rare willingness to work on them as open side projects. If you tell them this is just something they have to deal with, I wouldn't be surprised if you also remove some of the incentives folks have to keep contributing to OSS voluntarily in the first place. Very little money, and massive risk of losing control, recognition, etc. even if you "succeed"... how many people are still going to bother? And then you get shocked, shocked that OSS is losing to proprietary software and dying.

This is not like that though; moving from a pro-user license to a pro-business license is the reason for being upset, not just losing control over the product.

With the move, any future improvements run the very real risk of being extended then closed off by tech companies.

It's simply hubris for an entire community of developers to look at an existing working product that got popular due to the goal of being pro-user, then say to themselves "we can replace it with this new thing I created, but in order for my new thing to gain traction it must be immediately favourable to big business to close off".

If you view it in that light, then, yeah, you can understand why the upset people are upset, even if you don't agree with them.

> Many of them were upset enough to engage in decade-long lawsuits. But we'd ultimately be in a much worse place if "avoiding making original creators upset" was the primary factor in development, over things like compatibility, bugs, performance, security etc.

Original creators did frequently get upset, but the difference between "some individual forked the code or cloned the product" is very different to "an entire community celebrating a gradual but persistent and constant effort by the same community to move the ecosystem away from a pro-user license".

I hope this gives you some insight into why people are upset, even if you don't agree with them. Most of them aren't articulating it like I did.

Kinda like how the purpose of creating LLVM was to create a more extensible compiler framework, not to create a permissively licensed compiler. As it happens the license of LLVM has not really led to the proprietary hellscape that some people suggested it would, and in any case the technical benefits vastly outweigh the drawbacks. Companies like Apple that do have proprietary compilers based on LLVM are difficult to describe as "freeloaders" in practice because they contribute so much back to the project.

I didn't say it was.

> The purpose of rewriting it is to provide a modernized alternative with some benefits from the choice of language

I did not contend that either.

> and the choice of license is incidental.

This I disagree with - the license choice is not incidental; it is foundational to gain popularity in a hurry, to gain widespread adoption at corporates.

The rewriter's intentions is to gain popularity over the incumbent software; using a pro-user license does not gain popularity for all those pro-business use-cases.

The license switch from pro-user to pro-business is not incidental. It's deliberate, and it's too achieve the stated goal of replacing the existing software.

This is one place where I feel that the ends do not justify the means.

    > 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

I’ve notice a lot of that in base OS systems

Its a curiosity more than anything though

Pardon?

  $ file `which apt`
  /usr/local/bin/apt: Python script, ASCII text executable

? file `which apt`

/usr/bin/apt: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=157631f2617f73dee730273c7c598fd4d17b7284, for GNU/Linux 3.2.0, stripped

You can of course add your own "apt" binary in /usr/local/bin/apt which can be written in any language you like, say COBOL, Java, Common Lisp or Python.

It looks like in trixie, it's libpam-modules that pulls in debconf, which is written in Perl. And libpam-modules is required by util-linux, which is Essential: yes.

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.

For clarity, 'sh' is what is softlinked to dash. Not bash.

And for a good reason. Dash is so much faster for small scripts that call each other. Back in a pre-systemd days, when init was done by a mountain of shell scripts, changing that symlink between bash and dash resulted in twice/half the boot time on some systems.

Please don't make up wrong facts that would be trivial to check first.

All minimal Debian installations include bash as it is an essential package. Where essential is used in the sense of https://www.debian.org/doc/debian-policy/ch-binary.html#esse...

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.

Please show me a project where you believe you "effectively require containers" just to run the code, and I will do my best to refute that.

> since we no longer live in a storage constrained world.

I think you do care about the storage use if you're complaining about containers.

And I definitely care, on principle. It adds up.

For reasons I can only assume have to do with poorly configured CI, pip gets downloaded billions of times annually (https://pypistats.org/packages/pip), and I assume those files get unpacked and copied all the time since there would be no good reason to use uv to install pip. That's dozens of petabytes of disk I/O.

I guess GP meant "containers" broadly, including things like pipx, venv, or uv. Those are, effectively, required since PEP 668:

https://stackoverflow.com/questions/75608323/how-do-i-solve-...

This statement makes no sense. First off, those are three separate tools, which do entirely different things.

The sort of "container" you seem to have in mind is a virtual environment. The standard library `venv` module provides the base-line support to create them. But there is really hardly anything to them. The required components are literally a symlink to Python, a brief folder hierarchy, and a five-or-so-line config file. Pipx and uv are (among other things) managers for these environments (which manage them for different use cases; pipx is essentially an end-user tool).

Virtual environments are nowhere near a proper "container" in terms of either complexity or overhead. There are people out there effectively simulating a whole new OS installation (and more) just to run some code (granted this is often important for security reasons, since some of the code running might not be fully trusted). A virtual environment is... just a place to install dependencies (and they do after all have to go somewhere), and a scheme for selecting which of the dependencies on local storage should be visible to the current process (and for allowing the process to find them).

They are all various attempts at solving the same fundamental problem, which I broadly referred to as containerization (dependency isolation between applications). I avoided using the term "virtual environment" because I was not referring to venv exclusively.

Of all the languages, python in the base system has been an unmitigated garbage fire.

It was not their action, nor is it hacked, nor is the message contained within pip.

The system works by pip voluntarily recognizing a marker file, the meaning of which was defined by https://peps.python.org/pep-0668/ — which was the joint effort of people representing multiple Linux distros, pip, and Python itself. (Many other tools ignore the system Python environment entirely, as mine will by default.)

Further, none of this causes containers to be necessary for installing ordinary projects.

Further, it is not a problem unique to Python. The distro simply can't package all the Python software out there available for download; it's completely fair that people who use the Python-native packaging system should be expected not to interfere with a system package manager that doesn't understand that system. Especially when the distro wants to create its tools in Python.

You only notice it with Python because distros aren't coming with JavaScript, Ruby etc. pre-installed in order to support the system.

If I need a python script, I have to arrange for all the RUN lines to live inside a virtual environment inside the container.

The fact that users have to keep up with multiple PEPs, error messages, --single-version-externally-managed, --break-system-packages, config files everywhere, stealth packages in .local and uv to paper over all of this shows that Python packaging is completely broken.

There's still quite a bit you can do with the "system Python". Mine includes NumPy, bindings for GTK, QT5 and QT6, Freetype, PIL....

> insofar Python allows that with its __pycache__ spam

This is, to my understanding, precisely why the standard library is pre-compiled during installation (when the process already has sudo rights, and can therefore create the `__pycache__` folders in those locations). This leverages the standard library `compileall` module — from the Makefile:

   @ # Build PYC files for the 3 optimization levels (0, 1, 2)
   -PYTHONPATH=$(DESTDIR)$(LIBDEST) $(RUNSHARED) \
    $(PYTHON_FOR_BUILD) -Wi $(DESTDIR)$(LIBDEST)/compileall.py \
    -o 0 -o 1 -o 2 $(COMPILEALL_OPTS) -d $(LIBDEST) -f \
    -x 'bad_coding|badsyntax|site-packages' \
    $(DESTDIR)$(LIBDEST)

Please do not spread FUD.

They don't have to do any of that. All they have to do is make a virtual environment, which can have any name, and the creation of which is explicitly supported by the standard library. Further, reading the PEPs is completely irrelevant to end users. They only describe the motivation for changes like --break-system-packages. Developers may care about PEPs, but they can get a better summary of the necessary information from https://packaging.python.org ; and none of the problems there have anything to do with Linux system Python environments. The config files that developers care about are at the project root.

Today, on any Debian system, you can install an up-to-date user-level copy of yt-dlp (for example) like so, among many other options:

  sudo apt install pipx
  pipx install yt-dlp

Okay so to create a five line script I have to make a virtual environment. Then I have to activate and deactivate it whenever using it. And I have to remember to update the dependenceis regularly. For my five line script.

Seems to me the companies managing mloc-codebases pushed their tradeoffs on everyone else.

> Okay so to create a five line script... For my five line script.

I can guarantee that your "five line script" simply does not have the mess of dependencies you imagine it to have. I've had projects run thousands of lines using nothing but the standard library before.

> Then I have to activate and deactivate it whenever using it.

No, you do not. Activation scripts exist as an optional convenience because the original author of the third-party `virtualenv` liked that design. They just manipulate some environment variables, and normally the only relevant one is PATH. Which is to say, "activation" works by putting the environment's path to binaries at the front of the list. You can equally well just give the path to them explicitly. Or symlink them from somewhere more convenient for you (like pipx already does for you automatically).

> And I have to remember to update the dependenceis regularly.

No, you do not in general. No more so than for any other software.

Programs do not stop working because of the time elapsed since they were written. They stop working because the world around them changes. For many projects this is not a real concern. (Did you know there is tons of software out there that doesn't require an Internet connection to run? So it is automatically invulnerable to web sites changing their APIs, for example.) You don't have to remember to keep on top of that; when it stops working, you check if an update resolves the problem.

If your concern is with getting security updates (for free, applying to libraries you also got for free, all purely on the basis of the good will of others) for your dependencies, that is ultimately a consequence of your choice to have those dependencies. That's the same in every language that offers a "package ecosystem".

This also, er, has nothing to do with virtual environments.

> Seems to me the companies managing mloc-codebases pushed their tradeoffs on everyone else.

Not at all. They are the ones running into the biggest problems. They are the ones who have created, or leveraged, massive automation systems for containers, virtualization etc. — and probably some of it is grossly unnecessary, but they aren't putting in the time to think about the problem clearly.

And now we have a world where pip gets downloaded from PyPI literally billions of times a year.

My understanding of the reasoning is that python-based system packages having dependencies managed through pip/whatever present a system stability risk. So they chose this more conservative route, as is their MO.

Honestly if there is one distribution to expect those kinds of shennanigans on it would be Debian. I don't know how anybody chooses to use that distro without adding a bunch of APT sources and a language version manager.

The tricky part is when "users" start using pip to install something because someone told them to.

As for statically linked system package manager - there is an option for that in Alpine. Not the default though - file/storage size is not the only downside, upgrading also is.

Let's say apt depends on a bunch of libraries, some of which are updated quite often. Whenever any of those are upgraded, you have to recompile that staic binary (or worse, wait for maintainer to do it) and download/upgrade it. That take some time, and in meanwhile you're depending on old library version, which might be broken/vulnerable.

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

But even so - what price correct & secure software? We all lost a tonne of performance overnight when we applied the first Meltdown and Spectre workarounds. This doesn't seem much different.

> We have an alternative that isn't 10x slower, and comes with many other benefits

Anyone involved with development around a fruity company would say Swift ;)

> Critical infrastructure still written in C - particularly code that parses data from untrusted sources - is technical debt that is only going to get worse over time.

But hasn't all that foundational code been stable and wrung out already over the last 30+ years? The .tar and .ar file formats are both from the 70s; what new benefits will users or developers gain from that thoroughly battle-tested code being thrown out and rewritten in a new language with a whole new set of compatibility issues and bugs?

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…

In all seriousness though, let me assure you that I plan to take a very considerate approach to Rust in APT. A significant benefit of doing Rust in APT rather than rewriting APT from scratch in Rust means that we can avoid redoing all our past mistakes because we can look at our own code and translate it directly.

https://github.com/keepassxreboot/keepassxc/issues/10725#iss...

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.

You don't want the core cryptography implemented in Rust for Rust's sake when there's a formally verified Assembler version next to it. Formally verified _always_ beats anything else.

The core cryptographic algorithms, IMHO, should be written in a dedicated language for writing cryptographic algorithms so that they can get formally-verified constant-time assembly out of it without having to complain to us compiler writers that we keep figuring out how to deobfuscate their branches.

Formally verified in an obscure language where it's difficult to find maintainers does not beat something written in a more "popular" language, even if it hasn't been formally verified (yet?).

And these days I would (unfortunately) consider assembly as an "obscure language".

(At any rate, I assume Rust versions of cryptographic primitives will still have some inline assembly to optimize for different platforms, or, at the very least, make use of compile intrinsics, which are safer than assembly, but still not fully safe.)

Take BLAKE3 as an example. There's asm for the critical bits, but the structural parts that are going to be read most often are written in rust like the reference impl.

It seems that for reasons I don't understand this idea isn't popular and people really like hand rolling assembly.

https://github.com/PLSysSec/FaCT

They struggle to guarantee constant time for subroutines within a non-constant time application, which is how most people want to use cryptography.

In contrast, a rust implementation can be compiled into many architectures easily, and use intrinsically safer than a C version.

Plus cryptography and PKI is constantly evolving. So it can’t benefit from the decades old trusted implementations.

(New cryptographic software can also be developed by all sorts of people. In this case I'm not familiar, but we do know that GnuPG worked for the highest profile case imaginable.)

Ironically, it was the urge not to roll your own cryptography that got people caught in GPG-related security vulnerabilities.

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.

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?

No. Rust is not magic, it just forces a discipline in which certain safety checks can be made automatically (or are obviated entirely). In other languages like C, the programmer needs to perform those checks; and it's technical debt if the C code is not coded carefully and reviewed for such issues. If coding is careful and the code is review - there is no technical debt, or perhaps I should say no more than the unsafe parts of a rust codebase or the standard libraries. And the safety of critical infra code written in C gets _better_ over time, as such technical debt is repaid.

> Rust is explicitly designed to be what you'd get if you were to re-create C knowing what we know now about language design and code safety.

That's not true. First, it's not a well-defined statement, since "what we know now" about language design is, as it has always been, a matter of debate and a variety of opinions. But even regardless of that - C was a language with certain design choices and aesthetics. Rust does not at _all_ share those choices - even if you tack on "and it must be safe". For example: Rust is much richer language - in syntax, primitive types, and standard library - than C was intended to be.

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

And the answer to "why now" is quite simple - Because of the whole Rust in kernel debate, people started scrutinizing the situation.

People who become aware of something only when it’s being used by something huge also aren’t early adopters either. Rust has already been in the Windows kernel for years at this point, with none of this consternation.

According to what?

> Rust is explicitly designed

There is no standard. It's accidentally designed.

> knowing what we know now about language design and code safety.

You've solved one class of bugs outside of "unsafe {}". The rest are still present.

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

No, just that it's not 1968 anymore, and if you want to claim your language has learned lessons from the past, then this is one that clearly got missed.

> The phrase "design by committee" isn't typically used as a compliment...

While the phrase "emergent incompatibilities" is only known as a detriment.

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

Again, I ask for a reference, "according to what?" I understand this is the zeitgeist. Is it actually true? It seems to me this great experiment is actually proving it probably isn't.

> This kind of deflection and denialism isn't helping.

Once again, I asked for proof that the claim was true, you've brought nothing, and instead have projected your shortcomings onto my argument.

> And I'm saying this as someone who really likes C++.

Have you ever pushed for C++ to replace C programs because you assume they would be "better" according to some ill defined and never measured metrics?

> Again, I ask for a reference, "according to what?" I understand this is the zeitgeist.

I think that at this point it is pretty well-established that the majority of security CVEs in C or C++ applications are caused by memory safety bugs. For sources see https://www.cisa.gov/news-events/news/urgent-need-memory-saf.... As a C++ dev this totally makes sense. (I just happen to work in a domain where security doesn't really matter :)

IOW, what's your specification?