jpnt

Curriculum Vitae

2026-10-07T00:00:00+00:00

Architecture

2025-12-23T00:00:00+00:00

No problem, no requirements.
No requirements, no use cases.
No use cases, no logical boundaries.
No logical boundaries, no architecture.
No architecture, no efficient solution.
No efficient solution, the system falls apart.

What is architecture?

Software architecture is how you organize a system so it can change safely and meet its goals. That’s it.

Most writing on architecture falls into two extremes. Either it’s abstract frameworks with diagrams that obscure more than they clarify. Or it’s “just build it bro” with no structure at all, leaving you to figure things out as you go. Both fail when the system needs to evolve.

Architecture must reduce the cost of future change. It must keep coupling under control so modifying one part doesn’t break everything else. It must make failure predictable and deployments safe.

Where to start: Requirements and use cases

Start here. Not with diagrams. Not with layers. Start with what the system is supposed to do.

Requirements define the problem. Use cases show how actors interact with the system to accomplish goals. An actor can be a user, an external system, a scheduled job - anything that triggers behavior.

If you skip this, you’re building based on guesses. Requirements and use cases ground everything in reality.

Functionalities: What does the system need to do?

Once you know the requirements and use cases, list the functionalities. These are the things the system must actually do.

For a web service that processes orders, functionalities might be:

Accept HTTP requests
Validate input
Check inventory
Calculate pricing
Process payment
Update database
Send confirmation email
Return response

Don’t organize these yet. Just list them. Get them out of your head and into writing. This is the “what.”

Logical boundaries: Who does what?

Now group functionalities into logical boundaries. A boundary is a responsibility assignment. Which functionalities belong together? Which should be separate?

The key question: who does what?

For the order processing service:

HTTP Handler: accept requests, return responses
Core Logic: validate input, check inventory, calculate pricing
Database Client: update database
Payment Service: process payment
Email Service: send confirmation email

Each boundary has a job. Boundaries should be cohesive - related things stay together. They should minimize coupling - a boundary shouldn’t need to know about internals of other boundaries.

This is where diagrams help. Draw boxes and arrows. Show who talks to whom. Not for documentation, but to see if your boundaries make sense. If the diagram is a mess, your thinking is a mess.

Development: Organizing the code

Now translate boundaries into code. Modules, components, subsystems - these are different granularity levels of the same concept. A module is a small unit of code. A subsystem is a collection of modules. An API is the interface between them.

What matters is that each logical boundary has a home in the codebase.

Each boundary should have:

A clear interface
Internal implementation hidden
Minimal surface area
Stable contract

Deep modules are better than shallow ones. A deep module does a lot behind a small interface. open(), read(), write(), close() is the classic example. Shallow modules expose internal complexity and force you to understand it.

The UNIX generalization principle exemplifies deep abstraction. “Everything is a file” reduces diverse operations—disk, network, terminals, pipes—to a unified interface. This hides substantial complexity behind a minimal surface, enabling composition and reducing cognitive load. A shallow alternative would expose separate APIs for each resource type, increasing complexity and reducing composability.

Dependencies should flow one way. If A depends on B, B shouldn’t depend on A. Cycles are coupling traps.

How you organize the code depends on use cases and requirements.

Deployment: How does it run

Architecture isn’t just code structure. It’s also how the system runs in reality.

Single process. Multi-threaded. Multi-process. Distributed. Each adds complexity. Each adds capability.

Start simple. A single process with a thread pool is enough for most small to medium services. Add processes or services only when you have a clear reason: isolation, independent scaling, different deployment cycles.

Distributed systems are an order of magnitude harder. Don’t go there until you have to.

Diagrams are tools, not architecture

MBSE (Model-Based Systems Engineering) has a lot of formalism. Activity diagrams. Internal block diagrams. Sequence diagrams. State machines. Some of this is useful. Most is overkill.

What’s useful:

Understanding the system
Seeing communication paths
Identifying actors and use cases
Exploring logical boundaries
Checking if your design makes sense

What’s not useful:

Treating diagrams as the deliverable
Formalism for its own sake
Every possible diagram type
Analysis paralysis

Draw diagrams to think. Then write code.

