OpenBSD 7.2
openbsd.org
openbsd.org
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.
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.
Now that's niche!
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.
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.
More specifically:
(edit: it seems they didn't: OpenBSD/i386 hasn't actually supported running on [386sx/386dx] for some time. )
You may need locks on a non-SMP system (since you can still have concurrency), but without parallelism you don't need atomics... right?
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.
/me goes back to his polling-only application :)
(we have an interrupt, but it's "the watchdog fired and you're about to die anyway", so not exactly complex to handle...)
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).
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.
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.
"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.
That might be why it's still supported.
Who is funding OpenBSD these days?
As for funding essentials like electricity, network, hackathons, and unpleasant development work, that would be the OpenBSD foundation (http://www.openbsdfoundation.org/activities.html)
$87.5k in 2022?
That doesn't even pay for a single person after taking the rest of the expenses into account.
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 truly adore BSD; using Linux is a chore comparatively. But I don't really have a choice.
Intel and Broadcomm hand you a binary firmware blob and tell you to go screw yourself for the most part.
Atheros is one of the few helpful ones. The wifi support that we have now is the result of painstaking hard work.
And to be honest, I use the wifi on OpenBSD fine without 802.11ac support
But OpenBSD does have 802.11ac support*, since 7.1. :-)
* On iwm(4)/iwx(4) only for now.
Not speaking as an Open Source everything advocate. But I wonder how much would it cost to develop a fully open WiFi 7 and Bluetooth 5.3 Chip.
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.
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.
On both machines FreeBSD
https://www.haiku-os.org/blog/waddlesplash/2022-07-09_haiku_...
Edit: iwx not iax
OpenBSD does better here. AC is supported on Intel cards.
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
https://ftp.openbsd.org/pub/OpenBSD/snapshots/amd64/man72.tg...
Good documentation is a killer feature, in my opinion. It's nice they provide it all in one tar ball.
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.
> Added support for Apple M2
> 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.
https://www.notebookcheck.net/Lenovo-ThinkPad-Z13-laptop-rev...
And you do not need to switch the CPU arch.
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.
Keep you eyes open for sales. /r/homelabsales/ has great deals on these SFF devices sometimes.
I've read that the PCEngines struggles to keep up with network traffic in excess of 100Mb/s.
Although this update may have addressed that. That router guide is ok. but the official pages are better. https://www.openbsd.org/faq/pf/example1.html
Hit me up directly if you have any questions. o2kewl[at]gmail[dot]com
It's an: HP t730 Thin Client
From dmesg:
cpu0: AMD RX-427BB with AMD Radeon(tm) R7 Graphics, 2697.05 MHz, 15-30-01
4-cores total
I haven't tested it on a 1Gb/s but @c17r said it works: https://news.ycombinator.com/item?id=25045963
I have an older alix one, and I think it worked with 100Mb/s, but struggled after that.
Now, I bought my apu in 2016 and I don't regret it, but I'm not sure I'd buy one in 2022.
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.
(I wish this was true for Linux too...)
That's one reason PCEngines is so popular, even though PCEngines themselves seem mostly preoccupied with Linux and FreeBSD.
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.
Patch for OpenBSD 7.1 kernel to ignore the L6F GFE interrupt storms: https://gist.github.com/joemiller/9f5698c5634d4a93d101985dc5...
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.
https://teklager.se/en/products/router-components/pc-engines...
I set mine up years ago, so won’t link to the old guide I used.
Have to go with NetBSD there. :)
More seriously, you could give them test rides inside QEMU before you decide.
IMHO:
FreeBSD = general purpose
(Open|Net)BSD = more specialized
> but it's really about what you want and what you need.
So I'm agreeing with you!
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.
>you can't run the big cores at full throttle all the time because they just use too much power.
Yes you don't do that...not even on servers (sometimes).
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
It is...it's called cost.
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.
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.
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.
Install the OS, grab the src, subscribe to the lists and get to hacking!
The IRC and Matrix chats are great spots to get the low down, communities are helpful and documented.
Are there any good resources?
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.
The FAQ is your friend
one diff
two OKs
commit
blowfishOne fish Two fish Red fish Blue fish.
>Updated drm(4) to Linux 5.15.69
>inteldrm(4): support for Alder Lake, Raptor Lake
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.
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
I've been a huge fan since v4.7 and I'm glad to see the constant improvements.
https://old.reddit.com/r/openbsd/comments/q8lsiq/how_relevan...
# uname -a OpenBSD xxx 7.1 GENERIC.MP#3 amd64
# ifconfig em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 lladdr x:x:x:x:x description: xxx index 2 priority 0 llprio 3 media: Ethernet autoselect (1000baseT full-duplex) status: active inet x.x.x.x netmask 0xffffff00 broadcast x.x.x.x inet6 fe80::x:x:x%em0 prefixlen 64 scopeid 0x2 inet6 2601:x:x:x::1 prefixlen 64 pltime 301996 vltime 301996
Congrads to OpenBSD on a stable OS and how they plan their releases
See you next thread!