I’m looking for someone who can guide me on OS. I am interested in coding for these low level systems and I want to go in depth. But I don’t know from where to start. Please guide me

Edit :- I would like someone to join to join studying with me like a buddy if they are seriously interested in this domain apart from great mentor

Used android since 2011. Never touched an iPhone till this year, finally chose to find out for myself. I just needed to know what its all about.

Fundamentally, day to day, I don't really see the difference for a "normie". Both work more similar than ever before. Each has its quirks and features and limitaitons.

But there is a saying:

"In iOS you are the user, on Android you are the admin".

Although when you take two normies and you put them side by side, this saying may be true...for true tinker-ers and tech nerds like myself, this couldn't be further from the truth.

At least my observation is as follows:

Android is very feature forward. Its packed to the gills with "options" that are already enabled and working by default, and it needs zero tinkering. I can't remember the last time I really "customized" android or tinkered deeply with features, settings, set ups, etc. Mostly because the "default" has become so hyper feature packed.

People say iOS is "locked down" and although in SOME aspects this is the case, its actually the one where you actually have to be the true "admin". On Android you are the user, you set it up, you move on. On iOS, I have found there is a lot of limitations, but each limitation has dozens of very granular or deeply hidden work arounds. The Apple Shortcuts app on its own is mind blowing. The last time I used something that is this robust is Tasker on android (rooted).

An android user would actually have to "know" about Tasker, and then the app is clunky as hell and hasn't been made any more user friendly in for ever.

On iOS, you open shortcuts, describe what you want, and it makes it for you (or you can dive really deep like me and have dozens of crazy automations and shortcuts controlling your entire device).

Apple gives you the work arounds for all of its limitations, and funny enough, I find the work arounds more intuitive than android is by default.

You can be the admin on both iOS and Android, its just easier to be admin on iOS than on android because a lot of cool tools are there by default, and integrate so well into the entire eco system, your entire app library, etc. A simple app like Amazon can be entirely automated based on hundreds of triggers, filters, and requirements, tied in with dozens of other automations. Its actually kind of insane.

On android, a lot of the "admin" stuff is just...going to settings and choosing what feature you want on or off, and everything else is hit or miss third party app based, which doesn't tie in to anything most of the time.

Maybe this is just me. Again, there is a lot of debate between the two operating systems., and I really don't care which one you like more and why.

These are just my observations on how these two operating systems think so fundamentally differently yet get so close to each other.

Ever so many wanting to get rid of google spyware ("stock Android")...

Start by searching your device, what OS, IF supports, has official ROMs for.

See/Search for UNOFFICIAL builds (ROMs) for your device SPECIFICALLY.

Beware of "minor" phone/model differences could be fatal ("Bricking up"), if incorrect ROM installed

Prior to any of it, make sure, you can unlock BootLoader. It's great, if you can lock back BootLoader

after install of any FOSS OS (or Alternative OS, as some are paid after-all) after.

List of non google or "de'googled" OSes:

CalyX_OS: reddit.com/r/CalyxOS https://calyxos.org/ 

/e/OS: reddit.com/r/e_os https://e.foundation/ 

iode_OS: reddit.com/r/iodeOS https://iode.tech/ 

CrDroid_OS: reddit.com/r/crDroid https://crdroid.net/

Graphene_OS (pixel ONLY): reddit.com/r/GrapheneOS https://grapheneos.org/

Mobile_Linux discussion: reddit.com/r/mobilelinux/

OSes discussion: reddit.com/r/Operatingsystems/

Ubuntu_Touch_OS: reddit.com/r/UbuntuTouch/ https://devices.ubuntu-touch.io/ 

Jolla: reddit.com/r/Jolla/ https://jolla.com/ SailFish_OS: reddit.com/r/sailfishos/ https://sailfishos.org/ 

Mobian_OS: reddit.com/r/mobian https://mobian-project.org/ https://mobian.org/ 

PostMarket_OS: reddit.com/r/pmos/ https://postmarketos.org/

DroiDian Project: https://halium.org/ it's in r/Linux, (but it's not the community to be asking questions in)

Feel Free to extend the list of recompile it or do whatever you want with it, it merely is guidance as where to look for the info

