On 01/25/16 13:55, Adam Thompson wrote: > On 16-01-23 08:34 PM, Ted Unangst wrote: >> I will add that one of the reasons we have support for all these >> museum pieces is that people can build their very own museum and run >> something interesting on it. But running on emulators doesn't really >> satisfy that goal. If there are, in fact, no museum pieces left in the >> world, we no longer need to supply an OS to run on them. > > Huh. Previous discussions had led me to believe that the OpenBSD > project's rationale for supporting all these various architectures was > that it ultimately resulted in much-higher-quality code because > platforms like VAX and SPARC64 acted as canaries for suboptimal coding > practices?
and emulators have little to do with this. *BOOM* why did it just crash? bad code? Bad emulator? Ah, here's a fix to stop the crash! But what did we fix? Did we just code to the emulator instead of the hardware? Real hw often has real bugs. Emulated hw has ... different bugs. > (Endian issues, stack issues, framing issues, alignment > issues, etc., etc., etc.) The ultimate rationale is "because people wanted to" -- that meant more than being able and willing to power up a machine and build stuff, it meant USING the machines for day-to-day work. And there's the problem. It's almost impossible to justify using a SPARC or VAX or most other non-i386, non-amd64, non-ARM systems anymore. For a number of years, and until about six months ago, I used a Sun E250 as my primary writing/showing (webserver) machine. It did the job great, and I was patting myself on the back for "helping the project" by running something, well, "odd". But why was I running a Sun E250? What could it do better than anything else for me? When my E250 did something strange (which it did from time to time), there wasn't much that I (as a non-coder) could do about it...nor was there much interest in "fixing" these power-hungry slugs by those that could. They didn't have one, and they didn't want one. How much was I helping OpenBSD by running on an E250? Close to zero. Could have helped a lot more if I took the money spent on power and air conditioning my basement and sent it to the group. Yes, running on diverse hw does help improve the portability of code -- IF it doesn't get in the way of other goals. The slow stuff is definitely getting in the way of advancing OpenBSD in more important areas, like amd64 security, these days. 15 years ago, when the performance difference between the fastest and slowest platforms was maybe an order of magnitude or so, it wasn't a big deal to drag along the slugs. Today, there are several orders of magnitude between the fastest modern platforms and fastest samples of "relic" platforms (IF they still run!). It's a problem. > Besides, I thought the run-on-everything-and-anything (including the > verging-on-absurd) was NetBSD's thing, not OpenBSD's? See > http://netbsd.org/ports/, make your own opinions on which platforms > verge on the absurd... well, perhaps it is appropriate that someone "fork" OpenBSD to do the same thing, more honestly. Want to run an MVME88k? GREAT! Here's OpenBSD/mvme88k v5.5. Mac Quadra 650? Here's OpenBSD/mac68k v5.1. Amiga? Here's OpenBSD/Amiga v3.2. Want to run on an 80386? Here's 3.3. pmax? Here's 2.7. Not a real fork, in that there would likely be no (or very minimal) active development, just someone with some bandwidth and time on their hands to run a website, a support list (NOT OpenBSD's mail lists!), and a logo (a zombie blowfish? "uhhhhh... cycles.... cycles!!!!") Really, if you load OpenBSD on a mac68k, you aren't doing it to WORK, you are doing it to see a modernish OS on your old relic. Great, enjoy! Don't slow down OpenBSD's security work on relevant platforms for relics. Meanwhile, there ARE platforms that are still borderline useful. MacPPC, Sparc64 need people to RUN them for real life work, and improve them for relevancy, as naddy@ said. Nick.
