Google’s Fuchsia OS on the Pixelbook(arstechnica.com)
arstechnica.com
Google’s Fuchsia OS on the Pixelbook
https://arstechnica.com/gadgets/2018/01/googles-fuchsia-os-on-the-pixelbook-it-works-it-actually-works/
125 comments
Can someone summarize the technical tradeoffs they made in developing this OS vs. say Windows and Linux for example? Also, anything that is just plain better and represents recent innovations in OS design?
There's no point to these early Fuschia review attempts. I don't see how it demonstrates anything. It's like looking at the famous first email from Linus Torvald and figuring out what the os would be in the end. So it boots, it has windows, but not apps, and prints some things to the screen. It tells us nothing about real intentions, future capabilities, etc.
As somebody who read that famous first email and shared it around her lab: We were all tremendously excited, and spent days discussing it.
This is the same thing - it's exciting. It's trying to do things many of us have thought of, but never worked on. It's new technology. It's something that, in our hearts, we want to succeed just because the alternatives are all grungy and dusty and carry the compatibility fixes of generations.
Of course, if you don't really care about OS technology, or look at it from a consumer perspective, yeah, it's not giving you anything.
But for engineers who care about OSs? This is amazing and invigorating.
This is the same thing - it's exciting. It's trying to do things many of us have thought of, but never worked on. It's new technology. It's something that, in our hearts, we want to succeed just because the alternatives are all grungy and dusty and carry the compatibility fixes of generations.
Of course, if you don't really care about OS technology, or look at it from a consumer perspective, yeah, it's not giving you anything.
But for engineers who care about OSs? This is amazing and invigorating.
I do share the excitement, but that's exactly why I found this video rather uninspiring. It doesn't say a thing about how Fuchsia is new or interesting. It just goes through a bunch of extremely unfinished screens in consumer product review style. Nothing much to see really.
I found it interesting to browse some of the source code to get an idea of the roles that different language runtimes seem to play. But much more than that I would be interested in the driver model, the graphics stack, the IPC facilities and how it all differs from Linux/Android.
I found it interesting to browse some of the source code to get an idea of the roles that different language runtimes seem to play. But much more than that I would be interested in the driver model, the graphics stack, the IPC facilities and how it all differs from Linux/Android.
It's all written in C++, so from a security and reliability perspective, I'm sketical it's going to offer much improvement over Linux. I don't see any evidence yet of "new technology". I'm happy to be proven wrong.
I can use your logic to prove that there is no evidence of new technology in the Falcon 9 rocket.
After all, it is developed with very similar tools compared to every other rocket in existence.
After all, it is developed with very similar tools compared to every other rocket in existence.
Assuming your analogy has merit, I doubt very much this is true. Computer modelling, for example, has improved significantly over the years.
However, it is true that many high profile failures in aerospace have been due to software errors, so I would say that software tooling is certainly one area that they could also benefit from.
However, it is true that many high profile failures in aerospace have been due to software errors, so I would say that software tooling is certainly one area that they could also benefit from.
In line with your reasoning, software development methodology has significantly improved over the years. One does not write C++ in 2018 as they would have written C in 1980.
Best practice has changed, but C++ does not enforce it. Did Samsung follow best practices with Tizen?
Languages like Rust and Haskell are an attempt to put such best practice into the language tooling.
Languages like Rust and Haskell are an attempt to put such best practice into the language tooling.
You'd have to be insane to want to implement an os in Haskell.
>Languages like Rust and Haskell are an attempt to put such best practice into the language tooling.
Best practice often varies between projects and changes rather often, ..say.. in a matter of a few years. Most of what Haskell and Rust offer are a library away (yes, even compile time checks) for C++, but not vice versa. There is a reason new languages with baked in 'opinion' come and go.
Best practice often varies between projects and changes rather often, ..say.. in a matter of a few years. Most of what Haskell and Rust offer are a library away (yes, even compile time checks) for C++, but not vice versa. There is a reason new languages with baked in 'opinion' come and go.
You cannot make C++ secure and safe with a library.
If you state your criteria for 'safe' and 'secure', I can point you towards library implementations for each of your points.
You can not stop the users from shooting themselves in the foot, but that is not the goal here. We want to enable 'safe and secure' programming, not develop toy idiot-proof write-only languages that are useless for large projects.
You can not stop the users from shooting themselves in the foot, but that is not the goal here. We want to enable 'safe and secure' programming, not develop toy idiot-proof write-only languages that are useless for large projects.
> You can not stop the users from shooting themselves in the foot, but that is not the goal here.
It should be the goal. Even experts make mistakes. This is why static type systems exist. The logical thing to do is to strengthen the type system to prevent more classes of errors.
It should be the goal. Even experts make mistakes. This is why static type systems exist. The logical thing to do is to strengthen the type system to prevent more classes of errors.
And yet you always need to provide users an way out for the sake of pragmatism.
Examples: Rust's unsafe block, Haskell's Unsafe.Coerce, etc.
If the user avoids the analogous features in C++ and stick to modern conventions, it is not less safe/secure.
If the user avoids the analogous features in C++ and stick to modern conventions, it is not less safe/secure.
Of course the programming language defines the architecture ...
Programming languages do influence how a problem is solved and this often affects architecture. This is especially true with respect to concurrency. However my main problem with C++ is security, not want architectures it inspires.
The most radical OS architectures are all based on integration of compiler and language techniques - see Singularity or JNode for examples.
> It's all written in C++, so from a security and reliability perspective, I'm sketical it's going to offer much improvement over Linux.
Are you an expert in C? or in C++?
Are you an expert in C? or in C++?
It's not news to anyone that C/C++ puts the burden of security and safety onto the programmer. And it's getting harder all the time, see for example Spectre mitigation. C was designed alongside Unix in the 70's, a very different era. It is time for a next generation OS, but it needs to be built using next generation tooling.
> It is not news to anyone that C/C++ puts the burden of security and safety onto the programmer.
Okay, so neither.
Please consider reading these links. [1] [2]
[1] http://qr.ae/TbSNZ8
[2] http://www.lb-stuff.com/cc
Okay, so neither.
Please consider reading these links. [1] [2]
[1] http://qr.ae/TbSNZ8
[2] http://www.lb-stuff.com/cc
I have programmed C and C++ professionally on and off for over two decades, but I don't think that is relevant here. C++ shares many of the same security and safety problems as C, that is why they are often lumped together.
On the one hand I'm excited, but I ultimately hope this fails (commercially, anyways) because I don't think the world needs more devices loaded up with Google's spyware.
That seems rather pedantic. At this point I'm curious enough to watch these "reviews", but I don't care enough to try it myself. I happy reviewers are showing off the work, whatever they call it, review, sneak peak, preview.
Yeah, you can't "review" something that isn't even close to finished.
Windows Phone was originally supposed to eschew apps for some sort of focus on views, I forget what they called it. Now Windows 10 Mobile is more or less just Windows 10, with apps. I won't mind if someone finally finds a new model and makes it not suck, but when you're early in the product design phase is when you try crazy ideas to see if they pan out, the final product ends up looking more normal.
Windows Phone was originally supposed to eschew apps for some sort of focus on views, I forget what they called it. Now Windows 10 Mobile is more or less just Windows 10, with apps. I won't mind if someone finally finds a new model and makes it not suck, but when you're early in the product design phase is when you try crazy ideas to see if they pan out, the final product ends up looking more normal.
Windows Phone 7 Series had the concept of hubs (e.g. People Hub). It was an innovative model, and having so much functionality built in eased the pain of missing or poor quality native apps for things like facebook/Twitter. It was helpful in an “information at your fingertips” sort of way, where everything was organized without solos between apps/platforms.
Windows Phone 8.1 was the beginning of the end for hubs, with the OS feeling much more like iOS/Android, with winmo 10 basically killing it altogether.
Curiously much of the hub functionality seems to be coming back to Windows proper. For example, see ‘People’ integration in the taskbar that shipped with Windows 10.
Windows Phone 8.1 was the beginning of the end for hubs, with the OS feeling much more like iOS/Android, with winmo 10 basically killing it altogether.
Curiously much of the hub functionality seems to be coming back to Windows proper. For example, see ‘People’ integration in the taskbar that shipped with Windows 10.
I don't agree. How is this not interesting?
1. This is an open development effort, that's interesting.
2. It's moving very quick.
3. the code is really interesting.
1. This is an open development effort, that's interesting.
2. It's moving very quick.
3. the code is really interesting.
There are already important signals here.
1. Your login is tied to your google account. Want to use the computer in any real capacity? Google account.
2. They think bringing back multi tasking from the 90s is important.
3. People will want to control their computer views.
4. They are making a new kernel.
5. They believe in the capabilities based security model.
6. They believe in micro kernels.
7. They don't have any NEW ideas yet (otherwise we would see them in early stages). Maybe they will come up with something, it's research right?
1. Your login is tied to your google account. Want to use the computer in any real capacity? Google account.
2. They think bringing back multi tasking from the 90s is important.
3. People will want to control their computer views.
4. They are making a new kernel.
5. They believe in the capabilities based security model.
6. They believe in micro kernels.
7. They don't have any NEW ideas yet (otherwise we would see them in early stages). Maybe they will come up with something, it's research right?
I feel like just executing an old idea correctly is as worthwhile as coming up with something new.
It seems that the most useful OS/programming concepts have already been thought of, but all implementations are lacking in some ways, so I tend to agree.
It's neat to see the progress even if you don't know where it's going. I wouldn't call it a 'review', though.
So if the title was "Google Fuchsia early preview" then that would be fine.
I'm hoping it will be noticed by Linus and other Linux developers and help them address some of the shortcomings that Fuchsia aims to fix. It seems like this is how Google is exerting pressure on Linux to get what it wants...
Maybe - but it doesn't seem to me like the Linux community as a whole cares much about what Google wants.
And they don't have to: Google has their own capabilities to edit the kernel the way they want (they have done it before) or make their whole own kernel.
I don't think they're trying to push Linux anywhere.
Maybe they're trying to win over users from Linux, giving them some power in the software market & free contributions.
I don't think they're trying to push Linux anywhere.
Maybe they're trying to win over users from Linux, giving them some power in the software market & free contributions.
Its sort of a "review" of an early preview. I think it demonstrates a lot especially what Fuchsia is and what it is capable of. The other point would be that Google gets free advertisements of their new OS.
I don't think they really care about anyone knowing about it right now as a company, so the decision to open-source it right away confuses me a bit.
Maybe it's a subtle signal of their plans/capabilities towards competitors/dart devs?
Maybe it's a subtle signal of their plans/capabilities towards competitors/dart devs?
I disagree. It allows people that are interested in Fuchsia, but don't have the skills, time or hardware to build it, an opportunity to visually follow its progression.
The code is available here:
https://fuchsia.googlesource.com/
Key components:
## Zircon
Zircon is the operating system's foundation: it mediates hardware access, implements essential software abstractions over shared resources, and provides a platform for low-level software development.
For example, Zircon contains the kernel, device manager, most core and first-party device drivers, and low-level system libraries, such as libc and launchpad. Zircon also defines the Fuchsia IDL (FIDL), which is the protocol spoken between processes in the system, as well as backends for C and C++. The backends for other languages will be added by other layers.
## Garnet
Garnet provides device-level system services for software installation, administration, communication with remote systems, and product deployment.
For example, Garnet contains the network, media, and graphics services. Garnet also contains the package management and update system.
## Peridot
Peridot presents a cohesive, customizable, multi-device user experience assembled from modules, stories, agents, entities, and other components.
For example, Peridot contains the device, user, and story runners. Peridot also contains the ledger and resolver, as well as the context and suggestion engines.
## Topaz
Topaz augments system functionality by implementing interfaces defined by underlying layers. Topaz contains four major categories of software: modules, agents, shells, and runtimes.
For example, modules include the calendar, email, and terminal modules, shells include the base shell and the user shell, agents include the email and chat content providers, and runtimes include the Dart andFlutter runtimes.
https://fuchsia.googlesource.com/
Key components:
## Zircon
Zircon is the operating system's foundation: it mediates hardware access, implements essential software abstractions over shared resources, and provides a platform for low-level software development.
For example, Zircon contains the kernel, device manager, most core and first-party device drivers, and low-level system libraries, such as libc and launchpad. Zircon also defines the Fuchsia IDL (FIDL), which is the protocol spoken between processes in the system, as well as backends for C and C++. The backends for other languages will be added by other layers.
## Garnet
Garnet provides device-level system services for software installation, administration, communication with remote systems, and product deployment.
For example, Garnet contains the network, media, and graphics services. Garnet also contains the package management and update system.
## Peridot
Peridot presents a cohesive, customizable, multi-device user experience assembled from modules, stories, agents, entities, and other components.
For example, Peridot contains the device, user, and story runners. Peridot also contains the ledger and resolver, as well as the context and suggestion engines.
## Topaz
Topaz augments system functionality by implementing interfaces defined by underlying layers. Topaz contains four major categories of software: modules, agents, shells, and runtimes.
For example, modules include the calendar, email, and terminal modules, shells include the base shell and the user shell, agents include the email and chat content providers, and runtimes include the Dart andFlutter runtimes.
Thanks for the overview. Nice names!
I like the naming even more than the architecture! :-)
Which component are they going to name Steven?
probably their package "universe" ;)
I find it fascinating how polished the UI is even as it's missing core features.
The UI is made with Flutter, which can be used for Android & iOS apps today: https://flutter.io/
Thanks, that's a cool tool I've begun playing with it and it seems to simplify a lot of the difficult parts of creating good looking UI on mobile.
Most "reinvent $thing" projects begin by reinventing the parts of the $thing that are fun to reinvent. The "core features" are no fun to reinvent
This "review" is the video portion of this Ars Technica article: https://arstechnica.com/gadgets/2018/01/googles-fuchsia-os-o... which of course does not purport to be a review of Fuchsia.
Thanks! We've updated the link from https://www.youtube.com/watch?v=FhX6cANaJ6o.
What is this supposed to become, exactly? Google hasn't said much about it and speculators are making big claims like how this will replace ChromeOS and Android. I don't see that happening any time soon considering how deeply entrenched both OSes are, but Google's dedication mixed with the lack of comments makes me think again.
Depending on the future direction they take this, it might end up replacing OpenBSD for me.
Mac OS X and OpenBSD are my daily drivers, but at their core, they are BSDs, and less and less I find myself using the NeXTSTEP portion of Mac OS X and more and more time in BSD-land, which is leading me to move more and more of my overall computer time to OpenBSD which is a great operating system but is still largely a continuation of the UNIX/POSIX/BSD model which I appreciate like fine wine but do not love.
If Fuschia ends up being the answer to the question of what would happen if we built a new operating system from scratch today, taking the best lessons we were able to learn in the past 50 years, then I might be using it as my daily driver in 10 years.
Or maybe not. Nobody can really say what it will be right now.
Mac OS X and OpenBSD are my daily drivers, but at their core, they are BSDs, and less and less I find myself using the NeXTSTEP portion of Mac OS X and more and more time in BSD-land, which is leading me to move more and more of my overall computer time to OpenBSD which is a great operating system but is still largely a continuation of the UNIX/POSIX/BSD model which I appreciate like fine wine but do not love.
If Fuschia ends up being the answer to the question of what would happen if we built a new operating system from scratch today, taking the best lessons we were able to learn in the past 50 years, then I might be using it as my daily driver in 10 years.
Or maybe not. Nobody can really say what it will be right now.
Don’t hold your breath. The zircon API isn’t innovative in any modern sense. Additionally it’s bloated and not clean like L4. It’s just in house IP for Google.
(HN won’t let me directly reply to the comment below so here it is:
Nothing in zircon doesn’t already exist on Linux or any other modern kernel. Additionally it has bloat, like 3 distinct IPC mechanisms.
Even further, if it ends up being any technical person’s main driving OS it will surely sport a POSIX API and at that point it’s just another implementation of POSIX with similar a security model.)
(HN won’t let me directly reply to the comment below so here it is:
Nothing in zircon doesn’t already exist on Linux or any other modern kernel. Additionally it has bloat, like 3 distinct IPC mechanisms.
Even further, if it ends up being any technical person’s main driving OS it will surely sport a POSIX API and at that point it’s just another implementation of POSIX with similar a security model.)
Fuchsia docs says POSIX lite and Web runtime, under Backwards compatibility.
More info at https://fuchsia.googlesource.com/docs/+/HEAD/book.md#zircon-...
You can fire up the fuchsia in qemu, as it requires hardware graphics, you can't run the desktop, but you can have multiple shell open. I've had a play and it has vim and sql_shell and a bare bones top.
This is interesting: I thought they had taken a lot of care to implement very clean concepts.
Could you explain what you mean? I'd like to understand your point of view.
You think the lack of technical innovation is what makes products fail? Seems to me that it's actually the opposite that's true.
Never said it was going to fail. I just don’t expect it to be more appropriate as a hacker’s OS than OpenBSD or Linux.
Probably something more architecturally sound for future platforms in augmented and virtual reality among other things. One of the biggest issues with Android is managing permissions for apps to system resources. Proper sandboxing of 3rd party code is a big deal, especially if the next generation experiences are so much more immersive.
Given the amount of activity in porting Chromium to Fuchsia [x], my bet is on Fuchsia eclipsing Chromeos. A possible reason for this would be to get out from under the linux kernel; Fuchsia/Zircon enables google to make changes quickly.
[x] http://bit.ly/2EBckRk
[x] http://bit.ly/2EBckRk
well, based on the demo there, I'd almost only want it is a Google Assistant version of Amazon's Show where it could be an assistant for various users (and guests). Outside of that, I'm not sure.
Obviously, it has to be more with all of the aspects of it, but in its current state, that's the only thing I can envision.
Obviously, it has to be more with all of the aspects of it, but in its current state, that's the only thing I can envision.
Short review: Another OS written in C/C++ that will have a million and one bugs over the next 3 decades.
Just want to point out that not that long ago redox-os (the microkernel OS in Rust) asked people to test it.
People were able to kernel panic it, get privilege escalations, and DDoS it. In short, it had the same same issues a C based kernel would get.
It's true that it's still heavily in development and doesn't offer any guarantees whatsoever, but I think that it should be pointed out that just because your language is good, doesn't mean that your end result will be good (and vice-versa, C based kernels like l4 and C based projects like SQLite have been formally verified (at least SQLite was verified after compilation, so they check for undefined language constructs.))
People were able to kernel panic it, get privilege escalations, and DDoS it. In short, it had the same same issues a C based kernel would get.
It's true that it's still heavily in development and doesn't offer any guarantees whatsoever, but I think that it should be pointed out that just because your language is good, doesn't mean that your end result will be good (and vice-versa, C based kernels like l4 and C based projects like SQLite have been formally verified (at least SQLite was verified after compilation, so they check for undefined language constructs.))
Well, I mean, one of the issues listed is "getting a lockup with ls * on the default directory". Sure, Rust (or any other language, even something like Idris) is not a magic pill, but at that stage of development, you can't expect much. I would still say that it is, on average, a lot easier to shoot yourself in the foot in C than in Rust.
Can you link to that? I'd be curious to see how they did those things. I guess Redox has a lot of unsafe Rust code?
Here is the "Redox Crash Challenge":
https://github.com/redox-os/redox/issues/1136
According to the Redox book, at last count they had 70 cases of unsafe across 4500 total lines of kernel code.
https://doc.redox-os.org/book/introduction/unsafes.html
https://github.com/redox-os/redox/issues/1136
According to the Redox book, at last count they had 70 cases of unsafe across 4500 total lines of kernel code.
https://doc.redox-os.org/book/introduction/unsafes.html
Safe rust doesn’t mean “no bugs”, these kinds of issues aren’t inherently memory safety issues, they can also be the product of logic bugs.
Why focus on the language and the possibility of a million and one bugs but not the architecture and design choices?
Because it's an easy indicator of someone who has no idea what they're doing in OS development. Choosing the wrong tool for the job is meaningful. Have you ever looked through Chromium's C++ codebase? The same people are working on this and it tells us that they haven't learned their lesson (or they want to tightly integrate Chrome with Fuschia, which is also a foreboding sign).
Edit: I should clarify that I think C is the only rational choice and that Rust is ill suited to osdev as well. I'm only talking about C++ here.
Edit: I should clarify that I think C is the only rational choice and that Rust is ill suited to osdev as well. I'm only talking about C++ here.
>Because it's an easy indicator of someone who has no idea what they're doing in OS development. Choosing the wrong tool for the job is meaningful. Have you ever looked through Chromium's C++ codebase? The same people are working on this and it tells us that they haven't learned their lesson.
Have you looked into the backgrounds of the main developers working on Fuchsia OS? Because if you had you would have discovered that that they have a rather impressive resume who actually know what they're doing.
Travis Geiselbrecht - BeOS, iOS, Hiptop OS, Little Kernel
Brian Swetland - BeOS, Hiptop OS
Chris McKillop - a member of the original iPhone team, WebOS, QNX OS, Hiptop OS
Have you looked into the backgrounds of the main developers working on Fuchsia OS? Because if you had you would have discovered that that they have a rather impressive resume who actually know what they're doing.
Travis Geiselbrecht - BeOS, iOS, Hiptop OS, Little Kernel
Brian Swetland - BeOS, Hiptop OS
Chris McKillop - a member of the original iPhone team, WebOS, QNX OS, Hiptop OS
Someone said something similar earlier, but I chose not to respond to avoid getting deeper into an unrelated argument. The short of it is that I don't find BeOS (and Haiku) particularly impressive. WebOS is all userspace and I don't really care how Fuschia's userspace looks, and I have to admit I don't know much about QNX or Hiptop.
I know you're a prolific commentator here, so if you don't mind me asking ... Which operating systems have you designed (or worked on) to say that writing a microkernel in C is a symptom that they don't know anything about OS development?
Writing a microkernel in C is fine. I said _C++_. But for the record, I built this:
https://github.com/KnightOS/kernel
And I've worked on toy kernels here and there and studied more serious kernels in depth.
https://github.com/KnightOS/kernel
And I've worked on toy kernels here and there and studied more serious kernels in depth.
You're probably missing their tradeoffs. Google has deep expertise in C++ within the company and integration with existing libraries / tools is a huge bonus. So if the goal is a market-ready product and velocity matters, then it makes sense not to adopt a new language that is still changing a lot. It's only your opinion that they've chosen the wrong tool. There isn't one right answer to nuanced product decisions.
>then it makes sense not to adopt a new language that is still changing a lot
I should clarify that I agree with eddieh and think C is the only rational choice.
I should clarify that I agree with eddieh and think C is the only rational choice.
>Because it's an easy indicator of someone who has no idea what they're doing in OS development.
Actually suggesting Rust as some kind of magic bullet over C/C++ is a huge indicator "of someone who has no idea what they're doing in OS development".
It's similar to when first year CS students learn that assembly is "faster" (a hazy notion itself), and then want everything to be written in assembly.
Actually suggesting Rust as some kind of magic bullet over C/C++ is a huge indicator "of someone who has no idea what they're doing in OS development".
It's similar to when first year CS students learn that assembly is "faster" (a hazy notion itself), and then want everything to be written in assembly.
>It's similar to when first year CS students learn that assembly is "faster" (a hazy notion itself), and then want everything to be written in assembly.
That's an interesting kind of first year students... The kind I know flee before anything lower than C++.
That's an interesting kind of first year students... The kind I know flee before anything lower than C++.
Added to my comment:
>Edit: I should clarify that I think C is the only rational choice and that Rust is ill suited to osdev as well. I'm only talking about C++ here.
>Edit: I should clarify that I think C is the only rational choice and that Rust is ill suited to osdev as well. I'm only talking about C++ here.
Nah, writing a kernel in modern C++ or Rust is pretty rad. Higher level abstractions can be designed to avoid bugs (As evidenced by the explosion of macros in the Linux code base). Check out L4Ka::Pistachio https://github.com/l4ka/pistachio
> Because it's an easy indicator of someone who has no idea what they're doing in OS development.
From appearances, the lead "someone" on at least the kernel appears to be Travis Geiselbrecht, who worked at the OS and/or kernel level on BeOS, the Danger Hiptop (Sidekick) OS, his own NewOS (now the basis for HaikuOS), and an embedded OS at Jawbone before joining Google and starting work on LK, which is being used as the basis for Zircon and the Android bootloader.
So I think maybe you mean
> Because it's an easy indicator of someone who does not have the same opinions about OS development than I do.
...because, y'know, that's fine! But "this guy obviously has no idea what he's doing?" Gonna agree to disagree there.
From appearances, the lead "someone" on at least the kernel appears to be Travis Geiselbrecht, who worked at the OS and/or kernel level on BeOS, the Danger Hiptop (Sidekick) OS, his own NewOS (now the basis for HaikuOS), and an embedded OS at Jawbone before joining Google and starting work on LK, which is being used as the basis for Zircon and the Android bootloader.
So I think maybe you mean
> Because it's an easy indicator of someone who does not have the same opinions about OS development than I do.
...because, y'know, that's fine! But "this guy obviously has no idea what he's doing?" Gonna agree to disagree there.
I'd say the same thing without narrowing the statement to C/C++. ;-)
I believe the kernel is based on L4, which has at least one bug-free implementation[1].
1: http://sel4.systems/
1: http://sel4.systems/
The Ziron microkernel is based on Little Kernel[1]. One of the main authors of Fuchsia was the developer of LK.
[1]https://github.com/littlekernel/lk/wiki/Introduction
[1]https://github.com/littlekernel/lk/wiki/Introduction
Thanks for the correction
you're right. it should be written in typescript. or maybe the java prerelease from 1995.
Urg...
https://externos.io/
Edit:
>eXperience the future.
I don't know what gets me more, the idea of a js os, the bad capitalization, the period at the end of a non sentence, the cliché expression...
https://externos.io/
Edit:
>eXperience the future.
I don't know what gets me more, the idea of a js os, the bad capitalization, the period at the end of a non sentence, the cliché expression...
Whoever's behind it seems to be stuck at the "gaussian blur compensates for all forms of design inexperience!!1" stage too.
As someone who has dabbled in OS development over the years, you'd be a fool to use anything other than C (I suppose you could use a restricted subset of C++ if you really don't want to write anything but a toy OS) or assembly if you have something to prove.
What about Rust disqualifies it? Let's say besides ecosystem immaturity (lack of libraries). As a non-systems programmer, I'm curious.
One drawback about Rust OSes right now is that they must use nightly Rust, and therefore, don't gain our stability guarantees. This is another form of immaturity.
I still wish they would have done it anyway, but oh well :)
On a technical level, there's nothing stopping you: we already have one serious project (Redox) and many, many hobby projects that exist.
I still wish they would have done it anyway, but oh well :)
On a technical level, there's nothing stopping you: we already have one serious project (Redox) and many, many hobby projects that exist.
They do have some rust showing up in their repos. It looks like its mostly bindings needed to run rust on the OS. I don't know what their long term goals with it are. I'm guessing they want it for writing high performance user space daemons or whatever the fuchsia equivalent is.
https://github.com/fuchsia-mirror?utf8=%E2%9C%93&q=&type=&la...
https://github.com/fuchsia-mirror?utf8=%E2%9C%93&q=&type=&la...
Not OP but the reason I dislike Rust for OS/kernel development is that it's just too damn complicated. Kernels should be written in more conservative languages.
C just pushes the complexity onto the programmer without help.
Random subjective opinion presented as objective truth!
because
> Not OP but the reason I dislike Rust for OS/kernel development is that it's just too damn complicated
isn't?
I'm also not sure why stating my opinion is a problem. If you can't handle someone not bother to pussyfoot around and preface any statement with an "IMO" disclaimer, that seems like your problem.
isn't?
I'm also not sure why stating my opinion is a problem. If you can't handle someone not bother to pussyfoot around and preface any statement with an "IMO" disclaimer, that seems like your problem.
[deleted]
I haven't personally looked into the Rust based OS (I know it exists), but I can guarantee that they're using inline assembly, fighting with language features, working around limitations, and forgoing safety.
I'd be shocked if that isn't the case. I'm not saying that you can't build an OS in Rust or other languages, just that OS development is complicated enough without having to fight your language.
I'd be shocked if that isn't the case. I'm not saying that you can't build an OS in Rust or other languages, just that OS development is complicated enough without having to fight your language.
You just provided at least two good reasons. Add the ABI instability as a third and rust has struck out.
I'm conflicted on this.
I really do like the idea of a challenger to the linux monoculture (among devs)/the windows monoculture (among consumers), but I really hate the idea of google getting yet more power.
If it was pretty much anyone else doing this.
I really do like the idea of a challenger to the linux monoculture (among devs)/the windows monoculture (among consumers), but I really hate the idea of google getting yet more power.
If it was pretty much anyone else doing this.
How exactly is Google getting power here? The code is totally open. They just seem to be giving themselves more flexibility and potential to build better products.
If anything, this will result in less power over the Linux kernel for Google. It seems like that’s something you’d appreciate.
(My response to s2g’s reply below because HN is terrible for commenting:
I see your point that they now unilaterally control how the kernel is engineered, but my counter argument is that I don’t think this meaningfully changes their control over the platform. They were already free to modify the Linux kernel at their whim. Having upstream control doesn’t make you emperor of derived applications.
As a separate point, don’t you think it just results in less efficiency and worst products if google isn’t free to steer the project in the direction that makes the most sense for the application? It seems they can more easily make zircon for their use case, and I think that will result in cheaper and better phones.)
If anything, this will result in less power over the Linux kernel for Google. It seems like that’s something you’d appreciate.
(My response to s2g’s reply below because HN is terrible for commenting:
I see your point that they now unilaterally control how the kernel is engineered, but my counter argument is that I don’t think this meaningfully changes their control over the platform. They were already free to modify the Linux kernel at their whim. Having upstream control doesn’t make you emperor of derived applications.
As a separate point, don’t you think it just results in less efficiency and worst products if google isn’t free to steer the project in the direction that makes the most sense for the application? It seems they can more easily make zircon for their use case, and I think that will result in cheaper and better phones.)
Fuschia uses a BSD style license whereas the Linux kernel is GPL. Google or hardware vendors can modify the Fuschia code without sharing the changes with the public, for better or worse.
Google, as the copyright owner, could do that, or let hardware vendors do so, even if it was GPL.
BSD-style means that anyone can do that, even Google's competitors, without any additional permission from Google.
BSD-style means that anyone can do that, even Google's competitors, without any additional permission from Google.
Everyone said the same thing about Android.
...and Amazon went ahead and forked it, in addition to CyanogenMod, Paranoid, Copperhead, "HALFB4kedMod 0.9Beta2(No camera)"[1] and so on. Android's openness is not just empty words.
1. Until the developer changes phones and loses interest. Nevertheless, thank goodness for XDA.
1. Until the developer changes phones and loses interest. Nevertheless, thank goodness for XDA.
And by now not even the caller app, or the phonebook app, or the calendar, or Homescreen, or settings, or search are open anymore.[1]
Everything now requires Google's proprietary services
Oh, and Google prevents OEMs from cooperating with Amazon.[2]
As result, Android is almost completely controlled by Google.
And you call that "open"?
[2] See the ongoing Antitrust case in the EU against Google
Everything now requires Google's proprietary services
Oh, and Google prevents OEMs from cooperating with Amazon.[2]
As result, Android is almost completely controlled by Google.
And you call that "open"?
________________________
[2] See the ongoing Antitrust case in the EU against Google
You can still go fully open; https://microg.org/ and https://f-droid.org/en/ I don't have Pay, and no cloud push notifications, and the GPS assist isn't quite as perfect, but the only real bugbare is no swyping keyboard.
Sure, but that's not the same. By that argument — the core of the OS is open, just everything on top isn't — you might as well call macOS open because Darwin is open.
Android is nowadays proprietary, sadly.
Android is nowadays proprietary, sadly.
This is actually a very good analogy. There are even open reimplementations of core foundation and coaca, but no one would ever call OSX open.
Android was always "completely controlled by Google". It wasn't developed in the open - they would throw the code over the wall when it was ready. Does software have to be developed in the open for the result to be open? Answers to this vary depending on your perspective.
If you're going to dismiss "open-core" and corporate-controlled open projects out of hand, I have bad news to tell you Gitlab, Red Hat, VS Code and hundreds of other projects the rest of us non-purists are grateful for providing their source under licenses that allow for modifications or forking...
If you're going to dismiss "open-core" and corporate-controlled open projects out of hand, I have bad news to tell you Gitlab, Red Hat, VS Code and hundreds of other projects the rest of us non-purists are grateful for providing their source under licenses that allow for modifications or forking...
Yes, but in the past they actually threw code over the wall.
They stopped updating most system apps code, and never continued even providing the code.
Originally, everything was open source at least.
They stopped updating most system apps code, and never continued even providing the code.
Originally, everything was open source at least.
How many of the core devs don't work for Google? How much of the overall project direction is decided by people who have nothing to do with Google?
Saying "it's open, so they don't really control it" is like saying Linus doesn't have control of the Linux kernel.
Maybe google will figure out how to make an Android style play and hold this OS hostage by withholding their services.
> If anything, this will result in less power over the Linux kernel for Google. It seems like that’s something you’d appreciate.
Yes.
Saying "it's open, so they don't really control it" is like saying Linus doesn't have control of the Linux kernel.
Maybe google will figure out how to make an Android style play and hold this OS hostage by withholding their services.
> If anything, this will result in less power over the Linux kernel for Google. It seems like that’s something you’d appreciate.
Yes.
> How many of the core devs don't work for Google? How much of the overall project direction is decided by people who have nothing to do with Google?
This is why some developers are starting to hate open source. There's no technical excitement, it's all about community and governance and who has power and corporations and codes of conduct, etc... If not, you're going to fail. You get an army of experts scrutinizing your project and it's unexciting.
This is why some developers are starting to hate open source. There's no technical excitement, it's all about community and governance and who has power and corporations and codes of conduct, etc... If not, you're going to fail. You get an army of experts scrutinizing your project and it's unexciting.
> My response to s2g’s reply below because HN is terrible for commenting:
Click on the comment’s link (the “x hours ago”) to reply.
Click on the comment’s link (the “x hours ago”) to reply.
It wasn’t that. It was rate limiting me... for some reason.
[deleted]
Like Android, this is OSS.
Sure, Google runs the core development, but everyone will benefit from this eventually.
Sure, Google runs the core development, but everyone will benefit from this eventually.
Control the API, control the platform.
Control the platform, control the market around the platform.
Sure it's 'open', but at the same time, heavily subject to the authority of the owners.
See also the systemd/gnome impact to linux ecosystem..
posix in general keeps unices and unix likes (including linux here) more open than other systems since the API is less fluid / under the influence of a single group..
this phenomenon won't occur here.
Control the platform, control the market around the platform.
Sure it's 'open', but at the same time, heavily subject to the authority of the owners.
See also the systemd/gnome impact to linux ecosystem..
posix in general keeps unices and unix likes (including linux here) more open than other systems since the API is less fluid / under the influence of a single group..
this phenomenon won't occur here.
Echo runs on Android. Amazon Fire runs on Android.
>If it was pretty much anyone else doing this.
Look at seL4, minix3, genode, helenos.
Look at seL4, minix3, genode, helenos.