Why I Prefer FreeBSD on All of My Machines

⚠️ Authors note: This is an opinion article. It describes my personal experience and preference. Anyone can use which ever operating system they like and think of fitting them best (though I strongly oppose that any system should be required or called a de-facto standard, I hope we have left those times behind and have learned something from it). Whenever I am free to choose, I will almost always choose FreeBSD. And when I am not free to choose I will use it anyway.

Whenever I mention that I use FreeBSD, people usually assume that I am talking about a server, a storage appliance, a router or perhaps some other infrastructure system hidden in a rack. Using FreeBSD on a workstation with a graphical user interface already appears unusual to many people, and using it on an embedded system such as a Raspberry Pi somehow seems almost incomprehensible. I have never really understood this categorization. A workstation, a server and a Raspberry Pi are all computers. They differ in their available resources, peripherals and workloads, but there is no reason why this should automatically require three completely different administrative environments.

In fact, one of the greatest advantages of using FreeBSD is precisely that the same operating system can be used on all of them. The configuration files are in the same locations, services are managed in the same way, network interfaces are configured using the same tools, system parameters are adjusted using the same mechanisms, and the same package-management and build infrastructure is available. When I move from my workstation to a server through SSH, or from a server to an embedded controller through a serial console, I do not have to switch mental models. I do not have to remember which generation of network-management framework happens to be used on this machine, where this distribution stores its service configuration, which package manager is responsible for a particular file or whether a certain command happens to be the GNU, BusyBox or some distribution-specific implementation.

This uniformity is extremely convenient and, in my opinion, often underestimated. Knowledge gained while debugging a workstation is directly useful when repairing a server. A script written to configure an amd64 machine can often be used almost unchanged on an AArch64 board. The same commands, directory structures and conventions occur everywhere. Instead of learning separate operating systems for desktop computers, servers and embedded devices, I can concentrate on the differences which actually matter: the hardware and the application.

There are naturally exceptions. Sometimes a device is not supported well enough, a proprietary application requires another operating system or a vendor supplies an essential driver only for Linux or Windows (though reverse engineering capabilities of modern LLMs even solve this pretty well). Some Raspberry Pi systems currently run Raspberry Pi OS because I need uniform hardware support across several Pi generations. This is a pragmatic decision, not an ideological preference. Where the required hardware works, I would much rather use FreeBSD.

• A quiet system by default
• Consistency without freezing the system in time
• An integrated operating system
• Standards and predictable command-line tools
• Documentation and source-code quality
• Binary and source compatibility
• Foreign binaries and compatibility layers
• Jails and virtualization
• ZFS
• Networking
• A graphical workstation is still a Unix machine
• Embedded systems are computers too
• Hardware and GPU support
• The license
• No systemd
• Why I do not want Windows
• Mandatory access control and the optional superuser
  • The optional superuser
• The alleged software problem
• The operating system underneath the work
• References

A quiet system by default

One of the first characteristics I appreciate about FreeBSD becomes visible immediately after installation: it does not enable a large collection of remotely accessible or application-level services merely because somebody thought they might possibly be useful.

A newly installed FreeBSD system naturally runs the basic facilities required by an operating system. Device management, system logging, process scheduling and periodic maintenance do not disappear. The important point is that additional services generally remain disabled until the administrator explicitly enables them. SSH, NFS, RPC services, routing daemons and third-party applications do not spontaneously become active simply because their packages happen to be installed.

When I want an SSH server, I enable it:

sysrc sshd_enable="YES"
/etc/rc.d/sshd start

The decision is then visible in /etc/rc.conf. A third-party service installed through the package system usually provides an rc.d script below /usr/local/etc/rc.d, but it will still not be started until I enable it. The base system and additional software follow the same general administrative model.

This has consequences beyond saving a few megabytes of memory. When examining a machine, I can normally determine why every significant service is running. There should not be an indexing daemon, discovery service, synchronization client, telemetry component, cloud integration layer or update orchestrator which appeared because of a default selected by somebody else. A running process usually corresponds to an explicit administrative decision.

A quiet default installation also keeps the number of failure modes and the exposed attack surface small. A service which is not running cannot listen on a network socket, consume memory, write logs, wake up the processor or alter system state. This is especially valuable on embedded platforms and older computers, where resources should be spent on the actual purpose of the machine rather than on a growing collection of background components.

FreeBSD starts as a comparatively small and understandable system. Capabilities are added when they become necessary. This is a remarkably simple principle, but it is one which many modern operating systems appear to have abandoned.

Consistency without freezing the system in time

FreeBSD has existed since the early 1990s, and a current installation is obviously very different from one from that era. Hardware architectures have appeared and disappeared, storage systems have changed, new security mechanisms have been introduced, and entire classes of network and peripheral devices did not exist when the project began. Nevertheless, the basic administrative structure of the system remains recognizable.

Central system configuration is found below /etc. Local settings normally belong in /etc/rc.conf, while the supplied defaults remain separately in /etc/defaults/rc.conf. Boot-loader configuration belongs in /boot/loader.conf, runtime kernel parameters in /etc/sysctl.conf, and third-party application configuration normally in /usr/local/etc. Base-system startup scripts live below /etc/rc.d, while scripts installed by packages are placed below /usr/local/etc/rc.d.

This layout has survived for decades because it works. It is not necessary to replace it merely to make a new release appear modern. Improvements are introduced within the existing administrative model instead of invalidating it. The sysrc utility, for example, provides a convenient and safe interface for changing rc.conf, but it does not hide the resulting configuration inside an opaque database. The file can still be read and edited using an ordinary text editor.

As a result, old knowledge retains value. A FreeBSD administrator returning after many years will encounter a few new commands, new filesystems, new security facilities and new hardware, but the system will still be structurally familiar. Old documentation may contain obsolete details, but its description of the overall operating model often remains useful. Configuration experience accumulates instead of being discarded every time a new framework becomes fashionable.

This consistency becomes even more valuable when several classes of machines are involved. My workstation, servers, virtualization hosts and embedded systems do not need entirely different configuration-management approaches. The shell history and manual pages on one machine remain relevant on another. When I have understood how a particular subsystem behaves on my workstation, I can apply the same understanding to a remote server or a small ARM board.

Consistency is therefore not merely a pleasant property of an individual installation. It reduces the total cognitive complexity of an entire environment.

An integrated operating system

Another important distinction is that FreeBSD is developed as an integrated operating system. Its kernel, base userland, system libraries, boot loader, shell, fundamental utilities, service-management framework and documentation belong to the same project and are maintained in a common source tree.

