DEV Community: Yassir El bakkari

Born2beRoot

Yassir El bakkari — Tue, 14 Apr 2026 07:20:55 +0000

introduction

Born2beRoot is a system administration project. In this project, we learn how to create and manage a virtual machine. We use tool VirtualBox to install an operating system.

The goal of this project is to understand how a server works. We learn how to secure the system, manage users, and control services. We also learn how to use the terminal instead of a graphical interface.

This project helps us understand the basics of Linux systems. It teaches us how to work step by step, follow rules, and solve problems by ourselves.

Virtual Machine (VM)

A Virtual Machine (VM) is like a computer inside your computer.
Now let's see Virtual Machine (VM)
First, your real computer has hardware:

CPU (processor)
RAM (memory)
Disk (storage) On top of this hardware, you install a program like VirtualBox. This program is called a hypervisor.

what is hypervisor ?
A hypervisor (or Virtual Machine Monitor, VMM) is software that lets multiple operating systems run on a single physical machine. It manages hardware resources (CPU, memory, storage) and allocates them to virtual machines (VMs) without interference. This improves hardware utilization, reduces costs, and provides flexibility in cloud and server environments.

How It Works ?
A hypervisor runs on hardware or a host OS to create and manage virtual machines (VMs), each with its own virtual CPU, memory, storage, and network. It intercepts guest OS requests and translates them to physical hardware, ensuring isolation, security, and stability.
The source👈🏻

Types of Hypervisor:

Type 1 Hypervisor:

A Type 1 hypervisor runs directly on the host's hardware. It doesn't rely on a host operating system. This architecture offers better performance and security because there is no intermediary OS. It's the standard for enterprise-level data centers and cloud providers like Amazon Web Services (AWS) and Microsoft Azure.

Examples: VMware ESXi, Microsoft Hyper-V, KVM (Kernel-based Virtual Machine), and Xen.

Pros:

High performance (direct hardware access).

Strong security (no intermediate OS layer).

Suitable for mission-critical workloads.

Cons:

Requires dedicated hardware.

Setup and management are complex compared to Type-2.

2. Type 2 Hypervisor

A Type 2 hypervisor runs on top of a conventional operating system (like Windows, macOS, or Linux). It's essentially an application within the host OS. This type is generally used for desktop virtualization, development, and testing environments where a user needs to run multiple OSs on their personal computer. Performance is slightly lower than Type 1 due to the overhead of the host OS.

Examples: Oracle VM VirtualBox, VMware Workstation, and Parallels Desktop.

Pros:

Easy to install and use.

Useful for development, testing, and malware analysis.

Provides good host–guest integration features.

Cons:

Slower performance (no direct hardware access).

Security depends on the host OS; compromise of host may affect guests.

The hypervisor acts like a manager.

When you create a virtual machine:

It takes a part of your real CPU

It takes a part of your RAM

It creates a virtual disk (a file on your real disk) Now, inside this virtual machine, you install an operating system like Debian.

The virtual machine thinks it is a real computer.
But in reality:

The CPU is not real → it is shared from your real CPU

The RAM is not real → it is just a reserved part of your RAM

The disk is just a file

When the VM runs:

The OS inside the VM sends instructions (like open file, run program)

These instructions go to the hypervisor

The hypervisor translates them

Then it sends them to the real hardware

So the flow is like this:

Program → OS (inside VM) → Hypervisor → Real Hardware

This is why virtualization is powerful:

You can run many systems on one computer

You can test without breaking your real system

You can create servers easily

Creating the Virtual Machine

To start the Born2beRoot project, we need to create a Virtual Machine using VirtualBox.

First, we create a new virtual machine and give it a name that ends with 42 (example: login42). This is required.

Then, we choose the operating system. We must use the latest stable version of Debian.

After that, we configure the machine:

choose RAM (enough for the system to work)
create a virtual disk

The disk must be used later with LVM and encryption. This is very important in the project.

We must also follow these rules:

no graphical interface (no desktop, no GUI)
only a minimal installation
the machine is used as a server

Example:

After creating the machine, we start it using a Debian ISO file and install the system.

Step 1: Attach the ISO file

You go to:

Settings → Storage

Click “Empty”

Choose your ISO file (example: debian-13.4.0-amd64-netinst.iso)

👉 What happens inside:

The ISO file acts like a virtual CD/DVD

The VM will read it when it starts

Step 2: Start the machine

You click Start

👉 Inside the system:

VirtualBox starts the VM

