Google's Fuchsia OS Developer Site Debuts (Forbes)
Zircon was previously known as Magenta and it was designed to scale to any application from embedded RTOS (Real-Time Operating Systems) to mobile and desktop devices of all kinds. As a result, there has been much speculation that Fuchsia will be the natural successor to Android and Chrome OS, combining capabilities of both with backwards compatibility to run legacy applications built on either. In short, this thing is designed to run on anything from 32-bit or 64-bit ARM cores to 64-bit X86 processors and it has a potential to be rather disruptive."
Posted Jul 1, 2019 16:10 UTC (Mon)
by acarno (subscriber, #123476)
[Link] (85 responses)
Does anyone know what problem this OS/(micro)kernel is meant to solve?
Posted Jul 1, 2019 16:20 UTC (Mon)
by kilobyte (subscriber, #108024)
[Link] (38 responses)
So the problem Fuchsia is meant to solve is not technical but business.
Posted Jul 1, 2019 16:25 UTC (Mon)
by pakumar (guest, #96315)
[Link] (2 responses)
Posted Jul 1, 2019 17:14 UTC (Mon)
by xav (guest, #18536)
[Link]
Posted Jul 1, 2019 19:07 UTC (Mon)
by jdulaney (subscriber, #83672)
[Link]
Posted Jul 2, 2019 9:19 UTC (Tue)
by HelloWorld (guest, #56129)
[Link] (34 responses)
Posted Jul 2, 2019 16:41 UTC (Tue)
by thomasg (guest, #114185)
[Link] (33 responses)
The elimination of Linux from Google is clearly a goal, and Google can and will use a lot of resources to achieve it.
Posted Jul 2, 2019 23:15 UTC (Tue)
by HelloWorld (guest, #56129)
[Link] (32 responses)
Besides, the whole “users can fight back” thing is BS anyway. Yes, GPLv2 guarantees access to the source code, but it doesn't do anything to prevent vendors from shipping locked bootloaders and that's the real issue. And for many, many devices the drivers were never merged into the mainline kernel anyway, so even when you do get a vendor's kernel sources they're probably outdated and require proprietary userspace blobs for graphics etc. So yeah, source code sounds awesome in theory. In practice it's often useless.
Posted Jul 3, 2019 9:54 UTC (Wed)
by nilsmeyer (guest, #122604)
[Link] (29 responses)
Posted Jul 3, 2019 12:02 UTC (Wed)
by HelloWorld (guest, #56129)
[Link] (28 responses)
Posted Jul 4, 2019 14:07 UTC (Thu)
by smurf (subscriber, #17840)
[Link] (27 responses)
You can unlock your phone all you want if you don't have the code you need to run its hardware. Specs are not available either.
Some reasonably-worded "Right to Repair" legislation would help. Fat chance, unfortunately, for our politicians to do something that's actually reasonable for a change. G20 demonstrated that quite clearly. Again. But I digress.
Posted Jul 4, 2019 23:24 UTC (Thu)
by marcH (subscriber, #57642)
[Link] (26 responses)
In democracies (there are still a few left...), politicians do and say whatever it takes to be elected. How many non-technical people around you understand the "Right to Repair" proposition? How many have even heard of it? Have you ever tried to explain the GPL to one of them? I haven't.
You probably heard there's been a record heatwave across most of Europe recently. Guess what: more politicians are concerned with climate change now!
It's very easy to blame politicians and sorry I'm getting a bit tired of it: almost every time they suck it's just because people suck. We're 100% emotional and close to 0% rational/logical and politicians just go with the main flow, otherwise they're gone the next term. Sure, there are back alley deals now and then and some gerrymandering here and there, however most of what anyone considers "bad" happens in broad daylight, the real question it's whether anyone cares or is too busy watching the latest irrelevant news/shows on TV instead. Some even think democracy is a futile ideal.
If you really care about something then some form of canvassing is required. I guess social networks is one of the options. Even then it's a lot of non gratifying effort.
To finish on a more positive note: if like me you find it much easier to rant in LWN comments than trying to have civil debates with people you don't like the ideas of, there's still a simple and effective way to support what you care about: pay others and especially the press to do it. If you don't help journalists make a living then Big Finance/Oil/Agro/Pharma/Internet/etc. is very happy to take care of that, they've become pretty good at it.
Posted Jul 5, 2019 6:27 UTC (Fri)
by smurf (subscriber, #17840)
[Link] (25 responses)
Sure. Ask them why their phones are no longer usable when they're running Android X while their apps now require Android X+3 (and are not non-upgradeable because their back-end cloud service would stop working).
The problem isn't restricted to the GPL anyway. Why should I be required to toss their whole phone just because the screen broke or the battery died, instead of simply replacing the offending part?
> Guess what: more politicians are concerned with climate change now!
(a) Ha. I wish. :-( :-( :-(
(b) False dichotomy, esp. because you can save a whole lot of CO2 by not producing the heaps of easily-broken things we buy anew every time they're past their warranty. Same for phones and their firmware, as mentioned.
> To finish on a more positive note
I already spend a non-trivial chip of my income on quality journalism. Have for years. Doesn't prevent the occasional rant. ;-)
Posted Jul 5, 2019 9:20 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (24 responses)
Posted Jul 5, 2019 10:13 UTC (Fri)
by smurf (subscriber, #17840)
[Link] (23 responses)
Google hopes to achieve the same thing with a stable ABI for drivers and whatnot. I wish them luck, they'll going to need it.
Posted Jul 5, 2019 13:58 UTC (Fri)
by pizza (subscriber, #46)
[Link] (4 responses)
I don't see how this is going to happen, from a technical perspective. Sure, the "ABI" is just "pass message X to component Y" but you also need API stability on top of the ABI. This means the message and component IDs, the structure/content of the messages, and the underlying behavior on both ends. If it was just ABI differences, then porting to a newer "Android Linux" kernel would be trivial.
Instead, Google, the SoC vendors, and the phone makers all routinely hack-n-slash willy-nilly all the way up and down the stack, resulting not only in ABI changes, but API changes at every level. I don't see how this new Fuchsia thingey will make an iota of difference, because the "problem" is completely non-technical in nature (ie piss-poor engineering management practices), and cannot be solved via technical means, and will just get re-created (on an even larger scale) when the barely-enforced requirement to release sources is removed.
Posted Jul 5, 2019 15:32 UTC (Fri)
by smurf (subscriber, #17840)
[Link] (1 responses)
The security disasters of yesteryear's unmaintained phones should have told them that this is necessary. Whether they actually do any of that is still up in the air.
Posted Jul 17, 2019 22:22 UTC (Wed)
by nix (subscriber, #2304)
[Link]
Posted Jul 5, 2019 15:59 UTC (Fri)
by excors (subscriber, #95769)
[Link] (1 responses)
Or e.g. when phones got high-res cameras and high-res displays and wanted to copy images from one to the other, without users complaining about it draining their battery in ten minutes, they had to add something like ION. That's a pretty simple driver and still took about two years to get upstreamed - and only into staging, where it has remained for another six years. It would be irresponsible to make users suffer poor power efficiency until the upstream Linux developers (who mostly seemed uninterested in mobile use cases) eventually accepted the problem and designed a nice solution. The problem had to be solved on a timescale that matched the product development cycle - i.e. months, not years - and the Linux development process seems far too slow for that.
Fuchsia should have an easier time because smartphones (and other products using mobile SoCs) are a much more stable and well-understood technology now, with little scope for innovation, so it's not chasing a moving target like Android Linux was. It'll only get interesting when Fuchsia has become mature and stable, then a totally new use case comes along and Fuchsia has to rethink a lot of its core assumptions. That'll reveal whether their stable driver ABI makes things better or worse.
Posted Jul 5, 2019 17:37 UTC (Fri)
by marcH (subscriber, #57642)
[Link]
Many engineers prefer to do the Right Thing - until management reminds them the deadline.
> rapid advancement of smartphone hardware and of user expectations.
It may change a bit now that sales are slowing down but these "user expectations" are also why smartphones do not make a good case for the Right to Repair. Vehicles and appliances are much better angles.
- Don't you think you should have a Right to Repair your old smartphone?
Posted Jul 5, 2019 19:42 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (17 responses)
In case of stable ABI, however, the OS updates can be decoupled from drivers, allowing smooth upgrades as long as the ABI is not broken.
Posted Jul 5, 2019 20:01 UTC (Fri)
by marcH (subscriber, #57642)
[Link] (12 responses)
Indeed: I have a couple old and relatively cheap PCs that I'm pretty sure no one cares about. Yet somehow they run Windows 10 successfully. No GPL or even open-source involved.
Posted Jul 5, 2019 20:08 UTC (Fri)
by pizza (subscriber, #46)
[Link] (11 responses)
(Go figure, manufacturers supporting their stuff..)
Posted Jul 5, 2019 21:30 UTC (Fri)
by marcH (subscriber, #57642)
[Link] (10 responses)
How do you know that? I just had a look at driver dates in the Device Manager on this 2012 system and they range between 2006 and 2015. The only driver I ever manually updated was for the GPU, its updates stopped coming in 2015.
> (Go figure, manufacturers supporting their stuff..)
For a limited and often short time. They have very little incentive to.
Software is really unique for two reasons: 1. zero marginal cost / all fixed costs, 2. no one wants to pay for it. Free Software wins because it's just the most efficient and economical choice. Stable ABIs, forks, GPLv8 and other rights to repair make easier conversation topics but they matter much less.
Posted Jul 5, 2019 23:04 UTC (Fri)
by pizza (subscriber, #46)
[Link] (9 responses)
Because with every Windows release since the beginning of time, Microsoft has changed at least one major driver API. Granted, the rate of change has slowed considerably since Windows 8, but even Win10 has incompatible changes versus 8.1.
Posted Jul 5, 2019 23:10 UTC (Fri)
by marcH (subscriber, #57642)
[Link] (4 responses)
Examples?
Actually changed existing ABIs or merely *added* new ones? Big difference: the difference between years-old driver versions are still compatible (if not optimal) with the latest Windows 10 versus not.
Posted Jul 6, 2019 0:36 UTC (Sat)
by pizza (subscriber, #46)
[Link] (3 responses)
NT4->2K required new sound drivers, and XP->Vista too. 2K->XP and everything from Vista onwards is stable.
Printer drivers changed a few times, though I think since Vista (Possibly 7) it's been stable at an ABI level. That said, I think with Win8+ a tweaked driver is necessary if you want to print from Metro apps with full functionality.
Posted Jul 6, 2019 0:57 UTC (Sat)
by marcH (subscriber, #57642)
[Link]
Even if representative that still gives a few years of stability.
Posted Jul 6, 2019 21:48 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (1 responses)
What you seem to be missing is that pretty much all graphics hardware supports the basic graphics drivers. So when Windows is updated, and there's no updated specific driver, Windows downgrades to the basic generic driver which still works.
Contrast that with WinPrinters, where upgrading Windows breaks the WinPrinter driver, and your printer is now scrap. Same thing with scanners. Okay, most printers today support postscript or pdf, and most old printers supported pcl5, which means that you can upgrade Windows and fix things so your printer doesn't break, but most GDI-only printers are toast with a Windows upgrade, and many non-GDI printers are toast if the user doesn't know how to force a generic driver.
(Re-reading this, I don't know if I've replied to the wrong person, but the fact remains that graphics is a poor example of arguing about API/ABI stability. It is almost unique in the fact that there is a fall-back that means when the specific driver fails, a generic driver is there to take over.)
Cheers,
Posted Jul 7, 2019 12:05 UTC (Sun)
by pizza (subscriber, #46)
[Link]
Let's be honest, unaccelerated 2D framebuffers aren't what users care about when they clamor for "working drivers". (And FWIW, Linux has been in the same boat for a _very_ long time between vesafb and uefifb on PCs, and platform-specific fbdev drivers for embedded systems..)
> but most GDI-only printers are toast with a Windows upgrade, and many non-GDI printers are toast if the user doesn't know how to force a generic driver.
WinVista (2006!) introduced a new printer driver model, and things have been remarkably stable since then. Note that I'm talking about the interfacing to the hardware and the OS print subsystem here; if it was properly signed, a basic printer driver written for Vista should JustWork(tm) all the way up to Win10. Printer manufacturers' bloatware is another matter though. That stuff was brittle as hell..
(OSX, on the other hand, despite using CUPS under the hood, more often that not broke printer drivers with every release due to other changes at the OS level. Perhaps it was their way of "subtly" encouraging folks to move to IPP-based networked printers?)
Posted Jul 6, 2019 0:36 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
However, most of the driver API surface remains exceptionally stable. If you have a USB device or a simple PCI device then it's mostly likely that it'll work just fine across multiple versions of Windows.
As an example, I recently helped with a PCI driver for a H264 multi-stream video compression PCI card that I installed back in 2006. The driver was written for Windows Server 2003 but it worked just fine on recent Windows Server 2018 after I dealt with driver signature validation issues. The userspace app also is working fine. The Chinese company that produced them is long out of business.
On the other hand, their phone system is built (also by me) on Asterisk and uses DAHDI to drive a phone line adapters. It stopped working a couple of years ago with newer kernels for unknown reasons. DAHDI is fully open sourced and has been around for 20 years and yet it's still not in the kernel.
Posted Jul 7, 2019 12:26 UTC (Sun)
by pizza (subscriber, #46)
[Link] (2 responses)
As long as it's Vista or newer, then yes -- Microsoft introduced a new driver model that forced most USB and PCI drivers into userspace. There was much gnashing of teeth and quite a lot of hardware never saw drivers written for the new model (launching the era of "Linux has better hardware support than Windows") but as you mentioned, simple drivers that didn't otherwise interface to OS innards JustWork(tm) all the way to current Windows systems.
Linux's libusb (for USB devices) and UIO (for everything else) have been around at least as long as Vista. I don't know how popular UIO turned out to be, but libusb is widely used. Both have stable APIs (and ABIs) Somewhere around here I have a proprietary driver based on libusb-0.1 (which dates back 19 years) that still works as well as the day it was written (which is to say not terribly well, which is why I reverse-engineered a replacement that has the added advantage of working on non-IA32systems...)
> their phone system is built (also by me) on Asterisk and uses DAHDI to drive a phone line adapters.
In a former life I inherited a DAHDI Asterisk system on failing hardware. It was an utter mess from top to bottom. I gave up on trying to rebuild the system on new hardware and up-to-date Asterisk, and as far as I know the original system image is still running inside a VM with a passed-through line card. More recently I tried to set up an Asterisk system using DAHDI and ran into the same kernel problems you mentioned, eventually abandoning the whole thing in disgust. (It was just as well though, as a few months later a near-direct lightning strike took out everything I had plugged into the phone lines and most of the network infrastructure -- some stuff literally exploded. Today I have the phone-interfacing stuff on a separate UPS, with fiber bridges to the rest of the network infrastructure)
Posted Jul 7, 2019 21:02 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link]
UMDF is also limited to drivers that can completely function at IRQL_PASSIVE, so this precludes the use of DMA.
Posted Jul 9, 2019 11:47 UTC (Tue)
by darwi (subscriber, #131202)
[Link]
UIO is very popular in the embedded industry, where manufacturers just want to write a quick driver against a stable user-space ABI, without getting bothered much about kernel programming.
This is typically requested by HW engineers turned lousy SW engineers, who ask for giving them direct access to the device registers and interrupts without wanting to be bothered by anything else, or for quick embedded industry prototypes (and you know the industry's habit of moving prototypes code *as-is* into production).
I'm not aware of UIO being used *heavily* in other context like servers and desktops. The only exception I'm personally aware of is Google's Edge TPU work (drivers/staging/gasket), which should migrate to UIO if it's to be really merged mainline. Assuming that "Edge" TPU will extend one day from IoT to full-fledged laptops and such.
Posted Jul 5, 2019 20:04 UTC (Fri)
by pizza (subscriber, #46)
[Link] (3 responses)
Without a stable API, a stable ABI is worthless.
(...and the history of Android's kernel/hardware facing APIs is anything but stable...)
Posted Jul 5, 2019 22:15 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Posted Jul 5, 2019 22:58 UTC (Fri)
by pizza (subscriber, #46)
[Link] (1 responses)
LWN has a decade worth of articles about any number of Android-created subsystems, APIs, and drivers and the challenges of upstreaming them.
For a while I followed Cyanogen (later LineageOS) development, and with every major release, there were new headaches due to forward-porting stuff that relied on changed Android-specific kernel and device driver userspace APIs. APIs that were not part of any kernel.org release. (with Google, SoC vendors, and major OEMs all getting in on the action. Multi-million-line diffs from upstream were quite common.)
Another example I'm familiar with -- In spite of the same GPU being used on different SoCs in a given generation (ie across the same Android version) the kernel<->userspace ABI wasn't stable because the userspace side had implementation-specific knowledge embedded within it, and also changed based on what other IP blocks happened to be bolted on (eg media decoders or camera engines)
It wasn't until Android 7 that Google finally required its OEMs to start using google-defined stable hardware-facing APIs as a certification requirement, and each successive release has expanded the subsystems required.
I get Linux's lack of a fixed "Driver" API can lead to the appearance of more maintenance work (keeping on top of that was part of $dayjob for the better part of a decade, but was pretty minor compared to the work we already needed to do) but it is specious to claim that most of the churn from one Android release to the next was due to upstream kernel.org changes.
Posted Jul 6, 2019 0:38 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Jul 9, 2019 10:40 UTC (Tue)
by hummassa (subscriber, #307)
[Link] (1 responses)
Posted Jul 9, 2019 10:57 UTC (Tue)
by smurf (subscriber, #17840)
[Link]
Posted Jul 1, 2019 16:38 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (7 responses)
Posted Jul 1, 2019 17:46 UTC (Mon)
by gregkh (subscriber, #8)
[Link] (6 responses)
I stand by my statement that anyone who claims they want a stable driver api doesn't know what they are doing from a technical point of view. The amount of cruft that internal apis like this build up over years and decades will kill an operating system, and we have the prior art to prove it.
Also, no one can claim a stable driver api before they actually have released anything _and_ tried to keep it stable for a number of years :)
I am eager to see how this actually plays out, and am glad to see some more competition in the kernel space, we desperately need it. There are lots of interesting ideas in Fushia, and of course, if any of them actually work out to be a good idea and improvement, there's no problem with having Linux adopt them as well. So we all benefit from this work
Posted Jul 1, 2019 17:51 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Jul 1, 2019 18:28 UTC (Mon)
by ncultra (✭ supporter ✭, #121511)
[Link] (1 responses)
Posted Jul 1, 2019 21:46 UTC (Mon)
by mageta (subscriber, #89696)
[Link]
Binary ABIs probably add to the problem, because there is no 'passing-layer', but that is not the only problem in preserving a stable API. The information you pass, may it be function-arguments, or protocol messages have to stay the same for it to claim to be backwards-compatible/stable, and that is the challenge.
Posted Jul 1, 2019 20:45 UTC (Mon)
by roc (subscriber, #30627)
[Link] (2 responses)
It's not that easy. Some of the ideas (e.g. "have less than 500 syscalls", "use capabilities instead of namespaces") would require breaking backward compatibility. Others would require far-reaching architectural changes in core subsystems, e.g. to support Fuschia's VM features. If you rewrite Linux's internals and replace its syscall interface is it still Linux? :-)
I'm still skeptical about Fuschia taking on Linux until we hear more about WHY Google is doing it and what the long-term plan is.
Posted Jul 4, 2019 6:20 UTC (Thu)
by smurf (subscriber, #17840)
[Link] (1 responses)
I assume that any sort of Linux ABI compatibility isn't in the charts for Fuchsia any time soon ..?
Posted Jul 4, 2019 7:59 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
A translation layer like Linuxulator from BSD might do the trick, though.
Posted Jul 1, 2019 16:53 UTC (Mon)
by rweikusat2 (subscriber, #117920)
[Link] (8 responses)
Posted Jul 1, 2019 17:04 UTC (Mon)
by zlynx (guest, #2285)
[Link] (3 responses)
Posted Jul 1, 2019 17:45 UTC (Mon)
by lkundrak (subscriber, #43452)
[Link] (1 responses)
Posted Jul 1, 2019 18:18 UTC (Mon)
by zlynx (guest, #2285)
[Link]
Pretty much all of NT has the ability to run drivers in a separate environment. Everything communicates through well defined messaging APIs.
NT 3.5 did implement separation between the kernel and many drivers. But it was not performant enough to compete well against Novell so for NT 4.0 they brought everything back into a single address space. Microsoft never lost the separation though, and for Vista they split the graphics driver back out to user-space because those drivers were so complex and crash-prone.
Posted Jul 1, 2019 20:06 UTC (Mon)
by rweikusat2 (subscriber, #117920)
[Link]
Posted Jul 1, 2019 18:34 UTC (Mon)
by ncultra (✭ supporter ✭, #121511)
[Link]
Posted Jul 2, 2019 23:21 UTC (Tue)
by HelloWorld (guest, #56129)
[Link] (1 responses)
Yeah right. Except of course those 2 billion phones running OKL4.
https://gdmissionsystems.com/products/secure-mobile/hyper...
Posted Jul 4, 2019 14:59 UTC (Thu)
by smurf (subscriber, #17840)
[Link]
Posted Jul 6, 2019 17:34 UTC (Sat)
by marcH (subscriber, #57642)
[Link]
Except for the hundreds of millions of embedded controllers running one:
https://www.embedded.com/electronics-blogs/cole-bin/44290...
> non-solution to a non-problem
Yeah, because security is not a hot topic right now...
It's funny how this Torvalds vs Tanenbaum debate because (in)famous, pretty sure neither ever anticipated anything that big. I bet you can find other religious texts also born "accidentally" like this, I mean merely publishing the "right thing at the right time" without any big expectation.
Posted Jul 1, 2019 20:32 UTC (Mon)
by roc (subscriber, #30627)
[Link] (6 responses)
Posted Jul 2, 2019 0:07 UTC (Tue)
by tialaramex (subscriber, #21167)
[Link] (5 responses)
Example: Adam Langley's last blog post, from New Years Day, is an entire design for a zero-knowledge attestation feature for FIDO-style devices. Google promotes and heavily relies on such devices, so is this something Google is doing? Should I expect to get updated software that offers zero-knowledge attestation for my device? Er, probably not. Langley finishes up saying he has "work tomorrow".
Or one I'm most intimately familiar with, Certificate Transparency. CT was very obviously Langley and co's weird side project - right up until Google needed a lever to shift the immovable object that was the Symantec CA, and then there was broader corporate support. Today it's mandatory for Chrome and Google operates most of the big fast logs and wrote code for at least two of them. And after CT was a success you'd periodically see Googlers trying to make Something Else Transparency (and failing, CT solves only a very narrow problem, maybe it's raw luck that we had that exact problem, probably not). Some of those projects even looked promising, Google didn't put lots of firepower behind them and none came to anything.
Travis Geiselbrecht makes operating systems. He helped Be Inc. make theirs, he's worked at Palm (on their failed last PalmOS I think) at Apple (on iOS) at Danger, and so on. These days he's at Google. I have no doubt you could _order_ Travis not to write any operating systems while he works for you, but I'm not sure why you would? But that history I receited isn't exactly a list of balls knocked out of the park either. iOS still exists, the rest failed - at least commercially. So, paying Travis isn't a bet his next project replaces Linux.
I remain stubbornly of the opinion that writing more operating systems only makes sense as a hobby, but Google isn't hurting for money or talent, so they're welcome to go prove me wrong.
Posted Jul 2, 2019 7:27 UTC (Tue)
by gus3 (guest, #61103)
[Link]
As I walk around with my Raspberry Pi heads-up display and forearm keyboard. (I wish!)
-----
> I remain stubbornly of the opinion that writing more operating systems only
Linux started out as Linus Torvalds' hobby. Several other parties turned Linux into
N.B. I have no specific knowledge, information, or investment about such
Posted Jul 2, 2019 22:52 UTC (Tue)
by roc (subscriber, #30627)
[Link] (3 responses)
So whether or not Fuschia is well motivated, at least I'd expect them to make something up.
Posted Jul 3, 2019 8:51 UTC (Wed)
by Wol (subscriber, #4433)
[Link]
Isn't that how MOST things at Google start?
I was under the impression that one of things that attracts engineers to Google is an allocation of company time to work on private projects. And if those projects look promising Google take them on board.
MOST people look at the world through their own set of blinkers, and if reality doesn't match their own rose-tinted view they're too eager to cry "conspiracy". To me, the idea that Fuchsia was a private project that "struck lucky" seems to fit the facts. The idea that Google has studied Darwinism and Evolution, and actively encourages such projects also - to me - seems to fit the facts.
Cheers,
Posted Jul 3, 2019 11:02 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Jul 3, 2019 15:00 UTC (Wed)
by anselm (subscriber, #2796)
[Link]
Yep, sounds exactly like a hobby project that got out of control.
(Remember that both the IBM PC and MS-DOS originally started as somebody's hobby project, and now there's a giant multi-multi-mega-$$$ industry ultimately built on those. Also, Linux.)
Posted Jul 1, 2019 23:11 UTC (Mon)
by garrison (subscriber, #39220)
[Link]
Posted Jul 2, 2019 1:01 UTC (Tue)
by aryonoco (guest, #55563)
[Link] (20 responses)
On the kernel level, it solves Google's problem of Linux not having a stable driver ABI.
On the development level, it fixes the problem of Android SDK being horrible.
Whether stable driver ABI is desirable or not is debatable, the Linux community has obviously decided that it's not, but many people clearly disagree.
Posted Jul 2, 2019 3:05 UTC (Tue)
by pizza (subscriber, #46)
[Link] (6 responses)
s/not having a stable driver ABI/being the only Android component under a copyleft license/
Posted Jul 2, 2019 8:57 UTC (Tue)
by mjthayer (guest, #39183)
[Link] (5 responses)
Posted Jul 2, 2019 12:02 UTC (Tue)
by squeed (subscriber, #87316)
[Link] (3 responses)
This is the core reason why Android phones never get updates - it's a hellish rebase to port their hacky drivers on to a new kernel version. So, they don't, and the phones languish with stale or missing updates.
By moving the drivers out of the kernel, Google is hoping that Android vendors will have an easier time keeping their phones up-to-date.
Posted Jul 2, 2019 15:40 UTC (Tue)
by rahvin (guest, #16953)
[Link] (2 responses)
To me this is about two issues, the first being Google doesn't like things developed elsewhere (not in house syndrome), and they have certain manufacturers in the Android ecosystem that don't like copyleft. With this initiative they can kill both. Personally, I hope it's an abject failure, because if you think your phone isn't updated now, it's going to be even worse under this new OS because the customer won't even have access.
Posted Jul 3, 2019 12:14 UTC (Wed)
by HelloWorld (guest, #56129)
[Link]
Vendors can already stop customers from running their own kernels, they only need to lock the bootloader. GPLv2 doesn't prevent that, and that is one of the reasons why GPLv3 was invented.
Posted Jul 4, 2019 14:42 UTC (Thu)
by smurf (subscriber, #17840)
[Link]
In principle, Fuchsia works by message passing, so the situation with strange manufacturer drivers should actually become easier. Compile your own kernel, let it run all the 3rd party critters it wants (in a sandbox if necessary; sandboxing is somewhat easy if you control all communication to a process), and otherwise do your own thing. The only problem with that idea is that everybody and their dog will immediately establish cute undocumented shared-memory interfaces so that they don't need to pay the message passing and transcoding penalty, which will quickly kill off any plan to use this new fancy modularization for anything useful.
Posted Jul 4, 2019 13:30 UTC (Thu)
by arnd (subscriber, #8866)
[Link]
A lot of things were open-coded in kernels of early Android devices: clock management, timers, irqchips, PCI host bridges, GPIO, LED, pin control, and many more things had no abstract interface at all a few years ago, and now there is a subsystem for each one that drivers can plug into. If all those drivers are outside of the tree, it's much harder to come up with any clean interface for them (much less a stable one).
Posted Jul 2, 2019 15:49 UTC (Tue)
by rweikusat2 (subscriber, #117920)
[Link] (12 responses)
Posted Jul 2, 2019 18:55 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (7 responses)
Posted Jul 2, 2019 20:24 UTC (Tue)
by rweikusat2 (subscriber, #117920)
[Link] (4 responses)
Posted Jul 3, 2019 11:01 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
We can look at Android - the main success story of Linux. The driver story there is a burning trash fire - tons of code that is not upstreamable or even in straightforward binary blobs. And this situation persists, even though Google is exerting quite a lot of pressure on vendors. And because Linux developers like to break the driver API, forward-porting this mess is complicated.
Posted Jul 3, 2019 11:25 UTC (Wed)
by pizza (subscriber, #46)
[Link]
Those subsystems saw a _lot_ of churn between major Android releases, and even as stuff slowly got upstreamed, the usual kernel development process saw that stuff change, often significantly. So it wasn't a lack of a stable "driver API" holding anyone back, it was that Google et al were changing all sorts of other internal, non-driver APIs to suit their needs and/or whims. Indeed, the core "no stable API" kernel.org folks routinely showed far, far more discipline with respect to API stability than anyone involved with Android kernels.
This is why vendor-supplied OS upgrades were so hard to come by; everyone involved essentially had to rewrite all their "special sauce" for each update. Over time Google got a lot more disciplined, (including stabilizing and upstreaming much of the important stuff), and started forcing the SoC vendors and OEMs to behave better.
As an aside, part of why upstreaming was so challenging is that a lot of the changes, while great for some use cases (ie smartphones) caused significant functional or performance regressions for other uses. It turns out that a single-OS-for-everything requires quite a bit of ongoing engineering discipline, and Google's going to re-learn that lesson the hard way with respect to Fuschia.
Posted Jul 4, 2019 14:46 UTC (Thu)
by smurf (subscriber, #17840)
[Link]
A stable driver API is pretty much a necessity when manufacturers either hack their vendor kernel into unmergeability or flatly refuse to ship source (or both) and we let them get away with it.
Posted Jul 17, 2019 21:12 UTC (Wed)
by nix (subscriber, #2304)
[Link]
As someone who's been doing it for years with a really fairly invasive out-of-tree patchset, keeping up with kernel API changes is really not difficult at all. Even disruptive changes usually come with dozens of real-life examples in the kernel source tree of how to port to the new API within a week or two of the API landing, and the old API is rarely ripped out until a kernel release or two has gone past: and the old API being replaced with the new is pretty obvious to anyone who watches the subsystems they depend on, or even just tries to recompile the patchset in question with each new kernel release (a minimum bar for any maintainer, one would think). A vendor who had trouble with that rate of change is a vendor who can't do fairly simple transformations on their source even given three to six months to do them. The quality of any driver that hard to maintain is probably beyond abysmal.
And Linux is so "absent" on desktops that I've been using it to the exclusion of all else as my desktop OS since 1997, and I really haven't had to look hard to find hardware it worked on (though before about 2005 it did take "find out what the X developers use" to pick a machine with the right graphics card). For at least ten and probably more like fifteen years Linux has had better hardware support than any other OS in existence. A lack of drivers is not its problem, and crippling the driver API to overcome it would not help in any case.
Posted Jul 2, 2019 23:22 UTC (Tue)
by rgmoore (✭ supporter ✭, #75)
[Link]
A stable API has advantages and disadvantages. It's advantageous because it makes it easy to maintain drivers; once they work, they should continue to work without any churn keeping them API compatible. A stable API is problematic because it means you have to support all the mistakes in the first version of your API indefinitely. The success of the Linux model- an unstable API and in tree drivers as the accepted approach- should prove that a stable driver API is not absolutely necessary for success, even if you think it's not optimal.
Posted Jul 2, 2019 23:25 UTC (Tue)
by HelloWorld (guest, #56129)
[Link]
Posted Jul 4, 2019 14:44 UTC (Thu)
by mrshiny (guest, #4266)
[Link] (3 responses)
Posted Jul 5, 2019 0:21 UTC (Fri)
by tao (subscriber, #17563)
[Link] (2 responses)
Posted Jul 5, 2019 1:32 UTC (Fri)
by mrshiny (guest, #4266)
[Link] (1 responses)
Posted Jul 5, 2019 6:30 UTC (Fri)
by smurf (subscriber, #17840)
[Link]
Posted Jul 2, 2019 13:16 UTC (Tue)
by weberm (guest, #131630)
[Link] (2 responses)
Posted Jul 3, 2019 11:16 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link]
The site is automatically generated from MD files (using Javascript, yes) stored in a git repo. Feel free to clone them locally and view them using any tool: https://fuchsia.googlesource.com/fuchsia/+/master/docs
Posted Jul 4, 2019 14:50 UTC (Thu)
by mrshiny (guest, #4266)
[Link]
Posted Jul 3, 2019 1:51 UTC (Wed)
by ssmith32 (subscriber, #72404)
[Link] (1 responses)
Posted Jul 22, 2019 2:16 UTC (Mon)
by tbodt (subscriber, #120821)
[Link]
Posted Jul 6, 2019 22:05 UTC (Sat)
by walex (guest, #69836)
[Link]
I have been describing it several times in online discussions, and there are the articles in the August 1979 issue of "Software Practice and Experience".
Posted Jul 11, 2019 9:10 UTC (Thu)
by davidgerard (guest, #100304)
[Link]
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
They have their own libc, a non-GPL busybox clone (though Sony paid for that one), Bluetooth (BlueZ is GPL and not used anymore) stack, and many other components that were rewritten to avoid the GPL.
Fuchsia is clearly intended to provide a new, non-GPL kernel, for Android and other Google products.
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
What does this have to do with GPL?
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
- You mean the one I dumped when my operator gave me a new, much better one "for free"?
Google's Fuchsia OS Developer Site Debuts (Forbes)
Plenty of phones die without receiving any updates, even though the source code is available. Simply because nobody cares.
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Wol
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
That's not quite true. Vista (and later XP) provided new UMDF (User-Mode Driver Framework) API, but it didn't force anybody to use it. The old in-kernel API is still here and can be used just fine.
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Reason
Reason
> makes sense as a hobby
a business proposition. Fuchsia might turn out the same way for Google: a hobby
that became someone else's much bigger profit.
future outcomes.
Reason
-- someone's hobby project that got out of control
-- full employment program for bored Google engineers
-- seize even more power for Google
Not to mention if you're going to make it open source you presumably want a community to rally around it, and offering some kind of vision really helps with that.
Reason
> -- someone's hobby project that got out of control
Wol
Reason
Reason
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
A little humility would be in order here. Linux is (still) absent on desktops and the lack of drivers definitely contributed to it, during early 2000-s poor driver support was a constant bane of Linux existence (along with the fractured distro ecosystem).
But that has nothing to do with the stability of the driver API! The lack of drivers happened because the things that needed drivers had no documentation, reverse-engineering of hardware interfaces is hard and slow, and the vendors who wrote the other-OS drivers were unwilling to produce drivers for Linux because they needed to provide source code (and they were ancient proprietary monsters who saw this as unacceptable) and because they saw Linux as too niche, not because the burden of forward-porting the drivers to new kernel releases was too high.
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
If these weren't possible then the companies in question would need to keep their drivers in mainline and up to date, and the problem wouldn't occur.
Google's Fuchsia OS Developer Site Debuts (Forbes)
In that light, make sure to vet the OS very closely before you consider using it for anything.
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
Google's Fuchsia OS Developer Site Debuts (Forbes)
The Zircon API resembles quite a bit that of MUSS
Google's Fuchsia OS Developer Site Debuts (Forbes)