Hacker News Reader

Comment by accurrent | Hacker News Reader

He has a point though... As we get more CPU/ram we as programmers don't even bother to check how many resources we are using. Personally, I don't know whether its a good thing or a bad thing. Also in terms of systems languages I believe only rust has some potential to truly replace C. Although, a large part of C usage still takes place in the embedded world where rust has yet to be ported to many embedded processors. Go's GC makes it a show stopper for use in many places as for haskell I would be very interested to see more low level embedded programming going on in it.

View on HN

> He has a point though…

Does he? He "stat[es as] fact" that

> There has been no attempt to move the smallest parts of the ecosystem, to provide replacements for base POSIX utilities.

which as xwvvvvwx notes is categorically wrong, then points out that rustc can't compile itself on i386, which is relevant… how?

> then points out that rustc can't compile itself on i386, which is relevant… how?

Remember he is speaking as the leader of an operating system project. As in, a basic part of the project functioning normally is compiling the whole thing from scratch. If something needs cross-compilation to even get started it won't end up in OpenBSD base.

I seem to recall when it supported more architectures they made a public show about how they weren't going to cross compile even for targeting wimpy/sluggish machines, because recompiling the OS was a good stress test for the kernel itself.

And thus they lock themselves into the lowest common denominator as they target smaller systems. This is ridiculous. OpenBSD looks like performance art, literal security theater.

> And thus they lock themselves into the lowest common denominator as they target smaller systems. This is ridiculous. OpenBSD looks like performance art, literal security theater.

Those lowest common denominator systems tend to find bugs not present elsewhere.

And stating that openbsd looks like performance art and security theater seems to indicate you haven't looked at what openbsd has done for security.

OpenBSD can be security theater and still do great things. But at some point sticking to an 90s Unix/C aesthetic looks deeply anachronistic.

Yes, bugs are found at boundaries and interfaces, large or small. Something has to be different for the output to be different.

If someone writes a bug proof TLS implementation while at the bottom of the pool wearing SCUBA gear, it is still security theater.

Do you use it? I have had it on one machine or another since around 2000, and I have by and large been pretty happy with it. Not every personality type will like it, and sometimes they do make odd decisions, but it is pretty well put together.

Another point about the *BSDs, something doesn't have to be in base for you to use it. The base system is supposed to be small and not have a lot of dependencies. You are free to use things in ports and packages or compile them yourself. So this is not the same as never being able to use rust.

> then points out that rustc can't compile itself on i386, which is relevant… how?

I'm actually gobsmacked this is the case. There used to be a saying, only half-joking, that a language that can't host/compile/bootstrap itself is nothing more than a toy. As others have more eloquently pointed out, it shouldn't have to be explained why people who write operating systems and compilers would consider that a no-go.

Eh, 64-bit desktops were becoming common a decade ago. Considering the small minority of developers using a 32-bit machine for development, I don't see that it is worthwhile to spend effort on that.

Note that Rust can (and does) target various 32-bit platforms (ARM and maybe RISC-V, not sure) for cross-compile. Self-hosting on a 32-bit platform is such a minor drawback these days. 64-bit ARM processors are becoming more common these days as well.

There are still plenty of 32bit machines out there. I personally have maintained and support a Intel 4004 knockoff used for controlling a big industrial machine. And of course more modern variants of the same machine with an 8008. Some of these couldn't even run DOS but it's still supported.

32bit is not even close to be being that old and lots of machines, applications or platforms require it and they need maintenance. Especially OpenBSD is a system that I as a Linux-fan recognize for supporting old hardware much better than Linux.

And it's not only 32bit x86, there is plenty of other architectures limited to 32bit, mostly from the ARM sector but I believe some older MIPS and other even more exotic arch's are supported.

If rust can't selfhost on x86 how can we expect it to selfhost on more exotic 32bit hardware that BSD supports?

Oh, I wasn't implying that OBSD or NBSD should adopt Rust as a development language. Not at all.

My point is more that I wouldn't want the Rust developers to spend time on making it able to self-host on 32-bit platforms. I'd prefer they spend their time elsewhere, that's all.

> I'd prefer they spend their time elsewhere, that's all.

And I'm sure the OpenBSD developers would prefer to spend their time on OpenBSD instead of working around Rust's lack of support for a platform that OpenBSD supports. I'm still kind of surprised that when the question of "why doesn't OpenBSD switch to Rust?" and the answer was "because Rust doesn't self host on a platform we support" that the response has been "well drop that platform." How about: no. How about: if someone wants Rust to be a viable option, then they have to adjust Rust to be a viable option, not ask other projects to massively constrain their currently working support of a platform.

I hate to sound like the old geezer, but I get the impression that many people here have no clue about software beyond desktop and mobile. It's like they don't even realize that firmware and operating systems have to be written and maintained on older hardware. There is a lot of software out there running on legacy hardware that the world depends upon which you never see.

> I'm actually gobsmacked this is the case.

So gobsmacked you apparently couldn't even begin to attempt answering the question but felt you just had to go on a rant as irrelevant as you believe it's righteous, uh?

