OpenBSD 7.9 was already on the 6.18.y longterm support version for the drm(4) drivers, Jonathan Gray (jsg@) completed the update back in March, 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.
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.
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.
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.
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.
The major contention some with wisdom have with ai is it makes the genuine 10x and 20x engineers into 80x engineers and 250x engineers but it makes the mediocre engineers exponentially worse.
We're also collectively contending with more than one generation of contributors who don't know how what they started with got to where it was and carry a mindset of "this is how things should be done", and then we reach moments where a lot of the smarter people collectively talked enough about to realize: oh, the rest of us built three decades on stupidity of what was called OOP (and not real OOP according to some) because categorization meme caught on and was taught in school as the way.
There does need to be heterogeneity where some corners refrain from taking what could be irreversible steps.
Renovation of the core parts of the BSDs, illumos, and Linux with CompCert C or something like it using LLMs, done by the right hands, will be interesting.
I would love to see ZFS on OpenBSD ; if only the necessary talent wasn't preoccupied.
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.
Your logic is ridiculous - I wouldn't post publicly like this if I was projecting.
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.
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.
OpenBSD predates popular semantic versioning conventions by a few years.
This is similar to Linux kernel versioning
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…
We're also collectively contending with more than one generation of contributors who don't know how what they started with got to where it was and carry a mindset of "this is how things should be done", and then we reach moments where a lot of the smarter people collectively talked enough about to realize: oh, the rest of us built three decades on stupidity of what was called OOP (and not real OOP according to some) because categorization meme caught on and was taught in school as the way.
There does need to be heterogeneity where some corners refrain from taking what could be irreversible steps.
Renovation of the core parts of the BSDs, illumos, and Linux with CompCert C or something like it using LLMs, done by the right hands, will be interesting.
I would love to see ZFS on OpenBSD ; if only the necessary talent wasn't preoccupied.
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.
MSI Modern 15