Linked by subterrific on Mon 9th Jan 2017 22:25 UTC
OSNews, Generic OSes

Rux's goal is to become a safe general-purpose microkernel. It tries to take advantage of Rust's memory model - ownership and lifetime. While the kernel will be small, unsafe code should be kept minimal. This makes updating functionalities of the kernel hassle-free.

Rux uses a design that is similar to seL4. While there won't be formal verification in the short term, it tries to address some design issues of seL4, for example, capability allocation.

The code is very approachable for anyone interested in capability-based microkernel design.

Order by: Score:
New breed of robust operating systems?
by Alfman on Mon 9th Jan 2017 23:57 UTC
Alfman
Member since:
2011-01-28

I don't know what's up with the coverage of rust operating systems, but good ;) At this pace I don't know they'll be enough to last though 2017 though, haha. I'd like to keep the discussion going...

The language of choice for many hobby OS developments traditionally has been C/C++ by convention, which is understandable given the defacto status it has, but over the decades these tend to fall into the "me too" category. So I'm encouraged that more hobby OS devs are opting to break convention and go with rust, or really anything with safe-by-default semantics. Java and other managed languages offered that, but IMHO they were always held back by undesirable runtime tradeoffs.

These new breed of operating systems could finally crack the plateau of security we've been stuck at with complex C based operating systems. What's not clear is whether they can ever catch up in an economic race to the front that started 25-35 years ago. These entries are so far behind now that it's hard to envision them ever becoming mainstream.

I've lost faith that change can be driven by the users who tend to play with these operating systems. Still, in theory one of these could eventually catch the eye of a multinational company, say sony, and in an attempt to beef up security for the playstation, which keeps getting hacked, they might eventually invest in more secure operating systems. It could be enough to slowly kick-start a commercial rustlang economy.


...Discuss!

Reply Score: 4

tidux Member since:
2011-08-13

Rust could be what Ada once was, only with the distinction of preexisting hobbyist buy-in. It's also at the heart of Servo, Mozilla's new browser engine to replace Gecko. Chuck in a C library and some POSIX compatibility for Unix software and you could have Redox become this decade's BeOS or OS X, an attempt to marry the best of unix to a more modern system.

Reply Score: 3

kwan_e Member since:
2007-02-18

Rust could be what Ada once was, only with the distinction of preexisting hobbyist buy-in.


I think Ada still is. It's just not "sexy".

Ada is old and crusty so it only gets used for serious stuff and stuff that needs to be supported whatever the cost.

Rust is new and part of the culture of creating something from scratch every time design mistakes catch up to them but they don't want to do the real engineering work when it does, opting to repeat other people's mistakes by starting over again. But then, you did say "hobbyist" already ;)

Hobbyist buy-in is like an oxymoron.

Reply Score: 4

cb88 Member since:
2009-04-23

Without the hobbyists you have no developer pool to draw from... thus Ada is developed at "whatever the cost" expenses.

Reply Score: 3

kwan_e Member since:
2007-02-18

It's the psychological profile of the hobbyists that matter. A language like Ada that has relatively few hobbyists because it isn't sexy is not that much different from a language fully of fad-hopping hobbyists who will abandon ship when they realize the language they thought solved their pet peeve has developed something else to peeve them off in its stead.

Reply Score: 2

Alfman Member since:
2011-01-28

kwan_e,

Rust is new and part of the culture of creating something from scratch every time design mistakes catch up to them but they don't want to do the real engineering work when it does, opting to repeat other people's mistakes by starting over again. But then, you did say "hobbyist" already



Yes and no. It's really not like new languages are developed in a vacuum, they clearly benefit from experience with languages that preceded them. In other words, today's developers have the benefit of hindsight and can consciously fix many of the issues where C/C++ are criticized, such as cruft, safety and bad compilation times with large projects. So we shouldn't be making the same mistakes that have been made in the past.

But the possibility still exists that we are making new mistakes with new languages, and I think those would be well worth talking about. Do you have anything specific in mind?

Edited 2017-01-10 16:11 UTC

Reply Score: 2

kwan_e Member since:
2007-02-18

today's developers have the benefit of hindsight and can consciously fix many of the issues where C/C++ are criticized over cruft and lack of safety. So we shouldn't be making the same mistakes that have been made in the past.


It's the way they go about fixing the issues - "oh, we'll just create yet another language" - that is the problem. All languages will develop cruft, and all languages will paint themselves into a corner. The most ideological ones tend to do that the most frequently.

Only a handful of languages are left where the base is committed to using it cruft and all and not just abandon it for the latest fad in language design.

Reply Score: 2

Alfman Member since:
2011-01-28

kwan_e,

It's the way they go about fixing the issues - "oh, we'll just create yet another language" - that is the problem. All languages will develop cruft, and all languages will paint themselves into a corner. The most ideological ones tend to do that the most frequently.

Only a handful of languages are left where the base is committed to using it cruft and all and not just abandon it for the latest fad in language design.



