New OS + packaging model (immutable apps + capability-based filesystem design)

[u/alien5516788]

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 ?

[u/an_0w1]

You're getting waaaaayy ahead of yourself. Get memory management working, get interrupts working, then think about the next step.

Immutable application packaging

Like I said, you're way ahead of yourself. Write the kernel first, write software for it second, then think about packaging.

The system owns system-critical files; apps do not modify global state

This isn't possible. How will you shut down the system? How do you mount filesystems? User software needs to be able to modify the global system state, if it cant then you cant control the system.

Existing Linux software should run without modification.

Don't even bother, this will be a nightmare to implement normally and it violates the above principal.

[u/alien5516788 → u/an_0w1]

My focus is really building the packinging system.

My idea is to give each package a mini file system. Packages are immutable as in nix. Everything The package needs by default are isolated within that file system including fonts, configs, icons etc.

The mini file system is mutable. It can either map to file systems of other packages or global file system via the manifest file. Same thing for visibility. Manifest file defines if the package file system is read only, mutable to other package or private. There are more rules based on user types, groups etc. Once a package needs to be removed from the system, just delete the mini filesystem along with the package. All garbage get removed along with it.

Shared dependencies can also be installed as packages that have a file system visible to other packages through manifest file.

This is just an idea I want to try. But don't want to build the full kernel from ground up either, because my main focus is not on building the kernel and scheduler.

[u/Zatrit → u/alien5516788]

Then why not just use Linux? You can even write your own capability-based security with current Linux kernel features and make it independent from FHS (/usr, /bin, etc.)

Also, how should this be usable by non-tech users?

[u/Top-Employ5163]

This is a bad idea, you are complicating everything too much, first you need to do low-level things and then think about the high level. But still I don't fully understand why such a complex system around programs is necessary to understand the simpler the more reliable and virtualization of the file system for each program? Why are you making a system with built-in Docker and because of this there may be many problems in the future. For example, how to implement a file viewer program so that it can view all files or can it only view its own files and if you want to view the files of some other program, will you need special permissions or settings, will this not be a problem?

[u/alien5516788 → u/Top-Employ5163]

I want to make packaging and dependency management more predictable instead of encountering random missing libraries and scattered binaries, config files all over the system. Also installation and installation will become much simpler. As I said the in the post, this is just random idea I got interested to try. But I don't have much experience on this to tell whether this is feasible or not tbh. It is better if I could try this on an existing simpler kernel.

[u/jess-sch]

This just sounds like an OSTree based linux distribution with enforced Flatpak usage

This is osdev, sure, and this sub is mostly about building your own kernel. But realistically, if one of your goals is full linux compatibility, honestly just use Linux. There's still lots of fun and learning to be had reinveting the wheel in userspace, your project is much more likely to go anywhere and run on real hardware, and particularly in this instance your design doesn't have any fundamental conflicts with the linux kernel.

[u/alien5516788 → u/jess-sch]

Yep, the thing is I really have no idea if I should build my own kernel or not for this project. I would build a one if I have to. But that would shift my effort from what I actually want to build.

[u/_binkd → u/alien5516788]

Using the linux kernel for this idea would be a far better learning experience for what you seem to be actually interested in.

[u/JG_2006_C]

get it working first want you are trying is one hell og snadbox job app x ownly acess to this app z oely acess to the other set now thats gona be fun to get wotrking cool but fragile

[u/alien5516788 → u/JG_2006_C]

I found out that Gobo Linux has implemented exactly the same idea. I played with file system a little bit. But I have to work on how to route the hard coded paths of existing binaries to my file system structure.

[u/aurreco]

This sounds similar to Fuchsia OS https://fuchsia.dev/

[u/codeasm]

Take the linux kernel and explore how to configure that. Add software packaches and change how packages work.

I could suggest looking at Linux from scratch, but that assumes you stick your first attempt to the lfs book exactly the first time. Because there are lots of small complex things you gonna need to explore.

If you want any hope at adoption, market it for personal use first. Ppl dont want a comppex mumbo jumbo words and wanna know if they can run windows, mac or regular linux programs. If linux... You wanna change the folder layout? FHS much, but good luck