Linux itself is a kernel. A usable Linux system combines that kernel with a C library, a userland, compiler tools, a startup system, package-management infrastructure and many other independently developed components. Linux distributions perform the considerable work of selecting and integrating those pieces, but they make different decisions. Even distributions which initially appear similar may use different network-management systems, firewall frameworks, package layouts, boot mechanisms and upgrade procedures.

FreeBSD’s integrated development model produces a more clearly defined base system. Third-party applications are deliberately kept separate through binary packages and the Ports Collection. Files below /usr/bin and /usr/sbin belong to the operating system, while additional programs are normally installed below /usr/local/bin and /usr/local/sbin. The same distinction exists between /etc and /usr/local/etc.

This separation makes upgrades, repairs and audits much easier. It is usually clear whether a file belongs to FreeBSD itself or to an installed application. The base system is not simply another collection of packages mixed together with browsers, databases and desktop programs. It can be rebuilt from /usr/src, upgraded as a coherent unit and compared against a known system distribution.

The integrated model does not eliminate bugs, nor does it mean that every component always evolves at exactly the same rate. It does, however, greatly reduce the number of accidental boundaries between independently assembled components. The kernel and userland are designed with one another in mind, and the documentation describes that particular combination rather than an abstract mixture which may behave differently on each distribution.

Standards and predictable command-line tools

I also appreciate the way FreeBSD approaches standards. This point requires some qualification because FreeBSD utilities are not identical to GNU utilities, and not every traditional Unix command has a completely standardized interface. Where no applicable specification exists, implementations naturally differ. A script which relies on a GNU-specific extension is not portable merely because several Linux distributions happen to ship the same GNU implementation.

Where standards do exist, however, FreeBSD generally treats them as contracts. POSIX-defined behaviour is taken seriously, and extensions tend to be identified as such. Manual pages frequently contain explicit STANDARDS, COMPATIBILITY and HISTORY sections. They explain whether a command follows POSIX, implements historical BSD behaviour or provides an additional FreeBSD-specific option.

This makes command-line tools far less surprising. When behaviour differs from another Unix implementation, it is usually possible to determine whether the difference results from a standard, a documented extension or historical compatibility. The system does not silently assume that whichever behaviour was implemented first has become a universal specification.

For software development, this distinction is valuable. I want to know whether a shell script uses a portable interface or depends on an implementation detail. I want system calls and utility options to have documented semantics, especially when they are used in automation which may survive for many years. Standards compliance does not guarantee the absence of bugs, but it provides a stable target and a shared vocabulary for discussing them.

Documentation and source-code quality

FreeBSD manual pages are part of the system rather than an optional accessory. User commands, system calls, configuration files, device drivers and many kernel interfaces are documented locally. It is entirely normal to use man 4 to understand a device driver or man 9 to inspect an internal kernel API.

man rc.conf
man loader.conf
man sysctl
man ifconfig
man jail
man 9 malloc

The locally installed manual pages correspond reasonably closely to the locally installed system. This means that solving a problem does not always begin with searching through forum discussions, videos or configuration examples written for some other release. The answer is often already installed on the machine.

The source tree follows a similarly consistent style. No codebase of this size is uniformly beautiful, and FreeBSD naturally contains old compatibility code and complicated subsystems. Nevertheless, naming, formatting, comments, error handling and subsystem organization usually follow recognizable conventions. Moving from one part of the system to another still feels like reading different parts of the same project.

This matters whenever the system has to be extended or debugged beyond ordinary administration. Device drivers, executable-image handlers, network protocols and kernel modules are not inaccessible vendor internals. They are inspectable parts of a system which is intended to be understood and modified. When something behaves unexpectedly, I can read the startup script, inspect the utility, follow the corresponding library call and, if necessary, examine the kernel implementation.

The interfaces themselves are also commonly designed with future extension in mind. Structure sizes, version fields, reserved members, compatibility handlers and extension pointers are used where appropriate so that new functionality does not automatically require every existing consumer to be broken. This cannot make every internal interface eternally stable, but it demonstrates that compatibility is considered during design rather than being left as an afterthought.

Binary and source compatibility

FreeBSD takes compatibility between kernel and userland seriously. This is partly a practical requirement of the upgrade process: during an in-place source upgrade, the new kernel initially has to run the old userland before the replacement userland can be installed.

The system therefore contains compatibility support for binaries built against older FreeBSD releases. This is not an unconditional promise that every arbitrary executable from every historical release will run forever. A sufficiently old program may require a library which no longer exists, depend on a removed device or rely on an undocumented interface. Nevertheless, when the necessary libraries are retained, old FreeBSD binaries often remain usable for an astonishingly long time.

Shared libraries are handled with a similar concern for ABI stability. Symbol versioning and compatibility implementations make it possible to improve interfaces without instantly invalidating all existing binaries. Kernel interfaces still evolve, particularly for out-of-tree modules, but those changes are generally documented and treated as changes which have a real cost.

The same attitude applies to source compatibility. An old program may need adaptation when standards, compilers or security requirements change, but the system does not casually rearrange fundamental interfaces merely to create activity. Existing software is regarded as something worth preserving.

This is particularly useful in scientific, industrial and embedded environments. Software may outlive the project which originally created it, and rebuilding it may not be trivial. Source code can be lost, development environments can disappear, or a proprietary vendor may no longer exist. Being able to continue executing an old binary is not nostalgia; it is an operational capability.

Foreign binaries and compatibility layers

FreeBSD’s compatibility architecture extends beyond old FreeBSD executables. The Linux binary compatibility layer allows many unmodified Linux binaries to run directly on supported FreeBSD systems. The kernel implements the relevant Linux ABI, while a Linux userland below /compat/linux supplies the expected libraries and filesystem content.

This is not the same as running a complete Linux virtual machine. There is no separate Linux kernel, and not every Linux-specific facility is reproduced. Applications which depend deeply on cgroups, namespaces, stuff like the /proc filesystem that is usually not existing on FreeBSD or particular kernel internals may not work. For ordinary user-space applications, however, the distinction can become nearly invisible. A Linux binary can be started from the shell like another executable and appears in the ordinary process table - often one just needs to patch a few /bin/bash lines to map correctly to /bin/sh or /usr/local/bin/bash and everything is up and running.

FreeBSD also provides mechanisms for associating foreign executable formats with interpreters. Through binmiscctl, for example, an executable for another architecture can automatically be passed to a QEMU user-mode emulator - for example allowing one to execute AArch64 binaries on the amd64 machine transparently. Windows executables can similarly be integrated through Wine. Build systems and users do not necessarily have to prepend the emulator command manually each time; the operating system can recognize the executable format and select the configured handler.

