Hi all,

Random thought

Anyone remember IRIX? The company that ran it is defunct. Was the code ever released? If not, what's the harm in releasing it at this point? Where could one even get it at this point?

I doubtful there is anything useful that could be ported in the code, but you never know!

Hey everyone,

Just got miniDLNA running stable on OpenBSD 7.8 after quite a battle. Sharing my findings in case others hit the same issues.

The Problem

rcctl start minidlna reports ok but immediately rcctl check minidlna returns failed. The service never creates a PID file and dies silently. This seems to be a known issue with the rc script on OpenBSD 7.8 — possibly related to the unveil/pledge restrictions in the package.

Root Causes Found

rcctl broken — minidlna's rc script doesn't work reliably on 7.8

unveil restrictions — media paths outside /var/db/minidlna are blocked when running as daemon

Don't use -d flag — it prevents self-daemonization and causes instability

Corrupt/incomplete media files — minidlna crashes scanning bad metadata

Working Solution

Create symlinks so media paths are within unveil scope:

ln -sf /data/media/videos /var/db/minidlna/videos

ln -sf /data/media/music /var/db/minidlna/music

ln -sf /data/media/photos /var/db/minidlna/photos

media_dir=V,/var/db/minidlna/videos

media_dir=A,/var/db/minidlna/music

media_dir=P,/var/db/minidlna/photos

friendly_name=MyServer

db_dir=/var/db/minidlna

log_dir=/var/log

port=8200

inotify=no

notify_interval=60

/etc/login.conf — increase openfiles limit:

minidlna:\

:openfiles=4096:\\

:tc=daemon:

cap_mkdb /etc/login.conf

/etc/rc.conf.local:

minidlna_class=minidlna

/etc/rc.local — bypass rcctl entirely:

#!/bin/sh

mkdir -p /var/run/minidlna

chown _minidlna:_minidlna /var/run/minidlna

/usr/local/sbin/minidlnad \

-f /etc/minidlna.conf \

-P /var/run/minidlna/minidlna.pid \

-u _minidlna

Key insight: Without -d, minidlna self-daemonizes with PPID=1 — stable and boot-persistent. With -d it stays in foreground and dies when the shell exits.

Verify it's running correctly:

ps -p $(pgrep minidlnad | head -1) -o pid,ppid,command

# PPID should be 1

Hope this saves someone the hours I spent on it!

OpenBSD 7.8 · miniDLNA 1.3.3

I am currently investigating a possible switch from GNU/Linux to FreeBSD/GhostBSD. I have used GNU/Linux for the past 20+ years.

I have read parts of the FreeBSD handbook and was positively surprised by its clarity and that its content is not particularly difficult to understand. At the same time I am well aware that FreeBSD and GNU/Linux differ in many respects and that I will need to learn new things. I plan to begin my evaluation of FreeBSD/GhostBSD in a virtual machine.

My hardware is fairly common — 5600G; B550; NVMe SSD — and it should reasonably work on FreeBSD without problems. If anyone has a different view I am very interested in hearing about your experience.

I use my PC for web browsing with Firefox, word processing with LibreOffice, OS testing with Virt‑manager, and a fair amount of multimedia consumption, both local files and online content.

My limited knowledge and experience of FreeBSD/GhostBSD makes me doubtful that they will be able to meet all of my needs. What I am most unsure about is support for various multimedia formats/codecs and hardware/GPU acceleration for both local files and online content.

I would be very grateful for any input from FreeBSD and/or GhostBSD users.

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:

═══════════════════════════ ON HARDWARE ══════════════════════════════

ThinkPad T480 isn't magic — it's just unusually well-documented in FreeBSD-land. The wiki tells you which kernel modules to load for the trackpoint, which acpi_video tweaks fix backlight, exactly which iwm/iwn driver matches your wifi card. That isn't true for random laptops. Save yourself a year: pick hardware the community has already debugged.

Corollary: a "spare disk" is not enough. Spare TWO disks. One for the OS, one for your /home and data — the classic configuration. ZFS makes this trivial to set up and disaster-proof. When (not if) you brick the OS partition trying something experimental, you reinstall and your data is still there. Took me three re-installs to internalize this.

Actually, I prefer managing one pair of disks for Linux and another pair for FreeBSD — kept entirely separate. No dual-boot tears, no GRUB rescue at 2am, no shared partitions to corrupt. Two systems, four disks, full isolation.

════════════════════════ ON DESKTOP ENVIRONMENTS ═══════════════════════

I cycled through Xfce, KDE, GNOME, i3, Hyprland (briefly), and landed back on MATE. The cycle wasn't wasted — it taught me what I actually need vs what looked cool on r/unixporn. MATE is boring, stable, lightweight, and doesn't fight FreeBSD's input stack.

