/Google Fuchsia General/ : /gfg//

Well it won't replace Linux on the server side.

We're talking laptops, smartphones and desktops.

More freedom. You know when people say
>I wish we could do a, b, and c but it would require rewriting x, y, and z
Well they're doing it.

The difference between the kernel alone is a good justification, let alone the rest of the system components.

You faggots need a second post or an extended OP that answers the questions Jow Forums actually cares about without marketing crap. Questions like

>is it a *NIX? Is it POSIX compliant?
>what license does it use? What is open? Are there copyleft components?
>will it have the same firmware issues as Android meaning it's gonna devolve into glorified abandonware after a few updates?
>what promises does it make about security?
>will Google products (TM) have special integration?
>will it be more configurable out of the box than standard Android phones?

Attached: 1521961894541.jpg (1280x1426, 183K)

>Well it won't replace Linux on the server side.
No reason to jump to conclusion now, it's not even finished yet. There's nothing special about Linux when it comes to servers. Look at how quickly companies have migrated Unix in the past, from BSD to SUN, back to BSD, to Linux, sometimes Azure.

Whole divisions can change in only a few years, total conversion in as low as 5.

I'll deal with the replies after a quick afternoon stroll

Threads aren't advertisements or wiki pages, we're here to discuss the topic. If you're unfamiliar, ask or look it up, all the information is public.

It's much better looking this stuff up and asking a more specific question. For instance
>whats the advantage of a microkernel vs a monolithic?
is a much better post than
>what kernel does it use?

post a riced desktop of fucksia and i'll consider

So they can add even more botnet

You're right.

>Threads aren't advertisements or wiki pages
looking at the OP, they quite literally are. If you are going to make generals, at least provide some factual backing if you want to get people's attention. This is common knowledge.

I'd just like to interject for a moment. What you're referring to as Fuchsia, is in fact, GNU/Fuchsia, or as I've recently taken to calling it, GNU plus Fuchsia. Fuchsia is not an operating system unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX.

Many computer users run a modified version of the GNU system every day, without realizing it. Through a peculiar turn of events, the version of GNU which is widely used today is often called "Fuchsia", and many of its users are not aware that it is basically the GNU system, developed by the GNU Project.

There really is a Fuchsia, and these people are using it, but it is just a part of the system they use. Fuchsia is the kernel: the program in the system that allocates the machine's resources to the other programs that you run. The kernel is an essential part of an operating system, but useless by itself; it can only function in the context of a complete operating system. Fuchsia is normally used in combination with the GNU operating system: the whole system is basically GNU with Fuchsia added, or GNU/Fuchsia. All the so-called "Fuchsia" distributions are really distributions of GNU/Fuchsia.

Attached: rms.png (372x469, 401K)

It's a micro kernel which means it will be slower than a monolithic kernel like Linux, how much slower is yet to be seen.

It will have piss poor hardware support for a very long time if not forever, which is ok for Google and affiliates as they will only need drivers for the hardware they sell.

It's permissive which means those hardware drivers will be proprietary.

In short, it is of no interest to Linux desktop users, they might as well run OSX or Windows.

No. We're talking smartphones and IoT. Probably chromebooks. But there's literally nothing interesting in the general laptop and desktop market for Google to even bother competing.

>There's nothing special about Linux when it comes to servers
There actually is. It's cheaper and generally performs better than the competition.

>Look at how quickly companies have migrated Unix in the past
That's because commercial UNIX is extremely expensive. The base OS is expensive, the add-ons are expensive, the support is expensive, the special hardware it runs on is expensive.
And the alternatives were either Windows or potentially getting sued by AT&T, so no wonder people were migrating like crazy.

That won't happen again any time soon, though. Linux hit the sweet spot of being good enough - something that killed Plan9 in the past. And there's literally nothing so far suggesting Fuchsia can so much as match, let alone exceed Linux in performance.

There is literally nothing wrong with a FAQ section for general threads

