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?
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.
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.
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.
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.
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.
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.
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?
> 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.
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.
> We have moved away from a world of shared libraries, filesystems, and UNIX users and permissions into a world of shared-nothing
This is absurd. Fuchsia has all of shared libraries, filesystems, users and permissions. Probably even more of those than Linux.
And while I am a fan of microkernels, I can hardly claim that have become more interesting as of lately. In fact, I would even claim they have become even less interesting, since people are now taking seriously for some reason all the side channel attacks that practically make hardware-enforced privilege separation useless.
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.
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.
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.
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
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.
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.
I find these playground rule recitations to be a rather lily-livered way of stifling discussion. This is a forum and we're here to discuss things. Lest you forget, the _users_ and their opinions are the most valuable part of Hacker News, so how about we dispense with the self-appointed hall monitoring? I really don't give a shit if there's a commandment about not comparing HN to Reddit. If the shoe fits...
I'm interested: can you name even one more of the supposed "many, many signs"? The only one you elucidated doesn't really click; nor can I discern that HN is, by any stretch, a "poor clone" of anything about Reddit. HN has, in fact, many virtues that Reddit can't really touch, and it's basically just as old as Reddit, not that Reddit really invented anything that hadn't already existed for decades.
I got banned from posting for _4 hours_ because I got downvoted 5 points in a half hour for these comments. Suffice it to say I tried writing more substantive but the policy had its obvious effect, the off-topic echo chamber was preserved.
Look no further than you're being _upvoted_ for quintupling down on inanity completely divorced from the article that's we're supposed to be discussing, even with schoolyard debate nonsense like "can you name even one thing backing up your thesis statement?" (back in the day, or still with more traditional HN posts, you'd get something more like: 'I find that surprising, what makes you feel that way?'. Dang calls this "coming with curiosity" or something like that)
Meanwhile in the sibling thread, we have a guy with a year old account neener-neering me for daring to mention things are bad because it's a noob fallacy, and people who have actually been here a while getting flagged/dead through the floor for pointing out this _isn't actually some steadfast rule_, its a classic HN "rule". Meanwhile, I've been here for 12+ years and its never been close to being as bad as it is right now.
This site, and you, are getting what always happens to these sites: too large of an audience to preserve quality of discussion over group dynamics. You shall inherit the board, but, no one will be the wiser for you being here - it's all half-baked assertions, schoolyard bully absolutist nonsense that you know isn't argumentation, you'd never talk like that to someone in real life. Then add the thesis here being that people _in the actual company_ aren't seeing the truth, their coworkers are engaged on makework PhD bullshit because otherwise they'd jump to Apple (never mind that the #1, #2, and #3 pieces of career advice in the valley is to leave so you get promoted)
Quite to the contrary, I'd talk to you exactly like this in real life. I cordially invite you to coffee if you'd like proof of that. You made a very broad claim that was unsupported, so I asked you to support it. You responded with zero support and with a lot of heated blather that violates as many HN policies as you could manage. Stop complaining about upvotes and downvotes, and support your argument, instead.
As for your "coming with curiosity" scolding attempt? Please review the first two words of my comment.
Because Google has infinite money, the execs just hire people so they can admire the zoo of smart people they've built. Why do they need Vint Cerf, Guido, and Rob Pike? Why are they on the MIDI board? Because there's no real reason not to.
Actually, it is a 3rd OS named Fuchsia, which uses a custom kernel called Zircon which is MIT.
"Zircon is the core platform that powers Fuchsia. Zircon is composed of a kernel (source in /zircon/kernel) as well as a small set of userspace services, drivers, and libraries (source in /zircon/system/) necessary for the system to boot, talk to hardware, load userspace processes and run them, etc. Fuchsia builds a much larger OS on top of this foundation."
I suspect that this is a consequence of the above problem. Something that's pretty successful and growing at a pretty good clip is not a giant spigot of money, and therefore it's effectively useless to Google. Maintaining it requires programmers that could be better put to searching for the next spigot.
As I understand it, higher level promotions require a portfolio be compiled and submitted to an anonymous review board. A successful product launch is one of the most valuable additions to these packets.
This has two logistical consequences: 1 - it's more valuable to launch a new product that it is to successfully maintain/grow a current one. 2 - the person running these new projects tends to get promoted away, leaving it rudderless.
Google could change all this overnight by restructuring what these review boards prioritize.
It works for some things but they've kind of painted themselves into a corner with cloud services, many companies do not trust that GCP will not just disappear without a trace someday.
People always say this on HN, and while it’s definitely a viable explanation for why Google so often cans projects that are well-loved, I’m finding it harder to believe the more I think about it. If all of us on the outside are so aware of this fact about Google’s culture, surely someone with sway has heard about it, and taken steps to fix it. I’m sure Google are well aware of the perception that they’re always getting rid of products, and would like to fix that. So if the explanation was just that the culture doesn’t reward maintaining existing projects, I’m sure we would have heard something about a corporate incentive to maintain stuff.
I hate the word, but if there's one thing google has it's analytics - data. They can tell if something is growing or dying. I'm guessing they could even tell youtube was growing before they bought it. But seeing an upward trend seems easier than seeing a flat line and deciding it can't be turned into an upward trend.
> So if the explanation was just that the culture doesn’t reward maintaining existing projects, I’m sure we would have heard something about a corporate incentive to maintain stuff.
So, two things:
1) Changing culture is really hard, especially at a company the size of Google, and
2) Even if they could change the culture, it's possible they simply don't care or they believe the benefits outweigh the cost.
How about this explanation instead: Google doesn't actually have a habit of canceling projects that are well-loved?
If you don't believe it, try selecting 10 of their supposedly killed products at random. Had you honestly heard of them ever before? Do they look like something that would have had a significant user base? Hell, do they even look like they were actual products?
> product launches and cancellations are a consequence of an internal culture that rewards launching new products, but not maintaining or improving them
This is very stale information at this point. Product launches are now pretty heavily gated, and promotion criteria are far less based on launches than on overall impact, including but not limited to improving/maintaining products.
I think that depends where you are. There's a lot of lip-service being paid, but from what I've seen, it's mostly translated to talking about _landings_ rather than _launchings_, which isn't much of a change.
I think landings allows for a much broader scope of accomplishments. For example, if refactor an entire system for demonstrably better maintainability and efficiency, that's a landing, but not a launch.
People say this all the time about every company. For many this is true, when seen from the narrow perspective of an individual. However for the only metric that people care about (stock price and profit) Google’s system is incredibly successful. Higher ups will not dictate changes like this if the company is successful. Culture change at the macro level only happens when the company is spiraling at the macro level.
That's a wild leap with zero evidence. Fuchsia runs on one unimportant production device and has basically zero usage. Saying it will replace all of Android and ChromeOS is...optimistic to say the least.
> For more than two years, a small and stealthy group of engineers within Google has been working on software that they hope will eventually replace Android.
> "And while Android is reaching EOL in the next 4-5 years, most of this work will be carried on in Fuchsia OS, which is set to eventually replace Android"
May be. We have not seen future. But that is not the point and a person who is claiming there is "zero evidence" is mistaking absence of evidence to evidence of absence. Arsetechnica has published several articles on this topic in past and are available to read on Wikiepedia page for the OS.
General information suggests this is one of those long term things if successful would be massively game changing.
Better than all existing options? I'm skeptical that a kernel written in C++ is likely to be better than e.g. a formally verified microkernel such as seL4. If they ever rewrite it in Rust, then it might be more interesting.
If it improves the security of the device and means that Google will keep updating it, then that will be good. However, personally I have given up buying Google-branded devices. They only gave me security updates for my Pixel C for three years (2016-2019).
This seems like a good question, and I also hope someone with good knowledge/experience around this to give some good comparison.
I have given only very cursory look into QNX and Fuchsia/Zircon and it seems that one of the main difference is the capabilities-based architecture in Fuchsia. It's a big change in the API/conceptual model, but we'll have to see if that actually translates into a meaningful difference at the application level - e.g. whether it allows building new types of applications, or allows building meaningfully more secure/fast/reliable applications.
This seems like a pretty flawed strategy to me. Lots of improbable products turned into multi-billion dollar companies. Tiny videos set to music, watching other people play video games, liking pictures of food, and so on. It seems to me that it's less about the product and more about the execution. There are lots of Google products that could have taken off if they had been iterated instead of abandoned. Take Apple as one example. They develop a product vision, then spend several versions refining the thing till it goes from a curiosity to a must have. Or look at Facebook with Oculus, they had a vision and released headset after headset, till they found a feature set that had the user engagement metrics they were looking for. They didn't just give up once the Gear VR proved to be a dead-end, which is exactly what Google did with their VR efforts and then cleanly missed the boat Oculus is on now with the Quest.
> All that we do now is find ways to make that hose go faster, and desperately search for another hose.
There’s one other thing Google does a lot of: try to foresee and actively forestall how someone else might cut-off or divert the flow to the existing hose. While both Chrome and Android evolved in directions that explored potential new hoses, they were clearly both initially directed at protecting the existing hose from being choked off or diverted by monopolies on the client side; Android was purchased and engineered to prevent Apple gaining the kind of dominance in mobile to do that, Chrome and Chrome OS against the desktop Windows monopoly and IE.
Google+ was deployed against Facebook and abandoned once it was clear that Facebook’s position, while making it something of a competitor for ad dollars, wasn’t, even without a competitive Google alternative, an existential threat to Google’s money hose.
This is the big one that people forget. Android itself isn't there to force tracking and marketing on users. It's there to prevent somebody else from controlling mobile devices and being a gatekeeper between Google's services and users. As long as nobody else can prevent Google from reaching users, Google doesn't care that people can run Android without Google services.
In practice, poor development practices and incompetent product management has left some bits hard to change. The search provider used to be hardcoded with no way for the user to override it. That only changed when some early Android phones began shipping with Bing as the default. To this day, it is impossible to allow any non-system app store to update apps in the background. This hasn't changed only because Amazon, Samsung, and many other OEMs failed to get developer traction with their own app stores. Now that there are antitrust rumblings, Google has hinted they will finally fix this, but once again, this isn't a threat to the core Android strategy of removing gatekeepers.
> Android itself isn't there to force tracking and marketing on users. It's there to prevent somebody else from controlling mobile devices and being a gatekeeper between Google's services and users.
If that were the case, it would require more data collection than competitors and force ads. Instead, you can trivially get your location on Android devices (even those sold by Google) without telling Google. You cannot on iOS. You can install apps on your Android device without telling Google. You can develop apps for your own device without telling Google. To do any of these things on iOS requires exploiting a vulnerability.
Similarly, Google doesn't give itself a privileged separate settings for marketing data collection that ignore global settings. https://support.apple.com/en-us/HT202074
If the point of Android were data collection and marketing, Google would abuse configurability of data collection at least as much as Apple does, but it does not, not even on devices that Google itself sells.
Google Play Services is essential for most features a user would expect in a modern mobile phone. For running bank apps (SafetyNet), many maps apps or apps that include maps (eg Uber, Tinder - due to Google Maps API), push notifications, etc. It's absolutely used to lock-in users to the Google ecosystem and discourage them from degoogling.
Those are services that can be provided by others on any Android device, including those sold by Google. The fact that others aren't providing those services doesn't mean Android itself is meant to lock in users (or to collect data / serve ads), only that others haven't found a reason to provide those services. Google also provides many of those services on other OSes it does not develop (e.g., Chrome push notifications and Widevine).
Yep, the reality is that it was more likely a defensive play against Microsoft. At the time (mid-2005) it seemed most likely that Windows Mobile would eventually take over, and Android's strategy was taken from the Windows Desktop playbook.
Google had to postpone Android phones once iPhone launched because Google realized how badly they'd misjudged smartphones, particularly on-screen keyboards & multi-touch (& thinking that their primary competitor was Microsoft and Nokia & not Apple). It's actually a testament to the leadership that they managed to recognize that Apple was the 800lb gorilla here so quickly (which clearly wasn't obvious to other competitors in the space).
> which clearly wasn't obvious to other competitors in the space
I had a family friend that was a tech writer in 2007 or so. He proudly mocked my interest in the first iPhone. Pulling me aside and showing me how his blackberry had a mini trackball and a mouse cursor and just how precise this all was.
It’s obviously funny now, but yea I remember a lot of the “smart money” was against the modern smartphone at the time.
How exactly does a random piece of IoT junk that looks like it could come from any single one of countless fly-by-night manufacturers in Shenzen (namely the "Nest Hub" that's now running some version of Fuchsia, per the OP) turn into a money-making firehose for Google? Just curious, because I'm having trouble seeing how this could make sense.
The problem is that many good ideas only look good in hindsight.
In 15 years, we'll either say "Fuchsia was a brilliant move, I'm so glad my home runs on that OS" or we'll say "Remember Fuchsia? lol".
Here's what I mean. Acquisitions by Google in 2005: Reqwireless (mobile ads, merged with google analytics); Dodgeball (social networking, later Google Latitude); Akwan (Search tech); Skia (graphics library); Phatbits (Google Desktop); allPAY (???); bruNET (???); Android (cheap OS for mobile devices).
In 2005, which of these were going to change the world?
Advertising/influence depends on two things:
1) Knowing what you're thinking (e.g. the search request you speak to your Nest Hub)
2) Presenting messages to you (e.g. displaying search results/suggestions/ads on the Nest Hub screen in your home)
No, most private companies are not monopolies (although many would not mind I guess).
It seems online advertising has a strong network effect[1], where website owners use Google ads because that's where most advertisers are and advertisers use Google ads because it has most reach (and therefore tracking). This naturally creates a monopoly, just like with Facebook, twitter, LinkedIn, AirBnB, Uber etc.
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
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.
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.
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.
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.
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.
> Hangouts _is_ Meet and Allo, if it weren't for the constant migration notices leading to constant commentary no one would be the wiser,
So, let's say that's true (and bluntly, after the Hangouts EOL notice I just jumped ship entirely to Signal as, frankly, I couldn't be bothered to figure out what the heck Google was doing), and that Allo and Meet--which are marketed as two different products--are somehow seamlessly integrated with the rest of the Google ecosystem so that you didn't actually need to grok the differences.
Assuming that was true, Google still completely botched the communication, and believe it or not, marketing and communication are really damn important. Google could have the greatest technology ever, but they're perceived as being unreliable, and both their words and their actions reinforce that perception.
So, maybe in this specific example, the transition wasn't as traumatic is the flat out cancellation of Reader or Plus. But in the end, the communication was so muddled that it ultimately doesn't matter because to the rest of the world outside the Google bubble it just looks like yet another example of Google being Google.
AFAICT, the primary effect is that HN commentary on any google release has approximately zero SNR. Some back-room team could cure cancer and the HN thread would be 90% complaints about Reader. Compare/contrast the vast numbers of dead github projects, dead startups, and dead code generally. (Also, who the fsck calls the cancellation of plus traumatic?? That's comedy gold.)
This is an open source release under the MIT license. You can use it, fork it, or ignore it...
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?
> The first major open source kernel since Linux, and somewhat arguably OS X, has been released.
Depending on your definitions, OpenSolaris and Redox would object. And it's open sourced in a way that's designed to support making proprietary products, so you'll forgive my not really celebrating.
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!
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.
>> 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!
Please don't repeat shallow-dismissal clichés and particularly not with added snark. You may not owe $BigCo better, but you owe this community better if you're participating in it.
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
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.
> 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.
> 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.
That seems like a good thing to me. Personally I'm not very interested in an OS that's 'bold', I want an OS that's stable and well tested and releasing slowly on a limited set of devices seems a good way of doing that.
Where else could've they launched it? It's not like Apple has tons of HW products that require M1.
If Google would chose to launch Fuchsia as a base of next Android and force all OEMs on it, that would mean people managing release should be fired, as that's not how you stage major changes.
This not make much sense, but if Google launched it in his own, then at least some OEMs could go along (supposing Fucsia is good, I don't know which could their selling point)
Apple has been launching the "M1" piece by piece for years now. They started with Qualcomm/PowerVR cores and ended up with custom designs over years of iterative product launches.
I have no idea why do you think M1 is such a green field effort when it obviously shares so much of it's design with A series SoCs you've been seeing in your favorite iDevice.
You do realise that Apple's M1 processor + OS porting was a 10 year goal to produce the results that you see before you?
Several years ago [0], the same ones here were calling Fuchsia dead since 2016 - 2018 and theoretically today it should already have died. Today Google has surprised the skeptics here and just released Fuchsia 1.0 on a real device (earlier than expected) and now you're already calling it dead again?
This whole thread sounds like a Linux meltdown club to me. In fact, Google is taking / controlling Fuchsia in the same direction as to what Apple has always done with iOS / macOS and its own silicon.
Perhaps when this decade ends, you will be looking at this comment (and this one [1]) via a phone running Fuchsia.
> but when Apple LAUNCH it, it do it WitH cONfIdeNCE.
The answer I'm looking for is that during this 10 year effort Apple had already and always used their existing designed ARM chips in their iPhones and iDevices. Once they improved it over time and it surpassed their Intel counterparts, it was the time to target the Mac which is why you are hyping over the M1 performance.
In fact, macOS was already on ARM years ago. It's just that it would have ran slower and wasn't ready which is why they waited and here we are.
But this claim:
> And this is how you know fucsia/google will not.
How can you be so certain that the owner of the world's most used mobile operating system [0] and a very competitive desktop OS on the market [1] cannot or 'will not' launch Fuchsia with confidence (even when they just did)? Don't you think it's extremely too early to make such vacuous claims without ANY compelling evidence?
Apple apologist here, but uh, really the M1 isn't a first-gen product, it's more like a TENTH-gen product. It's a direct evolution from the A4 chip series, and apple only did the big sexy "we mean business" rebrand when, after a decade of R&D, they'd basically bred a mouse up to the size of a mammoth.
Apple quietly ramped it up year over year; at its initial release, it was just another "me too" phone ARM chip, but as they built it, after a few years they had their own chip design team and were no longer just popping in generic ARM Cortex designs. Then it quietly got 2, then 3x faster than the other phones on the market. Finally it reached full parity with common-market intel chips; apple made sure their "intel on arm" emulator was working well.
They still didn't release it! They waited a couple more years - until it was so fast that even emulated, it would be comparable with a brand new low-end intel machine, and then, finally, they branded it as the M1 and released it.
---
Google's strategy seems to be playing out really similarly. Put it out in the wild in some devices where they won't get flak for the usual teething problems. Work all of those out, and then, once it's pretty robust, make the big confident "sexy play" to deploy it on an android phone.
Another way of looking at it is that it probably takes a really long time to bring up an operating system to the point where it is production-ready.
It would be easier to do if you can target one hardware platform that does not change so that you don't have to also shift gears. If you're building the Great Pyramid, you don't want to also move it to a new construction site when it's half-completed.
Launching on hardware that was already released could mean they gave themselves that time. By the time they're finished (now), the hardware is old.
> A bold move would have been to put this on the next Pixel.
Which will delay the next Pixel at least several years while causing a unprecedented level of fragmentation in the Android ecosystem? BTW, I don't expect this kind of experimental projects can live without reaching any milestones. Replacing Android with Fuchsia is just not a feasible option at this moment.
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.
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 think OP's point is it doesn't matter if the drivers are crappy, as long as they only use a fixed and we'll defined interface.
If drivers all had a well defined interface, the exact same driver, binary or source, can be used across any OS version, and maybe even on other OS's with the right shims.
Then you don't need driver manufacturers to all collaborate to update the OS.
I wonder if a stable driver interface could also result in higher driver quality: if the same driver keeps working across many versions, even with relatively few users it could aggregate incremental improvements from various parties?
Why can't the vendors just contribute their drivers to the kernel? Why is it so hard? Looks like Intel is doing it and their products just work on Linux as a result. Why can't these shitty mobile hardware manufacturers do the same?
The sad answer is that they can't be bothered to meet the quality standards expected for upstream kernel code. Easier to just throw garbage in a tarball and ship privesc vulnerabilities to millions of users.
> Microsoft knew that, so they made sure to be ABI compatible so they could keep updating the OS.
That's just not true. A lot of hardware support was stranded by OS version updates, especially pre-Vista and Win7. It's reached a point where Linux deals a lot better w/ some older hardware than any currently-supported Windows version.
There were a lot of drivers who will not work with new windows versions. Due for examples of changes in things expectedv in the inf file or the registry. Installing drivers in windows was a lot of pain.
Ok, but again when you talk about "new windows versions" you're talking about an event that happens very infrequently, and most drivers do continue to work for decades without needing to be updated across multiple major versions. Windows 7 drivers from 11 years ago generally speaking still work in Windows 10 today. Hell, even Vista drivers (14 years ago!) often still work. Contrast that with the Linux kernel where you have to recompile external drivers, what, every few weeks?
Not just hardware but even older Windows applications run way better on WINE than on Windows 10. Microsoft doesn't care about reverse compatibility or long-term support for consumers.
> Microsoft knew that, so they made sure to be ABI compatible so they could keep updating the OS.
I don't remember it that way. I remember buying motherboards and receiving CDs full of drivers for the many Windows versions. I remember having to scour the internet for drivers and finding a different one for each Windows version. I remember failing to find drivers for new versions of Windows because the manufacturer couldn't care less. I remember incredibly shitty manufacturer applications that took over one minute to display a window on the screen. I even managed to reverse engineer one of those into a free software user space driver.
> I remember buying motherboards and receiving CDs full of drivers for the many Windows versions.
There haven't been "many" Windows versions in the entire existence of Windows. I bet you don't remember getting different drivers for every service pack or security update.
AMD already does and that creates a lot of friction both due to the bloat of the kernel the majority of which is now the AMD driver and the issue with code conventions and quality.
Unless hardware vendors agree to support a generic driver for each device type which can be maintained by the Linux kernel team it’s going to be a total nightmare and even then you need an easy model to extend the generic driver with a device specific one through an easy interface.
The AMD driver bloat is the register definitions. They have like 100+ MB of autogenerated register defines, some duplicated 8 times for each unit instance, for every chip generation and variant.
It's not real code, though it is ugly as heck and I have no idea why AMD can't do it a saber way.
They do have a high quality product. And then you have to buy their next high quality product instead of continuing to use the old one. Their products are hardware, not drivers, and they get more money by selling more hardware rather than letting old hardware get updated.
Can't use the hardware without the drivers. If the driver is low quality proprietary code that can't be fixed or updated, they don't have a high quality product.
And yet here we all are with umpty billion Qualcomm SoCs floating around and nobody complaining about how Qualcomm's chips don't work well (except, of course, in comparison to Apple's).
The hard reality that Linux kernel driver model stalwarts must face is that the only measure that matters to these companies is profit margin, and the economics just are not in favor of upstreaming their drivers. So knowing that, do we continue to yell into the night or do we implement a solution that doesn't leave umpty billion devices without kernel security updates?
> So knowing that, do we continue to yell into the night or do we implement a solution that doesn't leave umpty billion devices without kernel security updates?
Absolutely. Google has more than enough power and leverage to solve this problem. Why doesn't it require manufacturers to upstream their drivers instead of enabling their shitty industry practices? Literally just make it a requirement for Google Play services licensing or something. The phone manufacturers will be forced to require it from the chip manufacturers as well.
Google already does a lot of good work getting open source firmware into chromebooks. It should do even more. Use all that intellectual property for good for once.
Nowadays, a lot of products go out of production and are replaced by the next model before they have time to settle and get a consumer reputation. It sometimes feels like they do only 1 production run per model and then bye-bye. So, quick and "good enough", "as good" or "not worse than others" is good enough :-/
> Do they not care about having a high quality product?
No.
They care about maximizing shareholder value. If shipping lots of hardware with barely functional drivers integrators need to beat up into shape makes the most profit, that's what they'll do.
If you spend $20K more on making the software work, then it pays off paying $1 less for a part with a crappy driver than buying one from a vendor who also provides great software for anything you intend to sell more than 20K units.
I second others: it is horrible, low quality code.
I spent lots of time looking at released drivers for things like wifi dongles and cheap Linux sticks/tablets, and there are all sorts of horrors. The wifi cards do not fully implement scanning or ad-hoc mode. Existing ioctls are ignored or implemented wrong. Sleep is used for thread synchronization. Android device drivers hardcode specific app names and apply fixups for them, presumably to prevent crashes.
Intel has much better code, at least in wireless drivers, but to be fair their jobs is easier, because most of the logic runs in the embedded processor, and you only get the binary blob for its code.
I'm guessing that depends on how big the pile of Fuchsia-compatible device drivers grows and how badly people running open source OSes want to use that hardware.
Where there's a demand for a particular class of device, maybe someone will create a shim? Then the kernel folks can have a debate.
Currently though, I think Linux has a big head start.
Okay, but having a stable interface doesn't fix vendors shipping bad code, it just decouples it so you can run terrible drivers on a less-terrible kernel. Better yet, Fuchsia removes any obligation for vendors to share code (by both separating drivers from the OS and having the OS itself be permissively licensed), so third parties can't even start from vendor code and try to improve things.
Binderized HALs => HALs expressed in HAL interface definition language (HIDL) or Android interface definition language (AIDL). These HALs replace both conventional and legacy HALs used in earlier versions of Android. In a Binderized HAL, the Android framework and HALs communicate with each other using binder inter-process communication (IPC) calls. All devices launching with Android 8.0 or later must support binderized HALs only.
These are two distinct problems. Rather, one is an improvement and another is a problem. The terrible drivers can then be isolated, pinpointed if you want, and the OS can move forward - if you don't use the AMD GPU or the HP printer no need to have it bloating your kernel, so I take this as the improvement (I was always fond of microkernels, so I'm advocating here). On the second problem, I fail seeing how the blame for vendors failing to update their drivers could fall on the OS. With this approach the failing is just much more evident, not any less damaging.
> The term of OS is heavily overloaded. But Fuchsia's goal is NOT to build other Android, but mainly to replace the Linux kernel.
To paraphrase a popular saying, "the driver interface apparently has an abstraction problem, so Google created Fuchsia - and now we have two problems."
It's a pet project. If you want to solve the kernel ABI problem, you can easily hard-fork and maintain that ABI indefinitely from any Linux kernel.
And if that sounds like it's too hard, imagine how hard it is to maintain your own kernel, and all the associated user space you now have to reinvent.
In fact, you don't even need to hard fork. You could have your own rolling tree with a stable "Android ABI" interface that vendors can write drivers against, optionally.
In any case, no company in their right mind would use this project. Google has proven repeatedly they will enforce a monopoly on their platform one way or another.
Android already uses a similar model since Project Treble was introduced, with version 8 all drivers must use Android IPC instead of being Linux drivers.
Treble driver model is quite similar to Fuchsia, so it already happened, no need to prove anything.
> 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.
The postmarketOS folks are doing it, starting from downstream OEM Linux kernels, and the patches are being accepted on LKML. It's a lot of work because so much ARM hardware is its own weird mixture of long-supported basic IP blocks and newer stuff with its own quirks, and ARM has nothing like the plug-and-play hardware enumeration of modern x86 systems. So untangling all of this just takes a lot of time and effort. But this has nothing to do with Linux per se; it's all about the ARM system architecture itself and the SoC-based industry that has sprung up around it.
And no, running a microkernel-based system won't help at all, because any hardware that's part of the SoC can read or write arbitrary memory hence your driver can (perhaps unwittingly) subvert the very same security mechanisms you're supposedly relying on. Not to mention that some of these drivers handle, e.g. voltage regulators that will happily fry your hardware irreversibly if poked the wrong way. All of this stuff is inherently part of the trusted base of your system, so you're not going to do any better than what Linux already gives you.
> the monolithic natural of Linux Kernel and its strict licensing terms made it hard to get code upstreamed
> In 2018, we got the OS running natively on a Pixelbook. After that, the Fuchsia team stopped doing its work in the open and stripped all UI work out of the public repository.
Linux (AFAIK) still doesn't require the typical CLA paperwork or copyright assignment. The "strict licensing terms" of the Linux kernel ensures that kernel stays open. If openness is a goal of Fuschia, the GPL would not be a problem here.
If anything, Linux needs a harder license, like GPLv3 or similar, to maintain openness in a world of locked bootloaders and not-even-half-baked clone appliances with manufacturers who aren't interested in coughing up the kernel source.
> strict licensing terms made it hard to get code upstreamed back
How come?
Right now, the phone ecosystem isn't perfect. It's hard to update phones. Why is that? Because manufacturers don't care about long-term support. But at least you could ask them for kernel source, fix their drivers and eventually upstream everything, like postmarketos does.
Now, with a stable driver ABI and permissive license, drivers won't get released. Hardware vendors still have no incentive to support old hardware, so bugs will remain unfixed, and hardware will decay as usual... Oh, sure, maybe you'll get one more update before reaching an edge-case in some driver? I also expect manufacturers to put all kind of ugly things in the kernel if no agreement with google prevents them to do so. Cue "branded" kernels, with drivers incompatible with each other due to some extra or removed APIs. And back to square one, but with only binaries and no source this time around.
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.
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.
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.
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.
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.
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.
You don't need a new Android phone every two years and you haven't needed to for a while now. The Android situation certainly isn't as good as the Apple situation, but it's not as bad as ten years ago.
For most people, the only problem using a five year old phone today is the degraded battery. Almost all software is backwards compatible with the old operating systems and nobody simply outside IT cares about kernel updates. Journalists, human rights activists and American refugees like Snowden should fear kernel exploits, your average Joe is pretty unlikely to actually get infected. The massive segregation of Android devices is actually a good thing in this scenario, because you need to prepare your exploits for whole ranges of devices and several versions software versions, making "the Android botnet that ends all Android botnets" incredibly hard to build.
The Android privacy nightmare is all Google being built around spying; the security nightmare is mostly due to brands like Samsung not releasing timely updates, not necessarily because Broadcom and Qualcom don't build patches.
With medium to high end Samsung devices now reaching four years of Android security updates, the entire field is slowly becoming much better. The cheaper, low-end devices lag behind, but it figures that people who cannot afford a $300 phone can't pay for software support and the profit margins become razor thin the cheaper the phone gets. Five years of software updates for a $90 phone just isn't realistic.
This whole situation is why I lament Windows Phone's failure. Microsoft had the right idea, which carriers hated, that the operating system should be independent of the rest of the device. Carriers wanted to force their ugly branding everywhere and fought hard against MS, who themselves bumbled and failed spectacularly by breaking backwards compatibility with every major Windows Phone release, and the entire project was doomed to fail.
Android could have been similar to Linux; a Google-supported core repository with vendor packages for drivers, updatable in the same way Debian is. Nobody outside the hacker community seems interested in this approach, but it could have been.
I think you give some valid concerns. I definitely understand you, but I want to give some counter arguments to where I'm seeing chances with Fuchsia in addition to the dangers that you rightfully point out.
First, there are thriving non-copyleft driver projects, like mesa. No copyleft forces Intel to contribute to it. No copyleft forces AMD.
Second, even in Linux, many drivers aren't maintained by their vendors, but third parties. I think that an upstream driver is generally easier to deal with for most parties, so most parties would prefer it. If fuchsia is indeed as modular as it promises to be, users can swap out those drivers, at least in custom ROMs. Android custom ROMs already copy over proprietary drivers from the native OS upon installation.
Third, the GCC compiler has artificially restricted the ability to use it as a backend for third party languages, which led to many projects choosing LLVM instead. These projects now contribute to LLVM's success. Yes, some extensions to LLVM are proprietary. Still many companies contribute to LLVM directly.
Fourth, legal action doesn't turn a company into a good citizen. They might release the source code in the end but they become extremely hostile to free software projects coming forward, because suddenly the legal department got involved. Those employees who share the cause can't freely talk on mailing lists any more because all mails to the project first require approval by a company lawyer. Etc. The released source code might be unusable anyways because it's done to a fork of an outdated version of the kernel.
> First, there are thriving non-copyleft driver projects, like mesa. No copyleft forces Intel to contribute to it. No copyleft forces AMD.
This is not entirely true. Mainline Linux has a longstanding policy of not including kernel-side graphics support in the officially-released tree unless it can be used with a totally Free userspace. So Mesa is, to some extent, piggybacking on incentives that have been established as part of the GPL'd Linux kernel.
Well if you hang Free Software's hopes entirely on the Linux kernel, or the Linux kernel doesn't mature to the point where it isn't the hall monitor for everyone's code quality, then that might be what happens.
Darwin might be knocking. Evolve or die.
(And its a bit weird that the Linux kernel is so centralized with a cabal lead mostly by one dude who yells at everyone on the planet about their shitty driver code quality. If you're at all Libertarian or libertarian, that should probably bug you a bit that Free Software picked that as the ideal model.)
Linux only happened because Microsoft didn't care to put much love on their POSIX subsystem for Windows NT, and BSD was busy fighting AT&T.
Looking at the pleothora of BSD/Apache/MIT OSes appearing for embeeded devices it is clear what the future of Linux will become, when the generation that gave birth to it is gone.
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.
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.
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.
> 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.
I share your feeling, but I'd rather have a none isolated driver I can trust than an isolated one I cannot trust. My threat model includes fishy OEM doing borderline things.
In driver development I often see abstraction violations or very loose abstractions: news hw capabilities can't be accounted for when designing framework abstractions.
I have never done dev on windows, but I guess there is a reason why the form factor of things running windows is pretty limited. I don't see how you can have fixed interfaces in an ever evolving wold.
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/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.
> 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.
Given that Fuchsia is not GPL licensed (making proprietary forks possible & likely) and apparently developed behind closed doors, not by a self sustained community like the Linux kernel its not very far from your worst case scenario, especially if Google starts force feeding it into Android like it did with many non GPL and proprietary licensed software over the years.
I wonder how much GPL actually protects against proprietary forks. Aren’t most of these driver vendors in China where Google would have little recourse if GPL is violated?
Well, at least it makes major vendors cooperate - for example a lot of modern Sony PlayStation hardware runs heavily modified FreeBSD, yet anything the project ever got back from Sony is IIRC some multiprocessing improvement patches.
Also the multitude of companies contributing together to the Linux kernel are often direct competitors. Yet due to the GPL all their contributions are available to everyone else - so even though you are technically helping your competition, they have to do the same thing for you.
With permissive license, you competition can take the code and run with it, never contributing anything back, kinda like how Sony did in the example above.
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.
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.
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.
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.
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.
243 comments
[ 3.3 ms ] story [ 253 ms ] threadPerhaps it is a corporate wide move to stop contributing to Linux. Or perhaps they plan on displacing Linux from the computing world.
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.
Are you talking about Linux, or Android specifically? Either way, I don't really agree that there's "little" going on there.
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.
[0] https://blackberry.qnx.com/en/software-solutions/automotive/...
My three favorite GUI operating systems, putting aside software support, are iOS, BeOS, and... Photon on QNX.
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.
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?
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.
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.
This is absurd. Fuchsia has all of shared libraries, filesystems, users and permissions. Probably even more of those than Linux.
And while I am a fan of microkernels, I can hardly claim that have become more interesting as of lately. In fact, I would even claim they have become even less interesting, since people are now taking seriously for some reason all the side channel attacks that practically make hardware-enforced privilege separation useless.
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.
"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.
Sometimes they stumble upon something another PA needs, but often it just ends up as a patent or research paper.
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.
https://news.ycombinator.com/newsguidelines.html
Look no further than you're being _upvoted_ for quintupling down on inanity completely divorced from the article that's we're supposed to be discussing, even with schoolyard debate nonsense like "can you name even one thing backing up your thesis statement?" (back in the day, or still with more traditional HN posts, you'd get something more like: 'I find that surprising, what makes you feel that way?'. Dang calls this "coming with curiosity" or something like that)
Meanwhile in the sibling thread, we have a guy with a year old account neener-neering me for daring to mention things are bad because it's a noob fallacy, and people who have actually been here a while getting flagged/dead through the floor for pointing out this _isn't actually some steadfast rule_, its a classic HN "rule". Meanwhile, I've been here for 12+ years and its never been close to being as bad as it is right now.
This site, and you, are getting what always happens to these sites: too large of an audience to preserve quality of discussion over group dynamics. You shall inherit the board, but, no one will be the wiser for you being here - it's all half-baked assertions, schoolyard bully absolutist nonsense that you know isn't argumentation, you'd never talk like that to someone in real life. Then add the thesis here being that people _in the actual company_ aren't seeing the truth, their coworkers are engaged on makework PhD bullshit because otherwise they'd jump to Apple (never mind that the #1, #2, and #3 pieces of career advice in the valley is to leave so you get promoted)
As for your "coming with curiosity" scolding attempt? Please review the first two words of my comment.
Who can divert from Google's massive ad income funnel?
Apple.
Facebook.
(Also maybe several foreign governments' antitrust cases.)
An engineer on your payroll is an engineer not on the competition's payroll.
Guido van Rossum (creator of Python) is a Distinguished Engineer at Microsoft. Before that, he worked at Dropbox.
I get the quarterly check-ins from the "alumni recruiting" team, and can assume Guido does too.
"Zircon is the core platform that powers Fuchsia. Zircon is composed of a kernel (source in /zircon/kernel) as well as a small set of userspace services, drivers, and libraries (source in /zircon/system/) necessary for the system to boot, talk to hardware, load userspace processes and run them, etc. Fuchsia builds a much larger OS on top of this foundation."
- Fuchsia Docs, https://fuchsia.dev/fuchsia-src/concepts/kernel
Always building new infrastructure, and not maintaining the existing one.
This has two logistical consequences: 1 - it's more valuable to launch a new product that it is to successfully maintain/grow a current one. 2 - the person running these new projects tends to get promoted away, leaving it rudderless.
Google could change all this overnight by restructuring what these review boards prioritize.
So, two things:
1) Changing culture is really hard, especially at a company the size of Google, and
2) Even if they could change the culture, it's possible they simply don't care or they believe the benefits outweigh the cost.
If you don't believe it, try selecting 10 of their supposedly killed products at random. Had you honestly heard of them ever before? Do they look like something that would have had a significant user base? Hell, do they even look like they were actual products?
This is very stale information at this point. Product launches are now pretty heavily gated, and promotion criteria are far less based on launches than on overall impact, including but not limited to improving/maintaining products.
(Googler but interpretation is my own)
(Also a Googler.)
It wont. From what I understand this new OS will replace others over time. Also it is way better than existing options.
> For more than two years, a small and stealthy group of engineers within Google has been working on software that they hope will eventually replace Android.
https://news.ycombinator.com/item?id=19702968
> "And while Android is reaching EOL in the next 4-5 years, most of this work will be carried on in Fuchsia OS, which is set to eventually replace Android"
I wouldn't bet on it. Sounds like IBM OS2 all over again.
General information suggests this is one of those long term things if successful would be massively game changing.
QNX appears to already be in every market where Fuchsia wants to go.
Google could have bought Blackberry and used QNX in Android 5, rolling it up to Chromebooks. Why was this not the path they chose?
I have given only very cursory look into QNX and Fuchsia/Zircon and it seems that one of the main difference is the capabilities-based architecture in Fuchsia. It's a big change in the API/conceptual model, but we'll have to see if that actually translates into a meaningful difference at the application level - e.g. whether it allows building new types of applications, or allows building meaningfully more secure/fast/reliable applications.
There’s one other thing Google does a lot of: try to foresee and actively forestall how someone else might cut-off or divert the flow to the existing hose. While both Chrome and Android evolved in directions that explored potential new hoses, they were clearly both initially directed at protecting the existing hose from being choked off or diverted by monopolies on the client side; Android was purchased and engineered to prevent Apple gaining the kind of dominance in mobile to do that, Chrome and Chrome OS against the desktop Windows monopoly and IE.
Google+ was deployed against Facebook and abandoned once it was clear that Facebook’s position, while making it something of a competitor for ad dollars, wasn’t, even without a competitive Google alternative, an existential threat to Google’s money hose.
In practice, poor development practices and incompetent product management has left some bits hard to change. The search provider used to be hardcoded with no way for the user to override it. That only changed when some early Android phones began shipping with Bing as the default. To this day, it is impossible to allow any non-system app store to update apps in the background. This hasn't changed only because Amazon, Samsung, and many other OEMs failed to get developer traction with their own app stores. Now that there are antitrust rumblings, Google has hinted they will finally fix this, but once again, this isn't a threat to the core Android strategy of removing gatekeepers.
It can be, and is, both.
Similarly, Google doesn't give itself a privileged separate settings for marketing data collection that ignore global settings. https://support.apple.com/en-us/HT202074
If the point of Android were data collection and marketing, Google would abuse configurability of data collection at least as much as Apple does, but it does not, not even on devices that Google itself sells.
https://venturebeat.com/2008/08/07/first-android-phones-push...
I had a family friend that was a tech writer in 2007 or so. He proudly mocked my interest in the first iPhone. Pulling me aside and showing me how his blackberry had a mini trackball and a mouse cursor and just how precise this all was.
It’s obviously funny now, but yea I remember a lot of the “smart money” was against the modern smartphone at the time.
They're not innovating at this point. They're twiddling thumbs.
If we broke up Apple, Google, Facebook, and Amazon, then they'd be forced to fight for survival.
Struggle births innovation.
In 15 years, we'll either say "Fuchsia was a brilliant move, I'm so glad my home runs on that OS" or we'll say "Remember Fuchsia? lol".
Here's what I mean. Acquisitions by Google in 2005: Reqwireless (mobile ads, merged with google analytics); Dodgeball (social networking, later Google Latitude); Akwan (Search tech); Skia (graphics library); Phatbits (Google Desktop); allPAY (???); bruNET (???); Android (cheap OS for mobile devices).
In 2005, which of these were going to change the world?
Searching for sources of income ?
It seems online advertising has a strong network effect[1], where website owners use Google ads because that's where most advertisers are and advertisers use Google ads because it has most reach (and therefore tracking). This naturally creates a monopoly, just like with Facebook, twitter, LinkedIn, AirBnB, Uber etc.
[1] https://en.wikipedia.org/wiki/Network_effect
I guess a microkernel is pretty cool though, the academic ideal.
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.
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.
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.
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.
So, let's say that's true (and bluntly, after the Hangouts EOL notice I just jumped ship entirely to Signal as, frankly, I couldn't be bothered to figure out what the heck Google was doing), and that Allo and Meet--which are marketed as two different products--are somehow seamlessly integrated with the rest of the Google ecosystem so that you didn't actually need to grok the differences.
Assuming that was true, Google still completely botched the communication, and believe it or not, marketing and communication are really damn important. Google could have the greatest technology ever, but they're perceived as being unreliable, and both their words and their actions reinforce that perception.
So, maybe in this specific example, the transition wasn't as traumatic is the flat out cancellation of Reader or Plus. But in the end, the communication was so muddled that it ultimately doesn't matter because to the rest of the world outside the Google bubble it just looks like yet another example of Google being Google.
AFAICT, the primary effect is that HN commentary on any google release has approximately zero SNR. Some back-room team could cure cancer and the HN thread would be 90% complaints about Reader. Compare/contrast the vast numbers of dead github projects, dead startups, and dead code generally. (Also, who the fsck calls the cancellation of plus traumatic?? That's comedy gold.)
This is an open source release under the MIT license. You can use it, fork it, or ignore it...
Depending on your definitions, OpenSolaris and Redox would object. And it's open sourced in a way that's designed to support making proprietary products, so you'll forgive my not really celebrating.
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.
So they can cancel more products if they keep Fuchsia!
No, but replacing android or chrome OS with a new OS built from scratch should right?
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html
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
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.
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.
That seems like a good thing to me. Personally I'm not very interested in an OS that's 'bold', I want an OS that's stable and well tested and releasing slowly on a limited set of devices seems a good way of doing that.
That is how you know Apple mean business.
And this is how you know fucsia/google will not.
If Google would chose to launch Fuchsia as a base of next Android and force all OEMs on it, that would mean people managing release should be fired, as that's not how you stage major changes.
This not make much sense, but if Google launched it in his own, then at least some OEMs could go along (supposing Fucsia is good, I don't know which could their selling point)
I have no idea why do you think M1 is such a green field effort when it obviously shares so much of it's design with A series SoCs you've been seeing in your favorite iDevice.
Several years ago [0], the same ones here were calling Fuchsia dead since 2016 - 2018 and theoretically today it should already have died. Today Google has surprised the skeptics here and just released Fuchsia 1.0 on a real device (earlier than expected) and now you're already calling it dead again?
This whole thread sounds like a Linux meltdown club to me. In fact, Google is taking / controlling Fuchsia in the same direction as to what Apple has always done with iOS / macOS and its own silicon.
Perhaps when this decade ends, you will be looking at this comment (and this one [1]) via a phone running Fuchsia.
[0] https://news.ycombinator.com/item?id=17568335
[1] https://news.ycombinator.com/item?id=22005286
The answer I'm looking for is that during this 10 year effort Apple had already and always used their existing designed ARM chips in their iPhones and iDevices. Once they improved it over time and it surpassed their Intel counterparts, it was the time to target the Mac which is why you are hyping over the M1 performance.
In fact, macOS was already on ARM years ago. It's just that it would have ran slower and wasn't ready which is why they waited and here we are.
But this claim:
> And this is how you know fucsia/google will not.
How can you be so certain that the owner of the world's most used mobile operating system [0] and a very competitive desktop OS on the market [1] cannot or 'will not' launch Fuchsia with confidence (even when they just did)? Don't you think it's extremely too early to make such vacuous claims without ANY compelling evidence?
[0] https://www.statista.com/statistics/272698/global-market-sha...
[1] https://www.geekwire.com/2021/chromebooks-outsold-macs-world...
Apple quietly ramped it up year over year; at its initial release, it was just another "me too" phone ARM chip, but as they built it, after a few years they had their own chip design team and were no longer just popping in generic ARM Cortex designs. Then it quietly got 2, then 3x faster than the other phones on the market. Finally it reached full parity with common-market intel chips; apple made sure their "intel on arm" emulator was working well.
They still didn't release it! They waited a couple more years - until it was so fast that even emulated, it would be comparable with a brand new low-end intel machine, and then, finally, they branded it as the M1 and released it.
---
Google's strategy seems to be playing out really similarly. Put it out in the wild in some devices where they won't get flak for the usual teething problems. Work all of those out, and then, once it's pretty robust, make the big confident "sexy play" to deploy it on an android phone.
It would be easier to do if you can target one hardware platform that does not change so that you don't have to also shift gears. If you're building the Great Pyramid, you don't want to also move it to a new construction site when it's half-completed.
Launching on hardware that was already released could mean they gave themselves that time. By the time they're finished (now), the hardware is old.
Which will delay the next Pixel at least several years while causing a unprecedented level of fragmentation in the Android ecosystem? BTW, I don't expect this kind of experimental projects can live without reaching any milestones. Replacing Android with Fuchsia is just not a feasible option at this moment.
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....
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.
If drivers all had a well defined interface, the exact same driver, binary or source, can be used across any OS version, and maybe even on other OS's with the right shims.
Then you don't need driver manufacturers to all collaborate to update the OS.
It is no accident that Project Treble drivers follow a similar mikrokernel approach to Fuchsia.
On Android, after Project Treble, classical GNU/Linux drivers are considered legacy mode drivers.
https://source.android.com/devices/architecture/hal
Fuchsia is the next step.
They treat drivers and software as a cost-center, so the software quality is typically horrible. Can't be merged, won't be merged.
Microsoft knew that, so they made sure to be ABI compatible so they could keep updating the OS.
That's just not true. A lot of hardware support was stranded by OS version updates, especially pre-Vista and Win7. It's reached a point where Linux deals a lot better w/ some older hardware than any currently-supported Windows version.
I don't remember it that way. I remember buying motherboards and receiving CDs full of drivers for the many Windows versions. I remember having to scour the internet for drivers and finding a different one for each Windows version. I remember failing to find drivers for new versions of Windows because the manufacturer couldn't care less. I remember incredibly shitty manufacturer applications that took over one minute to display a window on the screen. I even managed to reverse engineer one of those into a free software user space driver.
There haven't been "many" Windows versions in the entire existence of Windows. I bet you don't remember getting different drivers for every service pack or security update.
Unless hardware vendors agree to support a generic driver for each device type which can be maintained by the Linux kernel team it’s going to be a total nightmare and even then you need an easy model to extend the generic driver with a device specific one through an easy interface.
It's not real code, though it is ugly as heck and I have no idea why AMD can't do it a saber way.
What makes you think they want to? They want you to buy the next chip and the next and the next, not keep using the previous one with a new OS.
Do they not care about having a high quality product?
The hard reality that Linux kernel driver model stalwarts must face is that the only measure that matters to these companies is profit margin, and the economics just are not in favor of upstreaming their drivers. So knowing that, do we continue to yell into the night or do we implement a solution that doesn't leave umpty billion devices without kernel security updates?
Absolutely. Google has more than enough power and leverage to solve this problem. Why doesn't it require manufacturers to upstream their drivers instead of enabling their shitty industry practices? Literally just make it a requirement for Google Play services licensing or something. The phone manufacturers will be forced to require it from the chip manufacturers as well.
Google already does a lot of good work getting open source firmware into chromebooks. It should do even more. Use all that intellectual property for good for once.
Yep. They are using their power and leverage to stabilize the kernel driver interface so that this just stops being a problem.
> Literally just make it a requirement for Google Play services licensing or something.
Google already has enough trouble keeping manufacturers on Google Play without giving them even more incentive to develop alternatives like microG.
https://wccftech.com/oppo-vivo-xiaomi-and-huawei-band-togeth...
https://wccftech.com/huawei-executive-says-the-company-wont-...
Android really needs the chip makers more than the chip makers need Android.
No.
They care about maximizing shareholder value. If shipping lots of hardware with barely functional drivers integrators need to beat up into shape makes the most profit, that's what they'll do.
If you spend $20K more on making the software work, then it pays off paying $1 less for a part with a crappy driver than buying one from a vendor who also provides great software for anything you intend to sell more than 20K units.
I spent lots of time looking at released drivers for things like wifi dongles and cheap Linux sticks/tablets, and there are all sorts of horrors. The wifi cards do not fully implement scanning or ad-hoc mode. Existing ioctls are ignored or implemented wrong. Sleep is used for thread synchronization. Android device drivers hardcode specific app names and apply fixups for them, presumably to prevent crashes.
Intel has much better code, at least in wireless drivers, but to be fair their jobs is easier, because most of the logic runs in the embedded processor, and you only get the binary blob for its code.
> The Fuchsia kernel is released under the following MIT-style license: /zircon/kernel/LICENSE.
> All Fuchsia user space components are released under a BSD-style license: /LICENSE or an Apache 2.0 license: https://fuchsia.googlesource.com/infra/+/main/LICENSE.
> All code that is BSD-licensed has an additional IP grant: /PATENTS.
[1] https://fuchsia.dev/fuchsia-src/contribute/governance/policy...
Where there's a demand for a particular class of device, maybe someone will create a shim? Then the kernel folks can have a debate.
Currently though, I think Linux has a big head start.
Binderized HALs => HALs expressed in HAL interface definition language (HIDL) or Android interface definition language (AIDL). These HALs replace both conventional and legacy HALs used in earlier versions of Android. In a Binderized HAL, the Android framework and HALs communicate with each other using binder inter-process communication (IPC) calls. All devices launching with Android 8.0 or later must support binderized HALs only.
Taken from https://source.android.com/devices/architecture/hal-types
To paraphrase a popular saying, "the driver interface apparently has an abstraction problem, so Google created Fuchsia - and now we have two problems."
And if that sounds like it's too hard, imagine how hard it is to maintain your own kernel, and all the associated user space you now have to reinvent.
In fact, you don't even need to hard fork. You could have your own rolling tree with a stable "Android ABI" interface that vendors can write drivers against, optionally.
In any case, no company in their right mind would use this project. Google has proven repeatedly they will enforce a monopoly on their platform one way or another.
Anyway, if they succeed in integrating it into Android then that will be a lot of users :P
Treble driver model is quite similar to Fuchsia, so it already happened, no need to prove anything.
The postmarketOS folks are doing it, starting from downstream OEM Linux kernels, and the patches are being accepted on LKML. It's a lot of work because so much ARM hardware is its own weird mixture of long-supported basic IP blocks and newer stuff with its own quirks, and ARM has nothing like the plug-and-play hardware enumeration of modern x86 systems. So untangling all of this just takes a lot of time and effort. But this has nothing to do with Linux per se; it's all about the ARM system architecture itself and the SoC-based industry that has sprung up around it.
And no, running a microkernel-based system won't help at all, because any hardware that's part of the SoC can read or write arbitrary memory hence your driver can (perhaps unwittingly) subvert the very same security mechanisms you're supposedly relying on. Not to mention that some of these drivers handle, e.g. voltage regulators that will happily fry your hardware irreversibly if poked the wrong way. All of this stuff is inherently part of the trusted base of your system, so you're not going to do any better than what Linux already gives you.
> In 2018, we got the OS running natively on a Pixelbook. After that, the Fuchsia team stopped doing its work in the open and stripped all UI work out of the public repository.
Linux (AFAIK) still doesn't require the typical CLA paperwork or copyright assignment. The "strict licensing terms" of the Linux kernel ensures that kernel stays open. If openness is a goal of Fuschia, the GPL would not be a problem here.
If anything, Linux needs a harder license, like GPLv3 or similar, to maintain openness in a world of locked bootloaders and not-even-half-baked clone appliances with manufacturers who aren't interested in coughing up the kernel source.
"BPF will replace the Linux kernel" - Linux kernel developer
Funny that the B in BPF stands for Berkeley, as in "BSD".
I bet it will be renamed at some point.
How come?
Right now, the phone ecosystem isn't perfect. It's hard to update phones. Why is that? Because manufacturers don't care about long-term support. But at least you could ask them for kernel source, fix their drivers and eventually upstream everything, like postmarketos does.
Now, with a stable driver ABI and permissive license, drivers won't get released. Hardware vendors still have no incentive to support old hardware, so bugs will remain unfixed, and hardware will decay as usual... Oh, sure, maybe you'll get one more update before reaching an edge-case in some driver? I also expect manufacturers to put all kind of ugly things in the kernel if no agreement with google prevents them to do so. Cue "branded" kernels, with drivers incompatible with each other due to some extra or removed APIs. And back to square one, but with only binaries and no source this time around.
> netstack. Migrating netstack to another language would require a significant investment. In the fullness of time, we should migrate netstack to an approved language.
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.
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.
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.
This allows device vendors to use fuschia without releasing device specific software to the community resulting in further degraded software freedom.
Because Android is not GPL.
Google owns the software, so manufacturers really only make money from the device sales, and bundled spyware.
For most people, the only problem using a five year old phone today is the degraded battery. Almost all software is backwards compatible with the old operating systems and nobody simply outside IT cares about kernel updates. Journalists, human rights activists and American refugees like Snowden should fear kernel exploits, your average Joe is pretty unlikely to actually get infected. The massive segregation of Android devices is actually a good thing in this scenario, because you need to prepare your exploits for whole ranges of devices and several versions software versions, making "the Android botnet that ends all Android botnets" incredibly hard to build.
The Android privacy nightmare is all Google being built around spying; the security nightmare is mostly due to brands like Samsung not releasing timely updates, not necessarily because Broadcom and Qualcom don't build patches.
With medium to high end Samsung devices now reaching four years of Android security updates, the entire field is slowly becoming much better. The cheaper, low-end devices lag behind, but it figures that people who cannot afford a $300 phone can't pay for software support and the profit margins become razor thin the cheaper the phone gets. Five years of software updates for a $90 phone just isn't realistic.
This whole situation is why I lament Windows Phone's failure. Microsoft had the right idea, which carriers hated, that the operating system should be independent of the rest of the device. Carriers wanted to force their ugly branding everywhere and fought hard against MS, who themselves bumbled and failed spectacularly by breaking backwards compatibility with every major Windows Phone release, and the entire project was doomed to fail.
Android could have been similar to Linux; a Google-supported core repository with vendor packages for drivers, updatable in the same way Debian is. Nobody outside the hacker community seems interested in this approach, but it could have been.
I would be willing to accept some closed source drivers if it meant Linux actually worked reliably on most modern hardware (no it really doesn't).
First, there are thriving non-copyleft driver projects, like mesa. No copyleft forces Intel to contribute to it. No copyleft forces AMD.
Second, even in Linux, many drivers aren't maintained by their vendors, but third parties. I think that an upstream driver is generally easier to deal with for most parties, so most parties would prefer it. If fuchsia is indeed as modular as it promises to be, users can swap out those drivers, at least in custom ROMs. Android custom ROMs already copy over proprietary drivers from the native OS upon installation.
Third, the GCC compiler has artificially restricted the ability to use it as a backend for third party languages, which led to many projects choosing LLVM instead. These projects now contribute to LLVM's success. Yes, some extensions to LLVM are proprietary. Still many companies contribute to LLVM directly.
Fourth, legal action doesn't turn a company into a good citizen. They might release the source code in the end but they become extremely hostile to free software projects coming forward, because suddenly the legal department got involved. Those employees who share the cause can't freely talk on mailing lists any more because all mails to the project first require approval by a company lawyer. Etc. The released source code might be unusable anyways because it's done to a fork of an outdated version of the kernel.
This is not entirely true. Mainline Linux has a longstanding policy of not including kernel-side graphics support in the officially-released tree unless it can be used with a totally Free userspace. So Mesa is, to some extent, piggybacking on incentives that have been established as part of the GPL'd Linux kernel.
Darwin might be knocking. Evolve or die.
(And its a bit weird that the Linux kernel is so centralized with a cabal lead mostly by one dude who yells at everyone on the planet about their shitty driver code quality. If you're at all Libertarian or libertarian, that should probably bug you a bit that Free Software picked that as the ideal model.)
Looking at the pleothora of BSD/Apache/MIT OSes appearing for embeeded devices it is clear what the future of Linux will become, when the generation that gave birth to it is gone.
Also, the reason so much hardware doesn't have drivers for Linux until after many years, when it has been reverse-engineered.
So, it is both an advantage, and a hindrance.
Do you have control over your device or can Google release updates and do whatever they want with it?
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.
Doesn't that make 5? (Potentially dumb question, I know...)
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.
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.
> 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.
In driver development I often see abstraction violations or very loose abstractions: news hw capabilities can't be accounted for when designing framework abstractions.
I have never done dev on windows, but I guess there is a reason why the form factor of things running windows is pretty limited. I don't see how you can have fixed interfaces in an ever evolving wold.
We all would, but that doesn't seem practical given the market dynamics explained elsewhere in this thread.
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/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.
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.
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.
[1] https://stackoverflow.com/questions/5283032/i-o-completion-p...
Want the new networking APIs? They are exposed only to platform frameworks not POSIX.
Also the multitude of companies contributing together to the Linux kernel are often direct competitors. Yet due to the GPL all their contributions are available to everyone else - so even though you are technically helping your competition, they have to do the same thing for you.
With permissive license, you competition can take the code and run with it, never contributing anything back, kinda like how Sony did in the example above.
I could see the rest of their portfolio migrating to Fuchsia OS eventually, including both Chrome OS and Android.
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.
https://youtu.be/1z1nsuQi40w
I returned mine as I had this happen to me, which completely invalidates its use as a clock.