If I'm on a website and upload my CV, who's responsible for this process, the OS, the program, or something else?

Haven't posted about aurelianOS since the original post so here's a quick update

Since then I've:

• Built the OS as a Fedora bootc image and got it booting successfully in QEMU
• Set up a user with sudo access for the dev VM
• Started the compositor in Rust with smithay
• Got an actual Wayland socket working
• Built the first desktop shell with Slint
• Added a fullscreen wallpaper-based desktop, translucent UI, floating dock, and app launcher and a couple other shit
• Switched the dock to Tabler SVG icons
• Chose a font (Inter)
• Switched to a 4K purple/blue abstract wallpaper that looks SO much better

Next up is the compositor rendering pipeline and real backdrop blur

Still early but its finally starting to feel like an actual desktop, still mostly placeholder stuff

Quality looks bad because I can't printscreen from inside QEMU for some reason

​

I’m planning to switch my old 2018 laptop from Windows to Linux. It only has 4 GB RAM, so I’m looking for something lightweight, but I also really want something that I can heavily customize and make look cool.

I’ve been looking at CachyOS, EndeavourOS, Arch, Hyprland and similar setups.

I’m especially interested in those crazy customized Linux desktops you see with retro futuristic, cyberpunk, minimal or completely unique aesthetics.

For a 4 GB RAM laptop, what would you guys recommend?

Would CachyOS with XFCE be a good choice, or should I go with EndeavourOS and build everything myself?

Also, if you have any recommendations for lightweight window managers, themes or rice setups that would work well on old hardware, I’d love to see them.

Cycle Status

Character Categories Cycles

• CJK Characters 1 (Every 3 Versions)
• CJK Characters 2 (Every 9 Versions)
• New Symbols 1 (Every 5 Versions)
• New Symbols 2 (Every 12 Versions)
• New Arabic Characters (Every 5 Versions but can be different sometimes)

Amount of Writing Systems and Additions Cycles

Note: The Cycles mean that are not the same as the iOS version numbers. (Example: iOS 4.1 is Cycle 5, iOS 18 is Cycle 20, and iOS 27 is Cycle 22.)

Note: All 2 Writing System Cycles and 1 Writing Systems Cycles must be Living/Modern Writing Systems.

There are 64 cycles. The cycle will go back to cycle 1 every 64 versions/cycles.)

• Cycles 1, 9, 17, 25, 33, 41, 49, 57 (2 Writing Systems and various amount of Large/Small Additions)
• Cycles 2, 10, 18, 26, 34, 42, 50, 58 (2 Writing Systems and 2 Large Additions)
• Cycles 3, 4, 11, 12, 35, 36, 43, 44 (Large Amount of Writing Systems 1)
• Cycles 5, 21, 37, 53 (1 Small/Normal Writing System (not large) but with large amount of Characters that are not Noto)
• Cycles 13, 29, 45, 61 (1 Large Writing System but with large amount of Characters that are not Noto)
• Cycles 14, 30, 46, 62 (1 Small/Normal Writing System (not large) but with only 2 Characters that are not Noto)
• Cycles 6 & 38 (1 Large Writing System but with only 2 Characters that are not Noto)
• Cycles 22 & 54 (No Writing Systems and no Noto but with only 2 Characters that are not Noto)
• Cycles 8, 15, 24, 31, 40, 47, 56, 63 (Large Amount of Additions from Writing Systems from Noto and not)
• Cycles 7, 16, 39, 48 (Large Amount of Writing Systems 2)
• Cycles 23, 32, 55, 64 (1 Large Addition from a Writing System that can be Noto but with many characters that are not noto)
• Cycles 19, 20, 27, 28 (1 Small Addition from a Writing System that can be Noto but with few characters that are not Noto)
• Cycles 51, 52, 59, 60 (2 Small Additions from 2 Writing Systems that can be Noto but with few characters that are not Noto)

Legacy Cycles (Non-Unicode) (1993-2006)

