LWN: Comments on "Google's Fuchsia OS Developer Site Debuts (Forbes)"

Google's Fuchsia OS Developer Site Debuts (Forbes)

tbodt — Mon, 22 Jul 2019 02:16:37 +0000

Handles are per-process, so you'd only have to break the ABI if you somehow needed more than 2^32 handles in a single process. That's probably more than would reasonably fit in memory.

Google's Fuchsia OS Developer Site Debuts (Forbes)

nix — Wed, 17 Jul 2019 22:22:24 +0000

Isn't this basically what Treble is all about? A stock kernel *does* have to be able to boot, etc, in a Treble world, IIRC.

Google's Fuchsia OS Developer Site Debuts (Forbes)

nix — Wed, 17 Jul 2019 21:12:42 +0000

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.

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.

Google's Fuchsia OS Developer Site Debuts (Forbes)

davidgerard — Thu, 11 Jul 2019 09:10:45 +0000

minor note - "Forbes" doesn't report this - it's a contributor blog.

Google's Fuchsia OS Developer Site Debuts (Forbes)

darwi — Tue, 09 Jul 2019 11:47:27 +0000

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

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.

Google's Fuchsia OS Developer Site Debuts (Forbes)

smurf — Tue, 09 Jul 2019 10:57:36 +0000

The PostmarketOS people would probably be even happier if they had a kernel that actually gets updates.

Google's Fuchsia OS Developer Site Debuts (Forbes)

hummassa — Tue, 09 Jul 2019 10:40:29 +0000

I bet the PostmarketOS crowd disagrees...

Google's Fuchsia OS Developer Site Debuts (Forbes)

Cyberax — Sun, 07 Jul 2019 21:02:55 +0000

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

UMDF is also limited to drivers that can completely function at IRQL_PASSIVE, so this precludes the use of DMA.

Google's Fuchsia OS Developer Site Debuts (Forbes)

pizza — Sun, 07 Jul 2019 12:26:09 +0000

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

Google's Fuchsia OS Developer Site Debuts (Forbes)

pizza — Sun, 07 Jul 2019 12:05:32 +0000

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

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

The Zircon API resembles quite a bit that of MUSS

walex — Sat, 06 Jul 2019 22:05:28 +0000

The distinct VMO VMAR concepts and the "handles" that can be passed via "channels" and are removed from the sending process seem to have been inspired closely by the "kernel" of the MUSS operating system developed at Manchester in the 1960s-1970s, a design that in simplicity and efficiency has yet to be surpassed, even if later operating system "kernels" have had somewhat similar features.

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

Google's Fuchsia OS Developer Site Debuts (Forbes)

Wol — Sat, 06 Jul 2019 21:48:17 +0000

> Okay, here's the most obvious: NT4 -> Win2K -> WinXP -> Vista, Win7 -> Win8.0, and Win8.1 -> Win10 all required different graphics drivers due to different ABIs. (Win7 allowed using Vista drivers, and 8.1 could use 8.0 drivers, but IIUC all others had an incompatible changes at the ABI level. (Win10's various semi-annual updates have introduced further changes but it's not clear if there's an ABI break lurking in there somewhere..)

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,
Wol

Google's Fuchsia OS Developer Site Debuts (Forbes)

marcH — Sat, 06 Jul 2019 17:34:28 +0000

> The problem that people still aren't using microkernels

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.

Google's Fuchsia OS Developer Site Debuts (Forbes)

marcH — Sat, 06 Jul 2019 00:57:25 +0000

"most obvious" and maybe not very representative: GPUs have evolved at a speed not far from smartphones.

Even if representative that still gives a few years of stability.

Google's Fuchsia OS Developer Site Debuts (Forbes)

Cyberax — Sat, 06 Jul 2019 00:38:04 +0000

I meant that Android's userspace API that is exposed to applications is stable. Not the inner OS workings.

Google's Fuchsia OS Developer Site Debuts (Forbes)

pizza — Sat, 06 Jul 2019 00:36:59 +0000

Okay, here's the most obvious: NT4 -> Win2K -> WinXP -> Vista, Win7 -> Win8.0, and Win8.1 -> Win10 all required different graphics drivers due to different ABIs. (Win7 allowed using Vista drivers, and 8.1 could use 8.0 drivers, but IIUC all others had an incompatible changes at the ABI level. (Win10's various semi-annual updates have introduced further changes but it's not clear if there's an ABI break lurking in there somewhere..)

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.

Google's Fuchsia OS Developer Site Debuts (Forbes)

Cyberax — Sat, 06 Jul 2019 00:36:47 +0000

That's half-true. There are major changes in some APIs, like 3D-accelerated video drivers. This is not a problem because there's just a handful of accelerated video device manufacturers and Microsoft works with them directly.

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.

Google's Fuchsia OS Developer Site Debuts (Forbes)

marcH — Fri, 05 Jul 2019 23:10:48 +0000

> Because with every Windows release since the beginning of time, Microsoft has changed at least one major driver API.

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.

Google's Fuchsia OS Developer Site Debuts (Forbes)

pizza — Fri, 05 Jul 2019 23:04:14 +0000

> How do you know that?

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.

Google's Fuchsia OS Developer Site Debuts (Forbes)

pizza — Fri, 05 Jul 2019 22:58:21 +0000

> Which APIs? The kernel APIs are not stable, since it's built on Linux.

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.

Google's Fuchsia OS Developer Site Debuts (Forbes)

