18 ms·

The Google Nest Hub is first commercial Fuchsia device

236 points by moh_maya 5y ago

stjo 5y ago
This makes no sense to me. Why is google building it? They want a more stable experience by using a microkernel and pushing everything to the userland? Maybe this will help with updates and vendors letting their devices rot? Or is it something to do with licensing?
- kenhwang 5y ago
  It's probably preferable than continuing to use the JVM-clone like it's an OS, while porting Linux to be the actual OS to run their JVM-clone OS.
- wolpoli 5y ago
  A large investment like this is likely a strategic move. Perhaps it is a corporate wide move to stop contributing to Linux. Or perhaps they plan on displacing Linux from the computing world.
- tomComb 5y ago
  Good questions, and I don't know the answers, but it is kind of odd (particularly given the pace of change in other areas of computer tech) that the world's most popular operating system was designed so long ago, and it seems like there is so little going on in this area. Of course, Apple is hard at work on iOS, but we don't know what sort of under the cover innovations that might good. So. I'm glad to see something new.
  - LordDragonfang 5y ago
    >the world's most popular operating system was designed so long ago, and it seems like there is so little going on in this area. Are you talking about Linux, or Android specifically? Either way, I don't really agree that there's "little" going on there.
- extrapickles 5y ago
  Most OS's out there are unsuitable for making appliances, which this seems aimed at. Right now your choices are a Realtime OS or Linux. Realtime OS don't support making GUIs and Linux has a lot of foot-guns. Normally, updates to an appliance are one binary blob, this looks to support all of the various pieces having their own blob, and allow the OS to be updated independently from the application binaries, so security updates can happen without the appliance vendor needing to do anything.
  - nyanpasu64 5y ago
    QNX is a microkernel RTOS which supported GUIs... but BlackBerry killed off support for using it on the desktop, and BlackBerry phones died out. IDK what else is using QNX technology now.
    - kemonocode 5y ago
      Cars [0], apparently. [0] https://blackberry.qnx.com/en/software-solutions/automotive/qnx-car-platform https://blackberry.qnx.com/en/software-solutions/automotive/...
      - jaywalk 5y ago
        Ford uses QNX for SYNC 3, although they are abandoning it and switching to Android Automotive starting with the 2023 model year.
  - handrous 5y ago
    > Realtime OS don't support making GUIs My three favorite GUI operating systems, putting aside software support, are iOS, BeOS, and... Photon on QNX.
- AshamedCaptain 5y ago
  Who needs an excuse to keep a lot of very senior OS developers happy to be employees?
- jcranmer 5y ago
  I can't speak as to their motivations specifically, but one of the things that I've noticed from poking around the kernel API is that the kernel APIs are much more coherently designed than the conventional kernels we have are. In particular, one of the key design goals appears to be a heavy use of a capabilities-enabled handle-based API, even for more conventional syscalls (e.g., mmap). One of the benefits of this approach is that it simplifies a lot more cross-process management stuff; you can inspect (or edit!) another process's memory maps, for example, with the same system call that a process would use to edit its own. It would also enable something like CreateRemoteThread; it would definitely be far easier to write a debugger for Fuchsia than it is for Linux.
  - astrange 5y ago
    Mach/Darwin/iOS has this and I suppose it's nice, but it does break down when you introduce POSIX compatibility, because you have to deal with the less expressive and insecure concepts like pids and file descriptors there.
    - wallscratch 5y ago
      Os noob here, what’s less expressive / insecure about PIDs or file descriptors?
      - jcranmer 5y ago
        PIDs and file descriptors are effectively global tables indexed by integers that are reused. This means that you have inherent race conditions: you want to an operation on pid X, but in between the time you decided you want to do it and the time you actually did it, pid X died and a new pid X was created. This is even worse for PIDs, since there's basically nothing you can do to actually have any sort of locking to avoid race conditions.
        zozbot234 5y ago
        Linux has PID namespaces now, so it's not global. But yes, the race conditions you describe are real, and can only be addressed via new API's.
- Daishiman 5y ago
  Because things have changed since the time Linux became ubiquitous. We have moved away from a world of shared libraries, filesystems, and UNIX users and permissions into a world of shared-nothing (no shared memory, no shared filesystem), capabilities, new and extremely aggressive attack vectors, and a need to compartmentalize and virtualize at more fundamental layers even if it comes at a performance penalty. You can't retrofit a microkernel-like abstraction on top of Linux. At the same time, a lot of the features you need for a shared multi-user system are basically cruft for modern mobile, single-user systems with little use for shared resources (not saying they're not shared; it's just that you can no longer trust apps installed in the user system so expecting apps to behave nicely is out of the window). The new wave of OSes embraces formal correctness when possible, JIT, garbage-collected application programming languages, tightly-enforced resource boundaries, deny-by-default security models, provably-safe system programming languages (Rust and whatever else will come), immutability and copy-on-write at the cost of filesystem space, and secure memory abstractions for more RAM. So why spend time supporting features that new OSes don't need, optimizing things that are no longer priority (HDD schedulers vs no-op SSD schedulers), when for once it _is_ actually easier to start over and fixing a lot of traditional pain points?
  - zozbot234 5y ago
    > a lot of the features you need for a shared multi-user system are basically cruft That's just not true. A "single-user" system running multiple "apps" where each app is actually endowed with its own user-like privileges is just a shared multi-user system by another name. There's no reason not to reuse the existing infrastructure, if perhaps with some tweaks.
    - Daishiman 5y ago
      Too many tweaks to be worth it. To this date we still find bugs in sudo, interactive shells, weird env var interactions from su and inheriting variables. The Unix permissions system is complicated yet insufficient for protecting systems. There are multiple, orthogonal machineries for isolation (jails, chroot, namespaces,SELinux thingies, setuid and sticky bits) and they all interact in horrendous ways that leave huge security gaps. Just reconsidering their use cases and redoing al lot of that having learned the lessons of the past twenty years is a huge advance.
- dragonwriter 5y ago
  > Why is google building it? As the longer-payoff/higher-risk companion to Chrome OS as the longer-payoff/higher-risk companion to Android, in a nested generalization of the Poseidon-and-Polaris strategy discussed as a model (among other places) in Mary and Tom Poppendieck’s Implementing Lean Software Development. It’s kind of a go-to strategy for Google in important markets; when you are essentially made of more money than you can figure out ways to spend, internal diversification so that you literally don’t make the choice between the immediately useful but maybe future-limited approach and the longer-time-to-payoff, higher-risk approach less tied to what is currently optimal makes a lot of sense.
