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.

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.

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

I have been translating different #opensource apps for years. It all started with Proton Mail back in the days when it was released.

Later I translated Tusky – the mastodon app for Android. Later I moved to the iPhone platform and stopped supporting the Android platform. I really can’t count the different translations I made, so I will just list the most recent,

• Openvibe – the cross platform app.
• Vivaldi – the browser born in Norway.
• Proton Mail, the privacy focused email service from Switzerland.

What Makes Slackware Different?

BDFL Model: Patrick Volkerding is still the main decision-maker.

Slackware doesn't follow a strict release cycle; releases happen when they're ready.

Conservative Software Choices: Slackware favors well-tested software over the latest trends. Example: PAM and elogind were adopted only in version 15.0.

Simplicity Over Ease:

• Not necessarily user-friendly, but internally simple.
• Avoids unnecessary complexity, making it robust and reliable.

No Automatic Dependency Management:

• Installs the whole system by default to satisfy dependencies.
• Avoids problems common with dependency-resolution tools in other distros.

Plain Bash-Based Package Management:

• Uses simple tools like installpkg, removepkg, etc.
• Packages are .txz tarballs.
• Information about installed/removed packages is kept in plain text under. /var/lib/pkgtools

Vanilla Packages:

• Software is built as-is from upstream, with headers and documentation intact.

Customization and Community

SlackBuilds:

• Every Slackware package comes with a build script (.SlackBuild) that users can modify.
• Encourages local compilation and customization.
• Third-party SlackBuilds are available from slackbuilds.org.

Minimalism and User Responsibility:

• Puts power and responsibility in the hands of the system administrator.
• Assumes knowledge of /etc config files and CLI usage.

No systemd:

• Maintains traditional init systems.
• Avoids opaque management layers.

EOF

If the fzf-package fails ensure that you have go-lang and relog to make sure that /etc/profile.d/go.sh gets loaded.