What Lisp taught me

When I discovered Lisp it changed how I think about systems for the better.

Lisp has code-as-data. Your code is a data structure you can manipulate. Macros let you extend the language itself. You’re not stuck with what the language gives you - you can adapt it to your problem.

This made me realize: rigid architectures exist because languages are rigid. If you can shape the language to your domain, boundaries become more fluid. You can build DSLs that express your problem directly.

I’m not saying “rewrite everything in Lisp.” I’m saying: the right abstraction level makes architecture simpler. Sometimes that’s a module. Sometimes that’s a language feature. Sometimes that’s a DSL.

Risk-driven design

How much design upfront? Risk-driven architecture says: design enough to address the main risks, then start building.

Big Design Up Front is waste. No design at all is technical debt. The middle ground is “just enough.”

Just enough means:

Requirements are clear
Use cases are defined
Functionalities are listed
Logical boundaries make sense
Major risks are addressed

Then build. Adjust as you learn.

Proof of Concepts: Build to understand

Don’t design everything in your head. Build small, throwaway versions to validate assumptions.

PoCs answer questions: Is this approach feasible? Does this library work as advertised? Is this performance achievable? Do these boundaries actually make sense?

Get something working first. A single process. A simple version. Understand the problem by solving it poorly, then refine.

Design decisions that look good on paper often break in reality. PoCs reveal the truth before you commit.

Work in sprints. Focus on one PoC per sprint. Validate assumptions, get feedback, iterate. Don’t spend months designing. Build, measure, learn. Adjust architecture based on what you discover.

Trade-offs: Multiple solutions exist

For any architectural problem, there are multiple valid solutions. Single process vs multi-process. SQL vs NoSQL. Monolith vs microservices. Sync vs async.

The question isn’t “which is best?” The question is “what are the trade-offs?”

Build a trade-off matrix. List options. Identify criteria: complexity, performance, operational cost, team capability, time to market. Score each option. Make the trade-offs explicit.

No solution is free. Every choice has costs. Architecture is about choosing which costs you’re willing to pay.

REST! Take breaks

When your brain is tired, it’s impossible to discern good solutions from bad ones.

Architecture requires clear thinking. If you’re stuck, step away. Sleep on it. Go for a walk. Come back fresh.

The best architecture insights often come when you’re not staring at the problem.

Books that helped

Design It! by Michael Keeling taught me collaborative design and risk-driven architecture. Architecture isn’t a solo activity. It presents as a survey a lot of material I’ve learned through the years in a concise manner.

Release It! by Michael Nygard taught me that production reality is harsh. Circuit breakers, bulkheads, timeouts, these are not an after thought. Your software will be under attack from the moment you deploy.

A Philosophy of Software Design by John Ousterhout taught me about deep modules and complexity hiding.

The Art of UNIX Programming taught me a lot about the great ideas from the creators of Unix.

Designing Data-Intensive Applications by Martin Kleppmann taught me about reliability and trade-offs in data systems.

The paradox I lived in

I spent a lot of time confused. MBSE says to model everything with diagrams. Pragmatic programmers say to just build. Lisp showed me that flexibility comes from the right tools, not more diagrams.

Here’s what I’ve landed on:

Requirements and use cases are non-negotiable
Functionalities come first, then boundaries
Diagrams help you think, they’re not the architecture
How you organize code depends on the problem
Simple systems deserve simple architectures
Add complexity only when needed

Architecture is not a framework. It’s not a diagram. It’s how you organize decisions so the system can evolve without falling apart.

Start with requirements. Define functionalities. Draw boundaries. Write code. Deploy. Iterate.

Keep it simple. Ship it.

SSH Configuration

2024-12-29T00:00:00+00:00

Introduction

The Secure Shell (SSH) protocol is a cryptographic network protocol designed for secure communication over an unsecured network. It is widely used for remote login and command-line execution, replacing older, insecure protocols like Telnet and rsh. This guide will explain how to configure SSH and manage keys.

How To Use SSH Keys

SSH key-based authentication is more secure and convenient than passwords. The client creates a private key and sends a public key to the server.

Create a Key Pair on the Client

Run the following command to generate a new SSH key pair:

$ ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519 -C "your_email@example.com"

This will create two files:

id_ed25519: The private key (keep this secure!)
id_ed25519.pub: The public key

Copy Public Key to the Server

Use the ssh-copy-id tool to copy your public key to the server:

$ ssh-copy-id -i ~/.ssh/id_ed25519.pub user@127.0.2.1

Alternatively, manually append the public key to the server’s ~/.ssh/authorized_keys file:

$ cat ~/.ssh/id_ed25519.pub >> ~/.ssh/authorized_keys
$ chmod 600 ~/.ssh/authorized_keys

Start the SSH Authentication Agent

Start the agent to manage your keys:

$ eval $(ssh-agent -s)

Add Your Private Key to the Agent

Load your private key into the SSH agent:

$ ssh-add ~/.ssh/id_ed25519

Verify that the key has been added:

$ ssh-add -l

SSH Daemon (sshd) Configuration File

The SSH daemon settings can be fully configured through its file located at /etc/ssh/sshd_config. Open it with a text editor:

# vi /etc/ssh/sshd_config

Recommended settings:

PermitRootLogin no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no

After modifying the configuration, restart the SSH daemon to apply changes.

If you are using systemd, use:

# systemctl restart sshd

Verify SSH Connection

After setting up your keys and configuration, test your connection to the server:

$ ssh user@server_ip

Troubleshooting Common Issues

Permissions Errors

Ensure the following permissions on your SSH-related files:

$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/id_rsa
$ chmod 644 ~/.ssh/id_rsa.pub

Debugging Connection Issues

Use verbose mode to diagnose issues:

$ ssh -vvv user@server_ip

CPU Cache

2024-10-28T00:00:00+00:00

What is CPU cache

CPU cache is a small but high-speed memory located on or near the processor core. It is designed to store frequently accessed data and instructions, allowing the CPU to retrieve them far more quickly than from the main memory. Modern CPUs have multiple levels of cache (L1, L2, and L3), each balancing size and speed to optimize data access speed and overall system performance.

Why CPU cache

The main purpose of CPU cache is to reduce the time it takes for the CPU to retrieve data from main memory by storing recently or frequently accessed data closer to the CPU. Since cache memory is significantly faster than main memory, using cache reduces the latency associated with memory access. This reduction in latency boosts the CPU’s ability to process instructions efficiently, minimizing bottlenecks that arise due to slower main memory access speeds.

The memory hierarchy

Memory hierarchy refers to the structured arrangement of storage within a computer system, organized by speed, size, and cost.

The hierarchy goes as follows (from fastest to slowest):

Registers
- Fastest and smallest storage located within the CPU
L1i/d, L2 and L3 Cache
- Multi-level caches that provide fast access to frequently used data. L1 being the fastest and L3 the slowest.
Main memory (RAM)
- Larger but slower memory used to store data and instructions currently in use by the system.
Longterm storage (Flash, Spinning disk)
- Non-volatile storage that holds data long-term, access is slower compared to RAM.
Remote storage (Internet)
- Usually slower than secondary storage due to the latency caused by the overhead of the communications between computers.

So, cache memory sits between the CPU and the main memory, serving as a fast buffer that stores copies of frequently accessed intructions and data, thus reducing the time it takes for the CPU to retrieve data.

Before CPU cache

Before the introduction of CPU caches, processors had to fetch data directly from main memory for every operation. This process was slow and inefficient due to the significant speed difference between the CPU and main memory. As CPU speeds increased this disparity became more pronounced leading to performance bottlenecks.

Comparison of speed

Here’s a comparison of typical access times across different levels of the memory hierarchy, note that this values are hardware dependant so this is just to give a general idea:

Memory Type	Access Time	N cycles
Registers	0.2 - 1 ns	1 cycle
L1 cache	0.5 - 3 ns	1 - 3 cycles
L2 cache	5 - 20 ns	15 - 60 cycles
L3 cache	10 - 40 ns	30 - 120 cycles
Main memory (DRAM)	50 - 100 ns	150 - 300 cycles
Solid-State drive	10 - 100 μs	30,000 - 300,000 cycles
Hard-Disk drive	5 - 20 ms	15,000,000 - 60,000,000 cycles