mabbo 5y ago
Many years ago, I interned at Google and a very wise mentor of mine explained Google to me in a way that has stuck with me. "Google discovered a hose that money poured out of. It's called 'online advertising'. All that we do now is find ways to make that hose go faster, and desperately search for another hose." Why does Google develop 3+ different OS's? In case one of them is a money hose. Why has Google created thousands of products, only to cancel most of them once people fell in love? Because they decided that they weren't money hoses.
- ashtonkem 5y ago
  Also, Google's internal politics are kind of broken. It's my understanding that a lot of the product launches and cancellations are a consequence of an internal culture that rewards launching new products, but not maintaining or improving them.
  - refulgentis 5y ago
    Neither OP or GP have it right - Fuchsia isn't a "3rd OS", it's a kernel, like Linux, except MIT. Maintenance is most certainly rewarded, at least in the 5 years I've been at Google
    - mike_d 5y ago
      Eh. If you've been at Google for 5 years then you should recognize Fuchsia as another one of the "retention projects" where you get paid to twiddle away at something cool in the corner and your only real deliverable is not going to work for Facebook or Apple. Sometimes they stumble upon something another PA needs, but often it just ends up as a patent or research paper.
      - refulgentis 5y ago
        I can forthrightly say you're way, way, off the mark here. Another common anecdote in any Fuchsia article, one I myself believed at times, but not the case here. Edit: one of the many, many signs HN has deteriorated to a poor clone of subreddit combos is getting downvoted for knowing that this isn't a do-nothing project, which should be obvious to anyone reading: the whole point of the article is _it is launching on consumer hardware_. Sad stuff.
merrvk 5y ago
It's a damn shame that you have to use flutter, that's all I'd say.
- malkia 5y ago
  what should be used instead?
  - NwpierratorR 5y ago
    Android Runtime(ART) obviously.
- refulgentis 5y ago
  You don't, any C++ will do, as well as Java, Swift, etc etc etc. Also, it's a kernel, not a whole window management system + APIs + look & feel like people are reading here
renewiltord 5y ago
Huh, genuinely thought this was a research kernel type situation. But they have a display manager and everything built in to it. Wonder why they're using a different kernel instead of using Linux.
- tmccrary55 5y ago
  Google doesn't control Linux. I guess a microkernel is pretty cool though, the academic ideal.
- deleted 5y ago
  [deleted]
- johannes1234321 5y ago
  Linux is GPL.
- dodobirdlord 5y ago
  It is in a sense something of a research kernel. The reason to not use Linux is that it’s 30 years old and crufted up with things like multiple users, processes running as the user that started them, and POSIX. Linux also doesn’t have a stable kernel interface for drivers, which is probably a huge pain when dealing with supporting a device for many years. Either you don’t update the OS on the devices, or you have to modify all of your drivers every time you update the OS.
refulgentis 5y ago
The comments on this article are disappointing. The first major open source kernel since Linux, and somewhat arguably OS X, has been released. I was looking forward to commentary on that, not blinkered commentary complaining this exists when Android/ChromeOS do already (the error there is Android is a window manager + runtime on top of a kernel, ChromeOS is a window manager) or how performance reviews should be run.
- kemonocode 5y ago
  At best, it'll be something others will be able to leverage and make forks out of, and thanks to its permissive license, they won't have that pesky requirement to make the source code of their fork available. At worst, it'll be yet another product abandoned in a couple years by Google because it failed to meet some ludicrous goals that are out of reach for 99% of the companies in the world anyway. Such is the way people see Google nowadays, and can you really blame us?
- CarelessExpert 5y ago
  I disagree. The comments, here, give some real meta-insight into how Google is seen in the tech world: As an unreliable partner. Google has clearly and profoundly lost the confidence of the broader tech community. In particular, Google's history of starting and cancelling random projects helps explain why people are wondering why Google is releasing Fuschia: without some understanding of their motivations, it's impossible to trust that it'll actually have any kind of extended lifespan. For all we know, Fuschia, Android, and ChromeOS are basically the OS equivalent of Hangouts, Meet, Allo, and Duo, in which case becoming in any way reliant on it is a huge mistake.
  - refulgentis 5y ago
    I probably won't reply past this, any thread on Google is a karma sink because it'd require Google users backing me up here but...the analogy completely breaks, immediately. Hangouts _is_ Meet and Allo, if it weren't for the constant migration notices leading to constant commentary no one would be the wiser, you log into Gmail and chat just like you did 10 years ago. Duo's a featured product, people go too far and think it's "yet another video chat app", but, they're forgetting Google has to offer both FaceTime _and_ Zoom, it has consumer and corporate customers, the corporate one doesn't need stickers and hats, the consumer one doesn't need meeting links that work in a browser.
CarelessExpert 5y ago
Who wants to start a betting pool for when they cancel the project now that it's officially released into the world? I'm going with 2025. Just enough time for it to build up some momentum before they pull the rug out from under the user base!
- watermelon0 5y ago
  If this can possibly replace Android, WearOS (or recently announced WearOS/Tizen mashup), and ChromeOS, it’s quite possible that Fucshia is here to stay. Android apps and Chrome can easily run on a different OS, the only problem are device drivers, but I’m sure Google is in a position to persuade manufacturers to provide drivers for their OS.
  - phkahler 5y ago
    >> If this can possibly replace Android, WearOS (or recently announced WearOS/Tizen mashup), and ChromeOS, it’s quite possible that Fucshia is here to stay. So they can cancel more products if they keep Fuchsia!
    - Google234 5y ago
      Does every new Windows update count as a “cancellation” to you?
      - phkahler 5y ago
        >> Does every new Windows update count as a “cancellation” to you? No, but replacing android or chrome OS with a new OS built from scratch should right?
        Google234 5y ago
        It wouldn’t be like that. Take a look at this https://en.m.wikipedia.org/wiki/Ship_of_Theseus https://en.m.wikipedia.org/wiki/Ship_of_Theseus
The_rationalist 5y ago
Probably the biggest Google vaporware ever
- bogwog 5y ago
  They got the vapor wave aesthetics with the name at least
- yjftsjthsd-h 5y ago
  Vaporware with shipping units and published source code?
- myko 5y ago
  it's literally shipping
hourislate 5y ago
Just another bot net from Google. How much personal information will these devices running this new OS capture/steal? No thanks....
- logicslave 5y ago
  Ahhaha... Google is basically just a large data collecting bot net
- yjftsjthsd-h 5y ago
  In all seriousness - how is that any different from ChromeOS or Android? It's not like the kernel is what determines privacy issues.
- dang 5y ago
  "Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
yalogin 5y ago
This has been open knowledge for a few years now. I was fully expecting it to be cancelled before launch. In that sense am surprised it saw the light of day. However, I have never seen an explanation of why they need an OS written from scratch. The whole kernel and driver ecosystem, apps, development model, every single thing written from scratch. It took 6 years too for it to be productized. Why would anyone make that kind of an investment? It has to be extremely compelling. I would like to hear it from them
- na85 5y ago
  Linux wasn't invented at Google.
jillesvangurp 5y ago
I think it's telling that they are 'launching' this with a product that barely matters in their product portfolio. That indicates to me that they don't see this as an Android killer just yet. A bold move would have been to put this on the next Pixel. Clearly, that's not happening. If that was at all feasible, they would have waited for that and that would have been the grand launch. So, clearly it's nowhere near ready for such a launch. Their main issue with this is that OEMs like Samsung probably are not in any hurry whatsoever to jump on board and be even more dependent on Google. Without OEMs, app developers will drag their heels as well and Google is forced to maintain Android and not do a half-assed job of it. At this point Google has Android in cars, tvs, on phones, etc. Killing that would be suicidal; Google needs users interacting with their ads. If they botch the Fuchsia launch somehow, they'd have more OEMs taking things in their own hands and cutting loose from Google and forking Android (like Amazon and Huawei already did). They clearly are not ready to pull the plug on Fuchsia just yet but at this point it's a more than likely outcome. IMHO, they should just rip off the band-aid and move on. Most of what is wrong with Android is fixable.
- dragonwriter 5y ago
  > I think it's telling that they are 'launching' this with a product that barely matters in their product portfolio. It’s certainly the best way to immediately get it a whole lot of real world use and feedback with basically zero sales effort, and its economical since it lets them transfer resources allocation from supporting a dead-end effort to a live one. > A bold move would have been to put this on the next Pixel. “Bold” is sexy, but not the same as smart long-term strategy in many cases.
