Read these 2 announcements to see what was happening and what to do afterwards for fixups.
https://lists.freebsd.org/archives/freebsd-announce/2026-July/000294.html
https://lists.freebsd.org/archives/freebsd-announce/2026-July/000295.html
Read these 2 announcements to see what was happening and what to do afterwards for fixups.
https://lists.freebsd.org/archives/freebsd-announce/2026-July/000294.html
https://lists.freebsd.org/archives/freebsd-announce/2026-July/000295.html
Just my personal thoughts, but I think there are 2 "ideal" political systems.
One is "perfect heroic dictatorship", and another is "fully realized communism".
Both are impossible for human beings. So the correct answer should be anywhere in the middle.
The former requires "100% perfect hero" that doesn't have self-interested at all. lim 100% is insufficient and real 100% is mandatory.
The hero "predicts" that anyone others have self-interested thoughts at any rate, comparing the hero's "100% pure public interest and public desire", with deep and intensive studies.
Yes, human beings cannot be as such, thus, "perfect heroic dictatorship" is impossible.
For the latter, human being cannot be "perfect parts of the whole social system". Cannot make personalities to be 0%. lim 0% is too huge and real 0% is mandatory. Impossible.
I cannot understand why such a silly law was even discussed.
The problem the law want to resolve is at "user facing service" level like SNS.
And at least theoretically, SNS service softwares can have user IDs / age verification data etc. completely independent from underlying OS.
Why require OS to keep age verification data, even if user-facing services can ignore accounts on OS inside the services? Not at all understandable.
Does the law (I'm not a resident of places having such a law) mandate ALL applications to use OS side user IDs directly? If so, and there's unignorabully huge penalty, make just a bit of sense.
I want to propose prohibiting to use OS-side IDs directly for SNS services and mandate managing by itself. It would make it easier to keep privacy if multiple services are running on single computer.
Latest Production Branch of NVIDIA GPU driver 595.80 and latest New Feature Branch of NVIDIA GPU driver 610.43.02 -devel variants just landed onto latest (aka main) branch of FreeBSD ports tree.
https://cgit.freebsd.org/ports/commit/?id=e94bcef6b11d8e72392600b83d9a5b0de0a15fed
https://cgit.freebsd.org/ports/commit/?id=fd3541282146dacd8fe86c3eec81e34dedf5d683
The updates are now landed on latest (main) branch of ports tree.
https://cgit.freebsd.org/ports/commit/?id=536352bd7c13b49c985d0e07474d7258ba793fbe
A set of NVIDIA counterpart of graphics/drm-612-kmod are under review as D57206.
https://reviews.freebsd.org/D57206
Also available via Bug295519 (actually the same patch).
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295519
Anyone having issues with graphics/nvidia-drm-66-kmod{-580|-devel} or previous version (at DRM6.9) of graphics/nvidia-drm-latest-kmod{-580|-devel} and not hesitating to build ports locally can try my above-mentioned patch if you're on 15.1{-BETA*|-RC*} or upcoming -RELEASE, or recent enough stable/15 and main.
Note that, as graphics/drm-612-kmod and graphics/drm-latest-kmod bumped to DRM6.12 are NOT available on 2026Q2 quarterly, NVIDIA counterparts shouldn't appear on 2026Q2 even after the patch lands onto main (aka latest) branch (would appear on upcoming 2026Q3).
In early days of Internet for "consumers", the resources allowed were far more limited, and connections were "dial-up" basis. So most "near-open" solution was to connect to more ancient BBS services via telnet access points (i.e., NIFTY serve in Japan which [I heared] is Compu-serve alike), but not all BBS services that anyone can subscribe (with or without fee) provided such an connections. So open communities for open source codes were difficult to start up.
But now, we have excellent services like here.
In Japanese, though, possibly you'll be interested.
I myself never tried, but there's LUNA 68k/88k emulator, nono introduced here.
Upstream here (Japanese site).
Note that FreeBSD 15.0-RELEASE and later has /lib/libsys.so.7 which is syscalls parts splitted out from /lib/libc.so.7 (and libc depends on libsys).
It would help languages other than C to implement language-specific base libraries independent from whole libc.
Maybe not so useful for many, but some screen editors are not good at handling looooong single line, even if the whole bunch of file size is small.
An example of this situation would be copy (from terminal emulator) and paste to editor window the output from poudriere to see specific ports are included in skipped (or succeeded) ones on building a large number of ports. Built, ignored, failed, skipped ports has single output line respectively.
In this specific cases, editors/leafpad (and IIRC, editors/pluma, too) locks up on horizontal scrolling (in case turned over at right end of window, vertical, too) or searching. devel/geany works fine.
Just examples I've tried before.
It would be nice if...
For example, I imagine if anyone belonging to @bsd.cafe pastes some URL from the tab that mastodon client is running, it would be something like ```
https://mastodon.bsd.cafe/@User/11111
and if anyone belonging to @bsd.netowork attempts to open the toot via the link, converted to
https://mastodon.bsd.netowork/@User@bsd.cafe/11111
with input to indicate the conversion is wanted or not on click.
Maybe annoying to implement, though.
Basically, Quarterly, the default for *-RELEASE, gets security upgrades, build fixes and fixes for anything stopped working to work again only.
And Quarterly branches from main (aka latest) every quarter (early Jan., Apr., Jul. and Oct.).
Next one (2026Q2) would be branched in early April (soonish).
If you want to use anything new but running supported *-RELEASE, you need to manually switch default pkg repo to latest.
But as it means there could be more breakages on latest, (re-)read Chapter 4 of the handbook, especially Chapter 4.4.2, before trying and decide whether to switch or not.
Thanks for this new place to sit and discuss!
But the opening date was a bit unfortunate, first thought it's April Fools' joke.