Cache memory provides much faster access times compared to main memory, which is why it is crucial for reducing latency and improving the performance of the CPU.

How CPU cache works

Cache lines, cache hits and misses

CPU cache operates by storing copies of data from frequently accessed main memory locations. When the CPU needs to access data, it first checks whether the data is available in the cache. If the data is found (cache hit), it is returned quickly. If the data is not found (cache miss), the CPU must fetch the data from the slower main memory.

Modern CPUs don’t just fetch the exact data needed for a particular instruction when accessing memory. Instead, they fetch an entire cache line.

A cache line is a contiguous block of memory, typically ranging from 32 to 128 bytes in size, depending on the processor’s architecture. The idea is that when one piece of data is accessed, the data adjacent to it is also likely to be accessed soon (this is known as spatial locality).

By fetching the entire cache line, the CPU increases the chances of future accesses resulting in cache hits, thereby reducing the need for further memory accesses.

For example, when accessing an element of an array, it is highly probable that nearby elements will also be accessed shortly. By loading the entire cache line, the CPU can serve future requests directly from the cache, which significantly speeds up data retrieval.

This strategy enhances the overall efficiency of the cache system by reducing the number of cache misses, particularly the compulsory misses (those that occur the first time a data item is accessed).

Cache temporal locality and spatial locality

Cache performance is heavily influenced by the principles of temporal locality and spatial locality:

Temporal Locality: recently accessed data is likely to be accessed again soon. Caches take advantage of temporal locality by storing recently accessed data, anticipating that the CPU will need it again.

Spatial Locality: data located near recently accessed data is likely to be accessed soon. Caches utilize spatial locality by storing blocks of data that include the requested information and adjacent memory addresses.

The 3 C’s of cache misses

Cache misses can be categorized into three types, known as the 3 C’s:

Compulsory Misses: when data is accessed for the first time and must be loaded into the cache.
Capacity Misses: when the cache is too small to hold all the data required by the CPU, leading to some data being evicted and causing misses.
Conflict Misses: these occur in set-associative or direct-mapped caches when multiple data items compete for the same cache line, leading to evictions and misses

Replacement Algorithms

When the cache is full, something has to be trashed to make room for new data. The choice depends on which replacement algorithm is used:

FIFO: The oldest data gets replaced. Not very good.
LRU: The data that hasn’t been used for the longest time gets replaced. Most commonly used in multitasking environments.
LFU: The least accessed data gets replaced. Can be useful in some embedded scenarios where a computer is frequently doing something.
Random: A random block is replaced, which is the simplest and cheaper to implement.

CPU Cache Address and Tag

The cache address and tag system is used to quickly determine whether the data the CPU needs is available (or not) in the cache. This process is fundamental to how caches operate, and it works differently depending on the type of cache organization algorithm (fully associative, direct mapped, or set-associative).

Fully Associative vs Direct Mapped vs Set-Associative Cache

There are three main algorithms that determine how data is stored and retrieved:

Fully Associative Cache

How it works: Any memory block can be stored in any cache line, giving maximum flexibility in placement.
Tag Comparison: The CPU compares the tag in every cache line to find a match, making this process complex and costly.
Use Case: Used in small caches where flexibility and avoiding misses is more important than cost.

Direct Mapped Cache

How it works: Each memory block has only one possible location in the cache, determined by a part of its address.
Tag Comparison: The CPU only checks the tag for that specific line, making comparison simple and fast.
Drawback (Trashing): Frequent evictions can occur if multiple memory blocks map to the same line, reducing performance.
Use Case: Cost-effective design, useful for simpler systems.

Set-Associative Cache

How it works: Cache is divided into “sets.” Each block of memory can be stored in any line within a designated set.
Tag Comparison: The CPU checks tags of all lines in a set, providing flexibility with moderate complexity.
Use Case: Most common in modern CPUs as it balances cost and performance.

NOTE: At the hardware level, cache misses can be reduced by changing capacity, block size, and/or N-set associativity.

CPU Cache Flag Bits

Flag bits are used in each cache line to track the status of the data:

