Google’s long-in-development, from-scratch operating system, Fuchsia, is now running on real Made by Google devices, namely, the first-generation Nest Hub.
Google has told us that as of today, an update is beginning to roll out to owners of the first-generation Nest Hub, first released in 2018. For all intents and purposes, this update will not change any of the functionality of the Nest Hub, but under the hood, the smart display will be running Fuchsia OS instead of the Linux-based “Cast OS” it used before. In fact, your experience with the Nest Hub should be essentially identical. This is possible because Google’s smart display experience is built with Flutter, which is designed to consistently bring apps to multiple platforms, Fuchsia included.
A big moment for the Fuchsia team, and the culmination of years and years of work. Google is clearly testing the waters here, allowing the brand new operating system to get some experience under its belt in a relatively controlled environment. Theoretically, Google could do the same transparent rollout on Android devices, since Fuchsia can run Android applications just fine – users wouldn’t even notice. However, I’m sure that is still a few years away.
The main problem of Fuchsia OS, my opinion, being made by Google. It just screams Google wants to have total control over the whole OS stack. Hence do we need another Windows? Or better to have Linux ticking in all the devices around us? And at least have an impression we still have some control.
But if Fuschia is open source (as it is), what is the concern?
Hard to answer this one in a comment section. If Windows would be open source, right now, wouldn’t you still have some concerns regarding it?
The normal complaint about windows is that it is closed and thus only under the control of one company. Since Fuscia is open that thinking doesn’t apply to it.
So what is your problem with it?
If you will read my question and your answer again, you will get my point. Hint, sure it applies to it. And that is only one aspect of it. There are many others. As said, comment section is not the right place to discus this in depth and in length. Long story short i still prefer Linux.
jockm,
Having open source is one thing, being a trustworthy custodian is another. For example a lot of people were worried about oracle’s takeover of prominent open source projects. It resulted in a billion dollar lawsuit with google after all.
Hypothetically Fuchia could solve some of our longstanding gripes with linux, like stable drivers. I need to take a wait and see approach myself before deciding what I think about it though. I’d prefer for it to be a community project over a corporate one. Corporations seem more likely to put in anti-features, especially as this OS becomes more popular and executives take a bigger interest in changing it to fit their profit motives. A public community project is more likely to oppose that stuff (at least that’s my perception). While things can be forked, realistically the dominant version is going to be what determines the path going forward.
Check Android and the case with Huawei.
Yes, android is open source, and still huawei was mostly cut away from the smart phone market.
And in the case of google…. the introduce new stuff… with the intent of stopping the people to migrate to other products [What a coincidence now that Huawei was officially announcing the launch of HarmonyOS on 2.nd June, google was rushing too to announce somehow funchsia. Why was fuchsia not announced at a big Google Event???].
The specialty of google is to announce all kind of products and features, and then later, after their competition is hurt/destroyed they revert parts of the features and completely remove the product.
A less know case is google maps: people built their solutions on top of google maps api , and hoping of the years they would get even better features (especially since google maps page improved too), but the opposite was the case, the api’s got features removed and worse usage conditions.
And the worst of all is the google support. Even if you are a paying clients, the client support is completely horrible.
My advice: don’t get trapped into google. Check the stories from Mozzila developers how they were fooled by google. Check the trouble “chromium” on linux has because of chrome/google is cutting of api access ….
https://www.omgubuntu.co.uk/2021/01/chromium-sync-google-api-removed
Ask yourself: why gets chromium the api access removed? What’s the problem for google that people are using chromium on linux instead of chrome?
Remember hangouts and the features that were at the beginning, and which came later … and how it ended. Google plus…
HarmonyOS is also open source. So why not to talk about harmonyOS?
cipri,
My own google maps integration work was affected by this too.
Yea, in terms of support I’d agree google takes the cake as the worst for both end users and corporate accounts. Your best bet is to be a VIP with a large soap box to catch google’s attention, or posting in a public forum frequented by google employees in hopes that they’ll escalate your case within the company. Otherwise google support is notoriously MIA. It’s brilliant actually, don’t even bother with support, haha.
Indeed.
Google’s tactic is to violate everyone privacy and use this information to convince advertisers to pay for “targeted adverts”; and then spam billions of people on behalf of the paying advertisers (where most victims of the spam are using ad-blockers, and most advertisers get ripped off paying for “clicks” that actually came from bots).
To make their evil scheme work they rely on online services (e.g. Google Play, Google search, Youtube, …) so that they can screw everyone regardless of which OS they use – their malware is on their servers, not the OS.
In other words; Google have no reason to put anything dodgy in Fuchsia itself. Instead, they have every reason to make it better (more free, more open, more secure, more trustworthy) than iOS (their main competitor for smartphone operating systems); because that helps to attract more consumers to some of their services (Google Play) in the same way that using Linux for Android helped attract more consumers to some of their services.
For “Fuchsia vs. Linux” (which isn’t really relevant for adoption); they’re both open source; and Fuchsia is technically better for multiple reasons (stable driver interfaces, power management, better scheduler, security benefits of micro-kernel, more modern APIs than “1960s design reimplemented in 1990s”, etc). My main concern would be teething troubles (no matter how much testing you do before release, there will be bugs on release day); but even for this Google seem to be taking a good/cautious strategy (not releasing it for the complicated smartphone market until it’s better tested in a smaller/simpler niche).
TLDR: Yes, Google are among the top 5 most evil companies in the world, but that doesn’t mean that I wouldn’t trust Fuchsia.
As for something being technically better, this is a moot point. As it always depends on the point of view and practical applications. But OK, lets see how the whole monolithic vs. microkernel debate will work in practice.
I’d say the most relevant practical application is smartphones.
For smartphones (when Fuchsia gets that far); I’d expect an improvement in support/updates (less “your phone is 2 years old so you don’t get any kernel/OS updates because we couldn’t be bothered updating our drivers” from manufacturers); but that won’t be obvious until several years after manufacturers switch to Fuchsia.
For security, I’d expect teething problems causing “new Fuchsia” to have slightly more CVEs than “old Linux” when Fuchsia is first released, but over time (as the teething problems are fixed) Fuchsia will probably drop to around half the CVEs that you get on Linux/Android (possibly being better than Linux within 6 months, and reaching that “half the CVEs” point at around 5 years after Fuchsia’s adoption on smartphones). I’d also expect that some “monolithic fanboys” will do a premature victory lap (“Hah, micro-kernel wasn’t more secure”) before they find out they were wrong. 😉
Sadly; (assuming Fuchsia isn’t adopted on smartphones until maybe 2025) this means we might need to wait until 2030 before we find out how Fuchsia actually compares to Linux/Android.
Brendan,
I agree with your synopses. I haven’t studied Fuchia yet, but they may well have a better engineering foundation than linux does. Linux developers have remained stubborn in the areas of ABI stability and it’s come at the cost of end users. Also, while unix has brought us a very long way in computer history, POSIX carries a lot of evolutionary package. The linux kernel itself is married to synchronous design patterns that while once the heart of unix multiprocessing, is actually limiting for asynchronous software. Ideas to improve this are nothing new, but they rarely get past the academic phase because they have no way of achieving critical mass.
Unlike most academic operating systems, Google has the ability to quickly shift android sales away from linux to fuchsia if they wanted to, they could even do it under the same andorid brand. I also share Geck’s reservations because there’s a lot of opportunities for google to make this very bad for FOSS, much like the way they create hard dependencies on proprietary bits like google play services on android to inhibit the viability of competing operating systems that are based on android’s open source code. Google could even create a secure-boot/TPM-like framework to prevent owners from moding their fuchsia devices despite the fact that it’s open source. This all remains to be seen, but hypothetically if fuchsia is IOS-ified, it could be regressive for owner rights.
And you’re right that it may take a while before we really know.
Linux and drivers are not the main problem, when it comes to to updating smartphones. Manufactures of the devices are the ones that dictate the update cycle. This won’t change with Fuchsia. If it would ever change with Fuchsia then suddenly it likely won’t be a problem with Linux anymore. In addition i would say Linux has an advantage here, with drivers, but we must make ARM manufacturers to produce open source drivers. As for CVEs. I don’t see why there would be any less CVEs with Fuchsia. If you would compare Fuchsia as a microkernel to Linux as a whole. Then yes, it could be less CVEs would affect Fuchsia. But when you take Fuchsia as a microkernel plus the userland and compare that with Linux having the same components. Here prediction of CVEs become a moot point. And then if you take something like a complete operating system with all the applications, again i don’t see much reason on why microkernel based operation system would have less CVEs. In theory microkernel has some advantages over monolithic design. Regarding the kernel itself. But you don’t just use the mikrokernel, you need the rest too. Manufactures of smartphones will update phones, against CVEs, by providing a ROM, for some years, and then it is over again. If you take something like Linux, open source drivers and open source applications. Then you should be safe for a decade, regarding updates. Still, likely you would need to use a custom ROM. Not the one from the manufacturer, when the support ends.
Geck,
I don’t want to say it’s the “main problem”, but the monolithic nature of linux combined with the lack of an ABI are part of the problem. An ABI would help a lot since the manufacturer drivers would no longer be tethered to a kernel and we would be free to update the kernel without the manufacturer’s involvement.
I don’t understand what you are saying here. But think about windows computers. We have computers manufactured over a decade ago with no manufacturer support that can still get windows 10 updates. This is in large part because users were not put in the position of being dependent on the manufacture for OS updates in the first place. This is what’s fundamentally broken with android. Fuchsia devices could fix this, but whether or not it does is going to depend on how it’s licensed and who is responsible for updates. I hope it does not follow the android model because that’s been a mess on every level.
This is why some of us are in favor of having an ABI to isolate manufacturer’s blobs from updates. Otherwise it’s going to be a repeat of the mess that android is currently in.
@Alfman Yes, that is why i said, on the very top, do we need another Windows? In my opinion we don’t need that. What we need is more open source drivers on ARM front. That is the real solution and that is why i prefer to use Linux. If vendors on x86 front gave in and now we can comfortably use Linux on desktop, then over time i am sure that ARM vendors will start to do the same. There is no guarante you would be better off with Fuchsia based Android, once smartphone manufacturer would stop providing updates for your model. As Linux and situation regarding drivers for Linux is not preventing smartphone manufacturer to offer support, for lets say a decade. And you, as an end user, there is no guarantee you would have access to driver blobs or for the license would allow you to use it. Outside some official ROM.
Geck,
I’m also a proponent for using linux as well. There’s zero doubt that I’ve benefited plenty from open source and I agree that ideally all drivers would be open source. However I think it’s fair to be critical of times when linux does fall short including the lack of ABI. I don’t believe dogmatic FOSS philosophy should trump pragmatism.
Well, it took decades for x86 computers to be as well supported as they are. Linux is dominant in servers and it’s easy to get official vendor support. But on the desktop most vendors still don’t have official support for linux. My gigabyte motherboard’s IO chip is not supported by linux for example, which means I can’t get temps or control fans, clock speeds outside of the bios. It fits in the ‘good enough’ category, but nevertheless it highlights the limitations for FOSS projects providing support without a manufacturer’s cooperation.
I honestly think that it’s wishful thinking to think any ARM vendors are going to change their ways and start producing open source drivers at this point. We’ve had so many years of these same complaints that by now I think these practices for ARM vendors are going to continue. 10 years from now it will be the same deal as now.
There’s no guarantee for anything. But I think it’s in the best interests of users if the OS developers assume that manufacturers are not going to provide updates. I’d hate to see us repeat the ABI mistakes of linux as it’s played out on android. I want new operating systems to be better than linux at mitigating this problem from the get-go.
I’m not just saying this to put down linux, but having a dependency on the manufacturer to provide OS upgrades is one of the worst aspects of android and IMHO would be a terrible mistake to repeat this again with fuchsia. We need to be able to upgrade the OS without the involvement of manufacturers. Linux makes this problematic.
I share your concerns about google controlling Fuchsia, I don’t know how that will turn out. But in terms of the driver problem I think it’s time we acknowledge that linux’s monolithic design is at least partially responsible for android’s upgrade problem.
@Alfman If you want to be pragmatic, fine, but that doesn’t change all that much. Linux is not a problem here. It’s vendors who get to decides when the support ends, not Linux. Hence device drivers, open source or blobs, are not such a big problem in this regard. It’s a vendor that says we will support two or three Android versions. I don’t see on why the situation would be any different when using Fuchsia as a kernel. ARM is trying to become relevant on desktop and in server space. Better open source Linux driver support hence makes more and more sense. Once that happens you, not Google or some smartphone vendor, gets a real chance of using a device for a decade, or longer. And there might be an occasional fix in the driver, every year or so, compared to some blob, you download from somewhere, you are supposed to trust, that didn’t get an update or a fix in a decade. Linux is just so superior in this regard that i don’t get people claiming on how Linux got it backwards and now someone supposedly needs to fix that. Linux got it right.
Geck,
I just don’t see a reason to deny the fact that the lack of an ABI contributes to the problem. And IMHO android and ARM SBC owners suffer because of it.
Windows has the same problem in terms of manufacturers NOT providing source code and ending support after a few years. What makes all the difference is that windows uses forwards compatible ABIs. If windows worked the way linux did, then its long term support would be as bad as android. I don’t say this to attack linux, because that’s not at all the case. I say it because I think that we in the linux community get so wrapped in thinking we’re best that we refuse to acknowledge sometimes there are better more pragmatic solutions that do work. We need to learn to be less stubborn though.
I’m very interested in ARM as well and I agree that ideally everything should be open source. But…sometimes it just isn’t. What we’ve got is an eternal stare down between open source advocates (you and I) and the manufactures. Android has been in this stalemate for decades now and we’re no better off than we were. So I ask you, what is really going to change this time? I really want this to be solved as badly as anyone, but if nobody’s going to budge then that tells me this is never going to get fixed.
Fuchsia has an opportunity to get the ball rolling where the linux community have failed. I don’t say that lightly, I really want the linux community to succeed, but so long as it’s leadership remains stubborn, it’s very likely that we’re going to have the exact same problems when 2031 comes around. If we really want to fix this, something’s going to have to change. Conceivably fuchsia could be the catalyst we need.
But we have to ignore plenty of evidence to the contrary to make that case. I’m thankful linux works as well as it does on x86 desktops thanks to its highly standardized environment and the many years of reverse engineering to get here, but even so there are things that don’t work like my gigabyte motherboard. My scanner doesn’t work under linux (it was a gift to me and of course the giver didn’t think about linux). I have no intention of giving up on linux, but at the same time I wish we’d be more open to pragmatic solutions.
@Alfman Comment section is a bit problematic, when it comes to discussing such problems in depth and in length. I don’t share your views and feel that what you propose is a giant step backwards, not forward. Attempts, such as the one Google is making, that must be prevented, as the solution and outcome doesn’t solve any real problems it only reintroduces existing ones. Just another Windows in this regard. Smartphone manufactures still dictating when a device reaches EOL, by not providing future updates and in general lack of drivers. It might take a couple of years longer, like it did on x86 front, but on the long run i am sure that Linux will get get the problem sorted out properly, for ARM, RISC-V and beyond.
https://www.kernel.org/doc/Documentation/process/stable-api-nonsense.rst
Geck,
I have to ask, are you you happy with android long term support as it is today? If so then your view starts to make sense to me. I can understand your view in the context of someone who doesn’t have a problem with android’s current state of support.
However if you are like are like those of us who feel android support is particularly bad, then your opinion that linux got it right is irrational or at the very least counterproductive to me. It’s a pretty sure bet that if we don’t change anything, we will be destined to repeat this indefinitely. We will be unable to fix anything if we refuse to change our approach; stubbornness gets us more of the same.
Yes, but the fact remains that we’re dependent on manufacturers is because 1) we don’t have the source code and 2) linux lacks an ABI. We’ve been calling on manufacturers to provide source code forever, but that is not happening and we don’t have control over #1. This eternal stare down is NOT working for consumers. But we do have control over #2. We CAN fix this problem, but it requires us to be more pragmatic than we’ve been.
The only way I could agree with you is if I were ok with support remaining as it is for the rest of my days, but personally I think we need to do better.
We’ve been waiting decades though, why do you think next decade or decade after that will be any different? I’m serious, what has changed in terms of market dynamics that would yield a different outcome this time?
I’m very aware of that opinion, but it’s just one point of view and many developers disagree. Maybe serious competition from another operating system is what’s needed to drive real progress for this industry.
@Alfman The only thing that can improve current situation is supported and maintained open source driver included in the Linux tree. Linux people are pragmatic, that is why there are blobs included over there too. The rest, and that includes your proposal, that we already have. We already have binary drivers for Linux/Android and that is the part you are not happy with. Using Fuchsia as a kernel, do you realistically believe that you will buy a smartphone with lets say Android 10 and after a decade the driver blob from the manufacturer site, if you will be able to download it in the first place, will support Android 20? With Linux, done in the right way, yes, you can actually expect that. Now how many times did you search for a device driver for Windows, that was supported up to and including XP but you needed one for Windows 7 or 10? Or Windows on ARM? Good luck with that.
Geck,
ABIs work too though and it isn’t helpful for us in the linux community to ignore our own role in creating this stalemate.
Sounds like you are referring to the proprietary firmware required to initialize hardware itself, but that’s different from the kernel drivers we’re talking about.
Well, I haven’t tried fuchsia yet, so it’s a bit of a wild card to me. For all I know google could screw it all up *shrug*.
But in principal the answer is yes it should work as long as the ABI continues to be supported. And in terms getting the drivers, you already have them on your device. As long as you aren’t too restricted you could back them up, upgrade your kernel, fork the kernel, etc and these drivers should continue to work as well as they did on day one.
Well, microsoft royally screwed us over with obligatory driver signing requirements. There were lots of windows kernel drivers that were 100% compatible with windows vista/7 ABIs (including those I had written myself), but MS broke everything by intentionally refusing to load drivers that did not have a corporate code certificate. This was a disaster for small & open source driver developers. There were 3rd party tools to bypass microsoft’s new restrictions, but microsoft ended up blocking those too. These actions pissed me off so much I decided to stop windows kernel development altogether. Incidentally it is also when I became serious about linux.
Now in terms of our discussion here, I wouldn’t want to go back to windows because I strongly disliked microsoft having control over my work. But that doesn’t mean there isn’t merit to any of the engineering that went into windows. Honestly there are things that the linux community could learn from microsoft and apple even though there are aspects I strongly oppose about both companies. Our goal should be to make linux the best OS regardless of where ideas originate from, period. This requires us to acknowledge when we come up short rather than double down on problematic decisions. Unfortunately I think linux leadership is over-saturated with bureaucracy and infighting. I want linux to get better, but we need to get out of our own way!
Anyways, it seems our views are mutually exclusive. So let us each drink to notion of progress and not worry so much about the details, haha. *clink*
@Alfman Yes, we can agree we disagree on this topic. Whenever i read a license of drivers included in Raspberry Pi OS, search for Windows blobs, basically deal with whatever blob i need to deal with …. We don’t have to get to technical to understand that kernel with or without some stable interface for drivers and whenever blobs are involved usage of blobs will be limited. And there is just no way you would be able to update blobs on some Android device through a whole decade. If you believe that most manufacturers have this interest then you are naive. All in all Linux and open source drivers are just light years ahead of that and resolve all the issues mentioned above. I am sure that someday some Android devices will have good open source drivers in Linux tree and some will still offer blobs. I agree that we are not there yet, hence best to wait until that happens and after we can compare the option i or you prefer to choose and use.
Geck,
On the contrary I am completely aware that manufactures are not going to provide support for very long. That’s where an ABI can help, so we can update the kernel without manufacturers getting involved. This is a proven model that works.
Except that we’ve been waiting for so long. This was an old debate in 2011, it’s a tired debate now in 2021, if we do not change our approach we’re going to have this same long winded debate in 2031, 2041, etc. I wish things were different, I really do,, but it’s crystal clear that we’re not going to fix this by following the same old dogma.
The biggest difference between you and I is that I want us to take pragmatic steps to fix this now whereas you’re fine with not making any progress ever, even if it means remaining dependent on manufacturers for kernels indefinitely. Manufacturers are fine with this arrangement and evidently so are you. You may say you are against it, but the actions that you take are reinforcing this eternal stalemate and those actions speak louder than words.
While I have my reservations about fuchsia, at least this is an area where they can make real progress and hopefully the new competition would give linux a much needed kick in the butt to address its deficiencies.
@Alfman Regarding some device drivers, blobs are the main problem, that is what we have now, and the solution is hence not more blobs.
@Alfman Thanks, but no thanks. Some of us will continue to actively fight such future as we don’t want to live in it. People, like you, that are OK with the state of blobs, personally i don’t even care if Google makes another Windows for you or not. But there is no way i am supporting it. Being pragmatic is one thing, being advocate of dark ages is another. If Google will try to push another Windows on us, then we will just fight is as we did Microsoft in the past. To move another step forward in the right direction, just like Microsoft had to do in the past.
Geck,
I agree blobs are not desirable. However your description is not a fair representation of what’s happening with mobile devices.
Linux without ABI = consumers are completely dependent on manufacturer kernels, no independent upgrades, manufacturers determine device’s end of life and hardware must be replaced to get new kernel.
Linux with ABI = consumers are dependent on manufacturer drivers, but they are free to upgrade and fork the kernel & OS without manufacturer involvement.
Adding an ABI isn’t asking them to give up anything that they would have without it. Instead of being dependent on manufactures for the entire kernel. they would only be dependent on the manufacturers for the drivers. We can both agree this isn’t ideal, but at least it’s real progress for users.
Does ABI solve the proprietary driver problem? No, but it’s not like our current path provides the solution anyways. Being able to upgrade the kernel independently from the drivers would bring huge benefits to android. How long are you willing to keep android users in the dark ages under the control of manufacturers? You said you wanted to wait it out, ok…but to what end? I’d like a serious answer, how many more years/decades do you find acceptable to remain in this standoff? Every year this stalemate continues is another year that consumers remain dependent on manufacturers for kernel updates. How many decades of acceptable losses we should continue to tolerate in the hopes that manufacturers will eventually open source?
If you give a specific number, will you concede at that point in time that we should finally be taking a look at pragmatic solutions?
If you refuse to give a specific number and you’re resolve to wait indefinitely, well that’s a loosing proposition for users. Our refusal to consider pragmatic solutions in the linux community hurts users and I find it unfortunate that we’re willing to put sheer stubbornness over user interests like this.
There may have been a time, long ago, when I would have sided more with you, but I’m not going to blindly support a plan that in all likelihood keeps us stuck here. The way I see it, we must evolve if we want anything to actually improve. If fuchsia ends up overtaking linux in mobile, it will have been our fault for refusing to let linux evolve to better serve users.
@Alfman As for the possibility of updating a kernel. In that regard Linux with open source drivers is still a superior option in all regards. Additional benefit for example being, after the device EOL, the driver will still likely get a security update if discovered. Terms of use being fundamentally different. If lets say an average consumer would have a possibility to download an Android driver, due to some ABI. Don’t you believe the very first thing consumer would have to do is to select a device or a chip name and after to select an Android version … There is just no way it would work for current Android and Android 10 years back or forward. And if by any chance it would, nobody would touch that driver in half or a whole decade. Kernel would evolve and it would need to take into consideration a buggy and insecure driver that it still needs to support and can’t be fixed. What i am trying to say is you would still get around 3 to 5 years of “proper” support and after that good luck. As for saying we need to stop blocking progress. We are not doing that as there is no technical limitation involved with Linux and blobs that would prevent somebody to support devices for 10 years. Instead of currently in average from 3 to 5 years. I won’t discuss this further as comment section is not a place to conduct such in depth and lengthy discussions and if we would continue we would likely spend the next decade in doing so. Past decade or two in my opinion proved, what is the next step and what would be considered a step forward or backwards. More blobs for sure can’t be considered a step forward. Maybe you gain a bit of convenience, on the short term, but on the long run you shoot yourself in the foot and not only that as it gets worse.
But lets say Google goes ahead with this and this becomes a new reality. Maybe some will start writing open source drivers for Fuchsia and maybe that could in some way still be usable for Linux. I know this sounds a bit naive but i guess lets at least try to keep a bit of positive attitude. Or if Google starts abusing the position and ARM or Nvidia stay stubborn, maybe some other architecture to lead the way to more open source device driver future. In this day and age such things can change in a decade.
Geck,
1) If a manufacturer is willing to provide long term updates, great! An ABI doesn’t stop them from doing it… nothing is lost.
2) If a manufacturer is not willing to provide long term updates (which has been an ongoing problem with android), then having an ABI would allow kernel updates despite the manufacturer’s unwillingness to help. In this case an ABI would be superior.
3) To the extent that our community is able to reverse engineer the hardware to create our own source code, having an ABI doesn’t block such efforts. Nothing is lost.
So once again, I agree that ideally we would have full source code for everything, but in the meantime an ABI would help to solve some of android’s systemic long term support issues without creating any new barriers to your goal. I’m not saying your goal of full open source doesn’t have merit, but I am saying that making any progress is better for most users than making none.
We already have examples of successful kernel ABIs and I have confidence in the FOSS community’s talent to solve any technical challenges that would come up. Unfortunately our biggest obstacle right now may be the mental roadblocks that would deter us from even trying.
Fair enough, I don’t mind a bit of optimism… but again to what end? I don’t want to end up living in a reality distortion field either where we just tell ourselves everything is going great while ignoring the problems and the solutions. We’re not doing our community any favors this way. I think we ought choose the paths that lead to progress over long term complacency.
@Alfman Linux and open source drivers are still superior to each and every point you made.
Geck,
That’s a cop out because if we had the source code we wouldn’t even be having this debate.
You’re argument is based on a hypothetical presumption that we have source code. Hypothetically if we had all the source code for everything then fine. However your presumption has been false for over a decade now, and without the source code your argument that having control of all the source code is better falls flat.
Should we have the source code? Sure, nobody’s against that! But it’s counterproductive to ignore the fact that we don’t. Adding a linux ABI would enable owners to retake control over the kernel and not be dependent on manufacturers for OS updates & forks. Would this give owners control over the driver blobs? No, but that’s not something they have today under the status quo anyways, so nothing’s lost.
Also, just to be clear, your goal of having source code isn’t mutually exclusive with having an ABI. The pragmatic solution is to offer users the benefits of the ABI today while still working on getting the source code.
We already have blobs now and we have little or no control regarding drivers. More blobs is not a solution. Visiting https://arm.nvidia.com/ there is an image of a device running Ubuntu on the front page. Linux is open source, ARM is open regarding licensing the architecture to 3rd party. Moving back, to some open core and one company controlled reality is a no go. Be it ARM or some other architecture, providing open source drivers, that is the next step forward. In the last decade we didn’t fail, as you say, Linux didn’t fail, ARM did in this regard. That is why we still use blobs, just fine, until something better comes along.
Anyway, that is it from my side. Regardless if Google takes a step back, there is enough of us that will make sure Google or somebody else takes two forward, when the time comes. And then we can discus this further.
@Alfman Let’s make a deal. Google or somebody else can create a kernel with some ABI, to satisfy people that want it and that are OK with blobs when it comes to drivers. Linux to achieve an official open source driver. Both options to run on some nice hardware. And lets after compare and discuss on what somebody, that actually has an opinion on this, will prefer to choose as a daily driver.
Geck,
Great, so you should be in full agreement with me then! An ABI improves the situation from owners having little or no control over the entire kernel to having little or no control over just the drivers. This is an objective improvement. Logically speaking, we should both be in agreement here.
Ok, but many of us have been waiting patiently for over a decade already and waiting hasn’t changed anything. Instead it’s solidified into the status quo. We owe it to users to offer solutions. ABIs can help reduce the dependency on manufacturers from the entire kernel to just the drivers. Is it as good as full driver source? No, but it’s real progress. And we could still pursue full source code without forcing our users to stay stuck while we keep “waiting” indefinitely.
No, i am not agreeing with you. For me driver blobs on smartphones, IoT devices, TVs, cars … are a no go. The only reason i tolerate them is as i have no other alternative. I don’t care or want for somebody to improve the blob situation, for me, by offering more blobs. It’s still crap. I want to have a choice to buy all the things i mentioned above and for them to have Linux and open source drivers installed. If no other way will work then i support enforcing this by law. Some country saying OK enough is enough, devices must have open source drivers or can’t be sold in this country. But lets give them a chance to first figure it out by themselves. Realistically the market should take care of it as the solution that is more open usually replaces the one before. If the one before isn’t able to adapt.
Geck,
I know you say that, but it’s an illogical position. You’re complaining about binary drivers. That’s fine, keep complaining about binary drivers! We’re in full agreement about that. However in the meantime you would have all of us suffer under what is effectively the entire kernel including the drivers being provided as a big binary blob. This situation is objectively worse than the one that you are complaining about. Logically you *should* agree with me.
@Alfman For my taste this was already too long discussion for comments sections. If we would go ahead and start discussing technical and practical levels of microkernel and monolithic kernel that would just be too much. In the end it depends on point of view and execution. In regards to Linux and (open source) drivers i have no issues if i have to update the monolith and i like the concept of loadable kernel modules. When it comes to Linux i actually prefer it. And that there is some central authority that manages it as a whole. Instead of splitting it apart and have groups of projects working on different areas that makes a (logical) whole. Like for example with Wayland. In a way it is nice to have more control but on the other hand all the fragmentation and different implementation details, that’s a mess. Each approach has pros and cons. And then there is the actual execution part, where Linux for example could stand no real chance if it would be managed differently. As usually people make the difference too. It’s not just about some technical stuff and pros and cons lists.
Geck,
Once I again I don’t take issue with your goal, but I do take issue with your let’s-just-wait-it-out-more-in-the-hopes-that-it-eventually-gets-better solution. That’s NOT a pragmatic solution and that’s not leadership, that’s complacency and passing the buck. An ABI gives us a real solution to isolate the manufacturer’s involvement from the rest of the kernel and it legitimately gets us closer to both our goals of users being able to update the kernel. Users are worse off because we’ve done nothing to fix this in the past decade. And more than likely we’ll once again be worse off in the next decade if we keep doubling down on our do-nothing approach. As they say, those who forget history are condemned to repeat it. Users being stuck with older linux kernels provided by manufacturers could end up being a permanent situation for the ARM & mobile industry. The inability to update linux kernels on our devices is a failure today and will continue to be a failure in the future if we insist on stubbornness over pragmatic solutions.
@Alfman Google owned open core alike kernel (operating system) that puts emphasize on (driver) blobs. That in my book is not about being pragmatic.
Geck,
My concern right now is about linux. I have a linux distro and I’d really like to support ARM harmware, but my god this manufacturer dependency is a mess! As it stands today I find it unacceptable that the entire linux kernel is effectively a binary blob from the manufacturer. I’d love nothing more than for mainline linux to just work everywhere without being forced to use a vendor’s kernel. I honestly don’t care how we get there. I’d be ecstatic if your solution had worked, but it isn’t working and this is after waiting so many years. We need to stop deflecting blame and take responsibility for our part in this stalemate. I’d much rather see linux evolve to address our needs than be forced to retool with a new OS. It’s a shame that linux is not being allowed to evolve, it leaves linux not up to the task of being a kernel that owners can independently modify and support on today’s hardware.
If I had a say I would make this a priority. We need to do our part to maximize owners control over the software stack because it’s evident that doing nothing and waiting for manufacturers to take action is not working. They aren’t looking out for owner interests, but we should be.
I know fuchsia can run the android VM, but can it also run linux binaries? Lots of programs (mostly games) depend upon native libraries.
They are working on a compatibility layer called starnix.
Yes, exactly how they were working on a google drive client for linux?
Google is promising and maybe doing at the beginning some good stuff to bring the people over and to steal momentum from the competition… then slowly their products become worse and worse till you don’t want to use them anymore…. and then they shut them down because they are not used by a big amount of people.
My advice: don’t waste your time with google products, because your time and knowledge earned will be wasted short or mid term. And don’t build on top of google API’s, especially cloud apis.
First, I’d like to point out that software being open-source doesn’t mean the code is automagically & accurately audited/verified by qualified 3rd parties to contain no questionable or nefarious code. If someone wants to trust Google, of all companies, whose business model is to mine & sell the data of its users, simply because they publish millions of lines of OS code, be my guest. Count me out until there’s hard evidence to justify that trust.
Second, I keep reading people say `if it’s open-source you can just fork it`. Really? That’s what people are already proposing? Quick question… Thinking of the endless flow of complaints about fragmentation, how well has that approach worked out for Linux? Fragmented development, support, and userbase.. Don’t like it? Fork it again. Why have just one Fuchsia OS when you can have 5, 10, or 20?
I hope Fuchsia turns out to be a win for users but I don’t believe there’s no catch, and I don’t trust Google any more than I could throw their corporate headquarters. Fuchsia OS open-source? Great, super. Now prove why that actually means anything.