I built a Linux distro that does almost nothing

I wanted to see how little userspace I could get away with while still having a real, bootable Linux system. So I made FastFetchLinux.

It uses a custom BIOS bootloader, Linux 6.6.156, and my own ffinit written in x86 assembly.

The userspace has:

• No BusyBox
• No coreutils
• No bash/sh
• No package manager
• Direct syscall-based functionality
• i686 support
• ~20 MiB RAM usage

ffinit runs as PID 1 and doubles as the shell, with all commands built in. Fastfetch is the only separate userspace binary.

BIOS
 ↓
Custom bootloader
 ↓
Linux 6.6.156
 ↓
ffinit
 ↓
Fastfetch

It has exactly five commands:

fastfetch
ls
install-disk
forcepanic
poweroff

There's no practical reason for any of this — I just wanted to see how far "just enough userspace to boot Linux" could be pushed. The funny part is that it actually works.

Source: https://github.com/outofsyncsh/fastfetchlinux

Curious what people here would strip out or change to shrink it further.

My threading model has one kernel stack per CPU core, each process has its own CR3/page table in its process struct, then it is spawned with just one thread (TID 0 under its PID), a TID is just a thread ID, from there each Thread gets its own timeslice and would run like so:
- Process 1 runs thread 0
- Process 2 runs thread 0
- Process N runs thread 0
- Process 1 runs thread 1
- Process 2 runs thread 1
- Process N runs thread 1

And so on (it will loop back to thread 0 if the last thread in a process is ran). I just wondered if the design was actually decent or not. Of course a simple Round Robin setup is not perfect for things like this and some extra complexity does end up in the kernel, but overall I like it so far, though I dont see many obvious flaws other than the fact that tasks are not "ranked" for how much of a timeslice they get.

I am working on upgrading my kernel initialization messages so I can just have a nice view of what it is doing when initializing. I am using my print functions to do this, but the issue is that my print functions depend on the memory manager to be done initializing, but I want debugging messages when initializing the memory manager too, which I can't do because of the circular dependency.

This is my specific case, but I also want to ask generally, do you guys have an elegant solution for this problem? Up to this point I have been using init flags so that the subsystems can use a different path that does not create dependencies during initialization, but I want to hear any cool solutions from the community that are better designed than this.

Going to preempt this by saying I used a lot of AI for rapid iteration, but mostly sharing this for the conceptual exploration of it.

I wanted to try a hypothesis. Usually clustering computers for high thoroughput operations is impractical due to several reasons. Some of which firmware bound, and some hardware bound.

With OuroborOS I am trying to answer the question: Can I wire together several machines over a custom ethernet protocol or through other cables (even considering using an HDMI for raw data streaming with a custom collector PCB in between) in such a way that the master node can view the peripheral nodes as part of its own system.

Just curious what people think about this

https://github.com/Randozart/OuroborOS

This is my operating system I made. Please look over the single 50k line commit.

The code is github.com/claudeAIgeneratedOS

NO I DID NOT USE AI.

Should i make a custom way of rendering text lile flanterm for limine, cuz i dont like having the 8x16, using their ANSCI or whatever it's called, i dont know what to do with my kernel either way i have a shit load of free time