>a micro kernel will be slower than a monolithic kernel
The overhead of inter-service communication is offset by the lack of a necessity to perform constant clean-ups and security checks. All modern software architecture is service-oriented. Stop being stuck in the 60s.
en.wikipedia.org/wiki/Service-oriented_architecture

>material design
>nice

Attached: wut pepe.jpg (951x840, 90K)

>It's permissive which means those hardware drivers will be proprietary.
Your diagnose: clinically retarded.
Linux is riddled with proprietary drivers, and it's copyleft, whereas OpenBSD has better open source hardware support.

>Using the Linux kernel was a perfectly reasonable decision in the early days of Android, but it has held Android back over the years.
Requiring that GUI applications run on their own shitty jvm was mistake.

Stop being retarded. The issue is that kernel can't trust userspace memory, therefore it has to copy the necessary regions into its own space when context-switching. That is the overhead that kills performance in microkernels, because they do several orders of magnitude more context switches. And you can't work around that in any meaningful way unless you want to end up with insecure and unstable mess.

They already fell for this meme twice

It's made by Google, what do you think?
Probably want a new OS so they can get an even deeper botnet.

The most important one:
>will it be another botnet?

But Google at least knows how to write software.
My body is ready for the botnet OS.

>hardware support
You do know that Google makes its own hardware, including chips and routers? Yes?

Technically incorrect. You are an ignoramus and you shouldn't have outspoken uninformed opinions on subjects you haven't studied.
>A deeper analysis shows that the three points— user-kernel-mode switches, address-space switches, and memory penalties—are not the real problems; the hardware-inherited costs of mode and address-space switching are only 3%–7% of the measured costs.
Now go away.

Attached: Figure4.png (1291x618, 87K)

Did you even finish reading the sentence?
>which is ok for Google and affiliates as they will only need drivers for the hardware they sell.

They want to get rid of the GPL license. That's the #1 reason. Not sure why no one has mentioned this yet

>It will have piss poor hardware support for a very long time if not forever
>hardware drivers will be proprietary
ARM Linux has these same problems.

Stop shilling this shit, for fucks sake. No one gives a fuck about your shiny new botnet.

Attached: kys.jpg (354x423, 16K)

>But Google at least knows how to write software.
You don't know much about software project do you?
You can have the best coders on the planet and still end up with a massive failure because your project management sucks. And Google's management sucks the most of everything I've seen.
Just remember, this is the company that started with the popular sort-of-open Google Talk messaging service and then killed it just because they could and replaced it with several different unsuccessful proprietary failures in a row. The last of which, Google Allo, got shitcanned this month.
And that's just the tip of the iceberg. Google's management fucks up almost everything.

If by "GPL license" you mean poorly-architected and barely-documented legacy code, then yeah.

You don't know what you're talking about.
The context switches themselves can be as fast as they want to, but that's a red herring. The actual overhead that shows up in practice (and not in loaded benchmarks) comes from the memory copying when doing practical things such as syscalls. In a monolithic kernel you just have to do it once because you only pass the userspace/kernel barrier once. In a microkernel, it's a lot more.
But of course you wouldn't know about that because you don't know shit about kernel design. You're just here repeating some academic papers that glance over the real issues and concentrate on very specific benchmarks because that's the only thing that makes microkernels look good.

>The overhead of inter-service communication is offset by the lack of a necessity to perform constant clean-ups and security checks.

You don't understand what you are talking about, what are these security checks, cleanups that are not needed in micro kernels ?

There is ONE actual advantage to micro kernels, which is that if any subsystem outside of the kernel one crashes, they can at least in theory be restarted and won't crash the rest of the system.

But the cost is in performance, there is no magic which removes the overhead of all that context switching and message passing, it will ALWAYS be slower than a monolithic kernel with the same level of optimization.

Minix, HOPES to reach only 20% slower than monolithic kernels. Now those 20% would be a necessary sacrifice if monolithic kernel's like Linux were crash-prone, but they're not, instead they are remarkably stable AND much more performant, hence micro-kernels being regulated to niche markets like real-time.