I find this approach architecturally elegant because compatibility is attached at the executable boundary. The calling process starts a program, and the system decides how that program has to be activated. Emulation and compatibility do not have to be reimplemented independently by every shell script and application.

This also reinforces the idea of using FreeBSD as the common operating environment. Linux or Windows software can be accommodated where necessary without turning the entire machine into a Linux or Windows installation.

Jails and virtualization

FreeBSD jails are another technology which existed before containers became fashionable. They were introduced with FreeBSD 4.0 in 2000, several years before LXC appeared and long before container orchestration became an industry of its own.

A jail extends the traditional chroot concept by isolating more than the filesystem hierarchy. Processes, users, hostnames, networking and other resources can be separated. Modern VNET jails can receive their own virtualized network stacks, and ZFS datasets can be assigned or delegated to individual jails. Depending on the intended use, a jail can contain a complete FreeBSD userland or share substantial parts of the host filesystem through read-only mounts and snapshots.

Jails are not hardware virtual machines and should not be presented as identical security boundaries. They share the host kernel, which is precisely what makes them lightweight. For services which can use the same FreeBSD kernel, they provide a direct and understandable isolation mechanism. A jail can be described in /etc/jail.conf, attached to a network interface, assigned resource limits and controlled using the ordinary service infrastructure.

For workloads requiring separate kernels, I normally use Xen. FreeBSD can operate as a Xen Dom0, allowing the virtualization host itself to remain a FreeBSD system. ZFS can provide the storage, familiar network interfaces and bridges can connect the guests, and the host is still configured through the same mechanisms used everywhere else.

FreeBSD also includes bhyve, which is a perfectly reasonable choice and more tightly integrated into the base system. My preference for Xen is based on my existing infrastructure and experience rather than a claim that no other hypervisor should be used.

Keep in mind that jails and full virtualization serve different purposes. Jails offer low-overhead isolation for FreeBSD services, while Xen guests provide a separate kernel and can run other operating systems - or consist of library operating systems. Both can coexist without requiring the host to adopt an entirely different management model.

ZFS

Then there is ZFS, which remains, in my opinion, the best general-purpose storage system available.

Calling ZFS a filesystem is technically correct but incomplete. It combines filesystems, pooled storage, checksumming, redundancy, snapshots, clones, compression, replication, quotas, reservations and volume management into a coherent design. Physical storage devices form pools, and datasets are allocated from those pools without requiring the administrator to divide the available space into a rigid collection of traditional partitions.

Each dataset can have its own compression, quota, reservation, snapshot and delegation policy. Snapshots are cheap administrative objects rather than exceptional emergency operations. Clones can be created from snapshots, datasets can be replicated using send and receive streams, and every block is protected by checksums which allow many forms of silent corruption to be detected.

Boot environments are particularly useful on FreeBSD. Before a significant system upgrade, a new boot environment can be created from a snapshot. If the upgrade fails, the previous environment can be selected again from the boot loader. This is not a substitute for backups, but it converts many potentially unpleasant system-recovery procedures into controlled rollbacks.

Yes, ZFS uses RAM. Much RAM. Very much RAM. Its ARC uses available memory as an adaptive storage cache, which is generally a productive use of memory which would otherwise remain unused. The cache can be constrained on small systems, and there are situations in which UFS is the simpler and more appropriate choice. An embedded device with very little memory does not necessarily require ZFS merely because ZFS exists.

On large storage systems, however, the capabilities of ZFS are difficult to replace. Btrfs has improved significantly and may be entirely appropriate for many Linux installations, but I still consider ZFS to provide a more coherent and mature overall storage-management model, particularly at large scale.

The transition from the original FreeBSD ZFS integration to the shared OpenZFS codebase introduced some additional movement and complexity. A subsystem which had previously felt like a tightly controlled part of one operating system became more visibly dependent on a cross-platform upstream project.

Networking

FreeBSD’s networking stack and network-management tools are another major reason I use it. The system has a long history as a server, router, firewall and network-appliance platform, and that heritage remains visible.

Tools such as ifconfig, route, netstat, sockstat and tcpdump form a coherent set. VLANs, bridges, routing tables, packet filters and virtual interfaces behave in understandable ways. PF and IPFW provide powerful firewalling and traffic-control capabilities without requiring an entirely separate orchestration framework.

The most important property is predictability. A network interface behaves like a network interface, a route behaves like a route, and a bridge behaves like a bridge. There is comparatively little magic between the configuration which was written and the packets which leave the machine.

The same tools can be used on a notebook, a jail host, a router, an embedded controller and a Xen Dom0. The topology may be completely different, but the underlying administrative vocabulary remains the same. Once again, there is no need to abandon one mental model and adopt another merely because the machine has a different physical role.

The performance is also excellent. Exact benchmark results naturally depend on drivers, queue configuration, packet sizes, offloading and the workload being tested, but I have repeatedly found FreeBSD networking to remain fast and stable under real loads without requiring the network stack to be replaced by a fashionable special-purpose subsystem.

A graphical workstation is still a Unix machine

People usually understand using FreeBSD on a server. They are often much more surprised when I explain that I also use it on graphical workstations and notebooks. I see no reason why connecting a monitor should require replacing the operating system.

On graphical systems, I normally use Xfce running on Xorg. It provides an ordinary desktop with panels, windows, menus and file management without attempting to become a second operating system layered on top of the first one. It remains lightweight enough that the desktop environment itself does not consume most of the available memory or processor time.

My main workstation is still based on Westmere-era Xeon processors. It has 196 GB of RAM because it is also used for technical workloads which can make productive use of that memory, but the processors themselves are old. I also use older i5- and Celeron-based notebooks with between 2 GB and 8 GB of RAM.

These machines remain useful. They can run editors, compilers, terminals, plotting software, scientific tools, document-processing systems and web browsers. They can be used to develop software, write articles and prepare scientific publications. Not every task requires a new high-end computer, and there is no sensible reason why displaying windows and editing text should demand the equivalent of what would have been considered a supercomputer not very long ago.

Modern web browsers and individual applications can of course consume absurd amounts of memory, and sufficiently demanding simulations, machine-learning workloads or compilation jobs may justify faster processors and modern GPUs. In those cases, the application requires the hardware. What I reject is having to replace a functional computer because the operating system and desktop environment have become too heavy to perform essentially unchanged tasks.

Lightweight software preserves useful hardware. It reduces power consumption, heat, cost and electronic waste, while allowing older systems to continue doing productive work. FreeBSD with Xfce fits this model very well.

Embedded systems are computers too

