Hacker News Reader

Comment by choroid | Hacker News Reader

What does google gain from ditching linux?

I know some of the folks working on this and a companion piece of hardware[+]. These people say it's all about embedded and real time. Linux hasn't been designed for that (and if you haven't used Linux for something deeply embedded: it's a real issue, and not a slur on Linux. Motorbike, car, truck, bicycle all fit different points in the transportation matrix).

[+] which hardware may never see the light of day, who knows? Certainly not me, a non-googler. And the people I know are engineers; perhaps upper management has other intentions. But that's what my friends are working on.

Interesting. I would like to know the comparisons between Fuchsia, and QNX which is also a real-time microkernel operating system that runs on cars and phones. It seems Fuchsia competes with QNX directly in that space.

Another question is if the operating system is designed to be real-time, the applications also need to be real-time. If the applications are not real-time, you lose the real-timeness. Dart is garbage-collected. I suppose it is not real-time, yes?

There are a bunch of hard realtime kernels; QNX is not a major player.

What are some of the major players?

VxWorks, eCos, ITRON, RTEMS, RTX... There are a plethora of players emphasizing specific features. Outside realtime, various BSDs and then some RT Linux and even still wince.

Free software plays a huge role in this field of course, dating back to the Cygnus days.

There's a bunch of them, but you'd never want to run hard realtime on a phone or tablet. Hard realtime gives you horrible performance, but excellent latency guarantees. One big thing they do in hard realtime systems is to disable the CPU cache, because caching prevents determinism. It's also essential for performance, but in a hard realtime system performance isn't important.

1. Modularity makes it easier to update portions of the OS even when device manufacturers are uncooperative (e.g. broadcom / qualcomm failing to provide driver source code)

2. Commercial license

3. They get to control commits (rather than waiting for linux devs)

> 2. Commercial license

Not sure if this is what you were referring to, but the article notes

"With Fuchsia, Google would not only be dumping the Linux kernel, but also the GPL: the OS is licensed under a mix of BSD 3 clause, MIT, and Apache 2.0. "

Duel licensing.

Google will have a "technically open source" version but OEM's will be required to buy the separately licensed google version to include things like the play store and gmail.

Dual-licensing in that sense is far more common with GPL'd apps/libraries where the copyright holder offers a separate commercial license for the same code.

The Fuchsia source is primarily BSD licensed (with some MIT bits like the Magenta kernel, and some third party code generally of the MIT/BSD/Apache2/Zlib varieties).

Unless I'm mistaken dual licensing GPL'd code also requires holding the initial copyright. It also adds complications around outside contributions. With BSD they can accept contributions under that license and still license it themselves.

>Duel licensing.

I don't think that's legal, but it's a pretty interesting idea. Instead of just mandating a license, the vendor and customer can each advocate a license, and then have a duel to determine which license to use. Of course, each side would have to find someone willing to risk death in a duel (and one of them would have to die, for it to be a real duel), just for the sake of their employer. Do you think it'd be better to have a duel with swords or pistols? I guess they could water it down and remove the death requirement, perhaps by having the combatants do fencing or wrestling or something like that.

The worst part is I actually thought about the fuel/dual thing when I wrote it but still picked the wrong one.

See all the standard microkernel arguments, which seem particularly apropos given the overall Android ecosystem. You ideally want the vendor provided device drivers sandboxed since they're often not that good.

A more permissive license that does not use the GPL

Drivers reside in userspace

Stable driver ABI

Reduced attack surface area

Control of their own kernel development

Linux system internal are ugly, there is little progress on static driver verification, resource management heuristics are poorly tuned, and the kernel network stack is so bad, you can make a living selling your own user space version. Linux has a lot of very real problems.

I'm really curious as to where you find the kernel's network stack problematic? Can you explain that in more detail?

Also, what issues do you have with the scheduler?

This may be applicable:

Scheduling for Android devices

https://lwn.net/Articles/706374/

https://blog.cloudflare.com/kernel-bypass/

For an example among many. Basically network data should magically appear in bulk, whereas in Linux it's almost one packet at a time.