>Linux is riddled with proprietary drivers, and it's copyleft, whereas OpenBSD has better open source hardware support.

Kek, Linux comes with the best hardware support out-of-the-box (as in FULLY OPEN SOURCE) of all systems in the world. OpenBSD has nowhere near the hardware support Linux has, and a lot if not most of what they have were PORTED from Linux, you fucking loser.

Cool ad m8

Attached: Report.png (666x462, 247K)

>>is it a *NIX? Is it POSIX compliant?
Fuchsia is not a *NIX, but, similarly to BeOS and Haiku, is partially posix compliant and ships with the dash shell and musl c library.

>>what license does it use? Are there copyleft components?
A mixture of mostly BSD, MIT and Apache.
What is open?
The entire OS is currently open.
>>Are there copyleft components?
Vim is included, and it's copyleft I believe.

>yet another daily jewgle shill thread
how much does this pay?

I am skeptical about the future of Fuchsia.

When developers begin their career, they usually start by working on existing projects, fixing bugs, assisting in new projects, then eventually get entrusted with designing their own projects from scratch.

From the current state of affairs, it seems, that Google either does not have competent kernel programmers or does not employ them where it matters. Currently their primary OS is Android, and they aren't doing jack to fix it's flaws. There have been some (superficial) SEAndroid patching, but no work at all on other fronts. If Google can't even fix flaws in Linux kernel, how do they expect to maintain their own OS? They didn't even allocate resources for libc development for a long time (after initial Android purchase and until Crystax patches were incorporated). I don't believe, that they have ability to produce a competitive kernel.

Where's Fuchsia-tan?!!!!?

>that Google either does not have competent kernel programmers
Google has spent the past couple of years exclusively hiring competent programmers to build this. They have enough money to entice even the most loyal of fags.
It's where Microsoft has bled a lot of their wizard talent.

"Fuchsia" has a "dream team":

> The backgrounds of Fuchsia’s contributors are widely varied, including those from RedHat, FreeBSD, Danger, BeOS, iOS and more.

>microkernels slow
blog.darknedgy.net/technology/2016/01/01/0/

This is nuFabrics.
Stop living in 2012

!!

Attached: uwu.jpg (1020x542, 68K)

>If Google can't even fix flaws in Linux kernel
computerworld.com/article/2469087/mobile-apps/android-linux-kernel-fight-continues.html

Cute!

Attached: fuchsia-home-recent.png (1200x800, 796K)

I can't wait, looks so comfy.

google has plenty engineers devoted to working on the linux kernel. their contributions are ones that make business sense. performance/security improvements to linux have significant cost benefits at scale. google hires industry experts and dumps so much cash at them they have no need wander away.

they already maintain several OSes internally and externally, what's the challenge in writing one more? if it makes business sense to write a good OS it will be done.

nice autism, but it has zero relevance on actual technical matters
it also gets posted every time we have a microkernel thread

>they already maintain several OSes internally and externally
and they're working on another one, altOS

Google has the resources to hire best developers around, if they feel like it. What it can't control is the reception of their work on the community, especially if what they come up with isn't as open source as legally possible and not capable of running code created for UNIX platforms.

There, all excellent points to add to the OP, thank you.
>A mixture of mostly BSD, MIT and Apache.
is it just me or does this sounds even mix-and-matchier than XNU and surrounding components?
>Vim
On a peculiar side note, vim's license is more an advertisement to donate to children in uganda than it is a license, making it sillier than the WTFPL. It is however "compatible with the GPL, by an explicit conversion clause" according to the FSF.

Attached: 1511458073570.png (429x410, 61K)

They really need to change the name though. I don't like "Fuchsia". Sounds gay and hard to pronounce.

They renamed kernel from Magenta to Zircon, next they should rename the OS. Something short that sounds good.

Not this shit post again, he drags up some unavailable benchmark from 30 years ago comparing a micro kernel to a unnamed unix, it's the worst shit I've ever read.

Just do a fucking reproducable benchmark between a micro kernel and Linux, and if the micro-kernel would be anywhere near comparable in performance then you can shout it from the rooftops, which is what any micro-kernel vendor would do should they actually have such a result.