Cyberax — Fri, 05 Jul 2019 22:15:25 +0000

Which APIs? The kernel APIs are not stable, since it's built on Linux. Android user-space APIs are stable, for at least 5 year periods.

Google's Fuchsia OS Developer Site Debuts (Forbes)

marcH — Fri, 05 Jul 2019 21:30:46 +0000

> Those old PCs are running modern drivers, not the stuff that was available at the time of manufacture.

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.

Google's Fuchsia OS Developer Site Debuts (Forbes)

pizza — Fri, 05 Jul 2019 20:08:15 +0000

Those old PCs are running modern drivers, not the stuff that was available at the time of manufacture.

(Go figure, manufacturers supporting their stuff..)

Google's Fuchsia OS Developer Site Debuts (Forbes)

pizza — Fri, 05 Jul 2019 20:04:44 +0000

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

Without a stable API, a stable ABI is worthless.

(...and the history of Android's kernel/hardware facing APIs is anything but stable...)

Google's Fuchsia OS Developer Site Debuts (Forbes)

marcH — Fri, 05 Jul 2019 20:01:20 +0000

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

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.

Google's Fuchsia OS Developer Site Debuts (Forbes)

Cyberax — Fri, 05 Jul 2019 19:42:46 +0000

> If the device drivers in question had been required to adhere to the GPL, i.e. a link to all sources on every phone, we would be able to forward-port the stuff and thus keep these phones alive.
Plenty of phones die without receiving any updates, even though the source code is available. Simply because nobody cares.

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.

Google's Fuchsia OS Developer Site Debuts (Forbes)

marcH — Fri, 05 Jul 2019 17:37:17 +0000

Well put, thanks.

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

excors — Fri, 05 Jul 2019 15:59:29 +0000

I think many of the problems with Linux on Android are a consequence of the rapid advancement of smartphone hardware and of user expectations. E.g. when ARM designed big.LITTLE and some phone vendor decided to use it in a product, the software engineers probably had just months to get the kernel working with the new chips. They had to hack the scheduler, because there simply wasn't enough time to work with the wider kernel community and discuss all the implications and reach consensus and make the fundamental scheduler changes needed for a clean HMP implementation and get all the code reviewed and merged and released; that would have taken years, by which time they would have fallen multiple SoC generations behind their competitors (iOS and other Android vendors), and the long-term maintainability of the code would be irrelevant because they'd have gone out of business.

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.

Google's Fuchsia OS Developer Site Debuts (Forbes)

smurf — Fri, 05 Jul 2019 15:32:29 +0000

Google is in some position to fix this, basically by requiring that the phone needs to be runnable with a stock kernel before the manufacturer gets the right to distribute its (closed-source) equivalent of the Google Apps suite. Ideally, they'd also insist that the kernel and the UI building blocks must be OTA-updateable.

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.

Google's Fuchsia OS Developer Site Debuts (Forbes)

pizza — Fri, 05 Jul 2019 13:58:47 +0000

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

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.

Google's Fuchsia OS Developer Site Debuts (Forbes)

smurf — Fri, 05 Jul 2019 10:13:37 +0000

If the device drivers in question had been required to adhere to the GPL, i.e. a link to all sources on every phone, we would be able to forward-port the stuff and thus keep these phones alive.

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.

Google's Fuchsia OS Developer Site Debuts (Forbes)

Cyberax — Fri, 05 Jul 2019 09:20:41 +0000

> 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).
What does this have to do with GPL?

Google's Fuchsia OS Developer Site Debuts (Forbes)

smurf — Fri, 05 Jul 2019 06:30:08 +0000

Yeah, but that's mainly because proprietary drivers exist in the first place.
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)

smurf — Fri, 05 Jul 2019 06:27:59 +0000

> Have you ever tried to explain the GPL to one of them?

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

Google's Fuchsia OS Developer Site Debuts (Forbes)

mrshiny — Fri, 05 Jul 2019 01:32:08 +0000

Nope, the open source drivers. I've had problems with nouveau and the amd drivers. It's been a recurring problem for a decade at least with the free drivers.

Google's Fuchsia OS Developer Site Debuts (Forbes)

tao — Fri, 05 Jul 2019 00:21:34 +0000

Lemme guess, Nvidia's proprietary driver?

Google's Fuchsia OS Developer Site Debuts (Forbes)

marcH — Thu, 04 Jul 2019 23:24:51 +0000

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

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.

Google's Fuchsia OS Developer Site Debuts (Forbes)

smurf — Thu, 04 Jul 2019 14:59:05 +0000

That thing is not a microkernel. It's a hypervisor. Also we-as-people are not using it – we use [some complicated Java runtime thing which uses] Linux which is mostly-blissfully-unaware that OKL4 even exists.

Google's Fuchsia OS Developer Site Debuts (Forbes)

mrshiny — Thu, 04 Jul 2019 14:50:07 +0000

XHR and Javascript are not surveillance tools. Javascript is just code and XHR is just web requests done from code. They can be used for surveillance, sure, but it's not automatically the case that they are used for surveillance. Tons of websites today are written using Javascript and don't have any particular surveillance features because of that. Websites have been tracking you with cookies and pixels since before Javascript.

Google's Fuchsia OS Developer Site Debuts (Forbes)

smurf — Thu, 04 Jul 2019 14:46:09 +0000

A stable driver API is a completely brain-dead idea if you only have GPL code and intend for those drivers to be available as freakin' source code, if not live in the mainline kernel anyway.

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.