> Fixed luna88k MULTIPROCESSOR kernels booting with CPU modules installed in arbitrary slots.
An OS release capable of running on the latest hardware in 2022 is still making optimizations for a niche system from the late 80s/early 90s. There's something very beautiful about that.
I searched for this luna88k and was taken to a Wikipedia page that I read until I realized it was for a computer called LUNA but it had a 68k processor.
The reason it came up was a tiny quote from the NetBSD announcement of Luna 68k support which mentions its "rare cousin" the 88k LUNA.
Also a good example of what I understand the OpenBSD development goals to be: developers work on the features and hardware support that interest them. It isn't a popularity contest; targeting the most popular platforms or growing the number of users of OpenBSD is not a project goal.
So as long as there are developers who want to do the work to support the 88k LUNA (whatever it is) then it will happen.
I thought I knew a lot about 68k processors, but "88k" is new to me. It turns out to be the Motorola 88100¹, which was used in Unisys servers running Unix.
Motorola had a lot of VME bus boards with 88100/88110 CPUs. There's still a web site dedicated to the 88k CPUs at http://www.m88k.com
Fun fact - the 88k was designed by Mitch Alsup, who also designed SPARC CPUs for Ross, x86s for AMD and others. He is retired, but still active in the comp.arch Usenet newsgroup.
This is something i always felt was lost with what seems to be "commercialization of free software" - software doing things because it was technically possible regardless if that made commercial sense. Nowadays it seems most projects have commercial interests (or even if they don't they act like it) and processes that come against that, often ending up abandoning things because of usage metrics and agendas, as if they have some board of directors to please.
Yeah it's one of the many reasons I use OpenBSD - I can actually use my old, perfectly-functional hardware from literally decades ago and still run the latest software with latest security features and frequent updates. On numerous architectures, too!
The toolchains dropped support for the i80386, not the OSes directly.
Intel, as they're known for doing, half-assed many things. Even though the 32 bit mode on the i80386 wouldn't be compatible with i8086 real mode and they could've made vast improvements, they decided to make just a mediocre 32 bit CPU, since they figured most people would just be running it as a super fast i8086.
The m68020 in 1984, by comparison, was much more forward thinking. It had atomic operations, could exist in a multi-processor environment much more easily than an i80386, and it can still run a modern OS (NetBSD) in 2022.
> None of this actually relevant to openbsd dropping 386 support 15 years ago.
Well, I think the argument being made (implicitly) was:
If Intel had made a decent and capable implementation of 386 with forward looking CPU instructions etc. 386 could have been alive and kicking today in many more operating systems and platforms.
It's more like the PC platform has continued to evolve in many ways, and 30 year old museum pieces aren't particularly interesting. Contrast with the mac68k platform, which is frozen in time. You don't see anybody trying to build one kernel that boots on every Mac ever made because the CPU has changed several times, but it wouldn't be pleasant even with continuity.
IIRC, the argument from the developers on OpenBSD misc mailing lists is that developing on 30 year museum pieces gives them perspective on the difference between right and wrong. It exposes them to more "stuff" than if it were the other way around.
But that's not how it works. Nothing is frozen in time. NetBSD 10 isn't functionally frozen compared with NetBSD 1.4 on mac68k because mac68k hardware hasn't changed since back then.
"PC" means personal computer, and the term existed long before the IBM PC, but the term is being used here to refer to the i8086, x86 and amd64 generic platforms. The fact that there's tons of overlap from the original IBM PC with an i8088 to a Compaq 386, then between the i80386 and a PCI Pentium, then more overlap from the Pentium to the Core2Duo, then to a modern UEFI multi-core CPU, means that if people just say, "ISA is dead, so let's rip it out" would lead to a world of pain, unless you want to drop support for every x86 in the world that doesn't use UEFI.
There are lots of people who want to do exactly that, but why? They very untechnically say there's "technical debt", say stupid things like, "people have to spend time supporting that" when open source is volunteer and most code written well will just continue to compile and run well.
Most people forget that the rest of the world that has less money has our leftovers, so some gatekeeper wanting to desupport older hardware he doesn't have WILL affect others. If there's no good technical reason to take it out, don't.
Running on older hardware quickly points out performance regressions. Running on alternate architectures points out issues like bad stack alignment assumptions, endian assumptions or bad word size assumptions. Running on systems with less memory brings light to software that's using too much memory. All of these things benefit someone, and it's pretty shitty to say that people who're less well off should be out of luck because certain people don't want to be told they should code with less assumptions and/or should care when they're told there's something wrong with their code. It happens more than you realize.
But even if people want a "financial" justification for everything, all of those benefits of testing on older hardware help with making sure a system is robust and runs well even on resource constrained embedded platforms. So there's that.
It's funny how some people will scream about not wanting to keep support for hardware less fortunate people have, but will shut up when someone mentions that the same support is important for embedded use.
You are so right with regression and slow sofware. Tryd to install rhel8.6 on a t61p from 2009. Gnome alone used half the vram around 130mb. And was slow as hell. Git is fast? Ever tryd to use it with 3gb of ram and a laptop hardisk? Switching branch on a linux repo took 4 minutes. I then converted the repo to a bitkeeper one (took about a week), changed to freebsd and the laptop was usable again...with i3 the nvidia drivers and bitkeeper. I really think dev's should test resonable sofware on a 2g raspberry or something like that regularly.
I don't know specifically why OpenBSD dropped support, but NetBSD dropped i80386 support after NetBSD 4 because gcc dropped i80386 support. So it is, in fact, relevant because OpenBSD would've had to have maintained an older gcc just for i80386 if they wanted to continue to support it.
IIRC, the 386 did not have atomic load/store operations (XADD, CMPXCHG), so it's much harder to write reliable semaphores/mutexes on that platform. I'm surprised OpenBSD supported it for this long.
(edit: it seems they didn't: OpenBSD/i386 hasn't actually supported running on [386sx/386dx] for some time. )
I'm trying to remember from the last em64t/ia32e & ia32 ISA toy OS I messed around with.
i386 ISA is the bare minimum for functioning protected mode to be better than real-mode DOS. i286 protected mode is absolute trash.
i386 is so bad at dealing with SMP primitives, it was standard practice to have a non-SMP kernel. Then, you get into the business of maintaining 2 kernel flavors or a major kernel feature flag.
For those interested, there is a quirky processor mode trick called "unreal mode" that allows flat addressing without switching to protected mode (no protections, just like real-mode DOS).
The 386 still has hardware and software interrupts which might just happen between the load and store instructions, so it's not as simple as "we don't need atomics".
If you were writing code specifically for the 386, I suppose you could implement all semaphores as critical sections to guard against external interrupts; I see no reason why that wouldn't work. But realistically, that code would be more of a museum piece than something you'd want to maintain in a 2022 operating system.
> Do they all have other jobs and using their spare time to devote to such a serious project?
Yes, except when <daywork> is also OpenBSD related. But that has nothing to do with the foundation.
> $87.5k in 2022?
The year isn't over... and there should be some left from bygone years.
> That doesn't even pay for a single person after taking the rest of the expenses into account.
I'm not aware of a single full-time paid developer, by the OpenBSD foundation. It's more a gig thing. In addition for Hackathons the foundation pays for the venue and network, and the developers usually fly themselves in.
The foundation was founded b.c. the CD sales (back when there were still CDs sold) didn't even cover electricity and network costs of the main site anymore.
It's all done like in the good old days of Linux, before big business stepped in.
I wish there was more interest in getting acceptable WiFi and Bluetooth performance from any BSD. Even FreeBSD lacks anything but a half-baked 802.11n implementation :/
I truly adore BSD; using Linux is a chore comparatively. But I don't really have a choice.
My understanding[1] is that openbsd has better 802.11 drivers than freebsd and reading the lists this is largely due to absolutely herculean effort by one person.Stefan Sperling [2]
Dramatic bio(probably none of this is true. but this lives in my head after reading the lists). Sperling never wanted to be a hero, had no training or experience interfacing with those piles of electronic treachery we affectionately call "wifi". But he wanted a change, he wanted a difference. He stepped up and wrote a patch. Now he is the sole defender between us and the vile manufactures actively trying to keep us from our starbucks internet connection. Not the hero we deserved, But the hero we needed[3].
Apparently finding people willing to work in that arcane shithole known as wifi drivers is hard. I looked once and it scared the hell out of me. A lovecraftian mess of undocumented registers and unknowable machines.
1. I don't have a laptop with FreeBSD so this is all hearsay.
2. Sperling is also writing got(game of trees) a sane implementation of git. http://gameoftrees.org/
3. The theme song for this majestic endeavor. https://www.youtube.com/watch?v=TZsUAqaOiHU
edit: I stated that got was plumbing for git and that is not true. that implies got uses git code. it does not, got uses the git file format.
It's partly the driver, partly the stack, at least on FreeBSD. My understanding is the newer high-speed wifi modes use multiple channels or pairs of channels or something like that, and the 80211 stack in FreeBSD was just not built with that in mind. So retrofitting it is some work. I think there are other things like that missing still, in addition to driver support.
I know of at least one open implementation of a wifi and BTLE modem made by a small university research team (though I can't find it online so it may not be published yet, won't say who it is unless I can find public details). It's definitely possible but it did take a team of grad students a little over a year to tapeout, and so it'd likely be very expensive
The RF side of WiFi is hell. The modem side is work, yes, but getting the air interface to work, and then dealing with all the interference management side is a nightmare.
I am not certain, but I think part of the 'blob' thing on WiFi internal implementations is to prevent someone breaking certification, particularly for the interference mitigation for things like DFS.
You can use both, to an extent. My most recent example: The documentation for GNU troff (groff) in Debian is incomplete-- the man page for eqn(1) includes the GNU extensions mostly, but not the basics. So I downloaded the OpenBSD manpages which includes complete documentation for eqn(7).
I too keep making the mistake of using the openbsd man pages for linux projects. Then am confused when things don't work as they should.
You would think I would learn better after a few cycles of this, but nope, I am rather stupid that way... or perhaps the openbsd documentation is just that much better.
Because they're deciding to try improving their driver API compatibility layer to import the Intel drivers directly from Linux instead of reverse engineering like OpenBSD is. Time will tell which approach is better in the long run.
Jup, wireless is one thing, i run around with a old smartphone and tether over usb (on my laptop). But the other one is fan-speed, i can even play AAA-Games...for a minute then my GPU crashes because of overheating (on the workstation with a AMD-Card). No way to adjust fan-speed from the OS is not good.
> Added support for Lenovo ThinkPad x13s and other machines using the Qualcomm Snapdragon 8cx Gen 3 (SC8280XP) SoC.
Given the current status and trajectory of ARM64 in phones and tablets, in SBCs, laptops, and even some servers, coupled with the deeply-held global interest in reducing energy usage, every year I get more confident in the belief that AMD64 has peaked and ARM64 is the upcoming top platform. I'm not sure if I'll ever buy another x86 machine for myself.
I'm so excited about arm64. Regardless of your opinion of Apple, you have to appreciate that they've really pushed the consumer world forward with their switch to arm processors in laptops.
I was just reading the new ThinkPad Z13 with the latest Ryzen is faster and gets similar battery life than the M1 or M2, so I wouldn't call x86 dead yet.
>with the latest Ryzen is faster and gets similar battery life than the M1 or M2, so I wouldn't call x86 dead yet.
Mind you, even "as fast as M1" would look amazing compared to Qualcomm's mediocre chips. Those who talk of ARM superiority forgot that if you don't buy an Apple device, what you get is mediocrity. And that's just talking of CPU performance. If you need a real GPU, those qualcomm SOC drop from "bearable" to "absolute garbage". While the M1 and M2 have GPUs that are comparable to some of NVIDIA's mid range offerings.
ARM based windows PCs aren't really going to supplant x86 as long as Qualcomm doesn't put a real effort.
Qualcomm is also one of the manufacturers that makes it impossible for Android to be supported for as long as iOS. Closed drivers + no will to do long term support because they're happy to sell more e-waste = drivers won't work on newer linux kernels and what remains is a brick.
Microsoft sold ARM-powered versions of the Surface for a while (not sure if it was ARM64 at that point) and releases a version of Windows which runs on the Pi, so it's something they've showed interest in for a while. I'm guessing that they also see the writing on the wall in terms of ascendancy of the ARM platform and want to make sure they have software to sell which runs on it as it happens, but hardware vendors haven't been falling over themselves to bring ARM Windows devices to market just yet.
Been very interested in OpenBSD for a while. Planning on installing it onto PCEngines' APU + antenna and using it as a router. Following this guide: https://openbsdrouterguide.net/ .
Serve the home [1] regularly reviews all sorts of low end small form factor hardware and aliexpress hardware. You'd probably be better served (heh) by scanning their website before investing in hardware. You can get an aliexpress device with much more horsepower and higher speed ports. If your budget is $200 then fine, but if you find out later doubling your budget gets a box that sustains 1 gigabit speeds or $600 gets you a machine that sustains 2.5gbe speeds and your $200 was wasted, it would be great for you to discover that now.
Another piece of advice I received from an OpenBSD contributor is to lurk on the mailing lists and see what the OpenBSD developers (esp. those that hack on networking code) actually use themselves and get that if you care about stability and performance.
greetings fellow traveler. I am also a big fan of openbsd for home router/firewall. Been running it since the early 2000s.
I've gone through a lot of hardware in that time. From an old dec alpha (kernel panic'd often) to only x86 these days.
In recent years I've started to use these low-cost, fanless, intel machines from aliexpress. They're usually pretty great. Recently I upgraded (ServeTheHome's reviews were very helpful!) from a box I got in 2018 from aliepxress that had 6x 1gbe ports to a newer box with 2.5gbe since my fiber ISP has 10gbe ports right now (and there are no cheap, fanless, low-power intel boxes with 10gig nic's). Specifically a Celeron N5105 (N6005 was not available earlier this year, so I canceled and ordered N5105) with 4x 2.5gbe nic's, this one[1] from Topton, though I believe other vendors on aliexpress are all selling basically the same thing.
The unit works pretty well, however, I noticed with OpenBSD 7.0 and 7.1 that one CPU core was constantly pegged at 100% servicing interrupts. Running `top -S` showed the acpi kernel thread was the culprit, and `systat` showed `acpi0` as the source of interrupts. The box worked fine and could route (with NAT and filtering) the full 2.5gbps internet connection fine, but it would run hotter and probably use more electricity than needed.
I enabled ACPI_DEBUG which did not make for a usable box at all due to the amount of debug prints being generated but it was enough to verify the interrupt spam coming from the ACPI GFE _L6F handler. A google search shows this is not particularly uncommon and is due to buggy motherboard firmware. Both Linux and FreeBSD have a way to disable interrupts on a live system. OpenBSD does not however. And FWIW, I booted an opnsense live CD based on FreeBSD and this interrupt storm was not happening. So I assume FreeBSD may have seen this particular bug or just happens to handle it already. This box should be fine with any of the FreeBSD based OS's. Which is often bundled on these firewalls you buy from aliexpress.
The usual fix for these interrupt storms from buggy BIOS's is an eventual fix from the vendor. In this case though I don't expect to ever seen a BIOS update for this box, and there really is not a website to go download one from anyway. The vendor on aliexpress assured me that if they ever release a new BIOS that they would tell me. I doubt this will ever happen.
In any case, I have "solved" the issue finally with a small kernel patch I found on the excellent openbsd mailing lists. The issue in that case was different, older hardware, but the symptoms were the same.
Long story short I am posting all of this here so that if someone else runs across this same issue they will be able to resolve it much faster than I was.
Did that increase your overall throughput? Drag racing pfsense vs OpenBSD on a xeon vmware system shows much less throughput on the OpenBSD system. I'm totally willing to pay the overhead for a more secure system, but I do still have certain performance goals.
no, i am able to saturate a 2.5gbps connection with NAT and filtering with or without ignoring the interrupt storm. Perf was never an issue, just higher temps (it's a fanless box) and probably energy draw (i never measured that so i am not sure how much)
> I've read that the PCEngines struggles to keep up with network traffic in excess of 100Mb/s.
For reference, quick iperf3 TCP tests on my APU2 (cpu[0123]: AMD GX-412TC SOC, 998.27 MHz; em[0123] at pci[1234] dev 0 function 0 "Intel I211" rev 0x03):
LAN host <-> APU: ~410 Mbps
LAN host <-> APU (over WireGuard): ~140 Mbps
However, I've put em[123] together as a veb(4) switch without pf involvement and two LAN hosts will get almost the full gigabit between them over that. Would need something bigger if I had a faster uplink or more complex LAN requirements.
That page has some outdated information. There's an official guide on OpenBSD's own website: https://www.openbsd.org/faq/pf/example1.html - No need to rely on third party blogs with BSD most of the time. Official docs and man pages are always better and up to date.
You managed to buy an APU2 or is this existing? They are pretty much uobtanium as of now.
I ran OpenBSD on my now deceased APU2. Never had any issues as it was solid up until it died, likely from lazily leaving it in a room which routinely reaches >90 F / 32 C in the summer. When the stars align and they release the SFP version, I'm going to grab one.
It exists? I got mine from Teklager, shipped internationally. Unfortunately the SFP didn’t work with my ISP’s fibre module (it would flap). I believe this is a Linux thing though. Otherwise quite happy with it.
The BSDs are awesome. I have been considering moving to BSD from Slackware Linux on my PC at home, but haven't yet pulled the trigger. Mostly, I cannot decide which to use among NetBSD, OpenBSD, or NetBSD.
FreeBSD is focused on the same market Linux is. It will probably give you the least trouble in terms of software and hardware compatibility.
OpenBSD is "the way things should be" according to a certain group of people. Generally feels good if you're tired of the Linux Mexican design standoff, but will sometimes leave you either very happy or very confused depending on whether or not you're on the same page as the developers.
I haven't used NetBSD extensively myself, but it seems to be a pretty simple system with a focus on portability.
None of the above matters if what you want to use doesn't work on your hardware. Test each one.
Try FreeBSD first, more functions more ports/pkg, i had OBSD for a long time, but decided against it because of ZFS and Wine-Proton....and much more, but it's really about what you want and what you need.
It totally depends on what you want to do/how you want to use your PC. For a 'general use' PC I'd suggest FreeBSD. There are more ports for newer programs that will offer more choices. NetBSD and OpenBSD also have their strengths, and EACH ONE can be used as a daily-driver. It just depends what you need/use.
Stopped using FreeBSD on my home servers (2 RockPro64s) because it lacks big.Little support, which results in an OS that doesn't distinct between the stronger and weaker cores. Among the BSDs only NetBSD supports it but that's too far from my comfort zone. Not only that but SSL and GNUTLS speeds were terrible at the time since it didn't knew how to use the cpu extensions (greatly impacts samba performance) I've stoped using.
Meanwhile Linux is a breeze. Faster, more responsible pulling 650MB/s on AES cryptsetup benchmark. BTRFS is actually quite good and LXC replaces jails. Transfers can easily saturate my gigabit connection. Don't think I'm going back so soon.
Do you like...not believe in the idea of power efficiency? Heterogeneous SoCs are one of the biggest reasons why we can have incredibly powerful smartphones that still last all day—you can't run the big cores at full throttle all the time because they just use too much power.
>having identical cores who can slow down and deactivate features on-demand or deactivate itself is a better use of space
With a take like that you're either a CPU micro-arch engineer working at the bleeding edge of research in this area or you have no idea how this actually works. One of the major ways we power optimize a core is by just making all the variable size structures smaller. That is, fewer/narrower execution units, smaller ROBs, smaller caches, less deep predictors, etc. Less hardware running means less leakage, which is the knob we're talking about controlling with little cores.
Now, in theory you can partially power gate a cache to turn, say, a 6-way cache into a 4-way cache, but doing so is extremely complicated from a correctness perspective and is really not something anyone is actually doing today.
And, anyways, fwiw: area is not really the a concern for modern SoCs at this point, it really is an issue of power/thermals. The feature size has gotten so small that they can afford to pack in extra stuff like accelerators and get good value out of them on the basis that it allows them to expend less energy than if they were to just use the CPU. For example, one big reason you see a lot of mobile SoCs with dedicated hardware for inference is because they have space and doing it with dedicate hardware lets them avoid burning a ton of energy on the CPU/GPU.
Cpu(core) hot-plug and a unified cache is not something new, it's also really hard for the OS to get full load (eff+perf cores) without swapping in and out.
>area is not really the a concern for modern SoCs at this point
OpenBSD is focused on correctness, security ("secure by default"), portability, and good documentation. (it is my choice.) It is the only one I know of that has had only 2 of the worst kind of security hole (remote hole in default install) since about 1996. It is the source of pf (firewall) and OpenSSH and I think other things that are used elsewhere. OpenSSH is widely trusted. It is not as fast at disk i/o as FreeBSD and doesn't have ZFS or Bluetooth support, or USB support for some use cases, I gather (though I use it with some USB things all the time).
FreeBSD seems focused on performance and stability, and some people say it is not as secure as openbsd, especially out of the box. Other people debate, and on it goes. It has the most users of the 3.
NetBSD seems focused on portability, and ... I don't know, fun hobby-ness? I know least there.
Qemu will let you see what works on the OS as far as software goes.
But fails to tell if your hardware is even supported.
They all have usb images available. Boot up, see if it finds everything, combined with your Software needs. I run all three so it's not always a trinary value.
It's most known for its portability and the number of architectures it supports, which many interpret as a comment on the quality of its underlying architecture.
SDF runs on it so you can play with it there.
OpenBSD is known for its security but I've run into too many rude people in their community which has never happened to me with NetBSD, maybe just a coincidence.
FreeBSD is known for its performance and being more up to date with drivers, etc but feels more "messy" and therefore less BSDish to me.
Take all of this with a grain of salt, just one man's take.
How do you get into this sort of stuff? "grab the src, subscribe to the lists and get to hacking!" is good but as a newbie, I would definitely need more guidance :D
OpenBSD has the best docs and really all you need to get up and going. Granted you may need to read some docs a few times, but it is all there. I got going with OpenBSD just by reading.
I have fond memory of booting OpenBSD the first time last year on an AMD RDNA GPU, after installation a simple "fw_update" got me a hardware accelerated graphic environment going. Very impressive in my book.
i am also wondering about this and happen to be in the middle of testing some L2 tunneling (etherip mostly, might also test vxlan or egre) with ipsec and wireguard in a set of VM's on virtualbox.
the SMP improvements in the networking stack caught my eye and i am in the process of trying to upgrade these vm's and re-test (iperf3). if i find anything interesting i'll report back
GL 2.1 support for my crappy Intel iGPU thanks to Gallium, instead of 1.4x. Good news. No modern gaming, but at least retrogaming and games like Trigger Rally will run fast. And, maybe, PSP emulation on an n270 Atom, but just as an experiment.
I like OpenBSD, but its very limited virtualization options means I cannot really use it full-time. Also the performance is not that great, but something I could live with.
An OS release capable of running on the latest hardware in 2022 is still making optimizations for a niche system from the late 80s/early 90s. There's something very beautiful about that.