Hacker News Reader

Comment by hvs | Hacker News Reader

This is pretty much a judgment of Rust:

  Such ecosystems come with incredible costs.  For instance,
  rust cannot even compile itself on i386 at present time
  because it exhausts the address space.

  Consider me a skeptic -- I think these compiler ecosystems
  face a grim bloaty future.

I would think that OpenBSD developers/users would care about security, since that's pretty much the value-proposition of OpenBSD.

View on HN

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.

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?

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.

Interesting point.

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

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.

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.

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.

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.

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.

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.

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.

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

Reply on news.ycombinator.com