It also pisses me off a lot ... and I try to change that with every new release when this is broken.

For some reason they do not listen - maybe most of them still use macOS for their desktops and FreeBSD only on servers ...

Maybe you stop spitting pointless hate first? @vermaden@bsd.cafe describes the problem correctly, and never said #FreeBSD "didn't want solutions", but only that they refuse his proposal. And to be fair, I'd refuse this as well, because I think it would just lead to more confusion.

To put this into perspective, we're talking about a rare corner case anyways. The idea of a stable branch is to never introduce breaking changes in the #ABI, and as it was meant, this should include in-kernel ABIs as well, so packages built for X.1 must always work on X.2 as well. Unfortunately, parts of the in-kernel ABI needed for some packages containing #kernel #modules are not stable in practice, and, also unfortunately, this includes a package almost everyone needs on a desktop installation: drm-kmod.

The obvious solution would be to make sure to keep the whole ABI stable as it was originally intended. I have doubts this will work out in practice.

So, you'd need to fiddle with the naming of ABI versions, including the minor release in them, to have distinct repositories for e.g. 14.1 and 14.2 to solve the issue for these rare corner cases. That would of course cost a lot, much more build time for ALL the packages, and also disk space. It would kind of spoil the idea of "stable".

There could be a more involved solution introducing a second "KBI" identifier, only attached to packages containing kernel modules, so only these would need extra builds. I personally think this would be the right thing to do, but it's a very intrusive change, touching the ports framework, the pkg utility, poudriere, the build and repository infrastructure, etc pp → in a nutshell, a damn lot of work for a complex change. 😞

CC: @joel@piou.foolbazar.eu

Sensitive content Click to open/close

We might partly clear the air with as few as two posts.

(1) Our use of foul language.

@vermaden, your headline use of "Fuckup" was acceptable in many places – including the official forums for the FreeBSD Project, where the headline would have been prominent, for a while, on the front page.

Your foul-mouthed headline did not belong on the front page of the FreeBSD subreddit. Perhaps you were unaware of removal. Most remarkable: the certainty that you responded to someone else's comment whilst ignoring a moderator plea to use an alternative title.

To anyone who reads this post (1) from me: please be patient for a second post, which might explain the anger that drove my recent foul-mouthed message in BSD Cafe.

@vermaden

(2) Your ignorance of the Technology Roadmap for FreeBSD.

You promoted the map – as valuable information.

The FreeBSD Foundation promotes the map – prominently, and frequently.

Within the map:

― the first focus area describes release-specific overlays.

Your shouting on 4th December not only demonstrated ignorance, it also devalued and mis-portrayed the FreeBSD Project in a way that was guaranteed to offend any number of people.

Now: we can not guess how many people will read – and believe – your ignorant, offensive post. We can not guess how many people will read the boosts of your ignorant, offensive post.

There's more, however I find it difficult to compose this second post without a resurgence of anger. I have made countless mistakes in the past. Some mistakes are easier to correct than others, especially where pride is involved.

Please do the honourable thing.

#FreeBSD #upgrade #misinformation

@grahamperrin

If you really want another answer from my side - then here you are - but you are not gonna like it.

If it was known in the FreeBSD project that its gonna be broken again - why message such as this one was NOT added to Release Notes?

[WARNING:BEGIN]

In the last minutes of 14.2 release process we found a bug that fixing will temporarily break (for 3 months) all kernel related pkg(8) packages (like drm-kmod or virtualbox for example) because of the way FreeBSD project organizes its package building repositories and support cycles. FreeBSD project is working on a solution that hope to prevent such problems in the future.

[WARNING:END]

I did not saw anything like that in the Release Notes.

... and you are making more drama out of this then #Netflix could have ever dream of.

@TomAoki

Thanks, missed that.

Seem I need to start mention to everytime check ERRATA now after checking Release Notes.

@vermaden
Usually, IIRC, release errata used to be a skeleton (space holder) at the beginning and updated as time goes by (with issues found and/or fixed by patch releases [-p*]).

But as users of graphics/[nvidia-]drm-[510|515|61]-kmod ports increased, the more screams are heard on point releases. So release engineering team were forced to write something about it.

And, as my prediction, release note is not a good place to do so, as this is clearly an issue with how pkgs are built and provided.

What was needed in release note would be, IMHO, pointing there's an open issue described in release errata. Preferrably at Abstract or at the top of Introduction, because Security and Errata section is for "fixed issues until previous release".

@TomAoki

Announcement

– the phrases "known problems" and "please see"

– third link: errata

– near the head of the page.

#FreeBSD

@TomAoki re: "many screams on forums.freebsd.org"

Thanks, I avoid the place, since I quit, now I see <forums.freebsd.org/posts/68198…> on page 1 of 4.

The word "petrol" comes to mind.

Discussion: FreeBSD 14.2-RELEASE Available

freebsd-14-2-release-available.95937 https://www.freebsd.org/releases/14.2R/relnotes/ Some parts, I found notable: Depreciated and Removed Drivers: agp(4) has been planned for removal in FreeBSD...

^{The FreeBSD Forums}

@TomAoki at <forums.freebsd.org/threads/pos…> I see some things that could be corrected or improved.

I'll summarise in Reddit in due course. In the meantime, people may take a hint from part of <mail-archive.freebsd.org/cgi/m…>.

With all that's past, and ongoing, readers might begin to understand why I object so strongly to things such as:

― describing developers as jerks

― describing the FreeBSD Project as not wanting to solve a problem, that was (still is) a quite despicable lie.

Examples of the truth:

― <old.reddit.com/r/freebsd/comme…> (3rd December) Colin attending to release discussions on the day of announcement whilst at an airport, and then <mastodon.bsd.cafe/@grahamperri…> his 4th December report from attendance at the multi-day AWS re:Invent 2024 event, which was relevant to FreeBSD and coincided with release of 14.2

― <bsd.network/@dvl/1136478726041…>

And so on.

Cc and respect to @joel

#FreeBSD #respect #developers #thanks

Possible solution to the drm-kmod kernel mismatch after upgrade...

There are a lot of threads on this subject. It's a thorny problem that often comes up after upgrades from a minor version that has not reached EOL yet. bapt@ has posted a solution to...

^{The FreeBSD Forums}

Graham Perrin

2024-12-14 13:17:43

Colin Percival's AWS re:Invent asks

daemonology.net/blog/2024-12-0…

#AWS #reInvent #ARM #Morello #CHERI #FreeBSD

My re:Invent asks

^{www.daemonology.net}

@grahamperrin
And me too posting DRM related things on most threads without the info I've found. They should be a "single" thread, though, regarding its technical details.

And complaining users should know it is impossible for small project like FreeBSD project to test all up-to-date, latest hardwares. To do so, ALL responsible key persons of ALL hardware manufacturers SHALL pop into FreeBSD project as developers/testers. Just a dream for now, unfortunately.

I can not downplay end users' frustrations with the kernel module (kmod) package build scenario that preceded the recent flurry/hurricane of activity through which spoon-feeding, largely by the FreeBSD Project, has begun.

What irks me is, the popular assumption that the Project should have provided everything. I mean, everything, whilst the Foundation pleads politely – repeatedly – for donations. The year during which attraction of sizeable investments has astounded me, but still, we're short of target figures (and I can not assume that a colossal lump sum to plug a gap will fall daintily from the air, as it has in some past years, for the 2024 budget).

The popular assumption of absolute entitlement, when it should have been ENTIRELY possible for a few imaginative members of communities to collaborate – to provide a complementary service.

Imagine: a complementary, community-driven kmods repo for just one architecture/platform, for just one version of the OS. This would have set a good example. Excite people, positively, to do more. To do good.

Essentially: be nice.

Gain colossal #thanks (not necessarily on a Tuesday in BSD Cafe).

Imagine: a place, an extraordinary Mastodon instance perhaps, where communities overlap.

Rewind. History. Did we have hordes screaming about the Project not providing torrents? No. Simple. We have respectable torrents that are not Project-provided – and the vast majority of people are entirely happy with this somewhat unofficial arrangement.

Fast-forward. Some awkwardness.

Now, people can know why my "no particular order" at <mastodon.bsd.cafe/@grahamperri…> was a lie with regard to the second thing there: torrents. Big #thanks to those people.

Me being #uppity here, today, does not dilute the Tuesday #thanks there.

Peace

cc @lproven @emaste @stefano @FreeBSDFoundation @TomAoki #FreeBSD #community

Graham Perrin

2024-12-10 07:31:16

In no particular order …

Eric Turgeon – for package repositories, and more.

John-Mark Gurney, Vincent Milum Jr, and others – for FreeBSD-related torrents, seeds, and so on.

Thomas Hurst – for FreshBSD.

Dan Langille – for FreshPorts.

Lucas Holt – for MidnightBSD.

Dmitry Salychev, Grégory Reinbold, Lars Engels, Marcel Kaiser, and Mehmet Mert Gunduz – for NomadBSD.

Shawn Webb – for co-founding HardenedBSD.

JT Pennington, Ken Moore, Kris Moore, and others – for PC-BSD, Lumina Desktop, TrueOS, TrueNAS, and more.

Bob Bruce, David Greenman, Jack Velte, Jim Mock, Jordan Hubbard, Murray Stokely, Pat Rietz, Rod Grimes, Theresa Elam, and others – for FreeBSD Mall, formerly known as Walnut Creek CDROM, and more.

Thom Holwerda – for OSnews.

Jesse Smith – for DistroWatch.com.

Stefano Marinelli – for BSD Cafe, and more.

Liam Proven – for no bullshit, by him on, you know.

pfSense of humor – for an excellent sense of humour, and more. I'm tempted to say "nothing more", but that'll be stretching his sense of humour. Too far.

The shortlist above should be much, much longer. Eye-wateringly long. The full list would take so long to compile that Wednesday will arrive in all time zones on planet Earth before I finish. Fact: if I don't click 'Post' ― now ― I'll make myself late for work. Again.

E&OE

#ThankYouTuesday

@TomAoki @grahamperrin @emaste @stefano @FreeBSDFoundation

I do not understand what "does it feasible" means.

I upgraded FreeBSD 13.3 to 14.0. It broke X.org on 2 testbed laptops.

As a direct result I skipped testing or writing about FreeBSD 14.0 or 14.1. Some months after the event I managed to manually get X11 working on my machines but my display manager was gone. I had to log in from the command line like it was 1989 or something.

When 14.2 came out I tried again.

I upgraded to 14.1. It was fine. I upgraded that to 14.2.

This time *it broke the console*. Not merely X but the text console.

I have only been experimenting with FreeBSD for about 3 years now but I am already becoming _deeply_ disenchanted with it.

I write for a living. I have had many angry FreeBSD users writing to me, on email and in social media, denying that what happened to me is possible. I also get that in my articles' comments.

So this year I went to the EuroBSDCon and talked in person to some of the core team and I learned that I was in fact right, that there are undocumented system requirements, and that the things I've found are mostly real but are not considered important.

It is *not good.*