Bonus learning: don't install Wayland compositors on FreeBSD before they're production-ready. X11 + a sensible compositor (or no compositor) outperforms experimental Wayland on this OS today. Maybe in two more releases.

══════════════════════ ON COEXISTING WITH LINUX ══════════════════════════

Running both daily isn't a war. It's two different tools for two different mental modes:

1. Linux when I need bleeding-edge: latest kernel, GPU compute workloads, anything that requires NVIDIA proprietary stack, Steam, things that touch hardware that landed in mainline last month.
2. FreeBSD when I need to think clearly: writing, code review, network experiments, anything where I want the OS to disappear and let me work.

The mental shift isn't a downgrade. It's a context switch. Two hats, two desks.

══════════════════ ON ZFS — THE THING I UNDERRATED ════════════════════════

ZFS boot environments saved me probably 40 hours of reinstall pain over the years.

\bectl create before-experiment``

then break stuff freely.

\bectl activate``

rolled back, reboot, done.

No Linux distro gives me this out of the box with the same simplicity (yes, btrfs exists, yes, NixOS exists, neither feels the same).

If you're starting FreeBSD: learn boot environments in your first week. Not month. Week.

════════════════════════ ON THE COMMUNITY ═════════════════════════════

All FreeBSD-forums and r/freebsd are friendly compared to Linux equivalents. Smaller userbase, higher signal-to-noise. Ask a specific question, you get a specific answer, usually from someone who has shipped production systems.

But: don't ask "should I use FreeBSD". Ask "what are the trade-offs for my specific workload". The former question gets you religion. The latter gets you engineering.

═════════════════════ QUESTION FOR THIS SUB ═════════════════════════════

What's the one thing YOU wish someone had told you in your first year on FreeBSD?

I suspect we'll generate a better FAQ in this thread than the wiki currently has.

Why the FreeBSD/UNIX model is architecturally superior — said by someone who loves Linux#

A companion piece to my earlier post on the Cathedral and the Bazaar. That essay made peace with both systems. This one takes a side — and tries to do it without lying.

I run Linux every day. Professionally, daily, by choice. I am not writing this as an outsider. I am writing it as someone who has paid the cost of both architectures with my own time and watched, over years, how the costs distribute differently across the two systems.

The bazaar wins on adoption. On hardware breadth. On velocity. None of that is up for debate.

But on the questions that matter once a system is in production — architectural coherence, security model, predictability under failure — the FreeBSD/UNIX model is better. Not by a small margin. By a structural one.

Here is why.

1. Kernel and userland are one designed system, not two negotiated systems#

This is the foundational difference, and almost everything else follows from it.

In FreeBSD, the kernel, the C library, the init system, the shell, the network stack, the file utilities, and the configuration files are all developed by the same team, in the same source tree, under the same review process. When the kernel changes how a syscall behaves, the userland that depends on that syscall is updated in the same commit window. The interface contract has one author.

In Linux, the kernel is one project. glibc is another. systemd is another. The init scripts, the networking tools, the package manager — each comes from somewhere else, each has its own release cadence, its own maintainers, its own opinion about how things should work. The distribution is the negotiation layer that tries to make them coexist.

This is not a moral failing of Linux. It is a structural consequence of the bazaar model. But it has real costs:

• A vulnerability in glibc affects every Linux system but is not the kernel team's problem
• A change in systemd behavior breaks software that was written against init scripts, and the kernel team has no opinion
• Two distributions can ship the same kernel and behave entirely differently because the userland was assembled from different sources

In FreeBSD, when something breaks, there is one source tree, one maintainer team, one bug to file. The blast radius of any change is auditable. In Linux, the same investigation crosses three to five project boundaries before you find the actual decision-maker.

2. The security model is part of the architecture, not an afterthought#

Linux security is a stack of bolt-ons. SELinux came from the NSA and was retrofitted. AppArmor came from Immunix and was retrofitted differently. Namespaces, cgroups, seccomp — each a separate mechanism, each developed in response to a different pressure, each with its own configuration model.

This is powerful. It is also exhausting. To secure a Linux container properly, you compose four or five orthogonal mechanisms and hope their interactions don't surprise you. Most production Linux deployments don't actually do this correctly. They turn on Docker and call it done.

FreeBSD's security model was designed, not accumulated:

• Jails (2000) — process and filesystem isolation, designed into the kernel, not bolted onto namespaces twenty years later
• Capsicum — capability-based sandboxing at the syscall level, integrated with the kernel's permission model
• MAC framework — mandatory access control as a first-class kernel subsystem, not an LSM module fighting for hooks
• Security event auditing — built in, configured once, present on every FreeBSD system

