notaplumber

Likely because the author doesn't care about that and are productivity focused. Besides, OpenBSD uses the same drivers as Linux, ported to the OpenBSD kernel.

https://github.com/openbsd/src/commit/ad8b1aafbcc34f7eb86e4e...

Although as mentioned in the article, this won't work on systems like *BSD, Solaris or macOS.

> And while it is likely that dhclient will eventually be removed from OpenBSD Base, it will live on in Ports, where it will be available to those who desire to use it:

To be clear, OpenBSD's dhclient is not ISC dhcp client, it is a version that has been maintained in OpenBSD for many years and has a weaker form of privsep, but dhcpleased is a new daemon written to be more in-line with other OpenBSD daemons.

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin/dhcpleased...

OpenBSD's previous dhclient: https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin/dhclient/

It definitely should not have been, this is news related to OpenBSD, there are no portable versions of either daemon.

I don't buy this. Some Acer laptops in the past have required that you set a Supervisor BIOS password in order to change the Secure Boot settings, but after you do that you can set the password to blank to clear it again.

It's looking very much like it will, but even if that wasn't the case, it's already widely in use and available in OS libc's and easy to copy, and it has been since OpenBSD first introduced it over 20 years ago. I also believe your performance claims are exaggerated.. and strlcpy does exactly what people want and expect in most scenarios.

> strlcpy... it’s not standard so it doesn’t satisfy 5 either.

It's a de facto standard supported on *BSD/macOS/Android/Linux(w/ musl libc) and a number of other commercial systems, it's also on track for standardization in POSIX (Issue 8).

https://www.austingroupbugs.net/view.php?id=986#c5050

https://www.opengroup.org/austin/docs/austin_1110.pdf

While it might not meet your arbitrary set of requirements, it already has decent adoption.

I unfortunately skimmed over this, isotopp's explanation helped clear things up in my head.

Thanks for this part, I feel like this was a crucial piece of information I was missing. Also explains my observations about TRIM not being as important as people claim it is, the firmware on modern flash storage seems more than capable of handling this without OS intervention.

> Because flash does not overwrite anything, ever.

This is repeated multiple times in the article, and I refuse to believe it is true. If NVME/SSDs never overwrote anything, they would quickly run out of available blocks, especially on OSs that don't support TRIM.

This is HN, I'm sure people would appreciate hearing the details. Like how does this integrate with OpenBSD's existing audio/graphics stacks, do you plan to upstream your work? With it being OpenBSD, are there security implications?

> I modified the OpenBSD kernel for the raspberry pi with gaming related extensions, in such a way that when the game runs there is no latency and no stuttering.

What does that even mean? What "gaming related extensions"?-- could you elaborate?

OpenBSD doesn't have any accelerated drivers for the GPU on the RPi, so I'm curious what your "no latency/no stuttering" modifications would even be, beyond perhaps maybe recompiling the kernel with HZ=1000 or something else..

> "OpenBSD users: Hi Mark!"

This is Mark Kettenis, who has despite comments made jokingly by marcan, been working with a few other OpenBSD developers to bring-up OpenBSD/arm64 on the Apple M1. At least on the Mac Mini the Gigabit Ethernet works, Broadcom Wi-Fi, and work on the internal NVMe storage is progressing.

There was an early teaser dmesg posted in Feburary showing OpenBSD booting multi-user (on bare metal): https://marc.info/?l=openbsd-arm&m=161386122115249&w=2

Mark has also been adding support for the M1 to the U-Boot project, which will not only benefit OpenBSD, but also Asahi Linux.

Another OpenBSD developer posted these screenshots and videos on Twitter.

https://twitter.com/bluerise/status/1359644736483655683

https://twitter.com/bluerise/status/1354216838406823936

Why wouldn't it be true? It's not as if the source and images aren't available for you to look at for yourself.

As for why BSD isn't more popular than Linux, well, that's a much bigger question. It could come down to licensing, project goals (not winning popularity contests), but mostly decades of history and Linux appearing at the right place, at the right time. There is place for alternative operating systems, choice is important.

EULAs are not legally binding in many jurisdictions.

Perhaps that's true. From what I read it shipped in a non-working state (manuals were there, but not some utilities were not), and I recall Apple engineers came out on Twitter saying it was being worked on and included it post-launch in macOS betas, even incorporating feedback. I believe Apple did tease at least Windows, maybe Linux in marketing, but I could be mistaken..

