Hacker News Reader

Comment by cletus | Hacker News Reader

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.

I don't know if this is still the case but the mission was absolutely to replace Android. Many at Google believe Android to be unsalvageable on two fronts: drivers and the general ecosystem.

It has been pitched internally at various products and (AFAIK) only found traction thus far on Nest hubs. It was heavily pushed for Chromecast but I guess nothing came of that.

I'm not an OS expert by any means but I am unconvinced about the viability of a microkernel architecture beyond theory. Security is an often-cited issue with context switching between user and kernel space.

View on HN

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.

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).

I bought two Android One devices... I'm afraid that the program is now dead:

https://www.android.com/one/

Their "Explore our latest phones" section shows 2 years old devices :/

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.

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.

Nokia branded phones are one of the best update experiences on Android.

> 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.

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.

Huh? Are you saying that in Windows, drivers don’t run in kernel space?

Some kinds of drivers (e.g. graphics) run at least partially in userspace.

Yeah, but it’s not the norm.

Don’t get me wrong. Windows did a lot of work on driver stability. But I think cletus is too narrowly focused, and misunderstanding the context around Android and Fuschia.

Fuschia has been described as a replacement for both ChromeOS and Android, with a goal of solving a range of problems (not just driver compatibility) and unifying the target development platform (beyond the somewhat-limited Android-for-ChromeOS options that exist today).

It does not seem to me that it’s primarily about fixing Android driver compat, which could probably be done in simpler ways (and, as others have noted, Treble sort of kind of exists to mitigate).

(I also was amused that Cletus claimed that Windows drivers run in userspace—generally not true—while claiming that there are no real-world microkernel OSes.)

I think they were talking about the various driver frameworks in Windows (WDM, KMDF, UMDF, NDIS and the various miniport drivers) having stable/well-defined interfaces and support libraries.

But also yes some drivers don't run in kernel space! https://docs.microsoft.com/en-us/windows-hardware/drivers/wd...

I believe the main problem is that Windows goes to reasonably extremely lengths (it's not perfect, but it's fairly good) to not break the driver interface, so if someone makes a driver for something, then semi-abandons it, the driver will continue to work for many years.

This is often clear in graphics cards, the main problem is old cards don't get support for newer versions of DirectX, but otherwise continue to work.

Linux explictly doesn't support this -- that means when some hardware manufacturer makes a closed source driver, it's very hard to update the kernel. Unfortunately it seems many bits of important phone hardware (like stuff Qualcomm makes) only have closed source drivers.

Samsung might not be directly motivated to make updates, but it’s now a selling point and consumers care about how many years of updates they’ll get. There’s no way to skip on it without hurting consumer trust and long term brand value.

↑ This. I got a Nokia Android One phone for this reason. I need security updates since I do banking and credit card transactions on my phone

Virtually no one outside of tech forums considers years of updates as a factor for which smartphone they pick. Most people, at least in the west, get a new subsidized phone on a contract every couple years. And if anything, they hate updates because stuff they're used to suddenly doesn't work like how they expect any more.

I've never heard anyone in real life say "I bought a Samsung phone last time and it was good but it didn't get any updates after 3 years so I'm never buying one again."

I have no idea how many people consider it, but Samsung made a comitment to offer 4 years of software support, and flagships one year more [1].

Few years ago it was not like that, I don't remember there were official promises and you typically got a year or two of updates. Until recently, long support was always mentioned as a big plus for iPhones.

Now every review I look mentions years of support as a big thing. I also see quite often on forums "I still have year of updates for my device, I'll skip this year's model" so people do think about it.

It's possible only techies look at these things (and read reviews and online discussions), but even so it's still better than it was.

[1] https://www.gsmarena.com/samsung_pledges_4_os_updates_5_year...

> Remember that Samsung is motivated to sell handsets, not update existing handsets.

Even though this is true, they still offer the longest updates.

> But modules could still (and can still) crash the kernel and the drivers don't necessarily have a particularly stable interface.

> 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.

