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.
> 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.
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).
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..
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.
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.
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.
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.
https://github.com/openbsd/src/commit/ad8b1aafbcc34f7eb86e4e...