There are parts of me that don't want to say this but will LLMs actually help Linux and smaller OSes by accelerating reverse engineering hardware that doesn't have open/good enough specs? Will we reach a point where hibernate works reliably on Linux? Weird hardware can be used well by FreeBSD?
This has nothing to do with LLMs. The *BSDs have been porting Linux video drivers for years. This is just the status quo of how video drivers on OpenBSD work.
I see quite a lot of announcements of compatibility and porting efforts -you would never know if someone used an LLM to help, but I would bet money it is being done without admitting it.
Just because you don't know how to do it doesn't mean they don't. As I said, the same people have been doing this for years, long before LLMs. They need to re-sync with upstream periodically so that's why you see announcements of new stuff.
Also, people who have been doing something for years are exactly the people who benefit the most from having pointless toil removed from the workflows.
Attitudes like yours are exactly why we won't know what level of AI assistance is used. People won't admit it because there is a lot of downside to doing so - especially in communities like this.
OpenBSD 7.9 was already on the 6.18.y longterm support version, Jonathan Gray (jsg@) completed the update back in March of this year, sponsored by the OpenBSD Foundation.
> OpenBSD is on 7.9 now and all releases are possible breaking changes.
> don’t think of version “8.0” as a major release per se, since OpenBSD is a fixed schedule release - not a Major.Minor release
Are these two statements a contradiction?
Thinking out loud, maybe the spirit of your comment is, “Every OpenBSD release is possibly a breaking change; the version numbers don’t mean anything.” Otherwise, I don’t see how it’s relevant to mention the current release ends in .9, then explain how the next version is constructed.
Please help me understand. I truly have no sense of how things work in OpenBSD land. The spirit of my comment here is entirely in good faith, just trying to learn.
I think they mean in addition to all releases possibly having breaking changes, the developers did not pick 8.0 instead of 7.10 because they thought this is a significant milestone, but instead because they always roll from N.9 to (N+1).0.
OpenBSD predates popular semantic versioning conventions by a few years.
I think MS-DOS already used in the 80s what you call "semantic" versioning. (Most probably even earlier examples, this is just the first thing that came to mind.)
nta but yes your spirit reading is correct. They're saying OpenBSD treats the version number as an integer, and every update adds .1. So 7.8 -> 7.9 -> 8.0, regardless of how significant or breaking the changes are.
Huh; I would have thought that importing MIT code into a GPL codebase (like the Linux kernel) essentially “beats out” the original MIT-licensing and instead creates an GPL-licensed fork of said code; thus making such forked code ineligible for re-import into an MIT/BSD-licensed project like the OpenBSD kernel (unless that project wants to be infected by the component’s licensing and become GPL-licensed in turn.)
Are you saying instead that the DRM drivers in the Linux kernel (the in-tree parts, I mean, not the firmware blobs) exist as an island of MIT-licensed code inside the otherwise GPL-licensed codebase?
Or are these parts of the Linux kernel not even technically in-tree, but rather developed in a separate canonical repo and frequently synchronized into the kernel as a vendored dependency? That’s the only way I can see this working; but it’s unclear to me why this state of things would have been maintained for any length of time when the Linux kernel was the only consumer…
The GPL is (in)famously viral. You can't base something on a GPLed codebase and say that your thing isn't covered by the GPL. The GPL is specifically designed to forbid that specific thing.
Here was my (perhaps incorrect) understanding. It's specific to the case of forking code that uses the very permissive MIT or BSD licenses, and relicensing the results under some other, more-complex copyleft license, like GPL or Apache.
1. These other copyleft licenses all effectively require a strict superset of the terms of the MIT/BSD licenses. MIT/BSD require attribution? So do these other licenses. MIT/BSD require distributing a copy of "the license" so that further forks understand the terms? So do these other licenses (provided you interpret the GPL-or-what-have-you as being a valid instance of "the license" the MIT/BSD licenses refer to, in the same sense that a square is a valid rectangle.) Etc.
2. Which therefore makes MIT/BSD-licensed code "donor compatible" with otherwise-copyleft-licensed recipient codebases, in the same sense that type-O blood donors are "donor compatible" with recipients of other blood types.
3. Or, if you want to be fine-grained about it, you can view this as all the original imported MIT/BSD-licensed code remaining MIT/BSD-licensed, while each post-fork-rewritten line of code is instead GPL-licensed (due to being contributed to the codebase under the codebase's toplevel GPL license + contributor agreement.)
4. But because enforcing the terms of the GPL upon a code file, also implicitly enforces the (very minimal) terms required by an MIT or BSD license upon the same code file, you can forget about the distinction of "old lines are still MIT/BSD-licensed, while new lines are GPL-licensed", and treat the whole mass of code as being GPL-licensed, and as long as you obey the terms of the GPL, you won't end up in violation of the MIT/BSD-licensing requirements of the upstream-imported code.
Now, I'm apparently still getting something wrong here. But I'm unclear where exactly this argument falls flat.
I know for a fact that I've seen MIT/BSD-licensed libraries abandoned, and then later a new maintainer shows up and re-licenses (their new fork of) the library code under the LGPL. And this is apparently legal, since corporations seem perfectly willing to make use the now-LGPL-licensed library in commercial Linux distros, etc.
I know I've also seen codebases forked, where the fork goes from one license to a more restrictive "sibling" license, e.g. LGPL -> GPL or GPL -> Affero GPL. If "you don't get to change the license on someone else's code" was true in general, these forks would be in violation of copyright. But nobody ever seems to assert that.
That‘s a common misunderstanding how licenses work on HN. Often even worse: "MIT allows relicensing" (no it doesn‘t, and sub-licensing is something different).
Yes, you need to supply all of those if you distribute the Linux kernel in binary form. No, most companies don‘t do that in practice. Yes, they are in breach of all those licenses. Yes, next kernel release there will be changes.
I‘ve long been procrastinating on writing a blog post about exactly that.
Amazing how OpenBSD is getting modern GPU support before having a working mmap. It's like a civilization landing on the moon before getting around to discovering radio. Weird tech tree.
I think the OP was asking the honest question: why not use Linux if the graphics stack is from Linux anyways. It's a fair question and I ask that myself.
Presumably because the other features of OpenBSD bring in some benefits to OpenBSD fans. Also you can always develop on your OpenBSD desktop (with the Linux shim) and then deploy to the server without the Linux shim.
I know, but felt that it was the kind of answer one should get when discussing UNIX systems.
Many of us that enjoy UNIX, regardless of its flaws[0], and do not appreciate a GNU/Linux monoculture, similar to having Google taking over the Web with Chrome OS forks.
[0] - Remember that its creators moved on from UNIX and C, creating other systems they saw as improvements on their creation.
I got your point about the monoculture, and I agree with you. Being different is not something bad.
My question was more nuanced though. It seems to me that in the past 10 years or so, openbsd didn’t invent very much. Of course that I agree that there are some punctual things where openbsd was first but that’s not the case lately. So it’s mostly a catchup game with linux features and compatibility needs for running linux software. If you open now the HN front page you will see one story about openbsd importing linux drivers and another story on openbsd struggles to support wine - and basically how wine developers don’t care too much about that.
Hence my question, if most of the effort is put to catch up with linux features, is it even worth anymore? If I want to use linux from 5 years ago, I could just do that. Putting so much effort and time into developing a linux feature clone just in case linux becomes evil, also doesn’t make sense, because you can fork when you see this. Licensing wise even less, I think there’s now a mixture on both sides.
So please take it as a genuine question, not as criticism or anything.
Yes, because an OS is much more than drivers, the culture among its users and developers is quite relevant, and OpenBSD users certainly don't want to deal with many Linuxisms like systemd for example, or rather favour pkg approach to software delivery, that is why they are on a BSD in first place.
Just like others might favour Illumos, Aix, z/UNIX, macOS or whatever take on UNIX evolution.
39 comments
[ 0.17 ms ] story [ 51.8 ms ] threadNow if they would only get rid of their hilariously unreliable 1970s file system.
Also, people who have been doing something for years are exactly the people who benefit the most from having pointless toil removed from the workflows.
Attitudes like yours are exactly why we won't know what level of AI assistance is used. People won't admit it because there is a lot of downside to doing so - especially in communities like this.
https://marc.info/?l=openbsd-cvs&m=177310343311915&w=2
I just wanted to highlight his continued efforts in my hype post for the upcoming 8.0 release.
They release every six month and increment by 0.1. And after 0.9 they rollover to the next whole number.
So don’t think of version “8.0” is a major milestone per se, since OpenBSD is a fixed schedule release - not exact a Major.Minor release.
> don’t think of version “8.0” as a major release per se, since OpenBSD is a fixed schedule release - not a Major.Minor release
Are these two statements a contradiction?
Thinking out loud, maybe the spirit of your comment is, “Every OpenBSD release is possibly a breaking change; the version numbers don’t mean anything.” Otherwise, I don’t see how it’s relevant to mention the current release ends in .9, then explain how the next version is constructed.
Please help me understand. I truly have no sense of how things work in OpenBSD land. The spirit of my comment here is entirely in good faith, just trying to learn.
This is similar to Linux kernel versioning
OpenBSD predates popular semantic versioning conventions by a few years.
https://github.com/openbsd/src/tree/master/sys/dev/pci/drm
Are you saying instead that the DRM drivers in the Linux kernel (the in-tree parts, I mean, not the firmware blobs) exist as an island of MIT-licensed code inside the otherwise GPL-licensed codebase?
Or are these parts of the Linux kernel not even technically in-tree, but rather developed in a separate canonical repo and frequently synchronized into the kernel as a vendored dependency? That’s the only way I can see this working; but it’s unclear to me why this state of things would have been maintained for any length of time when the Linux kernel was the only consumer…
Here was my (perhaps incorrect) understanding. It's specific to the case of forking code that uses the very permissive MIT or BSD licenses, and relicensing the results under some other, more-complex copyleft license, like GPL or Apache.
1. These other copyleft licenses all effectively require a strict superset of the terms of the MIT/BSD licenses. MIT/BSD require attribution? So do these other licenses. MIT/BSD require distributing a copy of "the license" so that further forks understand the terms? So do these other licenses (provided you interpret the GPL-or-what-have-you as being a valid instance of "the license" the MIT/BSD licenses refer to, in the same sense that a square is a valid rectangle.) Etc.
2. Which therefore makes MIT/BSD-licensed code "donor compatible" with otherwise-copyleft-licensed recipient codebases, in the same sense that type-O blood donors are "donor compatible" with recipients of other blood types.
3. Or, if you want to be fine-grained about it, you can view this as all the original imported MIT/BSD-licensed code remaining MIT/BSD-licensed, while each post-fork-rewritten line of code is instead GPL-licensed (due to being contributed to the codebase under the codebase's toplevel GPL license + contributor agreement.)
4. But because enforcing the terms of the GPL upon a code file, also implicitly enforces the (very minimal) terms required by an MIT or BSD license upon the same code file, you can forget about the distinction of "old lines are still MIT/BSD-licensed, while new lines are GPL-licensed", and treat the whole mass of code as being GPL-licensed, and as long as you obey the terms of the GPL, you won't end up in violation of the MIT/BSD-licensing requirements of the upstream-imported code.
Now, I'm apparently still getting something wrong here. But I'm unclear where exactly this argument falls flat.
I know for a fact that I've seen MIT/BSD-licensed libraries abandoned, and then later a new maintainer shows up and re-licenses (their new fork of) the library code under the LGPL. And this is apparently legal, since corporations seem perfectly willing to make use the now-LGPL-licensed library in commercial Linux distros, etc.
I know I've also seen codebases forked, where the fork goes from one license to a more restrictive "sibling" license, e.g. LGPL -> GPL or GPL -> Affero GPL. If "you don't get to change the license on someone else's code" was true in general, these forks would be in violation of copyright. But nobody ever seems to assert that.
That‘s a common misunderstanding how licenses work on HN. Often even worse: "MIT allows relicensing" (no it doesn‘t, and sub-licensing is something different).
Behold the full set of licenses and copyright notices that apply to the Linux kernel, scanned with FOSSology[1] and ScanCode[2], and curated by licensing professionals: https://raw.githubusercontent.com/Open-Source-Compliance/pac...
Yes, you need to supply all of those if you distribute the Linux kernel in binary form. No, most companies don‘t do that in practice. Yes, they are in breach of all those licenses. Yes, next kernel release there will be changes.
I‘ve long been procrastinating on writing a blog post about exactly that.
[1] https://www.fossology.org/
[2] https://github.com/aboutcode-org/scancode-toolkit
Just look for `fw_update`
Presumably because the other features of OpenBSD bring in some benefits to OpenBSD fans. Also you can always develop on your OpenBSD desktop (with the Linux shim) and then deploy to the server without the Linux shim.
Many of us that enjoy UNIX, regardless of its flaws[0], and do not appreciate a GNU/Linux monoculture, similar to having Google taking over the Web with Chrome OS forks.
[0] - Remember that its creators moved on from UNIX and C, creating other systems they saw as improvements on their creation.
My question was more nuanced though. It seems to me that in the past 10 years or so, openbsd didn’t invent very much. Of course that I agree that there are some punctual things where openbsd was first but that’s not the case lately. So it’s mostly a catchup game with linux features and compatibility needs for running linux software. If you open now the HN front page you will see one story about openbsd importing linux drivers and another story on openbsd struggles to support wine - and basically how wine developers don’t care too much about that.
Hence my question, if most of the effort is put to catch up with linux features, is it even worth anymore? If I want to use linux from 5 years ago, I could just do that. Putting so much effort and time into developing a linux feature clone just in case linux becomes evil, also doesn’t make sense, because you can fork when you see this. Licensing wise even less, I think there’s now a mixture on both sides.
So please take it as a genuine question, not as criticism or anything.
Just like others might favour Illumos, Aix, z/UNIX, macOS or whatever take on UNIX evolution.