Valid Bit: Indicates if the data in the cache line is valid (usable).
Dirty Bit: Shows if the data has been modified. If dirty, it needs to be written back to memory before replacement.
LRU Bit(s): Used in caches with replacement policies to track the “least recently used” line, helping decide which data to evict when new data comes in.

Cache Write Policies

A cache write policy defines how data is written to the main memory once it is written to the cache.

Write-Through: Data is written to both the cache and main memory at the same time. This is simple and ensures consistency but can be slower.
Write-Back: Data is written to the cache only and written to memory later, when it’s replaced. This is faster but needs the dirty bit to ensure modified data is written back.

Unified vs Split Caches

Unified Cache: Stores both instructions and data. This is more space-efficient but can lead to contention if instructions and data are frequently needed at the same time.
Split Cache: Divides L1 cache into separate caches for instructions and data (L1i and L1d). This speeds up access by reducing contention but requires more cache space.

Overview: Data Structure Alignment

Aligned data means data is stored at memory addresses that match its size (e.g., 4-byte integer at an address divisible by 4). Proper alignment speeds up access and reduces cache misses because misaligned data might span multiple cache lines, increasing access time.

Overview: Virtual Memory Effect on CPU Cache

Virtual memory uses addresses mapped to physical memory, which can affect cache efficiency due to aliasing (where different virtual addresses refer to the same physical address). Techniques like TLBs (Translation Lookaside Buffers) and page coloring help manage this by keeping virtual memory organized and reducing unnecessary cache invalidations.

Overview: CPU Pipelining Effect on CPU Cache

In pipelined CPUs, each instruction phase (fetch, decode, execute) happens in parallel. If there’s a cache miss, it can stall the pipeline, slowing down all stages.

Non-blocking caches help reduce stalls by allowing the pipeline to continue executing while fetching from memory.

Overview: CPU Branch Preduction correlation with CPU Cache

Branch prediction can lead to cache pollution if predictions are incorrect. When the CPU loads instructions based on a predicted path that turns out to be wrong, it wastes cache space, potentially evicting useful data.

Prefetching only high-confidence branches can help reduce this effect.

Example: E31 Core with FreeRTOS Data Structures:

In the SiFive E31 core running FreeRTOS, the operating system frequently accesses task control blocks (TCBs). When multiple tasks are running, frequently accessed TCBs stay in the cache, improving task-switching speed.

Using small, aligned TCB structures ensures fewer cache misses and better cache utilization.

References

Harris, S. L., & Harris, D. M. (2021). Digital design and computer architecture: RISC-V edition. Morgan Kaufmann.
Patterson, D. A., & Waterman, A. (2020). Computer organization and design RISC-V edition: The hardware software interface (2nd ed.). Morgan Kaufmann.
Hennessy, J. L., & Patterson, D. A. (2017). Computer architecture: A quantitative approach (6th ed.). Morgan Kaufmann.

Linux Audio Guide

2024-08-18T00:00:00+00:00

Understanding Current Audio Solutions

There are three commonly discussed audio abstraction layers in Linux:

Pulseaudio

Created as a modern replacement for Enlightenment Sound Daemon (ESD), it provides advanced features like per-application volume control and network audio streaming.

Jack

Designed as a professional audio server for Linux, it offers low-latency audio processing and precise control over audio inputs and outputs, making it suitable for professional audio work.

Pipewire

The newest abstraction layer, Pipewire integrates seamlessly with both Pulseaudio and Jack.

Understanding the Stack

Kernel layer

The kernel layer provides hardware abstraction. Advanced Linux Sound Architecture (ALSA) is the primary component that interacts with sound cards and manages communication, replacing the older Open Sound System (OSS). Thus, all three abstraction layers previously refered must communicate with ALSA.

Middleware/Backend layer

ALSA Library (libasound): Provides a userspace interface to interact with ALSA.

Problem: ALSA is specific to Linux. What about other operating systems?

Solution: The need for cross-platform support led to the creation of sound servers like Pulseaudio, which works on UNIX like operating systems and even on Windows.

So which one do I use?

You might be asking if you really need sound servers/abtraction layers over ALSA to get audio working on Linux. The short answer is: no. The correct answer is: you should use a sound server (spoiler: PipeWire).