I don't really think driver robustness is an issue here. The number of phones I've seen, used or heard about with driver problems is zero.

Add in the fact that phones are almost never rebooted (compared to desktops/laptops and other computers), and the driver situation looks incredibly stable.

Manufacturers keep stats of the number of kernel panics per year.

I was disappointed to find that on many models of phone, there was not a single active user who had not experienced at least one random reboot caused by a kernel panic a year after purchase.

The fact it boots straight back up to the lockscreen means many users will never notice that it's happened though.

> I was disappointed to find that on many models of phone, there was not a single active user who had not experienced at least one random reboot caused by a kernel panic a year after purchase.

The actual stats here will help; across a few million devices, random reboots unrelated to software or drivers will be expected.

You're saying that, one some models, the device never crashed. On others, there was at least one crash. That's at least a 0.00001% crash rate. That's unbelievably good. At that rate it's probably a hardware error, not a driver error.

If you used a different threshold we'd have a better idea - how many models have a crash rate of 10%? 5%?

> The fact it boots straight back up to the lockscreen means many users will never notice that it's happened though.

That provides further evidence that the money being poured into a new kernel to alleviate a problem that happens so rarely it can't be distinguished from statistical noise, and when it does happen, is almost never noticed by the user, is money being wasted.

The return here is not proportionate to the problem being experienced, and the solution is definitely not proportionate to the money being spent.

> You're saying that, one some models, the device never crashed

For at least one user, yes.

But there are many users who maybe only turn the phone on 5 minutes a day to check messages - so it isn't really odd for a few users to never see a crash.

> But there are many users who maybe only turn the phone on 5 minutes a day to check messages - so it isn't really odd for a few users to never see a crash.

I don't really know anyone who uses their smartphone for less than 5m per day, but that's irrelevant anyway.

The question is still: is the money being put into preventing this problem at all proportionate to the size of the problem?

If there's a problem that no one notices[1], is a solution really worth spending millions of dollars per year over five years?

[1] So few users complained about this it's not even a statistical rounding error.

I would bet money that it’s _usually_ a very difficult to reproduce software error.

edit: sure, bit flips will happen at scale, but they’re not as common as bad threaded programming.

Isn't fuchsia a microkernel?

Linux does not have a stable driver ABI or API.

> What makes the drivers unsalvageable? Proprietary blobs interacting with the Linux kernel?

Most drivers in the embedded world come from the BSPs (board support packages) of the SoC vendor. And holy hell wherever you look at leaked source code (cough Mediatek) it's madness. Nothing is upstreamed because the quality is so shoddy that you'd get Linus Torvalds into a proper ragepost if you dared to post it for submission, and as a result Android and most of embedded Linux is stuck at outright fossilized kernels where it's extremely hard to backport anything from newer kernels - which is also the reason why so few Android phones are supported for longer than two or three years after initial release. The SoC vendors simply won't provide BSP updates because of the effort involved.

And forget about copyright requiring vendors to open-source everything in Linux kernel space... most simply do not care and there is absolutely no will of enforcing it on a large scale - to the contrary, people trying to do so got booted off [1].

The proprietary blobs for components like WiFi/BT/GPU are only the icing on the cake. Barely any effort made to ensure it actually holds up in real world usage, only enough to pass qualification testing. IIRC Apple had at least one RF vendor make a completely new firmware for their chips because the official one was riddled with bugs.

[1]: https://sfconservancy.org/blog/2016/jul/19/patrick-mchardy-g...

Patrick McHardy wasn't interested in GPL compliance and source code release, only in extracting money from non-compliant companies.

Software Freedom Conservancy's approach on the other hand is to require compliance. Through their lawsuit against Vizio they are also aiming to make it possible for any user of GPLed but non-compliant software to sue for compliance. Hopefully this will change the amount of spontaneous GPL compliance for Linux in the industry.

https://sfconservancy.org/copyleft-compliance/vizio.html https://sfconservancy.org/copyleft-compliance/principles.htm...

Got a link for that Apple firmware thing? Sounds interesting. We really need open firmware for hardware devices. There is some for very old hardware though.