I realize you are a C/C++ fan, and there was a time I was too. However many problems with C/C++ are very widely recognized and understood, consequently some people look to new languages to solve them. The big players are motivated to work on new languages like D, swift, rust, go, etc, not because of fads, but because of systemic recurring problems they have experienced with their existing codebases.

This video on the topic of new and old systems programming languages is very informative, partly because Bjarne Stroustrup (the creator of C++) is there along with others, and he personally acknowledges the criticism against C++ being made by the employees of google and facebook in their build processes. I personally admire the way they are so friendly with each other with no animosity at all. Stroustrup even humorously takes it in stride "the reason I take this mic back is to say that I don't disagree with that." to everyone's laughter.

LangNext 2014 C++, Rust, D, Go 1HR discussion
https://www.youtube.com/watch?v=BBbv1ej0fFo


You like C/C++, then great. Maybe D-lang would be up your alley too then? Maybe we can discuss that? I enjoy taking about all languages, however in past discussions you seemed to take serious offense to any possibility that another language could have a single benefit over C++.

http://www.osnews.com/comments/29463

My goal is to foster a friendly discussion here, but to be honest, I don't know how to deal with you, haha. So I ask you thusly: what can I do so that we can have a friendly discussion even when rust comes up and we disagree? ;)

Edited 2017-01-10 18:24 UTC

Reply Score: 3

kwan_e Member since:
2007-02-18

I realize you are a C/C++ fan, and there was a time I was too.


I have spoken highly of Ada too. It is another language with roughly the same design goals as C++. Static, compile time typing. Zero cost abstractions. Backwards compatibility.

* I'm NOT a fan of the "old C" part of C++ (or modern C, for that matter), but I accept it and don't run off for greener pastures because it doesn't fit in with some ideology of extreme pureness.

However many problems with C/C++ are very widely recognized and understood, consequently some people look to new languages to solve them. The big players are motivated to work on new languages like D, swift, rust, go, etc, not because of fads, but because of systemic recurring problems they have experienced with their existing codebases.


You miss my point. At some point in the future, languages like D, Swift, Rust and Go will have systemic recurring problems with their existing codebases. At which point, it's obvious they'll leave for greener pastures.

We have already experienced this with the transition to Python 3 and Perl 6. Scheme 7.

Swift has already gone through its first round of complete breaking changes. And what does Swift even fix? Unlike Rust, it doesn't even have a reason to exist other than fancy syntax. And that is my point - it's the attitude of starting over again rather than do the real engineering work of designing past those features.

Stroustrup even humorously takes it in stride "the reason I take this mic back is to say that I don't disagree with that." to everyone's laughter.


You think I don't know Stroustrup's views on the matter. He's one of the biggest pushers, still, of modernizing C++ with better features and leaving old ones behind.

Unlike people who go around inventing Rust and Go, he stuck with C++, cruft and all.

And the people working with Ada are also committed to sticking with the whole language.

I enjoy taking about all languages, however in past discussions you seemed to take serious offense to any possibility that another language could have a single benefit over C++.

http://www.osnews.com/comments/29463


Don't mischaracterize it.

I simply was not convinced by your arguments and counter-examples in that discussion. You tried to make it sound like Rust does theorem proving for thread correctness, when in fact all it does is formalize and lock down ownership semantics. That's not taking offence.

what can I do so that we can have a friendly discussion even when rust comes up and we disagree? ;)


My point in this discussion is not about Rust vs C++. It's about what it takes for a language to become widespread enough to become as embedded as C and C++.

Languages will get big, bloated, and accrue cruft. No language is exempt. Until a language designer and community grows up and accepts this, and is willing to support the language with all its warts like Stroustrup does with C++ and the Ada guys with Ada (you could even say the same about HTML and Javascript, in a perverse way ;) ), their language is a fad language.

Maybe, and let's hope, Rust's designers and its community are mature enough to stick with Rust regardless of how much garbage it accrues over the years. If not, it will not get the hypercritical user mass to prevent the next GoSwiftRust from taking over and for the whole "we just need to get critical mass" game to start again, as it steals users from RustGoSwift and they lose their momentum. At least Rust does have a benefit in that it seems to be serious with zero cost abstractions. So at least it has a better chance of not having to pay for design mistakes. But Rust won't magically avoid paying for syntactical and semantical cruft.

Reply Score: 2

Alfman Member since:
2011-01-28

kwan_e,

You miss my point. At some point in the future, languages like D, Swift, Rust and Go will have systemic recurring problems with their existing codebases.


I don't understand why it means we should stick with C++, which has even more crust, indefinitely? That's not a good plan for many of us.

If today's languages are looking long in the tooth (to borrow from RobG) in the decades to follow, then by all means I hope they do build something even greater yet. This shouldn't hurt our pride, on the contrary the goals they set for themselves in the future will largely depend on the goals we set for ourselves today, which depend on what we've already achieved with C++ and Ada and Pascal all those years ago and even further back to Babbage and Pascal. The evolution of human ingenuity is a beautiful thing.

