Create accountLogin

Recent searches

No recent searches

Search options

Only available when logged in.
eupolicy.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
This Mastodon server is a friendly and respectful discussion space for people working in areas related to EU policy. When you request to create an account, please tell us something about you.

Administered by:

Server stats:

224
active users

eupolicy.social: AboutProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.3.6

#freebsd

64 posts52 participants0 posts today
Public
Michael Dexter

The June 3rd, 2025 Jail/Zones Production User Call is up:

youtu.be/rp20cZXQ_NY

We discussed adding Podman FreeBSD native features in Go, a GSoC project to add journaling to FreeBSD's ext2fs, OpenBSD open(2) and O_BELOW, #FreeBSD 15.0-RELEASE features and goals, and more!

"Don't forget to slam those Like and Subscribe buttons."

youtu.be- YouTubeEnjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.
Public
TomAoki

Filed Bug 287268 to add -devel version of #nvidia GPU driver on #FreeBSD #Bugzilla. This is planned to track basically New Feature Branch (NFB) of drivers, but if Production Branch of driver has larger version number, temporarily switches to it until new NFB is released upstream.
Note that Beta Branch of drivers are not tracked, although supports for them are incorporated in-tree in preparation of new NFB release, as versions on -devel branch.
bugs.freebsd.org/bugzilla/show

Now it's at 575.57.08.
nvidia.com/en-us/drivers/detai

Currently, pruning of deprecated ports seems to be ongoing (and some of which are requested to be reverted), causing category Makefile to be modified. So holding to open review on Phablicator to see there could be more or not for maybe 1 or 2 more days.

bugs.freebsd.org287268 – [NWE PORT] x11/nvidia-driver-devel, x11/linux-nvidia-libs-devel, graphics/nvidia-drm[,510,515,61,66]-kmod-devel: Add new port
Continued thread
Public
Felix Palmen :freebsd: :c64:

Solved! 🥳

This was a pretty "interesting" bug. Remember when I invented a way to implement #async / #await in #C, for jobs running on a threadpool. Back then I said it only works when completion of the task resumes execution on the *same* pool thread.

Trying to improve overall performance, I found the complex logic to identify the thread job to put on a pool thread a real deal-breaker. Just having one single MPMC queue with a single semaphore for all pool threads to wait on is a lot more efficient. But then, a job continued after an awaited task will resume on a "random" thread.

It theoretically works by making sure to restore the CORRECT context (the original one of the pool thread) every time after executing a job, whether partially (up to the next await) or completely.

Only it didn't, at least here on #FreeBSD, and I finally understood the reason for this was that I was using #TLS (thread-local storage) to find the context to restore.

Well, most architectures store a pointer to the current thread metadata in a register. #POSIX user #context #switching saves and restores registers. I found a source claiming that the #Linux (#glibc) implementation explicitly does NOT include the register holding a thread pointer. Obviously, #FreeBSD's implementation DOES include it. POSIX doesn't have to say anything about that.

In short, avoiding TLS accesses when running with a custom context solved the crash. 🤯

Public
Doerk

I was just wondering if I am the only person among the FreeBSD users having issues with LSPs? Seems like there are many LSPs that are not working under FreeBSD. Tried to integrate some in my Neovim setup just to notice that quite a lot of them are not working or at least are not supported on FreeBSD Mason and Lazy seem to complain about everything. How are you guys dealing with this?

#FreeBSD#LSP#Neovim
Public
ivy

yet another ACME client, based on uacme: github.com/llfw/lfacme

good:
+ uses uacme and POSIX /bin/sh
+ better configuration/hook system than dehydrated
+ comes with manpages
+ small and simple
+ supports Kerberized dns-01 domain validation

bad:
- only supports Kerberized dns-01 domain validation (but this could be improved)
- only tested on FreeBSD (but this could be improved too)

/cc @_bapt_

a simple ACME client based on uacme. Contribute to llfw/lfacme development by creating an account on GitHub.
GitHubGitHub - llfw/lfacme: a simple ACME client based on uacmea simple ACME client based on uacme. Contribute to llfw/lfacme development by creating an account on GitHub.
#freebsd#letsencrypt#acme
Public
The Psychotic Network Ferret

I think I need more reasons to use #OpenBSD. I used to be a heavy user, even used to run it on my laptop, but currently manage zero installations.

I also think I should give #NetBSD a fair shake, I've only ever installed it twice, and never really given it a chance.

Using OpenBSD is easy, I'll probably convert my wireguard router over to it.

But any suggestions on NetBSD use cases? I mean this from the context of a heavy #FreeBSD user with a massive emphasis on jails.

#BSD#UNIX
Public
U+002C

dear freebsd lazyweb: what do i need to do about about a freebsd port that doesn't have package builds? py-libtorrent-rasterbar doesn't have builds for 14/amd64, and that means i can't update deluge (in fact, it removed it because a transitive ABI dependency got bumped). it doesn't seem to be marked as broken, so i'm not sure why it's not there

i could make package from the ports tree, but that is a mild pain in the ass i would prefer not to do on my slow NAS

www.freshports.orgFreshPorts -- net-p2p/py-libtorrent-rasterbar: Python bindings for libtorrent-rasterbarThe python binding of libtorrent, an open source C++ library implementing the BitTorrent protocol.
#freebsd
ExploreLive feeds
About