The same argument applies to embedded platforms. A Raspberry Pi is not intrinsically a Linux machine. It is an ARM computer with a particular collection of peripherals, firmware and hardware interfaces. The operating system remains a separate choice.

Where the required hardware is supported, FreeBSD is an attractive embedded platform precisely because it remains FreeBSD. Service configuration, network administration, package management, shell tools and system layout work in the same way as they do on a large server or workstation. A small laboratory controller or automation node does not require an entirely new administrative worldview.

This uniformity also simplifies automation. The same configuration-generation logic can be applied to amd64 and AArch64 systems. Scripts do not have to detect which of several unrelated network frameworks is currently active. Monitoring, logging and deployment tools can follow the same conventions.

Small systems benefit particularly strongly from FreeBSD’s quiet defaults. A device with 512 MB or 1 GB of RAM should use that memory for its actual function. It should not spend resources on indexing, desktop integration, telemetry, discovery or cloud synchronization which nobody requested.

Hardware support remains the deciding factor. Some boards and peripherals are supported later than they are under Linux, and vendor-specific interfaces may never receive complete FreeBSD drivers. When a project depends on such hardware, Linux may be the pragmatic answer. This is a limitation of available drivers, not evidence that embedded systems require a fundamentally different kind of operating system.

Hardware and GPU support

Hardware support is one of FreeBSD’s genuine disadvantages. The newest notebook, Wi-Fi chipset or GPU may not be supported immediately. Linux benefits from a much larger contributor base and considerably more vendor attention, while Windows drivers are commonly supplied directly by hardware manufacturers.

I can generally accept hardware support arriving somewhat later, provided that it is properly integrated and remains stable afterwards. Once a device is supported, my experience has been that it usually continues to work reliably across releases. I prefer this to constantly changing layers of partially integrated vendor software.

Graphics support illustrates both sides of the problem. Intel and AMD DRM drivers are derived from the corresponding Linux drivers through a compatibility infrastructure. This works, but it also imports some of the synchronization and versioning complexity which FreeBSD otherwise avoids. Proprietary NVIDIA drivers are luckily available directly from NVIDIA.

Normal accelerated graphical desktops work well on supported hardware. Vulkan has worked on the Intel NUC systems on which I tested it, and OpenCL has been usable for several workloads. Vendor-specific compute remains less convenient. CUDA support lags substantially behind native Linux, and anyone whose primary workload depends on current CUDA tooling will probably have a much easier time using Linux on that particular machine.

This is a real limitation, but it does not follow that every workstation must therefore run Linux or Windows. Operating-system selection should be driven by an actual requirement. The possibility that a machine might someday need an unsupported GPU stack is not enough reason for me to abandon the environment which works better for everything it currently does.

The license

FreeBSD’s permissive licensing also matches my understanding of software freedom more closely than copyleft licensing does.

The GPL has achieved many important things. Copyleft has forced manufacturers to publish modifications which might otherwise have remained private, and it has helped preserve large bodies of software as shared infrastructure. The opening of devices such as the WRT54G family is a well-known example of the positive effect GPL obligations can have. I do not dismiss that contribution.

Nevertheless, my own idealistic definition of freedom is closer to the BSD model. When I release software freely, I generally want the recipient to be able to use it for any purpose: in another open-source project, in a proprietary product, in a laboratory instrument, in an embedded controller or as part of a commercial service. Attribution and preservation of the license notices are reasonable requirements, but I do not normally want to dictate the licensing model of the larger system around my component.

This seems particularly appropriate for an operating system. A permissively licensed system can be incorporated into commercial products, research instruments and appliances without forcing the licensing of every surrounding component into the same model. The source remains available, but the recipient receives broad permission rather than a legal mechanism governing whatever may later be built around it.

There is an obvious cost. A company can modify BSD-licensed software and decline to publish the resulting changes. The community may not receive every useful improvement. That is not an accidental loophole; it is part of the freedom the license intentionally provides. And out of experience especially large corporations tend to still contribute back.

The permissive licensing of the FreeBSD base also allowed components under other compatible licensing models to be integrated without imposing a conflicting copyleft requirement on the entire kernel. The original CDDL-licensed ZFS implementation is an important example. The same integration would have been considerably more difficult in a kernel whose licence was incompatible with the CDDL.

For my own work, the BSD model therefore feels closer to genuinely giving something away. Another person’s proprietary use does not remove the public version I released, and I would naturally prefer useful improvements to be contributed upstream. I simply do not believe every act of sharing must also regulate the licensing of everything built around the shared component.

No systemd

FreeBSD does not use systemd. It retains the BSD rc.d system, in which startup scripts declare their dependencies and configuration values are stored in ordinary text files such as /etc/rc.conf.

Systemd solves real problems, and many administrators prefer it. It provides service supervision, dependency management, activation mechanisms and a large collection of integrated facilities. My objection is not that every part of systemd is technically bad. I simply do not want that style of tightly integrated service-management ecosystem controlling increasing portions of my operating system. I want to know which script starts a service, to be able to open that script in an editor and to invoke it manually when necessary. I want configuration to remain visible in text files, and I do not want basic service diagnosis to depend on a central daemon and its surrounding ecosystem.

FreeBSD’s rc.d system is less spectacular. It starts services, stops services and orders their dependencies. It has been refined over decades, remains understandable and does its job. The absence of systemd is therefore not the sole reason I use FreeBSD, but it is a visible consequence of the project’s preference for smaller, inspectable and composable mechanisms.

Why I do not want Windows

I will not pretend to be neutral about Windows. I hate using modern Windows, not because it lacks technically impressive components or useful applications, but because the relationship between the administrator, the machine and the operating system feels fundamentally wrong.

With FreeBSD, I regard the operating system as software installed on my computer. I decide which services run, when the machine is upgraded, which kernel is booted, how storage is organized and how the machine participates in a network. Windows increasingly feels like a service delivered through hardware which I happen to own.

Updates are the most visible part of this difference. Security updates are necessary, and my FreeBSD systems are regularly updated. The problem is not that an operating system receives patches. The problem is losing control over when and how maintenance occurs. A workstation, laboratory controller or long-running service should not reboot because the operating system decided that its own update schedule is more important than the work being performed.

My FreeBSD machines routinely run for weeks or months between planned reboots, and systems in suitable roles can remain operational for much longer. Kernel security updates eventually require restarts, and preserving a large uptime counter is never more important than applying necessary fixes. The important distinction is that the reboot remains an administrative decision.

