OpenBSD Seeing Initial Work Land On Enabling 64-bit POWER

[dreich]

Use of C is inevitable due OS's own origins. Within constraints set by circumstances they are doing their best to be as secure as possible.

Compromising does not make OpenBSD extremely secure.

[rene]

"If wishers were horses, beggars would ride".

Use of C is inevitable due OS's own origins. Within constraints set by circumstances they are doing their best to be as secure as possible.

nope, ask the folks who write an OS in Rust (or Java previously) – https://www.youtube.com/watch?v=Voc6eUMmgvg

[kpedersen]

Compromising does not make OpenBSD extremely secure.

It is not a compromise. It is still the only valid choice.

Java cannot exist without a VM written in C.
Rust is rendered useless when interfacing with actual raw memory and hardware which is unsafe by its very nature.

Oddly enough C is safer to write than Rust unsafe sections because it is designed for it from the ground up. Rust's unsafe tags are a compromise.

Plus you had better hope OpenBSD developers write secure code. Most of the world depends on OpenSSH.

[pegasus]

Somehow I suspect OBSD users won't give flying fuck about "performance equaling complete shit" since their priorities lie elsewhere.

Having used openbsd as my primary desktop for the better half of the past decade, I can confirm that recent releases got very close to the point of being unusable. 6.6 had issues reading keyboard events, sometimes keys would get "stuck" for minutes without anything you could do. 6.7, to which I just upgraded (release tomorrow), can't even scroll this page smoothly without fully occupying all 4 cores for 10-15 seconds.
But it is still the best for what I need it for and no other unix or unix clone even comes close for this.

[cynic]

Having used openbsd as my primary desktop for the better half of the past decade, I can confirm that recent releases got very close to the point of being unusable. 6.6 had issues reading keyboard events, sometimes keys would get "stuck" for minutes without anything you could do. 6.7, to which I just upgraded (release tomorrow), can't even scroll this page smoothly without fully occupying all 4 cores for 10-15 seconds.
But it is still the best for what I need it for and no other unix or unix clone even comes close for this.

really?
I haven't used OpenBSD for a long time, how it became so bad?
is that an issued related to be a desktop machine (so, browser rendering and the like) or what?

[pegasus]

Combination of many things I guess ... security improvements by design, security improvements by necessity (intel...), dragging behind with gfx drivers due to lack of man power ... and probably some more things. This is why I'm very excited with the prospect of fully documented hardware such as these power machines running a paranoid OS such as OpenBSD. It will just take about 5 years before the combination is usable for normal people ...

[Volta]

Get back to me when Linux isn't complete and utter garbage.

Linux eats this crap for breakfast, so?

[jacob]

Rust is rendered useless when interfacing with actual raw memory and hardware which is unsafe by its very nature.

Not quite. Raw memory access in Rust is obviously unsafe by nature, but that essentially only concerns the actual memory addesses, alignment and in some cases, transmutation (i.e. unsafe dynamic casting). The rest of the code is safe, and Rust also retains all its other advantages like the strict and powerful type system, error handling, safety from data races, real generics, real modules (actually they suck compared to Ada's or OCaml's, but they are light years ahead of C's include files), and others.

The main obstacle I see at the moment to writing production OSes in Rust is rather the fact that the Rust compiler is very limited in terms of target platform support (especially if we stick to Tier-1 support, for a kernel you wouldn't want anything less). Especially compared to the wealth of architectures you can target with C.

[kpedersen]

Raw memory access in Rust is obviously unsafe by nature, but that essentially only concerns the actual memory addesses, alignment and in some cases, transmutation (i.e. unsafe dynamic casting). The rest of the code is safe, and Rust also retains all its other advantages like.

For an OS and drivers, there will be a lot of raw memory access. The bits that Rust can do safely could easily end up being unfortunately fairly small. Its like if we bolted on Lua, sure the Lua code will be 100% safe but it is on top of an abstraction that has no safety guarantees.

real modules (actually they suck compared to Ada's or OCaml's, but they are light years ahead of C's include files), and others.

A real module system is potentially my biggest issue with Rust. I feel that like NPM, PIP, etc, the dependencies will spiral out of control. This type of haphazard development will work poorly for a kernel.

Also, C header files are a weird one. They are not efficient but they make building very large projects possible. Not only is the preprocessor useful in this but the parsing nature of it (if forward declares are done right) allows for much larger codebases to be used than in smaller scale languages (Like Rust and Java's) "all in one" approach.

[jacob]

For an OS and drivers, there will be a lot of raw memory access. The bits that Rust can do safely could easily end up being unfortunately fairly small. Its like if we bolted on Lua, sure the Lua code will be 100% safe but it is on top of an abstraction that has no safety guarantees.

For raw memory access, the only unsafe part is assigning the pointer in the first place. Ultimately it can boil down to a single line

let mut blah = unsafe { from_raw_parts(...) };

All the rest can be and often is safe code. Check out Redox OS. The comparison with LUA is ridiculous, code compiled in Rust is native code that requires no interpreter, can be used even to implement interrupt handlers and generally is usable everywhere C is usable. Ultimately it all runs on top of a CPU that has no safety guarantees, but that does not change the fact that in the general case it is impossible to write provably safe code in C, whereas Rust does the same thing but can take you 90% of the journey towards safety provability.

A real module system is potentially my biggest issue with Rust. I feel that like NPM, PIP, etc, the dependencies will spiral out of control. This type of haphazard development will work poorly for a kernel.

Whatever you "feel" is obviously absurd. There is no relation in any shape or form between a module system and pulling in dependencies. You can define modules and require no external libraries at all, just like you can pull in a huge amount of libs and dependencies in C too (when using GTK, for example). There is absolutely nothing in Rust that would inherently take dependencies "out of control", the only difference between Rust and C in that regard is that in Rust the build system can guarantee which specific version of a library you are building against and which features of that library are compiled in, while in C there is no dependency control at all and you are extremely lucky if problems show up at build time and not at runtime (a shared library being absent, or a symbol missing or, worse, a symbol being there but the function in fact behaving differently...). Talk about haphazard.

Also, C header files are a weird one. They are not efficient but they make building very large projects possible. Not only is the preprocessor useful in this but the parsing nature of it (if forward declares are done right) allows for much larger codebases to be used than in smaller scale languages (Like Rust and Java's) "all in one" approach.

Again, this is patent nonsense. Modules are a key to managing large codebases, not an obstacle. Even C++, which is used for much larger projects than C, is moving away from include files and towards modules. Rust of course never mandated an "all in one" approach at all (neither does Java). In Rust the primary compilation unit is the crate, while in C it is the file + its dependencies, but obviously it is perfectly normal and expected for large codebases to consist of many crates. The Firefox source code, for example, has currently over 2 million lines of Rust, is that large enough for you?