felaktig.[info]

Tech drama. A BSD user.

Void Linux is an independent Linux distribution — meaning it's not based on Ubuntu, Debian, Fedora, or any other distro. It's built from scratch, which makes it a bit of a rare bird in the Linux world.

Here's what matters to you as a user:

It's fast. Void is known for being lightweight and snappy. It doesn't come loaded with unnecessary software or background services you'll never use. A fresh install gives you just enough to get started, and you build from there.

It uses XBPS instead of apt or pacman. That's its homegrown package manager. It's fast and handles dependencies well, but it's a different tool to learn if you're coming from Ubuntu or Arch.

It runs on runit, not systemd. This is a big deal in Linux-nerd circles. Systemd is the init system used by almost every mainstream distro — it manages startup, services, logging, and a whole lot more. Void chose runit instead, which is much smaller and simpler. For you, this means a faster boot and a leaner system, but also that some guides and tutorials written for “Linux” won't directly apply because they assume systemd.

Rolling release. There's no “Void 2024” or “Void 26.” You install once, and updates flow in continuously. No big-version-upgrade drama. But this also means things can occasionally break if an update introduces a bug.

Multiple editions. It comes with several desktop environment options (XFCE, LXDE, Cinnamon, MATE, Enlightenment) and also supports building your own minimal system. There's even a musl libc variant for the truly hardcore who want maximum lightweight.

Should you use it?

Want to learn how Linux works under the hood? – A great teacher

Want things to “just work” out of the box? – Probably not your first pick

Are comfortable in the terminal? – Very rewarding

Are coming from Windows/Mac? – Too steep a learning curve

The honest truth: Void Linux is fantastic for tinkerers and people who want a lean, no-nonsense system they control top to bottom. But if you're an average user who just wants to browse the web, write documents, and watch videos without thinking about your operating system, something like Linux Mint or Ubuntu will save you a lot of headaches. Void rewards curiosity and patience — if you've got those, it's a really satisfying distro to run.

NOTE: Stolen from Portuguese and translated into English by me, with a little help from Kagi Translate

In 2008, a developer with previous experience in NetBSD began work on a new package manager for Linux called XBPS, an acronym for X Binary Package System. He had in mind to create a tool that was fast, reliable, well-featured, and, most importantly, portable enough to work independently of any specific distribution.

Projects like this are not uncommon in the open source world, but XBPS ended up taking a slightly different path. To test their package manager in a truly neutral environment, the developer decided to create an operating system from scratch. If XBPS worked there, it would work anywhere. This is how Void Linux was born, an independent distribution that, over time, went from a technical experiment to a real alternative within the Linux ecosystem, even being compared in some scenarios with Arch Linux.

A really independent system

Unlike distributions like Ubuntu or Linux Mint, which are based on other distros, Void Linux is built from the ground up. This means that it does not inherit technical decisions, tools or limitations from previous projects. The entire system revolves around the XBPS, which remains one of its central pillars.

This independence allowed Void to adopt unusual choices. Over time, it came to differentiate itself not only by its origin, but by a combination of technologies that rarely appear together in other distributions.

Runit instead of Systemd

One of the first noticeable differences is in the init system. While most modern distributions use systemd, Void Linux opts for runit.

The init system is the first process started after the kernel and is responsible for initializing essential system services such as networking, audio, and graphical interface. The runit follows a simpler and more straightforward approach, focusing on speed and POSIX standard compliance. It avoids centralizing multiple functions in a single component, unlike systemd, which aggregates multiple responsibilities.

Although Void is one of the main promoters of the runit, it is not the only system to use it. Distributions such as AntiX, Artix, Gentoo, and Devuan also support it, and the runit can even appear in BSD systems, including NetBSD itself and OpenBSD, and can also be used in environments such as macOS for user-level process management.

GLIBC or MUSL

Another point that differentiates Void Linux is the possibility of choosing between two C libraries: glibc and musl.

These libraries act as an intermediate layer between programs and the Linux kernel. The choice between them directly impacts the behavior of the system. GLIBC is the most common and offers wide compatibility, being used by most distributions. MUSL was designed with simplicity, lightweight and POSIX compliance in mind, resulting in smaller binaries and lower resource consumption.

This choice, however, may have implications. Not all software works perfectly with MUSL, especially proprietary applications or those dependent on specific GLIBC behaviors. Still, Void stands out for consistently supporting MUSL, which is relatively rare. An example of another distribution that follows this line is Alpine Linux, widely used in container environments precisely because of its lightness.

Rolling release with a conservative approach

