Fuchsia: Google's modular, capability-based, non-Unix operating system
fuchsia.googlesource.com
fuchsia.googlesource.com
One practical disadvantage compared to Linux is that it's not GPL, so if Google uses it to make a mainstream mobile phone operating system, other vendors won't be compelled to release their kernel sources like they are with Android today, which means a Fuchsia equivalent to LineageOS might not support as many devices.
Also, capability-based security is fine as long as there's some way for the owner of the device to acquire all capabilities. If there is not, it's fundamentally anti-user, since it's treating the user as an adversary. Since most Android devices require aftermarket modifications to get root access, I'm not too hopeful about Fuchsia. If these bullet points are anything to go by and DRM and verified boot are first-class features, it's likely that Fuchsia will have built-in mechanisms that prevent the user from copying protected video content, so it's unlikely that the average Fuchsia powered device would grant the user full privileges.
I don’t get this sentiment at all. The vast majority of users don’t know what root access is, let alone care about it.
Also, users don't care about these restrictions until they do. The user might be completely unaware that there are restrictions on what they can do with the device before they decide to install something like a system-wide ad-blocker (which are becoming more popular) or maybe an app that can download YouTube videos.
The reason most users don't care is that they don't understand what's going on: They've been programmed to believe that law ≥ morality when there exist so many painfully simple - even modern - examples where this cannot possibly be the case.
People used to buy a car with the expectation it last 20-30 years and would not think about buying a car that they had to take to the manufacturer for repairs or aftermarket upgrades, after all: You need your car to get to work, and everyone knew if there was a malfunction and the manufacturer refused to repair it under warrantee (like a broken windscreen) you could at least get a competitive best-price repair from an open market of repairmen. Without this, how could you possibly trust the purchase of a car?
Now they do, and indeed I know people who rotate cars as often as they exchange their phone for the newest version. If the manufacturer won't repair it for free, they can charge as much as they can get away with - far and above the best price -- and the only reason they can do this is because they have a technical monopoly on some secret keys used to perform updates and upgrades.
If there's a user who, given the choice, would protect a manufacturers' "right" to price-gouge them, then they're a fucking idiot.
I can't speak about all people, in all time periods, but most people in the 1960s/70s in the USA were thinking about keeping their cars for 10 years maximum. Cars were dizzyingly cheap in those days, and a highschool student could work part-time during a single summer and buy a new sports car.
To me, the only thing that has changed between now and then is the price of vehicles, not the expectation that they're disposable.
Users don't understand what a CAN bus is, but open access to CAN buses is better for anyone who needs to maintain a car.
For cars, software and generally living on this planet, the more one doesn't understand, the more they'll pay.
Opera v12 is a great example of that. There is no browser with its feature-set. In purely objective terms all other browsers are strictly inferior when it comes to usability and range of features outside the web rendering core. It also provides a number of data storage features. Now Opera ASA has given up on it, and because it's closed sourced not even small things like changing SSL ciphers can be fixed.
So millions of users were forced to switched to worse alternatives, and some were forced to manually extract their data.
The kick in the butt about this: There's a leak of the source code on the internet, but collaboration on it is nigh-impossible because any site hosting it is breaking copyright law. This despite Opera v12, with the Presto engine, being 100% and entirely abandoned and with the sale of the "Opera Browser" to a chinese malware company, there not even being any way for the public to know who actually owns the rights to v12.
If Verizon wants to sell you a device with GPS but rent you the feature for 10 bucks a month.
If the government wants the privilege of censorship unobstructed by the inherent technical impossibility of controlling every aspect of user owned devices.
If you want to avoid planned obsolescence and use your device longer than 18 months.
If you are a keirig owner if you want to buy the coffee of your choosing.
If you want to refill your ink cartridges.
Any obnoxious thing that people would trivially bypass if they had full control of their own stuff.
The fact that you an otherwise intelligent individual could ask such a staggeringly ridiculous question is why the free market is a worthless answer to any of the above.
There is a reason standards are developed by knowledgable parties rather than hoping that buyers will navigate the quagmire of complicated topics to demand sanity from merchants.
Nit: it's not a free market if the buyer doesn't understand the transaction.
What we've seen, especially in the latter half of the 20th century and afterwards, is companies using the complexity of the law to create transactions in which the buyer thinks they're getting a good deal, but in fact they're getting screwed over by lawyers. That's not a free market. That's using government complexity as a club to beat senseless consumers when they don't do things the way you expect them to. It's a form of rent-seeking using the regulatory state.
It's important to understand what it is, otherwise you aren't able to propose any reasonable solutions. For example, throwing even more complexity at the problem in an effort to protect consumers would just make matters worse.
I'm in favor of your approach, just wanted to point out that 1) it's incomplete, and 2) without an understanding of root causes we'll still be in the same spot 20 years from now
Is a minority of users not users? By this logical, we can remove all accessibility features, because disabled users are only a minority.
I would disagree. With the introduction of Android 8 and Project Treble, as long as the userspace OS changes adhere to the HAL contracts, updating to a new OS version should will be considerably easier because there is no need to modify the kernel.
According to the Project Treble lead you can even place AOSP userspace on any Project Treble phone and it would work.
In the spirit of HN though this comment basically guarantees its success, right?
Could expand on where it suffers? I've been playing around with Rust in the embedded space (nothing serious at all); I find it to be as elegant in a nonstd situation as it is in standard high level app development.
> and suffers from a lot of the same classes of problems C++ does,
What are those classes of problems? C++ never offered a safe alternative to C, but did offer some eases of use and stronger typing over C.
Rust on the other hand has a huge amount to offer over C. At no point in my Rust work do I ever wish I was working with C, quite the contrary. But I like strongly typed languages, Rust is definitely not for those that dislike types.
By "the embedded space" do you mean "devices running Linux with Rust in userspace?" Because that's much higher level than what I'm talking about, and has very different design concerns from those of a general purpose operating system.
My main beef with Rust for low level development is that Rust is way more complicated than it should be. IMO for serious low level programming Rust should have 1/10th the featureset. It also has issues dealing with the weird data structures that tend to come up in low level contexts in my experience. Rust also has the shiny fad status working against it IMO. If, say, 5% of C hackers understand low level programming and/or kernel hacking, then maybe 0.5% of Rust hackers do (if that).
>What are those classes of problems? C++ never offered a safe alternative to C, but did offer some eases of use and stronger typing over C.
It comes back to complexity and typing. There's nothing wrong with strongly typed languages (of which C is a member), but I strongly dislike object oriented languages and paradigms. Especially in low level contexts it's like forcing a square peg into a round hole. Other features C++ brings to the table like operator overloading and templates are antifeatures, doubly so in a kernel hacking context. Many of the same patterns of unnecessary complexity introduced by C++ are also present in Rust.
C is boring, but it's also transparent and straightforward. Ergonomics takes a backseat to simplicity in C, which is a compromise I'd take any day.
Rust itself is so inherently different from other a language like C that it takes a long time to truly understanding lifetimes and the borrow checker to the point where you are actually making use of the languages features.
The straightforwardness of C is really where it shines, and for me at least Rusts biggest upside is also its biggest downside, because learning to write good Rust is not an easy process.
No, I mean TockOS with the Hail dev board: https://www.tockos.org/blog/2017/introducing-hail/
> Rust is way more complicated than it should be
People often make this statement, but I don't know exactly what it means. The type system is great for writing finite state machines, which I'm finding to be a nice quality for the toy programs I've written on Tock.
> Rust also has the shiny fad status working against it IMO.
Rust is 2 years into it's stable life. It's young, will it ever exceed the number of lines written than C or C++, almost definitely not, but I wouldn't dismiss it off-hand because people like it, there might be a good reason for that.
> If, say, 5% of C hackers understand low level programming and/or kernel hacking, then maybe 0.5% of Rust hackers do (if that).
I wonder about this statement. I've noticed quite a large number of people in the community working with Rust in the embedded space. According to the people who responded to the Rust survey this year, https://blog.rust-lang.org/2017/09/05/Rust-2017-Survey-Resul..., it was nearly 17%.
> C is boring
I've met more undefined behavior that makes me not agree.
> and straightforward.
:/
> People often make this statement, but I don't know exactly what it means.
I can't speak for op, but you're right: people often make this statement. I'll try to explain what I might mean:
C is way more complicated than it should be.
The things we want in a language are tools that allow us to tell the computer what to do, but because people are bad at that, language design is taking us in the direction of telling the computer what we mean so it can tell us whether we're talking gibberish or not.
I don't need a type system. I don't need "warnings" about converting floats to chars: I know what I'm doing and why. I have a good idea what kind of machine code the compiler is producing, and yes: I often objdump to make sure.
If I need a FSM, I'll use erlang. If I need any kind of data processing, I'll probably use K/Q where I can. I can write some fast stuff in C where I need it. If I just need to bosh some stuff together I have perl. Maybe I want to fantasize about a DSL? It'll probably be a lisp or a forth. If I wanted a strong type system for units I want to get from some model nerds, I'll use OCaml.
I don't see the point in Rust when doing these things takes more code and runs slower, and worse:
> Rust is 2 years into it's stable life. It's young.
I got burned by Python when it was" two years into its stable life" sometime around 1.5 and again around 2.2, and so I hesitate even looking at rust unless in a decade it can still run and compile rust programs written today.
This whole "let's rewrite everything in rust" is good practice. I'm watching you guys do it, and I know afterwards you'll try to beat the performance I'm getting in other languages.
Once you're writing programs that are smaller and faster than me, then we'll probably talk.
> C: I've met more undefined behavior that makes me not agree.
I don't write C like most people, so perhaps I don't have trouble with it like most people. My C programs don't leak memory or crash, and I tend to use a belt+braces approach to security that is very difficult in languages without good multiprocess support.
No, you don't.
Regardless of your skills and seniority (I'm guessing pretty junior with this kind of hubris), there will come a time where you will make mistakes that can be caught by a good compiler. You want this compiler at your side, and the more statically typed your language is, the more robust your code will be.
> Once you're writing programs that are smaller and faster than me, then we'll probably talk
What a strange metric. Assembly language would probably meet these requirements but surely, you would not consider it.
If you check their profile their site suggests that have ~15 years of experience.
I've been programming professionally for almost thirty years at this point.
That's admittedly long enough to get some peculiar ideas about programming, but there's a certain kind of person that thinks "statically typing" is a panacea for programming mistakes -- or even that there's a single solution for anything at all...
Static typing is not perfect but it's better in all respects than dynamic typing.
... unless of course that solution is static typing.
> Static typing is not perfect but it's better in all respects than dynamic typing.
Except performance, of course: A dynamically-typed language is at the top of the STAC-M3 benchmarks for time series data processing.
Oh and defect count: Qmail has the lowest defect count of any source-available software in the last twenty years and it's written in C.
So I guess static typing is better unless you want correct code that runs quickly, which unfortunately is important to me.
Static languages are universally recognized and demonstrated as faster than dynamically typed languages, even if you claim to have found one rare exception. This is not just an opinion, it's scientific and objective fact.
But please share with us that code that runs more quickly on a dynamic language than a static language for you, I am genuinely curious (and equally curious to find out if you just made this up).
That makes sense, since your background isn't in high performance computing and you can't use google:
The first item on the list is written in an interpreted language.
> This is not just an opinion, it's scientific and objective fact.
I've just demonstrated two counterexamples, so it's clearly not "scientific and objective fact". Indeed I've never met anyone who even thought Rust would outperform an experienced C programmer in programmer speed, program runtime, and low program size.
Could I see the code? Because I'm pretty sure you can't write a fast numeric code without the knowledge of which type you will get on input. That's why fortran still rocks and we do nat have anything beyond fortran, c and c++ in the field of computation.
You're not far off.
The first trick is that even though `x` can have any type, `x[4]` and `x[5]` must have the same type. This kind of array whilst uncommon in Python is extremely common in array languages. Array languages tend to have a lot of vector operators (and so therefore are very competitive users of the AVS512 instruction set) which tend to be very fast. Programmers of array languages also tend to avoid things like loops and branches -- indeed you might enjoy http://nsl.com/ if you want to expand your mind a bit on that point.
The second trick is that an interpreter can be made very small. If you can get your entire program and the interpreter into L1 then you do not stall the CPU while your program fetches various parts of itself from memory. This is a trick languages like Fortran and C and C++ don't miss per-se, a very experienced programmer can usually identify the hotspots and optimise the hotpath for these things, but it is very time consuming to do this when your entire program is the hotpath!
Do you actually have anything to show to back up your claim? Anything at all?
Except the first paragraph:
The STAC-M3 Benchmark suite is the industry standard for testing solutions that enable high-speed analytics on time series data, such as tick-by-tick market data (aka "tick database" stacks).
I'm not going to bother any further with such an obvious troll.
Good luck dude. Wish you the best.
Because they're not on the page, so I can only conclude you made this up.
- how many instructions execute between an interrupt trigger and your vector getting executed
- if some piece of data is getting stored in text, data, or runtime space (harvard v single address spaces can make things weird)
- minimizing or not using a stack to avoid clobbering your puny memory
- other misc. things that even hardware vendors don't make easy (or sometimes possible) to find
Honestly I don't think that even C is great for these things, but I mostly blame hardware vendors/architects for this situation. They all like to roll their own standards for documentation, language interfaces, etc. Sometimes it feels like a competition to see who can come up with the worst.
So more of the "Arduino like" embedded space. That also has little to do with the design constraints of a general purpose operating system.
>People often make this statement, but I don't know exactly what it means. The type system is great for writing finite state machines, which I'm finding to be a nice quality for the toy programs I've written on Tock.
Rust gets new features daily [1]. C gets new features every decade if we're lucky.
>I wonder about this statement. I've noticed quite a large number of people in the community working with Rust in the embedded space. According to the people who responded to the Rust survey this year, https://blog.rust-lang.org/2017/09/05/Rust-2017-Survey-Resul..., it was nearly 17%.
Embedded space != kernel hacking, as I've already pointed out.
Does it not? It's the same issue around no-stdlib, stricter sense of allocated memory, etc. If it isn't something that I can extrapolate from you'll have to explain better why. It's been a while since my CS courses on operating systems.
> Rust gets new features daily [1]. C gets new features every decade if we're lucky.
Yes, this is an age thing. I'm sure in it's infancy, C was gaining features and changing rapidly. For example, C changed significantly early on it's syntax from K&R to Ansi. C compilers have to support that.
It's reasonable to say that the language isn't ready for your use, but the features that are being gained are all related to areas around ease of use of the language, making it easier to get started and lower the initial learning curve. They seem important. By the way, you linked to the RFC repo instead of the language repo: https://github.com/rust-lang/rust/commits/master. The language does have a lot of features that make it into the nightly branch, but those take a long time to bake until they're promoted to stable.
> Embedded space != kernel hacking, as I've already pointed out.
I thought we were talking about low-level programming, not explicitly Kernel hacking. Yes, Arduino and it's ilk are definitely not full OS'.
For actual Kernel hacking in Rust, there is:
- https://github.com/redox-os/redox
- https://intermezzos.github.io/book/
All of those projects seem very interesting. For Linux drivers, there was this exploratory project I saw a while back: https://github.com/tsgates/rust.ko (hasn't been touched in a while).
So people are doing it and seem to be enjoying it.
No, because a general purpose OS has to do that and effectively, securely, and performantly manage userspace access to those resources (including hardware resources, which you didn't mention). It also has to facilitate secure and performant interactions between userspace programs. Beyond kernel hacking you also have to do some serious work on userspace design, especially if you have a microkernel. This is an entirely different domain than embedded programming usually deals with.
>Yes, this is an age thing. I'm sure in it's infancy, C was gaining features and changing rapidly. For example, C changed significantly early on it's syntax from K&R to Ansi. C compilers have to support that.
Sure, but that doesn't make my argument less compelling. Rust may follow the same path but that's years out and IMO they've already gone too far.
>The language does have a lot of features that make it into the nightly branch, but those take a long time to bake until they're promoted to stable.
But not before the ecosystem runs with it and ships packages that require you to use a nightly compiler to be productive, in my experience. Not to mention that several projects still build the compiler themselves!
I have some opinions about projects like Redox but I'm out of time.
The design also seems extremely sensible and modern: Everything is namespaced and sandboxed (there's no default "/"), everything is an "object" (sounds similar to Plan 9's file descriptors), capabilities from the ground up, standard RPC between OS components (FIDL, similar to COM or XPC), built-in package management (looks like apps aren't globally installed by unpacking archives, but rather they're run directly from packages, and the process gets the archive file system mounted in its namespace), etc.
While Google seems to be aiming for phones, I wouldn't surprised if this ends up as an option on Google Cloud Platform in a few years' time.
In XNU, things like file systems, graphics and device drivers are all running in kernel mode, in the same address space as the kernel. The Windows kernel has the same design -- it's designed as a microkernel, with separate modules internally that communicate via a form of IPC, but everything is running in one process (as opposed to a real microkernel architecture where file systems etc. are userland processes).
With XNU, Apple forked Mach 3.0 and have been making a lot of changes to it over the years, even though Mach itself has progressed since then. On the other hand, XNU inherited Mach's high syscall overhead (considerably higher than Linux), and to my knowledge Apple has moved a lot of stuff into ordinary syscalls rather than Mach messages to remove this overhead.
Edit: Interestingly, around the time before Leopard, when Darwin was still a thing, there was a research project called Darbat [1] that tried to supplant parts of Mach with L4, a more modern microkernel, and actually run XNU as a userland process on top of it. Unfortunately, nothing came of that project.
[1] https://en.wikipedia.org/wiki/User-Mode_Driver_Framework [2] https://docs.microsoft.com/en-us/windows-hardware/drivers/wd...
The nice thing about Plan 9's everything-is-a-file setup is that everything has the same file-like interface. Saying everything is an object does nothing to convey any sort of standard interface.
Rob Pike replies here[1] that direct framebuffer access and networking are easy to get as new devices, although they need to be made available by the kernel. The "everything is a file" mantra doesn't fail, why would it?
In the second link, Carmack just notices that plan9 is pretty dead, and we all know it is :)
Everything is a file is how X Windows over network kind of works.
For real graphics performance that can match other systems, xshm and DRM had to be developed.
According to Google, Fuchsia is designed for:
modern phones and modern personal computers with fast processors, non-trivial amounts of ram with arbitrary peripherals doing open ended computation.
From "What is ledger?" [0]:
> Each data store is transparently synchronized across devices of its user through a [cloud provider]. Any data operations are made offline-first with no coordination with the cloud. If concurrent modifications result in a data conflict, the conflict is resolved using an app-configurable merge policy.
I'll note that although they use Firebase as the sync provider, it should be fully possible to host your own if you wish to avoid the cloud.
Keeping stuff in sync can be a huge pain sometimes, especially when you're just dealing with scattered files. I like having this functionality as part of the core system, and getting developers to handle our multi-device world.
The Ledger design docs are worth reading, they're short and approachable. Architecture [1] explains how it's implemented, and Conflict Resolution [2] covers how to handle when things go wrong.
[0] https://fuchsia.googlesource.com/ledger/#what-is-ledger
[1] https://fuchsia.googlesource.com/ledger/+/HEAD/docs/architec...
[2] https://fuchsia.googlesource.com/ledger/+/HEAD/docs/conflict...
i.e the "why" behind the design they've chosen.
For a moment there I thought you meant the X Windowing system.
That may seem quite irrelevant, but if I'd like someone to reinvent the OS, I'd like it to be people that have taken a stance in favour of stable, simple, straightforward software (the people behind Pinboard, Tarsnap; djb... just to name a few).
Even more surprisingly, Inbox (by Google) sorts everything by last message (last time I checked, which was a long time ago).
Notably, small teams can dictate priorities that don't scale at the level of tens of thousands of engineers.
but, who or what gives Google the capability to write a new OS? (e.g. are they currently employing a group of highly experienced, top-notch OS engineers? have they formed these engineers into an effective, efficient team? etc.)
These slides from the Chrome OS Internals [0] talk provide a good overview.
[0] https://events.linuxfoundation.org/sites/events/files/slides...
For example, you still cannot safely use any third-party keyboard on Android. Because Google refuses to give users a way to block internet access for individual apps, and third-party keyboards by definition can read out your passwords and everything you type.
Would just as well be helpful for all kinds of other apps. I'd be much less concerned about giving my camera app permission to take pictures at any point in time, if I knew that it can't actually upload those to anywhere. But I can't. I have to blindly trust my camera app for no reason other than Google not wanting to give up potential ad revenue.
i guess Google's Fuchsia push is motivated by some other, internal concerns.
When you look at the Fuchsia OS repositories in Github and select these by language the overwhelming bulk are C++. Regarding the languages you cite: there are some non-trivial parts in Go; the Fuchsia package manager, for instance. There are several bindings to certain key parts of the OS provided for Rust, but no actual Rust components that I can see. Python is used for some build and packaging utility type stuff. Kotlin is provided with one binding library with four whole commits.
Regarding two others mentioned in wikipedia; Dart is actually more prominent than Go, Python, Rust and Kotlin combined. C has lots of binding libraries, but only a pair of boot loaders appear to be core components, plus a fortune stub.
[0] https://github.com/fuchsia-mirror?utf8=%E2%9C%93&q=&type=sou...
To name a few: UNICOS, NeXTStep, HP-UX, RSTS, ULTRIX, VMS, AIX, SunOS, Solaris, IRIX, A/UX, MacOS, ProDOS, Amiga OS.
They were the first to do push based email and IM in a context outside of business AFAIK.
When the iPhone was announced in 2007, they realized that on-screen keyboards and multi-touch control were the future, so they did a complete redesign, moving to an interface similar to the iPhone. Here's a quote from one of their engineers talking about the iPhone announcement:
“As a consumer I was blown away. I wanted [an iPhone] immediately. But as a Google engineer I thought ‘We’re going to have to start over’” Chris DeSalvo said. “What we had suddenly looked so… nineties. It’s just one of those things that are obvious when you see it.”
[Every time this story is told, I like to remind - note how fast Google were able to pivot / adapt when Microsoft with their crazy resources and Engineering might took way longer. (Even beyond that MS had to change the way apps were developed for WP.) Fact is Google/Danger/Android were in a fundamentally good position mobile OS design wise way before the iPhone. After the iPhone - they looked at the possibilities of multi touch soft keyboard UI and were able to get there and surpass fairly fast.]
But even adjusting for that it took MS 3-4 years after the iPhone to just get Windows Phone 7 out, and that was also clearly a rushed release, because they had to throw everything out for Windows Phone 8.
I believe after rage from Jobs they left out multitouch zooming at first and did something double tap based, even though MS had done it before Apple (without capacitive) and Minority Report has shown it.
Not having to deal with Linux's refusal of maintaining a stable driver API and ABI for a start. The number one reason that stops Android from getting updates on smartphones is that hardware manufacturers don't want the burden of constantly making small changes to their proprietary drivers to follow new linux kernel changes, something that they don't have to worry about when they make drivers for, say, Windows PCs.
Even Google's own phones, like the Nexus and Pixel, are stuck because of this. They receive updates faster than non-Google phones, but they do not receive more than 2 years of feature updates (with an additional year of security updates courtesy of Google backporting fixes from newer android builds to the older kernel).
Fuchsia is not going to be burdened by Linux kernel dev policies of constantly breaking APIs and their requirement for driver developers to open source their stuff, obey the kernel coding preferences (like when they rejected AMD's driver because of the HAL) to get them mainlined so that they can finally be kept in a maintained state.
And as a result, its drivers will be far lower quality and much less stable, and the system as a whole will pay the complexity cost of working around the awful code that hardware vendors churn out.
I don't buy it. Windows provides stable driver ABIs and works just fine. A lot of the changes to the Linux driver API are gratuitous, and isolating driver development from the whims of the core won't actually hurt.
If anything, a stable ABI will help, since a smaller, well-defined boundary between the kernel core and drivers allows for things like Vulkan-like validation layers, better debugging, better sandboxing, and even transparent thunking to userspace.
Will some drivers be shitty? Of course. But many drivers won't be, and drivers will be less shitty overall when they can spend more time on being good drivers and less time dealing with GFP_FOOBAR becoming GFP_BARFOO.
Conventional wisdom is that backward binary compatibility i some huge unreasonable burden. This conventional wisdom is wrong; if anything, maintaining a stable ABI imposes some discipline that focuses development effort and that forces you to modularize your system.
Windows also has a more robust architecture where it matters, like the fact that a GPU driver crash doesn't kill the user session (windows can reload that subsystem while keeping the user session running since Vista), whereas it can either kill Xorg or just outright freeze the system on linux. A very useful way to architect the OS, although I've only experienced it on Vista and had more stable GPU drivers from 7 onward.
Depends on the driver, but often they are buggy and will never be updated for the life of a device. Once a device has been sold the manufacturer doesn't care about support. Most linux CVE's are in drivers, imagine how many are lurking in the binary blobs of random third parties?
That's why we should sandbox drivers as much as possible! I'm a big fan of punting a lot of driver work to userspace. How are we supposed to do that if drivers are allowed to use the entire Linux kernel internal API and do whatever they want? How can we possibly isolate a driver that thinks it has the right to take mmap_sem and twiddle PTE bits?
The key new "feature" of Fuschia is that its stable ABI makes closed-source drivers easier to write in the short term, relative to Linux. As a result, the vast majority of Fuschia drivers will be closed-source. Don't you agree?
I believe supporting a stable API and closed-source drivers will result in a technically inferior, more complex, less stable kernel. The Linux model of including all the drivers in a single open source codebase, where the drivers can be refactored and improved along with the rest of the kernel, is a genuinely superior way to develop a kernel, which produces a genuinely technically superior product. I just hope Google realizes this before they sink too many millions into Fuschia.
Anyway, what I said is that sandboxing isn't a substitute for open-sourcing. They are complements, not substitutes.
FUD. L4 is the most widely deployed kernel in the world.
> Anyway, what I said is that sandboxing isn't a substitute for open-sourcing.
Given reality, something must substitute for open source drivers. Sandboxing is certainly the obvious choice.
Linux is quite real, I assure you.
[1] https://developer.microsoft.com/en-us/windows/hardware/downl...
I strongly disagree with this statement. Windows is a buggy mess on all levels from GUI down to kernel. It is a consensus of technically enlightened people
Just thinking of how painful taking a dependency on guava can be makes me think this claim is satire. :(
If it wasn't in the Java ecosystem, it might not feel weird. But the Java community had maintained backwards compatibility for a long long time. Guava promises, what, a year?
And for internal use, that is fine. I have seen some poor sods introduce it as a dependency of theirs, which can lead to frustrating upgrade cycles.
Edit to add: the Jakarta libraries are also fairly well designed. To the point that most things in guava were already there.
If their main point was to get rid of GPL in kernel, and low level userspace, their main point is bad.
when will google toilet arrive ?
trust them for everything
Google has not proven themselves to be a developer/enthusiast friendly company. It feels like they look down on the rest of the world while locking systems behind restrictive(cumbersome) APIs to protect the unenlightened from themselves. Maybe that design philosophy is okay for services/apps but it has no place at the system level IMO.
Who knows maybe the fuchsia team doesn't share that philosophy, but I doubt it.