> There used to be a saying, only half-joking, that a language that can't host/compile/bootstrap itself is nothing more than a toy. As others have more eloquently pointed out, it shouldn't have to be explained why people who write operating systems and compilers would consider that a no-go.

Rust has been self-hosted for almost as long as it's existed. The boostrapping OCaml compiler was left behind back in 2011.

> Rust has been self-hosted for almost as long as it's existed. The boostrapping OCaml compiler was left behind back in 2011.

Not on x86 which is what this whole conversation is talking about. So if OpenBSD used rust in base they would have to drop support for x86.

We haven't even gotten to alpha, hppa, loongson, luna88k, macppc, octeon, sgi, or that backwards beauty of big-endianness, sparc64. But hey, it compiles on amd64! That should be good enough, right?

He's talking specifically about OpenBSD base. Unless you can point to a rust binary in OpenBSD that Theo forgot about, he's not wrong.

i386 is relevant because OpenBSD supports i386.

> He's talking specifically about OpenBSD base.

No, he is very explicitly saying that

> There has been no attempt […] provide replacements for base POSIX utilities.

Which once again is categorically false, a github repository purporting to do exactly that has been provided.

> i386 is relevant because OpenBSD supports i386.

i386 is supported, the issue is compiling the compiler on i386.

> i386 is supported, the issue is compiling the compiler on i386.

which is required for the system to be self hosting

seriously - what is being said is this:

" oh hey lets throw away the functional and perfectly good entire base set of utilities for this 1/2 complete project on github using a language that doesn't even natively build on all of our supported platforms and wouldn't even remove the need for a C compliler in base, and further complicate the base toolchain, not to mention breaking all kinds of other builds which use shell utilities expecting certain behavior, etc ,etc, etc, because somone thought it would be 'neat' to do this. And whyyyy aren't you taking me serously??? "

every few days (hours?) some noobish person desides to ask some fantasy question about whatever topic of interest they are noobing about on openbsd (and other OS) discussion lists, and then gets whiny when they are being called out for being 'green' about life itself. this is another of those cases, and I have no idea why it got crossposted here or upvoted.

Thank you for saving me the trouble of writing that.

> every few days (hours?) some noobish person desides to ask some fantasy question about whatever topic of interest they are noobing about on openbsd (and other OS) discussion lists, and then gets whiny when they are being called out for being 'green' about life itself. this is another of those cases, and I have no idea why it got crossposted here or upvoted.

this sort of attitude is astoundingly hostile and toxic for an open source community to hold.

I agree, but understand how tiresome it can get when people who -- understandably -- don't know any better do a drive-by of your project and suggest things, things which have often already been discussed to death, or don't even need to be discussed because anyone knowledgeable about the project would immediately see there's no need for discussion.

Now, that doesn't mean that a hostile rebuff is required or good policy, but random people who actually do not know what they are talking about, and haven't taken the time to learn enough to know what they're talking about, don't really deserve a long, in-depth, drawn out rebuttal or discussion.

> There has been no attempt to move the smallest parts of the ECOSYSTEM to provide replacements for base POSIX utilities.

You deliberately cut out the part which states he's talking about the ecosystem of OpenBSD, in an OpenBSD mailing list. That is an extremely disingenuous and uncharitable cherry-picked interpretation. He was categorically talking about efforts to port OpenBSD utilities to such a language and merge them into the project (i.e. the OpenBSD ecosystem). What you're suggesting he said is just plain FUD.

And if the end user is unable to compile everything, i386 would be only half-supported (or maybe, for the austere OpenBSD maintainers, not supported at all).

I think it is important for us to think more on the resources, for programs we write consume, when: they are compiling, they are executing and when they are just "dormant" on persistent memory. Experience and history shows that the bigger the program is, the more resources it needs to function, the more bugs it has, which consequently makes it more difficult to debug and prone to failure.

I run full Windows 10 on a tablet (dual core, 2GB RAM), and it's pretty amazing to me how many websites that have no reason to run slow completely fail on it.

I can only imagine it works fine on dev machines with much faster quad+ cores and 64GB of RAM or whatever.

Just as an aside, it's done a lot to have the tablet be my primary "fiddle-at-home" machine: keeps me really conscious of resource limits, including ones I normally don't think of like screen size. (Most websites render terribly in landscape on a 10" tablet.)

Win10 just doesn't work well on 2GiB. Compressed pages are nice but not enough to prevent swapping. It also doesn't help that MS prevents you from running 32-bit on modern hardware to alleviate some of the memory pressure.

The solution is to install 32-bit Linux on it. Then it won't suck.

Windows works great, the issue is the applications, and indirectly the developers of said applications, some of which are on HN.

Most applications are requesting hundreds of megabytes if not entire gigabytes, the system will swap to death after you open an app and a browser tab on facebook.

I remember a friend who bought a 2GB netbook, the thing froze to death whenever he opened just eclipse, he had to return it.

Or i386 OpenBSD.

Reply on news.ycombinator.com