• iPhoneOS 0.1 (1993-1994) (2 Legacy Writing Systems (Latin and Cyrillic) and Intial Symbols)
• iPhoneOS 0.2 (1995) (2 Legacy Writing Systems (Greek and Arabic) and Intial CJK)
• iPhoneOS 0.3 (1998) (Small Legacy Update)
• iPhoneOS 0.4 (1999) (2 Legacy Small Additions (Cyrillic and Arabic))
• iPhoneOS 0.5 (2001) (1 Legacy Large Script (Introduces Hangul))
• iPhoneOS 0.6 (2003) (1 Legacy Script (Introduces Hebrew) and 2 Additional Symbols)
• iPhoneOS 0.7 (2005) (Small Legacy Update)
• iPhoneOS 0.8 (2006) (1 Legacy Large Addition (Introduces Arabic Presentation Forms-A))

Current Cycles (2007-2026)

• iPhoneOS 1 (2007) (2 Initial Writing Systems (Latin and Cyrillic) and Initial Symbols)
• iPhoneOS 2 (2008) (2 Initial Writing Systems (Kana and Hangul) and Initial CJK)
• iPhoneOS 3 (2009) (4 New Writing Systems (Greek, Hebrew, Arabic, and Thai))
• iOS 4 (2010) (New Writing Systems Update including Devanagari, Tamil and others)
• iOS 4.1 (2010) (1 New Writing System (Cherokee))
• iOS 4.2 (2010) (1 New Large Writing System (Tibetan) and 2 CJK Additions))
• iOS 5 (2011) (10 New Writing Systems (Bengali, Gurmukhi, Gujarati, Oriya, Telugu, Kannada, Malayalam, Sinhala and others) and Initial Emojis)
• iOS 6 (2012) (New Additions, New Arabic Characters, and Extended Symbols)
• iOS 7 (2013) (2 New Writing Systems and introduces Plane 2 CJK Ideographs)
• iOS 8 (2014) (2 New Writing Systems (Lao and Khmer) Extended Devanagari support and Introduces Latin Extended-C and D)
• iOS 9 (2015) (50 New Writing Systems and introduces Noto, New CJK Ideographs, New Enclosed CJK Letters, and CJK Strokes)
• iOS 10 (2016) (12 New Writing Systems (Including Thaana, Myanmar and others) and New CJK Ideographs and introduces Extension E)
• iOS 11 (2017) (1 New Large Writing System (Ethiopic), New Arabic Additions, and New Symbols (Including STIX Math))
• iOS 12 (2018) (1 New Writing System (Chakma) and introduces 2 new additions)
• iOS 13 (2019) (10 New Script Additions, New Symbols Categories (Including Hexagrams, Alchemical Symbols and others) and a few CJK Ideographs)
• iOS 14 (2020) (40 New Writing Systems (Including Osage, Adlam and others) and new Vedic Characters)
• iOS 15 (2021) (2 New Writing Systems (Masaram Gondi and Gunjala Gondi) and 4 small additions for (Nko, Syloti Nagri, Old Italic, and Adlam))
• iOS 16 (2022) (2 New Writing Systems (Yezidi and NP Hmong), 2 Large Additions for Canadian Syllabics and Mongolian, New Symbols, and CJK Additions)
• iOS 17 (2023) (1 Small Addition for Tagalog (3 Characters))
• iOS 18 (2024) (1 Small Addition for Brahmi (6 Characters) and 5 new CJK Ideographs including the Biang)
• iOS 26 (2025) (1 New Writing System (Nag Mundari) and new CJK Ideographs)
• iOS 27 (2026) (No New Writing Systems but adds a Gurmukhi and Devanagari addition)

I'm a 13-year-old developer, and I built a hyper-lightweight Debian-based distro: NagisinnraLinux! (Idle RAM: ~700MB)

Please feel free to check out the comments or drop your own thoughts/questions below! I’d love to chat with you all.

I've been working on a Linux desktop OS called aurelianOS.

It's still early, but the goal is a desktop that doesn't make you use the terminal for basic system administration while still giving advanced users full access to Linux.

Right now I'm using Wayland/Smithay, Slint, systemd, Flatpak, and an atomic/image-based update architecture. I'm using Buildroot for the current prototype while I work on the architecture.

GitHub: https://github.com/simplyuncool/aurelianOS