The point is not that these mechanisms are individually stronger than their Linux counterparts. The point is that they were designed to fit together. The cathedral could make architectural decisions about how isolation, capability, and audit should interact. The bazaar cannot, because there is no single party with the authority to design across project boundaries.

3. The base system is auditable. The distribution is not.#

If I want to know exactly what is running on a FreeBSD machine, I read the base system source. It is one tree. The behavior of every system utility, every kernel subsystem, every configuration default — it is all in one place, version-controlled together, released together.

If I want to know what is running on a Linux machine, I have to know which distribution, which kernel version, which glibc, which init system, which package manager, which patches the distribution maintainer chose to apply downstream of upstream, and which configuration defaults the distribution shipped. This information is scattered across a dozen repositories maintained by a dozen teams.

Auditability is a security property. A system whose total behavior you cannot fully describe is a system whose attack surface you cannot fully measure.

4. Stable interfaces are a security feature#

Linux's binary interface to userland is famously stable — Linus's "we do not break userspace" rule is rightly celebrated. But that stability is enforced at the kernel boundary only. Above the kernel, the distribution layer breaks userspace constantly. Init systems change. Networking tools change. Configuration formats change. Software written against one Ubuntu LTS often does not run cleanly on the next.

FreeBSD's stability extends through the whole system. /etc/rc.conf works the way it worked twenty years ago. The networking configuration syntax is the same. The jail interface evolves additively. A FreeBSD admin who learned the system in 2005 can sit down at a FreeBSD 15 box and work productively in ten minutes.

This stability is not nostalgia. It is what makes long-term security maintenance possible. Systems that change their administrative interface every release accumulate misconfigurations as a normal consequence of upgrades. Systems that hold their interface stable do not.

5. ZFS is the proof of the model#

ZFS exists on Linux. It works. But it is not part of the system — it is a module, maintained by a separate project, with its own release cycle, fighting an ongoing license incompatibility that means it can never ship in the mainline kernel.

On FreeBSD, ZFS is a first-class citizen. The boot loader knows about it. The installer treats it as the default. Jails integrate with it natively. Boot environments work because the system was designed around the assumption that ZFS would be the foundation.

This is what the cathedral model enables that the bazaar model structurally cannot: an architectural decision can be made, propagated through the whole system, and become part of the system's identity. The bazaar can adopt a technology, but it cannot integrate it the same way, because there is no single integrator.

What this is not#

This is not an argument that Linux is bad. Linux is extraordinary. The fact that the bazaar produced a system that runs most of the planet's computing infrastructure is one of the great engineering achievements of the last forty years.

This is not an argument that you should switch. If your workload needs the latest hardware, the latest kernel features, the GPU stack of the moment — Linux is the correct answer and FreeBSD will frustrate you.

This is an argument that the architectural model — kernel and userland co-developed, security designed in, base system auditable as a single artifact, interface stability extending through the whole stack — is the better foundation for systems that need to be understood, secured, and maintained over long periods.

The bazaar wins the market. The cathedral wins the audit.

If you are building infrastructure that has to survive a decade of staff turnover, threat-model evolution, and version drift, the question is not which system is more popular. The question is which system you can still reason about in year nine.

The honest closing#

I run Linux because the market runs on Linux, and I am paid to operate where the market is. I run FreeBSD because at the end of the day, when I want to sit down and think clearly about a system, I want the system to have been designed by people who could see each other's work.

Both things are true. Both systems deserve respect.

But if you ask me which model I would build my own infrastructure on for the next thirty years — the answer is the cathedral. Not because the bazaar failed. Because the cathedral was built for this question, and the bazaar was built for a different one.

The Cathedral, the Bazaar, and the Two Systems on My Desk#

Eric S. Raymond wrote The Cathedral and the Bazaar in 1997 observing Linux — and used it to argue that the bazaar wins. Thousands of contributors, patches raining from everywhere, releases fast and chaotic, the whole thing held together by Linus's dictatorship of taste. Raymond was right about Linux. What he didn't fully explore is what happens when you put a cathedral next to the bazaar and use both of them every day.

That thought drives me to Istanbul — Κωνσταντινούπολη, the Second Rome. Stand in front of Agia Sophia (Αγία Σοφία): ancient, magnificent, a structure with foundations laid fifteen centuries ago, the largest solid one-piece dome ever built, still standing. Walk ten minutes and you are inside the Grand Bazaar — chaotic, alive, ten thousand merchants, no single architect, no single plan. Both are extraordinary. Both have survived. They are not competing. They are neighbors.

I do exactly that. Linux at work. FreeBSD on my personal ThinkPads. Two operating systems, two mental models, same pair of hands — every day.

And the longer I run both, the more I think ESR's framing needs a sequel.