End users can directly use ALSA if they wish and even have pseudo-pulseaudio emulation with apulse software.

But, and this is according to my personal experience, it is highly recommended that you use a sound server, specifically PipeWire and I will explain you why.

By default, ALSA comes with a very poor configuration, and does not (by default) support mixing of multiple streams. You can configure ALSA with various plugins that enable this feature such as dmix, dsnoop, etc.

It is a very tiresome thing to do because even if you apparently configure things properly you will always come accross some problem sooner or later.

Pulseaudio does one thing well: it sets a nice ALSA configuration by default, using its own plugin called pulse, which has multiple stream mixing without having to configure a single thing.

However (and once again I will speak from experience) when you start doing more things such as bluetooth audio or want to re-route audio you will find yourself stuck with pulseaudio, because when it was initally designed it did not prioritize these things. If one wanted to do professional audio, one had to install JACK most likely with pulseaudio already installed, this was a mess.

PipeWire

PipeWire aims to replace both PulseAudio and JACK by providing a unified solution for audio and video handling.

It provides a handful of benefits such as:

ALSA, PulseAudio and JACK compatibility
Low-latency audio
Simplified setup
Bluetooth audio support
Modular architecture

Therefore, if you want the best possible audio experience on Linux, install PipeWire.

PipeWire prerequisites

PipeWire requires three things to work properly:

D-Bus user session bus

for inter-process communication and session management

XDG_RUNTIME_DIR environment variable

for creating a runtime directory to store temporary files and session-specific data

Pipewire session and policy manager

wireplumber is the most commonly used

NOTE: If your DE/WM/Wayland compositor is not configured to provide a D-Bus user session bus, you have two options: run a dbus session alongside it

# .xinitrc
exec dbus-run-session mywm

or enable the dbus.socket/dbus-broker.service user service (preferred if your init provides one, e.g. systemd or runit) so the session bus is always available regardless of how you start your WM/compositor.

NOTE: To set XDG_RUNTIME_DIR manually you may paste the following in your .profile:

# .profile
if [ -z "$XDG_RUNTIME_DIR" ]; then
	XDG_RUNTIME_DIR="/tmp/$(id -u)-runtime-dir"
	mkdir -pm 0700 "$XDG_RUNTIME_DIR"
	export XDG_RUNTIME_DIR
fi

PipeWire setup

Install pipewire and a PipeWire session manager wireplumber. Additionally, I recommend installing alsa-pipewire to synchronize ALSA audio control with PipeWire’s.

PipeWire runs as user services, not system services. You need to enable and start 3 of them: pipewire, pipewire-pulse (the PulseAudio compatibility layer) and wireplumber (the session/policy manager).

If you are using systemd, use:

$ systemctl --user enable --now pipewire pipewire-pulse wireplumber

Bluetooth

Install bluez and enable bluetoothd to get access to bluetoothctl and other utilities, PipeWire bluetooth support is built-in and works really well in my experience, with full support for LDAC (A2DP sink) for my Sony WH-1000XM4.

Resources

https://docs.voidlinux.org/config/media/pipewire.html
https://wiki.archlinux.org/title/PipeWire
https://docs.voidlinux.org/config/bluetooth.html
https://wiki.archlinux.org/title/Bluetooth
https://pipewire.org/

inici(os)

2024-06-02T00:00:00+00:00

Introduction: The Problem

The growing complexity and size of modern software is a significant issue, which I have discussed previously in “Modern Software is a disaster”.

Today, software tends to be bloated, with enormous and complex codebases that can consist of tens of millions of lines of code and intricate dependency trees, often just to perform simple tasks.

It wasn’t always like this. In the past, when computers had limited processing power, developers had less freedom and were compelled to solve problems in more efficient ways.

Modern Software Design

Modern software design is fundamentally flawed. Theories such as Object-Oriented Design and Domain-Driven Design often fail in practice because they do not align with how computers actually work. The domain should be the memory, and the design should focus on code and data structures.

These theories often introduce new problems, including maintainability issues, poor performance, lack of security, and degraded user experience.

Kernel Design: Drivers