- Daishiman 5y ago
  There's a gigantic difference in developer effort to make an appliance OS versus a full-featured mobile OS.
  - jillesvangurp 5y ago
    They are clearly having commitment issues for that.
goodcjw2 5y ago
Disclaimer: I used to work and knew a lot Fuchsia developers very well. No, Fuchsia is not a pet project. Instead, it's solving a very realistic problem: building a clean driver interface, while keep it open and gain hardware vendor support. Anyone have shipped a Linux-based embedded system (including Android smartphone) knows the pain: there are tons of ad hoc driver source files need to be manually merged/rebased against the Linux Kernel. Want to upgrade the Linux kernel from 4.x to 5.x? Good luck redoing lots of merges and rebasing. There are tons and tons of git branches floating around, crazy examples like: "Linux-4.11-some_soc_vendor-some_oem-random_device-random_project-rev-1.3". It soon becomes unmanaged and device manufactures just gave up on keeping up with OS upgrades. Overall, the monolithic natural of Linux Kernel and its strict licensing terms made it hard to get code upstreamed back or to write properly modularized driver extensions. Even when people managed to get it work, you end up something like AMD's GPU driver takes 10% of Linux kernel [1]. The term of OS is heavily overloaded. But Fuchsia's goal is NOT to build other Android, but mainly to replace the Linux kernel. Is it worth it? Can Google pull it off? I don't know. But it probably worth a shot. [1] https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.9-AMDGPU-Stats https://www.phoronix.com/scan.php?page=news_item&px=Linux-5....
- xyzzy_plugh 5y ago
  I half agree with you. It's not so much that Linux lacks a clean driver interface, it's really that OEMs write shitty software that doesn't belong upstream. Ideally vendors stop writing garbage drivers and distributing hacked up kernels with their "sample code" (but ends up in production) and opaque binary blobs. Android unified vendors but simultaneously made them even lazier. It's somewhat hard to get non-android code from vendors in the past 5+ years. Which makes me very sad. Will Fuchsia somehow convince vendors to produce better drivers? I don't see how Fuchsia makes this problem significantly easier. Shitty vendors will continue to be shitty vendors and take the easiest path to making money. In any case, the Kernel's super power is its community, not the software itself. The LKML is vast and full of knowledge, a strange intersection of open source, research and corporate exploits. I don't see Fuchsia replacing that anytime soon.
  - londons_explore 5y ago
gher-shyu3i 5y ago
Worth noting that golang was evaluated and then discarded for fuschia: https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/docs/contribute/governance/policy/programming_languages.md#Go https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/d...
- amscanne 5y ago
  Why is that worth noting, and not the fact that the network stack is still Go-based? (So to say it’s discarded is inaccurate.)
  - gher-shyu3i 5y ago
    Because it was supposed to be a "systems language", yet it failed at that task. Furthermore, they want to move the network stack to an approved language over time: > netstack. Migrating netstack to another language would require a significant investment. In the fullness of time, we should migrate netstack to an approved language.
    - amscanne 5y ago
      I don't think it's failed. It's true that it has been far more successful as a general purpose web backend language, but you still have most of the container ecosystem (Docker, containerd, runc, kubernetes) written in Go. Either way, I don't think Fuchsia's language policy is noteworthy in this context.
rektide 5y ago
It's notable that this release has nearly ZERO attempt to market to or engage with 3rd party developers. It is solely for 1st party apps, solely under their control. Google picked a consumer device with extremely limited, contained functionality to target Fuchsia to. This is an extremely crazy twist for a device that is supposed to play a star, core role in the home, and a strong indicator to me of where we are in the War Against General Purpose Computing. There are definitely ways for 3rd parties to add to the experience, with the chatbot platform, but it's all expressed in Google's existing mold, via Actions with Google Assistant & other pre-baked systems of manipulation.
- bngybmgrglflps 5y ago
  It's a last-gen device. Why not interpret the lack of fanfare -- by design, a user won't even notice the swap -- as a soft launch? The smart home space has always been a shit show, from the radios up. It's a separate bag of rats from launching a research OS on real hardware.
  - rektide 5y ago
    I quite agree that this un-developable device issue is an IoT issue not really a Fuchsia issue. But it is also demonstrative a bit of some of the unique role Fuchsia has for us, what life after Android Things looks like.
blendergeek 5y ago
Possibly unpopular opinion: This is a tragedy for Free Software. The Linux kernel (and specifically its GPL nature) is the best thing that has ever happened to Free Software drivers and embedded systems. The only reason that companies release open source drivers for their products is because they are legally required to in order integrate with the Linux kernel. Clearly Google wants to move away from this world. I will mourn the day that a non-copyleft kernel supplants Linux and our only reason for free software hardware support comes to and end.
- wolverine876 5y ago
  How is Fuschia licensed?
  - therealrootuser 5y ago
    It isn't GPL; I believe it is tri-licensed in BSD, MIT, and Apache 2.
  - asciimike 5y ago
    https://fuchsia.dev/fuchsia-src/contribute/governance/policy/open-source-licensing-policies#licenses https://fuchsia.dev/fuchsia-src/contribute/governance/policy...
  - blendergeek 5y ago
    Fuschia is licensed under the BSD license as far as I can tell. This allows device vendors to use fuschia without releasing device specific software to the community resulting in further degraded software freedom.
- bogwog 5y ago
  This is also why Android is such a security and privacy nightmare, with the terrible user experience (and environmental impact) of having to buy a new phone every 1-2 years. Because Android is not GPL. Google owns the software, so manufacturers really only make money from the device sales, and bundled spyware.
