CharlotteOS – An Experimental Modern Operating System

172 pointsposted 3 months ago
by ementally
(github.com)

26 Comments

embedding-shape

3 months ago

This is probably a better introduction it seems, than specifically the kernel of the OS: https://github.com/charlotte-os/.github/blob/main/profile/RE...

> 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.

Philpax

3 months ago

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.

LavenderDay3544

3 months ago

OP here.

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.

KerrAvon

3 months ago

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.

incognito124

3 months ago

Recompiling the whole kernel just to change drivers seems like a deal-breaker for wider adoption

BobbyTables2

3 months ago

Wish OP had put that as the main readme.

The intro page is currently useless.

jadbox

3 months ago

In theory, wouldn't it be possible for the Linux kernel to also provide a URI "auto mount" extension too?

whatpeoplewant

3 months ago

This looks like a very interesting project! Good luck to the team.

bionsystem

3 months ago

I believe redox is doing the same (the everything as an URI part)

user3939382

3 months ago

I’m working on one with a completely new hardware comms networking infra stack everything

the__alchemist

3 months ago

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.

grepfru_it

3 months ago

Haiku, plan9, redox, and Hurd comes to mind

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

LavenderDay3544

3 months ago

Linux is a big corp OS. Look at who the biggest contributors are and who funds the Linux foundation, ultimately paying Linus and friends' salaries.

ogogmad

3 months ago

> Package managers and compiling-from-source instead of distributing runnable applications directly.

Docker tries to partially address this, right?

> Dependence on CLI, and steep learning curve.

I think this is partially eased by LLMs.

Zardoz84

3 months ago

BSD exists Also Open Solaris Minix etc...

ofrzeta

3 months ago

So, what's modern about it? "novel systems like Plan 9" is quite funny because Plan 9 is 30 years old.

kragen

3 months ago

It's comforting to see that capabilities with mandatory access control have become the new normal.

jancsika

3 months ago

> GPLv3 or later (with proprietary driver clarification)

What's that parenthetical mean?

not4uffin

3 months ago

I’m very happy I’m seeing more open source kernels being released.

More options (and thus) competition is very healthy.

shevy-java

3 months ago

Written in Rust. Hmm.

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.

ForHackernews

3 months ago

How does this compare to SerenityOS? At a glance, it looks more modern and free from POSIX legacy?

pjmlp

3 months ago

Interesting, and kudos for trailing other paths, and not being yet another POSIX clone.

varispeed

3 months ago

Modern operating system, ready to face challenges of today political landscape, should natively support "hidden" encrypted containers, that is you would log in to completely different, separate environment depending on password. So that when under threat could disclose a password to an environment you are willing to share and attacker would have no way of proving there is any other environment present.