I have also never personally experienced a FreeBSD kernel crash on one of my deployed systems. This is not proof that FreeBSD cannot crash; naturally it can. It is a description of my experience across many systems and many years. My experience with Windows has been considerably worse, particularly when updates, drivers and recovery mechanisms interact.

When Windows fails during boot, manual recovery mechanisms technically exist, but the primary experience is often an opaque graphical screen announcing that the system is diagnosing or repairing itself. Very little information is initially provided about what failed, what is being changed or how the administrator can intervene. One is left staring at a blank window or an indefinite progress message while the operating system negotiates with itself.

FreeBSD exposes the machine more directly. I can enter the boot loader, select another kernel, boot into single-user mode, mount filesystems manually, inspect logs, edit configuration files or return to an earlier ZFS boot environment. The repair environment is not a separate simplified product layered over the real system. It is the system.

The hardware requirements of modern Windows releases are another problem. Functional computers are excluded from supported upgrades because of CPU-generation lists, TPM requirements and other platform policies even when their actual performance remains entirely sufficient for the intended workload. I reject the idea that replacing an operating system should automatically require replacing working hardware.

The increasing cloud integration is perhaps even more objectionable. Online accounts, synchronization services, subscription suggestions and vendor integrations are pushed into the default installation and setup process. Individual components can often be disabled, removed or worked around, but doing so requires actively resisting the direction of the product. I do not want my operating system to repeatedly suggest uploading my files to somebody else’s computers. I do not want a cloud account to become the expected form of local identity. I do not want additional services to appear because an update decided that they would improve engagement. A local machine should remain a local machine unless I explicitly configure it otherwise.

Windows may be unavoidable for particular proprietary applications, hardware tools or testing requirements. In those cases I will use it, preferably in an isolated and controlled environment. It is not a system on which I want to build infrastructure or depend for long-running work.

Mandatory access control and the optional superuser

Another aspect of FreeBSD which is surprisingly easy to overlook is that its security model does not end with traditional Unix ownership, groups, mode bits and one universally privileged account. The Mandatory Access Control framework provides an in-kernel architecture through which additional security policies can participate in access-control decisions involving filesystems, processes, sockets, network interfaces, executable activation and other system objects. These policies can be loaded as kernel modules or compiled into the kernel, and several policies can be active at the same time. They do not replace the ordinary Unix permissions but add further restrictions on top of them; a MAC policy can deny something which the normal discretionary permissions would permit, but it cannot simply override a denial made by the base system. This makes the framework composable rather than turning it into a second, unrelated permission system.

One of my favourite examples is mac_portacl. Traditionally, a network daemon which wants to listen on a port below 1024 has to begin its life as root, bind the socket and then attempt to discard its privileges correctly. This is a rather unfortunate design inherited from a time when the distinction between “ordinary user” and “all-powerful system administrator” was considered sufficiently fine-grained. A web server does not need permission to mount filesystems, load kernel modules, alter routing tables or read every file on the machine merely because it wants to listen on TCP port 80.

mac_portacl allows binding individual TCP or UDP ports to be authorized for specific numerical user or group IDs. The daemon can therefore be started under its dedicated unprivileged account from its first instruction and still be permitted to bind exactly the ports it requires. It does not first have to receive every privilege available to root and then rely on its own code to discard those privileges without mistakes. The policy can also be configured so that even root is not automatically exempt from its rules, meaning that a particular port can genuinely be reserved for a particular service identity rather than merely being protected from ordinary users. The only drawback is the length limit of the ruleset encoded in a sysctl variable.

There is a small but important technical detail here. Since MAC policies may restrict existing permissions but cannot grant access which the traditional privilege checks already deny, the ports controlled by mac_portacl must first be removed from the ordinary net.inet.ip.portrange.reservedlow to net.inet.ip.portrange.reservedhigh range. After that, the MAC policy becomes the authority deciding which UID or GID may bind the port. This is a good example of the framework’s design: the traditional policy is not silently bypassed, but the administrator can deliberately move responsibility for a particular decision into a more precise policy.

The same idea appears in mac_bsdextended, which is sometimes described as a filesystem firewall. Its rules are normally managed using ugidfw and can impose additional restrictions based on the credentials of the accessing process, properties of the target filesystem object and the requested access mode. Unlike the labeling policies, mac_bsdextended does not attach persistent security labels to every file. It maintains an ordered in-kernel rule set and applies it in a manner deliberately reminiscent of a packet firewall. This makes it possible to express restrictions which do not fit neatly into owner, group and mode bits without changing the basic permissions of every affected file.

Traditional Unix permissions describe what an object’s owner and group normally permit, whereas mac_bsdextended can describe system-wide rules about which combinations of subjects, objects and operations must never be allowed. The distinction resembles the difference between configuring a listening service and placing a packet filter around it. The application’s normal permission model remains present, but an independently administered security boundary can reject accesses before they reach it. This is useful on multi-user systems, service hosts and appliances where the intended separation does not correspond exactly to the ownership hierarchy of the filesystem.

FreeBSD also includes proper label-based information-flow policies. mac_biba implements the Biba integrity model, in which subjects and objects receive integrity levels and optional compartments. The purpose is to prevent lower-integrity information or processes from modifying higher-integrity objects. A process at a low integrity level may be able to read a high-integrity object, but it cannot write to it; conversely, a high-integrity process is prevented from reading lower-integrity data which could contaminate its decisions. This allows the integrity of system components, configurations or valuable data to be represented independently of which numerical user happens to own them.

mac_lomac follows a related but more dynamic model. Instead of simply denying every read from an object at a lower integrity level, it can permit the read and then lower the integrity label of the reading process. Once the process has consumed less trustworthy information, it is no longer allowed to modify objects which require a higher integrity level. This floating-label behaviour is particularly interesting because it models the history of information flow rather than only the identity under which a process was started. A process which was previously trusted does not remain trusted merely because its UID has not changed after it has processed untrusted input.

mac_mls, in turn, applies labels to confidentiality rather than integrity. Subjects receive clearance levels and compartments, while objects receive classifications. The policy can prevent a process from reading information above its clearance and from writing sensitive information into a lower classification where it could become visible to less privileged subjects. Biba and MLS therefore address nearly opposite directions of undesirable information flow: Biba protects high-integrity objects from low-integrity influence, while MLS protects confidential information from flowing towards lower confidentiality levels.

These systems are more elaborate than ordinary access-control lists, but they are not merely theoretical models mentioned in an academic security book. They are implemented policies which can label processes, files, sockets and network interfaces, and labels can be assigned through tools such as setfmac, setfsmac and setpmac or inherited through login classes and executable labels. A service can consequently be constrained not only by the account under which it runs but also by the integrity or confidentiality domain in which it operates. The FreeBSD Handbook even demonstrates configurations in which a correctly constrained root process cannot access files belonging to a differently labeled service domain.

