AI models don’t really 'get' the BSDs. As a result, they often provide incomplete, imprecise, or flat-out wrong answers by defaulting to Linux paradigms. When it comes to illumos-based systems, they just completely lose the plot.

This is becoming a serious issue for the BSDs and illumos ecosystems. We are seeing entire websites flooded with AI-generated tutorials and guides that are totally incorrect. Most people don't realize this; they follow the instructions, fail, and then assume that the BSDs doesn't work well or are 'unstable' because they have supposedly changed since the guide was written.

Luckily, some people eventually find my blog, reach out, and finally understand what's actually going on. Others, unfortunately, end up on major social sites or comments, claiming that these systems are broken.

In 2026, one of our greatest challenges will be teaching people how to vet their sources and filter information.
And I see this as a very, very uphill battle.

#IT #SysAdmin #FreeBSD #NetBSD #OpenBSD #illumos #News #UnderstandingText #Disinformation

Still far away but not to far away from now in a country close, close by....

The European *BSD event of 2026! 😈⛳🐡

Registration is open!! 🔖

🎟️ https://tickets.eurobsdcon.org/eurobsdcon/brussels/

Sign up early and sign up lots!

While you're at it, don't forget to drop your abstract like it's hot! 🔥
https://events.eurobsdcon.org/

We are still and always looking for first-time *BSD speakers.
Whether you are just starting out or have a unique perspective to share, your voice matters!

The schedule will be published on 🗓️ 2026-07-15

For everything else, peek at https://2026.eurobsdcon.org/
More information is added all the time.

EuroBSDCon 2026 in Brussels, Belgium 🇧🇪
September 09-13, 2026

#RUNBSD #FreeBSD #NetBSD #OpenBSD #EuroBSDCon #EuroBSDCon2026 #BSD #CFP #Conference #Register

Alt...

An image of Matt LeBlanc as Joey Tribbiani, sticking his head around the door, wide eyed. It has the text: Did someone say ticket?

The extra magic spells to put the secondary #dhcpd and #unbound services in #FreeBSD jails; while still be able to synchronize with #OpenBSD.

https://www.tumfatig.net/2026/dhcpd-and-unbound-in-freebsd-jails/

I didnt have much doubt as standard USB audio tends to be pretty widely accepted by most OSes these days. ( Hell, I used to use USB audio with BeOS back in the day. )

But if anyone is wondering, those USB adapters that let you pair bluetooth headphones with a PS4 work well with #FreeBSD.

AND yeah, of course they do. FreeBSD is what is driving the Playstation 4 after all.

FediMeteo, HAProxy, and the art of not wasting snac threads

How FediMeteo uses HAProxy caching, static pages, and small FreeBSD jails to keep snac quiet and serve ActivityPub traffic efficiently.

https://it-notes.dragas.net/2026/05/18/fedimeteo-haproxy-and-the-art-of-not-wasting-snac-threads/

#FediMeteo #snac #snac2 #haproxy #freebsd #it #sysadmin #ITNotes