Whether developing monolithic or microkernels, much of the focus seems to be on driver development rather than actual innovation.

When something doesn’t work, the solution is often to write a new driver. This approach creates a bottomless pit of complexity, as there will always be new hardware to support, leading to more and more lines of code.

Rationale: How to Solve it

Proper Design: Bottom-up Approach

Many developers have the mindset of adding layers on top of existing systems to fix problems. This approach is not inherently wrong but cannot be applied universally.

An analogy is when something breaks, you have two choices: patch it up with duct tape and hope it holds (and add more tape if it doesn’t), or evaluate why it broke in the first place. Maybe the materials were unsuitable, or it was used incorrectly. We might need to create a new component to handle the task properly.

While this may seem simplistic, it illustrates that modern software often uses tools that are not ideal for the job, leading to suboptimal solutions.

To effectively solve these issues, we must evaluate our choices from the ground up, avoiding unnecessary bloat.

If “A” does “X” better than “B”, use “A”

This principle is self-explanatory: we should use the best tool for the job. By doing so, productivity is increased, and we avoid relying on multiple suboptimal software projects.

For example, if I want to display the contents of a file, I should use the best tool available for that task. The same applies to editing a file, etc.

Keeping It Stupid Simple (KISS)

A key principle in writing good software is to keep it simple. We should always seek the simplest way to achieve our goals. The philophy is: “if something can be simplified, it will get simplied”.

This principle applies to both the design and implementation stages. For example, instead of performing extensive computations, we might pre-calculate and store data for quick access.

It’s also crucial to stay focused when developing a feature and avoid adding unnecessary functionalities. This aligns with the original UNIX design principles.

How Many LOC Does It Take to Do “X”

Another important consideration is achieving functionality with the fewest lines of code possible, without sacrificing readability or performance.

OS Specific

These design philosophies still apply to other software, but here I am talking specifically about Operating Systems.

Bare-Bones Bootloader

Avoid multi-stage bootloaders and complex boot protocols (unless absolutely necessary).

No initial ram disk or anything similar. The goal is to boot as fast as possible with as less drag as possible.

Modular Design

This principle tells us to break the problem down in well-defined, independent modules each with a single responsability and communicate through simple and well-defined interfaces.

We need to separate the kernel, filesystem, multitasking, hardware interaction, etc. Set as a goal: a ridiculous low amount of lines of code to do “X”. The less you write, the better (without sacrificing performance, of course).

Zero Drivers

As previously mentioned, drivers are a major source of complexity in modern operating systems. We could look to embedded systems for inspiration on how to build an OS with zero drivers.

“Restrictive” multitasking

Multitasking is not inherently bad, but modern operating systems often run too many tasks simultaneously. For a consumer/desktop OS, I might only want to run 2 or 3 tasks at a time. This allows us to simplify the pre-emptive multitasking algorithm while still supporting multiple tasks when necessary.

Different OS for different purposes

I don’t want a general-purpose OS; I want an OS tailored to my specific use case. For example, if I’m using it on a desktop, I don’t need it to function as a server OS. This specialization simplifies the entire OS stack.

Small OS layer

The OS layer should be as minimal as possible. While POSIX provides a standard interface, it may be too large for what I intend.

Only the essential features should be implemented in the kernel and non essential features should be moved to userspace. In theory this simplifies kernel development and improves security (which may be irrelevant considering other design choices).

Use static linking for the kernel to avoid the complexity associated with dynamically linking a kernel.

Single User

Focus on single-user environment. This provides a great oportunity to simplify security and permission models.

Conclusion: thoughts and moving forward

ARM and RISC-V: a new oportunity

With the advent of new ARM SoCs and RISC-V processors, there is a tremendous opportunity to apply these principles and develop more efficient operating systems.

If I am aiming for “zero drivers”, my OS will be dependant on a specific computer, which immediately removes thousands of esoteric hardware written in the kernel.

If then a user wants to communicate with other external hardware, more software will be developed; I dont consider it a “driver” simply because it wont be written at the kernel space but instead at the user space.

“But what does that solve?” You ask. Well, by writing this external modules outside of the kernel to communicate with your hardware it means the kernel will always remain slim with no extra driver bloat you dont need.