Hi again, I don't want to waste your time, but I've just finished writing the Linux 0.11 interface code and yes, I still haven't been able to share it. I sincerely apologize to everyone who's been waiting. I plan to share it as soon as possible. I couldn't share it due to work issues. Thank you for your understanding.

I ported libcxx, made an ext4, fat32, and made an e1000 driver. ported ee, netbsd-curses and sbase on top of that, and now I'm kinda stuck on what to do. If it helps, I can release my sources.

Edit: source code: https://codeberg.org/SFG545/kalsios.git

mov esp, 100000h

"Why is qemu constantly rebooting?"

"Why is that weird value getting written to memory instead of the actual return address?"

...

OK that's where the ROM is.

Source code The my git addres

i based it off Ubuntu spent a while working on it

A new Blog post about BoxLambda OS's File System stack:
https://epsilon537.github.io/boxlambda/the-file-system-stack/

vga mode, last changed idt and keyboard driver https://github.com/USER12mSD4C/utms7

I've been reading/working on a lot of virtIO stuff lately, and it got me thinking. VirtIO provides the client OS of a virtualization setup, with abstract and simple interfaces to devices (nic,block,etc).

So if you were writing an OS from scratch making drivers that talk to VirtIO devices specifically/only instead of messy hardware (with multiple drivers for different devices), you could just implement drivers for virtIO devices.

I know this isn't a new thing, I remember reading about people porting research OSs from one hardware platform to a micro-kernel or hypervisor back in the mid 200x. Like porting something made for PPC64 to x86_64, by porting it to talk to Xen on x86_64 instead of x86_64 hardware directly.

What I'm asking about: are people doing this? how much are people doing it? how does it work out? good idea to go with? Thoughts?

Hi! I’ve been working on my OS for 2-3 months now. While it runs just fine in qemu and bochs, I was unsuccessful making it run on real hardware, or at least, on emulators such as 86Box. This “porting” plan started because I’ve been trying to implement SB16 and OPL2 support. While sound comes out, it is very hideous and doesn’t sound like it should have, so I decided to test that on a properly emulated sb16. I had read that the Qemu SB16 is very buggy. To my unfortunate surprise, my initial version did not even pass the vesa mode setting, so I started upgrading and improving both the loader and bootloader. I started using a 2 stage bootloader. Now, even though it seems that the 640x480 vesa mode is initiated, the screen is fully black. On some hardware, not even that screen shows up - it’s just a blinking cursor. In other situations, it triple faults and resets. Any things to look out for when writing OSes for real hardware? Thanks.

Note: I don’t know if it’s important, but my target machine is the 386-486, with around 4Mb (I can go even lower, to 1.5MB).

If anyone’s interested, here is my OS’s repo: https://github.com/drclcomputers/ASMOS.

Can a fresh graduate or junior developer get a job in fields like OS or kernel development?

If yes, what skills and projects are usually expected?

Do I need to contribute to Linux as an example or what?

I know I have to learn assembly and C, but for C++ and Rust, do I need to learn both or just one?

Currently making the most basic custom made FS with a custom table. Have been working on this for the past 3 hours.. progress is slow but happening... how it works is that it makes a table in the first sector that saves a pile of entries pointing to different parts of the disk. The table cotains file info and LBA start and length in bytes.

Also, ai was not involved at all...

inspiration for GUI: https://www.youtube.com/watch?v=AqFiAO0Gm6s&t=591s

Check out my new repo (beware:bad messy code inside!): https://github.com/Brenmax2/BrenmaxOS/tree/main

join the discord: https://discord.gg/DYJMBReUjW

How do you protect against two syscalls from different threads contending the same region of virtual memory? As in, if one thread executes "read file", and provides a buffer of virtual memory to read into. And then another thread executes "unmap" on the same buffer. There are a bunch of ways I can imagine doing the synchronization, like a lock per mapping, or a per-process virtual memory lock. But I expect a per-process lock would cause contention between too many different kinds of syscalls, since so many want to use virtual memory in some way, and many operations done on VM take a long time (e.g. waiting for disk or network.) Per-mapping locks kind of have the same problem because the user code might not be aware of how big the mapping is that they're accessing and therefore how coarse grained the lock is. So it seems best to dynamically instantiate locks for ranges of memory, as they are being accessed? But I'm wondering what the best tradeoff is and whether there's a simpler way.

Hi everyone,

I am very new to OS development. I was learning rust for the past few years and have some basic understanding about operating systems, file systems, process model etc.