But they don't, because there aren't any. Companies are constantly looking for the best possible performance out of their hardware, which is why Linux is so dominant in everything regarding high performance computing.

As an example of how performance is key, Netflix runs everything on Linux (frontend, all video encoding, user data management) EXCEPT for the final stream delivery over the network where they use FreeBSD because their network stack is slightly faster than Linux's.

Will you be able to use different browser engines in Fuschia like Gecko for Firefox?

>is it just me or does this sounds even mix-and-matchier than XNU and surrounding components?
don't mention that evil here
XNU is the cthulhu of kernels

They might have best developers, but those developers might not necessarily work on Fuchsia/Android/mobile. And if they work there, that work currently isn't visible to public. Maybe that's why people treat Fuchsia as a joke.

Micro-kernels don't actually need to compete with monolith on fair basis — for example, it is possible to use the IPC for non-critical paths and compensate for performance degradation with shared memory (like how Binder/Cursors work in Android). Unfortunately, Binder does not appear to be actively developed, which is why I am doubtful, that Fuchsia is going in that direction. For example, it have been 10 years, and there still no support for interrupting Binder operations (and no progress whatsoever). So much for "micro-kernel", lol

I preferred colors to rocks

>Micro-kernels don't actually need to compete with monolith on fair basis — for example, it is possible to use the IPC for non-critical paths and compensate for performance degradation with shared memory...

Stop posting these fucking unsubstatiated theories, NO FUCKING MICRO KERNEL has shown any such benchmarks whatsoever.

And SHOULD THEY, then we would have abandoned micro kernels because if not for the performance penalty, there would only be benefits with micro kernels.

It's the perfect example of a beautiful solution (full separation of operating system components) which is screwed by the harshness of reality where we don't have unlimited cpu power.

But they're not rewriting anything. They're forking another kernel. It is the same they did with Gentoo for ChromeOS.

I don't get this hype. Linux was started in the 90s, sure, but that's not what we're using today. One can say the same kind of thing about Windows and its retrocompatibility mania.

Will Fuchsia be 100% open source? Can we just take the kernel and make our own userspace, giving birth to Zircon distro or however you decide to call them? I sure don't want to be stuck with an interface that Google designed, Android is enough of a disappointment.

>Just do a fucking reproducable benchmark between a micro kernel and Linux,
Context switch. Try seL4 vs Linux.
Protip: seL4 has a guaranteed worst-case execution time for that. It's around 200ns on current-ish hardware. Linux takes multiple miliseconds. That's tens of times as long.
If doing a few context switch more is what you're worried about, then keep that in mind. It'd have to be a serious amount of context switches for it to matter.

what is the point, other than NIH syndrome

I did. And did you?

You see it is not just about what they sell as in repackaging existing hardware with their own drivers but also their own hardware with their own software, some of which is not even for sale.

>if not for the performance penalty,
What performance penalty?
Linux is a spaghetti shitfest.

LK is theirs too. They're not just 'forking another kernel', but one of their own.

>Context switch.
A very popular benchmark with the microkernel crowd because it makes them look good.
Sadly for them, it's largely irrelevant because most of the overhead comes from literally everything else.

Just shut up already you fucking shill.
How often are you going to spam this shit.
NOBODY should want google to rule OS-Space as well.
It's in the best interest of everybody that the next big OS doesn't come from google.

>most of the overhead comes from literally everything else.
Such as?

Tell me more.

What's everything else? Where's your "microkernel overhead"?

>It's in the best interest of everybody that the next big OS doesn't come from google.
Who cares as long as its not proprietary

No it isn't.

> google-os
> serves more ads and permanently open mic+camera
fucking yay.

>Who cares as long as its not proprietary
The project has not even taken off and it's already a licensing clusterfuck.

Attached: tumblr_inline_p7m7t99FCB1thva1p_1280.png (1280x1184, 496K)

Yes, exactly. And this seems to be the licensing equivalent