Either way, going after OS developers would be an extremely bad look for Apple, especially when they could just as easily disable the feature, or not have bothered finishing the implementation (or done it completely differently) after news of the Linux porting efforts started to spread (especially the Corellium public demo running Ubuntu).

Why would Apple go through the effort of adding support for booting alternative OS's on M1 Macs and then stand in the way of implementing drivers for the hardware? That doesn't make a lot of sense, IMHO. Especially considering Apple could have gone the exact same path as iOS devices, which is a heavily locked-down platform that shares a lot in common.

Sure there are, it's called brcmfmac. If the AsahiLinux team hasn't already got it working, certainly Corellium did a few months ago in their much hyped public demo image.

https://wireless.wiki.kernel.org/en/users/drivers/brcm80211

OpenBSD has also added support to their bwfm(4) driver already for 6.9.

Wireless is absolutely not the hardest problem for the M1 Mac, or running on any Mac, for that matter.

Because software patents should not be legal, and are not enforceable in many sane jurisdictions, e.g: Europe.

I'd much rather stick with "archaic" but understandable licenses like BSD, over verbose licenses that intertwine US Patent Law with Copyright law, such as Apache 2 or GPLv3.

Can you setup Starlink without the app, i.e: no cell phone? I'm getting real tired of devices that have no management/setup UI of their own.

All true, thanks for answering.

Sure that's fair, just thought it was interesting to point out the progress they've been making, especially with their 50th release around the corner (6.9 is due May 1st), and M1 SoC support in pretty good shape OOTB. USB works, Wireless, Ethernet on the M1 Mini, etc. It is lacking SMP and a bunch of other stuff, but still.. ton of impressive work.

Not trying to convince anyone to look at OpenBSD who has no inclination toward *BSD, but out of curiosity, what's missing for you?

OpenBSD has no equivalent to FreeBSD's support tiers, but arm64/aarch64 is supported with binary packages and syspatches today.

https://www.openbsd.org/arm64.html

Amusing seeing people reacting here on HN to the Apple M1 SoC Linux kernel upstreaming, meanwhile in OpenBSD.. FreeBSD hasn't made any public progress yet on M1 support.

https://marc.info/?l=openbsd-arm&m=161386122115249&w=2

https://github.com/openbsd/src/search?q=m1&type=commits

The problem is the actually often the opposite, in the real world many treat strncpy as if it behaves like strlcpy. Note that strlcpy is equivalent to:

    snprintf(buf, sizeof(buf), "%s", string);

strlcpy is on track for future standardization in POSIX, for Issue 8, but even as a de facto standard, it exists in libc on *BSD, macOS, Android, Solaris, QNX, and even Linux using musl.

https://www.austingroupbugs.net/view.php?id=986#c5050

But you're correct in that it is not a replacement for strncpy because no code should be using strncpy.

Linux arm64/Windows 10 ARM should be near native, minus graphics acceleration. x86 will be about as slow as you would expect with QEMU. Pretty slow.

There is no hardware assisted virtualization for x86 on ARM.

Specifically arm64 guests, otherwise it's just QEMU's TCG.

It's not proprietary, 3-clause BSD licensed. It's part of the chromium project. I use it on OpenBSD.

The built-in chrome PDF viewer PPAPI plugin is generally pretty decent and is at least sandboxed on most platforms. It handles larger documents a bit better than PDF.js.

There are many legitimate reason for one to need to be able to print or copy text from a document. Enforcing an entirely optional "security mechanism" when there is no technical reason to at the expense of the users of the software makes no sense at all, especially if the only argument is to respect the authors implied arbitrary wishes.

Xpdf has a history of enforcing purely software DRM on PDFs for no logical reason, such as the disabling of copying text and printing from documents. The upstream was against OS distributions patching this silly DRM out. I don't know if the upstream ever changed their policy on this, but there are better PDF readers out there now.

Here's a very long, and entertaining thread about it on the OpenBSD mailing lists from 2008.

https://marc.info/?t=120906296700004&r=2&w=2

No longer on their website, but original author considered this to be "cracking".

https://web.archive.org/web/20161129092715/http://www.foolab...