Hacker News Reader

Comment by sdkmvx | Hacker News Reader

OpenBSD supports a number of odd and unusual platforms and does builds on them. See http://www.openbsd.org/plat.html. Older hardware can both use a significant amount of electricity and require much more hand-holding than is possible. Virtualization and emulation are not acceptable substitutes because they claim that doing builds on e.g. VAX is one of the best ways to ensure that the code works on VAX as opposed to simply booting on VAX. They also regularly find bugs affecting all platforms that are exacerbated by one particular architecture (think alignment or endianness issues).

View on HN

OpenBSD's main value is high security standards.

- Is there a significant amount of people with high security standards and an interest in SGI workstation hardware?

- What about people who have high security standards and Sharp Zaurus hardware?

If these groups aren't as important, as say, ARM and x86 users, perhaps it could be worth dropping some of these platforms?

As a longtime OpenBSD fan and advocate, this has always fascinated me. I loved SGIs back in the day but they are slow as shit today and unusable for any kind of modern desktop usage unless all you do is write code in a terminal. These platforms survive in OpenBSD land because somebody still cares enough about them to enjoy hacking on them. There's no point in saying "Drop them!" because the devs working on them probably could care less what the rest of us think.

Personally, I do wish OpenBSD could somehow regain the popularity it once had and that support for modern hardware like 10GBE and scaling PF throughput w/ multi-core CPUs would improve. I don't know what it would take to bring people back.

>There's no point in saying "Drop them!" because the devs working on them probably could care less what the rest of us think.

If it's worse for the rest of the ecosystem, there's a point.

Is that clear? It's not as if when SGIs are taken away, developers efforts will seamlessly efficiently shift to amd64. I like to think that "oddities" like SGI are data-points to test against, and help keep abstraction alive by disallowing traps like pretending that everything is an x86.

I'd be interested to hear whether or not this is the case from people closer to such a condition, though (ie: OpenBSD, NetBSD, ???).

If they would rather refuse free hosting and will "not allow the conversation to that way" then it means they want to keep support for some physical hardware that's hard to find in existing datacenters.

This is like saying "I don't care if my arcade goes out of business, I'm going to keep the power hungry cabinets alive even though they only get used once every 3 years."

Why should everyone else pay the 20K to subsidize ancient hardware support? If there really is a subset of people who really really depend on this, then they should be forking up the cash to pay for something that could be had for free elsewhere if support was restricted to 95% of the platforms in use by the vast majority of people.

If there is an argument that maintaining this will somehow improve security overall and not just on ancient hardware then I would love to see it. But if the Devs working on it could care less of what the rest of us think, then maybe those Devs should pay their electricity bills to support their toy platforms because I could care less about what they think too ...

That is the argument. Obscure kernel and driver bugs are frequently only made apparent as edge cases on said ancient weird hardware, but the fixes benefit all platforms from a code-correctness point-of-view.

But many of those old hardware platforms can be emulated. So if their reason of existence is only triggering edge cases, there are other ways to do so.

Emulation isn't guaranteed to manifest the same edge case issues that surface these defects, though.

Then again, it's possible that emulation could surface other edge case issues. That's completely orthogonal to the value of non-emulated archaic architectures for this purpose, however.

Actually most can't be emulated because emulators don't exist and those which can typically can't be emulated correctly (Sparc emulators for example which are notoriously sparse and bad quality).

Some of the architectures also have different endianess and incredibly complicated peripherals to the cost effective host machines as well meaning that it's actually more power efficient to run native. A headless 100MHz VAXstation for example draws less power than the equivalent host that would be required to provide a full, accurate emulation with peripherals. These aren't arcade machines.

OTOH, the preservation of such historically relevant architectures would benefit enormously from emulation. This is an aspect that should get some attention and which could, possibly, open up another funding avenue to the project as a side effect.

Not really. The OS syscall interface, ABI and the fact everything is abstracted via your C compiler normalises the differences between the machines pretty well meaning you only end up dealing with portability issues.

Portability issues is where real hardware benefits. It's where you have battles of unusual register sizes, endianess, host/network order differences, different memory models and memory protection, different performance characteristics, different timings and different exploits.

Unless the emulation is 100% accurate, including timing, which is a really difficult thing to do (look at the effort MAME goes to), then the benefits over real hardware is moot.

Emulators are also expensive to write due to the above, have their own bugs and don't always recreate the bugs in the real hardware (which are sometimes exploitable).

I was thinking about MAME (more specifically, about MESS). If two groups benefit from a single effort, it seems to be an good investment, even if it costs nearly twice as much.

Also, using emulated hardware could cut down the usage of the real pieces, which could then be better studied and preserved. Doing less builds on vintage hardware is, actually, a good idea.

"... and unusable for any kind of modern desktop usage unless all you do is write code in a terminal."

Sounds good to me. Many times (actually most times) I have no need for a "desktop" metaphor on my screen in order to get things done. I actually get more done big jobs done faster without the desktop metaphor in the way.

"... the devs working on them probably could care less what the rest of us think."

That's what makes them so special.

Perhaps in the long run the most "powerful" and sought after computers will not be the ones with the latest chips, but the ones that the user has the most knowledge of and control over.

Can you imagine the old-timer reminiscing: "Remember when computers didn't have backdoors built-in?" or "Remember when you did not have to pay for a license to write programs for hardware you bought?"

But if the project stops keeping obsolete build machines around, they would save on electricity bills. Hackers could still hack, they just wouldn't be killing the project with legacy support costs.

