Step -1: Forbid Linux Kernel Modules for security reasons
Step 1: Require OEM's userspace drivers to use stable ABI (Android 8.0-9.0) exposed over a bus
Step 2: Require OEMs to use your way of doing secure boot chain (Android 10)
Step 3: Require OEM's kernel-space drivers to use stable ABI, and force the usage of Linux Kernel Modules (Android 11 -- we already lost the GPL here)
Step 3b: Start implementing VM support. Find a nifty marketing reason to have VMs ("Privacy Core")
Step 4: Require OEMs to use your own signed kernel (Android 12)
Step 5: Have said micro-kernel load/exec original kernel's executables
Step 5: Say that for security's-sake, it will be better of the nifty VM if its OS is a micro-kernel
Step 6: Require OEMs that your own signed kernel also runs as hypervisor
Step 7: Expose bus defined at step 1 across the VM. Use it to move various components from original kernel to the new micro-kernel, "for security reasons"
Step 8: Have said micro-kernel load/exec original kernel's kernel-space drivers (stable thanks to step 3)
Step 9: OTA kernel defined at step 4 to new micro-kernel
>How would Google switching their platform's kernel from Linux to Fuchsia "extinguish" Linux?
In that nobody would use it on mobile without continued development from Google (Android development can easily pause after say a 5-10 year transition period) and without Google apps and services on it.
At best, you'd have Samsung or some Chinese company keeping the flame alive for a short while.
After that everything now Android will be Fucscia based.
Your argument amounts to: "Before X happened, and after X had stopped happening, X wasn't happening".
Logically it's very strong. It's also neither here, nor there.
The "extinguish" part refers to the transition from Linux on mobile being a thing thanks to Android (on billions of devices) to Linux on mobile not being a thing anymore (or being a small niche) in a post-Android/Fucscia world.
It doesn't matter if Linux on mobile wasn't a thing before Android, the same way when defending a murder "Well, the victim wasn't alive before it was born either, judge" is not an argument.
Can they though? How would they even do that? The whole concept behind Android is to extend the reach of Google's advertising and service offerings into the mobile ecosystem.
This largely depends on them having the goodwill of the phone manufacturers in not de-googling their distributions. How would Google feel about Samsung switching the default search engine to Bing?
Most of the people who complain about stuff like this are those who run custom, degoogled Android ROMs and think they are entitled to Google's work forever.
It's technically true that I run custom degoogled Android ROM.
However, I'm MAKING my own Android ROM. I actually do the job Google implied they would do when they announced Project Treble with Android 8.0 (which is actually providing working new Android versions on older Android vendors).
I'm guessing you don't know my project, so I'm making GSIs, which make Android's Project Treble actually usable to thousands of various devices. If you take Google's Project Treble as-is, you get /at best/ something that is not even a smartphone (you get no in-call audio, assuming you get calls at all, because it doesn't provide VoLTE support). I'm making it actually daily-drivable.
Many users are saying that I'm doing Google's job there, and even some Googlers said so. But of course, it's not in Google's nor the OEM's best interests to do that, which is way this job needs to be done by other people.
Also, I sent dozens of patches to AOSP, with very very small success rate. (While my contributions to Linux were pretty smooth)
My line could have been misinterpreted, and I'm not sure how I'm supposed to interpret yours, so I'll explicit it just in case, because my previous post can be understood both ways:
No, I don't feel entitled to Google's work, the quote was sarcasm.
My point of showing my contributions is that I can do stuff on my own, that I'm happy that Android is opensource, and I do my best to contribute to it, in the opensource spirit. But if it stops being opensource, then so be it (it'd be a bigger shot in the foot for Google than for me anyway), I'm not simply leeching on Google's back, like previous comments assumed.
I'm entitled to Google's work because they made their code open source.
They did it because they wanted to be entitled to someone else's work (the free components they built it on). No one told them they couldn't be proprietary from the ground up.
> I might be naive here but I think they have technical reasons to switch to Fuchsia which is an RTOS...
Nowadays, Linux's realtime is pretty good. Steven Rostedt has extensive documentations on how to "debug" realtime on Linux. You know what's the number one source of non-realtime-ness in Linux? It's parts of hardware that Linux simply can't control. He found that on many PCs, the BIOS triggers SMI (to refresh the RAM IIRC), and said SMI blocks the CPU.
In case you're thinking "Surely this is an x86-only mess", well, sorry, but that's wrong. It's even worse for embedded systems with shared memory bus, where modem has higher priority over the bus, and can decides to stall any memory access made by the CPU.
Switching to Fuchsia won't change much wrt real-time. (Possibly with Fuchsia, it is harder for OEMs to footgun their drivers, which would still be an improvement)
I think the reason Android would switch to Fuchsia is simply that Google is too big to rely on the community, and most engineers there don't have an opensource mind, so overall it makes it more convenient for Google to get rid of 3rd parties. Yes, it is a technical reason.
I agree that extinguishing is not Google's goal (which is why I didn't add embrace/extend). It is just a side-effect.
Fuchsia is definitely not an RTOS, it's an embedded system of sort. I had some experience with little kernel which served the basis for zircon, so I followed the project for a bit - they have no real time guarantees from what I could tell.
Little Kernel? I mean yes, that was designed for embedded, but Google has rewritten a lot of it. What makes you think that it can’t be used for other things now?
You forget the part where all of this was necessary precisely because OEMs couldn't be bothered to update their drivers to work with more recent versions of the kernel.
Three years ago, gregkh did a presentation about LTS in Android. Guess who was using latest LTS kernels. Google? Nope. Sony and Essential are who.
Guess who upstreamed support for their phones in Linux kernel? Google? Still nope, again it's Sony.
How long was Pixel 1 supported? Ah yes, a whopping 3 years. (Same for Pixel 2 I believe). Who does better? Fairphone (circa 100 overall employees, and not many are software engineers), and nVidia.
Guess who provides major kernel upgrades? Sony (but not Google-certified sadly), and nVidia.
So far, Google hasn't shown any sign they are more capable than average OEMs to upgrade my devices.
> You seem to not understand who exactly provides kernels for Android and other embedded devices.
Oh, I perfectly understand how those things work, I've Google-certified more smartphones than I can count (which means more than 50), and that's merely one line of my resume.
In my comment, I mention Sony who upgraded their major kernel version. How does it fit your mental model of embedded system's BSPs?
I currently work in a company who provides software upgrades for a 10 years-old STB. This 10 years-old STB (that's older than the Nexus 4) is currently running Linux 5.4, and is planned to run Linux 5.14 in a few months, at millions of customers' home.
Are we bigger than Google? Gosh no, by orders of magnitude. Are we spending a lot of time on this? Well nope, we don't even need one person full-time to upgrade kernel version. Are we paying that person a lot? Nope, they could probably move to Google 500 meters away and have at the very least double salary.
Of course SoC-vendor stopped providing us with upgrades aeons ago.
But, contrary to Google, we actually have monetary incentives to keep supporting this device.
That's their point. Google, for their own phones, put next to no effort upstreaming the code, but accepted the vendor status quo.
If they can't even wrangle this for their own phones, how is going to a more permissive license and embracing proprietary modules going to make the situation better?
I'm not sure where you got that "point". Microsoft couldn't wrangle this either and they've still ended up with a wildly successful operating system which simply provided a stable ABI.
Why are you so darn sure that they're wrong and the model that's been failing for the last 15+ years is really the right one?
Microsoft's kernel is also famously behind the times because they can't update key parts because of the stable API. Like how the scheduler only knows about banks of 64 cores at a time, and you have to manually load balance your threads from user space in some cases. Or how they couldn't change their VFS to compete with Linux's expectations because they reversed the caching model. The NT filesystem cache sits between user space and the filesystem so internal metadata isn't cached by default but instead needs manual work from each day driver that's always not quite implemented well in practice. On Linux the cache conceptually sits between the FS and the block device so metadata is actually cached 'for free'. Because of these problems it was faster to literally run a whole other kernel for WSL2 rather than the apples to apples of WSL1.
And when we have an example of perfect phone APIs that don't need updates and perfectly written drivers to back those APIs then we can start to entertain that idea.
Stable does not mean perfect. It means putting a version number on it, don't fucking change it pointlessly, and decouple it from the other parts of the kernel.
My Pixel 5 with the latest update installed is running Linux 4.19. Pretty old, but still supported until 2024 according to kernel.org. Still, a more recent kernel release would be preferable of course.
One could require FLOSS drivers instead, so the community would have a possibility to update them later. This is exactly how it works on GNU/Linux phones, Librem 5 and Pinephone.
I'm not sure how switching to a more permissive driver model and licence where now you won't even get the source to these drivers will make the situation better.
There is a lot of negativity here, but for once I'm going to defend Google.
I've been using Linux on all my (non-mobile) devices for a long time, but I'm excited about the potential of Fuchsia as a general purpose (including desktop) operating system.
## Capability Based Kernel
Each process gets its own custom environment and only has access to capabilities that it receives, either ambient ones provided at startup, or passed down from other process via "RPC".
Linux has a hodgepodge of isolation solutions with different levels of abstraction, ranging from namespaces or seccomp over Docker and other container solutions to selinux, AppArmor, Firejail, Snap and Flatpak.
In short: it's kind of a mess.
The low level functionality has been steadily evolving, driven by containers, but very little of the ecosystem was built with sandboxing in mind. Most of the end-user solutions are either a leaky sieve, fringe and barely used, or a pain to use. Often all three of them.
I have a really hard time seeing the Linux (desktop) ecosystem evolve into something that can be reasonably secure. Not because of lack of technical foundations, but because of ecosystem cruft and lack of motivation.
A new open source OS with sandboxing as it's core design element can open the door to actually secure ecosystem.
## Sandboxed Drivers
In Fuchsia drivers are regular processes and only get access to what they need via capabilities.
A big part of the Linux kernel is drivers. Many of them are buggy and have potential vulnerabilities. I'd much rather have my drivers running in an isolated environment. Especially with huge drivers that no one can audit anyway (eg graphics cards - the AMD graphics drivers alone take up a large percentage of the kernel)
YES, this does allow hardware manufacturers to not open source their drivers and keep their shoddy, badly written code private instead of polishing it somewhat and upstreaming it to the Linux kernel, denying any chance of auditing or customizing them short of reverse engineering.
This definitely is a problem and a step in the wrong direction, which is my biggest concern about Fuchsia.
But it is my understanding that this is already the reality on mobile devices - most of them are based on a private kernel tree with a whole bunch of closed source drivers added.
## Library and Application Model
Fuchsia apps actually work a lot like Nix(OS). Apps are retrieved from a package registry and stored in an (immutable) blob store bashed on content hashes. Libraries are also shared between applications based on those hashes, which means different versions of libraries can be present and each application can have it's own set of libs.
As a NixOS user myself, this is exactly what I want.
In addition, system facilities like drivers and even higher level ones like an HTTP client use a standardized interface (via a FIDL schema and RPC) and can be swapped and plugged per application.
This opens a few interesting doors to application design. EG: you don't need to bake in an http client, you can just have bindings to the system interface, and let the OS provide the http client for you. (or let the user chose the implementation that they want).
This also has some interesting benefits for development.
---
In general, Fuchsia with its hybrid Kernel has made some really cool design decisions that would make it a great desktop and mobile OS, even for me as a big Linux supporter.
Do I trust Google to be a good steward of an open source OS and work with the community, rather than running a mostly "source available" project? Probably not. Do I have concerns about the effects on open drivers? Definitely.
But it's still a really cool effort, and a company like Google is one of the few players with the resources to actually make a new OS happen.
> But it is my understanding that this is already the reality on mobile devices - most of them are based on a private kernel tree with a whole bunch of closed source drivers added.
On mobile devices, the proprietary drivers are in user space. The kernel can be recompiled (because providers are forced to provide the source for their modified kernel), with necessary patches, which helps create alternative ROMs. This probably won't be a possibility anymore with a kernel for which you don't need to provide the source code. The drivers will probably be back in the kernel and you won't be able to patch the kernel to make it work on unsupported, newer / alternative user space.
> On mobile devices, the proprietary drivers are in user space.
So, the situation would stay the same regarding that.
> The drivers will probably be back in the kernel
Manufacturers putting drivers back into the kernel would be a step back for them since it would be more work than just using them in user space given there is a stable driver API.
> and you won't be able to patch the kernel to make it work on unsupported, newer / alternative user space
I think people forget that Fuchsia is more than the kernel. It comprises more things than Linux. Being based on a microkernel design, the kernel part represent just a small surface of the whole 'system interface'. All the rest is in the user space. The Android (platform) part of the system will be layered on top of this 'system interface', and will not define all the user space per se alone. This 'system interface' is well defined and documented [0] and, similarly to the Android (platform), they also have a CTS that tries to ensure that [1]. For example, the software layer implementing the product representing the Nest Hub is outside the Fuchsia platform, as will be with the Android (platform). So, a manufacturer implementing a particular feature inside the kernel, or in other component like drivers, will still result in its device having a 'system interface' at least compatible with the oficial Fuchsia one; if it's not, but offers something more, we all would be in the same situation where the provider bundles that features in closed blobs anyway.
I think Fuchsia's decoupled system architecture will make using an alternative user space not a big problem, if not even easier that it is with Android based systems.
The danger I see is that we get the bad mobile environments on other systems like desktop. I am an embedded dev and Fuchsia could be interesting. But it isn't really something I am waiting for. I like OSS much more than I like Google. And the lack of trust is deserved in my opinion.
The advantages seem very theoretical, the lack of tooling will be a problem at first. So there needs to be more compelling reasons to use it.
They are doing this to solve the chicken-and-egg problem of booting the adoption of Fuchsia. Without Android (ie. Linux) support, there's no way to pull off Fuchsia.
Reminds of WSL1, Microsoft originally also tried to have a translation layer between NT syscalls and Linux syscalls, but ended up scrapping all that in favor of a virtual machine in WSL2 due to a multitude of problems in WSL1. I wonder if Fuchsia has solutions to the problems encountered in WSL1 or are they doomed to repeat same mistakes?
WSL1 mostly had problems due to the layering violations and poor design decisions in the windows kernel and low level system libraries. E.g. filesystem functionality like "what constitutes an acceptable filename?" or "is that file locked?" is not only implemented by the NTFS driver and filesystem layer but also partly or fully by a number of higher-level system libraries. A lot of that lives on top of the windows syscall layer.
The Linux syscall layer (which is most of WSL1) lives next to, not above the windows syscall layer. But e.g. for all that filesystem access functionality, WSL1 doesn't just have to talk to the NTFS driver and generic FS layer but also to a lot of Win32 system libraries. If it doesn't, things will break. If it does, you have dependencies across layers, syscall conventions and system services. WSL1 didn't work because windows internals are a mess.
Given that the document has a section on WSL1 as prior art, they're clearly aware of the problem. It seems that they're mostly assigning the problem to NTFS not having the performance characteristics expected by Linux programs written against ext4, which seems like a solveable problem when working on a green field and can design the filesystem accordingly. Microsoft did not have that luxury.
Do you think they're misdiagnosing the actual problem that WSL1 had?
Yes they are. The Linux API surface is huge. Reimplementing all of it in a compatible way is a colossal amount of work, work that is neverending as Linux evolves.
If they can impose restrictions on applications, e.g. say to Android devs "you can only use this set of syscalls" and use e.g. seccomp to enforce that on Linux-Android, maybe they can get those applications to work. But if they want people to just take any Linux application and run it, they'll have to implement all kinds of crazy stuff. Take rr for example, they'd have to implement ptrace and perf_event_open and other arcane features that you really, really don't want to reimplement.
Today they're probably thinking that with some bounded amount of work they can run "90% of Linux apps" or something like that. But Microsoft thought the same thing about WSL1 and it didn't pan out, hence WSL2. It's strange to me to see Google failing to learn from that mistake.
WSL1 -> WSL2 wasn't only about filesystem performance. It looks like the Fuschia people are going to relearn those lessons the hard way. Namely, that it is much less work to make a real Linux kernel work well as a virtual guest than to reimplement compatible Linux kernel semantics in a host-OS-specific compatibility layer, and the former has better performance too. Also a lot of the work for the former is shared with other vendors whereas for the latter you're on your own.
What about Illumos's LX-branded zones? Bryan Cantrill has bragged about how complete that implementation is, about how it could even run something as exotic as the 100-language quine relay [1]. Sure, Joyent (who did most of the recent-ish work on this) ended up exiting the public cloud business, but surely that had more to do with the brutal winner-take-all nature of that space than any failure of the technology.
That Quine thing probably uses almost none of the Linux kernel API. Some of the language runtimes do some interesting things, but even fancy ones like V8 are not that challenging in terms of kernel APIs.
So I don't know anything about Illumos Linux zones, but if they run rr or docker or Firefox or WINE I'll be stunned. (Note that Firefox, rr and docker (by default) use seccomp-bpf syscall filtering which would be an absolute beast to implement in your Linux compatibility layer.)
I think from a technical standpoint, Fuchsia as a modern redesign of an operating system is very interesting.
However, from a technical point of view, the Windows kernel is just as exciting but the restrictions on the source code and its use make it very hard to build excitement in a community like this.
From a practical standpoint, the whole goal of the project is to throw out the open source system because manufacturers can't be arsed to play nice with open source. The philosophy behind it undoes a lot of the technical merit that would otherwise make it exciting.
Had Red Hat, Canonical or another such company been behind the project, I think the community would be all over it. With the way things are going, this is probably going to go down in the open source world like Darwin has: a few hackers building on top of it, but mostly everything is left up to the big corporation managing it. This is entirely different from Android, where enhancements are often built into custom ROMs made possible purely by the GPL nature of the kernel source code, enhancements that more than once made their way into the core Android project.
While I'm excited about a brand new kernel, I'm disheartened by knowing this project is a harbinger of death for large parts of the custom ROM scene. When Fuchsia appears on phones, we'll be thrown back into the days of customising Windows Mobile installs, by moving around special DLLs and copying over magical data files. Open source makes it easier to modify existing code, but manufacturers won't be running the open source version of that code.
>> when did HN become such a bitter, hurtful community
I don't think this happened. However, since HN inception, more and more people (edit to clarify: in the general population) worry about bad uses of technical advances. This is true outside HN and it reflects in the community. Both are good things in my opinion.
> When reasonable people stopped commenting
Quite the contrary. People are considering the whole picture, not merely the technical aspect of things. They are also thinking about the long term consequences and what is at stake. Technical aspects do not live in a vacuum.
I'm quite happy that people are no longer unconditionally in awe about new tech stuff regardless of what is at stake.
I actually understand people who only want to consider technical stuff less and less, as someone who is interested in technical stuff a lot. Please, think critically.
It does not mean you need to be against Fuchsia or anything. Just broaden your sight and take the time to consider whether things are done according to your values, and don't be angry against people who do.
People leaving might look to you as "more and more people worrying", but in reality the numbers don't show that. It's just your observation bias that is telling you what you want to believe.
On Reddit, this kind of situation on a subreddit is called a "circlejerk".
I'm aware that I may have biases and that my social group is not representative but do you have these numbers you are speaking about? Because you seem sure about this so I'd appreciate to be taught against my biases.
Until that, I'll stay with the idea that much more people are at least aware of issues around new tech today than before Snowden revelations, let alone the beginning of the 2000s, and some of them are not happy with this even if they haven't taken actual actions, and even if they are not the majority.
HN is probably only in advance on those topics compared to the general population by the way.
(I added a clarification to the original post because I'm not sure you understood my post like I intended and the sentence was indeed ambiguous)
This is so true. Just look at the number of comments on any technical post on here (e.g. the "how to write a syscall" post earlier today) vs any post having to do google/facebook/amazon.
It's pretty clear that some people are only on this site to hate on "big tech"
"Larry and Sergey won't respect you in the morning." was a slogan here 10 years ago. Quite appropriate for a startup forum.
It isn't new. There was a time when anything anti-Google or anti-Apple was downvoted to oblivion around 5 years ago, but that absolutely wasn't the historical norm (thankfully).
The whole tech landscape was much more optimistic place 10-15 years ago. There was a time when "do no evil" was not a joke in relation to Google. Against Google the bitterness is especially understandable considering how high pedestal they have fallen from.
The invention of dynamite was a great technical success.
The technical achievement here is not so special, but the implied goal (removing user rights by switching from a GPL to an MIT/BSD operating system on billions of devices) is.
> At what point are we going to call out Google for doing the “popular” embrace, extend, extinguish act?
I thought that what Microsoft did to WSL was the first indicator of Embrace and Extend of Linux. I guess Linux was always 'used' as the testing bed for the giants for creating their own closed ecosystems.
Hardly surprising that Fuchsia exists for the same reason; as I previously predicted.
And that's before you consider things like Docker, which will let you run linux software just about anywhere including windows, mac, BSD, etc. On the desktop we have things like Snaps, Flatpack, etc. Also consider Steam running games made for windows on Arch Linux, and Apple running software compiled for Intel on ARM. Windows 11 will run Android applications apparently. And of course WASM is the next level in portable executables.
The OS as a control point for where software can be installed and used is increasingly less relevant. It's increasingly about controlling the application stores and maximizing their reach rather than the OS platforms. Mobile is actually lagging behind these trends a bit; mostly because of draconian app store policies discouraging/forbidding anything that is "not native".
It will be interesting to see if Fuchsia will get a lot of adoption outside of Google. I'm very skeptical about their ability to convince others to use this. Even their strategy around Fuchsia remains murky. E.g. their whole IOT strategy resembles what they are doing with messaging in terms of quickly abandoned things that they announce with a lot of fanfare every year. One of these train wrecks is Nest, which they picked as a niche player guinea pig for the first commercial rollout of Fuchsia. I doubt it will move the needle for Nest. Or for Fuchsia.
I don't really know how does it work in Fuchsia but AFAIK it is supposed to implement capability-based access control giving the apps access only to what and when they really are meant to access (rather than everything the user who launched them is eligible to access). I believe constraining native apps written for traditional OSes this way may not be trivial.
Fuchsia's capabilities mechanism are strictly superior. There has been, over various android version, many fixes to "leaks" of information due to the SELinux configuration not being comprehensive enough, and linux being default open when it comes to capabilities. In contrast, Fuchsia is default closed, so if you don't ask for the permission to do something, you can't.
I distinctly remember ad companies using various tricks like reading /proc and the like to try and get information about what applications are running on a phone and what servers they are communicating with without asking for perms (it's fixed now, but it used to be a thing years ago). This is the kind of stuff that fuchsia should, in theory, prevent.
Yes, this is a huge problem. I wish Google would enforce zero-tolerance policy against apps misusing this mechanism and asking for permissions they don't really need for fulfilling their actual function.
Capability-based security has been available in FreeBSD for a decade now: https://en.m.wikipedia.org/wiki/Capsicum_(Unix) The real problem at the moment is not the OS, it’s the applications written or modified to use it.
> it loses all permissions normally associated with its controlling user, with the exception of "capabilities" it already has in the form of file descriptors.
What if we want to grant an app already running a new capability on the fly? E.g. I imagine a case of user opening a file in a GUI app as an OS-level file selection dialog getting invoked (provided the app already has a capability to invoke it, as by the manifest) and producing a capability for the app to access the file the user choosse in an explicitly specified (RO or R/W) mode.
It cannot be forced to enter, no. It could be executed in capability mode, though, except you would have to give up dynamic linking, for obvious reasons.
As for granting new capabilities - you can pass capabilities from the outside; otherwise the whole mechanism would make no sense :-) In Capsicum case, capabilities are file descriptors, and you pass them the usual way, over Unix sockets.
Fuchsia is going to hurt humanity. If that sounds exaggerated, consider that its license's sole purpose is to allow propietary drivers and other kernel modules. In a world where google wants to have clean hands and governments want to enforce policies on computers, what do you suppose will run on your android phone in the future? That's right, a government-mandated rootkit.
Edit: Of course, I know that this is technically possible already now, but if google creates an OS with the explicit support for such a contraption, there will be an industry where companies like Samsung can buy their "legal modules" for their target markets soon.
Well I disagree and I will just say, that the way I see it, Fuchsia is just pragmatic with drivers.
You cannot really force the vendors to ship open source drivers for your OS. But you can make it easy for them to write them against a stable ABI.
I would love to have a 100% open system. But because of proprietary standards and linux drivers policy, I am forced to use windows on my laptop. I rather would have a open OS and take just the proprietary drivers. Now I have to have the core proprietary and the drivers, with the alternative of messing with linux driver configs and custom kernels again. No thank you. I got work to do.
I would take fuchsia instead, if I could.
Which is open as far as I know, so I really do not see the way from here to government mandated rootkits. At least not through fuchsia.
To be honest, I've been waiting for the Linux ecosystem to do something about the desktop and the phone and it seems that they can't get it as consistent as Apple. Anything Linux, Google always has to step in, hand-hold them and run with their own creation in the end.
Essentially, they 'used' Linux as a test-bed for Android and now replacing it all with Fuchsia which aims to be as consistent as macOS and iOS. Starting with the Nest Hub [0] where the user won't notice anything different, which that is the point.
Due to the mess created by the Linux distro ecosystem, the free form swapping of system components by the user and driver maintenance hell vendors dealing with an unstable kernel API, I won't be surprised to see Fuchsia overtake ChromeOS and Android even by this decade. Not surprised to see Fuchsia attempting to run existing Linux apps too.
This just makes the process even quicker and everyone is watching them out in the open in real time™
No, humanity in general. There has been a decades-long battle between the powers that would love to have everything tightly controlled by the manufacturer (or a consortium of corporations with admissions for a lofty fee) and users who are aware of the advantages of open computing. It's a dividing line between actually owning a computing device and something like leasing it under certain conditions even though you paid for it. As everybody household has more and more computing device, and as these become much more user-hostile, transparency and openness is needed more than ever.
"and as these become much more user-hostile, transparency and openness is needed more than ever."
Yeah, I agree to that.
Which is why I do not agree to a statement, that a new and open OS will hurt humanity, because it does not have the same restrictive licence, you would prefer.
If anything, this melodramatic mindset is really hurting the struggle to really own your hardware
Secondly, to really own your device, we need open hardware anyway. Everything else is a weak compromise.
I see your point but Linux was actually designed in this way to be an open operating system, and using closed pieces of code in it, while possible, is discouraged by developers and is causing problems for their users. What is problematic to some (=companies) is actually a boon for others (=users). Designing an operating system specifically for the sake of using closed code in the system is not good news for openness, no matter how you put it.
But yes, all things considered, it's a bit similar to Apple using BSD as a base of Mac OS X - it had some positive effects on the overall ecosystem.
> You cannot really force the vendors to ship open source drivers for your OS.
But currently, mobile SoC vendors _are_ shipping open source drivers. They must release the source code of kernel-mode drivers in compliance with the GPL.
The problem with SoC drivers is that they're not upstreamed and upstreaming them would require major effort and specialized knowledge. SoC vendors work under intense scheduling pressure and feel the need to cut corners. In other words, this code remains outside the mainline kernel because it doesn't meet the quality bar set by Linux maintainers.
Many mobile hardware vendors don't even see value in maintaining a single kernel tree supporting all their SoCs: their approach is to freeze on an LTS kernel early in the development cycle of a particular generation and then never rebase their changes onto newer kernels. They also work mostly in secret until the new SoC is unveiled.
A stable driver API would appear to solve this problem, but actually causes huge constraints for kernel development while not solving the actual driver quality issue. GKI is an attempt to go down this path, but several kernel hackers disapprove it:
"A stable driver API would appear to solve this problem, but actually causes huge constraints for kernel development while not solving the actual driver quality issue. "
Why do you think that is?
(the criticism of GKI seems to be because of different issues)
As far as I understand, it is quite a deliberate choice of linux to actually force vendors to open source their drivers.
So what happens now is what you describe: the drivers get written against one lts kernel and then shipped and mostly forgotten.
(Which is why I cannot really use my old android tablet anymore, despite the hardware did not degrade)
With a stable driver ABI, I could update to a newer android and keep the drivers as they are.
And with vendors writing drivers for a small and clear API - they could deliver better quality drivers, and update them - because they do not have tp deal with the very expensive whole kernel integration they have to redo for every kernel and every driver.
So yeah, in rainbow fairy unicorn world they all just open source everything and work in harmony and collaboration for the greater good of humanity. But in reality right now, with proprietary being the standard mode, it is just a mess. And I prefer pragmatic solutions that actually improve the status quo.
> You cannot really force the vendors to ship open source drivers for your OS.
I wish Google did exactly that.
> But because of proprietary standards and linux drivers policy, I am forced to use windows on my laptop.
How does it force you to run Windows? I don't understand. You just choose hardware designed for Linux and you don't need to care about the drivers at all.
"You just choose hardware designed for Linux and you don't need to care about the drivers at all. "
Yeah well, if you can afford this (money and time) luxery and find what you need, good for you.
My hardware needs are not met with "linux designed hardware".
I need 2 devices: full powered gaming laptop and lightweight rugged long life battery touchscreen laptop: I found nothing in that realm and I actually did searched a long time.
So I have windows and chromeOS on my mobile hardware, but I gladly take fuchsia if it would be avaible.
But it is very strongly modified and reshaped and is still no open system I can control or own. But it works. With standby times for example, my 100% linux laptops could not even dream about (and that is, with all the quirks and optimisations hacked into them) as they are worlds apart.
(standbydrain is something like from 100% to 0% battery in 2 days on full linux and over 4 weeks with chromeOS.
My windows laptop lasts at least twice the time under windows, compared to linux. With more power.
Okay, but.. there are good open source drivers too. I am actually incredulous - do you _prefer_ to use proprietary drivers, given a choice? Proprietary drivers are often locked to certain kernels, so this means you can't get updates.
>Of course, I know that this is technically possible already now, but if google creates an OS with the explicit support for such a contraption, there will be an industry where companies like Samsung can buy their "legal modules" for their target markets soon.
Do you feel the same way about Linux kernel features like eBPF and tracepoints that provide a stable ABI for monitoring all kinds of userspace and kernel activity?
I'm a little more optimistic. Without external community lifecycle standards to adhere to, the factional nature of Google will make Fuchsia an ever-changing festival of APIs and implementations as their userspace is.
Long term they'll just add friction in their ecosystem.
No, not linux itself though, rather it is the phone manufacturer who do not want open their kernel source code so that random developer can reuse their phone even when outside support terms.
This is typically an issue with the manufacturer of the System on Chip, such as Qualcomm, Mediatek or Broadcom.
They’ve likely done some CBA and determined that porting their existing platforms to new operating systems requires a lot of work, and it’s far easier to sell a new SOC to OEM instead!
TLDR; blame Board manufacturers and not the Linux operating system/community as a whole. Although Google is trying so very hard to decouple the Operating system from the drivers as a whole.
There are already many similarly licensed and capable OSes, some (e.g. FreeBSD) capable of running Linux executables. Are these hurting humanity? I guess you could argue that they've enabled proprietary OSes on, say, game consoles, which could be a negative on humanity.
The second is it strikes me as absurd that the thing standing in the way of government rootkits is copyleft licensing. The power to enforce GPL style licenses lies in government -- a corrupt government can just ignore it.
You can already ship proprietary kernel components with Linux. It happens all the time. It's why you can't use "normal" kernels on most smartphone devices. And it's easy for entities like the government or Google or Samsung or whoever to run their code in, say, TrustZone, or heck, just run Linux as a guest under a microkernel. So many ways to do it, and creating an evil BSD licensed OS with the primary purpose of furthering the surveillance state just feels ... silly to me. Because they just don't need to.
Tldr; I don't believe anyone who isn't already installed rootkits on our phones is holding out until they can do it "officially" with modules for a BSD licensed kernel.
As I wrote, the problem is not the license itself (although we see more and more problematic cases with liberally licensed software). The problem is that google does it explicitly to support propietary modules better. If you don't see how removing legal, organizational, and technical obstacles to controlled devices helps this modern policy, I cannot help you. Besides, this is not about surveillance anymore, that battle has long been lost. This is about enforcement.
> If you don't see how removing legal, organizational, and technical obstacles to controlled devices helps this modern policy, I cannot help you.
As spijdar observes, with FreeBSD the legal and technical obstacles were removed long ago. I find the claims of doom to be so overworked in your post that I am not clear as to what organisational obstacles you are talking about: can you calm down and express this point more clearly?
The argument would apply in the same way FreeBSD if google tried to move android to FreeBSD. The point is not that a kernel with such license exist, but rather that a major platform is moving from a GPL kernel to a non-GPL kernel.
This will surely harm linux phones in the future.
Whether it is the end of the world is something I do not know, but it is not a net positive for software and hardware freedom on mobile devices.
Since it's capability based, the kernel doesn't export a list of current processes. That arguably makes rootkits easier even if they live in user space.
Step 1: Require OEM's userspace drivers to use stable ABI (Android 8.0-9.0) exposed over a bus
Step 2: Require OEMs to use your way of doing secure boot chain (Android 10)
Step 3: Require OEM's kernel-space drivers to use stable ABI, and force the usage of Linux Kernel Modules (Android 11 -- we already lost the GPL here)
Step 3b: Start implementing VM support. Find a nifty marketing reason to have VMs ("Privacy Core")
Step 4: Require OEMs to use your own signed kernel (Android 12)
Step 5: Have said micro-kernel load/exec original kernel's executables
Step 5: Say that for security's-sake, it will be better of the nifty VM if its OS is a micro-kernel
Step 6: Require OEMs that your own signed kernel also runs as hypervisor
Step 7: Expose bus defined at step 1 across the VM. Use it to move various components from original kernel to the new micro-kernel, "for security reasons"
Step 8: Have said micro-kernel load/exec original kernel's kernel-space drivers (stable thanks to step 3)
Step 9: OTA kernel defined at step 4 to new micro-kernel
Step 10: Extinguished.