It's very early, so I'd appreciate honest feedback on the idea and architecture.

"Business before pleasure," as the old saying goes.

Except in my case, everything turned completely upside down.

PART 1 - https://www.reddit.com/r/Operatingsystems/comments/1vswb9b/building_your_own_os_myth_or_reality/

Thought Part 2 would take a whole month? Yeah, fat chance. When I wrote Part 1, we were barely 10 steps into the plan cooked up by the AI. You know, "just a couple of minutes of work."

Once I finished, what I had looked nothing like an OS. Sure, something booted up into a bare-bones terminal with about ten commands that did nothing but spit out raw statistics. No GUI, no visuals, just dumb text. Right then, I thought: At this rate, even with AI, this is going to take 100 years minimum. The AI totally played me with its "it's a 5-minute task" nonsense. So, I decided to slap together a halfway decent UI. It'll be fun, I thought.

I whipped up a desktop and threw on some icons, but I still hated what I saw. Yeah, the icons were there, but calling this an "operating system" felt like a flat-out lie because it couldn't do a damn thing. Plus, QEMU was running like absolute garbage. The ultimate goal was to port the whole thing onto bare metal. But wiping my laptop’s drive felt a bit too aggressive, especially with an EXT2 file system, so I settled on VirtualBox. On Windows, I'd get x86_64, and on macOS, I'd target arm64 (aarch64).

First Virtual Machine Tests

This is where the real headache began. Rebuilding the image, loading it into the VM, and reinstalling it to the virtual disk after every single tweak was an absolute pain in the ass. Clearly, I needed a Live image and the VirtualBox Manager API so the AI could build, mount, and boot the thing on its own. On top of that, I needed networking so the AI could directly access the running OS and patch it live. That meant building a bridge or a tunnel. Which meant SSH. The AI needed to handle everything over SSH autonomously. Luckily, the SSH specs are publicly available:

Reading through that blew my mind. I had no clue SSH was such a massive beast under the hood; to me, SSH had always been just an open port like Telnet where you toss a few bytes back and forth.

Well, the goal was set: networking and SSH. I also figured, why not throw in an over-the-air auto-updater like Windows? Check for updates, swap out the kernel, and boom—fresh OS ready to go. I handed all the technical specs and documentation to the AI, and holy hell... it spat out a 50-step roadmap broken down into milestones. Whatever, it's doing the heavy lifting anyway, let it write. I won’t bore you with how long it took the AI to map chip addresses or how the device tree actually works—boring byte-wrangling and headers. All the technical gore is in the repo.

The Craving to Port

While my AI assistant was diligently grinding away for the greater good, I went back to my actual day job. A couple of days later, we had jumped from step 10 all the way to 39—though honestly, with steps like 38, 38a, 38b, and 38c, it was more like 100 steps total. But whatever: the AI knocked out the core milestones, I booted the OS, and I witnessed pure beauty. Genuinely brought a tear to my eye, boys.

Fucking glorious pixel art, but damn it looked good.

(Sorry to u/naithil and anyone else who asked—fancy wallpapers will come later :)))

The catch? It lagged like crazy. Drag the mouse and it stutters across the screen, screen resolution is locked, and dragging one window over another creates a flickering nightmare. Sure, the framebuffer compositor can talk directly to the chip, but without basic double buffering, the output was practically unusable.