JI00912 5y ago
Are there any privacy aspects to this? Does Google track everything that is going on? Do you have control over your device or can Google release updates and do whatever they want with it?
teddyh 5y ago
Linux was, AFAIK, the last GPL component of Android.
summerlight 5y ago
It's worth noting that Nest is using (likely heavily customized) Linux, pretty hard to keep sync with the upstream due to its monolithic kernel architecture while doesn't get aggressive investments like Android. But lifespan expectation for those products is much longer (~10 yrs) than typical smartphones (3~5 yrs) which leads to more maintenance headaches as Google accumulates their product portfolio, even compared to Android And... Even notorious Google couldn't completely pull their hands from Nest Secure although they decided to discontinue its production and sales. This is probably the problem they want to solve with Fuchsia. In this context, using Fuchsia is a pretty natural engineering decision. Fuchsia team can onboard its first customer while Nest team can outsource lots of its maintenance issues to a more appropriate team. I guess they already consider using Android before, but probably that's a no-go option since its support usually ends before 5 years. Of course, Android and Chrome OS have completely different needs and environments, so I don't expect them to converge to Fuchsia in any foreseeable future. More likely scenario would be a shared ecosystem based on Play Store which enables more future strategic movements.
s3r3nity 5y ago
ChromeOS, Android, WearOS, Fuchsia, Fitbit OS... Doesn't that make 5? (Potentially dumb question, I know...)
mikewarot 5y ago
Capability Based Security is a proven solution to computer security problems that arose in the Viet Nam conflict. Those problems keep cropping up here almost daily. The simple truth is that access control lists aren't up to the task of protecting systems with persistent internet connections and mobile code. A Windows or Linux machine can not ever be made secure. A microkernel, with the smallest possible attack surface, that never trusts driver code is the way forward. I don't care if the eventual winner is Fuchsia or Genode, all I want is momentum forward out of the morass that is the current Linux/Windows world. I look forward to trying out Fuchsia and Genode in the next few months, and porting a Forth interpreter to each.
- Eduard 5y ago
  What does the "Viet Nam conflict" have to do with capability-based security?
  - prutschman 5y ago
    I suspect a combination of 1) the US military having extensively studied this problem already. 2) that they did it a very long time ago.
  - mikewarot 5y ago
    Due to possible enemy infiltration of our computer systems and spy networks, there were multiple levels of secret data that had to be coordinated to allow airstrikes (one level of secret information) to avoid enemy radar(a different level of secrets). The location of enemy radar sites was very tightly held information, as knowing what we knew could reveal means and sources of information. The actual airstrikes would eventually be known by the destruction of enemy targets. It wasn't possible at the time to have a computer system which could allow the mixing of these levels of secrecy. This meant everything had to be done by hand. The development of Multilevel Secure systems by the Air Force in the 1970s is a direct result of that experience.
    - zozbot234 5y ago
      > It wasn't possible at the time to have a computer system which could allow the mixing of these levels of secrecy. This meant everything had to be done by hand. > The development of Multilevel Secure systems by the Air Force in the 1970s is a direct result of that experience. BTW, this stuff is not just for Air Force folks, either. Multi-level security is the most principled approach around to efficiently mitigate pervasive information-disclosure vulnerabilities like Spectre. The current approach to mitigation has us flushing speculation contexts down the drain even when sensitive info is provably not at stake, which is wildly inefficient compared to what's theoretically possible.
wolverine876 5y ago
I'm suprised to find people surprised at the development of a new OS. Linux is around 30 years old; Unix and C are around 50 years old. Eventually the parameters of the world and of user needs shift far enough from the original design that it's less expensive to develop something new than to adapt the old thing. Sometimes it's impossible to adapt the old thing: for practical purposes, no amount of work will make C secure. EDIT: Apparently Fuschia uses C and C++, and uses them exclusively in the kernel (if I understand correctly), and Rust and Dart are permitted for some uses, if this document is up-to-date: https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/docs/contribute/governance/policy/programming_languages.md https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/d... It's an impressive run, but the ground has shifted, slowly, under our feet, and now Unix/Linux are no longer a good fit. Let's not be conservative; let's do what our smarter predecessors did and embrace change. Fuschia is free and open source, per other comments in this thread. If that's true, let's be very thankful that the successor to Unix, if that's what Fuschia becomes, is FOSS. If Google put a proprietary OS on its phones, etc., even if they didn't charge for it, they'd have a lot of market power and they'd be competing with a 50 year old OS. It could be a terrible blow to FOSS.
- amelius 5y ago
  > It's an impressive run, but the ground has shifted, slowly, under our feet, and now Unix/Linux are no longer a good fit. Unix is still a good fit for a kernel; e.g. it is used by Apple. The stuff built on top of the kernel (UI, etc.) can change, of course.
  - jcranmer 5y ago
    > Unix is still a good fit for a kernel; e.g. it is used by Apple. The POSIX APIs are not a good basis for designing a kernel. There are plenty of areas where it's widely agreed that the APIs are fundamentally utter garbage: POSIX signals, filesystem ACLs, async I/O, select, IPC. Arguably even some of the more less garbage APIs (e.g., regular filesystem calls) are extremely detrimental towards writing good software--imagine if we had filesystem APIs based on semantics such as "atomic file write" or "append-only files" (that guaranteed that a reader would only see old or new versions, not partly-written versions) instead of what we have now, where people attempt to recreate those APIs in userspace.
paxys 5y ago
Damn, are microkernels finally back?
- pjmlp 5y ago
  They never went away in the embedded space.
remir 5y ago
I think this is great! Obviously Google has been working on porting Fuchsia to the Nest Hub for a while and I think they made the right call by deploying it to this kind of device first. They will get more users to test it in real life scenarios. At the same time, it's not a device that people use in mission critical situation, so if there's issues, it won't cause an uproar. I could see the rest of their portfolio migrating to Fuchsia OS eventually, including both Chrome OS and Android.
c0ffe 5y ago
I understand that Fuchsia is currently targeted at IoT or consumer devices, but can it run "containerized apps" in server environments with its current design (compared to Linux namespaces)? Maybe Kubernetes can be extended later to support Fuchsia nodes. It sounds really interesting to have a new target OS, with a different network and virtualization stacks.
- dcow 5y ago
  Considering all resources are accessed via scoped and capability-based handles, I suspect so. Not sure I want to see more kubernetes more places though... I'd rather just write software on a secure os in the first place.
mastrsushi 5y ago
Well, if Fuschsia doesn't do too well initially, at least they picked a hardware device that will probably be as forgetful as the Verizon Hub from 2009. https://youtu.be/1z1nsuQi40w https://youtu.be/1z1nsuQi40w
theogravity 5y ago
With this update, will the Nest Hub finally be able to tell time without an internet connection? I returned mine as I had this happen to me, which completely invalidates its use as a clock.
- ehsankia 5y ago
  I'm curious, do you mean actually show the time, or be able to respond to a voice query? I know newer Pixels for example run local-assistant and can answer a decent percent of queries locally, including telling time. I assume older Nest Devices don't yet have the local capability of processing your voice query locally, other than the hotword.
  - theogravity 5y ago
    Actually show the time. If the hub lacks an internet connection, the screen prompts you to get one and will no longer show time.
modeless 5y ago
I hope that performance is improved. The experience of using the Google Home Hub UI is quite bad. It looks slick and modern until you touch it, and then it feels like a car nav system display from 10 years ago. The frame rate is in the single digits. All the modern swoopy animations are wasted because the device can barely manage to display two or three frames before the animation is over. And the touch latency is off the charts. It's inexcusably bad. I mean, the hardware was purpose built for this software. They should have designed the software to meet the constraints of the hardware they knew they were shipping on. And it's plugged into the wall with a big form factor so performance should be better than phones where power consumption and heat dissipation are much more constraining.
- plerpin 5y ago
  It would be really interesting if someone could benchmark the performance before and after the transition.
uncomputation 5y ago
This is huge and exciting! One of the first open-source microkernels to get some serious commercial rollout, if I’m not missing anything. (I believe BlackBerry used a microkernel which was proprietary). Should be interesting!
gorgoiler 5y ago
Aside: Fuschia* is such an odd choice of name unless you are on a dual mission to not only make an MIT licensed Linux, but also to improve the ESL** world’s spelling and vocabulary. *Fuchsia, sorry. **German speakers will be fine.

