21–30 of 285 posts
A couple of years ago it was believed that Fuchsia would replace Android and ChromeOS. Then, IIRC, it was said in a Google IO that it was just some sort of experiment to test new OS ideas. What do you think is Google's masterplan for Fuchsia?
Like most of their products, I don't think there is a master plan.
A couple of years ago it was believed that Fuchsia would replace Android and ChromeOS. Then, IIRC, it was said in a Google IO that it was just some sort of experiment to test new OS ideas. What do you think is Google's masterplan for Fuchsia?
That's a form of public denial on their side. Why would they upstream Chromium, LLVM, Rust and Android ART support then? It has first class support for Flutter as a way of running all Flutter apps from day 0.
Don't be fooled too easily by that statement.
A couple of years ago it was believed that Fuchsia would replace Android and ChromeOS. Then, IIRC, it was said in a Google IO that it was just some sort of experiment to test new OS ideas. What do you think is Google's masterplan for Fuchsia?
"Midori was a research/incubation project to explore ways of innovating throughout Microsoft’s software stack. This spanned all aspects, including the programming language, compilers, OS, its services, applications, and the overall programming models. We had a heavy bias towards cloud, concurrency, and safety. The project included novel “cultural” approaches too, being 100% developers and very code-focused, looking more like the Microsoft of today and hopefully tomorrow, than it did the Microsoft of 8 years ago when the project began." [1]
Later some of this ideas became core features on Windows.
For a great overview about Mindori project: [1] http://joeduffyblog.com/2015/11/03/blogging-about-midori/
Earlier quoted context omitted.
Indeed. I wonder why they didn't go with Rust? They seem to be trying to make the perfect architecture from scratch without worries about complexity or how experimental it is or even how long it'll take, and yet they don't go with a language that'll solve a whole other class of problems? Seems like an odd choice. Maybe they're just making use of the existing C++ talent pool at Google.
Lots of the userland pieces are in Rust. I don't think Rust gives you much advantage for kernel code (esp. in a microkernel), because most of it is unsafe anyway. And Rust has some missing pieces for this kind of code (for example, using custom allocators on a per-data structure basis is still difficult).
I'm both very excited someone is taking a shot at trying something new on kernel side. But i can't help wonder about what would a future look like where 90% of hardware run on a Google-owned operating system.
Would that really ever happen? Microsoft - a company so dominant it got an antitrust lawsuit - hasn't even been able to get 90% of the market share. No operating system since the very early days of computing has. Not only that, but other older operating systems are always going to have an advantage here anyway: they'll have support, ecosystems, documentation, and people with years of experience with them. Google isn'…
Note that some ostensible competitors like Startpage are still powered by Google under the hood.
I'm both very excited someone is taking a shot at trying something new on kernel side. But i can't help wonder about what would a future look like where 90% of hardware run on a Google-owned operating system.
Would that really ever happen? Microsoft - a company so dominant it got an antitrust lawsuit - hasn't even been able to get 90% of the market share. No operating system since the very early days of computing has. Not only that, but other older operating systems are always going to have an advantage here anyway: they'll have support, ecosystems, documentation, and people with years of experience with them. Google isn'…
Earlier quoted context omitted.
Indeed. I wonder why they didn't go with Rust? They seem to be trying to make the perfect architecture from scratch without worries about complexity or how experimental it is or even how long it'll take, and yet they don't go with a language that'll solve a whole other class of problems? Seems like an odd choice. Maybe they're just making use of the existing C++ talent pool at Google.
Lots of the userland pieces are in Rust. I don't think Rust gives you much advantage for kernel code (esp. in a microkernel), because most of it is unsafe anyway. And Rust has some missing pieces for this kind of code (for example, using custom allocators on a per-data structure basis is still difficult).
This debate about monolithic vs. micro-kernels has been had many times. Maybe this time the resolution is different, who knows. But FWIW Linux didn't reach its success because someone made a feature comparison between it and what else was out there in a spreadsheet and somehow discovered how Linux was so much better. Instead, Linux won (and continues to win) because it's the Rocky Balboa of operating systems. It may…
Keep in mind, too, that path dependence plays a huge role here. Linux took off when the alternatives were Windows NT, Novell Netware, or commercial Unixes running on underpowered RISC hardware.
Earlier quoted context omitted.
Indeed. I wonder why they didn't go with Rust? They seem to be trying to make the perfect architecture from scratch without worries about complexity or how experimental it is or even how long it'll take, and yet they don't go with a language that'll solve a whole other class of problems? Seems like an odd choice. Maybe they're just making use of the existing C++ talent pool at Google.
Lots of the userland pieces are in Rust. I don't think Rust gives you much advantage for kernel code (esp. in a microkernel), because most of it is unsafe anyway. And Rust has some missing pieces for this kind of code (for example, using custom allocators on a per-data structure basis is still difficult).