There are naturally practical limitations. Label-based policies require careful planning, filesystems have to support the required labels, boot and login environments must receive suitable initial labels, and an incorrect configuration can make a machine rather comprehensively inaccessible. The MAC framework documentation also explicitly warns that not every possible attack path from an already malicious privileged process is covered, so these policies should not be treated as a magical proof that a compromised traditional superuser can never escape every restriction. They are additional kernel-enforced security mechanisms, not substitutes for careful service design, jails, secure levels, Capsicum or physical control of the machine.

There are also useful network-oriented policies beyond mac_portacl. mac_ifoff provides a deliberately blunt interface-silencing mechanism. Incoming and outgoing traffic on the loopback interface and on other interfaces can be enabled or disabled through separate policy controls, with an additional option governing whether BPF may still receive traffic. This can be useful for appliances, staged startup procedures, emergency isolation and systems which should become network-capable only after a trusted initialization sequence has completed. It is not intended to replace a packet firewall; it provides a policy-level decision about whether network data flow is permitted at all.

The newer mac_ipacl policy addresses another problem which becomes important with VNET jails. It allows the host administrator to specify which IPv4 and IPv6 addresses or subnets a particular jail may assign to particular interfaces. Delegating a virtual network stack to a jail therefore does not have to mean allowing that jail to select arbitrary addresses available on the surrounding network. The host can authorize the exact address ranges belonging to the jail and reject everything else, including more specific exceptions within otherwise permitted subnets.

The optional superuser

Perhaps the most unusual possibility, however, is that FreeBSD can disable the traditional superuser privilege associated with UID 0 altogether. The tunable

security.bsd.suser_enabled=0

can be placed in /boot/loader.conf, or the corresponding sysctl can be changed while the system is running. When disabled, processes with an effective UID of zero no longer automatically satisfy the kernel’s privilege checks merely because they are root. The setting also exists on a per-jail basis, allowing a jail to contain an account named root for ownership and compatibility purposes without granting that account the usual collection of jail-local superuser privileges.

This distinction deserves some precision. UID 0 does not cease to exist, and ordinary filesystem ownership can still make it different from other accounts: files owned by UID 0 remain owned by UID 0, and their mode bits continue to be evaluated normally. What disappears is the general kernel rule that a process with effective UID 0 should be exempt from ordinary privilege checks. A system which uses this facility therefore has to be designed around explicitly delegated resources and narrowly defined mechanisms rather than assuming that an administrator can always become omnipotent later.

Such configurations are often constructed around a small number of carefully audited set-ID helpers, service-specific accounts and resources whose ownership has been arranged in advance. There is an important subtlety here: once security.bsd.suser_enabled is zero, merely making a program setuid-root does not restore the kernel privileges which were just disabled. The helper can still change its effective identity and gain access to files, sockets or other resources permitted to that identity by ordinary ownership and configured policies, but it does not regain universal privilege merely because the resulting UID is zero. Operations which normally require kernel privilege must instead be eliminated from the running design, performed during an earlier trusted initialization phase, or delegated through an explicit mechanism.

Recent FreeBSD versions also provide mac_do together with mdo, allowing an administrator to authorize narrowly specified credential transitions without granting unrestricted superuser access. Rules can describe which user or group may transition to which target credentials, and the policy can restrict those transitions to invocation through approved executables. This is much closer to the security model I prefer: instead of asking whether a process is “root”, the system can ask which exact transition or operation has been authorized for this particular caller.

A machine without an effective universal superuser is naturally not suitable for every ordinary workstation or general-purpose server. Package installation, hardware reconfiguration and emergency repairs become considerably less convenient when no running process can acquire broad kernel privileges. For a sealed appliance, dedicated network service, embedded controller or carefully constructed jail, however, this can be an extremely powerful design. Once initialization has completed, there need not be any account whose compromise automatically grants authority over the entire running environment.

What I like about all of these mechanisms is not that every FreeBSD installation has to use them. Most of my systems do not run a full MLS or Biba configuration, and introducing mandatory labels without a clear threat model would add complexity without necessarily improving security. The important point is that the operating system provides the mechanisms in a coherent, documented and inspectable form. I can choose ordinary Unix permissions for a simple workstation, add a filesystem firewall for a service host, allocate individual low-numbered ports to unprivileged daemons, constrain VNET jail addresses, introduce integrity labels for a sensitive appliance or construct a running system in which UID 0 no longer represents an all-powerful escape hatch.

The alleged software problem

One of the most common arguments against using FreeBSD - or really any system other than Windows - is that one supposedly needs Windows for all the so called “standard software” (which is no standard anyways). According to this view, alternative operating systems may be suitable for servers, routers or programmers who enjoy spending their evenings compiling obscure utilities, but it would not be possible to perform ordinary productive work on them. As soon as documents have to be written, images edited, measurements evaluated, videos recorded or machines designed, one allegedly has to return to Windows.

This confuses two entirely different statements. It can be perfectly true that a particular organization has built its workflow around one specific proprietary application (which is a bad idea to be honest) which is only available for Windows. A manufacturer may distribute a configuration program only as a Windows executable, a customer may require files in the native format of a particular commercial CAD system, or some laboratory instrument may come with control software which cannot reasonably be replaced (though reverse engineering capabilities of modern LLMs make much more possible than it was a few years ago). In such a case, Windows may indeed be at first glance the easier choice for that particular task. What does not follow is that useful software in general is missing from FreeBSD, or that serious technical, scientific and creative work cannot be performed there. My daily work is almost entirely based on open-source tools, and in most areas I do not regard them as emergency replacements for something supposedly more professional. They are the tools I would choose independently of the operating system.

For writing documents, scientific publications and longer technical notes, I use LaTeX. I have never found anything better for documents whose structure, typography, equations, references and reproducibility actually matter. A LaTeX document is source code for a publication: it can be placed under version control, compared meaningfully between revisions, generated from scripts and built again years later without manually reconstructing a collection of hidden formatting decisions. Bibliographies, equations, figures and cross-references belong to the document structure rather than being fragile decorations attached through a graphical interface. And everything is searchable via grep and accessible to programmatic tools too. For typesetting music, the corresponding tool in my workflow is LilyPond, which applies much the same idea to musical notation. Neither system is necessarily the fastest way to produce a two-line shopping list, but for material which is intended to remain readable, maintainable and correctly typeset, they are difficult to replace. For quick note taking markdown documents and pandoc have turned out to be a very useful combination.

