alpha Digital Alpha-based systems
amd64 AMD64-based systems
armv7 ARM-based devices, such as BeagleBone, BeagleBoard, PandaBoard ES, Cubox-i, SABRE Lite, Nitrogen6x and Wandboard
hppa Hewlett-Packard Precision Architecture (PA-RISC) systems
i386 Standard PC and clones based on the Intel i386 architecture and compatible processors
landisk IO-DATA Landisk systems (such as USL-5P) based on the SH4 cpu
loongson Loongson 2E- and 2F-based systems, such as the Lemote Fuloong and Yeeloong, Gdium Liberty, etc.
luna88k Omron LUNA-88K and LUNA-88K2 workstations
macppc Apple New World PowerPC-based machines, from the iMac onwards
octeon Cavium Octeon-based MIPS64 systems
sgi SGI MIPS-based workstations
socppc Freescale PowerPC SoC-based machines
sparc64 Sun UltraSPARC and Fujitsu SPARC64 systems
Now that LLVM/Clang is in, the potentially viable platforms (i386/amd64/armv7?) can work toward switching, while gcc4 remains for the ones that can't yet. I believe m88k is only gcc3 platforms left, but there's a very passionate guy in Japan interested in keeping his OMRON LUNA-88K and LUNA-88K2 workstations alive.
This may all seem strange, but OpenBSD has always strongly been against cross-compiling beyond perhaps initial platform bring up. This means being able to compile a release and packages on the physical machine must work.
m88k and sh4 are the odd ducks, and if there were a backend wow that would be painful to build llvm on natively :)
Were they cool in their day? Sure. But the consumer router you use to hook up an O2 or an Octane to the internet has a more powerful MIPS CPU.
It also helps to have systems that are slow or have low memory, occasionally they hit bugs that are unnoticed on modern hardware.
Alpha may have been interesting in that it had some peripheral similarities to PC machines, but were actual 64-bit computers in the 90s. For kernel driver hackers, popping in a PCI network card that was probably never tested on anything besides a x86 PC, getting it to pass packets, and then making it your home firewall, was a thing of beauty.
I think that trying 'oddball' platforms indeed help shaking out bugs. But if that's the goal (rather than supporting the five users that still use such hardware), wouldn't it be more attractive to build pseudo-platforms in an emulator that simulate other architecture choices, and run it on fast and easy-to-get x86_64 hardware?
That said, the real reason these platforms continue to exist because volunteers continue to maintain them. You would have to ask those individuals what value they derive from the hobby.
If anyone knows some similar example please let us know.
Yes, you could do an image loader for HP-UX bins on another OS, but that level of technical competence is rare.
The reason why OS people do ports - portable software is good software. Avoiding ISA monoculture avoids shortcuts in kernel architecture. Some ISAs (alpha, sparc64) easily trigger invalid assumptions on ordering, alignment, endianness, etc improving overall quality. Alternative archs are also a great way to learn about areas of the system that are "done", so you can go fix and improve the things that were assumed to be "done" once you have requisite background.
Which consumer routers have 64-bit MIPS CPUs? I thought they'd mostly settled on mediocre 32-bit CPUs.
OpenBSD does have a port for the ER series, but it's separate from the SGI MIPS ports:
(I just realized that's a pretty subjective question but I actually am interested in the opinion of someone who has interest in the odd corners of openbsd)
Note: I don't use OpenBSD on it, just the default OS which is a custom roll of Debian.
It's certainly not a problem for me if that's really just a limit on bandwidth, and not some kind of additional CPU load or network latency.
I run a OpenBSD router in a PC Engine Apu1d and it's more than fast enough. I can hit 700+ mbps on iperf with a basic pf rule set. Since OpenBSD is in the middle of updating their network stack to enable SMP I'd bet that number will rise with the next couple releases. I found mailing list posts from a year ago that have the iperf benchmarks of the apu1d right at 500 mbps. I'm interested to see if the network changes that landed in 6.0 will mean a measurable difference. This is entirely academic on a 30 mbps connection but I like it when numbers change.
Everything else you write, I completely agree with.
But seriously, it's often said that the tree is now full, you need to remove something unmaintained before you add may something new.
..more seriously, while it may not be noticeable by DVCS users, working directory sizes for CVS/SVN repositories can actually /decrease/ when code is removed.
And wish github provided navigation that was as easy and lightweight as this.
I understand that a certain degree of conservatism in software can be beneficial, but given just how limited CVS is, it would be kinda like writing code in ed (now I hope no-one actually does that).
I was actually picking a BSD to install on a laptop recently. OpenBSD got dropped off the list when I found out that they still use CVS for base system and ports (because, yes, I do intend to hack on those).
In any case, your basic premise is wrong. If you see someone riding a horse buggy on a freeway, it's not unreasonable to ask why they're doing that.
Surely it must work for them I'd be thinking. If you use a tool that still works and has worked, changing for the sake of it seems unnecessary.
The question is, why, knowing that there are things that work vastly better (I'm not speaking hypothetically here - I used CVS for many years myself, and I remember all the painful limitations, and the nearly universal joy on the team when we finally migrated to Subversion), they still stick to that old stuff?
Sure, there's some cost to migration, but it's been done thousands of times before by other people, so there are a lot of tools that automate all that, and vast knowledge about how to do it right. So the cost really low compared to the objective benefits that they would get - such as, well, being able to rename things without wiping history, or tracking changes across several files etc.
So, is it really just the "that's how we did that in the good old days, and that's how we like it - now get off my lawn" sort of thing, or are there some technical reasons why they consider CVS good enough? I'm hesitant to assume the former until I can definitely ascertain that it's not the latter.
I won't argue that the opposite is true, but the general speed limit in openbsd is not the tooling or even the meta-tooling around the source tree, but rather how many decent coders is active at this moment and how much useful code can they get reviewed and committed.
I don't think I've ever seen something along the lines of "phew, if I hadn't had $weird-dvcs in place, I could not have invented this provably correct parallel AVX-accelerated version of SHA768" or something to that effect.
Just to make it clear, I'm not complaining about OpenBSD using CVS in general, or claiming that they are too slow or missing features because of it. I'm just wondering why, in this day and age, anyone would use CVS when so many clearly better alternatives exist. I know I would be frustrated if I had to code in a CVS repo, and would push to get it migrated to at least SVN just to make my own life more comfortable. So it naturally makes me wonder why other people in that situation, who presumably know at least as much as me, do not.
Diffs mailed between devs still look the same, oks for diffs
are still a social construct that needs persons and not programs.
[edit: mods can you update?]
[prev in list] [next in list] [prev in thread] [next in thread]
Subject: CVS: cvs.openbsd.org: src
From: Pascal Stumpf <pascal () openbsd ! org>
Date: 2016-09-03 22:47:02
Message-ID: 9a28502641f17805 () openbsd ! org
[Download message RAW]
Module name: src
Changes by: firstname.lastname@example.org 2016/09/03 16:47:02
Use the space freed up by sparc and zaurus to import LLVM.
Vendor Tag: LLVM
Release Tags: LLVM_3_8_1
No conflicts created by this import
[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic
Google cache is here: https://webcache.googleusercontent.com/search?q=cache:https:...