Add OS design blog post
This commit is contained in:
parent
52308bd2b6
commit
755db73766
|
|
@ -0,0 +1,129 @@
|
|||
---
|
||||
title: OS Design
|
||||
description: Most OSs suck
|
||||
categories: [technology,projects]
|
||||
published_date: "2022-03-22 21:29:00 +0000"
|
||||
layout: default.liquid
|
||||
is_draft: false
|
||||
---
|
||||
# Operating System Design
|
||||
|
||||
Recently I've been "working" on a project called [GayBSD](https://bsd.gay).
|
||||
|
||||
Most of the work at this point is designing and planning stuff. There's not really been much actual programming going on,
|
||||
since that's hard and requires knowing how everything is going to fit together.
|
||||
|
||||
> Just a note before we start: I know very little about programming, operating system design, and most other stuff here.
|
||||
> All of this is just from ideas I've came up with, or borrowed from other people. I have no idea how new any of these ideas are, or how well they'd actually work.
|
||||
> This is mainly just to get them out there, and maybe have a bit of fun.
|
||||
|
||||
## Bad Design
|
||||
I've been thinking a lot about how awfully designed lot's of modern tech is, including hardware, operating systems, software, etc.
|
||||
Lot's of that is just because it's all incredibly old. Terminal emulators are still based around and meant to be compatible with ancient teletype interfaces.
|
||||
|
||||
And backwards compatibility *is* good, it allows even old tech to be repurposed, but it also doesn't allow you to be very creative with designing stuff, or modernize it very well.
|
||||
Some terminal emulators try and do this, eg. [kitty](https://sw.kovidgoyal.net/kitty/) and [Alacritty](https://alacritty.org/index.html), by implementing better text formatting, the ability to view images, and other stuff.
|
||||
But they're still based around the TTY and being POSIX compliant. The main way to make any sort of interactive terminal UI is still just `ncurses`.
|
||||
|
||||
The Linux kernel is massive, with millions of lines of code. Trying to read through and understand it would be impossible.
|
||||
Again, that's mainly due to backwards compatibility, and just a bunch of legacy code. It still relies on C, even though at this point it doesn't even make much sense for modern processors *[1]*.
|
||||
|
||||
## Good (maybe) Design
|
||||
It would take an incredible amount of work to design a fully featured operating system, that runs most applications, from scratch.
|
||||
It's pretty much impossible. It's like a web browser.
|
||||
|
||||
What *would* be possible however, is a small "toy" operating system, built from scratch, with all of this design knowledge in mind.
|
||||
An operating system based on all the knowledge gained over the decades, but without the burden of needing to be fully compatible with every piece of hardware & software.
|
||||
|
||||
It would never be widely adopted. It probably could only run a couple ported Linux programs. Might run on one or two processors.
|
||||
But I think that's good enough. It'd be fun to try. Might be possible to apply some concepts from it to a Linux/BSD distro.
|
||||
|
||||
## Plans
|
||||
GayBSD right now is based on the core code of FreeBSD. That means nothing except userspace utils and similar bits & pieces we design will be able to follow these design ideas, unless we do a massive rewrite of all the core code, which doesn't make much sense.
|
||||
|
||||
I still think it'd be good to work on however, even just to get some experience with designing an OS, and it'll probably be able to be more useful to people as well.
|
||||
I can also try out some more ideas with programs and designs, being able to implement and try them out without having to write a whole OS beforehand.
|
||||
|
||||
Eventually though, at some point, I actually want to design a whole operating system, from scratch, following these principles.
|
||||
There are a [couple](https://os.phil-opp.com/) [guides](https://github.com/rust-embedded/rust-raspberrypi-OS-tutorials) for writing an OS in Rust, which I'll probably look at and maybe follow.
|
||||
I still need to learn a *lot* more before I even attempt any of this.
|
||||
|
||||
I don't even know what the best language to write this in would be. I like Rust, but it still follows the C design, which again, kind of sucks *[2]*.
|
||||
|
||||
Another, even more unlikely idea I have, is to design a *CPU* from scratch. Designed to be small and easy to understand, with a custom designed assembly language designed to be (fairly) human readable.
|
||||
I could then implement this operating system with that language, therefore in a way designed to take advantage of how modern processors work.
|
||||
A nice side effect would be having an assembly language that doesn't suck.
|
||||
|
||||
My goal for that language would be to have the same low-level control as assembly, but feasible to write programs in like C.
|
||||
Again, I also know nothing about programming language design, so I'd have to learn a lot more about that before I attempt this.
|
||||
|
||||
## Specific Ideas
|
||||
There are a couple specific ideas I have for things in the OS, other than just "modern design" and basing it around how CPUs actually work now.
|
||||
I'll be going through a few here.
|
||||
|
||||
### Package Manager
|
||||
A lot of package managers right now suck. I've heard some good things about how NixOS and Guix do stuff, but I haven't actually had the chance to try them out yet.
|
||||
|
||||
My goals for an ideal package manager would be, in order of importance:
|
||||
1. User friendly
|
||||
> It should be very easy to understand and use, even by beginners. It should also be fairly simple to create packages for.
|
||||
|
||||
2. Modular
|
||||
> It should be able to work with different workflows and setups, and different OS designs.
|
||||
|
||||
3. Powerful
|
||||
> While being easy to understand, it should also have lot's of options for power users.
|
||||
|
||||
4. Distributed
|
||||
> Instead of relying on some central repository, it should be able to fetch packages from multiple different sources, and it should be easy to add new package sources
|
||||
|
||||
Another important thing I think it should implement, is an easy way to transfer configurations between setups, sort of like Guix does *[3]*.
|
||||
|
||||
I also think sandboxing is an important feature.
|
||||
> Note: I don't think sandboxing is the right word for this, but I don't know what else to call it
|
||||
|
||||
I want something sort of like Python's virtual environments.
|
||||
I want to be able to install packages just for a certain package I want to build, without having to install it system wide.
|
||||
It would then be easy to install multiple versions of a package at once for different things, and easy to cleanse the packages you don't need anymore after building a program.
|
||||
|
||||
### Terminal
|
||||
Like I said earlier, even modern terminal emulators suck.
|
||||
I want to design a terminal, still based around text, but with a modern design.
|
||||
|
||||
It should be able to work well with a screen reader, have lot's of formatting options, not just for text, but for layout as well.
|
||||
Programs should provide a mix of layout and content information, with exact styling being handled by the terminal itself.
|
||||
|
||||
It should be able to handle multimedia such as images and videos, while still keeping in mind it's meant to be text oriented.
|
||||
|
||||
Consequently, there should be a simple, easy to use, but still powerful, library to create this content.
|
||||
|
||||
It follows that the shell should also be radically different. Designed to be human readable, and simple to use.
|
||||
I'd like it to be more verbose than how most shells usually are too.
|
||||
|
||||
### Desktop Environments
|
||||
Writing a good desktop environment is hard. Most ones nowadays suck in atleast a few ways.
|
||||
|
||||
GNOME looks nice, and is fun to use, but not very customizable, and GTK is confusing and hard to work with.
|
||||
|
||||
KDE is highly customizable, and working on being quite lightweight (I've heard), but doesn't look the best imo, and still has some usability problems
|
||||
|
||||
Also the support for screen readers is apparently not the best in most of these.
|
||||
|
||||
There are a lot more desktop environments, but I haven't used them enough to provide much info on them, plus I assume most of these points would apply to them too.
|
||||
|
||||
A good desktop environment would look good & have good design, while being highly customizable, and easy to do so.
|
||||
Developing an app for it should be simple instead of frustrating.
|
||||
It should globally respect user preferences and customizations.
|
||||
|
||||
### Fun Stuff
|
||||
An operating system should be fun to use.
|
||||
|
||||
For my ideal system, it'd have a cute interface theme, keygen music during the install, and other neat features.
|
||||
|
||||
If it's not going to be a mainstream thing, I might as well have a bit of fun with it, make it different to use, not just from a design perspective.
|
||||
|
||||
|
||||
## Citations
|
||||
1. [C Is Not a Low-level Language](https://queue.acm.org/detail.cfm?id=3212479), by **David Chisnal**
|
||||
2. [C Isn't A Programming Language Anymore](https://gankra.github.io/blah/c-isnt-a-language/), by **Aria Beingessner**
|
||||
3. [Keeping one’s home tidy](https://guix.gnu.org/blog/2022/keeping-ones-home-tidy/), by **Ludovic Courtès**
|
||||
Loading…
Reference in New Issue