@vermaden WTF.

Stop spreading jumped-up misinformation about the FreeBSD Project not wanting solutions.

If you want a pointer, to evidence, you could begin by showing some fucking respect.

Cc @joel

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 <https://forums.freebsd.org/posts/681980> on page 1 of 4.

The word "petrol" comes to mind.

@TomAoki at <https://forums.freebsd.org/threads/possible-solution-to-the-drm-kmod-kernel-mismatch-after-upgrade-from-bapt.96058/> 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 <https://mail-archive.freebsd.org/cgi/mid.cgi?be9146d1-a895-4e52-91c1-85186bb86cbe>.

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:

― <https://old.reddit.com/r/freebsd/comments/1h59yk6/freebsd_142release_now_available/m04h9c4/> (3rd December) Colin attending to release discussions on the day of announcement whilst at an airport, and then <https://mastodon.bsd.cafe/@grahamperrin/113651368822521287> 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

― <https://bsd.network/@dvl/113647872604140584>

And so on.

Cc and respect to @joel

#FreeBSD #respect #developers #thanks

@grahamperrin @joel
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.