What an astounding achievement. In 6 years, this person has written not only a very well-designed microkernel, but a build system, UEFI bootloader, graphical shell, UI framework, and a browser engine.
The story of 10x developers among us is not a myth... if anything, it's understated.
Didn’t expect to see my project on the main page today ‘^^
Right now the build is broken, so you can’t test the full OS, but you can run individual apps with:
Impressive achievements, congrats! You said that your microkernel is "influenced by Zircon". Did you also study other architectures like e.g. sel4, Minix or openQNX? What do you consider the important design choices in your microkernel design? Is there a document where you go into this? Have you done performance measurements, i.e. to which other microkernel design do you think your kernel is comparable in terms of performance?
Thanks! Skift is basically a patchwork of all the OS ideas I like. The UI takes inspiration from SwiftUI/Flutter, the microkernel is influenced by Zircon, and there are some Plan 9 ideas where everything is a URL. A few bits are probably inspired by NT and Darwin too, though I don’t remember exactly which.
Maybe adding some Xerox PARC, Oberon, NeXTSTEP / NeWS style, Powershell ideas could also be interesting, on how the shell, UI, and dynamically loaded code (or OS IPC), makes the whole OS customizable, , just throwing another set of ideas into your bucket.
Hi monax, I would like to hear how you started the project. I am also currently trying to implement my own micro kernel, with hopes of doing something similar to SkiftOS in order to learn OS fundamentals, but I don't know how to start. What are the first things to tackle when taking on such a project?
I don’t know what I can tell you, I think where you start and how you start don’t really matter. The important thing is to keep going. These kinds of projects are a lot of work, and as long as you keep making progress, you’ll eventually get to what you want.
Thank you for the reply, one more thing. Did you study established code bases and/or books to guide you through the architecture process and initial implementation? If so, how do you take advantage of these resources without falling into the trap of "borrowing" implementation while trying to build your vision?
What you did here is really cool and inspiring :).
I always paste this book here when hobby OSes appear. I wrote my own GUI OS in the 90s and I couldn't have done it without this. Copies available on your usual shadow library I would imagine...
Wow, you did it yourself?! This is just wow, as a C/C++ developer I know how to create an OS, but at most I could come up with an idea, but writing all this myself, I have no words.
What ideas do you employ around security? Do apps have full access to memory? To hardware? Is there a permissions system? Sorry I'm not that familiar with how microkernels work.
Apps don’t get full access to memory or hardware. The kernel only maps what they’re allowed to see. Drivers live in user space, and apps talk to them through capabilities (handles you can pass around). There’s no ambient authority, you only get access if you’ve been given the key.
What about filesystem access rights? Does any application have full access to all user's files? Or only to files belonging to this particular application?
I dove deep into the code base. Found lib-sdl. Found impl-efi. Found co_return and co_await's. Found try's. Found composable classes. Found my codebase to be a mess compared to the elegance that is this. We are not worthy...
Kudos to the owner of this project. Well done. It is really modern C++ (with modules) and improvements on top. I see that it introduced some kind of GC and other high-level quality-of-life improvements. I noticed stuff like `co_try` and `.unwrap()` and `async`. Was it inspired by Rust? What plans do you have with this project?
Thank you! We need more GPOS options. We have been entrenched in the main 3. I think there's lots of room for making something better. [misaligned incentives?]
Every modern commercial OS is a hybrid architecture these days. Generally subsystems move out of the kernel when performance testing shows the cost isn't too high and there's time/money to do so. Very little moves back in, but it does happen sometimes (e.g. kernel TLS acceleration).
There's not much to say about it because there's never been an actual disagreement in philosophy. Every OS designer knows it's better for stability and development velocity to have code run in userspace and they always did. The word microkernel came from academia, a place where you can get papers published by finding an idea, giving it a name and then taking it to an extreme. So most microkernels trace their lineage back to Mach or similar, but the core ideas of using "servers" linked by some decent RPC system can be found in most every OS. It's only a question of how far you push the concept.
As hardware got faster, one of the ways OS designers used it was to move code out of the kernel. In the 90s Microsoft obtained competitive advantage by having the GUI system run in the kernel, eventually they moved it out into a userland server. Apple nowadays has a lot of filing systems run in userspace but not the core APFS that's used for most stuff, which is still in-kernel. Android moved a lot of stuff out of the kernel with time too. It has to be taken on a case by case basis.
Can you explain why TTY-PTY functionality hasn't been moved from the Linux kernel to userspace? Plan 9 did so in the 1990s or earlier (i.e., when Plan 9 was created, they initially put the functionality in userspace and left it there.)
I don't understand that, and I also don't understand why users who enjoy text-only interaction with computers are still relying on very old designs incorporating
things like "line discipline", ANSI control sequences and TERMINFO databases. A large chunk of cruft was introduced for performance reasons in the 1970s and even the 1960s, but the performance demands of writing a grid of text to a screen are very easily handled by modern hardware, and I don't understand why the cruft hasn't been replaced with something simpler.
In other words, why do users who enjoy text-only interaction with computers still emulate hardware (namely, dedicated terminals) designed in the 1960s and 1970s that mostly just displays a rectangular grid of monospaced text and consequently would be easy to implement afresh using modern techniques?
There a bunch of complexity in every terminal emulator for example for doing cursor-addressing. Network speeds are fast enough these days (and RAM is cheap enough) that cursor-addressing is unnecessary: every update can just re-send the entire grid of text to be shown to the user.
Also, I think the protocol used in communication between the terminal and the computer is stateful for no reason that remains valid nowadays.
The usual reason for all of this is that programmer time is expensive (even if you're a volunteer, you have limited hours available), and not many people want to volunteer to wade through tons of legacy tech debt. That's especially true when the outcome will be an OS that behaves identically to before. A lot of stuff stays in the kernel because it's just hard to move it out.
Bear in mind, moving stuff out of the kernel is only really worth it if you can come up with a reasonable specification for how to solve a bunch of new problems. If you don't solve them it's easy to screw up and end up with a slower system yet no benefit.
Consider what happens if you are overenthusiastic and try to move your core filesystem into userspace. What does the OS do if your filesystem process segfaults? Probably it can't do anything at that point beyond block everything and try to restart it? But every process then lost its connection to the FS server and so all the file handles are suddenly invalidated, meaning every process crashes. You might as well just panic and reboot, so, it might as well stay in the kernel. And what about security? GNU Hurd jumped on the microkernel bandwagon but ended up opening up security vulnerabilities "by design" because they didn't think it through deeply enough (in fairness, these issues are subtle). Having stuff be in the kernel simplifies your architecture tremendously and can avoid bugs as well as create them. People like to claim microkernels are inherently more secure but it's not the case unless you are very careful. So it's good to start monolithic and spin stuff out only when you're ready for the complexity that comes with that.
Linux also has the unusual issue that the kernel and userspace are developed independently, which is an obvious problem if you want to move functionality between the two. Windows and macOS can make assumptions about userspace that Linux doesn't.
If you want to improve terminals then the wrong place to start is fiddling with moving code between kernel and user space. The right place to start is with a brand new protocol that encodes what you like about text-only interaction and then try to get apps to adopt it or bridge old apps with libc shims etc.
>Consider what happens if you are overenthusiastic and try to move your core filesystem into userspace. What does the OS do if your filesystem process segfaults? Probably it can't do anything at that point beyond block everything and try to restart it? But every process then lost its connection to the FS server and so all the file handles are suddenly invalidated, meaning every process crashes. You might as well just panic and reboot, so, it might as well stay in the kernel.
I mean, it's not necessarily true that if a filesystem process crashes, every other process crashes. Depending on the design, each FS process may serve requests for each mountpoint, or for each FS type. That already is a huge boon to stability, especially if you're using experimental FSs. On top of that, I think the broken connection could be salvageable by the server storing handle metadata in the kernel and retrieving it when the kernel revives the process. It's hardly an insurmountable problem.
Sure it can all be solved, FUSE is an example of doing that for less important ancillary filesystems. I'd actually just make the protocol stateless and store fd state in the clients. My point is more general - the people who design operating systems know all about these tradeoffs and have to decide what to spend time on within a limited budget.
Consider: crash bugs are finite. Do you spend your time on complex rearchitecting of your OS to try and fail slightly less hard when some critical code crashes, or do you spend that time fixing the bugs? If the code is big, fast changing and third party then it might make sense to put in the effort, hence FUSE and why graphics drivers often run a big chunk of code out of kernel. If the code is small, stable and performance sensitive, like a core filesystem where all your executables reside, then it doesn't make sense and stays in.
Browsers also use a micro-kernelish concept these days. But they're very deliberate and measured about what gets split out into extra processes and what doesn't.
The microkernel concept advocates for ignoring engineering tradeoffs in order to put everything into userspace all the time, and says precious little about how to ensure that translates into actual rewards. That's why it's an academic concept that's hardly used today.
>crash bugs are finite. Do you spend your time on complex rearchitecting of your OS to try and fail slightly less hard when some critical code crashes, or do you spend that time fixing the bugs?
Finite can still be a very large number. Clearly the former is preferable, otherwise your argument applies just as well to usermode code. Why bother having memory protection when the code should be correct anyway?
Remember the CloudStrike bug? That wouldn't have happened had the developer been able to put the driver in user mode. The module was not critical, so the system could have kept on running and a normal service could have reported that the driver had failed to start due to an error. That's much, much, much preferable to a boot loop.
Everyone is responsible for their own software, but the OS is more critical than other pieces and also a lot more profitable, so they can afford to invest. Some userspace apps with large budgets do use microkernel architectures, most obviously browsers.
But by and large, kernel code is much more tightly scoped and stable than userspace apps. The requirements for a core filesystem change very slowly and a migration from one version to another can take years. Userspace apps might update every week and still be too slow. We tolerate much more instability in the latter than the former.
The engineering costs of moving things out of the kernel can be significant. If your OS isn't totally hosed then - third party drivers excepted - there's probably a finite number of bugs you have to solve to get reliability up above your target level. It can often make sense to just sit down and fix the bugs instead of moving code out of kernel space, which will take a long time and at the end the bugs will still be there and still need to be fixed.
This argument gets a lot weaker when you can't fix the bugs, or when code changes so frequently new bugs get added at the same rate they get fixed. AV scanners and GPU drivers are good examples of that. And they do tend to get moved out of kernel space. Most of CrowdStrike doesn't run in kernel mode, and arguably Microsoft should have kicked the remaining parts out of the kernel a long time ago. A big chunk of the GPU driver was already moved.
Unfortunately by the nature of what AV scanners are trying to do they try to get everywhere. I'm sure MS would love nothing more than to boot them out of Windows but that's an antitrust issue not a technical issue.
Some simpler CPU boards for embedded systems have no onboard graphics, they just have a serial port, so you have to use a terminal or terminal emulator to talk to them.
Nintendo's 3DS OS and Switch 1+2 OS are bespoke and strictly microkernel-based (with the exception of DMA-330 CoreLink DMA handling on 3DS if you want to count is as such), and these have been deployed on hundreds of millions of commercially-sold devices.
I would love to read a writeup when you do - I've been wanting to build a hobby OS with a database-like storage system and have been paralyzed about the design.
SkriftOS is impressive. It's very similar to a plan that I assumed I could only do as early-retirement avocation (if ever hit a startup equity lottery jackpot). I didn't imagine it could be done on the side.
What else does it have rather than beautiful UI? Network support? Sound? What file systems does it support? What about multiple users? What about applications isolation?
It would be nice to have such information displayed somewhere on the site.
It’s a microkernel-based operating system. Mostly just a learning/fun side project for me. It implements something akin to the NixOS /store. Hardware, networking, sound, and the file system are all very barebones. Most of the work so far has been put into the framework, some example apps, and the browser.
apologies for offtopic rant, but why cant they (palmsource/??) just open source BeOS codebase? what possible gain they can have by holding onto 20yo codebase just out of licensing spite. honestly for all the do-gooder talk in VC community this is the easiest thing to achieve. have a funding clause that if your company dies then all rights of unfinished works goto investors and by charter opensource it for benefit of other startups. we could have had greatness many times over.
Because it costs money to open source something as large as an OS, because you need to vet the source base to ensure that you own the rights to publish all of the source code under whichever license. To execs, it looks like throwing money into the toilet.
thats a strawman, here's a summary of ownership from google:
Be Inc. => Palm => PalmSource => ACCESS Co.
this is ho many times they moved it around or sold it. each one of these times they had to do due diligence before same as you do with any ip acquisition. okay if you dont want to do full opensource, how about taking a few modules and just bsd-3 or MIT-ing them. it shows Intent, how many time any VC has done this in last 20 years? none that I recall. this is the problem, big do-gooder talk about changing the world, but at the end of day they are out to JUST make money.
Hmm... what about wider hardware support? How difficult would be to port/adapt/etc libre drivers from other OS (linux comes to mind) considering SkiftOS is microkernel? :)
I was an early adopter of Copilot, but over time I found myself using it less and less. Now I’ve removed AI assistants from all my editors entirely. The way they’re integrated into IDEs feels distracting and intrusive, and honestly, I love coding, so why automate the fun part?
Awesome! I’ve been waiting for this feature since 2020, and having them finally working is so cool. I haven’t migrated all the code yet, but it’s heading in the right direction
What an astounding achievement. In 6 years, this person has written not only a very well-designed microkernel, but a build system, UEFI bootloader, graphical shell, UI framework, and a browser engine.
The story of 10x developers among us is not a myth... if anything, it's understated.
And unlike a similar project, they accomplished it without the benefit of divine guidance.
Very impressive!
The greatest programmer who ever lived. Gifted with divine intellect.
[dead]
[flagged]
Not with Messiah.ai :D
Oh my God. That domain is parked and for sale for $125,000?!?!
Wild.
Oh that is nothing. Check out god.ai..... domain parking is back. At this point we might as well just have a TLD for .god
> TLD for .god
Sounds like a good TLD for an "identity and access management" system :)
Musk would just hog it for himself
You might enjoy reading the SerentiyOS progress reports
https://serenityos.org/
I want serenity now
https://www.youtube.com/watch?v=LW_s6EqOxqY
Yeah it’s amazing.
Didn’t expect to see my project on the main page today ‘^^ Right now the build is broken, so you can’t test the full OS, but you can run individual apps with:
```bash ./skift.sh run --release <app-name> ```
on Linux or macOS.
To see all available apps:
```bash ls ./src/apps ```
This works for everything except the browser. For that, use:
```bash ./skift.sh run --release vaev-browser -- <url-or-file> ```
The HTTP stack is super barebones, so it only supports `http://` (no HTTPS). It works with my site, but results may vary elsewhere.
Most of my time so far has gone into the styling and layout engine rather than networking.
Impressive achievements, congrats! You said that your microkernel is "influenced by Zircon". Did you also study other architectures like e.g. sel4, Minix or openQNX? What do you consider the important design choices in your microkernel design? Is there a document where you go into this? Have you done performance measurements, i.e. to which other microkernel design do you think your kernel is comparable in terms of performance?
Kudos for exploring other avenues outside UNIX.
Thanks! Skift is basically a patchwork of all the OS ideas I like. The UI takes inspiration from SwiftUI/Flutter, the microkernel is influenced by Zircon, and there are some Plan 9 ideas where everything is a URL. A few bits are probably inspired by NT and Darwin too, though I don’t remember exactly which.
Sounds like really solid ideas. You must have a lot of experience to inspire yourself from so many diverse niche worlds. GL!
Maybe adding some Xerox PARC, Oberon, NeXTSTEP / NeWS style, Powershell ideas could also be interesting, on how the shell, UI, and dynamically loaded code (or OS IPC), makes the whole OS customizable, , just throwing another set of ideas into your bucket.
Overall it looks interesting, all the best.
Skift, Karm, Hjert, Opstart.
As a Norwegian, the name of this system and those components sound Danish (Skift, Karm, Opstart) and Danish-inspired (Hjert). Am I right? :)
Yes, you're right, I found the Danish word cool-sounding
Hi monax, I would like to hear how you started the project. I am also currently trying to implement my own micro kernel, with hopes of doing something similar to SkiftOS in order to learn OS fundamentals, but I don't know how to start. What are the first things to tackle when taking on such a project?
I don’t know what I can tell you, I think where you start and how you start don’t really matter. The important thing is to keep going. These kinds of projects are a lot of work, and as long as you keep making progress, you’ll eventually get to what you want.
Thank you for the reply, one more thing. Did you study established code bases and/or books to guide you through the architecture process and initial implementation? If so, how do you take advantage of these resources without falling into the trap of "borrowing" implementation while trying to build your vision?
What you did here is really cool and inspiring :).
I always paste this book here when hobby OSes appear. I wrote my own GUI OS in the 90s and I couldn't have done it without this. Copies available on your usual shadow library I would imagine...
https://us.amazon.com/Developing-32-Bit-Operating-System-Cd-...
How much time did it take you to get the project to this phase?
I had multiple rewrites, but this last iteration is two years old
How long did the first iteration take?
This is the kind of project that allows you to have a 2 line CV:
contact: your e-mail
skills: project website
and you'd get hired in a ton of places.
Wow, you did it yourself?! This is just wow, as a C/C++ developer I know how to create an OS, but at most I could come up with an idea, but writing all this myself, I have no words.
I had some help for the browser engine
The code is really well written - very understandable and modern, kudos on that!
I'm curious, how come the app I just compiled works on macOS?
The framework has a layer of OS abstraction, and uses SDL to create the window and get user inputs
How devs can create something like this with normal time constrains? I couldn't squeeze this kind of project having day to day 9 to 5 job as dev.
You don't! Most of it was written during a phase of my life where I had barely any social life '^^
I wonder the same thing.
What ideas do you employ around security? Do apps have full access to memory? To hardware? Is there a permissions system? Sorry I'm not that familiar with how microkernels work.
Apps don’t get full access to memory or hardware. The kernel only maps what they’re allowed to see. Drivers live in user space, and apps talk to them through capabilities (handles you can pass around). There’s no ambient authority, you only get access if you’ve been given the key.
What about filesystem access rights? Does any application have full access to all user's files? Or only to files belonging to this particular application?
Applications will each have their own namespace, and will only have access to user files if given the right to, on a per directory/file basis
This is a very nice approach. You should mention it on the main page of your OS site.
Interesting. Thanks.
This looks really cool! congratulations to the person who made this! Is there a video demo of this somewhere?
I am amazed that you also managed to write a browser engine!
Video demo would be amazing.
It should be embedded into the website alongside the pictures, in a carousel.
Obviously not her first rodeo...
I dove deep into the code base. Found lib-sdl. Found impl-efi. Found co_return and co_await's. Found try's. Found composable classes. Found my codebase to be a mess compared to the elegance that is this. We are not worthy...
The modules... :chefs-kiss:
Kudos to the owner of this project. Well done. It is really modern C++ (with modules) and improvements on top. I see that it introduced some kind of GC and other high-level quality-of-life improvements. I noticed stuff like `co_try` and `.unwrap()` and `async`. Was it inspired by Rust? What plans do you have with this project?
Very impressive! Do you support GPUs or is the UI completely CPU rendered? It looks really beautiful.
It's CPU rendering, GPU is on the roadmap
Thank you! We need more GPOS options. We have been entrenched in the main 3. I think there's lots of room for making something better. [misaligned incentives?]
Slightly related and coming from ignorance here, but what is the general intuition for the pros and cons of a microkernel approach in OS development?
Every modern commercial OS is a hybrid architecture these days. Generally subsystems move out of the kernel when performance testing shows the cost isn't too high and there's time/money to do so. Very little moves back in, but it does happen sometimes (e.g. kernel TLS acceleration).
There's not much to say about it because there's never been an actual disagreement in philosophy. Every OS designer knows it's better for stability and development velocity to have code run in userspace and they always did. The word microkernel came from academia, a place where you can get papers published by finding an idea, giving it a name and then taking it to an extreme. So most microkernels trace their lineage back to Mach or similar, but the core ideas of using "servers" linked by some decent RPC system can be found in most every OS. It's only a question of how far you push the concept.
As hardware got faster, one of the ways OS designers used it was to move code out of the kernel. In the 90s Microsoft obtained competitive advantage by having the GUI system run in the kernel, eventually they moved it out into a userland server. Apple nowadays has a lot of filing systems run in userspace but not the core APFS that's used for most stuff, which is still in-kernel. Android moved a lot of stuff out of the kernel with time too. It has to be taken on a case by case basis.
Can you explain why TTY-PTY functionality hasn't been moved from the Linux kernel to userspace? Plan 9 did so in the 1990s or earlier (i.e., when Plan 9 was created, they initially put the functionality in userspace and left it there.)
I don't understand that, and I also don't understand why users who enjoy text-only interaction with computers are still relying on very old designs incorporating things like "line discipline", ANSI control sequences and TERMINFO databases. A large chunk of cruft was introduced for performance reasons in the 1970s and even the 1960s, but the performance demands of writing a grid of text to a screen are very easily handled by modern hardware, and I don't understand why the cruft hasn't been replaced with something simpler.
In other words, why do users who enjoy text-only interaction with computers still emulate hardware (namely, dedicated terminals) designed in the 1960s and 1970s that mostly just displays a rectangular grid of monospaced text and consequently would be easy to implement afresh using modern techniques?
There a bunch of complexity in every terminal emulator for example for doing cursor-addressing. Network speeds are fast enough these days (and RAM is cheap enough) that cursor-addressing is unnecessary: every update can just re-send the entire grid of text to be shown to the user.
Also, I think the protocol used in communication between the terminal and the computer is stateful for no reason that remains valid nowadays.
The usual reason for all of this is that programmer time is expensive (even if you're a volunteer, you have limited hours available), and not many people want to volunteer to wade through tons of legacy tech debt. That's especially true when the outcome will be an OS that behaves identically to before. A lot of stuff stays in the kernel because it's just hard to move it out.
Bear in mind, moving stuff out of the kernel is only really worth it if you can come up with a reasonable specification for how to solve a bunch of new problems. If you don't solve them it's easy to screw up and end up with a slower system yet no benefit.
Consider what happens if you are overenthusiastic and try to move your core filesystem into userspace. What does the OS do if your filesystem process segfaults? Probably it can't do anything at that point beyond block everything and try to restart it? But every process then lost its connection to the FS server and so all the file handles are suddenly invalidated, meaning every process crashes. You might as well just panic and reboot, so, it might as well stay in the kernel. And what about security? GNU Hurd jumped on the microkernel bandwagon but ended up opening up security vulnerabilities "by design" because they didn't think it through deeply enough (in fairness, these issues are subtle). Having stuff be in the kernel simplifies your architecture tremendously and can avoid bugs as well as create them. People like to claim microkernels are inherently more secure but it's not the case unless you are very careful. So it's good to start monolithic and spin stuff out only when you're ready for the complexity that comes with that.
Linux also has the unusual issue that the kernel and userspace are developed independently, which is an obvious problem if you want to move functionality between the two. Windows and macOS can make assumptions about userspace that Linux doesn't.
If you want to improve terminals then the wrong place to start is fiddling with moving code between kernel and user space. The right place to start is with a brand new protocol that encodes what you like about text-only interaction and then try to get apps to adopt it or bridge old apps with libc shims etc.
>Consider what happens if you are overenthusiastic and try to move your core filesystem into userspace. What does the OS do if your filesystem process segfaults? Probably it can't do anything at that point beyond block everything and try to restart it? But every process then lost its connection to the FS server and so all the file handles are suddenly invalidated, meaning every process crashes. You might as well just panic and reboot, so, it might as well stay in the kernel.
I mean, it's not necessarily true that if a filesystem process crashes, every other process crashes. Depending on the design, each FS process may serve requests for each mountpoint, or for each FS type. That already is a huge boon to stability, especially if you're using experimental FSs. On top of that, I think the broken connection could be salvageable by the server storing handle metadata in the kernel and retrieving it when the kernel revives the process. It's hardly an insurmountable problem.
Sure it can all be solved, FUSE is an example of doing that for less important ancillary filesystems. I'd actually just make the protocol stateless and store fd state in the clients. My point is more general - the people who design operating systems know all about these tradeoffs and have to decide what to spend time on within a limited budget.
Consider: crash bugs are finite. Do you spend your time on complex rearchitecting of your OS to try and fail slightly less hard when some critical code crashes, or do you spend that time fixing the bugs? If the code is big, fast changing and third party then it might make sense to put in the effort, hence FUSE and why graphics drivers often run a big chunk of code out of kernel. If the code is small, stable and performance sensitive, like a core filesystem where all your executables reside, then it doesn't make sense and stays in.
Browsers also use a micro-kernelish concept these days. But they're very deliberate and measured about what gets split out into extra processes and what doesn't.
The microkernel concept advocates for ignoring engineering tradeoffs in order to put everything into userspace all the time, and says precious little about how to ensure that translates into actual rewards. That's why it's an academic concept that's hardly used today.
>crash bugs are finite. Do you spend your time on complex rearchitecting of your OS to try and fail slightly less hard when some critical code crashes, or do you spend that time fixing the bugs?
Finite can still be a very large number. Clearly the former is preferable, otherwise your argument applies just as well to usermode code. Why bother having memory protection when the code should be correct anyway?
Remember the CloudStrike bug? That wouldn't have happened had the developer been able to put the driver in user mode. The module was not critical, so the system could have kept on running and a normal service could have reported that the driver had failed to start due to an error. That's much, much, much preferable to a boot loop.
Everyone is responsible for their own software, but the OS is more critical than other pieces and also a lot more profitable, so they can afford to invest. Some userspace apps with large budgets do use microkernel architectures, most obviously browsers.
But by and large, kernel code is much more tightly scoped and stable than userspace apps. The requirements for a core filesystem change very slowly and a migration from one version to another can take years. Userspace apps might update every week and still be too slow. We tolerate much more instability in the latter than the former.
...What? How is that a response to anything I said?
Let me try again.
The engineering costs of moving things out of the kernel can be significant. If your OS isn't totally hosed then - third party drivers excepted - there's probably a finite number of bugs you have to solve to get reliability up above your target level. It can often make sense to just sit down and fix the bugs instead of moving code out of kernel space, which will take a long time and at the end the bugs will still be there and still need to be fixed.
This argument gets a lot weaker when you can't fix the bugs, or when code changes so frequently new bugs get added at the same rate they get fixed. AV scanners and GPU drivers are good examples of that. And they do tend to get moved out of kernel space. Most of CrowdStrike doesn't run in kernel mode, and arguably Microsoft should have kicked the remaining parts out of the kernel a long time ago. A big chunk of the GPU driver was already moved.
Unfortunately by the nature of what AV scanners are trying to do they try to get everywhere. I'm sure MS would love nothing more than to boot them out of Windows but that's an antitrust issue not a technical issue.
I think the fact that the line protocol for DEC VT terminals is as the ANSI X3.64 standard is why the issue hasn’t been addressed or modernized
See https://en.m.wikipedia.org/wiki/ANSI_escape_code
Some simpler CPU boards for embedded systems have no onboard graphics, they just have a serial port, so you have to use a terminal or terminal emulator to talk to them.
> Every modern commercial OS
Every +*general-puprose OS.
Nintendo's 3DS OS and Switch 1+2 OS are bespoke and strictly microkernel-based (with the exception of DMA-330 CoreLink DMA handling on 3DS if you want to count is as such), and these have been deployed on hundreds of millions of commercially-sold devices.
Microkernels are conceptually cleaner, and easier to make secure, but in practice generally slower than unikernels.
Gernot Heiser would strongly disagree with you on the last one :D
This is your chance! As a clean slate design, you can abandon the concept of a hierarchal file system and replace it with rdbms.
Yeah, an RDBMS would be nice, I still need to figure out the concrete implementation.
https://www.silicon.co.uk/data-storage/database/tales-tech-h...
Just inspiration.
I would love to read a writeup when you do - I've been wanting to build a hobby OS with a database-like storage system and have been paralyzed about the design.
Awesome project!
Looking forward to seeing it included in the next CCC CTF, like SerenityOS [0].
[0] https://2019.ctf.link/internal/challenge/1fef0346-a1de-4aa4-...
SkriftOS is impressive. It's very similar to a plan that I assumed I could only do as early-retirement avocation (if ever hit a startup equity lottery jackpot). I didn't imagine it could be done on the side.
That looks like alot of work, am surprised they built a custom build system, tho given the state of C++ build systems I can't really blame them.
Also why do OS devs seem to have a thing for making browsers? Shouldn't browsers be mostly agnostic to the OS?
The UI looks nice :)
Browsers are just application runtime ;)
What else does it have rather than beautiful UI? Network support? Sound? What file systems does it support? What about multiple users? What about applications isolation?
It would be nice to have such information displayed somewhere on the site.
It’s a microkernel-based operating system. Mostly just a learning/fun side project for me. It implements something akin to the NixOS /store. Hardware, networking, sound, and the file system are all very barebones. Most of the work so far has been put into the framework, some example apps, and the browser.
apologies for offtopic rant, but why cant they (palmsource/??) just open source BeOS codebase? what possible gain they can have by holding onto 20yo codebase just out of licensing spite. honestly for all the do-gooder talk in VC community this is the easiest thing to achieve. have a funding clause that if your company dies then all rights of unfinished works goto investors and by charter opensource it for benefit of other startups. we could have had greatness many times over.
rant over!
Because it costs money to open source something as large as an OS, because you need to vet the source base to ensure that you own the rights to publish all of the source code under whichever license. To execs, it looks like throwing money into the toilet.
thats a strawman, here's a summary of ownership from google: Be Inc. => Palm => PalmSource => ACCESS Co.
this is ho many times they moved it around or sold it. each one of these times they had to do due diligence before same as you do with any ip acquisition. okay if you dont want to do full opensource, how about taking a few modules and just bsd-3 or MIT-ing them. it shows Intent, how many time any VC has done this in last 20 years? none that I recall. this is the problem, big do-gooder talk about changing the world, but at the end of day they are out to JUST make money.
Hmm... what about wider hardware support? How difficult would be to port/adapt/etc libre drivers from other OS (linux comes to mind) considering SkiftOS is microkernel? :)
Looks awesome. Consider it bookmarked.
I'm on macOS, and still no luck building the code. But anything which doesn't involve building a custom GCC easily gets my vote :)
Looks amazing! Out of curiosity: how much (if at all) did you use AI to write code?
I was an early adopter of Copilot, but over time I found myself using it less and less. Now I’ve removed AI assistants from all my editors entirely. The way they’re integrated into IDEs feels distracting and intrusive, and honestly, I love coding, so why automate the fun part?
I find every project of this nature so so beautiful and incredible. Congrats.
So very lovely.
so cool! building from past 6 years (impressive)
Looks beautiful.
What a great project.
damn this is really good. I hope the register folk sees this.
"You need to enable JavaScript to run this app."
Nope. Unless your hobby OS also has a browser with a JS interpreter... which would be even more impressive.
looks like a cool project
dang, so cool
[flagged]
Looks great. I did pick up pretty strong NIH vibes, though. As an example, would CMake or Meson not work as a build system?
Meson doesn't support C++20 modules, cmake is not my cup of tea, and most importantly it's fun hobby project so I do what I want :^)
Makes sense. How have you found C++20 modules?
Awesome! I’ve been waiting for this feature since 2020, and having them finally working is so cool. I haven’t migrated all the code yet, but it’s heading in the right direction
Wait, modules work now? Maybe it's time to give them a shot, at least for my own code...