You think I don't know Stroustrup's views on the matter. He's one of the biggest pushers, still, of modernizing C++ with better features and leaving old ones behind.


That's what D-lang did for the most part. C++ itself faces a major conundrum, it's huge base of legacy code that keeps it popular is also responsible for holding it back. Sometimes to make progress past the local maxima, you have to fundamentally break some of the scaffolding that keeps you stuck there.

Don't mischaracterize it.

I simply was not convinced by your arguments and counter-examples in that discussion. You tried to make it sound like Rust does theorem proving for thread correctness, when in fact all it does is formalize and lock down ownership semantics. That's not taking offence.


I gave examples where rust provided better safety semantics than C++. Anyways I'm not going to revisit that fruitless thread, if you believe that C++ is just as safe as rust, then in the interests of a keeping things lighthearted, then I'll just accept it and move on and I ask that you do the same ;)


Languages will get big, bloated, and accrue cruft. No language is exempt. Until a language designer and community grows up and accepts this, and is willing to support the language with all its warts like Stroustrup does with C++ and the Ada guys with Ada (you could even say the same about HTML and Javascript, in a perverse way ;) ), their language is a fad language.


But that line of reasoning just seems arbitrary and relative. Obviously C++ had a beginning too. Calling something a "fad" now just because it's new doesn't convey anything meaningful at all about merit and just sounds condescending towards a group of professional developers who are genuinely working hard to advance the state of software engineering.



Maybe, and let's hope, Rust's designers and its community are mature enough to stick with Rust regardless of how much garbage it accrues over the years.


But why? Tech gets ditched all the time once it's outlived it's usefulness, and not just software.

In the video Stroustroup says "C++ is obviously too large."

The facebook engineer says of C++'s compilation efficiency problems "I think it's a problem intrinsic to c++. C lang was designed with batch multi-stage processing in mind, and it shows. All these companies share the same problems and that have a huge c++ code base. Have a huge army to babysit the build system, at the end of the day it was an unsolvable problem. No amount of money can make c++ compile fast."

The google engineer says "we measured data went to the compiler. 4.2million factor blow up when using class per header file."

C++ will remain useful to many people for a long time, that's fine. But there are many companies and individuals who are frustrated with it and I find it very hard to make a case that they should not embracing new languages. For many of us, languages that carry the burden of legacy cruft is not a good option. There's no reason different people with different programming language opinions can't co-exist, just look at mainframers. Diversity is the spice of life ;)

Reply Score: 2

RobG Member since:
2012-10-17

To be fair, I've used C++ about 1990, and its just getting too long in the tooth. Not enough deprecation in there - largely, I guess, due to the way its module system is based on textual inclusion - so it is hard to change things without breaking compatibility.

Templates are lovely, but end up with almost everything being in a header, so compile times just get worse. Without Concepts, error messages keep getting more complex, frequently surfacing in library code the developer should have no reason to know exist.

I know there are proposals for both modules and concepts, but they seem to be permanently kicked to the next version.

I've been experimenting with Rust, and must admit that even in its current state it is just a nicer experience, to me, than C++ development. I wish them every success.

Reply Score: 2

kwan_e Member since:
2007-02-18

I know there are proposals for both modules and concepts, but they seem to be permanently kicked to the next version.

I've been experimenting with Rust, and must admit that even in its current state it is just a nicer experience, to me, than C++ development. I wish them every success.


Yes, but at least we know they're serious about getting it right because we know they're serious about having to support a language feature once it gets in, even if it turns out to be bad (like std::async or std::bind). But even then, we know whatever their state is at their inclusion, we know it will not cost anyone if they don't want to use it.

Yes, Rust is a nicer experience. Because it isn't old enough to develop all those cruft issues. All languages are nicer experiences when they haven't developed. They will once its user base expands, and either people will stick with it, or more likely, abandon it for another language because that's the reason they came to Rust in the first place.

Not even God manage to fix anything just by drowning the fuck out of everyone and starting over again. And it's a good metaphor because language (and OS community) design is pretty much like playing God for that universe. If you're constantly going to drown everyone and start fresh, nothing will actually grow, and the seeds of cruft will still be there.

Let's hope Rust doesn't succumb to that Godly urge.

Reply Score: 2

zlynx Member since:
2005-07-20

I think that you may be missing the fact that Rust isn't written by hobbyists. It's written and used primarily by professionals with experience in one of the largest C++ code bases on the planet: Firefox. Firefox is big enough that it requires 64-bit build tools to compile on Windows. And it is popular enough that it is a major target for malicious hacking.

These people know exactly what problems they have and what they're solving.

Being attractive to hobbyists is a nice side benefit.

Reply Score: 2

kwan_e Member since:
2007-02-18

I think that you may be missing the fact that Rust isn't written by hobbyists. It's written and used primarily by professionals with experience


I don't see why "professionals with experience" can't be hobbyists. I'm not talking about skill level.

Reply Score: 2