Read further into the thread -- specifically the messages from asshat Theo. He is absolutely opposed to anything like that.

http://marc.info/?l=openbsd-tech&m=138973312304511&w=2

"I really love how we keep getting advice. Anyone want to suggest we hold a bake sale?"

I think if you're openly soliciting donations under the premise that they're essential to keeping the project running at all, you can put up with the people you're trying to get money out of asking questions to ensure that the money you're asking for really is as needed as you say it is.

Not Theo.

He clearly says things like "that's not up for discussion", "I'm not going into details", etc.

If anyone ever truly deserved the title BDFL...

I think if you ever use OpenSSH for anything whatsoever, you can put up with a grumpy Theo.

Especially since he is almost always technically correct--the best kind of correct.

What OpenBSD foundation really needs is a tactful and charismatic person to act as firewall and pf between Theo and the people with overflowing bank accounts, who are more accustomed to dealing with obsequious salesdroids than a person who is not only ten times smarter than their entire golf group put together, but also so aware of it that he cannot hide how much of a waste of time it is for him to suck up to any one of them, no matter how much he could use the cash.

Do you think Apple would have gone anywhere if Wozniak was the one talking to all the investors?

No, what OpenBSD needs is a broader FOSS community that doesn't turn every bump in the road into a referendum on bruised feelings from years ago, and recognizes its indebtedness. I type 'ssh' how many times a day?

Not that I don't understand those feelings. I've spent enough time lurking on openbsd-misc to have seen Theo and friends be beastly. But never without some provocation. And one might wish better impulse control on any number of online personalities.

(And if you find this rude, note that I'm not involved with OpenBSD -- not even on the mailing list anymore -- so blame me, not 'the OpenBSD community'.)

I'm not sure the "B" applies, unless it's from the same acronym as BOFH.

I may or may not agree with you, but don't call people asshats on HN.

He's earned it. He is however technically excellent.

The important part of sdkmvx's comment is that those SGI workstations help find bugs that also affect x86 users. The more diverse ecosystem makes it easier to reliably detect and reproduce tricky race conditions, endianess bugs or memory management mistakes.

From Theo de Raadt, on-thread:

  On a regular basis, we find real and serious bugs which affect all
  platforms, but they are incidentally made visible on one of the
  platforms we run, following that they are fixed.  It is a harsh
  reality which static and dynamic analysis tools have not yet resolved.

I was trying to think of a good way to say exactly this, but he says it better (and more authoritatively) than I ever could. Broad platform support is a significant factor contributing to overall quality in products like *BSD, and it's apparent in looking at the source.

We used to maintain SGI boxes for this same reason but we've pulled back. The main benefit we got from older RISC stuff was that they bitched about unaligned loads. If you are going to support any of those models you need at least one box like that in your cluster. SPARC was faster than MIPS so we kept SPARC.

I think Theo could probably thin down the cluster and still be good but maybe I'm wrong and he'll show up with examples that require all of that hardware. That would be interesting because in our case we've sorted out the problems and rarely see things blow up on the RISC boxen.

You appear not to realise that SGI hardware contains MIPS CPUs. A large amount of code is shared between these platforms:

http://www.openbsd.org/sgi.html http://www.openbsd.org/octeon.html http://www.openbsd.org/loongson.html

A mips32 port would also be very desirable for all those shitty little routers with their ancient Linux kernel, but sadly nobody is working on that at the moment.

So, should the network and firewall OS that many people claim OpenBSD is, slash its support for MIPS devices?

There's probably a few hobbyists that still use SGIs. Octeon is mostly commercial vendors, who could pay for all of OpenBSDs needs out of their fancy executive toilet paper budget. And there's one OpenBSD hacker who uses Loongson, even GNU cult leaders use GNU/Linux on Loongson instead.

More than one OpenBSD hacker used loongson

If you want to support MIPS for embedded applications then loongson is one of the fastest and cheapest ways to run stuff right now.

How's availability outside of China? I'm not finding many of these systems in the US.

I don't know about the US but there is a place in the Netherlands that says they have netbooks and small systems in stock.

Good point, I didn't know MIPS is still used in the embedded space, I thought it was all ARM these days.

But OpenBSD could be testing on an embedded MIPS development device at any data center they want.

MIPS is on the rise again as recent SoCs are more power efficient than ARM. I don't have a source for this unfortunately.

Sony Bravia EX series televisions are MIPS and Linux based for example.

It's not power efficiency, it's money.

MIPS SoC licensing is less expensive than ARM licensing at the smaller volumes inherent in low-end routers (.vs phones and tablets).

Except, Sharp Zaurus is ARM.

There's generic rack mountable ARM boxes. They don't need a Zaurus in their datacenter.

I don't see why they're proposing a all or none situation when they could choose to move and in doing so, limit the number of platforms they support. If anyone complains about a specific platform being dropped, well have them pay for the overhead associated with it.

Theo says it's because if they drop $platform, they'll lose the devs that like working on $platform who quite possibly work on @other_platforms as well.

So Theo would rather shutdown instead?

Change is hard, but I think it's worth a shot. And you never know maybe spending more time focused on real needs will create a better product from all the extra attention given to things that are work worthy.

Realize that funding for OpenBSD has been an ongoing problem for decades now. Theo would like to focus exclusively on managing the project, but instead he has to keep dropping everything to deal with the funding problem.

And, the OpenBSD development team has contributed a lot to the software community, so it's extra frustrating not to get enough support back.

I'd expect that at some point it just stops being a fight you want to keep fighting.

Reply on news.ycombinator.com