Void Linux follows the rolling release model, as does Arch Linux. This means that the system is installed once and updated continuously, without the need for periodic reinstallations. However, there is an important difference in how these updates are conducted.

While Arch tends to quickly adopt newer versions of packages, Void maintains a more conservative stance. Updates arrive continuously, but with a certain amount of additional care, reducing the likelihood of unexpected issues. This creates a balance between constant updates and stability, something that can be relevant for those who intend to use the system on a daily basis.

Technical minimalism in practice

Void Linux is often associated with the concept of minimalism, but not in a visual sense. This is a technical minimalism, where the system delivers only what is necessary to function.

It's possible to run Void with around 250MB of RAM, which highlights the impact of your design choices. There are no extra components running in the background unnecessarily, no tools installed by default beyond the essentials. This results in a fast and responsive system that requires manual configuration for virtually any task.

Installation and first steps

The Void Linux installation process starts with downloading the image from the official website. There are versions for different architectures, including 32-bit systems, as well as options with XFCE graphical interface and base images in text mode. During the download, the user also chooses between the versions with GLIBC or MUSL.

When starting the base image, the system presents a text mode environment. The default credentials are provided on the download page itself and on the home screen: the root user with password “voidlinux” or the user “anon”, also with the same password. To start the installer, administrative access is required, which can be done with the void-installer or sudo void-installer command.

The installer is text-based but well organized. By following the sequence of steps, it is possible to complete the installation without major difficulties. After the reboot, the system starts again in text mode, with no graphical interface installed.

Installing a graphical environment

To use the system with graphical interface, it is necessary to manually install the desired components. During testing, installing KDE Plasma was relatively simple, but required some additional adjustments, especially in the configuration of SDDM, the KDE login manager.

A relevant point noted during this process was that XBPS does not automatically install all the necessary graphics components. Elements such as Xorg or Wayland need to be installed manually, which highlights the more explicit nature of the system. This type of behavior requires greater familiarity with the inner workings of Linux.

For those who prefer to avoid this initial process, there is the version with XFCE pre-installed. Still, the installer remains in text mode, and the resulting system is quite lean. The installation includes only the basic interface components and the Firefox browser, with no app store or graphical tools for package management.

Using XBPS on a day-to-day basis

XBPS is simple in the way it organizes your commands. To update the system, usexbps-install -Syu , as long as the XBPS itself is up to date. Otherwise, the system informs you of the need to runxbps-install -u xbps it first.

Package installation is done withxbps-install nome-do-pacote , which may include the option-S to update repositories simultaneously. Packet removal is performed withxbps-remove nome-do-pacote, and using the parameter-R also removes unused dependencies. To fetch packages, the term commandxbps-query -Rs returns relevant results.

During our testing with the MUSL version, there was a case of unfulfilled dependencies when trying to install GIMP. The solution involved updating the system and changing the mirror of the repositories using the xmirror tool. After the full update and reboot, the installation proceeded normally. This type of situation illustrates both the flexibility and potential difficulties associated with using MUSL.

Compilation and isolation with xbps-src

In addition to installing binary packages, Void supports compiling software via xbps-src. An important differentiator is the use of isolated environments via chroot during the build process.

This isolation prevents build dependencies from interfering with the main system, keeping the environment cleaner and more predictable. The concept is similar to that used by modern containerization tools such as Docker, although applied differently.

Community, culture and governance

Void Linux has a smaller community compared to other popular distributions. This directly impacts the amount of documentation available and the ease of finding ready-made solutions to specific problems. While the Void Handbook is useful, it doesn't have the same level of detail as the Arch Linux documentation.

There is also a recurring profile of users migrating to Void in search of a leaner, less popular experience. This can influence the culture of the community, which tends to be more technical and, in some cases, less welcoming to beginners.

The project underwent a significant change in 2020 when its original creator left the team following internal disagreements. Despite this, development continued under the responsibility of other maintainers, and the system remains active, receiving regular updates.

Is it worth using?

The decision to use Void Linux depends directly on the user profile. For those not interested in differences between init systems, C libraries or package managers, the system probably does not offer relevant advantages over more popular alternatives.

On the other hand, users with a technical interest, who value control and understand the inner workings of the system, may find Void an interesting platform. It could also be a viable option for older machines, especially given its lightweight nature and support for 32-bit architecture.

In the current scenario, where Linux is moving towards more automated solutions, with greater use of containers and immutable systems, Void follows a more traditional approach. This does not make it obsolete, but positions it as a specific alternative, aimed at an audience that prefers a greater level of control over the system.

In the end, Void Linux doesn't try to be for everyone. It works well within its own context, serving a specific group of users who know exactly what they are looking for.