If we take Binder as example, there is
1. Synchronization overhead
2. Cross-process authentication (surprisingly expensive)
3. Other security/sanity checks.

You can't do without sanity checks, and they take considerable amount of CPU time. Binder kernel driver itself does not check, that specific call is addressed to correct interface, but the Java code does. In case of Binder/AIDL this requires writing to Parcel the name of interface and reading that name on remote side. Doing so can easily take more space in Parcel than rest of transaction arguments.

>Who cares as long as its not proprietary
I do and so should you.
The best part about Linux isn't the OS, it's Linus.

The best part about Linux is not the kernel, it's the userland*

Just show a fucking reproducable benchmark between a performant monolithic kernel like Linux and sel4 on a heavy workload using.

Where are these benchmarks ? It would be fantastic exposure for any micro kernel, it would be their path from niche use.

Again, if not for the performance penalty of micro kernels, there would be no drawbacks, and we would have switched to them long ago.

So it's a slightly more FOSS macOS.

As stated multiple times here, kernel has to copy memory from userpace it wants to use, and microkernel traditionally do a lot more of this because of the distributed architecture.
The distributed architecture itself is a source of overhead and problems because complex things (ex. NFS) require you to communicate between several separate userspace servers. And if any of those servers needs to perform a privileged operation, it needs to perform a separate syscall for that - thus additional overhead because kernel has to copy additional memory. In contrast, you'd only have to pass the kernel/userspace barrier once in a monolithic kernel.
Another thing entirely is keeping a consistent state between the servers, which is why I'm calling it a "distributed architecture" - because it sort of is one. And it inherits all the problems specific for that particular can of worms.

All of the above arises naturally from the microkernel concept and design. It's really nothing special but people tend to glance over it because it's inconvenient.

>literally BotnetOS
no

Attached: 1510193568985.jpg (733x448, 22K)

cringe

Piece of crap like everything from Google

>it's Linus.
I'd just like to interject for a moment. The person you’re referring to as Linus, is in fact, RMS/Linus, or as I’ve recently taken to calling us, RMS plus Linus. Linus is not a programmer unto himself, but rather another human component of a fully functioning GitHub ecosystem of GNU/Linux developers.

There really is a Linus, but he is just a part of a larger collective that includes Richard M. Stallman, among others.

Linus is one programmer: he is an essential part of the team working on operating system, but useless by himself; he can only function in the context of a complete dev team.

It's really not. A good chunk of the userland is even portable to loads of other systems.
It's the kernel that's interesting.

>complex things (ex. NFS) require you to communicate between several separate userspace servers.
Microkernels excel at IPC, to a degree that makes this irrelevant. NFS is a counter-productive example, as Linux absolutely sucks at it because of its monolithic pile-of-hacks design. See Dragonfly (or even FreeBSD) for good NFS server performance. Linux for kernel panics and data corruption.
>kernel has to copy additional memory
This is simply not true. They can share memory as well as your favourite monolith can.
>In contrast, you'd only have to pass the kernel/userspace barrier once in a monolithic kernel.
That's irrelevant, because microkernel IPC is an order of magnitude faster. You'd have to pass the "barrier" a hell of a lot to be slower than e.g. Linux at context switching.
>Another thing entirely is keeping a consistent state between the servers,
Sharing of state is what Linux often does, with the complexity it introduces. Otherwise, an untenable mess of locks. In more advanced OSs (not necessarily microkernel based, such as Dragonfly), the emphasis is on actually moving activity into concurrent lockless servers, which completely sidestep the issue and, because of the contention they get rid of, scale out better.
>All of the above arises naturally from the microkernel concept and design.
Classic misunderstanding by people that lack anything beyond a superficial understanding of OS development.
Learn more:
archive.fosdem.org/2012/schedule/event/549/96_Martin_Decky-Microkernel_Overhead.pdf
blog.darknedgy.net/technology/2016/01/01/0/
dragonflybsd.org/presentations/

>partially POSIX compliant

so no, it is not.

POSIX a shit.