236 points by moh_maya 5y ago

stjo 5y ago

This makes no sense to me. Why is google building it? They want a more stable experience by using a microkernel and pushing everything to the userland? Maybe this will help with updates and vendors letting their devices rot? Or is it something to do with licensing?

kenhwang 5y ago
It's probably preferable than continuing to use the JVM-clone like it's an OS, while porting Linux to be the actual OS to run their JVM-clone OS.
wolpoli 5y ago
A large investment like this is likely a strategic move. Perhaps it is a corporate wide move to stop contributing to Linux. Or perhaps they plan on displacing Linux from the computing world.
tomComb 5y ago
Good questions, and I don't know the answers, but it is kind of odd (particularly given the pace of change in other areas of computer tech) that the world's most popular operating system was designed so long ago, and it seems like there is so little going on in this area. Of course, Apple is hard at work on iOS, but we don't know what sort of under the cover innovations that might good. So. I'm glad to see something new.
- LordDragonfang 5y ago
  >the world's most popular operating system was designed so long ago, and it seems like there is so little going on in this area. Are you talking about Linux, or Android specifically? Either way, I don't really agree that there's "little" going on there.
extrapickles 5y ago
Most OS's out there are unsuitable for making appliances, which this seems aimed at. Right now your choices are a Realtime OS or Linux. Realtime OS don't support making GUIs and Linux has a lot of foot-guns. Normally, updates to an appliance are one binary blob, this looks to support all of the various pieces having their own blob, and allow the OS to be updated independently from the application binaries, so security updates can happen without the appliance vendor needing to do anything.
- nyanpasu64 5y ago
  QNX is a microkernel RTOS which supported GUIs... but BlackBerry killed off support for using it on the desktop, and BlackBerry phones died out. IDK what else is using QNX technology now.
  - kemonocode 5y ago
    Cars [0], apparently. [0] https://blackberry.qnx.com/en/software-solutions/automotive/qnx-car-platform https://blackberry.qnx.com/en/software-solutions/automotive/...
    - jaywalk 5y ago
      Ford uses QNX for SYNC 3, although they are abandoning it and switching to Android Automotive starting with the 2023 model year.
- handrous 5y ago
  > Realtime OS don't support making GUIs My three favorite GUI operating systems, putting aside software support, are iOS, BeOS, and... Photon on QNX.
AshamedCaptain 5y ago
Who needs an excuse to keep a lot of very senior OS developers happy to be employees?
jcranmer 5y ago
I can't speak as to their motivations specifically, but one of the things that I've noticed from poking around the kernel API is that the kernel APIs are much more coherently designed than the conventional kernels we have are. In particular, one of the key design goals appears to be a heavy use of a capabilities-enabled handle-based API, even for more conventional syscalls (e.g., mmap). One of the benefits of this approach is that it simplifies a lot more cross-process management stuff; you can inspect (or edit!) another process's memory maps, for example, with the same system call that a process would use to edit its own. It would also enable something like CreateRemoteThread; it would definitely be far easier to write a debugger for Fuchsia than it is for Linux.
- astrange 5y ago
  Mach/Darwin/iOS has this and I suppose it's nice, but it does break down when you introduce POSIX compatibility, because you have to deal with the less expressive and insecure concepts like pids and file descriptors there.
  - wallscratch 5y ago
    Os noob here, what’s less expressive / insecure about PIDs or file descriptors?
    - jcranmer 5y ago
      PIDs and file descriptors are effectively global tables indexed by integers that are reused. This means that you have inherent race conditions: you want to an operation on pid X, but in between the time you decided you want to do it and the time you actually did it, pid X died and a new pid X was created. This is even worse for PIDs, since there's basically nothing you can do to actually have any sort of locking to avoid race conditions.
      - zozbot234 5y ago
        Linux has PID namespaces now, so it's not global. But yes, the race conditions you describe are real, and can only be addressed via new API's.
Daishiman 5y ago
Because things have changed since the time Linux became ubiquitous. We have moved away from a world of shared libraries, filesystems, and UNIX users and permissions into a world of shared-nothing (no shared memory, no shared filesystem), capabilities, new and extremely aggressive attack vectors, and a need to compartmentalize and virtualize at more fundamental layers even if it comes at a performance penalty. You can't retrofit a microkernel-like abstraction on top of Linux. At the same time, a lot of the features you need for a shared multi-user system are basically cruft for modern mobile, single-user systems with little use for shared resources (not saying they're not shared; it's just that you can no longer trust apps installed in the user system so expecting apps to behave nicely is out of the window). The new wave of OSes embraces formal correctness when possible, JIT, garbage-collected application programming languages, tightly-enforced resource boundaries, deny-by-default security models, provably-safe system programming languages (Rust and whatever else will come), immutability and copy-on-write at the cost of filesystem space, and secure memory abstractions for more RAM. So why spend time supporting features that new OSes don't need, optimizing things that are no longer priority (HDD schedulers vs no-op SSD schedulers), when for once it _is_ actually easier to start over and fixing a lot of traditional pain points?
- zozbot234 5y ago
  > a lot of the features you need for a shared multi-user system are basically cruft That's just not true. A "single-user" system running multiple "apps" where each app is actually endowed with its own user-like privileges is just a shared multi-user system by another name. There's no reason not to reuse the existing infrastructure, if perhaps with some tweaks.
  - Daishiman 5y ago
    Too many tweaks to be worth it. To this date we still find bugs in sudo, interactive shells, weird env var interactions from su and inheriting variables. The Unix permissions system is complicated yet insufficient for protecting systems. There are multiple, orthogonal machineries for isolation (jails, chroot, namespaces,SELinux thingies, setuid and sticky bits) and they all interact in horrendous ways that leave huge security gaps. Just reconsidering their use cases and redoing al lot of that having learned the lessons of the past twenty years is a huge advance.
dragonwriter 5y ago
> Why is google building it? As the longer-payoff/higher-risk companion to Chrome OS as the longer-payoff/higher-risk companion to Android, in a nested generalization of the Poseidon-and-Polaris strategy discussed as a model (among other places) in Mary and Tom Poppendieck’s Implementing Lean Software Development. It’s kind of a go-to strategy for Google in important markets; when you are essentially made of more money than you can figure out ways to spend, internal diversification so that you literally don’t make the choice between the immediately useful but maybe future-limited approach and the longer-time-to-payoff, higher-risk approach less tied to what is currently optimal makes a lot of sense.

mabbo 5y ago

Many years ago, I interned at Google and a very wise mentor of mine explained Google to me in a way that has stuck with me. "Google discovered a hose that money poured out of. It's called 'online advertising'. All that we do now is find ways to make that hose go faster, and desperately search for another hose." Why does Google develop 3+ different OS's? In case one of them is a money hose. Why has Google created thousands of products, only to cancel most of them once people fell in love? Because they decided that they weren't money hoses.

