Live data from Hacker News

CharlotteOS – An Experimental Modern Operating System

github.com

51–60 of 104 posts

Re: CharlotteOS – An Experimental Modern Operating System

#51
post #49
post #11

Earlier quoted context omitted.

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

There is actually a talk like that from like two years ago, have to see if I find it again.

Re: CharlotteOS – An Experimental Modern Operating System

#52

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 proje…

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

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

Re: CharlotteOS – An Experimental Modern Operating System

#53

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.

fast necessitates manual control -> more semantics for low level control) that need to be expressible, ie: more complex 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

What languages are easy to understand and maintain, anyway?

Re: CharlotteOS – An Experimental Modern Operating System

#54
post #35

> GPLv3 or later (with proprietary driver clarification) What's that parenthetical mean?

Looks like it's explained here: https://github.com/charlotte-os/Catten/blob/main/License/cla... 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... :)

Re: CharlotteOS – An Experimental Modern Operating System

#55

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…

BSD exists Also Open Solaris Minix etc...

I reckon each of these has at least 3/5 of the complaints the OP has about Linux, because they're all still Unix clones.

Re: CharlotteOS – An Experimental Modern Operating System

#56
post #14

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…

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

> Docker tries to partially address this, right?

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.

Re: CharlotteOS – An Experimental Modern Operating System

#57
post #35

Earlier quoted context omitted.

Looks like it's explained here: https://github.com/charlotte-os/Catten/blob/main/License/cla... 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 do…

OP here, it's not mucking around with the license just making sure people know how the GPLv3 works. You are not required to provide source code for the combined work unless it is conveyed. If you combine the covered work with closed source but don't convey the resulting product you are not required to provide any source to anyone.

Many people don't know that, hence the clarification note.

Re: CharlotteOS – An Experimental Modern Operating System

#58

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.

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.

Re: CharlotteOS – An Experimental Modern Operating System

#60

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

I don't know anything about SerenityOS so I can't really say but if you have any more specific questions I'd be happy to answer them.
Post reply on HN