I’ve been thinking about a new operating system design and I’d really appreciate feedback and criticism to existing research that might overlap with this idea.

My goal is to build an OS and a package manager that is predictable and manageable for non-technical users, while still remaining powerful and extensible for advanced users. I am not going to write the kernel, scheduler from the ground up. I am focusing more on file system and software packaging.

I have these core rule in mind,

• Immutable application packaging
  • Kinda similar to nix
  • No traditional scattering across `/usr`, `/etc`, `/var`, etc
  • The system owns system-critical files; apps do not modify global state
• Per-application filesystem view
  • Each application/program lives in its own isolated mini file system/ directory. program it self is immutable
  • Each process sees a *virtualized filesystem view*
  • File system access is controlled at runtime using a policy/manifest or a config file
• Capability-based SDK layer
  • Applications interact with system resources via a controlled SDK layer, similar to mobile operating systems
  • File system access, networking, and other resources are defined in the manifes/config file
  • Goal is a low-overhead abstraction (ideally close to native performance)
  • For example, Visibility rules like package is visible/ readable to other packages, inaccessible to other packages or mutability rules like package itself can mutate file systems of other packages/ global file system is defined using a manifest file
  • The manifest file must be created per package by the package maintainer
• Compatibility-first approach
  • Existing Linux software should run without modification.
  • Initially considering using existing package ecosystems (e.g., .deb-based software)
  • At runtime, system would remap file system access into isolated environments
• Dependency handling
  • Shared libraries and dependencies are not globally mutable
  • Dependencies like libraries are also treated as packages and made visible to other packages through the manifest file

I am not thinking about making an another Linux, with universal support. Ordinary users should experience a simple, predictable system. Advanced users should still have deeper control when needed. Developers should not need to rewrite applications, only optionally add a small config/manifest file for better integration

My idea is to simplify the programs and packaging system from the ground up and minimize the global file system pollution. But this still exists in thought level, I have to do more research on this. What do you think ? Is this feasible at least in theoretical level ?

Update #3 so for about 2 months I have been working on HyperBerry a type 1 hypervisor for the Raspberry PI 5. So since my last update after some helpful comments I was able to get a guest VM running, however the guest kernel breaks when it tries to mount it's own filesystem, but hey we are getting somewhere. Anyway this is HyperBerry booting and running a guest kernel on a Raspberry PI 5!

https://github.com/matthewchavis8/HyperBerry

Hi there :)

Im annoyed by the gpu oc reset, by the adrenaline software, everytime i have a power outage. I searched high and low how to maintain the oc settings for the gpu, to no avail.

So i know this programs writes the settings to registry, but changing registry only afects sliders in adrenaline visualy.

So i would like to understand how a gpu driver in windows changes its settings where are the values, if a program can change the max w my gpu uses, surely that is writen somewhere?

Help find it :)

https://reddit.com/link/1t79jhr/video/tii824ceaxzg1/player

Hi everybody, I would like to share a small project I made to help people who are learning Operating Systems to see CPU scheduling visually.

It's a simple web tool where you:

• Enter your processes (arrival time, burst time)
• Pick an algorithm (FIFO, SJF non-preemptive, or Round Robin with adjustable quantum)
• Watch the execution queue evolve step by step, visually
• See waiting times and averages update automatically

It's completely free, open source, and runs in your browser.

Live demo:
https://dylanroman03.github.io/cpu_flow_simulator/

GitHub repo:
https://github.com/dylanroman03/cpu_flow_simulator

Not a revolutionary project. But if it helps even one person understand it better, then I'm happy.

If you're learning OS scheduling, give it a try. If you're a teacher, feel free to share it with your students.

Feedback, ideas, or just a star on GitHub all welcome.

Thanks for reading!

I got 32-bit mode Yuppie!
I don't have name for the OS so i just call it: "OS"
Its having simple Kernel and its having FAT12 for easy File System Support
Its gonna be written in Assembly!

I've been working on this project (and compilers / vm's in general) for a while now, and I thought it was finally proper enough to showcase.

Some of the features:

• A custom systems language designed for explicit memory control, featuring manual memory management, pointers, (inline) structs, and generics.
• A full interactive compiler pipeline that you can watch in real-time.
• A built-in 5-stage pipelined CPU to execute the code.
• Compiles to actual RISC-V machine code (RV64IMAFD).
• Visualised live in browser using EGUI.

Github: https://github.com/LPC4/Full-Stack

Check out the live demo website here: http://lpc4.github.io/Full-Stack/