ashtonkem 5y ago
Also, Google's internal politics are kind of broken. It's my understanding that a lot of the product launches and cancellations are a consequence of an internal culture that rewards launching new products, but not maintaining or improving them.
- refulgentis 5y ago
  Neither OP or GP have it right - Fuchsia isn't a "3rd OS", it's a kernel, like Linux, except MIT. Maintenance is most certainly rewarded, at least in the 5 years I've been at Google
  - mike_d 5y ago
    Eh. If you've been at Google for 5 years then you should recognize Fuchsia as another one of the "retention projects" where you get paid to twiddle away at something cool in the corner and your only real deliverable is not going to work for Facebook or Apple. Sometimes they stumble upon something another PA needs, but often it just ends up as a patent or research paper.
    - refulgentis 5y ago
      I can forthrightly say you're way, way, off the mark here. Another common anecdote in any Fuchsia article, one I myself believed at times, but not the case here. Edit: one of the many, many signs HN has deteriorated to a poor clone of subreddit combos is getting downvoted for knowing that this isn't a do-nothing project, which should be obvious to anyone reading: the whole point of the article is _it is launching on consumer hardware_. Sad stuff.

merrvk 5y ago

It's a damn shame that you have to use flutter, that's all I'd say.

malkia 5y ago
what should be used instead?
- NwpierratorR 5y ago
  Android Runtime(ART) obviously.
refulgentis 5y ago
You don't, any C++ will do, as well as Java, Swift, etc etc etc. Also, it's a kernel, not a whole window management system + APIs + look & feel like people are reading here

renewiltord 5y ago

Huh, genuinely thought this was a research kernel type situation. But they have a display manager and everything built in to it. Wonder why they're using a different kernel instead of using Linux.

tmccrary55 5y ago
Google doesn't control Linux. I guess a microkernel is pretty cool though, the academic ideal.
deleted 5y ago
[deleted]
johannes1234321 5y ago
Linux is GPL.
dodobirdlord 5y ago
It is in a sense something of a research kernel. The reason to not use Linux is that it’s 30 years old and crufted up with things like multiple users, processes running as the user that started them, and POSIX. Linux also doesn’t have a stable kernel interface for drivers, which is probably a huge pain when dealing with supporting a device for many years. Either you don’t update the OS on the devices, or you have to modify all of your drivers every time you update the OS.

refulgentis 5y ago

The comments on this article are disappointing. The first major open source kernel since Linux, and somewhat arguably OS X, has been released. I was looking forward to commentary on that, not blinkered commentary complaining this exists when Android/ChromeOS do already (the error there is Android is a window manager + runtime on top of a kernel, ChromeOS is a window manager) or how performance reviews should be run.

kemonocode 5y ago
At best, it'll be something others will be able to leverage and make forks out of, and thanks to its permissive license, they won't have that pesky requirement to make the source code of their fork available. At worst, it'll be yet another product abandoned in a couple years by Google because it failed to meet some ludicrous goals that are out of reach for 99% of the companies in the world anyway. Such is the way people see Google nowadays, and can you really blame us?
CarelessExpert 5y ago
I disagree. The comments, here, give some real meta-insight into how Google is seen in the tech world: As an unreliable partner. Google has clearly and profoundly lost the confidence of the broader tech community. In particular, Google's history of starting and cancelling random projects helps explain why people are wondering why Google is releasing Fuschia: without some understanding of their motivations, it's impossible to trust that it'll actually have any kind of extended lifespan. For all we know, Fuschia, Android, and ChromeOS are basically the OS equivalent of Hangouts, Meet, Allo, and Duo, in which case becoming in any way reliant on it is a huge mistake.
- refulgentis 5y ago
  I probably won't reply past this, any thread on Google is a karma sink because it'd require Google users backing me up here but...the analogy completely breaks, immediately. Hangouts _is_ Meet and Allo, if it weren't for the constant migration notices leading to constant commentary no one would be the wiser, you log into Gmail and chat just like you did 10 years ago. Duo's a featured product, people go too far and think it's "yet another video chat app", but, they're forgetting Google has to offer both FaceTime _and_ Zoom, it has consumer and corporate customers, the corporate one doesn't need stickers and hats, the consumer one doesn't need meeting links that work in a browser.

CarelessExpert 5y ago

Who wants to start a betting pool for when they cancel the project now that it's officially released into the world? I'm going with 2025. Just enough time for it to build up some momentum before they pull the rug out from under the user base!

watermelon0 5y ago
If this can possibly replace Android, WearOS (or recently announced WearOS/Tizen mashup), and ChromeOS, it’s quite possible that Fucshia is here to stay. Android apps and Chrome can easily run on a different OS, the only problem are device drivers, but I’m sure Google is in a position to persuade manufacturers to provide drivers for their OS.
- phkahler 5y ago
  >> If this can possibly replace Android, WearOS (or recently announced WearOS/Tizen mashup), and ChromeOS, it’s quite possible that Fucshia is here to stay. So they can cancel more products if they keep Fuchsia!
  - Google234 5y ago
    Does every new Windows update count as a “cancellation” to you?
    - phkahler 5y ago
      >> Does every new Windows update count as a “cancellation” to you? No, but replacing android or chrome OS with a new OS built from scratch should right?
      - Google234 5y ago
        It wouldn’t be like that. Take a look at this https://en.m.wikipedia.org/wiki/Ship_of_Theseus https://en.m.wikipedia.org/wiki/Ship_of_Theseus

The_rationalist 5y ago

Probably the biggest Google vaporware ever

bogwog 5y ago
They got the vapor wave aesthetics with the name at least
yjftsjthsd-h 5y ago
Vaporware with shipping units and published source code?
myko 5y ago
it's literally shipping

hourislate 5y ago

Just another bot net from Google. How much personal information will these devices running this new OS capture/steal? No thanks....

logicslave 5y ago
Ahhaha... Google is basically just a large data collecting bot net
yjftsjthsd-h 5y ago
In all seriousness - how is that any different from ChromeOS or Android? It's not like the kernel is what determines privacy issues.
dang 5y ago
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

yalogin 5y ago

This has been open knowledge for a few years now. I was fully expecting it to be cancelled before launch. In that sense am surprised it saw the light of day. However, I have never seen an explanation of why they need an OS written from scratch. The whole kernel and driver ecosystem, apps, development model, every single thing written from scratch. It took 6 years too for it to be productized. Why would anyone make that kind of an investment? It has to be extremely compelling. I would like to hear it from them

na85 5y ago
Linux wasn't invented at Google.

jillesvangurp 5y ago

I think it's telling that they are 'launching' this with a product that barely matters in their product portfolio. That indicates to me that they don't see this as an Android killer just yet. A bold move would have been to put this on the next Pixel. Clearly, that's not happening. If that was at all feasible, they would have waited for that and that would have been the grand launch. So, clearly it's nowhere near ready for such a launch. Their main issue with this is that OEMs like Samsung probably are not in any hurry whatsoever to jump on board and be even more dependent on Google. Without OEMs, app developers will drag their heels as well and Google is forced to maintain Android and not do a half-assed job of it. At this point Google has Android in cars, tvs, on phones, etc. Killing that would be suicidal; Google needs users interacting with their ads. If they botch the Fuchsia launch somehow, they'd have more OEMs taking things in their own hands and cutting loose from Google and forking Android (like Amazon and Huawei already did). They clearly are not ready to pull the plug on Fuchsia just yet but at this point it's a more than likely outcome. IMHO, they should just rip off the band-aid and move on. Most of what is wrong with Android is fixable.