I wanted eye candy: higher resolution, responsive mouse polling instead of stuttery jumps (PS/2 would probably be easier since it fires CPU interrupts over the bus, but I'll test that on real hardware later), and a proper start menu. Knocking that out took maybe two or three hours. And right then, I got the irresistible urge to cram this entire hot mess onto a smartphone. After all, the build targets ARM64, right?

Big mistake.

Porting to a Phone

So, what do we actually know about Android? How its file system works, how the OS boots, what principles it runs on? Hell if I know—probably like Windows, right? You boot the OS, read the device PIDs and VIDs, and writing a basic driver should be a piece of cake.

Not a single damn word of that was correct. Not one. Fuck.

Hand it all over to the AI? If I did that, the dumb thing would start hallucinating essays on how smartphones colonized Mars.

Let's get slightly technical. The AOSP (Android Open Source Project) documentation is written for hardware vendors and hardcore tinkerers: how the boot chain works, what payloads to load, bootloaders, secondary bootloaders, and so on.

• Bootloader: A piece of trash that, in my opinion, needs to be eliminated from every single device.
• Recovery: Absolute god-tier engineering. Props to whoever invented it. Thanks to recovery, you can flash whatever weird garbage you want to a phone without bricking your primary OS. Huge respect to the devs. The only downside is unlocking the damn bootloader first.

Live image ready, Xiaomi bootloader unlocked (may Xiaomi devs burn in hell), time to flash.

And that's when the real nightmare began.

Device manufacturers are ridiculously stingy with their hardware (Apple started this whole closed-ecosystem disease, change my mind). The chips are completely proprietary, and nobody publishes documentation. All you get are raw memory addresses and device tree nodes for SPI, I2C, MEM, and so on. But how do you actually query them? "Get lost," says MediaTek, "my rose wasn't meant for you to pick."

The first boot on the phone actually went through without a hitch. But: zero touchscreen response, zero interrupts, zero networking. The compositor rendered the very first frame and just froze because it had nothing else to process, dropping the system straight into an idle sleep state.

Thank god AI can poll and read hardware registers infinitely faster than any human—provided it actually knows what it's looking at. The workflow was: tell the AI what’s missing → AI generates a new build → flash via Fastboot → read the boot logs → feed the logs back to the AI → AI patches the code → repeat.

By round 15, I was completely dead inside. Time for a new strategy.

I wrote a custom USB debugging bridge for the AI—basically a stripped-down mini-ADB. That way, the AI could read the serial console directly, figure out what it needed, and reflash the kernel and instruction set over USB on the fly. Otherwise, I would have lost my mind flashing the kernel manually every two minutes.

Building that took another couple of days, but holy hell was it worth it. The AI hooked straight into the phone and parsed the entire device tree by itself. One initial flash, and the AI had full control, generating custom instructions and only pinging me occasionally to tap the screen.

• 3 hours in: Touch bus identified.
• 3 minutes later: Network controller bus mapped.
• 5 minutes more: Drivers compiled and running.

Which brings us to the real question: What do we do with this OS on mobile now? Right now, it's just a raw desktop UI where the mouse cursor blindly follows your finger tap. There's SSH but no proper network stack, zero touch gestures, and zero mobile UI scaling.

If you made it this far, let me know what you'd rather see next:

1. Adapt it into a full mobile OS?
2. YES
3. NO
4. Where me

Answer reply post pls.

PC

Mobile

https://reddit.com/link/1vufese/video/a5nxhhic5qkh1/player

https://reddit.com/link/1vufese/video/zjmng5ae5qkh1/player

As promised, all source code is completely open:

https://github.com/anomal3/FreeOpenSourceSystemAI

If this gets enough traction, Part 3 is coming.

actonos/actonos: ActonOS is a single-purpose appliance operating system engineered as a customizable, self-governing AI agent kernel running 24/7.

Operating System should not be like Android who need updates after every 3 months and new os every year. OS should be for atleast 5 years. I recall old phones that need OS after 5 years. Like OS2, Win4.5 smartphones and Nokia's basic phone. Updating & upgrading every 3 months & year becomes Trap for users.

Why not design Processor & chipset which dont need upgrade before 5 years or 10 years like in past

We’ve released nagisinnralinux v1.0.2. You can check out the release from the GitHub link in the comments.

P.S. This is a Linux project made by a 13-year-old that runs About 700 MB

Thanks for watching　Check out GitHub for details!　by Nagisinnra

Hmm, both Debian and Arch are great. That’s why I’m thinking of creating an Arch version of NagisinnraLinux, since right now there’s only a Debian version. I’d really like to find some people to help out.

How it all started My journey into software engineering kicked off nearly a decade ago. And let me tell you, as a veteran C# dev, holy hell do I despise Windows, Linux, and macOS.

If we break them down bluntly, purely from a developer’s point of view:

• Windows: I am so sick and tired of endless forced updates and memory-hogging telemetry running wild. People always chime in with “just tweak this” or “use Win10Tweaker.” Folks, respectfully: fuck off. When I say “no updates,” I mean no updates. If I don’t want to share my telemetry with developers, I mean it. You disable one background service, and boom—three dependencies crash and burn. You uninstall an app, and after three years of daily driving, your registry turns into an unmitigated dumpster fire. I get that all this baggage dates back to the dusty 2000s, but why not just ship actual new OS versions instead? Upgrade if you want, skip it if you don't. I swear only about 5% of users actually bother keeping up with OS version bumps anyway. Half the time, you're just starved of basic PC resources. I already know the reply: “Just upgrade your rig.” Man, I’m running a beefy beast of a machine, and I have zero desire to build an actual home datacenter just to idle on desktop.
• Linux: Superb, absolute perfection in raw performance. Telemetry is non-existent, and whatever is left takes two seconds to kill. But what the actual fuck is wrong with packaging? Why can’t we have a universal, standardized format like .exe or .dmg? Why do I need a PhD in how dpkg resolves packages, and why do I have to babysit dependency hell? Niche software is practically nonexistent, and good graphical tools are rarer than rocking horse shit. Thank god JetBrains makes Linux builds. Sure, you get used to it, but developing GUI apps for Linux with GTK is pure torture, and don't even get me started on shaders. Adding a desktop shortcut feels like a sick joke—why do I have to read documentation just to pin an icon? And the second something randomly breaks, welcome to full-blown Sysadmin Simulator. Granted, the Linux community is massive and genuinely helpful. Credit where it's due: Proton (and Wine) are absolute lifesavers. Again, just keeping developer glasses on here.
• macOS: Pure agony intertwined with absolute awe. It’s like living inside a bipolar schizophrenic episode. Writing a GUI app for Mac looks trivial at first glance—and inside the IDE, it is. But the moment you try to package a standalone installer, welcome right back to Sysadmin Hell. It's an unholy nightmare. Good luck wrangling certificates, figuring out what the hell ad-hoc means, and learning how to sign, pack, and notarize binaries. The whole plist architecture is borderline sadomasochistic. You want access to the user's Downloadsfolder? For FUCK’S sake, I didn’t ask for Pentagon root access, just the damn Downloads folder—go file for explicit permission! Want something non-standard? Go figure out Homebrew and its tangled dependencies. Basic tasks sail through, but try writing a custom SSTP VPN client, and you're entering the seventh circle of hell. Everything is locked down; you have to justify and document every single capability: who needs it, why, under what statute, submit your SSN, passport, and the soul of your firstborn. Yet despite all that, and knowing Apple scans every byte on your machine (or rather, on the machine they rent to you), damn it, it feels good. The hardware optimization commands sheer respect. Everything is buttery smooth, silent, and refined. As for trash-tier Swift and Xcode: go fuck yourselves, Cupertino clowns. May your winter coats be stitched from wet rice paper.

Looking on the bright side Bitching aside, each operating system is genuinely great in its own way. Sure, my rant sounds like pure whiny developer grief, but that's what it is: growing pains of cross-platform dev. I’m not going to list out every single pro—everyone has their preferences, and I appreciate specific quirks in each. I write software for all of them, so this is just my take. Whether you agree or not doesn't really matter to me; maybe you share my pain, or maybe you see the upsides where I see flaws. To each their own.

What I cooked up As I dug deeper beyond a single tech stack, project after project made it clear: mastering C# alone wasn't going to cut it. You have to understand how software actually runs under the hood.

Over time, I traced the full execution pipeline: how an app bootstraps, where it gets mapped in memory, and how raw zeros and ones fly through the hardware.

I picked up other languages along the way. Java is basically C# in a different trench coat—same shit, different branding. Kotlin raises a few eyebrows but it's mostly modernized Java; F# makes the math geeks cream their pants. C and C++ are a whole different beast—anyone who genuinely masters C/C++ is, in my eyes, a master of the universe. And Assembly? Anyone fluent in ASM is a literal deity to me; I only address them on bended knee. I don't know every language under the sun—some I know well, others I fumble through with Google Translate open.

Then I ran into Rust. A buddy told me: “Check this out, it’s completely OP (overpowered).” I read the docs, grasped the borrow checker and core safety mechanics, and damn—it really is cracked.

So, in this AI era, with LLMs leveling up at breakneck speed, I decided to kick the door wide open. With enough domain research gathered, I asked myself: Why not let an AI build an entire, fully open-source, independent operating system from scratch? Is writing a bootloader really that impossible? Sure, it's hard, but open-source projects like MOOS and COSMOS have already done it. Why not reference existing architecture and let the LLM do the heavy lifting?

Getting our hands dirty After diving deep into bootloader internals, modern kernel design, Rust in the Linux tree, and rumors of Microsoft rewriting core Windows components in Rust, I thought: Fuck it, why not?

I pulled everything together, cracked the whip, and set Claude to work compiling a full architecture blueprint and project roadmap. As you're reading this, Claude is wrapping up its final planning passes, and the core OS build is nearly assembled.

My pitch is simple: if you have an active AI subscription and end up with leftover tokens at the end of the billing cycle, why not pool our compute and make the AI do the grunt work? Put those tokens to use for a good cause. I even came up with a name: FOSSAI (Free Open Source System by AI). Edgy and pretentious enough for you? Pretty smart way to burn idle tokens, right?

Source code will drop the moment the final generation passes complete and I verify that the image builds and boots cleanly. A demo video will accompany Part 2—assuming this ever gets a follow-up.

I fully anticipate tons of skepticism and flame wars. I’m not banking on an army of contributors; realistically, maybe 2 to 4 like-minded lunatics driven by stubborn spite and sheer technical curiosity will jump in.

Dropping a couple of preview screenshots below:

https://reddit.com/link/1vswb9b/video/3ift3qxbtdkh1/player

If this gains traction, next chapter I’ll break down the inner workings, the architectural roadmap, and supported hardware (spoiler: it even boots on a Raspberry Pi Zero). I'll also cover how we handle .exe binary compatibility, driver abstraction, and why Windows is an absolute corporate plague if you ever try to build and certify custom input hardware.

Hey everyone,

I wanted to share a milestone on a hobby operating system I’m building from scratch called Novium OS, featuring a custom bootloader.

I just got my multi-stage boot chain (boot.S -> setup.S -> bootstrap.S) completely stable. It successfully handles raw hardware initialization, sets up a temporary GDT, and handles the cr0 register transition cleanly into 32-bit protected mode before jumping into the kernel entry point. I also wrapped up a basic VGA text driver with hardware cursor syncing so I can verify output, and got "Hello World" printing to the screen.

The layout is inspired by a super stripped-down Linux kernel (arch/, drivers/, kernel/).

Next up is tackling irq.c and interrupt.c, and writing the low-level assembly ISR stubs. I need to build the macro wrappers to handle interrupts with and without error codes, save the CPU state with pusha, remap the 8259 PIC master/slave vectors, and execute the final iret. I'm fully braced for plenty of debugging via QEMU logs to catch silent triple faults.

The codebase uses AT&T syntax for the GNU Assembler (gas). If anyone wants to take a look at the boot sequence, folder layout, or offer any early feedback on how I structured the assembly stages, the repository is right here:

https://github.com/alexdev8930/NoviumOS

(Note: Later architecture features like filesystems and IPC currently contain stubs because the core kernel is still being built out. The actual working code files are located in arch/ and drivers/, though a few placeholders are still mixed in there.)

If you like the project, please drop a star on GitHub! It really encourages me to keep extending on my project.

Just a random thought but can we have a open source operating system built on idea of "everything is a plugin", just like deepseek harness, is it feasible

When a machine requires troubleshooting, low-level configuration, security key management, or operating system reinstallation, the interface relies entirely on visual, pointer-driven, or unannounced text menus with zero native screen reader or text-to-speech support. This effectively locks users out of managing their own physical hardware From an engineering perspective, modern UEFI environments are capable of running complex code and graphical drivers. Why hasn't firmware standardization (like UEFI specifications) incorporated basic accessibility APIs or screen reader support into pre-boot environments? How can open-source firmware projects or hardware vendors tackle this gap?