When I wrote about FediMeteo (https://it-notes.dragas.net/2025/02/26/fedimeteo-how-a-tiny-freebsd-vps-became-a-global-weather-service-for-thousands/) for the first time, I told the story from the beginning: the idea born almost by chance while checking the weather for a holiday, the memory of my grandfather, who for years had been my personal meteorologist, the decision to build something small and useful, and then the surprise of seeing people actually use it. What began as a personal experiment quickly became a small global service, still running with the same philosophy: FreeBSD, jails, simple scripts, snac, text, emoji, and a lot of small pieces doing their work quietly.

That article was mostly about the birth and growth of the project. This one is about one of the less romantic parts of the same story, although I have to admit that I find a certain beauty in it too: keeping the service light as it grows.

FediMeteo (https://fedimeteo.com) is still intentionally simple from the outside. A homepage, some numbers, a list of countries, and many ActivityPub accounts publishing weather forecasts. The posts are text and emoji. There is no JavaScript requirement to read the pages, no heavy frontend, no unnecessary media attached to every forecast, and no dynamic homepage recalculated at every visit just to show the same numbers. This is not accidental. It is the way I wanted the service to behave from the beginning.

But the more the service is used, the more the small details matter. A request that looks harmless when there are ten followers may become a repeated request when there are thousands of followers, remote instances, crawlers, previews, and other servers fetching the same public objects. In the Fediverse, the same small thing can be asked many times by many different places, each one with a perfectly legitimate reason. The backend doesn't care: it just needs to deal with the requests.

And in FediMeteo, the backend is snac (https://codeberg.org/grunfink/snac2).

I like snac very much precisely because it is small, clear, and efficient. It is not a giant application that tries to be everything. It does a focused job and does it well. But this also means that I want to respect its shape. I do not want to waste its threads on work that the reverse proxy can safely do. A snac thread serving the same public avatar again and again is not a tragedy, but it is still a waste. A snac thread answering the same public ActivityPub object several times in the same minute is doing real work, but often not necessary work.

This is the reason behind the HAProxy (https://www.haproxy.org) tuning I am currently using in front of FediMeteo.

It is not about making the configuration look clever. It is about keeping snac quiet.

A continuation of the same idea

This is especially important because snac uses a limited number of threads. I like that. Limits are healthy. They force us to understand what the service is doing, and they prevent a small program from pretending to be an infinite resource. But limits also make waste visible. If a few threads are busy serving files that could have been served from cache, those threads are not available for something more useful.

With FediMeteo the implementation is different because the reverse proxy is HAProxy, but the reasoning is the same. I have many small snac instances, each one in its own FreeBSD (Bastille (https://github.com/BastilleBSD/bastille)) jail, and one public entry point that has to route, terminate TLS, compress, cache, and generally remove as much repetitive work as possible from the backends.

This is, in a way, the natural continuation of the original FediMeteo design. In the first article I wrote that I wanted to manage everything according to the Unix philosophy: small pieces working together. This is another piece of that same puzzle. HAProxy does the edge work. snac does the ActivityPub work. Scripts generate forecasts. cron launches updates. ZFS gives me snapshots. FreeBSD jails keep countries separated. Nothing is particularly heroic by itself, but the whole system becomes pleasant because each part has a clear responsibility.

Why there is almost no media

FediMeteo does not use media in its forecasts.

No images attached to the posts, no generated weather cards, no maps for each city, no decorative banners. The forecasts are text and emoji. This was a deliberate decision. Weather information does not become more useful just because it is put inside an image, and every media file used by the service would become something to store, serve, cache, federate, expire, back up, and occasionally debug.

Text and emoji are enough. They are accessible, light, readable in text browsers, friendly to timelines, and understandable even when someone does not know the local language perfectly. This was one of the original design principles of FediMeteo, and it also helps the infrastructure. Less media means less work, fewer cache entries, fewer repeated fetches, fewer surprises.

There is one exception: the avatar.

All FediMeteo accounts use the same avatar, and this is also intentional. I could have used a different avatar for each country, or for each city, or created something visually richer. It would have been nicer in some screenshots, perhaps. It would also have been operationally worse.

With one shared avatar, the reverse proxy has one very useful object to cache. It is public, identical for everyone, small, requested often, and therefore almost always hot in cache. HAProxy can serve it directly instead of asking each snac instance to return the same file. Since avatars are requested by remote instances, browsers, profile previews, and all sorts of federation-related fetches, this single decision removes a surprising amount of pointless backend traffic.

So the avatar is not only a visual identity. It is part of the architecture.

This is the kind of optimization I like most, because it starts before the software. It starts with deciding not to create a problem.

The homepage is static because it can be static

It is a static HTML page generated from a template. Once per hour, a cron script updates the numbers and statistics. It counts the data I want to show, regenerates the page, and then the page remains static until the next run.

This is not because I cannot make a dynamic page. It is because I do not need one. Boring is good.

The homepage does not need to query all the country instances on every visit. It does not need a database request for each user who opens it. It does not need to ask snac anything in real time. The numbers are useful, but they do not need to be updated every second. Once per hour is enough, and it also fits the spirit of the whole project: do the work when it is needed, then serve the result cheaply.

I have seen too many small services become heavy because the first implementation was convenient rather than appropriate. A cron job and a template are not fashionable, but they are often exactly what a page like this needs.

Many countries, one entry point

fedimeteo.com
www.fedimeteo.com
it.fedimeteo.com
uk.fedimeteo.com
jp.fedimeteo.com
us.fedimeteo.com
usa.fedimeteo.com
can.fedimeteo.com
canada.fedimeteo.com

At the beginning, it is always tempting to write one ACL after another in the HAProxy frontend. It is quick, it is explicit, and for five hostnames it is perfectly fine. But FediMeteo did not remain at five hostnames. As countries and aliases grew, a long chain of ACLs would have turned the frontend into a list of names instead of a description of how the proxy behaves.

So I moved the hostname to backend mapping into a map file:

fedimeteo.com        backend_fedimeteo
www.fedimeteo.com    backend_fedimeteo
it.fedimeteo.com     backend_it
uk.fedimeteo.com     backend_uk
jp.fedimeteo.com     backend_jp
us.fedimeteo.com     backend_us
usa.fedimeteo.com    backend_us
can.fedimeteo.com    backend_ca
canada.fedimeteo.com backend_ca

use_backend %[req.hdr(host),field(1,:),lower,map(/usr/local/etc/fedimeteo.map,backend_fedimeteo)]

I like this because it keeps the configuration honest. The frontend contains the policy. The map contains the data. Adding a country means adding an entry to the map and defining a backend. I do not need to make the frontend more complicated every time the service grows.

Backends as small compartments

backend backend_it
    mode http
    http-reuse safe
    server srv1 10.0.0.2:8001 maxconn 30
backend backend_uk
    mode http
    http-reuse safe
    server srv1 10.0.0.7:8001 maxconn 30
backend backend_jp
    mode http
    http-reuse safe
    server srv1 10.0.0.32:8001 maxconn 30

The maxconn 30 value is not a magic number. It is a ceiling. I want each small backend to have a visible limit in front of it. If something starts hammering a country instance, I prefer the pressure to appear at the HAProxy layer instead of becoming unlimited concurrent work inside snac.

http-reuse safe lets HAProxy reuse backend connections where appropriate. This is another small reduction in unnecessary work. Opening connections repeatedly is not the biggest problem in the world, but avoiding it is still better, especially when many small services sit behind the same proxy.

The front door

frontend https_in
    bind :::443 v4v6 ssl crt /usr/local/etc/certs/ alpn h2,http/1.1
    mode http
    option http-keep-alive

ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets

acl letsencrypt-acl path_beg /.well-known/acme-challenge/
http-request redirect scheme https code 301 unless letsencrypt-acl
use_backend letsencrypt-backend if letsencrypt-acl

http-request set-header X-Real-IP %[src]
http-request set-header X-Forwarded-Proto https

http-response set-header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Two caches, because the requests are different

cache mediacache
  total-max-size 128
  max-object-size 10000000
  max-age 3600
  process-vary on
  max-secondary-entries 12
cache jsoncache
  total-max-size 16
  max-object-size 1000000
  max-age 60
  process-vary on
  max-secondary-entries 12

The media cache is larger and has a longer maximum age. In FediMeteo, this mostly means the shared avatar and a few static-looking objects. Since there is intentionally almost no media, the important cached object is requested very often and remains warm.

The JSON cache is smaller and short-lived. It is there for public ActivityPub GET requests, not to store federation state forever. A 60 second cache is enough to collapse many repeated requests that arrive close together in time, without pretending that ActivityPub responses should be treated like immutable files.

This distinction is important. Caching is not one decision. It is a set of small decisions about what a response means, who can see it, how often it changes, and what happens if it is served again.

Recognizing media

acl is_media path_end -i .jpg .jpeg .png .gif .webp .svg .ico .mp4 .webm .mp3 .ogg .wav .flac .mov .avi .mkv .m4v

http-request set-var(txn.is_media) bool(true) if is_media

http-request cache-use mediacache if { var(txn.is_media) -m bool true }

http-response set-header Cache-Control "max-age=3600, public" if { var(txn.is_media) -m bool true }
http-response del-header Set-Cookie if { var(txn.is_media) -m bool true }
http-response del-header Vary if { var(txn.is_media) -m bool true }
http-response cache-store mediacache if { var(txn.is_media) -m bool true }

This is aggressive only if removed from its context. In this service, with this media policy, it is a reasonable choice. FediMeteo is not serving private media under these paths. It is mostly serving the same public avatar over and over.

For the same reason, I clean the request before it reaches the backend:

http-request del-header Authorization if { var(txn.is_media) -m bool true }
http-request del-header Cookie        if { var(txn.is_media) -m bool true }

The result is exactly what I want: the shared avatar becomes an almost perfect cache object. Small, public, repeatedly requested, and served by HAProxy instead of snac.

ActivityPub JSON microcaching

acl is_ap_json   req.hdr(Accept),lower -m sub application/activity+json
acl is_ap_ldjson req.hdr(Accept),lower -m sub application/ld+json
acl is_outbox    path_end /outbox
acl is_get       method GET
acl has_auth     req.hdr(Authorization) -m found
acl has_cookie   req.hdr(Cookie) -m found

So I only mark public ActivityPub GET requests as cacheable:

http-request set-var(txn.is_activitypub) bool(true) if is_get !is_outbox is_ap_json !has_auth !has_cookie
http-request set-var(txn.is_activitypub) bool(true) if is_get !is_outbox is_ap_ldjson !has_auth !has_cookie

It must be a GET, because I am not caching deliveries or anything that changes state. It must not be /outbox, because outbox collections are not the traffic I want to cache here. It must not have Authorization, and it must not have cookies, because authenticated or user-specific requests do not belong in a shared public cache.

Then the cache can be used and populated:

http-request cache-use jsoncache if { var(txn.is_activitypub) -m bool true }
http-response set-header Cache-Control "max-age=60, public" if { var(txn.is_activitypub) -m bool true }
http-response cache-store jsoncache if { var(txn.is_activitypub) -m bool true }

This is microcaching in the most practical sense. It reduces repeated work without changing the nature of the service.

Static media paths

acl is_short_path path_reg ^/[^/]+/s/
http-request cache-use mediacache if is_short_path

In FediMeteo this is less central than on a normal social instance, because I deliberately do not use media except for the avatar and basic static objects. Still, the rule fits the general policy: let HAProxy handle repeatable edge work, and let snac spend its threads where they are actually needed.

Vary, but not without limits

process-vary on
max-secondary-entries 12

For media, I remove Vary before storing the response. A shared avatar does not need to vary by Accept. For ActivityPub JSON, I am more careful because the representation matters.

Again, the important thing is not the number itself. It is the decision to make variation explicit and limited.

Seeing whether it works

http-response set-header X-Cache-Status HIT if !{ srv_id -m found }
http-response set-header X-Cache-Status MISS if { srv_id -m found }

Did this request reach snac?

A test can be as simple as:

curl -I https://it.fedimeteo.com/path/to/avatar.png
curl -I https://it.fedimeteo.com/path/to/avatar.png

For ActivityPub JSON, the test must use the right Accept header:

curl -I \
  -H 'Accept: application/activity+json' \
  https://it.fedimeteo.com/some/activitypub/object

curl -I \
  -H 'Cookie: test=value' \
  -H 'Accept: application/activity+json' \
  https://it.fedimeteo.com/some/activitypub/object
curl -I \
  -H 'Authorization: Bearer fake' \
  -H 'Accept: application/activity+json' \
  https://it.fedimeteo.com/some/activitypub/object

Compression and operational paths

filter compression
compression algo gzip
compression type text/css text/html text/javascript application/javascript text/plain text/xml application/json application/activity+json

There is also a local Prometheus exporter:

frontend prometheus
  bind 127.0.0.1:8405
  mode http
  http-request use-service prometheus-exporter
  no log

What this changes in practice

The map keeps hostname routing manageable. The backend definitions keep each country isolated and limited. The static homepage avoids dynamic work for something that changes once per hour. The shared avatar gives HAProxy one very hot media object to serve directly. The media cache keeps public files away from snac. The JSON microcache absorbs short ActivityPub bursts. Header cleanup prevents useless variation. Connection reuse avoids unnecessary backend connection churn.

But all of this is only a longer way of saying one thing:

fewer requests reach snac.

That is the metric I care about here.

Not because snac is slow. If anything, FediMeteo exists in its current form because snac is efficient enough to make this kind of project possible on a very small VPS. But precisely because the whole architecture is small and pleasant, I do not want to waste resources where there is no need.

This is also consistent with the rest of the project. Forecasts are serialized by scripts. Updates happen every six hours. The homepage is regenerated hourly. Countries live in separate jails. Snapshots and backups are handled outside the application. No single component tries to be the entire system.

HAProxy is just another small piece, but it sits in the right place to remove a lot of repeated work.

Caveats

It matches FediMeteo as it is now: almost no media, one shared avatar, static homepage, public forecasts, many small snac instances, and ActivityPub traffic that can benefit from a short public cache when there are no cookies or authorization headers.

If I decide one day to use media in forecasts, the media cache rules will need to be reviewed. If I use different avatars for each city or country, the cache will still work, but I will lose the very nice property of one shared, always-hot avatar. If ActivityPub responses become actor-dependent, public JSON caching must be reconsidered. If one country grows a very different traffic pattern from the others, it may deserve a different limit or policy.

This is why I do not like presenting configurations as magic. A good configuration is a written form of the assumptions behind a service. When the assumptions change, the configuration must change too.

Conclusion

The HAProxy layer follows this idea. It terminates TLS, routes hostnames through a map, reuses backend connections, serves the shared avatar from cache, microcaches public ActivityPub JSON, avoids authenticated and cookie-based traffic, and gives me a small diagnostic header to see what is happening.

There is no single brilliant directive here. There is only the usual work of matching infrastructure to reality.

FediMeteo publishes weather forecasts as text and emoji. The homepage is static HTML updated every hour. The accounts share the same avatar because it is enough, and because it is better for the cache. Each country has its own snac instance in its own FreeBSD jail. HAProxy stands in front of them and tries, quietly, not to bother them unless it has to.

I like this kind of infrastructure.

Not because it is invisible, but because when it works well, it leaves very little to say.

https://it-notes.dragas.net/2026/05/18/fedimeteo-haproxy-and-the-art-of-not-wasting-snac-threads/

#ITNotes #NoteHUB #fediverse #freebsd #haproxy #hosting #jail #networking #ownyourdata #server #snac #snac2 #social #web

IDEs, UNIX, AND THE LEGACY WORKFLOW THAT NEVER WENT AWAY

Words of Wisdom are dispensed in the article

I have a workflow consisting of

• screen
• bash or one of
• csh
• ksh
• zsh
• vim or
• vim.motif
• function third(){ awk '{if (NR%3==0){print "\033[32m" $0 "\033[0m"} else{print}}'; }
• function psgrep() { ps axuf | grep -v grep | grep "$@" -i --color=auto; }
• function mkcd(){ [ ! -z "$1" ] && mkdir -p "$1" && cd "$_"; }
• gcc
• g++
• asm
• ln
• go from golang
• lsd
• ncdu

These choices are deliberate. I want and demand the fastest programming ENV: which follow the UNIX principle & KISS

quotes

tl;dr*

Unix already solved many IDE problems decades ago using small cooperating tools instead of one large application.

• bash
• coreutils
• less
• tmux
• nvialready form a complete and focused development environment for many Unix workflows.

The shell becomes the workspace, the terminal manages sessions, and the editor remains small and predictable

sources:

man sh(1)

man ls(1)

man coreutils(1)

man less(1)

man screen(1)

man tmux(1)

man vim(1)

https://www.gnu.org/software/screen/

https://repo.or.cz/code-notes.git/blob_plain/HEAD:/notes/Unix_As_An_IDE.txt

https://go.dev/doc/install

https://go.dev/doc/tutorial/getting-started

#programming #UNIX #gcc #g++ #asm #ln #golang #lsd #ncdu #ncurses #BSD #freeBSD #ghostBSD #openBSD #Linux #OpenSource #POSIX

@trashheap @hakayova Why not a try x11/gnome-flashback (continued of GNOME 2 area) ?
For Pantheon, I've been using this desktop environment for 4 years on #FreeBSD.

Patching my laptop against the new Fragnesia #linux vulnerability, by installing #FreeBSD. (I kid, I kid.)

@trashheap I've been using KDE forever, so I'm biased. If you haven't used either of them predominantly before, I'm not sure if that choice matters a lot, as long as the base system is #FreeBSD.

So I seem to be backing up my system before switching back to #FreeBSD after a few months away. What Desktop Environment though? KDE? or XFCE? or something else?

Seven years of running FreeBSD on ThinkPads alongside Linux — lessons I'd give my younger self

<https://www.reddit.com/r/freebsd/comments/1tedyva/seven_years_of_running_freebsd_on_thinkpads/>

＂I daily-drive Linux at work and FreeBSD on my personal ThinkPads (T480 & P52 currently). Both laptops and both operating systems, every day. I'm the kind of person who reads freebsd-update output and Phoronix benchmarks in the same hour.

＂Recently saw the "is FreeBSD really that goated" thread and it brought back the timeline of my own journey. Started with a rough —call it version 0.9 — build that barely had X11 working, evolved through five iterations, landed on something I'd call "production-stable personal desktop" around version 2.0 on FreeBSD 15.0 with a heavily customized MATE, ZFS boot environments, BastilleBSD jails for microservices, WireGuard tunnels and PF.

＂If I could send a packet back in time to my earlier self, here's what I'd put in the payload: …＂

The image here is for <https://www.reddit.com/r/freebsd/comments/1tedyva/comment/om1t5mg/> because we can all agree that em dashes make scintillating conversation.

#goated #X11 #Wales #FreeBSD #BSD #Linux #ZFS #OpenZFS #Beastie #daemon #MyLittlePony #unicorn #dolphin #rainbow #IBM #Lenovo #BastilleBSD #WireGuard #AI #purple

Alt...

My prompt to ChatGPT: Draw a unicorn that has been genetically combined with a dolphin. The creature is flying across a rainbow whilst a gentle rain falls on lush green Welsh meadows beneath the rainbow. The sky, in the background, is an unnaturally vivid shade of purple. Below the rainbow: a quaint cottage with a person stood at the front door. The person is the mascot for BSD (Beastie). On the lawn in front of the cottage: a badly broken old IBM ThinkPad. In the sky, to the left of the rainbow: instead of a golden sun, place the FreeBSD logo (a red orb with horns).

@joel @trashheap
You've not mentioned about hw.nvidiadrm.modeset tunable in your page.
But if you want /boot/nvidia-drm.ko to actually work,
hw.nvidiadrm.modeset=1
would be needed in your /boot/loader.conf. Otherwise drivers should work with old-school way (aka UMS in contrast with KMS). nvidia-drm.ko would be loaded but ignored but nvidia-modeset.ko and nvidia.ko works.

As yours are RTX 4060 Ti, you're safe but RTX 5xxx series are known to require GSP firmware to be loaded to work. For this, if you upgrade to RTX 5xxx or later series, you'll additionally need tunable
hw.nvidia.registry.EnableGpuFirmware=1
in your /boot/loader.conf for it. (It could disallow suspend/resume, though.)

If you want fallback to old GPUs that doesn't have GSP in it (pre-Turing gen.), you can specify
hw.nvidia.registry.EnableGpuFirmware=17
instead.

Why /boot/loader.conf but NOT /etc/sysctl.conf is to avoid race conditions.
If loading nvidia.ko and nvidia-drm.ko happenes earlier than setting the tunable, these kmods cannot pick the tunable on load, thus, tunables but not sysctls.

And more, you'll want emulators/libc6-shim, devel/libepoll-shim and science/linux-ai-ml-env for CUDA on FreeBSD to run easier.

#FreeBSD #NVIDIA #CUDA

Fried my boot loader trying to update it.

#FreeBSD has decades of archives on boot loader updating, which means that searches are full of noise. "gpart bootcode" is not a thing today. Possibly complicated further because this was installed as 14.0 and upgraded to 15.0.

Reboot and got "missing boot loader"

Start over by hand:

gpart add -t efi -s 100M nda0

newfs_msdosfs -F 32 -c 1 /dev/nda0p1
attach to /mnt

mkdir -p /mnt/EFI/BOOT
cp /boot/gptboot.efi /mnt/EFI/BOOT/BOOTX64.efi

Reboot and again: "missing boot loader"

Anyone know the current incantation?

@mwl

Hmm, looks like loader.efi(8) doesn't contain much help.

I think you have to set an efi var because FreeBSD puts its loader in a non-standard location. I'll dry to dig up more info since I remember having to deal with this a few years ago.

#FreeBSD

How to force reboot a frozen Linux or FreeBSD machine

https://it-notes.dragas.net/2023/01/08/how-to-force-reboot-a-frozen-linux-or-freebsd-servers/

I've just used this...

#Linux #FreeBSD

Anybody use an #eGPU with #FreeBSD ? Information on it seems scant.

One of the few #sysadmin things that worries me any more is updating boot code after a zpool upgrade. #FreeBSD

I'm sure it'll be fine, but if I disappear forever you know what happened.

Announcing #BSDCan 2026 Travel Grants

Deadline: Friday the 19th!

To encourage and enable more first-time and returning attendees at BSDCan 2026, this year’s travel grant is a free room for up to five nights in a shared-bathroom private suite at the 90U residences.

Full details:

https://blog.bsdcan.org/2026/05/14/announcing-bsdcan-2026-travel-grants

#FreeBSD #NetBSD #OpenBSD

Announcing FediMeteo – Weather in the Fediverse!

UPDATE: I have created an account for updates and other information on FediMeteo - follow the account @admin to stay updated!

UPDATE: Ireland, Poland, Portugal and Switzerland have just been added

Weather has always influenced our lives: from agriculture to outdoor activities, to extreme events that, thanks to modern technology, can now be predicted with greater reliability. Personally, weather plays a significant role in my daily decisions, which is why I decided to create a service tailored for the Fediverse.

FediMeteo uses Open-Meteo data to publish updates every 6 hours, including current weather conditions, forecasts for the next 12 hours, and predictions for the upcoming days. Each country is served by its own dedicated instance (e.g., it.fedimeteo.com for Italy), managed through snac to ensure simplicity and efficiency in publishing.

You can follow FediMeteo directly in the Fediverse (on Mastodon and compatible platforms), via RSS, or by visiting the dedicated page for your city (e.g., fr.fedimeteo.com/paris).

Currently supported countries include:
Austria, Germany, France, Ireland, Italy, Netherlands, Poland, Portugal, Spain, Switzerland and the United Kingdom, – with many more regions coming soon!

FediMeteo is hosted on a FreeBSD-based VPS, with each country isolated in its own jail to ensure security and scalability.

Visit the main site to explore the national instances and start following your local weather updates today:
https://fedimeteo.com

Happy weather monitoring to all! 🌦️

FediMeteo is dedicated to my grandfather, who every evening would give me the weather forecast based on TV, radio, and his personal experience. He would convince me that the weather would be bad, so he had an excuse to accompany me to school instead of me going alone.

#FediMeteo #Announcements #FreeBSD #FediMeteo #WeatherForecasts #Weather #Meteo #snac #Fediverse #Mastodon

Achievement Unlocked!

With the help of the graciously-loaned Ampere system, I have completed a #FreeBSD 15.1-BETA2 Build Option Survey BEFORE the next pre-release landed! It CAN be done!

https://callfortesting.org/15.1-BETA2/

#LikeABOS*

* Sorry, I don’t have many B.O.S. jokes or puns but maybe @gumnos can loan some cycles.

TIL #FreeBSD does not support GPU device on #arm64. At least, not on my #ROCKPro64 card. Unless the web pages I found are wrong.

That just impacts transcoding here so no big deal. But it might be a bit more troublesome for ones who wanted to build a desktop out of it.

But... it has Linux emulation support.
Which means I can drop penguins farts in ARM jails.

New #blog #post: Package Manager Tier List

https://rldane.space/package-manager-tier-list.html

1521 words

Note: this is a very off-the-cuff tier list, using speed as the main qualifier, but the article explains exceptions to that as it goes on.

cc: my wonderful #chorus: @joel @dm @sotolf @thedoctor @pixx @orbitalmartian @adamsdesk @krafter @roguefoam @clayton @giantspacesquid @Twizzay @stfn

(I will happily add/remove you from the chorus upon request! :)

#rlDaneWriting #blost #DeadLikeMe #Linux #BSD #RunBSD #FreeBSD #OpenBSD #NetBSD #Debian #Arch #pacman #AUR #Fedora #homebrew #flatpak #snap #OpenSuSE #RPM

Great #podman lecture. Wish this would have existed while I was exploring #Docker containers on #FreeBSD. At least, it seems I did understood the thingy properly.

https://blog.hofstede.it/podman-on-freebsd-oci-containers-without-systemd/

hum…

May 12 03:00:48 freebsd kernel: pid 13188 (rsync), jid 0, uid 0, was killed: failed to reclaim memory

you mean 4GB of RAM is not enough to transfer a couple of TB from #ZFS to ZFS using rsync on #FreeBSD?

I am used to "raise your openfiles limit", not "no NAS server with less than 32GB RAM thank you"… 🤷‍♂️

#AdminFail

The difference is quite huge under heavy transfer load… rsync runs on "yellow" Intel machine and rsyncs data from it’s local storage to the remote "blue" arm64 one. Not sure if that explains the power usage difference 🤔 #arm #FreeBSD

Alt...

Two power consumption graphs while transferring data from one server to the other.

This shows a power consumption difference while transferring (at 500Mbps-1Gbps using rsync/ssh) data from a WD 16TB with Intel N150 to a WD 16TB with ARM Cortex-A53. And makes me confident migrating to #arm is a good idea - power consumption wise. Both run #FreeBSD 14 BTW.

Alt...

Two graphs showing power consumption.

It seems FreeBSD didn't want to get left out of the latest local privilege escalation trend. A buffer overflow in execve handling.

https://www.freebsd.org/security/advisories/FreeBSD-SA-26:13.exec.asc

#FreeBSD

https://aisle.com/blog/aisle-discovers-cve-2026-42511-a-21-year-old-freebsd-remote-command-execution-vulnerability

converted my #FreeBSD hosts to pkgbase, including some tiny VMs with 20GB disks. Why is are these disks full?

Well, /var/db/freebsd-update was ~7GB. #sysadmin

(Yes, most of my critical hosts are VMs on rented hardware, but these are offsite DNS and remote test nodes.)

I'm thinking of re-installing FreeBSD on my Thinkpad T480s (Intel iGPU) and exploring Sway as my Wayland compositor. What is the state of Wayland support in FreeBSD?

#AskFedi #FreeBSD #Wayland #Sway

Does anybody know what happened to the `ungoogled-chromium` package on #FreeBSD? I know I had installed it at one point, but it doesn't appear to be available any more:

$ pkg search ungoogled || echo not found
not found

The #eurobsdcon 2026 Call for Papers is still open!

https://2026.eurobsdcon.org/cfp/

Submit by June 20th, come to Brussels September 9-13 and mingle with #BSD people!

We also offer pre-submission guidance/mentoring, see the CFP text.

Wonder what BSD and the conferences are about? See https://nxdomain.no/~peter/what_is_bsd_come_to_a_conference_to_find_out.html

@EuroBSDCon #freebsd #netbsd #openbsd #freesoftware #libresoftware #brussels #bruxelles

Decided to upgrade my #FreeBSD installation on the desktop PC this weekend, especially after pkg was having issues pulling from the latest tree last weekend. Aside from upgrading base to 15.0-RELEASE-p8, I was finally able to upgrade all of my packages with pkg since then. ​​

#BSD #RunBSD

Alt...

My TV that I'm using as a monitor which is connected to my desktop PC. The PC is booted to FreeBSD and on the screen is a Tmux session with pkg finally installing all of the package updates that were pending since I experienced issues with the mirror a week ago.

Have any other #FreeBSD users recently started having trouble with #Chromium opening a window but then just hanging?

X thinks it has a window since other things continue painting just fine around its target rectangle, but any windows moved over it just leave un-cleared artifacts and the window doesn't respond to interactions AFAICT.

Looking at the stderr there's a lot of "can't connect to dbus" (though `service` shows it's running) and several instances of:

[49959:66588103999496:0502/114932.516666:ERROR:chrome/browser/ui/webui/ntp/new_tab_ui.cc:53] Requested load of chrome://newtab/ for incorrect profile type.

On #OpenBSD, the update process every six months is:

# sysupgrade
# sysmerge

And as needed:

# syspatch
# pkg_add -u

What are these processes for #FreeBSD?

The #eurobsdcon 2026 Call for Papers is still open!

https://2026.eurobsdcon.org/cfp/

Submit by June 20th, come to Brussels September 9-13 and mingle with #BSD people!

We also offer pre-submission guidance/mentoring, see within.

Wonder what BSD and the conferences are about? See https://nxdomain.no/~peter/what_is_bsd_come_to_a_conference_to_find_out.html

@EuroBSDCon #freebsd #netbsd #openbsd #freesoftware #libresoftware #brussels #bruxelles

I just installed the previous version of py311-bcrypt version 4.3.0 and I was able to restart radicale again.

Oh great just updated my #FreeBSD Bastille jails and my radicale now fails to start with the following errors.

[2026-04-30 18:52:44 +0100] [12116] [INFO] Logging of backtrace is disabled in this loglevel
[2026-04-30 18:52:44 +0100] [12116] [INFO] Loaded default config
[2026-04-30 18:52:44 +0100] [12116] [INFO] Loaded config file '/usr/local/etc/radicale/config'
[2026-04-30 18:52:44 +0100] [12116] [INFO] Skipped missing/unreadable config file '/root/.config/radicale/config'
[2026-04-30 18:52:44 +0100] [12116] [INFO] Starting Radicale (python=3.11.15 radicale=3.6.1 vobject=0.9.6.1 passlib=1.7.4 defusedxml=0.7.1 bcrypt=5.0.0 argon2-cffi=25.1.0 pika=1.3.2 ldap=n/a ldap3=2.9.1 pam=n/a) as user=root(0) groups=wheel(0),wheel(0),operator(5) on FreeBSD-15.0-RELEASE-amd64-64bit-ELF
[2026-04-30 18:52:44 +0100] [12116] [INFO] auth type is 'radicale.auth.htpasswd'
[2026-04-30 18:52:44 +0100] [12116] [INFO] auth.strip_domain: False
[2026-04-30 18:52:44 +0100] [12116] [INFO] auth.lc_username: False
[2026-04-30 18:52:44 +0100] [12116] [INFO] auth.uc_username: False
[2026-04-30 18:52:44 +0100] [12116] [INFO] auth.urldecode_username: False
[2026-04-30 18:52:44 +0100] [12116] [INFO] auth.delay: 1.000000 seconds
[2026-04-30 18:52:44 +0100] [12116] [INFO] auth.cache_logins: False
[2026-04-30 18:52:44 +0100] [12116] [INFO] auth htpasswd file: '/usr/local/etc/radicale/users'
[2026-04-30 18:52:44 +0100] [12116] [INFO] auth htpasswd file encoding: 'utf-8'
[2026-04-30 18:52:44 +0100] [12116] [INFO] auth htpasswd cache: False
[2026-04-30 18:52:44 +0100] [12116] [INFO] auth htpasswd encryption is 'radicale.auth.htpasswd_encryption.bcrypt'
[2026-04-30 18:52:44 +0100] [12116] [INFO] Read content of htpasswd file start: '/usr/local/etc/radicale/users'
[2026-04-30 18:52:44 +0100] [12116] [INFO] Read content of htpasswd file done: '/usr/local/etc/radicale/users' (entries: 1, duplicates: 0, errors: 0)
[2026-04-30 18:52:44 +0100] [12116] [WARNING] bcrypt module version '5.0.0' >= '5.0.0' and passlib(libpass) module version '1.7.4' < '1.9.3' found => incompatible, downgrade bcrypt or upgrade passlib(libpass)
[2026-04-30 18:52:44 +0100] [12116] [CRITICAL] An exception occurred during server startup: The htpasswd encryption method 'bcrypt' requires the bcrypt module but not usuable

I'm running on the latest 15.0-RELEASE-p7
Anyone ??

@a @celesteh expect FreeBSD Installer for 15.1 to offer KDE Plasma and applications, and X.Org.

<https://www.freebsd.org/releases/15.1R/>

#FreeBSD #KDE #Plasma #desktop

@projectanchorage I would look at multiple options.
- If you're strictly stuck with i386 (not even i486) that means #NetBSD is propably the only choice.
- Depending on your goals, you may want to consider #OpenBSD or #386BSD (today's #FreeBSD).
- Not shure if #OpenSolaris / #illumos supported anything beyond #SPARC(v9 / SPARC64) & #amd64.

The question to me is whether or not old #BSD versions emcan even be built with midern toolchains and if choosing them isn't going to bite one in the ass down the line.
- The reason I choose #Linux for @OS1337 is because it's mature toolchain, drivers and hardware support.
- Tho you may rightfully argue that #OS1337 is just taking the #toybox / #musl + linux "distro" #mkroot and basically tries to make something out of it.

The #eurobsdcon 2026 Call for Papers is open through June 20th!

https://2026.eurobsdcon.org/cfp/

Submit by June 20th, come to Brussels September 9-13 and mingle with #BSD people!

We also offer pre-submission guidance/mentoring, see within.

Wonder what BSD and the conferences are about? See https://nxdomain.no/~peter/what_is_bsd_come_to_a_conference_to_find_out.html

@EuroBSDCon #freebsd #netbsd #openbsd #freesoftware #libresoftware #brussels #bruxelles

The main #PeerTube dev, Chocobozzz, is the GOAT. Always quick to respond, get stuff fixed fast. The last issues we've had on Exquisite.tube directly resulted into documentation improvements:

https://github.com/Chocobozzz/PeerTube/commit/bbb8e6ac4eaadf88bcd9c6b65f727571655dad8d

(we are actually running #HardenedBSD - but this applies to #FreeBSD too)

@tfb @jrsharp
#FreeBSD had proceeded some parts of "abstraction" in this several decades.
For example, separation of buses (like ISA, PCI, USB, ...) and devices connected to any of the buses called "newbus" when it was introduced, GEOM for disks, NETGRAPH for networks. But the appoaches would be different with #NetBSD.
Putting newbus (current implementation) aside, others were for "flexibilities" over "abstraction for compatibilities".

My understanding in difference between aproaches of FreeBSD and of NetBSD would be...
FreeBSD: Make it work and stable, fast for running platform in production first. Then, consider making it portable.

NetBSD: Make it elegant and portable by separating machine independent (MI) parts and machine dependent (MD) parts. Then, making it stable would be easier to achieve. So the next would be performance tunings.

Link to document about newbus (already not "new" bus but "current" bus, though):
https://docs.freebsd.org/en/books/arch-handbook/newbus/

thyme

#openbsd #freebsd #runbsd #foss #comic

Alt...

fish and daemon examine old photos

That would be crazy if someone imported tmux, doas, tmux, and openrsync into #FreeBSD base. Like , crazy.

This morning I decided to update my Raspberry Pi 4 to the latest patch of FreeBSD 15.0-RELEASE. It's a UFS setup, running in read-only mode, as I mentioned in a previous post: https://it-notes.dragas.net/2024/05/31/freebsd-tips-and-tricks-native-ro-rootfs/

I remounted it in rw, rebooted, and started the process... halfway through, a power surge hit and everything shut down.

TIL: UFS is quite resilient to these situations, even on an SD card, and even during a freebsd-update.

#FreeBSD #RunBSD

The BSDCan 2026 schedule has been posted. 30 regular talks, one set of lightning talks, and one Audio BoF: https://www.bsdcan.org/2026/timetable/timetable-all.html

Both FreeBSD and NetBSD will be holding two day Dev Summits across the hall from each other in DMS.
https://wiki.freebsd.org/DevSummit/202606
https://www.netbsd.org/gallery/events.html#bsdcan2026

Just like last year, the reception on Saturday night is free if you register early. This year you must register before May 1, 2026: https://www.bsdcan.org/2026/registration.html
#bsdcan @bsdcan #freebsd #openbsd #netbsd #conference #ottawa