What is the idea behind AstrynnOS?
(Post from 16.10.2025 (DD.MM.YYYY))
As already said, I think the current (and well-known) available operating systems (OS) are not user-centered enough. I personally have only used Windows for most of my things and sometimes Linux for tasks I can’t easily do on Windows, but in both cases, I didn’t feel like I was at home. It’s software, but it’s not like we don’t talk about software with others — we talk about games, tools, and other stuff — but we rarely ever talk about the operating system itself, and if we do, it’s mostly negative. But now, let’s talk about the idea of AstrynnOS.
What is the idea of AstrynnOS?
AstrynnOS should be a place where you feel at home — even if you are only on your computer. When you start your computer, I want you to feel like you’ve arrived home and are safe. The system should be for people with no knowledge of technology, for people with a lot of knowledge, and everyone in between. It’s also for people who want an alternative, modern operating system that respects its users. No data will be sent to a server without the user knowing — and definitely not the user’s private data. AstrynnOS will also include features to make the OS more user-friendly. Here are some ideas I currently have that I want to implement:
fKernel
The fKernel (fallback kernel) is a system that decreases the need to restart — whether because of a kernel panic (better known as a Windows bluescreen), a system crash, or an operating system update. In all these cases, the fKernel would act as a system to reduce the number of required restarts. In short, the fKernel will mostly reinitialize the kernel if needed, and more.
DoorLock
A system that controls every access to files and directories to make sure apps don’t interact with things they are not allowed to. Every app is isolated and can only see its root directory. If it wants to see other files or directories, it needs to request permission to do so.
Example: If Program A wants to interact with files from Program B, it needs to request this. There are two scenarios:
1. Program B is running while Program A makes the request. DoorLock will then send the request to Program B to handle and respond (there will also be a default handler if developers don’t want to handle it themselves).
2. Program B is not running — in this case, the user will be prompted to make a decision on behalf of Program B.
(To make sure the user doesn’t get spammed with prompts, apps will be able to define “rules” for DoorLock, telling it how to decide on requests if Program B is not running.)
QuickStart (temporary name)
The user can add apps to QuickStart. The operating system will then analyze the first 4 seconds of the app’s start phase and the next 4 starts to log what the app requests during startup. With this information, the operating system can then load the app with the logged data into memory (RAM), so that the app can start much faster.
The app will only be loaded into memory if there is enough memory available and the operating system is idle — ensuring that the app won’t start until the user decides to start it. If memory gets low (a lot is in use), the allocated memory for already running programs will be used instead.
That’s not all, but these are some features I personally think would be great to introduce and have in an operating system. Of course, I’m still learning, as I said last time, but I’m sure that with time it will work out — and if not, then at least I learned something on the path to it.
Thank you for reading this,
Littleclone