dragonwriter 5y ago
> I think it's telling that they are 'launching' this with a product that barely matters in their product portfolio. It’s certainly the best way to immediately get it a whole lot of real world use and feedback with basically zero sales effort, and its economical since it lets them transfer resources allocation from supporting a dead-end effort to a live one. > A bold move would have been to put this on the next Pixel. “Bold” is sexy, but not the same as smart long-term strategy in many cases.
Daishiman 5y ago
There's a gigantic difference in developer effort to make an appliance OS versus a full-featured mobile OS.
- jillesvangurp 5y ago
  They are clearly having commitment issues for that.

goodcjw2 5y ago

Disclaimer: I used to work and knew a lot Fuchsia developers very well. No, Fuchsia is not a pet project. Instead, it's solving a very realistic problem: building a clean driver interface, while keep it open and gain hardware vendor support. Anyone have shipped a Linux-based embedded system (including Android smartphone) knows the pain: there are tons of ad hoc driver source files need to be manually merged/rebased against the Linux Kernel. Want to upgrade the Linux kernel from 4.x to 5.x? Good luck redoing lots of merges and rebasing. There are tons and tons of git branches floating around, crazy examples like: "Linux-4.11-some_soc_vendor-some_oem-random_device-random_project-rev-1.3". It soon becomes unmanaged and device manufactures just gave up on keeping up with OS upgrades. Overall, the monolithic natural of Linux Kernel and its strict licensing terms made it hard to get code upstreamed back or to write properly modularized driver extensions. Even when people managed to get it work, you end up something like AMD's GPU driver takes 10% of Linux kernel [1]. The term of OS is heavily overloaded. But Fuchsia's goal is NOT to build other Android, but mainly to replace the Linux kernel. Is it worth it? Can Google pull it off? I don't know. But it probably worth a shot. [1] https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.9-AMDGPU-Stats https://www.phoronix.com/scan.php?page=news_item&px=Linux-5....

xyzzy_plugh 5y ago
I half agree with you. It's not so much that Linux lacks a clean driver interface, it's really that OEMs write shitty software that doesn't belong upstream. Ideally vendors stop writing garbage drivers and distributing hacked up kernels with their "sample code" (but ends up in production) and opaque binary blobs. Android unified vendors but simultaneously made them even lazier. It's somewhat hard to get non-android code from vendors in the past 5+ years. Which makes me very sad. Will Fuchsia somehow convince vendors to produce better drivers? I don't see how Fuchsia makes this problem significantly easier. Shitty vendors will continue to be shitty vendors and take the easiest path to making money. In any case, the Kernel's super power is its community, not the software itself. The LKML is vast and full of knowledge, a strange intersection of open source, research and corporate exploits. I don't see Fuchsia replacing that anytime soon.
- londons_explore 5y ago

gher-shyu3i 5y ago

Worth noting that golang was evaluated and then discarded for fuschia: https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/docs/contribute/governance/policy/programming_languages.md#Go https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/d...

amscanne 5y ago
Why is that worth noting, and not the fact that the network stack is still Go-based? (So to say it’s discarded is inaccurate.)
- gher-shyu3i 5y ago
  Because it was supposed to be a "systems language", yet it failed at that task. Furthermore, they want to move the network stack to an approved language over time: > netstack. Migrating netstack to another language would require a significant investment. In the fullness of time, we should migrate netstack to an approved language.
  - amscanne 5y ago
    I don't think it's failed. It's true that it has been far more successful as a general purpose web backend language, but you still have most of the container ecosystem (Docker, containerd, runc, kubernetes) written in Go. Either way, I don't think Fuchsia's language policy is noteworthy in this context.

rektide 5y ago

It's notable that this release has nearly ZERO attempt to market to or engage with 3rd party developers. It is solely for 1st party apps, solely under their control. Google picked a consumer device with extremely limited, contained functionality to target Fuchsia to. This is an extremely crazy twist for a device that is supposed to play a star, core role in the home, and a strong indicator to me of where we are in the War Against General Purpose Computing. There are definitely ways for 3rd parties to add to the experience, with the chatbot platform, but it's all expressed in Google's existing mold, via Actions with Google Assistant & other pre-baked systems of manipulation.

bngybmgrglflps 5y ago
It's a last-gen device. Why not interpret the lack of fanfare -- by design, a user won't even notice the swap -- as a soft launch? The smart home space has always been a shit show, from the radios up. It's a separate bag of rats from launching a research OS on real hardware.
- rektide 5y ago
  I quite agree that this un-developable device issue is an IoT issue not really a Fuchsia issue. But it is also demonstrative a bit of some of the unique role Fuchsia has for us, what life after Android Things looks like.

blendergeek 5y ago

Possibly unpopular opinion: This is a tragedy for Free Software. The Linux kernel (and specifically its GPL nature) is the best thing that has ever happened to Free Software drivers and embedded systems. The only reason that companies release open source drivers for their products is because they are legally required to in order integrate with the Linux kernel. Clearly Google wants to move away from this world. I will mourn the day that a non-copyleft kernel supplants Linux and our only reason for free software hardware support comes to and end.

wolverine876 5y ago
How is Fuschia licensed?
- therealrootuser 5y ago
  It isn't GPL; I believe it is tri-licensed in BSD, MIT, and Apache 2.
- asciimike 5y ago
  https://fuchsia.dev/fuchsia-src/contribute/governance/policy/open-source-licensing-policies#licenses https://fuchsia.dev/fuchsia-src/contribute/governance/policy...
- blendergeek 5y ago
  Fuschia is licensed under the BSD license as far as I can tell. This allows device vendors to use fuschia without releasing device specific software to the community resulting in further degraded software freedom.
bogwog 5y ago
This is also why Android is such a security and privacy nightmare, with the terrible user experience (and environmental impact) of having to buy a new phone every 1-2 years. Because Android is not GPL. Google owns the software, so manufacturers really only make money from the device sales, and bundled spyware.

JI00912 5y ago

Are there any privacy aspects to this? Does Google track everything that is going on? Do you have control over your device or can Google release updates and do whatever they want with it?

teddyh 5y ago

Linux was, AFAIK, the last GPL component of Android.

summerlight 5y ago

It's worth noting that Nest is using (likely heavily customized) Linux, pretty hard to keep sync with the upstream due to its monolithic kernel architecture while doesn't get aggressive investments like Android. But lifespan expectation for those products is much longer (~10 yrs) than typical smartphones (3~5 yrs) which leads to more maintenance headaches as Google accumulates their product portfolio, even compared to Android And... Even notorious Google couldn't completely pull their hands from Nest Secure although they decided to discontinue its production and sales. This is probably the problem they want to solve with Fuchsia. In this context, using Fuchsia is a pretty natural engineering decision. Fuchsia team can onboard its first customer while Nest team can outsource lots of its maintenance issues to a more appropriate team. I guess they already consider using Android before, but probably that's a no-go option since its support usually ends before 5 years. Of course, Android and Chrome OS have completely different needs and environments, so I don't expect them to converge to Fuchsia in any foreseeable future. More likely scenario would be a shared ecosystem based on Play Store which enables more future strategic movements.

