Bizarre that he thinks a language or compiler is doomed unless it can compile itself on each platform it supports. Microcontrollers and cross-compilation wouldn't exist if that were the case.

I think it was more the implication that requiring more than 2GB of RAM to compile itself was an indication of its profligate resource usage.

That doesn’t seem like an especially strong argument since computing is full of time/space trade-offs and 2GB of RAM hasn’t been a significant amount for over a decade at this point (X86-64 only goes back to 2003 but it was a latecomer following Intel’s epic failure to deliver Itanium). Things like whole program optimization seem like a reasonable trade off for <$20 worth of RAM.

How much of that is Indicative of rustc vs llvm? The latter isn't exact a lightweight piece of software.

Until there is a rustc in production that doesn't use llvm to emit code in the backend, the point is moot, no?

To me the question is moot if the problem is llvm. I don't know if that's the case or not.

Modern tools require modern hardware. If the problem is that the target constraints don't allow modern tools to be used, the problem is the constraints and not the tools.

But maybe I just don't understand their stance here.

Depending on what you are working on / with, you may not be able to choose your constraints.

Constraints that you cannot change can certainly dictate what tools you have to choose from.

No, I don't think so. If LLVM is at fault then the issue is definitely not inherent to Rust the language or Rust the development culture.

Your code is what it depends on. If you are picking dependencies with no concern for the overhead they introduce, well, it says everything it needs to say: you value that dependency over the associated overhead it introduces.

Asking an OS to adopt those same preferences, without any appreciation for their needs or preferences is pretty rude and arrogant.

A better solution would be to ask “what would it take, because I’d like to understand your needs”. Maybe then Theo could help you understand their constraints. Trying to argue with him that he needs something he clearly doesn’t isn’t very nice and won’t get a nice response if you push it too far.

You are ultimately responsible for your dependencies. No program is innocent of its dependency graph.

Interesting point.

Does anyone know how much memory is needed to compile llvm+clang? GCC?

That varies widely on your linker and how many threads you use. I have compiled LLVM on systems with 4 GB of RAM, though; but have been forced to fall back on single-threaded compilation.

IDK about compiling llvm/clang, but using clang/llvm needs far less memory than gcc. I've used clang in machines with less than 256mb of RAM.

It seems like a number of *BSD projects are generally in favor of llvm and clang, in part because they dislike GNU/FSF.

I know OpenBSD supports some more esoteric hardware that LLVM probably will not target, however.

Well OpenBSD has this "dumb" rule that snapshots/releases are never cross compiled and be done on real hardware. So it's pretty much a rule that every hardware platform has to be self hosting.

Microcontrollers are the exception, but then they don't run a full blown OpenBSD stack anyways.

I don't know what project this is but a blanket "add a test which fails without your patch for EVERY PATCH no exception" rule is a bit cargo-culty.

Especially since the kind of test you're asking for, when written by a developer who is less than passionate about writing such a test but rather more passionate about just solving the problem his patch addresses, is probably not going to be worth much compared to a properly thought out set of tests which target the class of problems which the patch solves. Or possibly even an adjustment to existing tests on the basis of what the patch solves.

Finally, surely you get plenty of patches which do small useful things like cleanup but which it would likely be impossible to write a test for.

If you're saying great tests are better than adequate tests, nobody's disagreeing. But untested code puts a variety of burdens on project maintainers. I don't see why maintainers should be obliged to take on that burden when the person wanting the patch won't bother.

Also, I don't see your quoted rule in the post you're responding to. Instead I see them saying that in a specific case, they ask for tests with patches. How did you get from that specific case to such a universal, no-exceptions rule?

> I don't know what project this is but a blanket "add a test which fails without your patch for EVERY PATCH no exception" rule is a bit cargo-culty.

We had (and still have) 100% code coverage on Windows MSVC, Windows GNU, MacOS, iOS, Android, Linux, FreeBSD, NetBSD, DragonflyBSD, Solaris, WASM, and many other platforms, as well as all possible hardware (ARM32/64, x86/x64, ppc32/64/be/le, sparc64, mips32/64/be/le, mips64, riscv32...).

