Honest question: what is the big deal about syspatch? I see OpenBSD folks talk about it as if it is the greatest thing since sliced bread. How is this different from what many distributions have had for more than a decade in the form of apt or yum?
Can't use Linux distribution tools like apt/yum unless you package the update contents as rpm/dpkg files and distribute apt/yum with the base system. Neither of those is happening in OpenBSD, or likely any BSD. (I can go into more detail on why if you're curious.)
In some ways, the BSDs are just catching up to Linux in terms of update distribution mechanism. They all have a history of being self-hosting compile-from-source systems, and some greybeards are still pretty attached to that idea.
As someone who discovered Linux first and happily used it for many years before discovering the BSDs, I think there's a lot Linux gets right that BSDs will or should adopt to be relevant. (There are also many things the BSDs get right, of course.) This is a good example of that.
Using pkg to update both base and ports with a single tool will be nice. As will updating jails robustly; freebsd-update is not so great in jails in my experience.
The place people usually trip up is with freebsd-update getting confused about what version it's trying to update. The '--currently-running <release>' option is your friend here.
In this case it's just about sane defaults and options. You could take any binary-update Linux distribution and update from source yourself if you wanted to. It was always an option. All of the build machinery and sources were published from the beginning.
With the BSDs, you didn't even have the option of binary updates or packages until quite recently.
Well I misread it as amd64, thought it "can't be possible" and had to come down to this thread to realise the nature of my mistake.
aarch32 and aarch64 are strictly ARMv8, while arm32, being informal, could really be a catch-all term for all the previous ones. I don't know of any aarch32 distro though, they all seem to limit to ARMv7hf, which is sad because on a Raspberry Pi 3 you can't get the VideoCore binaries and v8 instruction set: going 64bit means most hardware does not work (at least: no X/wayland, no 3D, no sound), and some benchmarks have shown that they bring up 15-20% performance improvements.
Anyway, this is basically the same debate as x64 vs x86-64 vs amd64 and mostly bike shedding at the end of the day.
True, but there's some merit to being consistent with the naming used by the toolchain (which appears in things like cross compiler binary names) and the name printed by the linux kernel in 'uname -a')...
It's the official term from the ARMv8 architecture and also the name adopted by toolchains, but "arm64" was chosen for Linux: https://lkml.org/lkml/2012/7/15/127
Don't have 1st hand OpenBSD/arm64 experience but I'd definitely expect the page https://www.openbsd.org/arm64.html to be accurate as concerns device support, although I'd expect more drivers to be written. Not a committer but I think supported in this case is talking about system featureset on working hardware & project support (e.g. solid committers, build machines, etc), not meaning all hardware being supported.
I'd probably read the last year-or-so of openbsd-arm list and check the recent commit messges for that part of the tree if that page isn't clear..
Looking through the Pinebook website and forum a few days ago, there are many reports of hardware problems due to what seem like poor manufacturing and QA. :(
eg keyboards with keys that don't work, the GbE network pork actually only running at 100Mb/s, battery's that don't charge, screens with dead pixels
> The current target platforms are Rockchip RK3399, Allwinner A64/H5, Raspberry Pi 3 and Opteron A1100.
That's a good list, it may cover a number of "Maker"-oriented single-board computers that are fun to play with.
Note that most of the Raspberry Pi chip is its Broadcom Videocore IV graphics processor, which is not supported by the OpenBSD OS. You would have to hook up a screen to the GPIO pins, I think, rather than getting display out of the HDMI port. There are lots of LCD display "hats" on the market.
(I am typing this on my iPad, which is an iOS device, which is a descendent of BSD.)
Armbian and DietPI pages, although Linux oriented, contain a fairly long list of hackable boards, so you can look there for boards using supported platforms.