s3r3nity 5y ago

ChromeOS, Android, WearOS, Fuchsia, Fitbit OS... Doesn't that make 5? (Potentially dumb question, I know...)

mikewarot 5y ago

Capability Based Security is a proven solution to computer security problems that arose in the Viet Nam conflict. Those problems keep cropping up here almost daily. The simple truth is that access control lists aren't up to the task of protecting systems with persistent internet connections and mobile code. A Windows or Linux machine can not ever be made secure. A microkernel, with the smallest possible attack surface, that never trusts driver code is the way forward. I don't care if the eventual winner is Fuchsia or Genode, all I want is momentum forward out of the morass that is the current Linux/Windows world. I look forward to trying out Fuchsia and Genode in the next few months, and porting a Forth interpreter to each.

Eduard 5y ago
What does the "Viet Nam conflict" have to do with capability-based security?
- prutschman 5y ago
  I suspect a combination of 1) the US military having extensively studied this problem already. 2) that they did it a very long time ago.
- mikewarot 5y ago
  Due to possible enemy infiltration of our computer systems and spy networks, there were multiple levels of secret data that had to be coordinated to allow airstrikes (one level of secret information) to avoid enemy radar(a different level of secrets). The location of enemy radar sites was very tightly held information, as knowing what we knew could reveal means and sources of information. The actual airstrikes would eventually be known by the destruction of enemy targets. It wasn't possible at the time to have a computer system which could allow the mixing of these levels of secrecy. This meant everything had to be done by hand. The development of Multilevel Secure systems by the Air Force in the 1970s is a direct result of that experience.
  - zozbot234 5y ago
    > It wasn't possible at the time to have a computer system which could allow the mixing of these levels of secrecy. This meant everything had to be done by hand. > The development of Multilevel Secure systems by the Air Force in the 1970s is a direct result of that experience. BTW, this stuff is not just for Air Force folks, either. Multi-level security is the most principled approach around to efficiently mitigate pervasive information-disclosure vulnerabilities like Spectre. The current approach to mitigation has us flushing speculation contexts down the drain even when sensitive info is provably not at stake, which is wildly inefficient compared to what's theoretically possible.

wolverine876 5y ago

I'm suprised to find people surprised at the development of a new OS. Linux is around 30 years old; Unix and C are around 50 years old. Eventually the parameters of the world and of user needs shift far enough from the original design that it's less expensive to develop something new than to adapt the old thing. Sometimes it's impossible to adapt the old thing: for practical purposes, no amount of work will make C secure. EDIT: Apparently Fuschia uses C and C++, and uses them exclusively in the kernel (if I understand correctly), and Rust and Dart are permitted for some uses, if this document is up-to-date: https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/docs/contribute/governance/policy/programming_languages.md https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/d... It's an impressive run, but the ground has shifted, slowly, under our feet, and now Unix/Linux are no longer a good fit. Let's not be conservative; let's do what our smarter predecessors did and embrace change. Fuschia is free and open source, per other comments in this thread. If that's true, let's be very thankful that the successor to Unix, if that's what Fuschia becomes, is FOSS. If Google put a proprietary OS on its phones, etc., even if they didn't charge for it, they'd have a lot of market power and they'd be competing with a 50 year old OS. It could be a terrible blow to FOSS.

amelius 5y ago
> It's an impressive run, but the ground has shifted, slowly, under our feet, and now Unix/Linux are no longer a good fit. Unix is still a good fit for a kernel; e.g. it is used by Apple. The stuff built on top of the kernel (UI, etc.) can change, of course.
- jcranmer 5y ago
  > Unix is still a good fit for a kernel; e.g. it is used by Apple. The POSIX APIs are not a good basis for designing a kernel. There are plenty of areas where it's widely agreed that the APIs are fundamentally utter garbage: POSIX signals, filesystem ACLs, async I/O, select, IPC. Arguably even some of the more less garbage APIs (e.g., regular filesystem calls) are extremely detrimental towards writing good software--imagine if we had filesystem APIs based on semantics such as "atomic file write" or "append-only files" (that guaranteed that a reader would only see old or new versions, not partly-written versions) instead of what we have now, where people attempt to recreate those APIs in userspace.

paxys 5y ago

Damn, are microkernels finally back?

pjmlp 5y ago
They never went away in the embedded space.

remir 5y ago

I think this is great! Obviously Google has been working on porting Fuchsia to the Nest Hub for a while and I think they made the right call by deploying it to this kind of device first. They will get more users to test it in real life scenarios. At the same time, it's not a device that people use in mission critical situation, so if there's issues, it won't cause an uproar. I could see the rest of their portfolio migrating to Fuchsia OS eventually, including both Chrome OS and Android.

c0ffe 5y ago

I understand that Fuchsia is currently targeted at IoT or consumer devices, but can it run "containerized apps" in server environments with its current design (compared to Linux namespaces)? Maybe Kubernetes can be extended later to support Fuchsia nodes. It sounds really interesting to have a new target OS, with a different network and virtualization stacks.

dcow 5y ago
Considering all resources are accessed via scoped and capability-based handles, I suspect so. Not sure I want to see more kubernetes more places though... I'd rather just write software on a secure os in the first place.

mastrsushi 5y ago

Well, if Fuschsia doesn't do too well initially, at least they picked a hardware device that will probably be as forgetful as the Verizon Hub from 2009. https://youtu.be/1z1nsuQi40w https://youtu.be/1z1nsuQi40w

theogravity 5y ago

With this update, will the Nest Hub finally be able to tell time without an internet connection? I returned mine as I had this happen to me, which completely invalidates its use as a clock.

ehsankia 5y ago
I'm curious, do you mean actually show the time, or be able to respond to a voice query? I know newer Pixels for example run local-assistant and can answer a decent percent of queries locally, including telling time. I assume older Nest Devices don't yet have the local capability of processing your voice query locally, other than the hotword.
- theogravity 5y ago
  Actually show the time. If the hub lacks an internet connection, the screen prompts you to get one and will no longer show time.

modeless 5y ago

I hope that performance is improved. The experience of using the Google Home Hub UI is quite bad. It looks slick and modern until you touch it, and then it feels like a car nav system display from 10 years ago. The frame rate is in the single digits. All the modern swoopy animations are wasted because the device can barely manage to display two or three frames before the animation is over. And the touch latency is off the charts. It's inexcusably bad. I mean, the hardware was purpose built for this software. They should have designed the software to meet the constraints of the hardware they knew they were shipping on. And it's plugged into the wall with a big form factor so performance should be better than phones where power consumption and heat dissipation are much more constraining.

plerpin 5y ago
It would be really interesting if someone could benchmark the performance before and after the transition.

uncomputation 5y ago

This is huge and exciting! One of the first open-source microkernels to get some serious commercial rollout, if I’m not missing anything. (I believe BlackBerry used a microkernel which was proprietary). Should be interesting!

gorgoiler 5y ago

Aside: Fuschia* is such an odd choice of name unless you are on a dual mission to not only make an MIT licensed Linux, but also to improve the ESL** world’s spelling and vocabulary. *Fuchsia, sorry. **German speakers will be fine.