Live data from Hacker News

Zircon Fair Scheduler

fuchsia.googlesource.com

21–30 of 79 posts

Re: Zircon Fair Scheduler

#21

Earlier quoted context omitted.

Nothing, at all, has demonstrated that they plan it to replace Android -- that was a narrative various tech blogs invented. Nor would it have any benefit in moving away from the Java inspired/cloned underpinnings of the Android user layer. Google has a variety of initiatives, and they really like reinventing things (which can sometimes yield great outcomes). This is a kernel that is in contrast with Linux.

https://www.tomsguide.com/us/google-fuchsia-os-replace-andro... From the article, the OS allows for full compatibility with all Android apps. Furthermore, it notes that Google is going out of its way to avoid mentioning Android anymore. Of course, if I were Google and trying to sell the public on my new OS, I'd want them all to think that I'm not scrapping the old OS so that they feel they have a choice.

"the OS allows for full compatibility with all Android apps"

The article does not say that. The article mentions an ART target for Fuscia -- you have to build from something. That is approximately 0.1% of the way towards full compatibility. And for that matter you can run Android apps on a load of targets (although far from full compatibility), but that doesn't mean that they're replacing Android.

Google may absolutely replace Android -- they've made loads and loads of mistakes along the way -- but the way people keep arguing it doesn't make sense, using examples that jettison the parts that work well and somehow keep the parts that don't work well (which includes ART, as an aside). And indeed I'm falling into this same trap while talking about Fuscia like it's a kernel, when really the kernel is a small part and they're, at a very small scale, spit-boarding a new take on virtually every part of the system.

Regarding Google distancing itself from the Android name, that's just branding. To quote one analysis -- "Android sounds technical, has baggage, and might be stale". They've had enough missteps that it's an anchor more than a lift, so it makes sense that they stop highlighting it.

Re: Zircon Fair Scheduler

#23
post #14

Earlier quoted context omitted.

> And at that point you have to ask what is gained, and at this point the answer is "nothing". Not having to care about the permanent breaking of internal kernel APIs is not "nothing".

How, exactly, will they "not have to care"? The identical ramifications occur with Fuscia as they happen with Linux! This is farce. Every single problem that Android has had, from low-latency audio issues (they've rebuilt that a dozen times in a dozen cartoonish ways) to driver stagnancy, is completely and directly a result of Google choices and implementations (and they do the same thing again and again! It's remark…

It is a difference whether the fault for this lies at the Google engineers or the kernel maintainers.

Re: Zircon Fair Scheduler

#24

Earlier quoted context omitted.

Android OEMs are not in the business of writing kernels, though, and the changes they do are minimal. And their HAL/chipset code -- the thing they might actually care about as IP -- is not governed by the GPL at all, nor is any of the enormous volume of system and userspace code they write. It's a neat initiative and might yield something interesting, but if the Linux kernel was replaced by Fuscia the ramifications a…

The components of their HAL/chipset code in the kernel are most of the time governed by the GPL. We can take some examples apart of need be.

After Project Treble that only applies to the legacy HAL code.

Re: Zircon Fair Scheduler

#25
post #23

Earlier quoted context omitted.

How, exactly, will they "not have to care"? The identical ramifications occur with Fuscia as they happen with Linux! This is farce. Every single problem that Android has had, from low-latency audio issues (they've rebuilt that a dozen times in a dozen cartoonish ways) to driver stagnancy, is completely and directly a result of Google choices and implementations (and they do the same thing again and again! It's remark…

It is a difference whether the fault for this lies at the Google engineers or the kernel maintainers.

Google has never been required to commit upstream, but they've chosen to do so because of the ease of integrating changes downstream. They could have forked off and bashed the code into whatever form they wanted to. Breaking anything and everything.

But they didn't. They kept keeping it in sync. They probably had a reason for doing that.

Re: Zircon Fair Scheduler

#26
There are many references to multiple cpu systems throughout the document. Maybe I missed something, but I didn't know Fuschia was aimed at systems like that. I am no expert, but aren't the vast majority of multiple cpu systems servers or high-rnd workstations? If google can supply their own server os, Linux could lose a lot of support and funding

Re: Zircon Fair Scheduler

#27
post #2

This post has sky-rocketed to the top! I'm genuinely curious: can someone explain what's cool/interesting/important about this (maybe EL5)? Thanks!

Well, Google intends for this new OS to replace Android. They'll need to convince the public that this new OS is somehow better than Android, which everyone has come to know and love. It seems that they believe the best way to do that is a grassroots approach beginning with tech discussion hubs like HN and Reddit. Of course, they could have just meme'd hard about the fact that they're moving away from evil Oracle tec…

> Android, which everyone has come to know and love.

Haha, honestly now. If my Android didn't cost $700 I would long since have smashed it to bits. It's scheduler is totally garbage, to the point where Google's own media apps like YouTube and Music drop samples while the screen is redrawing. Who "loves" Android? To me it is the Win98 of mobile operating systems.

Re: Zircon Fair Scheduler

#28

> A NOTE ABOUT DEADLINES: While fair scheduling is appropriate for the vast majority of workloads, there are some tasks that require very specific timing and/or do not adapt well to overload conditions. For example, these workloads include low-latency audio / graphics, high-frequency sensors, and high-rate / low-latency networking. These specialized tasks are better served with a deadline scheduler, which is planned…

It does imply that. Multiple concurrent scheduling algorithms is nothing new, Linux and MacOS both support per-thread algorithm selection.

Re: Zircon Fair Scheduler

#29
post #22

https://cchalpha.blogspot.com/2019/03/bmq-scheduler-call-out... Someone made a scheduler on linux based on some of the ideas here. Its included in the postfactum (linux-pf) patch set i believe, which might have packages for your distro.

No, that's based on the deprecated multi-level round-robin scheduler, which we find tremendously amusing. :)

Re: Zircon Fair Scheduler

#30
post #24

Earlier quoted context omitted.

The components of their HAL/chipset code in the kernel are most of the time governed by the GPL. We can take some examples apart of need be.

After Project Treble that only applies to the legacy HAL code.

Even fully after Treble, there are absolutely still kernel drivers.
Post reply on HN