8 ms·

I'm not sure people realize just how much money Google has thus far sunk into Fuchsia for (AFAICT) very little in return. It was in the billions... years ago.

• beagle3 5y ago
  QNX did it right. So far, it doesn’t seem like anyone else did.
  • pjmlp 5y ago
    INTEGRITY OS, and several other RTOS in embedded space.
    • chrisjc 5y ago
      What does Tesla use? (searching the web doesn't seem to yield a consistent answer) Most of this thread has been focused on how Fuchsia will supplant Linux on Nest, Android and ChromeOS devices. However I immediately think about it will be used for Automobiles where RTOSes and prioritizing/scheduling operations deterministically is critical. I'm sure Fuchsia could be leveraged for autonomous robots too, but since they gave up Boston Dynamics, not so sure anymore. Perhaps they extracted what they needed from BD before selling them off. Again I wonder what OS Tesla uses for their robots, both Grohmann and Optimus. I have for many years thought that there was or so will be a battle in the RTOS space where Blackberry (QNX) would find themselves in a very similar situation they were in back when the iPhone and Android came onto the scene. (I know they were very different departments. Don't even know if they owned QNX at the time. Don't even know if you could consider them the same company anymore.) There is obviously a paradigm shift taking place in the automotive industry where the incumbent/ICE manufacturers have to make a choice of continuing down the path to oblivion or pivot to compete with the likes of Tesla, NIO, Polestar, etc... The RTOS will play an important part in the transition, and Google knows this. Google wants to be part of the stack and I believe they believe Fuchsia is the answer. Actually, I'd go so far as to say they want to own (or be the linchpin) the stack and again Fuchsia combined with Android Automobile (not Android Auto) is their attempt to move in while the incumbents are preoccupied with the other difficulties involved in this transition. If I was QNX/BB, I would be very concerned. Imagine the world of Automobiles resembling that of the Smartphone... You basically have two choices; Apple or a myriad of others all running their own flavor of Android... think Tesla or all the others running Android Automotive (Fuchsia). https://en.wikipedia.org/wiki/Android_Automotive https://en.wikipedia.org/wiki/Android_Automotive
      • pjmlp 5y ago
        No idea what Tesla does, the rest of the car indutry cares about stuff Tesla apperently does not, given the public reports on lack of software quality. NVidia uses a mix of QNX (for production) and GNU/Linux (for development) for their vehicles software. https://developer.nvidia.com/drive/driveos https://developer.nvidia.com/drive/driveos Note the safety critical remark for QNX, when human lifes are at stake, one gets to use OSes where safety matters as first priority.
        • The_rationalist 5y ago
          Tesla uses an Ubuntu Linux. QNX is probably obscolete vs Linux RTOS
          • pjmlp 5y ago
            Tell that to anyone doing high integrity computing certification with included liability clauses. Who will show in court from Linux RTOS contributors?
            • The_rationalist 5y ago
              Tesla has liability clauses about the life of people and if they trust linux then any other serious project can do so. BTW why just the kernel? It's ad-hoc. If your critical software project crash because of any open source user space library such as e.g .NET core, it's no different.
              • pjmlp 5y ago
                It shows given the sad stories regarding their auto pilot "quality".
• nine_k 5y ago
  QNX is a living proof of viability of the microkernel architecture in industrial setting.
  • cletus 5y ago
    I don't really know anything about QNX (like I said, not an expert) so I'm curious: just how general purpose is it? Has it made design decisions based on it's targeted use that are problematic for, say, running untrusted code in a sandbox?
    • Zhenya 5y ago
      Many car infotainment systems are either QNX or hypervised on top of QNX. https://blackberry.qnx.com/en/industries/connected-autonomous-vehicles https://blackberry.qnx.com/en/industries/connected-autonomou...
    • gmueckl 5y ago
      My experience with QNX is quite limited, but the OS is very general. There is a desktop GUI that is powerful enough to serve as part of self hosted software development environment. Generally, the tradeoffs are made to keep the core microkernel small and to give the system reliable guaranteed response times rather than raw performance because it is intended for hard real-time environments.
  • rwmj 5y ago
    I'm surprised no one has made a QNX compatible/clone? It's reputed to be a very small OS, or at least a small kernel.
• deleted 5y ago
  [deleted]
• numpad0 5y ago
  I think the point of Fuchsia to Google is it’s not Linux, nor bound by GPL. If it works it’s end of FOSS.
  • Engineering-MD 5y ago
    Why do you say it will be the end of FOSS? Fuchsia is still released under MIT license at present. If it is successful, another version could be released under GPL and built up as a competitor to the non GPL version.
  • bashtoni 5y ago
    That seems an odd statement to make about an operating system that is fully open source.
    • deleted 5y ago
      [deleted]
• mdasen 5y ago
  > Many at Google believe Android to be unsalvageable on two fronts: drivers and the general ecosystem. Could you elaborate? I'm simply curious why people would feel that way about Android. By the ecosystem, do you mean the fact that apps are primarily Java? That they're poorly made? What makes the drivers unsalvageable? Proprietary blobs interacting with the Linux kernel? Something else? It seems like a new kernel would have minimal drivers, but maybe it would offer a better way of having proprietary drivers? Linux doesn't have a stable device driver ABI so maybe that is making it hard for Google to update Android without the phone manufacturer being involved in the updating? I'm just curious what people see as the problems with Android that would require a new OS to fix. For example, if the problem is poorly made apps, that problem will follow you to a new OS if you let them publish for the new OS - and if you truly don't want them, you could remove them from the Play Store.
  • grumpyprole 5y ago
    Linux does not have a stable driver ABI or API.
  • cletus 5y ago
    The drivers part is easier to answer. Where Linux started drivers were compiled into the kernel. A few years later modules came along to dynamically load drivers (and other things). But modules could still (and can still) crash the kernel and the drivers don't necessarily have a particularly stable interface. Compare this to Windows. Drivers were once the bane of Windows and a huge problem for stability. Microsoft invested heavily in this and it seems to have worked. The Windows driver interface is I believe stable and has been for many years at this point and drivers themselves are more insulated from the kernel. Not completely but it's better in many aays. Android really has its hands tied here by what Linux does. You may agree or disagree with that but the above is a view held by influential people within Fuchsia. The ecosystem is really around the process by which updates are released. This is a tedious process of maintaining many Android trees and updating them with new Android releases. These need to be patched onto the existing trees or the changes made to the existing trees need to be ported onto the new Android tree. This is a nontrivial task either way. It's why Android phones get limited updates and those updates can lag behind the official release by months or even years. This isn't a situation Google likes so some want to make the manufacturer responsible for less, most notably the drivers. Remember that Samsung is motivated to sell handsets, not update existing handsets.
• jpkeisala 5y ago
  > much money Google has thus far sunk into Fuchsia for (AFAICT) very little in return. It was in the billions... years ago. Citation needed
  • cletus 5y ago
    The average cost of a Google engineer is at least $500k/year. This includes all direct compensation as well as amortized office costs, perks, meals and so on. I have no official figure on this but the average total comp can be well-established from levels.fyi as well as my own experience (disclaimer: Xoogler). 1000 engineers will give you a burn rate of $500m/year. I guarantee you the head count associated with Fuchsia is higher than this, probably much higher. Again, I have no official information on the current resource allocation but you can figure these things out by, for example, looking at the leadership structure. At a company like Google, certain positions will indicate head counts. An engineering director probably averages ~100 engineers rolled up through 2-3 layers of managers. A VP means 200-500. Familiarity with how Google staffs projects, how much Fuchsia was staffed while I was still there and the costs innvolved gets you easily into the billions of dollars over 5+ years.
    • md_ 5y ago
      https://techcrunch.com/2018/07/19/one-day-googles-fuchsia-os-may-become-a-real-thing/ https://techcrunch.com/2018/07/19/one-day-googles-fuchsia-os... says, as of 2018, “about 100” people work on Fuschia. I find your “much higher than 1000” estimate a bit surprising.
    • 8n4vidtmkvmk 5y ago
      i dont think L4 and below costs $500K? $170 base +$30 bonus+ 100 in stock.. i don't think other benefits add 200 more?
      • dlp211 5y ago
        nit: Stock grants/vests are not a cost to the company. They just create new shares and give them out.
• johncolanduoni 5y ago
  The idea that microkernels will have insufficient security due to additional context switching is a concern I’ve not heard before. Care to elaborate?
  • cletus 5y ago
    I was looking for a Linus quote I saw on this but can't seem to find it. It's not specifically about security but Linus said something about translation between user and kernel space was an absolute lower bound on performance and you're simply going to do more of that in a microkernel architecture. Think about it this way: if the TCP stack is in user space then how does another process talk to it to send a packet? Is it directly? Well that has issues. If it's via the kernel then you're already translating to the kernel and then out to user space. If this is an issue, will the temptation be to make some performance-related bypasses? Linus of course favours monolithic kernels [1] so consider that a disclaimer. [1]: https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_deb...
    • md_ 5y ago
      Huh? It’s widely said that microkernels trade performance for security. You seemed earlier to be saying that running core functionality in userspace implies a degradation in security. Typo?
    • j16sdiz 5y ago
      There are user mode TCP stack. It is doable with user mode IPC and IOMMU
    • codedokode 5y ago
      > Think about it this way: if the TCP stack is in user space then how does another process talk to it to send a packet? In a microkernel system, if a process holds a handle to a TCP stack then it can make calls like create_socket() and then use a socket. For better performance such calls can be executed without visiting the kernel, via call gates. If a process doesn't have a TCP handle, then it cannot access the network which is the best choice for most applications. And of course a privileged enough process can tap into other processes' inter-process calls and see what they are sending and receiving, or even intercept those calls and modify requests and responses, for example, to emulate a network card or to act as a firewall. In legacy systems like Linux or Windows every process has excess privileges - for example, access to network, to filesystem, to information about other processes, to shared memory, to hardware serial numbers. Linux has several hundreds system calls and they are available to any process. In a microkernel system I am describing the process would have the minimal privileges necessary for its job. For example, a TCP daemon would only have a handle to a router daemon (that redirects packets to a network interface) and no access to filesystem, information about kernel, and so on. Even if this daemon had a vulnerability it wouldn't be of much use for an attacker.
• grumpyprole 5y ago
  > unconvinced about the viability of a microkernel architecture beyond theory QNX is an example of a real-world microkernel OS that Blackberry purchased for use in mobile phones. One could argue it had superior peformance to Linux, not because of throughput, but due to its real-time guarantees.
  • sirjee 5y ago
    Not sure I understand the relationship between real-time guarantees and performance.
    • pantalaimon 5y ago
      Real time response/latency and performance/throughout are usually a tradeoff - you can’t have both.
    • Annatar 5y ago
      One of the core characteristics of a real time operating system is that it has to service events within guaranteed time.
      • simonh 5y ago
        It has to start servicing events within a guaranteed time, but completing them is another matter. If you have multiple tasks running in parallel and a lot of incoming events, constantly switching to service them will delay completion of your ongoing tasks wrecking their performance, and eventually the scheduler will get overloaded. So it depends on the cost of context switching, which is typically very high, and the frequency of context switches. Real time OSes are really important for applications where you have lots of lightweight tasks that need to be handled very promptly. If you have long running tasks (long running in CPU world, which can be fractions of a second) constantly getting interrupted and context switched can brutalise performance.
        • Annatar 5y ago
          I have a degree in the subject matter and I also run QNX so I know how it works and am well aware of what the trade-offs are, thanks. Before I even graduated from the university, I used to write lots of code which ran inside of interrupt requests on the Commodore 64 and Commodore Amiga where finishing before the next vertical blank was critical, so you could say that I've dealt with the practical even before I graduated in the theoretical. Not only did the code have to respond within the next vertical blank, ALL of it had to finish by the end of it, else I would have been the laughing stock of the scene. And before you cut in again, yes it was computationally expensive, therefore the code had to be really, really fast to get it all computed in time. When I write something here, I've already done it, and often on multiple occasions in multiple scenarios at multiple companies, therefore I don't need a lesson.
• dollop43 5y ago
  Project Treble is an effort to separate driver and Linux kernel. And later Android added mechanism to upgrade kernel from play service. I guess Google is resourceful enough to hedging on different approach to solve a similar problem. However, the crux of the problem is the Android manufacturer. You can't solve a human and incentive problem with a technical solution. Project Treble makes manufacturer easier to support their device, but they still don't motivate to do it. Google needs a tighter control on what device manufacturer should release. Android One is a good approach, only qualify certain devices to be include for meeting certain criteria. They could actually create a watermark on unsecured device for not updating Android version, just like chromium do it to website not using https. I think this is more effective than creating a new OS just to let the manufacturer being lazy.
  • defer 5y ago
    Not quite, treble is more about separating hardware specifics in a versioned, backwards compatible way. It's more for replacing the previous HAL system which in itself already abstracted the kernel for driver support (not necessarily just the kernel because modern platforms run things like audio, sensors, telephony outside of the kernel purview in specialized dsps or secondary mcus).
  • berdario 5y ago
    I bought two Android One devices... I'm afraid that the program is now dead: https://www.android.com/one/ https://www.android.com/one/ Their "Explore our latest phones" section shows 2 years old devices :/
    • shp0ngle 5y ago
      Android One is indeed dead. There are no incentives for the manufacturers to make these devices, as customers don't care and don't want to pay premium for them, while the manufacturers can get money from adding crapware to their phones.
    • jsnell 5y ago
      Nokia is still releasing new models (oh God, so many new models), and I think they're all on Android One. But indeed the Android One website not being updated with new ones is a bad sign.
• pjmlp 5y ago
  Most OS targeted to embedded space are microkernel based, while Windows and macOS have long been microkernel inspired with plenty of OS subsystems running on userspace. UNIX FOSS clones abhor microkernels, and then run containers everywhere with a monolithic kernel stuck accessing the real hardware via a type 1 hypervisor. It isn´t a theory for about several years already.
• torginus 5y ago
  Generally speaking the hybrid microkernel is the architecture both macOS and Windows went width, where some drivers still run in ring 0, but have some level of isolation between the core OS stuff, and driver stuff. For example, this allows Windows to restart a crashed GPU driver. Windows (and I think macOS as well) also has a stable kernel ABI/API for drivers, a fact that's probably appreciated by the hardware vendors. The bad name attached to microkernels I think stems from the debate between Tanenbaum and Linus in the 90s, where Tanenbaum's microkernel was sorely lacking in performance, mostly owning to the incredibly resource intensive context switches on the CPUs of the time. However, on newer CPUs, this cost is much less significant as CPUs are better optimized for this, making it worthwhile to revisit this issue.
• owaislone 5y ago
  As an outsider, I'd like big corps to spend billions on research projects or technologies like this than social networks like Google Plus. I feel a lot more good can come out of these projects even if the projects themselves fail.
• TickleSteve 5y ago
  >> context switching between user and kernel space. The amount of context-switching can be reduced these days by devoting cores to tasks/processes instead of tasks on a single core. Its not a free ride however as you pay with cache efficiency. For some systems, however I think it would pay off, the efficiency would increase with the number of cores until you get to 1 core per userspace task. At that point, its just IPC cost.
• mupuff1234 5y ago
  Billions doesn't sound right, are there any expenses other than salaries?
• codedokode 5y ago
  > with context switching between user and kernel space. This is an issue only because today CPUs are optimized for legacy monolith kernels which rarely switch and not for microkernels. Microkernels are very important because they allow to reduce privileged code size and move most things out of kernel. Legacy kernels like Linux or Windows are just an endless source of vulnerabilities, use legacy programming languages and have zero security. Linux doesn't even use static code analysis. For example, in Linux a network card driver runs at kernel with maximum privileges. In a microkernel it would be a separate process without access to anything in the system (even to a file system) so exploiting it wouldn't give much to attacker.
  • native_samples 5y ago
    No it's not. It's an issue because address translation is expensive, involving page table walks that require complex access to large in-memory data structures. CPUs cache the results but address space switches blow them away, by the nature of what they are. Modern CPUs (well Intel CPUs at least) have lots of features to try and mitigate these costs but they aren't widely used. For instance memory protection keys.
    • zozbot234 5y ago
      Modern CPUs support large pages that cut off some part of the page walk. Linux supports them transparently, so if you set up a bunch of threads sharing a single large address space it will be compacted into a handful of large pages. Single address space OS's in a broader sense have been made unviable by Spectre vulnerabilities; these days you need an address space flush at every transition from a "more private" to a "less private" information domain, which is basically every context switch when applications can't trust one another and have mutually private information that they're trying not to disclose to other apps.
      • native_samples 5y ago
        MPKs fix that. They can be switched more or less instantly because they don't require a TLB flush, and (recent) Intel CPUs don't speculate through MPK boundary violations.
• zozbot234 5y ago
  Microkernels are also not very useful on hardware without IOMMU's or separate buses isolating external components (like most SoC hardware), because a rouge-acting driver can take over your system anyway, so it has to be part of your trusted base. You can make such drivers into separate kernel-side threads or tasks, as a matter of pure convenience, but implementing them in userspace adds no security value.
  • surajrmal 5y ago
    While it's true that the attack vector you describes exist, assuming you can trust both the driver and hardware, it is hard to exploit as most software cannot talk directly to the driver. Even if it does, manipulating it the way you describe is challenging. By comparison, it's not only easy to talk with most drivers in a monolithic kernel, there is also many more ways to manipulate it which will result in the entire system being owned. Security isn't all or nothing if designed robustly. I hope the case for IOMMUs becomes stronger due to increased popularity of Operating Systems with userspace drivers. The BOM cost is simply worth it.
  • pjmlp 5y ago
    Customers of QNX, vxWorks and INTEGRITY OS beg to differ.
    • zozbot234 5y ago
      QNX works on real-time microcontrollers, where you just don't have the kind of hardware that can subvert an entire system by doing rouge DMA transfers. General-purpose systems are very different.
      • pjmlp 5y ago
        QNX works in whatever CPU one puts it on, plenty of choice, including plain Intel ones.
      • p_l 5y ago
        QNX is for "big embedded", not microcontrollers - it's plausible to have as deployment a POWER9 cpu. So is VxWorks.
• pch00 5y ago
  It has been pitched internally at various products and (AFAIK) only found traction thus far on Nest hubs. Since my Nest Hub received the update to Fuchsia it's been generally more laggy and unresponsive. Occasionally it needs a power cycle. I wish there was a way to downgrade to whatever it had pre-Fuchsia :(