The original argument#

Raymond's cathedral was proprietary software: small teams, long release cycles, source code hidden behind walls. The bazaar was Linux: open, chaotic, self-organizing, surprisingly coherent. His thesis was that given enough eyeballs, all bugs are shallow — and that the bazaar's apparent disorder produced better software than the cathedral's controlled perfection.

He was largely right. Linux won the server, the phone, the cloud. The bazaar scaled.

But here is what 1997 Raymond couldn't see from where he was standing: there is more than one kind of cathedral.

FreeBSD is a cathedral. But not that kind.#

FreeBSD is not proprietary. It is not closed. But it is unambiguously a cathedral in Raymond's structural sense: a unified base system developed by a core team with a coherent architectural vision, kernel and userland shipped as a single designed artifact, release cycles measured and deliberate.

The ports tree is the bazaar. Twenty thousand packages, community-maintained, chaotic in the good way. But the foundation underneath it — the cathedral — is not.

Linux is the opposite arrangement. The kernel is Linus's cathedral (benevolent dictatorship with strict taste). But the distributions? Debian, Arch, Fedora, NixOS, a thousand others? Pure bazaar. Everyone building their own floor plan on the same foundation. The result is an ecosystem of extraordinary breadth and an equally extraordinary inconsistency.

Neither arrangement is wrong. They optimize for different things.

What the bazaar gives you#

Speed. Reach. Adoption. If a new filesystem lands in the Linux kernel this month, someone has already packaged it for Arch by next week. GPU compute, bleeding-edge drivers, hardware that shipped yesterday — the bazaar gets there first because it has more people running in more directions simultaneously.

This is why Linux runs the cloud. Not because it is architecturally superior. Because the bazaar is the right model for capturing a fast-moving, heterogeneous market at scale.

I use Linux for exactly this: anything that requires the latest kernel, GPU workloads, NVIDIA's proprietary stack, Steam. The bazaar serves me well there.

What the cathedral gives you#

Coherence. Auditability. The confidence that comes from knowing the system was designed, not assembled.

When I read the FreeBSD source, I am reading a work with a consistent voice. The networking stack, the VM subsystem, the jail framework — they fit together because they were built by people who could see each other's work, argue about interfaces, and maintain a shared vision of what the system should be.

ZFS is the most obvious example. On FreeBSD, ZFS is not a bolt-on. It integrates with the boot loader, with jails, with the network stack's trust model. It behaves like a first-class citizen because the cathedral can make architectural decisions that span the whole building.

I use FreeBSD for the mental mode that requires the OS to disappear. Writing, code review, network experiments, infrastructure that needs to run for years without surprises. When I need to think clearly, I sit down at the cathedral.

The thing Raymond missed#

His framing set up cathedral vs. bazaar as a competition. Proprietary vs. open. Closed vs. free. In 1997, that was the right fight to have.

But the fight I have every day is different: which tool for which job?

Running both is not cognitive dissonance. It is the same instinct that makes a craftsman keep different tools for different materials. You do not use the same plane on hardwood and softwood. You do not resent the softwood plane for not being the hardwood plane.

Linux and FreeBSD are not enemies. They are the bazaar and the cathedral coexisting on my desk, each doing what it does best, each occasionally teaching me something about the other.

Just like Istanbul.

The question for this community#

Raymond's essay ended with a set of lessons distilled from watching the bazaar work. Twenty-eight years later, I think there is a companion essay waiting to be written — not against the bazaar, but about the cathedral's enduring value in a world the bazaar now largely runs.

What has FreeBSD taught you that Linux couldn't? Not in a tribal sense. In an engineering sense.

I suspect the answers to that question would make a better case for FreeBSD than any benchmark.

In case you haven't been paying attention. Last week, two new Linux LPE vulnerabilities were discovered and leaked. One only works on machines without AppArmor, the other works on all machines. And this is AFTER the "Copy Fail" vulnerability that came before.

The root cause of these vulnerabilities all seem to be the same: corrupt a cached suid file in memory and execute it. But I think the cause is deeper. All of these vulnerabilities exploit some kind of kernel system for in-place cryptography.

In place cryptography may save a couple of memory transfers, but it comes at a cost of much greater complexity, since now the kernel has to make sure that all user-passed pointers are valid and should be allowed to be written to. And the Linux kernel has failed to handle such complexity in at least three separate cases.

OpenBSD had it right. If you want a secure operating system, you have to sacrifice some micro-optimizations and features for the sake of much reduced complexity. And reduced complexity is the only way to have a truly secure operating system.

NetBSD 11.0 RC 4 is out. I upgraded this morning and so far no issues!

https://blog.netbsd.org/tnf/entry/netbsd_11_0_rc4_available