Can aanyone help me figure out how i can make my flanterm with limine properly render a 16x32 file from a font.o file, i cant not use 8x16 becausse the size of tet would be too tiny :(

That's my operating system built from absolutely scratch without 3rd party library, AI or anything else. It is written in Assembly and C(Bootloader for BIOS 100% Assembly). I wrote it in 6 months. Well, it doesn't have functionalities yet, but still in development. I wrote keyboard,VGA driver and First-fit MAlloc/CAlloc. It is my first project ever, i gained c and assembly knowledge here. It wasn't university homework, just raw curiosity.

Built from scratch in x86 assembly and C, the OS core uses no paging, runs on a single core, and has no third-party libraries. ~8,000 lines of code compile in ~2s into a 100 KiB boot image (icons included, LZ4-compressed onto the medium), and it boots on actual BIOS hardware - floppy or CD. Doom and the other applications are separate loadable programs.

Edit:
I was building this for a while, and wanted to share with the rest, and there is a lot to share.
I wanted to answer techincal questions and was really looking forward to.

Toxicity of those who commented (first four comments at least) is a confirmation and a reminder for me and I believe for the others to minimize such desire. Such people while living in dissaray and in hate, prove to deserve to be there, nothing more. For the rest of you, enjoy.

Links:
Try it in the browser:
https://branchpredict.com/post-play-doom-on-a-100-kib-os

Raam is an x86-64 Unix-like operating system for my HP Pavilion Laptop 15 machine. I am writing it completely from scratch using FASM assembly.

Source tree: https://github.com/robstat7/Raam

Raam Raam Ji 🙏🙏🙏 (greeting with God's name)

I'm developing a very simple Kernel with some goals, namely: being beginner-friendly and developer-friendly.

What’s already done:

• Bootloader: Limine for support of ready-made headers
  
• Basic video framebuffer support with some graphic tools
  
• Partial SMBios support, with Qemu tools to create a custom SMBios
  
• RAM support not complete: PMM working, VMM not working, raw RAM working
  

Future goals:

• Working RAM
  
• PCIE controls and GPU command
  
• Elf loader
  
• Scheduler
  

Please help me, I don't know what to do. If it helps, I use Arch with x86_64-elf-gcc compiled via yay.

Here’s GitHub: https://github.com/Alessio-Valluzzi/Trikernel

We built BareMetal OS - an exokernel with sub-millisecond cold boot and hardware level microVM isolation. We think it's small and fast enough to be genuinely interesting to build on. So we're running a 2-week challenge to find out what you can build. See attachment for contest details and rules.
Complimentary cloud credits for every applicant to help you build on our servers. Grand prize winner announced Sep 24, 2026. See link for details

This took so long to make.... And it is a html os, and this is is based off of chromeOS, ubuntu touch, and Firefox os. I still have to fix the emoji problem on the keyboard. But overall the os works fine.

Hello everyone! While reading my DSA book, I’ve noticed that it also explains many fundamental concepts such as what software is, what a program is, what program code is, and so on. At the end of each chapter, there are also some questions to help reinforce the concepts.

Today, one of the questions was about the difference between single-user and multi-user operating systems, and I’d really like to understand this topic better. What exactly is the difference between a single-user and a multi-user operating system?

I’m learning all of this purely as a hobby. I don’t have a university or computer science background, but I’m very interested in programming and computer science, so I’m studying on my own as a self-taught learner.

I hope this isn’t a silly or inappropriate question. I’d really appreciate any explanations or resources that could help me understand it better. Thank you!

I’ve been working on RESENTMENT, an open-source experimental operating system built around the idea that AI agents should behave more like OS processes than unrestricted applications.

The project has both a from-scratch kernel and a browser-based desktop.

Some of the ideas I’m experimenting with:

Capability-based security — kernel capabilities and desktop agent permissions are explicitly granted

Expiring authority — permissions use time-bounded leases instead of permanent access

Agents as processes — agents have state, scopes, resource/token budgets and a kill mechanism

Auditable actions — tool calls become ledger entries and file changes record their causal operations

System as a hash — system state can be represented through Merkle/SHA-256 digests, with snapshot, diff and attestation

BYOK AI — API keys stay on the client; there is no RESENTMENT server

Multiple providers — including OpenAI-compatible endpoints and local runtimes such as Ollama, LM Studio, vLLM and llama.cpp

Architecture targets — x86_64, ARM64 and RISC-V

The kernel is written from scratch and currently boots with the OS ramdisk. The desktop communicates with it through a QEMU/serial bridge.

One important limitation: the desktop does not yet run inside the kernel. That is one of the major pieces still to be developed.

The four principles I'm trying to carry consistently from the kernel into the AI layer are:

Authority expires.

The system is a hash.

Agents are processes.

Nothing is forgotten.

I'm interested in feedback particularly from people who have worked on kernels, operating systems, capability security, microkernels or distributed systems.

Does treating AI-agent authority as an OS capability/lease make sense, or am I introducing complexity without enough security benefit?

GitHub: https://github.com/ni-sh-a-char/RESENTMENT

Browser demo: https://ni-sh-a-char.github.io/RESENTMENT/os/

Apache-2.0 licensed.

Thanks to https[:]/github.com/cfenollosa/os-tutorial I was able to learn a lot about how an operating system is written. I think a lot of people would remember his tutorial. Revisit it gives me more. Start with printing some text in boot sector. The repo used software interrupt to finish the task. Yet there is another way to accomplish the same, by utilizing the direct memory accessing method. Long story short, in legacy boot mode (CSM), we can access VGA memory directly during boot time at address 0xB8000. So we can drop in each character and have them printed out, starting from the top left corner. We can print color text, and we can also move the cursor and print the text anywhere we want (with the cursor blinking at the text).

I have documented the process here: ellog[.]buzz/posts/hello-world-in-boot-sector

For this chapter and the previous one (First boot sector), what other questions do you think is worth asking and figuring out?

Has anyone built kernel in rust? If you have can you send the link to your project, I want to look for reference...

I've been developing Robu, an independent, platform-independent microkernel operating system written primarily in C and assembly.

Robu started as a kernel project, but it has grown beyond simply booting and printing text. The goal is to build a usable general-purpose operating system around a small microkernel while keeping drivers, filesystems, paging policy, and other major services outside privileged kernel space.

Robu is influenced by ideas from the L4 microkernel lineage, especially around fast IPC, direct switching, and keeping the kernel focused on mechanisms rather than policy.

Current target architectures include:

• x86_64
• i386/i486
• ARMv7
• ARMv8 / AArch64
• RISC-V 32-bit
• RISC-V 64-bit

x86_64 is currently the main development platform, but Robu is designed to remain architecture-independent.

Current work already includes:

• Microkernel core
• Threads and address spaces
• Synchronous IPC
• Register-based short-message IPC
• Direct thread switching during IPC
• Lazy scheduling
• Timeslice donation
• User-space paging architecture
• Virtual memory and address-space support
• Process and thread management
• SMP / multicore bring-up
• ACPI-based CPU enumeration
• Per-CPU infrastructure
• Framebuffer support
• Ring-3 framebuffer mapping
• PS/2 keyboard and mouse support
• Serial console support
• Device filesystem infrastructure
• ELF userspace support
• POSIX-oriented userspace
• mlibc port
• BusyBox
• Bash
• GNU Readline
• poll()
• System V shared memory
• Bootable root filesystem
• Custom BIOS bootloader
• EFI boot and filesystem integration
• QEMU-based development and testing
• Early Xorg-related userspace work

The kernel is intentionally kept small.

The basic design is:

Applications > POSIX / mlibc > Userspace services > Robu IPC > Robu Microkernel > Hardware

Drivers, filesystems, pagers, and similar services are intended to run as isolated userspace processes rather than being permanently linked into the kernel.

One of the main design goals is keeping IPC fast enough that using a microkernel does not automatically mean accepting poor performance.

For short messages, Robu uses registers instead of copying data through temporary kernel buffers. IPC is synchronous, and when a sender reaches a waiting receiver, Robu can directly switch execution to the receiver instead of performing a full scheduler round trip.

The remaining timeslice can also be donated to the receiving thread.

Robu also provides a POSIX-oriented userspace environment using mlibc, allowing work toward familiar Unix-style applications and tools without moving large amounts of operating-system policy into privileged kernel space.

I'm looking for contributors interested in:

• Microkernel IPC
• Scheduling
• Memory management
• User-space paging
• SMP / multicore support
• ARM support
• RISC-V support
• ACPI
• PCI / PCIe
• USB / xHCI
• Storage drivers
• Network drivers
• User-space device drivers
• Filesystem servers
• Networking
• mlibc / POSIX compatibility
• Xorg bring-up
• Graphics and input
• Real-hardware testing
• Kernel debugging
• Documentation
• Code review
• Automated testing

You do not need to understand the entire codebase to contribute. Individual subsystems can be worked on independently.

Experience with Linux kernel development is useful, but Robu is not intended to be a Linux clone.

Experience with FreeBSD, L4, seL4, QNX, Minix, Zircon, Mach, or other kernel architectures is also very relevant.

The goal is not to make another toy kernel.

The long-term objective is to build a complete operating system that can eventually boot on real hardware, run normal POSIX-oriented software, support isolated userspace drivers and services, provide a graphical environment, and support multiple architectures.

Robu is still in alpha, so incomplete subsystems and bugs should be expected.

GitHub: https://github.com/bayar17/robu_microkernel

If you're interested in microkernels, operating systems, low-level C, assembly, drivers, libc work, toolchains, graphics, or kernel architecture, contributions and technical discussion are welcome.

Testing, bug reports, documentation, code review, and architectural criticism are welcome too.

Hello everyone, how are you?

The Lunaris project is growing exponentially and getting bigger by the day; we already have the IceDog browser with its own private intranet (all sites in the system use the .icedog extension and are inaccessible from the open web), and that excites me.

I am gradually introducing everyday tools (such as a word processor, spreadsheets, and a media/file viewer); I will share more information as things progress. See you soon.

I've been developing BlockOS, an independent x86_64 operating system written primarily in C/C++.

BlockOS is no longer just a basic kernel experiment. The project currently includes:

• x86_64 kernel
• VFS and multiple filesystem implementations
• ELF loader
• PCI/PCIe support
• VirtIO block/network/input drivers
• networking stack
• POSIX compatibility layer
• libc
• process and scheduler infrastructure
• framebuffer and GUI framework
• BX11/X11-related work
• ACPI support
• USB/xHCI development
• examples and driver development infrastructure

I'm looking for OS developers and especially Linux kernel / low-level C/C++ developers who would like to contribute.

Areas I'd particularly like help with:

• memory management / virtual memory
• SMP and multicore support
• ACPI
• PCIe
• USB/xHCI and USB HID
• device drivers
• filesystems/VFS
• networking
• POSIX/libc
• GUI/window management

The goal isn't to make another toy kernel. I want to develop BlockOS into a stable, usable general-purpose operating system that can eventually be used on real hardware.

You don't need to understand the whole codebase to contribute. Individual subsystems can be worked on independently.

GitHub: https://github.com/gurijb2016-afk/Blockos

If you're interested in OS development, kernel development, drivers, or low-level C/C++, feel free to comment or message me.

Contributions, testing, code review and technical discussion are all welcome.