https://wiki.debian.org/Firmware/Open

> Patrick McHardy wasn't interested in GPL compliance and source code release, only in extracting money from non-compliant companies.

So what? If it makes them comply then I'm fine with it. No one else has taken on the fight except for a handful of large companies (Vizio and a settop-box-manufacturer whose name I forgot are the only cases I remember). Everyone else, particularly in the phone and embedded sector, outright shits on the GPL for decades now.

Particularly Google would be in an excellent position - they possess the Android trademark, they could require manufacturers and SoC vendors to properly open-source their stuff as part of the Android license, even for AOSP-powered devices.

Governments could also step in, similarly to enforcement of patents, but no government in the world has done anything to establish legal protection for open source that does not rely on open-source authors filing lawsuits on their own! Just imagine customs going on a trade fair and confiscating every device where the GPL and other OSS licenses are not obliged. After two rounds, no one would dare mess around any longer.

> Got a link for that Apple firmware thing?

Unfortunately not, that was many years ago and I might be remembering it wrong :(

AFAIK Patrick didn't even get compliance at all, just shady tactics to shakedown companies for money. The only way his actions resulted in compliance is if companies were scared after hearing about them and did their own compliance work, but that seems unlikely.

Conservancy are doing the Vizio lawsuit, do a lot of behind-the-scenes work, supported the VMware lawsuit, did a lawsuit against Best Buy/Samsung/Westinghouse/JVC and did one of the earliest compliance actions against Linksys resulting in the OpenWRT project:

https://sfconservancy.org/copyleft-compliance/past-lawsuits.... https://sfconservancy.org/copyleft-compliance/enforcement-st...

Harald Welte of gpl-violations.org did a lot of GPL compliance actions in Germany, admittedly none recently.

It would be great if Google could do GPL compliance actions against Android vendors, but they seem to be moving away from GPL projects instead of embracing them, so that seems very unlikely.

There was already a case where a Linux copyright holder got the USA customs department to withhold import of some GPL violating tablets. I think that eventually resulted in compliance, the details are somewhere on LWN, I forget the URL though.

I think if the Vizio lawsuit is concluded in favor of Conservancy, that is probably the best chance for widespread GPL compliance.

> So what? If it makes them comply then I'm fine with it.

An infringement lawsuit can't make anyone comply because a court will only ever order an infringer to pay monetary damages. An infringer might settle a lawsuit by agreeing to comply with GPL terms instead of paying damages, but that's not something a court would order.

Theoretically, if the GPL were a contract (an exchange of promises) and not a license (a grant subject to conditions), then a court could order a party in breach to comply with its terms. A court would only do that, however, if monetary damages were insufficient to compensate the non-breaching party.

Courts can also deliver injunctions, "specific performance" and similar non-financial remedies, not just monetary remedies.

https://en.wikipedia.org/wiki/Legal_remedy

The Conservancy lawsuit against Vizio contends that the GPL is also a contract and that downstream users are third-party beneficiaries of that contract, so they should be able to sue for compliance with the contract. Its a really interesting approach and I hope they win. I encourage you to read the court documents, they make for interesting reading.

https://sfconservancy.org/copyleft-compliance/vizio.html

Also, monetary damages are pretty much always insufficient in GPL cases, since money doesn't get you source code. I guess if the money was enough to pay for reverse engineering and reimplementation of the fixes/features present in the non-compliant codebase, then they could be enough.

> I guess if the money was enough to pay for reverse engineering and reimplementation of the fixes/features present...

Exactly.

> Nothing is upstreamed because the quality is so shoddy that you'd get Linus Torvalds into a proper ragepost if you dared to post it for submission

True, but the community does clean up and upstream stuff over time. It's just very slow work, made even more confusing by how much SoC hardware components are duplicated with small variations in different platforms. De-duplicating and merging drivers for some random IP block can involve pretty serious effort

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.

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.

> 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.

Not sure I understand the relationship between real-time guarantees and performance.

One of the core characteristics of a real time operating system is that it has to service events within guaranteed time.

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.

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.

I’m sorry if I offended you, but the question was about performance and event response is only one aspect of it, so I thought I’d expand on that for the benefit of anyone reading the thread.

Fine. Apology accepted.

Performance: Computing pi to a billion as quickly as possible

Real time guarantee: When a hook for an event is called it transfers all computation to that call within a time limit predictably and deterministically

Please correct me if I am wrong.

Real time response/latency and performance/throughout are usually a tradeoff - you can’t have both.

Only if you don't consider metrics like tail latency to be performance metrics.

The idea that microkernels will have insufficient security due to additional context switching is a concern I’ve not heard before. Care to elaborate?

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_deb...

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?

There are user mode TCP stack. It is doable with user mode IPC and IOMMU

> 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.

Someone should kill that link, it is no longer a relevant argument. Linus was mostly talking out of his ass complaining about microkernels. His main gripes were specific to Minix and Mach which were popular academic projects at the time.

There are many ways to make microkernels nearly as fast as monokernels, while being much safer and modular with all advantages that entails. See QNX or Sel4 for modern implementations.

Meanwhile, Linux itself has been getting more and more microkernel-y with things like eBPF which because of the monolithic design make the whole kernel much more vulnerable than warranted.

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.

> much money Google has thus far sunk into Fuchsia for (AFAICT) very little in return. It was in the billions... years ago.

Citation needed

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.

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.

i dont think L4 and below costs $500K? $170 base +$30 bonus+ 100 in stock.. i don't think other benefits add 200 more?

Their health insurance package is extremely expensive and a huge amount of money goes into supporting campuses with buses for commuters, full meals, laundry service, and so on.

I wouldn't call health insurance "extremely expensive" in the context of Google SWE salaries. On average it probably costs on the order of $5-$10k/head/year at most. My very loose upper bound estimate is $50k/year for all aux benefits and bus/campus costs.

nit: Stock grants/vests are not a cost to the company. They just create new shares and give them out.

They dilute shareholder value, and if you consider that many tech companies are also doing stock buybacks, it seems plausible to consider the net effect of (Handing out "free stock" with one hand) + (Buying back stock with the other hand) to be spending money.

I'd be willing to bet something like Fuchsia is on average L5-6 (or more) given retirement projects at Google attract some very senior engineers that would offset the L3/4s if you amortize them.

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 :(

> 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.

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.

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.

> Single address space OS's in a broader sense have been made unviable by Spectre vulnerabilities;

This is valid only for current CPUs and probably can be fixed. For example, current CPUs do not do speculative accesses for memory-mapped IO, and it means that similar method could be used to prevent access to kernel or other processes memory. There could be registers that contain lower and upper bounds of accessible memory, and they could be checked before accessing it.

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.

QNX did it right. So far, it doesn’t seem like anyone else did.

INTEGRITY OS, and several other RTOS in embedded space.

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

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

Note the safety critical remark for QNX, when human lifes are at stake, one gets to use OSes where safety matters as first priority.

Tesla uses an Ubuntu Linux. QNX is probably obscolete vs Linux RTOS

Tell that to anyone doing high integrity computing certification with included liability clauses.

Who will show in court from Linux RTOS contributors?

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.

It shows given the sad stories regarding their auto pilot "quality".

QNX is a living proof of viability of the microkernel architecture in industrial setting.

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?

Many car infotainment systems are either QNX or hypervised on top of QNX.

https://blackberry.qnx.com/en/industries/connected-autonomou...

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.

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.

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.

Customers of QNX, vxWorks and INTEGRITY OS beg to differ.

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.

QNX works in whatever CPU one puts it on, plenty of choice, including plain Intel ones.

QNX is for "big embedded", not microcontrollers - it's plausible to have as deployment a POWER9 cpu. So is VxWorks.

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.

>> 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.

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.

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.

That seems an odd statement to make about an operating system that is fully open source.

Billions doesn't sound right, are there any expenses other than salaries?

Reply on news.ycombinator.com