FreeBSD as a development platform

I put macOs in a separate camp (from BSDs) but added iOS to the same camp. Android in the linux camp.

What I mainly wanted to say is that I don't see Rust being a long term viable replacement. As you noted when C took over, it was mainly for newer OSes. AFAIK none of the older OSes were rewritten in it. It simply doesn't make economic sense to rewrite huge complex programs. [Edit] The major difference now compared to late 70s-early 90s is there doesn't seem to be any space for a new OS to flourish.
 
There is one new OS in active development, Fuchsia by Google:

Fuchsia

Fuchsia is a new open source operating system.
fuchsia.dev fuchsia.dev

But it isn't written in Rust so it aint cool :)
 
I was going to mention Fuschia! I haven't updated my git repo clone of it since June but it has about 5.3M LoC in Rust and 16K+ rust files (compared to 19.3K c, c++, h files etc). Though zircon (their microkernel) has hardly any *.rs files. May be it would have been different if it was started at the peak of Rust hype instead of a few years earlier!!

I thought Google isn't actually doing much with it (other than for their Nest Hub, where it is more an embedded OS)? They even laid off 16% of employees. From the outside it does seem it is not going replace Android or really going anywhere. If you have know better, let us know!

BTW, just its *.gn / *.gni files have 100K+ lines! (They use gn + ninja to build). Its total source size is 9.5M+ LoC. That's a remarkable size for something that has not seen much real use!
 
bakul said:
I was going to mention Fuschia! I haven't updated my git repo clone of it since June but it has about 5.3M LoC in Rust and 16K+ rust files (compared to 19.3K c, c++, h files etc). Though zircon (their microkernel) has hardly any *.rs files. May be it would have been different if it was started at the peak of Rust hype instead of a few years earlier!!

I thought Google isn't actually doing much with it (other than for their Nest Hub, where it is more an embedded OS)? They even laid off 16% of employees. From the outside it does seem it is not going replace Android or really going anywhere. If you have know better, let us know!

BTW, just its *.gn / *.gni files have 100K+ lines! (They use gn + ninja to build). Its total source size is 9.5M+ LoC. That's a remarkable size for something that has not seen much real use!
Click to expand...

Google's reward system can pump out lots of code quickly. But it doesn't prevent the messy product strategy decisions.

Fuchsia has a very interesting async-by-default API philosophy.
 
cracauer@ said:
Google's reward system can pump out lots of code quickly. But it doesn't prevent the messy product strategy decisions.

Fuchsia has a very interesting async-by-default API philosophy.
Click to expand...
Don't feel like async is good design for a microkernel, at least if security is a corncen, if goes the risk of butter overwrites and overflows, as well as prone to have DoD attacks against the kernel.

The seL4 kernel IPC mechanism is only blocking, without any kind of async, the Notification API is synchronization primitives, and as blocking as it can be, not have read the hardware specification. [eL4 API manual: https://sel4.systems/Info/Docs/seL4-manual-latest.pdf]

Doubt that the seL4 kernel would be able to provide their worst execution time guarantees, as well as memory guarantees with async calls in their kernel.
 
Not sure Fuchsia (actually Zircon) is a microkernel. It seems to be much more than that.

(Based on experience with several projects) I tend to think that the async model is more primitive than the sync one. Note that in Carl Hewitt's Actor model sends are async. Also the case in Erlang. Many more communication patterns are possible based on async sends than just request/reply.
 
You must log in or register to reply here.
Back
Top