> URIs as namespace paths allowing access to system resources both locally and on the network without mounting or unmounting anything
This is such an attractive idea, and I'm gonna give it a try just because I want something with this idea to succeed. Seems the project has many other great ideas too, like the modular kernel where implementations can be switched out. Gonna be interesting to see where it goes! Good luck author/team :)
Edit: This part scares me a bit though: "Graphics Stack: compositing in-kernel", but I'm not sure if it scares me because I don't understand those parts deeply enough. Isn't this potentially a huge hole security wise? Maybe the capability-based security model prevents it from being a big issue, again I'm not sure because I don't think I understand it deeply or as a whole enough.
The choice of a pure-monolithic kernel is also interesting; I can buy that it's more secure, but having to recompile the kernel every time you change hardware sounds like it would be pretty tedious. Early days, though, so we'll see how that decision works out.
Why would you buy it’s more secure. Traditionally in windows in-kernel compositing was a constant source of security vulnerabilities. Sure rust may help the obvious memory corruption possibilities but I’m not convinced.
Why would you need to recompile if hardware changes? Linux manages just fine as a monolithic kernel that ships with support for many devices in the same kernel build.
Incremental compilation makes that a lot less heavyweight than you would think and the idea is to automate the process so the average non-technical user doesn't need to know or care how it works.
The plan is to hand out panes which are just memory buffers to which applications write pixel data as they would on a framebuffer then when the kernel goes to actually refresh the display it composites any visible panes onto the back buffer and then swaps buffers. There is nothing unsafe about that any more so than any other use of shared memory regions between the kernel and userspace and those are quite prolific in existing popular OSes.
If anything the Unix display server nonsense is overly convoluted and far worse security wise.
Does this mean that window management has to be handled in the kernel? Or is there some process that tells the kernel where those panes should be relative to one another/the framebuffer?
In practice, the problem with URIs is that it makes parsing very complex. You don’t really want a parser of that complexity in the kernel if you can avoid it, for performance reasons if nothing else. For low-level resource management, an ad-hoc, much simpler standard would be significantly better.
Chuck Multiaddr in there (https://multiformats.io/multiaddr/), can be used for URLs, file paths, network addresses, you name it. Easy to parse as well.
Recompile (or at least relink) the kernel to change drivers (or even system configuration) is a bit of a blast from the past - in the 1960s thru 1980s it used to be a very common thing, it was called “system generation”. It was found in mainframe operating systems (e.g. OS/360, OS/VS1, OS/VS2, DOS/360); in CP/M; in Netware 2.x (3.x onwards dropped the need for it)
Most of these systems came with utilities to partially automate the process, some kind of config file to drive it, Netware 2.x even had TUI menuing apps (ELSGEN, NETGEN) to assist in it
If this kernel ever gets big enough where this might matter, I'm sure they can change the design. Nothing is set in stone forever and for the foreseeable future it's unlikely to matter.
Why? It can be fully automated just like dynamic module download and loading are.
Incremental compilation means you don't have to recompile everything just compile the new driver as a library and relink the kernel and you're done. Keep the prior n number of working ones around in case the new one doesn't work.
To be fair, the submission URL goes to the kernel specifically, so the README is good considering the repository it's in. The link I put earlier I found via the GitHub organization, which does give you an overview of the OS as a whole (not just the kernel): https://github.com/charlotte-os/
Paths are not full URIs. You can do hacks like /https:/example.com/foo but.. why?
I'm personally not at all convinced having a scheme multiplexer in front is a good thing, for a namespace like what a kernel would manage. It's just not really any different from having top-level /foo and /bar, and introduces a bunch of special cases. Windows drive letters suck for a reason.
Thanks. And there isn't much of a permanent team so far so if anyone wants to help then I'd be happy to hear from them on our Discord, Matrix or by email at charlotte-os@outlook.com.
I love seeing projects in this space! Non-big-corp OSSes have been limited to Linux etc; would love to explore the space more and have non-Linux, non-MS/Apple options. For example, Linux has these at the core which I don't find to be a good match for my uses:
- Multi-user and server-oriented permissions system.
- Incompatible ABIs
- File-based everything; leads to scattered state that gets messy over time.
- Package managers and compiling-from-source instead of distributing runnable applications directly.
- Dependence on CLI, and steep learning curve.
If you're OK with those, cool! I think we should have more options.
I don't think they will like Plan9 if file based everything is a turn off.
Did you know the Go language supports Plan9? You can create a binary from any system using GOOS=plan9 with amd64 and i386 supported. You might need to disable CGO and use libraries that don't have operating system specifics though. You can even bootstrap Go from it provided you have the SDK.
But you can see the theme here: Adding more layers of complexity to patch things. LLMs do seem to do a better job than searching forum posts! I would argue that Docker's point is to patch compatibility barriers in Linux.
They shouldn't have to. OS interfaces including commandline ones should be user oriented not bogged down by Unix dogma that was created wwhencomputerss used physical text terminals as their primary I/O device. It's not the 60s anymore and modern PC, servers, and embedded devices aren't ancient mainframes with physical terminal hardware where making everything appear to be a file and using convoluted scripting interfaces like the Unix shell made at least some sense.
The sad part is that there are too many ideas of old systems lost in a world that 30 years later seems too focused on putting Linux distributions everywhere.
Indeed. I am reminded of what Alan Kay has repeatedly referred to as a “pop culture” of computing that has become widespread in technical communities since the 1980s, when the spread of technology grew faster than educational efforts. One result is there are many inventions and innovations from the research community that never got adopted by major players. The corollary to “perfect is the enemy of the good” is good-enough solutions have amazingly long lifetimes in the marketplace.
There are many great ideas in operating systems, programming languages, and other systems that have been developed in the fast 30 years, but these ideas need to work with existing infrastructure due to costs, network effects, and other important factors.
What is interesting is how some of these features do get picked up by the mainstream computing ecosystem. Rust is one of the biggest breakthroughs in systems programming in decades, bringing together research in linear types and memory safety in a form that has resonated with a lot of systems programmers who tend to resist typical languages from the PL community. Some ideas from Plan 9, such as 9P, have made their way into contemporary systems. Features that were once the domain of Lisp have made their ways into contemporary programming languages, such as anonymous functions.
I think it would be cool if there were some book or blog that taught “alternate universe computing”: the ideas of research systems during the past few decades that didn’t become dominant but have very important lessons that people working on today’s systems can apply. A lot of what I know about research systems comes from graduate school, working in research environments, and reading sites like Hacker News. It would be cool if this information were more widely disseminated.
Yeah the more you read up on computing history from barely even 40 years ago, it seems that most of the things that we take for granted today became so more through politics (and in the case of Microsoft, bullying) than merit.
Plan 9 is novel compared to Unix which almost every OS in common use mimics. But the reference to Plan 9 was more as a nod to its namespace and suitability for distributed computing which partially inspired my design.
In an operating system course I attended it was mostly Unix and everyone was used to bashing Windows NT ("so crappy, bsod etc.") but we had Stallings' book and I was surprised to learn that NT was in many ways an improvement over Unix and Linux.
Specifically, "Users may link this kernel with closed-source binary drivers, including static libraries, for personal, internal, or evaluation use without being required to disclose the source code of the proprietary driver.".
Ok, even Doug Crockford has mucked around with licensing before, so this is definitely a digression and not aimed at CharlotteOS which looks fascinating:
I wish there was a social stigma in Open Source/Free Software to doing anything other than just picking a bog standard license.
I mean, we have a social stigma even for OS developers about rolling your own crypto primitives. Even though it's the same very general domain, we know from experience that someone who isn't an active, experienced cryptographer would have close to a zero percent chance of getting it right.
If that's true, then it's even less likely that a programmer is going to make legally competent (or even legally relevant) decisions when writing their own open source compatible license, or modifying an existing license.
I guess technically the "clarification" of a bog standard license is outside of my critique. Even so, their clarification is shoe-horned right there in a parenthetical next to the "License" heading, making me itchy... :)
There's a note in the repo that clarifies the meaning of the GPLv3 regarding the use of combining covered works with proprietary libraries when the resulting combined work is never conveyed. It doesn't modify the license, it just explains what it means in that specific case as we interpret it.
Also to be clear I am not a lawyer and nothing I say constitutes any form of legal advice.
I'd love some kind of meta-language that is easy to read and
write, easy to maintain - but fast. C, C++, Rust etc... are
not that easy to read, write and maintain.
Being maintainable comes down to code quality, comments, and documentation. These are thing that I really want to emphasize for this project but for now I'm just one guy and it's very early days so I have to focus developing core kernel components first.
Readit News
> URIs as namespace paths allowing access to system resources both locally and on the network without mounting or unmounting anything
This is such an attractive idea, and I'm gonna give it a try just because I want something with this idea to succeed. Seems the project has many other great ideas too, like the modular kernel where implementations can be switched out. Gonna be interesting to see where it goes! Good luck author/team :)
Edit: This part scares me a bit though: "Graphics Stack: compositing in-kernel", but I'm not sure if it scares me because I don't understand those parts deeply enough. Isn't this potentially a huge hole security wise? Maybe the capability-based security model prevents it from being a big issue, again I'm not sure because I don't think I understand it deeply or as a whole enough.
(You don't have to recompile the kernel if you put all the device drivers in it, just keep the object files around and relink it.)
The plan is to hand out panes which are just memory buffers to which applications write pixel data as they would on a framebuffer then when the kernel goes to actually refresh the display it composites any visible panes onto the back buffer and then swaps buffers. There is nothing unsafe about that any more so than any other use of shared memory regions between the kernel and userspace and those are quite prolific in existing popular OSes.
If anything the Unix display server nonsense is overly convoluted and far worse security wise.
Also the only approach for systems where people advocate for static linking everything, yet another reason why dynamic loading became a thing.
Most of these systems came with utilities to partially automate the process, some kind of config file to drive it, Netware 2.x even had TUI menuing apps (ELSGEN, NETGEN) to assist in it
Incremental compilation means you don't have to recompile everything just compile the new driver as a library and relink the kernel and you're done. Keep the prior n number of working ones around in case the new one doesn't work.
The intro page is currently useless.
I'm personally not at all convinced having a scheme multiplexer in front is a good thing, for a namespace like what a kernel would manage. It's just not really any different from having top-level /foo and /bar, and introduces a bunch of special cases. Windows drive letters suck for a reason.
Dead Comment
Reactos if you need something to replace windows
Implementing support for docker on these operating systems could give them the life you are looking for
Did you know the Go language supports Plan9? You can create a binary from any system using GOOS=plan9 with amd64 and i386 supported. You might need to disable CGO and use libraries that don't have operating system specifics though. You can even bootstrap Go from it provided you have the SDK.
Incidentally 9Front is a modern fork of Plan9.
Docker tries to partially address this, right?
> Dependence on CLI, and steep learning curve.
I think this is partially eased by LLMs.
Docker is a good way of turning a 2kb shell script into a 400mb container. It's not a solution.
Flatpak would be a better example.
There are many great ideas in operating systems, programming languages, and other systems that have been developed in the fast 30 years, but these ideas need to work with existing infrastructure due to costs, network effects, and other important factors.
What is interesting is how some of these features do get picked up by the mainstream computing ecosystem. Rust is one of the biggest breakthroughs in systems programming in decades, bringing together research in linear types and memory safety in a form that has resonated with a lot of systems programmers who tend to resist typical languages from the PL community. Some ideas from Plan 9, such as 9P, have made their way into contemporary systems. Features that were once the domain of Lisp have made their ways into contemporary programming languages, such as anonymous functions.
I think it would be cool if there were some book or blog that taught “alternate universe computing”: the ideas of research systems during the past few decades that didn’t become dominant but have very important lessons that people working on today’s systems can apply. A lot of what I know about research systems comes from graduate school, working in research environments, and reading sites like Hacker News. It would be cool if this information were more widely disseminated.
Your complaint is more pointless than what you're complaining about.
What's that parenthetical mean?
Specifically, "Users may link this kernel with closed-source binary drivers, including static libraries, for personal, internal, or evaluation use without being required to disclose the source code of the proprietary driver.".
I wish there was a social stigma in Open Source/Free Software to doing anything other than just picking a bog standard license.
I mean, we have a social stigma even for OS developers about rolling your own crypto primitives. Even though it's the same very general domain, we know from experience that someone who isn't an active, experienced cryptographer would have close to a zero percent chance of getting it right.
If that's true, then it's even less likely that a programmer is going to make legally competent (or even legally relevant) decisions when writing their own open source compatible license, or modifying an existing license.
I guess technically the "clarification" of a bog standard license is outside of my critique. Even so, their clarification is shoe-horned right there in a parenthetical next to the "License" heading, making me itchy... :)
Also to be clear I am not a lawyer and nothing I say constitutes any form of legal advice.
More options (and thus) competition is very healthy.
SerenityOS is written in C++.
I'd love some kind of meta-language that is easy to read and write, easy to maintain - but fast. C, C++, Rust etc... are not that easy to read, write and maintain.
easy to understand, maintain -> computer does more work for you to "figure things out" in a way that simply can't be optimal under al conditions.
TLDR: what you're asking for isn't really possible without some form of AGI