Perhaps Void Linux takes user freedom of choice a little more seriously than you'd like. A more reduced and simplified alternative, but one that still provides many choices to the user, is to install Arch Linux using Archinstall.

Date: June 16, 2026

The FreeBSD Release Engineering Team is pleased to announce the availability of FreeBSD 15.1-RELEASE. This is the second release of the stable/15 branch.

Some of the highlights:

  • The iwlwifi(4) and other LinuxKPI based wireless networking drivers are now based on Linux v7.0.

  • FreeBSD cloud images using packaged base systems now include pkg(8), and support automatic base system package updates on first boot.

  • A new kern.sched.name tunable allows the kernel scheduler to be selected at boot time.

  • Significant progress has been made towards complete support for the C23 version of the C programming language.

  • Unicode support has been updated to Unicode 17.0.0 and CLDR 48, adding 4,803 characters.

For a complete list of new features, supported hardware, and known problems, please see the online release notes, hardware compatibility notes, and errata list, available at:

For more information about FreeBSD release engineering activities, please see:

Date: December 2, 2025

The FreeBSD Release Engineering Team is pleased to announce the availability of FreeBSD 15.0-RELEASE. This is the first release of the stable/15 branch.

  • The FreeBSD “base” system can now be installed and managed using the pkg(8) package manager (see “Packaged base system” below).

  • The FreeBSD 15.0 release artifacts (install images, VM images, etc.) were all generated without requiring root privilege.

  • FreeBSD now has a native inotify implementation, simplifying directory watching and software porting.

  • OpenZFS has been upgraded to 2.4.0-rc4.

  • OpenSSL has been upgraded to the latest long-term support (LTS) version, 3.5.4, which includes support for QUIC and now standardized quantum-resistant algorithms, ML-KEM, ML-DSA, and SLH-DSA.

  • OpenSSH has been upgraded to 10.0p2 which includes support for quantum-resistant key agreement by default.

For a complete list of new features, supported hardware, and known problems, please see the online release notes.

https://www.freebsd.org/releases/15.0R/relnotes/

TL;DR * If you need power, flexibility, and universal compatibility → stay with sudo.
* If you prefer lean, mean, and less to go wrong → give doas a spin.
Whichever you pick, remember: the real power isn’t the command you run, it’s the judgment you apply before you hit Enter. Keep experimenting, stay curious, and own your admin choices! 🚀

The Heavyweight: sudo

Aspect Details
History & Adoption Born in the early ’90s, sudo is the de‑facto standard on most Linux distros and BSDs. It’s battle‑tested, heavily audited, and supported by a massive community.
Feature Set Extremely feature‑rich: fine‑grained per‑command permissions, logging, authentication timestamps, SELinux integration, plugin architecture, and more.
Configuration Uses /etc/sudoers (or files under /etc/sudoers.d). The syntax is powerful but can be verbose and tricky; a misplaced comma can lock you out.
Security Model By default, requires the invoking user’s password (or can be set to NOPASSWD). Supports “lecture” warnings, authentication retries, and timestamp caching.
Performance Slightly heavier because it parses a large policy file and forks a helper process. In practice the overhead is negligible for interactive use.
Portability Works everywhere—from tiny embedded devices to massive server farms. Most tutorials assume sudo.

Bottom line: If you need granular control, audit trails, or you’re working in an environment where everyone already knows sudo, stick with it. It’s the Swiss Army knife of privilege escalation.

The Lightweight Challenger: doas

Aspect Details
Origin Developed by OpenBSD as a simpler, safer alternative to sudo. It’s deliberately minimalistic.
Feature Set Stripped down to the essentials: run a command as another user (default root). No per‑command whitelists, no timestamps, no fancy plugins.
Configuration One tiny file: /etc/doas.conf. Syntax is straightforward—think “allow user X to run anything as root”. Example: permit :wheel or permit nopass :wheel.
Security Model By default, requires the invoking user’s password unlessyou specify nopass. Because the codebase is tiny, the attack surface is smaller, which many security‑focused folks love.
Performance Faster startup (les parsing) and a smaller binary (~30 KB). On low‑resource systems the difference is noticeable.
Portability Primarily shipped with OpenBSD, but ports exist for Linux, NetBSD, and a few other *nixes. Not as universally pre‑installed as sudo.

Bottom line: If you crave simplicity, want a tiny, auditable binary, and don’t need the bells and whistles, doas is the sleek, no‑nonsense option. It’s the minimalist’s dream—“just works” for most everyday admin tasks.

When to Choose Which?