The OpenBSD parts of our code base weren't tested at all; they weren't even compiled.

In practice that meant that pretty much every PR broke the OpenBSD support in some subtle way, and people would only discover those failures during the release process, which took a lot of time to fix, usually from somebody that did not care about OpenBSD at all, requiring them to create a VM to be able to develop and test from OpenBSD itself.

So yeah, we decided to unanomously require that code that cannot be tested be removed, and gave the OpenBSD devs the chance to fix it. Starting with requiring OpenBSD contributor on their PRs to add testing support.

It wasn't practicable because their platform is designed to prevent non-OpenBSD users to develop for it. So we removed the code, and this became some OpenBSD user group problem.

This solution actually worked better for them, because it became up to them to decide when new versions of our project got released for OpenBSD, so they could get the latest release, apply patches, test that it compiled locally and passed tests, etc. before doing a release for OpenBSD, something that we did not care about doing.

We believe that code that isn't compiled doesn't compile, and that code that isn't tested doesn't work correctly. Our OpenBSD parts were living proof that this is 100% true.

I find it quite ironic that this project is security related, and some of the bugs that hit OpenBSD were CVEs that were completely preventable. This CVEs only hit OpenBSD because it was the only untested platform. In a sense, OpenBSD users actually were quite lucky, in that most releases broke compilation for OpenBSD, and that saved them from many CVEs. Unluckily for them, not all bugs result in compilation errors.

> Finally, surely you get plenty of patches which do small useful things like cleanup but which it would likely be impossible to write a test for.

We have 100% code coverage. All our functionality is heavily tested and fuzzed. The modifications in a cleanup PR are exercised by many tests, and therefore tested.

If someone submits a bugfix, that means we were missing a test, so we require users to add one. OpenBSD devs weren't able to do that, so we stopped accepting their bugfixes, and at some point removed all the code.

If you don't think that bugfixes should be accompanied by tests that check that the fix works and the bug cannot be reintroduced again, then I disagree with you, and hope I never have to use your software.

> This is pretty much a judgment of Rust:

I guess. It's really a judgment of Rust (specifically the compiler toolchain) for this one use case.

> I would think that OpenBSD developers/users would care about security,

Maybe. Again, I think "cat" and other system tools are really low on the list of priorities for anyone securing a system. Not to say that they don't represent attack surface, by any means, but there are just a lot of things to do before rewriting the utility entirely.

“cat” and related tools make perfectly interesting exploit targets on Unix systems that follow the Unix philosophy:

https://www.cvedetails.com/cve/CVE-2014-9471/

There is a big difference between being having vulnerabilities and being valuable attack surface. Again, I am not saying that cat and others do not provide attack surface, or even valuable attack surface, only that step 1 is not "rewrite cat".

Generally "cat" is not exposed to the internet, and if you're running a service and you said "I'm concerned about local attackers using cat" it's probably a lot easier to just put the service into some sort of environment (container, sandbox, user, whatever) that doesn't give access to cat.

> step 1 is not "rewrite cat"

Totally agree on this point. In fact, I think it’s brash for the rust armada to think that the borrow checker alone is going to help replace 20+ years of maintenance on these kinds of tools, which often crufty, and gnarled by the sands and whims of generations that preceded us.

As a member of the Rust Armada I can tell you that I don't believe that rewriting cat in rust is something I consider a high priority.

That's not BSD cat, that's GNU cat. And I am using AWK and KSH + dcgi in my Gopher server with a chrooted root gopher hole, it works fine.

In fact, it’s neither, it’s coreutils (gnu, yes) `date`. My point is that seemingly innocuous system utilities do make for exploit targets, because folks shell to them.

Yes, you can lock things down with jails/containers, but it’s a valid target. Defense in depth, and all that jazz.

They do care about security. They just don't care about Rust.

They can not care about more than one thing.