OpenBSD 8.0 release will have inteldrm/radeondrm/amdgpu drivers from Linux 6.18

Posted by doener 2 days ago

Counter181Comment45OpenOriginal

Comments

Comment by brynet 2 days ago

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.

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.)

Comment by alberth 2 days ago

Note that OpenBSD is on 7.9 now and all releases are possible breaking changes.

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.

Comment by coherentpony 2 days ago

> 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.

Comment by MYEUHD 2 days ago

What they meant is that, in terms of scale, the jump from 7.8 to 7.9 is more or less the same as the jump from 7.9 to 8.0

This is similar to Linux kernel versioning

Comment by drdexebtjl 2 days ago

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.

Comment by bananaflag 2 days ago

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.)

Comment by drdexebtjl 2 days ago

No, MS-DOS followed a simple major.minor scheme, with major bumps signifying project milestones or marketing reasons.

Semantic versioning is not what I call it, it’s a formal specification: https://semver.org/

Comment by heavensteeth 2 days ago

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.

Comment by Gracana 2 days ago

How does GPL code get ported to BSD?

Comment by brynet 2 days ago

Most of the common drm code and kernel gpu drivers are already MIT/X licensed for historical reasons, same goes for the Mesa GL and Xorg components.

https://github.com/openbsd/src/tree/master/sys/dev/pci/drm

Comment by derefr 2 days ago

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…

Comment by Tomte 2 days ago

> I would have thought […]

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

Comment by ralph84 2 days ago

No, you don't get to change the license on someone else's code just because you import it into your project.

Comment by 1 day ago

Comment by rescbr 2 days ago

Each file has their own license, and they are on the same repo.

Comment by quotemstr 2 days ago

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.

Comment by kccqzy 2 days ago

You can take BSD-licensed code and package it into a GPL bundle, which is what the kernel is doing. You can also extract the BSD-licensed code without the GPL-licensed code and it will be fine.

Comment by quotemstr 2 days ago

It depends on how closely the code is coupled to the rest of the project. Traditionally, sharing an address space carried the GPL taint. There's nuance to it, of course, but the question was never really settled, and nowadays people just ignore licenses.

Comment by nanolith 2 days ago

OpenBSD has a strict "no GPL" policy. It does not incorporate GPL code in the kernel, and it has slowly weeded out GPL code from userland. This is one reason why it builds with Clang instead of GCC.

If Linux DRM weren't licensed under more permissive terms, OpenBSD simply wouldn't permit its inclusion.

Comment by kpcyrd 2 days ago

When you link GPL code with your proprietary code into a binary (shared address space), and distribute the binary to people, those people are entitled to your proprietary source code.

When I compile my GPL code with a copy of somebody else's MIT code into a binary (shared address space), other people's copy of that MIT code is still MIT licensed.

Comment by throwaway7356 2 days ago

> Traditionally, sharing an address space carried the GPL taint.

Clearly two different files don't share the same address space. So no problem.

Comment by Gracana 2 days ago

TIL, thanks! I wondered if that was the case, but couldn't find a license while clicking around in the code on my phone.

Comment by pizzaiolo 2 days ago

I wonder if it's downloaded after installation, like nonfree codecs in many Linux distros

Comment by rootnod3 2 days ago

Yes. The firmware blobs get downloaded at the end of the install via `fw_update`.

Comment by rootnod3 2 days ago

Specifically in this script https://github.com/openbsd/src/blob/master/distrib/miniroot/...

Just look for `fw_update`

Comment by asmnzxklopqw 2 days ago

Genuine question: if this is only a catch up game, then why not just use the original in the first place?

Comment by jon128 2 days ago

[dead]

Comment by pjmlp 2 days ago

So, AT&T UNIX System V it is then.

Comment by sidkshatriya 2 days ago

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.

Comment by pjmlp 2 days ago

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.

Comment by asmnzxklopqw 2 days ago

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.

Comment by pjmlp 2 days ago

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.

Comment by jacquesm 2 days ago

Linux has effectively been taken over by big business. OpenBSD is still relatively independent.

Comment by 2 days ago

Comment by doener 2 days ago

Via https://news.ycombinator.com/item?id=50154649

Comment by sippingabonedry 2 days ago

[flagged]

Comment by jon128 2 days ago

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.

Comment by oblio 2 days ago

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?

Comment by asveikau 2 days ago

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.

Comment by andrewchambers 2 days ago

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.

Comment by asveikau 2 days ago

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.

Comment by andrewchambers 2 days ago

What makes you say I don't know how to do it?

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.

Comment by asveikau 2 days ago

Because you assumed they would direct an LLM to do it and lie about it. Seems like projection to me.

Comment by andrewchambers 2 days ago

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.

Comment by asveikau 2 days ago

You tell me I'm part of a swarm of people like me, but we haven't met, and I don't think you have enough information to know what a person like me is.

On the other hand my life experience is often that people who accuse others of doing activities in secret, and being dishonest about it, that is often, but I will give you not always, indicative of where their own head is at.

Comment by andrewchambers 1 day ago

I think you misunderstood what I said or I didn't say it clearly. I was speaking in general terms of trends across our industry, not this specific project.

Comment by jamesnorden 2 days ago

"I would bet money they used LLMs and lied about it" (paraphrasing) isn't neutral.

Comment by andrewchambers 1 day ago

I didn't say or intend to say 'they' did it. I said I bet it is being done in general. Maybe that is the core misunderstanding here.

I fully believe the BSD people didn't use it - I just think in general you wouldn't know which projects are doing it and which aren't.

In fact, if you dig into these projects, they have llm disclosures for misc debugging and other things.

Comment by jon128 2 days ago

[dead]

Comment by doublerabbit 2 days ago

I'm very happy and lucky to have to a modern laptop where everything just works including S3 hibernation in FreeBSD.

MSI Modern 15