Situation Recommended Tool
*Enterprise environments with complex policies sudo (granular ACLs, logging, existing toling)
Security‑hardening where a tiny codebase matters doas (smaller attack surface)
*Systems with limited storage or memory (IoT, containers) doas (tiny footprint)
Cross‑distribution scripts/tutorials sudo (everyone expects it)
*You just want something that “just works” without a manual doas (simple config, less to break)

A Quick Word‑play Wrap‑Up

Think of sudo as the *Swiss watchmaker—complex, precise, and built for every conceivable scenario. doas is the digital watch—clean, lightweight, and gets the job done without the extra gears. Both keep time, but one does it with more flair.

🚀 OpenBSD: Security by default, no sugar‑coating needed.

🔐 Built‑in PF firewall, W^X memory protection, and the legendary pledge()/unveil() sandbox.

🛡️ LibreSSL & OpenSSH were born here—your data stays locked tighter than a vault.

💡 BSD’s permissive license lets you remix, sell, or ship closed‑source products without legal headaches.

Why give BSD a try?

Rock‑solid stability (servers that run for years without reboot).

Clean, readable code—perfect for learning OS internals.

A community that tells it like it is, no fluff.

👉 Ready to experiment? Spin up an OpenBSD VM today and see security the way it was meant to be: default‑on.

#OpenBSD #BSD #CyberSecurity #OpenSource #PrivacyFirst #TechTips

I recently got a threee month trial to try out Kagi. The search engine you pay for. This is weird, but it is actually great. Getting top-notch search results, almost every time. But this post was not about Kagi. It might come at a later date. A smaller write-up below about Kagi.

Alright, let’s cut through the fluff and give you the straight‑up lowdown on Kagi.

What is Kagi?

Kagi is a subscription‑based search engine that markets itself as a privacy‑first alternative to the big‑tech giants. Instead of mining your clicks for ad revenue, you pay a modest monthly fee (around $6–$10 depending on the plan) and get a clean, ad‑free experience where your data stays yours.

Why someone might pick Kagi over Google or Bing:

  • Privacy‑by‑design – Kagi doesn’t track you across the web, store personal identifiers, or build a profile to sell to advertisers. Your search history is encrypted and can be wiped at any time.

  • No ads, no sponsored results – What you see is what you get. No “sponsored” links masquerading as organic results trying to lure you into a purchase you didn’t ask for.

  • Customizable ranking – Users can tweak how results are prioritized (e.g., favor recent content, prioritize certain domains, or boost scholarly sources). It’s a bit like having a personal SEO consultant whispering in your ear.

  • Integrated tools – Kagi bundles a few handy extras: a built‑in summarizer, quick‑look previews, and a “search within results” feature that feels like a Swiss‑army knife for digging deeper without firing off a new query.

  • Speed & relevance – Because it isn’t bogged down by ad‑delivery pipelines, Kagi often returns results faster, and many users report that the top hits feel more on‑point for niche or technical queries.

The trade‑offs:

  • Cost – It’s not free, so you’re paying for the privilege of not being tracked. If you’re comfortable with the ad‑driven model of mainstream engines, the price tag might feel unnecessary.

  • Coverage – While Kagi indexes a huge swath of the web, its index isn’t quite as massive as Google’s. In ultra‑obscure corners of the internet, you might occasionally hit a dead end.

  • Ecosystem lock‑in – Since it’s a paid service, you’re tied to its platform for the duration of your subscription. Switching back to a free engine later means losing any personalized ranking tweaks you set up.

  • Bottom line: If you value privacy, hate ads, and don’t mind shelling out a few bucks for a cleaner, more controllable search experience, Kagi is a solid contender. If you’re happy letting Google sniff around your queries in exchange for free, lightning‑fast results, you probably won’t miss it.

Anyhow, I started contributing to Kagi as a translater.

  • Kagi Search – Kagi is a subscription‑based search engine that markets itself as a privacy‑first alternative to the big‑tech giants.

EOF

The BSD operating systems occupy a unique niche in the Unix landscape. They are not simply “alternatives to Linux.” They are coherent operating systems built from a single source tree, designed under unified standards, and engineered with long-term maintainability in mind. OpenBSD, in particular, shows how disciplined engineering can shape a kernel and userland that behave predictably even under demanding conditions.

Kernel Structure and Internal Mechanics

The BSD kernels follow a monolithic-but-modular architecture. Subsystems such as the virtual memory system, network stack, filesystem layers, and device drivers operate within a shared address space but remain cleanly separated through strict internal interfaces.

OpenBSD’s virtual memory system is a refined implementation of NetBSD’s UVM. Over the years, the OpenBSD team has removed undefined behavior, tightened boundary checks, and simplified internal paths. The kernel’s malloc(9) allocator uses randomized allocation patterns, guard pages, and strict size verification to prevent memory corruption and use-after-free attacks.