VM checks boot device

It finds the ISO (virtual CD)

It loads the Debian installer into RAM

Step 3: Debian Installer starts

You will see menu:

Install

Graphical Install (DO NOT use for project ❌) 👉 Choose: Install

Step 4: Installation process

Now step by step:

Choose language

Choose country

Configure keyboard

👉 Then:

4. Network config (automatic usually)

5. Set hostname (example: login42)

6. Create root password

7. Create user

Example:

Step 5: Disk partitioning (IMPORTANT)

👉 Choose:

Guided - use entire disk and set up encrypted LVM

We choose the disk which we wish to create the partition (it only have to show one disk).

Once we choosed the disk we must make the partition as is in the subject. To do it properly we select the second option Separate /home partition.

We choose option Yes so the changes will be writen in the disk and so we can set the logical volume manager (LVM).

We click on Cancel; the erasing of the data is not required.

Again, we must choose desired password for the LVM encrypt. As is mention before we must repite the process and I advice you to write it down.

n this step we must input the required amount of volume group to use during the guided partitioning. We can write down max or the total avalaible memory, in this case being 30.8 GB.

Codexion

Yassir El bakkari — Mon, 13 Apr 2026 15:50:23 +0000

Introduction

Codexion is a concurrent system simulation written in C where multiple threads represent coders competing for limited shared resources called dongles, Each coder runs independently in parallel, and all coders must coordinate access to these resources without direct communication.

At the system level, this project models how an operating system manages multiple processes competing for shared hardware, Each coder is implemented as a POSIX thread (pthread), and each dongle is protected using using synchronization primitives such as mutexes and condition variables to ensure safe access, Since multiple threads attempt to access the same resources at the same time, the program must prevent race conditions, deadlocks, starvation, and inconsistent shared state.

Each coder repeatedly performs a cycle of actions: acquiring two dongles, compiling code, releasing resources, debugging, and refactoring. However, each coder has a strict time constraint: if they fail to compile within a given deadline, they are considered to have burned out, and the simulation stops. A separate monitor thread continuously checks the state of all coders and enforces this rule with high precision timing.

The system also introduces a scheduling mechanism that controls how dongles are assigned when multiple coders request them at the same time. Depending on the selected policy (FIFO or EDF), the order of access changes dynamically based on request time or urgency. Additionally, a cooldown mechanism delays reuse of dongles after they are released, adding another layer of resource contention.

Overall, Codexion is a low-level concurrency problem that requires careful coordination between threads, precise timing control, and efficient synchronization to ensure fairness, liveness, and correctness under strict constraints.

System Overview

This project simulates a group of coders running in parallel using threads. Each coder is an independent execution flow controlled by the operating system. All coders share limited resources called dongles, which are protected to prevent conflicts when multiple coders try to use them at the same time.

The system runs continuously in cycles. Each coder repeatedly tries to acquire two dongles, performs compiling, then releases the resources and moves to debugging and refactoring. Since resources are limited, coders may need to wait until dongles become available.

At the same time, a monitoring system observes all coders and tracks their last compiling time. If a coder does not compile within the allowed time limit, the system stops and that coder is considered burned out.

To manage fairness, the system uses a scheduling strategy (FIFO or EDF) that decides which coder gets access to a dongle when many coders request it at the same time.

Core Concepts

1. Threads (POSIX Threads)
A thread is a single flow of execution inside a process. In this project, each coder is represented by a thread created using POSIX threads.

Inside the operating system, the CPU does not run all threads at the same time. Instead, it switches very fast between them using context switching. One thread runs for a short time, then it is paused, and another thread continues.

All threads share the same memory space. This means they can access the same data, such as shared counters and shared dongles. Because of this shared memory, synchronization is required to avoid conflicts.

2. Shared Resources (Dongles)
Dongles are shared resources used by coders to compile. Each coder needs two dongles at the same time to perform the compiling step.

Since all coders share a limited number of dongles, multiple threads may try to access the same resource simultaneously. Without control, this would lead to conflicts where two coders use the same dongle at the same time, which is not allowed.

This is why dongles must be protected using synchronization tools.

3. Mutex (Mutual Exclusion)
A mutex is a locking mechanism used to protect shared resources. Only one thread can lock a mutex at a time.

When a coder locks a dongle, other coders trying to access it will be blocked by the operating system and placed in a waiting state.

The OS manages this waiting internally using kernel queues. The blocked thread does not consume CPU time until it is allowed to continue.