For calculations which are too exploratory for a standalone program, I use Jupyter notebooks. They are useful not only for numerical experiments but also for formatted technical note-taking, because explanations, equations, plots and executable code can remain together. A calculation does not have to be described retrospectively in a document after it has already been performed somewhere else; the reasoning, implementation and resulting figures can form one reproducible object. And one can build labbooks or diaries with Jupyter very well. For larger programs and ordinary text editing, my preferred editor is still Vim. Yes, really. Its interaction model initially appears strange because it assumes that editing text is a language of operations rather than a sequence of mouse movements, but after becoming accustomed to it, navigating and transforming text becomes extremely fast. More importantly, the same editor is available in a graphical terminal on my workstation, through SSH on a server and on a serial console connected to an embedded system. Once again, the mental model does not have to change merely because the machine does.

Vector graphics are usually produced with Inkscape, while GIMP is used for photographs, rendered images and other pixel-based graphics. These tools cover most of what I need when preparing illustrations for articles, presentations, publications and project documentation. For video recording and screencasts, I use OBS Studio. Blender is used for editing and rendering three-dimensional objects, but it also provides a surprisingly capable video editor when recorded material has to be assembled, cut or annotated. The idea that image and video work intrinsically requires an Adobe subscription is therefore rather foreign to my experience. There may be particular commercial workflows which require proprietary exchange formats or plugins, but that is very different from claiming that graphics or video cannot be handled without Windows.

Mechanical design is performed in FreeCAD. It is used for the printable mechanisms, housings, optical components, robot parts and various other engineering constructions which regularly appear in my projects. I also use it extensively to design our parts at work. For finite-element simulations, Elmer and CalculiX provide the numerical machinery required for many structural, thermal and multiphysics problems. The resulting geometry can be prepared for 3D printing using Cura. These tools are not always as polished in every corner as expensive commercial engineering suites. Nevertheless, the combination is perfectly capable of producing real parts and evaluating real engineering questions. More importantly, it is scriptable, inspectable and can be integrated into automated workflows instead of existing only as a sequence of mouse operations inside an opaque application.

Much of my scientific and technical work is naturally performed in Python, together with NumPy, Matplotlib and the surrounding numerical ecosystem. PyOpenCL is used where larger numerical operations can profit from execution on GPUs or other OpenCL devices. PyTorch is also used for machine-learning work, although obtaining a current and fully functional installation on FreeBSD can be considerably more annoying than I would like. This is one of the areas in which Linux has a genuine practical advantage because the machine-learning ecosystem is developed almost entirely around Linux and current vendor-specific GPU stacks - and many developers there currently move fast and love to break things as well as don’t care much about portability. It is nevertheless possible to perform a large amount of machine learning and local inference on FreeBSD, and Ollama is used for running local language models where supported configurations are sufficient.

For LLM-assisted work, I use Codex alongside the usual editors, compilers and development tools. I do not see this as replacing the traditional toolchain. It is another component within it: source code is still compiled, tested, reviewed and stored in version control, but an LLM can assist with implementation, code review, exploration of unfamiliar codebases and repetitive transformations. Local inference through Ollama is useful where data should remain on the local machine or where a small specialized model is sufficient. Remote tools are used where their additional capabilities justify them. The important point is that the operating system does not prevent modern AI-assisted workflows merely because it is not the operating system currently receiving the largest number of glossy desktop applications.

For conventional software development, Clang is the C and C++ compiler supplied with the FreeBSD base system. I also use Erlang, Python and many other language runtimes depending on the project. Git manages source code, articles, configuration, CAD scripts and practically everything else which can sensibly be represented as a collection of files. Rsync is used to move and synchronize those files between systems. These are simple tools, but they scale from a small embedded project to substantial repositories and infrastructure. A Git repository created on the workstation behaves the same way on a server, and an rsync invocation does not care whether its target is a storage machine, a Raspberry Pi or a jail. This consistency is far more valuable to me than having a different graphical synchronization product for every type of device.

Structured data is commonly stored in PostgreSQL, which is suitable for far more than the stereotypical web application and has become one of the most useful general-purpose data-management systems available. Geospatial data is handled with PostGIS and pgvector allows efficient vector indices. Neo4j is used when the relationships between objects are more naturally represented as a graph than as conventional tables. Small datasets and quick calculations may remain in notebooks or ordinary files, but once data has to be queried, validated, shared between processes or retained for a longer project, using an actual database is usually preferable to constructing yet another collection of increasingly complicated spreadsheets.

ImageJ and Fiji deserve special mention because they are among those rare scientific tools whose usefulness extends far beyond the field in which one first encounters them. I use them for analysing microscopy images from electron and optical microscopes, but the same environment can display and process MRI and computed-tomography DICOM data, reconstruct three-dimensional volumes, recover physical scales, measure structures and evaluate image sequences. It can also be used for astronomical data and many other forms of scientific imaging. The plugin ecosystem is enormous, the operations are sufficiently transparent for serious analysis, and repetitive processing can be scripted. It is difficult to think of another single utility which has solved such a diverse collection of image-analysis problems for me.

Laboratory work also involves a large number of smaller programs and scripts which communicate with instruments, collect measurements, transform data and automate experiments. These are often written in Python or C and talk to equipment through serial links, Ethernet, USB devices or vendor-defined protocols. This is an area in which a Unix system is particularly pleasant because devices, processes, sockets, pipes and files can be combined without requiring a monolithic laboratory-management application. A measurement program can produce data which is immediately processed by another tool, inserted into PostgreSQL, plotted through Matplotlib and archived through ordinary filesystem mechanisms. When a vendor supplies only a Windows application, it may occasionally have to be placed in a virtual machine or reproduced through the documented protocol, but most instruments do not fundamentally care which operating system sends commands to their interface.

For ordinary communication, I use Thunderbird for email. I remain unconvinced that a web page should be involved in reading and writing email at all. Email is an established network service with standardized protocols, local caching, folders, filters, multiple identities and the possibility of retaining an archive independently of whichever provider currently hosts the mailbox. Turning it into a branded website removes many of those advantages and makes a basic communications protocol unnecessarily dependent on one browser session and one provider’s interface. Thunderbird allows multiple accounts to be handled in one place and keeps email functioning as email rather than as another cloud application.

Pidgin is used for XMPP instant messaging. Chromium is my usual browser where the modern web cannot be avoided, which unfortunately is rather often. Scanner access is provided by SANE, and HPLIP handles communication with HP printers. These are not exciting parts of the toolchain, but that is precisely the point: printing, scanning, browsing and messaging are ordinary computer tasks, and they work without requiring the operating system to become a delivery mechanism for one vendor’s online account and bundled services.

