https://marc.info/?l=openbsd-cvs&m=177310343311915&w=2
I just wanted to highlight Jonathan's continued efforts backporting updates in my usual "HYPE" post series for the upcoming OpenBSD 8.0 release.
(I'm the author of the mastodon post that was shared.)
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” as a major release per se, since OpenBSD is a fixed schedule release - not 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.
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…
MSI Modern 15
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.
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.
It is just an obvious fact that when there are hostile swarms of people like you, that it is prudent to not disclose when you used an llm to unblock yourself.
I was being very neutral about this obvious fact and you became irrationally hostile.
If Linux DRM weren't licensed under more permissive terms, OpenBSD simply wouldn't permit its inclusion.