As you move to 10G, thus start to eat a lot of cpu.

Since that article was published, things have changed a little bit. At least for the filtering use case they talked about in the blog, XDP (https://www.iovisor.org/technology/xdp) has come about, which is an in-kernel mechanism by which to filter at wire speed.

I don't disagree that there are many examples, but it's hard to solve them unless people give specifics.

Not really a problem for mobile... For HPC there have been user mode and offload tweaks since forever. The fact that none of the hardware or task specific techniques can replace the traditional BSD sockets stack is because writing that in general is a ton of work... Work which G would have to do ^10 to replace Linux in an android context.

Wasted cycles are directly proportional to power consumption.

Fun? A blank canvas? Freedom from trolls? Don't have to argue with Linus about userspace, evar?

AFAIK, there's at least 3 kernels running on an Android device. - LK (1) for the bootloader (the screen you see when launching fastboot, I believe) - LK (2) for 'Trusty', the crypto engine - Linux as the bootloader's payload.

If Magenta is also an instance of LK then they can maintain each through a common source tree and the bootloader can initialize the device resources once without needing separate drivers for each distinct kernel.

Most Android devices also run some OS on the baseband processor (on-die or separate), and often the Wifi, Codecs, Bluetooth, Power Management blocks, etc also run their own little OSes. It's getting a little crazy, how many distinct cores exist on these devices.

Magenta was based on LK but it is definitely its own thing and is evolving in its own directions (64bit, SMP, userspace, etc). LK is generally MCU-targeted and can be very tiny (15-20K for a minimal system used for bootloader cores or tiny embedded things).

Likely most of the other things mentioned here but also reducing the number of patents used in selling an android device:

http://www.zdnet.com/article/310-microsoft-patents-used-in-a...

The majority of those patents are low quality and prior art laden. They were used to shake down Android OEM's that didn't want to go to court. Barnes & Noble called them on their extortion games and both companies immediately settled with Barnes & Noble also setting up a joint venture. Microsoft knows their junk and doesn't want to actually prove they aren't. Any court case involving an Android OEM will automatically get legal aid from Google in invalidating any patents presented.

According to an analysis by NCAM

  21% of Microsoft’s alleged Android portfolio scored as
  commercial versus 79% as non-commercial. This means
  that only one fifth of the portfolio was directly 
  commercially relevant, casting doubt the overall 
  viability of the Microsoft licensing packages on offer.

  There are a surprising amount of abandoned and expired 
  patents already in this space. Much of the Android 
  platform may, in fact, be a 'Freedom to Operate' space 
  and already part of the public domain. There may well 
  be alternatives to the Microsoft licensing packages 
  that could be assembled from the rich vein of patents 
  that occupy the 'Freedom to Operate' space.

>In sum, M-Cam's analysis suggests that Microsoft's claim to ownership of the Android OS may not be as strong as it has hitherto insisted it is and it asks:

  The question remains as to whether Microsoft actually owns proprietary rights 
  to the Android OS or is the company unfairly taxing device makers by exploiting 
  an uninformed belief in its supposed innovation?

http://www.i-programmer.info/news/193-android/7537-microsoft...

http://www.m-cam.com/sites/www.m-cam.com/files/Patently%20Ob...

https://seekingalpha.com/article/3545506-microsoft-sacrifici...

Linux was developed with personal computers and servers in mind. Not mobile phones. The world really needs a bottom up mobile first operating system IMO. iOS is the closest to this right now, but at the end of the day it's still just Darwin.

How would a mobile first OS differ? The constraints of mobile devices are way above the desktop constraints linux was built to deal with.

Same thing Apple and Windows gain - you get to call all the shots - feature set, release schedule, programming language/environment...

If you have the resources to do it, I guess - why not do it? Especially for something like a phone/tablet OS.

Control.

Smaller surface area for various purposes from security to performance. Stable ABI for driver (I'm guessing) giving Google the ability to upgrade the core OS.

More permisive/corporate friendly license

Reply on news.ycombinator.com