The graphical environment around all of this is Xfce. It provides windows, panels, menus, keyboard shortcuts and a file manager while remaining light enough to run fluidly on old hardware. It does not attempt to define how applications store their data, how services are managed or which online identity should own the session. Most of the important tools are independent applications which communicate through files, pipes, sockets and documented formats. Xfce merely provides a convenient graphical environment in which they can be used.

There are many other programs in my daily environment which do not immediately come to mind, and I am still planning a separate article about the complete open-source toolchain I use. The list above is therefore not intended as a comprehensive catalogue. It is simply the set of tools which I encounter regularly while writing publications, developing software, evaluating experiments, designing mechanical parts, administering infrastructure, producing graphics and communicating with other people.

The relevant point is that none of this feels like working around the absence of “real” software. I am not sitting in front of FreeBSD wishing that I could finally return to an operating system on which productive work is possible, on the contrary it is the most productive environment I have at hands and the tools feel way more native and consistent than what I was used to in the Windows ecosystem during my youth. The tools are already there, and in many cases they are better suited to my work because they use open formats, can be automated, integrate with version control and remain usable independently of a vendor account or subscription. They also tend to be available across architectures and machine classes, which means that the same software environment can follow me from a workstation to a server or embedded platform.

There are naturally proprietary programs for which no complete open-source replacement exists. Some engineering suites (especially for high end FPGAs), vendor configuration utilities, some games (though for example Factorio runs perfectly well on FreeBSD), some GPU compute frameworks and organization-specific office workflows (which are in my opinion a sign of misdesign already) genuinely require Windows or Linux. When such a requirement exists, the corresponding operating system can be used in a virtual machine, on a dedicated computer or for the particular workload which needs it. What I reject is the much broader claim that one cannot perform ordinary or professional work without Windows. My daily work consists of scientific computing, software engineering, document preparation, CAD, image analysis, system administration and a fair amount of rather unusual hardware development, and all of it is performed with this toolchain on FreeBSD.

The software is not missing. It is simply not always packaged as a collection of subscriptions, launchers and web pages.

The operating system underneath the work

Ultimately, I prefer FreeBSD because it behaves like infrastructure. It starts with little enabled, keeps configuration in predictable locations, treats standards as meaningful contracts and develops the kernel and userland as one system. Its documentation is part of the installation, its source is readable, compatibility is considered during interface design, jails provide lightweight isolation, Xen provides full virtualization, ZFS provides an exceptionally capable storage model, and the network stack remains fast and dependable.

The same system can be used on my workstation, on servers, on virtualization hosts and on embedded controllers. This is not merely aesthetically pleasing. It means that I do not have to change mental models every time I connect to another machine. The commands, configuration conventions, diagnostic procedures and accumulated knowledge remain useful everywhere. The hardware and workload change, but the operating system does not arbitrarily redefine how a computer is administered.

A computer should spend its resources on the work for which it exists. It should not require new hardware merely to continue displaying a desktop. It should not start services because somebody else decided that they might be useful. It should not force cloud accounts into local administration, replace meaningful failure information with progress animations or demand constant attention for its own maintenance.

I do not need the operating system itself to be exciting. The physics, software, machines and strange projects built on top of it are allowed to be exciting. FreeBSD stays underneath them, quietly and consistently doing its job.

References

• FreeBSD
• Virtualization and Hypervisors:
  • Xen
  • bhyve
• Graphical environments:
  • Xorg, the main X11 server
  • Xfce, a lightweight desktop environment
• binmiscctl, the utility to manage binary image activators
• brandelf, the utility to mark a binary for a specific ABI
• The IEEE 1003 series: Portable Operating System Interface (POSIX)
• The FreeBSD source tree, there is a read only mirror on GitHub
• Compatibility, storage and system software:
  • OpenZFS, the OpenZFS storage platform used by FreeBSD
  • Btrfs, a copy-on-write filesystem commonly used on Linux
  • QEMU, machine emulator and virtualizer, also usable for transparent foreign-architecture execution
  • Wine, a compatibility layer for running Windows applications
  • systemd, the service and system manager used by many Linux distributions
  • tcpdump, command-line packet analyzer
  • ipfw, FreeBSD’s firewall and traffic-control framework
• Document preparation and text processing:
  • LaTeX, document preparation and typesetting system
  • LilyPond, music engraving and typesetting system
  • Pandoc, document-format conversion and publishing tool
  • Jupyter, interactive notebooks for computation and technical documentation
  • Vim, modal text editor
• Graphics, video and media:
  • Inkscape, vector graphics editor
  • GIMP, image editor for raster graphics
  • OBS Studio, video recording and streaming software
  • Blender, 3D modelling, rendering and video-editing software
• CAD, simulation and manufacturing:
  • FreeCAD, parametric open-source CAD system
  • Elmer, multiphysics finite-element simulation software
  • CalculiX, finite-element analysis software
  • Ultimaker Cura, slicer for additive manufacturing
• Scientific computing and machine learning:
  • Python, general-purpose programming language widely used for scientific computing
  • NumPy, numerical array and scientific-computing library for Python
  • Matplotlib, plotting and visualization library for Python
  • PyOpenCL, Python interface to OpenCL
  • PyTorch, machine-learning and tensor-computation framework
  • OpenCL, heterogeneous parallel-computing API
  • Vulkan, cross-platform graphics and compute API
  • CUDA, NVIDIA’s GPU computing platform and programming model
• LLM and AI tools:
  • Ollama, software for running and serving language models
  • Codex, LLM-assisted software-development tool
• Programming and development tools:
  • Clang, C, C++, Objective-C and related language frontend for LLVM
  • Erlang, programming language and runtime for concurrent and distributed systems
  • Git, distributed version-control system
  • rsync, file synchronization and transfer utility
• Databases and data processing:
  • PostgreSQL, relational database management system
  • PostGIS, geospatial extension for PostgreSQL
  • pgvector, vector-similarity search extension for PostgreSQL
  • Neo4j, graph database management system
• Scientific imaging:
  • ImageJ, scientific image-processing and analysis software
  • Fiji, scientific image-processing distribution based on ImageJ
• Communication, web and peripheral support:
  • Thunderbird, email client
  • Pidgin, multi-protocol instant-messaging client
  • Chromium, open-source web browser project
  • SANE, scanner-access framework
  • HPLIP, HP’s open-source printing and imaging software

This article is tagged:

• Opinion
• FreeBSD
• System administration
• Administration
• Computer
• DIY