Mutexes ensure that shared resources are used safely without data corruption or simultaneous access.

4. Synchronization and Critical Sections

A critical section is a part of the program where shared resources are accessed or modified.

In this project, critical sections include:

Taking dongles
Updating last compilation time
Incrementing compile counters
Printing logs Only one thread can execute a critical section protected by a mutex at a time.

Only one thread can execute a critical section protected by a mutex at a time.

5. Scheduling (FIFO and EDF)

When multiple coders try to take the same dongle at the same time, a scheduling policy decides who gets it first.

FIFO (First In First Out):
The coder who requests the resource first is served first. Requests are handled in arrival order.

EDF (Earliest Deadline First):
Each coder has a deadline based on:
last compile time + time to burnout.
The coder with the closest deadline gets priority.

This scheduling is implemented using a priority system that organizes waiting threads.

6. Monitor System (Burnout Detection)

A separate monitor thread continuously checks the state of all coders.

It compares the current time with each coder’s last compilation time. If a coder exceeds the allowed time without compiling, the monitor triggers a burnout event and stops the simulation.

This monitor acts like a watchdog system inside the program, ensuring that no coder stays inactive for too long.

7. Lifecycle of a Coder

Each coder repeats the same cycle during execution:

First, the coder tries to acquire two dongles. If successful, it enters the compiling phase.
After compiling, the coder releases the dongles and moves to debugging, where it waits for a fixed amount of time.
Then the coder enters refactoring, another waiting phase.
After completing these steps, the coder returns again to try compiling.

This cycle continues until the system stops due to burnout or completion condition.

Concurrency Problems

In a multi-thread system like this project, running threads at the same time creates several hidden problems. These problems do not appear in normal single-thread programs, but they become critical when many coders share the same resources.

1. Race Conditions
A race condition happens when multiple threads try to read and write the same shared data at the same time.
1- video (YouTube)
2- video (YouTube)

In this project, shared data includes:

last compilation time
compile counters
dongle state
log output

If two threads update the same variable without protection, the final value becomes unpredictable. It depends on which thread executes first, which is decided by the OS scheduler.

To prevent this, mutexes are used to ensure that only one thread modifies shared memory at a time.

2. Deadlock
A deadlock happens when threads block each other in a circular way, and none of them can continue execution.
video (YouTube)

In this project, each coder needs two dongles. If every coder locks one dongle and waits for the second one, all threads can become stuck forever.

The system prevents this by changing the order of resource acquisition depending on the coder ID (even or odd). This breaks the circular waiting condition and avoids deadlock.

3. Starvation

Starvation happens when a thread never gets access to a required resource because other threads are always prioritized before it.

In scheduling systems like FIFO or EDF, a poorly designed priority system could continuously favor some coders and block others indefinitely.

To avoid starvation, the scheduling logic ensures fairness by controlling the order of access to dongles and respecting either arrival time (FIFO) or urgency (EDF).

4. Livelock

A livelock happens when threads are not blocked, but they keep changing state without making progress.

For example, coders may repeatedly try to acquire dongles but always fail because others take them first. They stay active but never reach the compiling phase.

Careful scheduling and controlled locking reduce this behavior.

5. Resource Contention

Since the system depends on precise timing (burnout detection), small delays can affect correctness.

If thread scheduling or locking delays are too slow, a coder may exceed the allowed time before being checked by the monitor.

This is why the monitor must run frequently and efficiently, and shared state updates must be protected and fast.

Threads (Deep System Explanation)

1. What a thread really is (system level)

A thread is the smallest unit of execution the operating system can schedule on the CPU.
1. video (YouTube)
2. video (YouTube)
3. video (YouTube)

Inside the OS:

A process is a container of memory (code, heap, globals).
A thread is a running path inside that memory. So when you create threads with POSIX:
you are not creating “new programs”
you are creating multiple CPU execution paths inside the same process

Each thread has:

its own register state (CPU state)
its own stack (function calls, local variables)
shared access to heap and global memory

The OS scheduler sees each thread as:

a runnable entity that competes for CPU time So it continuously switches between threads using context switching.

2. Thread creation: pthread_create
When you call:
pthread_create(&thread, NULL, routine, arg);
nternally the OS does:

Allocate a thread control block (TCB)

Create a new stack for the thread
Store the starting function pointer (routine)
Put the thread in the ready queue
Mark it as runnable

At this point:

the thread exists
but it may not run immediately

The scheduler decides when it gets CPU time.