Interrupt handling is intentionally conservative. OpenBSD avoids complex interrupt-threading mechanisms, prioritizing clarity and auditability over maximum parallel throughput. This results in a predictable and transparent CPU interrupt model.

Filesystems and I/O Strategy

OpenBSD primarily relies on the Fast File System (FFS) with soft updates journaling. While this may appear minimalistic compared to advanced filesystems like ZFS, the decision reflects OpenBSD’s preference for correctness and simplicity. A simpler filesystem is easier to audit, less error-prone, and reduces the probability of kernel-level memory vulnerabilities.

FreeBSD takes a different approach. Its ZFS integration includes ARC caching, snapshots, send/receive replication, and robust error correction. The contrast illustrates how BSD variants follow their own philosophies—OpenBSD favors a tight core, while FreeBSD embraces feature-rich solutions for large-scale deployments.

Networking: Architecture and Implementation Nuance

Networking is where BSDs have historically excelled.

OpenBSD’s Packet Filter (PF) is integrated deeply into the network stack. It offers a concise rule syntax, stateful inspection, normalization, and traffic shaping. The state table forms the heart of PF’s performance design, and OpenBSD developers continuously refine it to avoid bottlenecks during connection surges such as SYN floods.

The ARP and IPv6 neighbor discovery subsystems have undergone substantial rewrites to eliminate unsafe patterns and ensure full protocol compliance.

FreeBSD, on the other hand, pushes raw networking performance. With advanced TCP algorithms like RACK and high-throughput NIC drivers, it can saturate modern 40–100 Gbit environments. NUMA-aware design in both VM and networking layers gives it a significant edge in multi-socket server systems.

Syscall Layer and Userland Integration

BSD systems treat the syscall interface with long-term stability in mind. ABI-breaking changes are avoided unless absolutely necessary, and compatibility layers remain in place for years. This cautious evolution makes BSD systems reliable platforms for embedded appliances, firewalls, and long-lived servers.

OpenBSD’s userland and kernel form a unified ecosystem. System daemons like bgpd(8), iked(8), and relayd(8) use kernel-enforced restrictions such as: • pledge(2) — syscall whitelisting • unveil(2) — selective filesystem visibility • Privilege separation — splitting processes into minimal-privilege components

These are not retrofitted security additions; they are deeply integrated into the OS design.

Development Culture and Codebase Integrity

The culture of BSD development is its strongest asset.

OpenBSD emphasizes readable, consistent code. Developers avoid layering abstractions for convenience; instead they refactor aggressively to maintain clarity. Kernel APIs deprecated for internal reasons are removed only after a staged transition, preserving system stability.

The unified base system model means kernel, libraries, and core userland utilities evolve together. There is no fragmentation between upstream, distributors, and packagers. The result is a system where decisions flow smoothly from architectural principle to implementation.

Closing Perspective

BSD systems excel not by chasing trends but by adhering to coherent internal philosophies. • OpenBSD focuses on correctness and proactive security. • FreeBSD pursues performance, scalability, and advanced features. • NetBSD pushes portability and clean architecture across countless platforms.

Exploring BSD means stepping into an operating system lineage where clarity and long-term stability guide every subsystem. In a world of ever-increasing complexity, the BSD approach shows that disciplined engineering still produces systems that are secure, maintainable, and built to endure.

Today is a good day because I have been using gnu+linux for 27 years. And BSD for about 10 years.

The first encounter I had with the linux kernel and the underlying os, was in 1998. A friend of mine and our computer science teacher. The teacher also had an interesting idea. We got a desktop computer to play around with. I had got an installation disc from a store (if I remember correctly). The disc included Redhat version 5.1 codenamed “Manhattan”, long before Redhat became RHEL (Red Hat Enterprise Linux) and I also got this very thick booklet.

I just dug around in my old notes and found more #opensource projects I have been translating through the years. And the following came to mind:

  • Ente Auth – Open source 2FA authenticator, with end-to-end encrypted backups
  • Ente Photos – Safe home for your photos. End-to-end encrypted. Cross-platform. Open-source.
  • Session – Session is a private messaging app that protects your metadata, encrypts your communications, and makes sure your messaging activities leave no digital trail behind.
  • Bitwarden – This does not require a description right?
  • Mastodon for iOS – Social networking that's not for sale. Part of the fediverse.
  • FairEmail[inactive] Android app – not updating this translation because of previous post.

I might have translated even more, but this was what I found today.

EOF

Enter your email to subscribe to updates.