OpenBSD: arm64 platform now officially supported, and has syspatch(8) | Hacker News Reader

OpenBSD: arm64 platform now officially supported, and has syspatch(8)

undeadly.org

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?

Its not really, but previously you had to build from sources to apply security/reliability fixes between releases.

Just glancing at the man page, atomic rollback kinda jumps out...

Is that the same as using yum history to roll back?

Windows too!

(sort of)

> what is the big deal about syspatch?

It's not revolutionary, just very convenient. It's automatic, and I think M:Tier offers a similar service.[0]

> How is this different from […] apt or yum?

It's a "utility for security and reliability binary updates to the base system."[1] Syspatch is only for base system, not ported packages.

[0]: https://stable.mtier.org/ [1]: https://www.openbsd.org/61.html [2]: Package Management https://www.openbsd.org/faq/faq15.html

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.

Packaged base is a beta feature in FreeBSD https://wiki.freebsd.org/PkgBase

But IMO there's nothing wrong with freebsd-update.

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.

freebsd-update works fine in jails, as long as you use it correctly. Unfortunately there are a few landmines due to versioning issues.

".. use it correctly": As in excluding the kernel component in freebsd-update.conf or how do you mean?

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.

Yeah, I'm familiar — I'm a FreeBSD developer. Pkgbase is a feature in development; it's not officially complete or supported in any release.

> some greybeards are still pretty attached to that idea

"Whenever you remove any fence, always pause long enough to ask yourself, 'Why was it put there in the first place?'" G.K. Chesterton

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.

Yup. Same for code that looks unused :). Very good advice. Sometimes fences can come down, sometimes they make better neighbors.

Isn't the official term aarch64?

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

Thanks to Linus Torvalds I think.

Yes, but like Debian, OpenBSD is ignoring that.

Fedora, openSUSE, Mageia, etc. use the official term. Debian and the BSDs use the informal "arm64" term.

The informal makes more sense, BTW.

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')...

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.

I saw this last night, plan to order a Pinebook today.

Edit: Registered for a Pinebook today, will have look for a board to play with. Any suggestions?

Thanks for the reminder! Registered for one just now myself. I wonder how long the wait is.

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

* https://forum.pine64.org/showthread.php?tid=5046

* https://forum.pine64.org/showthread.php?tid=5025

* https://forum.pine64.org/showthread.php?tid=4997

Not sure it's really worth the potential hassles at this stage. :(

That being said, if you can put up with the potential issues then it probably wouldn't hurt to try it out. :)

so does this mean smart phones and IOTs can run on BSD?

OpenBSD support list [0] at the moment:

> 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.)

[0]: https://www.openbsd.org/arm64.html

You can use an RS232/USB connector to hook it up to a VT100-compatible terminal or emulator. That’s what I plan to do this afternoon.

Alternatively you can just SSH 59 it. It depends on what your objectives are.

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.

https://www.armbian.com/download/

http://dietpi.com/

Reply on news.ycombinator.com