Hacker News Reader

Comment by PhantomGremlin | Hacker News Reader

Antagonistic headline.

The article does a pretty good job of answering the question: Linux is bloated, isn't real time, and has IP issues.

"Linux is bloated, isn't real time, and has IP issues."

There have been real-time kernels for Linux. They're kind of important for people using Linux for professional audio (and doubtlessly other fields as well).

Yes. There is the PREEMPT_RT patchset for sub-millisecond response times. Many of the features for PREEMPT_RT have been merged to mainline, so stock performance is quite good to the millisecond level.

Linux is modular, you can remove the parts you don't want.

Linux has multiple real-time varietals.

Linux has no IP issues that I know of.

IP issue: Google doesn't have the right to give hardware vendors a pass on proprietary drivers for Linux. Ignoring the problem seems to work so far, though.

That said, a stable driver API with the possibility to update the kernel without updating drivers is probably more important to Google. In the best case (and I expect a worse result than that) it means that Android phones can be updated for a long time without requiring support from the vendor.

The damn vendors should just upstream the damn drivers. Drivers for embedded hardware are such a clusterfuck. You have no idea how bad it is unless you have worked in that space.

Linux being GPLed is probably the only reason it's used so often on all these different embeded platforms. No one is sharing code on these other oses unless you have piles of money but with Linux anyone can pretty much click "y" in menuconfig and you're good to go on nearly anything.

The GPL has made Linux a "Universal Kernel" of sorts.

Linux "enterprise" distributions update things for a long time without requiring support from the hardware vendor.

Google's familiar with this approach, I hear that they backported x86-64 to an earlier kernel for years.

In the embedded case, usually only vendors have (or used to have, who knows if they use source control) the source code. As I said, you have no idea how bad it is unless you've had to work with that crap. Maybe have a look at "Bad" in this classic. https://www.dolphin-emu.org/blog/2013/09/26/dolphin-emulator...

Edit: right, you can backport fixes and features while keeping the ABI stable. That is what Google seems to be doing with Android kernels to some degree.

And Google has done that -- for instance, they use Binder for IPC instead of dbus/kdbus on Android. But every time Google does that, they pay a price for using Linux, as they have to maintain anything in the kernel that doesn't make it upstream.

The reason Google cares about this, as noted elsewhere, is that there is no stable kernel ABI for drivers, so vendors who release drivers-as-blobs, fail to release the driver source code (yes, it's a GPL violation; yes, it happens anyways) or otherwise pin their driver to a specific ABI need to release new drivers every time the kernel changes. Google would love to release Android versions independently of drivers, the way Windows works.

> Google would love to release Android versions independently of drivers, the way Windows works.

Which they'll be able to do with Project Treble: https://android-developers.googleblog.com/2017/05/here-comes...

it won't update the kernel part.

If they had stuck with the APIs and ABIs literally everyone else uses they wouldn't have this problem in the first place. Most people's userspace is not tied this heavily to the kernel version because the APIs and ABIs there are fairly stable.

Interestingly enough, if you look at the Linux kernel in terms of LOC, it is lower than Win7/8/10 which are lower than MacOSX.

that's quite impressive as Linux also contains the source code for mountains of hardware, from the most ancient to (almost) the most modern

Not to mention drivers for every networking scenario and filesystem under the sun.

By every filesystem, you mean all variants of `ext`, right?

But it's leaving out a lot more important stuff:

* Secure and fast micro-kernel.

* Only non-blocking async calls (similar to Microsoft's Singularity).

But they didn't follow through with using managed memory only as Microsoft did, which might catch them some day. Their app-layer does, so it's a problem to solve anyway.

Reply on news.ycombinator.com