"Google discovered a hose that money poured out of. It's called 'online advertising'. All that we do now is find ways to make that hose go faster, and desperately search for another hose."
Why does Google develop 3+ different OS's? In case one of them is a money hose. Why has Google created thousands of products, only to cancel most of them once people fell in love? Because they decided that they weren't money hoses.
There’s one other thing Google does a lot of: try to foresee and actively forestall how someone else might cut-off or divert the flow to the existing hose. While both Chrome and Android evolved in directions that explored potential new hoses, they were clearly both initially directed at protecting the existing hose from being choked off or diverted by monopolies on the client side; Android was purchased and engineered to prevent Apple gaining the kind of dominance in mobile to do that, Chrome and Chrome OS against the desktop Windows monopoly and IE.
Google+ was deployed against Facebook and abandoned once it was clear that Facebook’s position, while making it something of a competitor for ad dollars, wasn’t, even without a competitive Google alternative, an existential threat to Google’s money hose.
In practice, poor development practices and incompetent product management has left some bits hard to change. The search provider used to be hardcoded with no way for the user to override it. That only changed when some early Android phones began shipping with Bing as the default. To this day, it is impossible to allow any non-system app store to update apps in the background. This hasn't changed only because Amazon, Samsung, and many other OEMs failed to get developer traction with their own app stores. Now that there are antitrust rumblings, Google has hinted they will finally fix this, but once again, this isn't a threat to the core Android strategy of removing gatekeepers.
https://venturebeat.com/2008/08/07/first-android-phones-push...
This has two logistical consequences: 1 - it's more valuable to launch a new product that it is to successfully maintain/grow a current one. 2 - the person running these new projects tends to get promoted away, leaving it rudderless.
Google could change all this overnight by restructuring what these review boards prioritize.
This is very stale information at this point. Product launches are now pretty heavily gated, and promotion criteria are far less based on launches than on overall impact, including but not limited to improving/maintaining products.
(Googler but interpretation is my own)
(Also a Googler.)
If you don't believe it, try selecting 10 of their supposedly killed products at random. Had you honestly heard of them ever before? Do they look like something that would have had a significant user base? Hell, do they even look like they were actual products?
So, two things:
1) Changing culture is really hard, especially at a company the size of Google, and
2) Even if they could change the culture, it's possible they simply don't care or they believe the benefits outweigh the cost.
Always building new infrastructure, and not maintaining the existing one.
"Zircon is the core platform that powers Fuchsia. Zircon is composed of a kernel (source in /zircon/kernel) as well as a small set of userspace services, drivers, and libraries (source in /zircon/system/) necessary for the system to boot, talk to hardware, load userspace processes and run them, etc. Fuchsia builds a much larger OS on top of this foundation."
- Fuchsia Docs, https://fuchsia.dev/fuchsia-src/concepts/kernel
Sometimes they stumble upon something another PA needs, but often it just ends up as a patent or research paper.
Searching for sources of income ?
It seems online advertising has a strong network effect[1], where website owners use Google ads because that's where most advertisers are and advertisers use Google ads because it has most reach (and therefore tracking). This naturally creates a monopoly, just like with Facebook, twitter, LinkedIn, AirBnB, Uber etc.
In 15 years, we'll either say "Fuchsia was a brilliant move, I'm so glad my home runs on that OS" or we'll say "Remember Fuchsia? lol".
Here's what I mean. Acquisitions by Google in 2005: Reqwireless (mobile ads, merged with google analytics); Dodgeball (social networking, later Google Latitude); Akwan (Search tech); Skia (graphics library); Phatbits (Google Desktop); allPAY (???); bruNET (???); Android (cheap OS for mobile devices).
In 2005, which of these were going to change the world?
It wont. From what I understand this new OS will replace others over time. Also it is way better than existing options.
QNX appears to already be in every market where Fuchsia wants to go.
Google could have bought Blackberry and used QNX in Android 5, rolling it up to Chromebooks. Why was this not the path they chose?
I have given only very cursory look into QNX and Fuchsia/Zircon and it seems that one of the main difference is the capabilities-based architecture in Fuchsia. It's a big change in the API/conceptual model, but we'll have to see if that actually translates into a meaningful difference at the application level - e.g. whether it allows building new types of applications, or allows building meaningfully more secure/fast/reliable applications.
> For more than two years, a small and stealthy group of engineers within Google has been working on software that they hope will eventually replace Android.
https://news.ycombinator.com/item?id=19702968
> "And while Android is reaching EOL in the next 4-5 years, most of this work will be carried on in Fuchsia OS, which is set to eventually replace Android"
They're not innovating at this point. They're twiddling thumbs.
If we broke up Apple, Google, Facebook, and Amazon, then they'd be forced to fight for survival.
Struggle births innovation.
No, Fuchsia is not a pet project. Instead, it's solving a very realistic problem: building a clean driver interface, while keep it open and gain hardware vendor support.
Anyone have shipped a Linux-based embedded system (including Android smartphone) knows the pain: there are tons of ad hoc driver source files need to be manually merged/rebased against the Linux Kernel. Want to upgrade the Linux kernel from 4.x to 5.x? Good luck redoing lots of merges and rebasing. There are tons and tons of git branches floating around, crazy examples like: "Linux-4.11-some_soc_vendor-some_oem-random_device-random_project-rev-1.3". It soon becomes unmanaged and device manufactures just gave up on keeping up with OS upgrades.
Overall, the monolithic natural of Linux Kernel and its strict licensing terms made it hard to get code upstreamed back or to write properly modularized driver extensions. Even when people managed to get it work, you end up something like AMD's GPU driver takes 10% of Linux kernel [1].
The term of OS is heavily overloaded. But Fuchsia's goal is NOT to build other Android, but mainly to replace the Linux kernel.
Is it worth it? Can Google pull it off? I don't know. But it probably worth a shot.
[1] https://www.phoronix.com/scan.php?page=news_item&px=Linux-5....
Android unified vendors but simultaneously made them even lazier. It's somewhat hard to get non-android code from vendors in the past 5+ years. Which makes me very sad.
Will Fuchsia somehow convince vendors to produce better drivers? I don't see how Fuchsia makes this problem significantly easier. Shitty vendors will continue to be shitty vendors and take the easiest path to making money.
In any case, the Kernel's super power is its community, not the software itself. The LKML is vast and full of knowledge, a strange intersection of open source, research and corporate exploits.
I don't see Fuchsia replacing that anytime soon.
If drivers all had a well defined interface, the exact same driver, binary or source, can be used across any OS version, and maybe even on other OS's with the right shims.
Then you don't need driver manufacturers to all collaborate to update the OS.
It is no accident that Project Treble drivers follow a similar mikrokernel approach to Fuchsia.
On Android, after Project Treble, classical GNU/Linux drivers are considered legacy mode drivers.
https://source.android.com/devices/architecture/hal
Fuchsia is the next step.
> In 2018, we got the OS running natively on a Pixelbook. After that, the Fuchsia team stopped doing its work in the open and stripped all UI work out of the public repository.
Linux (AFAIK) still doesn't require the typical CLA paperwork or copyright assignment. The "strict licensing terms" of the Linux kernel ensures that kernel stays open. If openness is a goal of Fuschia, the GPL would not be a problem here.
If anything, Linux needs a harder license, like GPLv3 or similar, to maintain openness in a world of locked bootloaders and not-even-half-baked clone appliances with manufacturers who aren't interested in coughing up the kernel source.
Binderized HALs => HALs expressed in HAL interface definition language (HIDL) or Android interface definition language (AIDL). These HALs replace both conventional and legacy HALs used in earlier versions of Android. In a Binderized HAL, the Android framework and HALs communicate with each other using binder inter-process communication (IPC) calls. All devices launching with Android 8.0 or later must support binderized HALs only.
Taken from https://source.android.com/devices/architecture/hal-types
They treat drivers and software as a cost-center, so the software quality is typically horrible. Can't be merged, won't be merged.
Microsoft knew that, so they made sure to be ABI compatible so they could keep updating the OS.
I spent lots of time looking at released drivers for things like wifi dongles and cheap Linux sticks/tablets, and there are all sorts of horrors. The wifi cards do not fully implement scanning or ad-hoc mode. Existing ioctls are ignored or implemented wrong. Sleep is used for thread synchronization. Android device drivers hardcode specific app names and apply fixups for them, presumably to prevent crashes.
Intel has much better code, at least in wireless drivers, but to be fair their jobs is easier, because most of the logic runs in the embedded processor, and you only get the binary blob for its code.
What makes you think they want to? They want you to buy the next chip and the next and the next, not keep using the previous one with a new OS.
Do they not care about having a high quality product?
Unless hardware vendors agree to support a generic driver for each device type which can be maintained by the Linux kernel team it’s going to be a total nightmare and even then you need an easy model to extend the generic driver with a device specific one through an easy interface.
The postmarketOS folks are doing it, starting from downstream OEM Linux kernels, and the patches are being accepted on LKML. It's a lot of work because so much ARM hardware is its own weird mixture of long-supported basic IP blocks and newer stuff with its own quirks, and ARM has nothing like the plug-and-play hardware enumeration of modern x86 systems. So untangling all of this just takes a lot of time and effort. But this has nothing to do with Linux per se; it's all about the ARM system architecture itself and the SoC-based industry that has sprung up around it.
And no, running a microkernel-based system won't help at all, because any hardware that's part of the SoC can read or write arbitrary memory hence your driver can (perhaps unwittingly) subvert the very same security mechanisms you're supposedly relying on. Not to mention that some of these drivers handle, e.g. voltage regulators that will happily fry your hardware irreversibly if poked the wrong way. All of this stuff is inherently part of the trusted base of your system, so you're not going to do any better than what Linux already gives you.
How come?
Right now, the phone ecosystem isn't perfect. It's hard to update phones. Why is that? Because manufacturers don't care about long-term support. But at least you could ask them for kernel source, fix their drivers and eventually upstream everything, like postmarketos does.
Now, with a stable driver ABI and permissive license, drivers won't get released. Hardware vendors still have no incentive to support old hardware, so bugs will remain unfixed, and hardware will decay as usual... Oh, sure, maybe you'll get one more update before reaching an edge-case in some driver? I also expect manufacturers to put all kind of ugly things in the kernel if no agreement with google prevents them to do so. Cue "branded" kernels, with drivers incompatible with each other due to some extra or removed APIs. And back to square one, but with only binaries and no source this time around.
> The Fuchsia kernel is released under the following MIT-style license: /zircon/kernel/LICENSE.
> All Fuchsia user space components are released under a BSD-style license: /LICENSE or an Apache 2.0 license: https://fuchsia.googlesource.com/infra/+/main/LICENSE.
> All code that is BSD-licensed has an additional IP grant: /PATENTS.
[1] https://fuchsia.dev/fuchsia-src/contribute/governance/policy...
Where there's a demand for a particular class of device, maybe someone will create a shim? Then the kernel folks can have a debate.
Currently though, I think Linux has a big head start.
"BPF will replace the Linux kernel" - Linux kernel developer
Funny that the B in BPF stands for Berkeley, as in "BSD".
I bet it will be renamed at some point.
To paraphrase a popular saying, "the driver interface apparently has an abstraction problem, so Google created Fuchsia - and now we have two problems."
And if that sounds like it's too hard, imagine how hard it is to maintain your own kernel, and all the associated user space you now have to reinvent.
In fact, you don't even need to hard fork. You could have your own rolling tree with a stable "Android ABI" interface that vendors can write drivers against, optionally.
In any case, no company in their right mind would use this project. Google has proven repeatedly they will enforce a monopoly on their platform one way or another.
We have moved away from a world of shared libraries, filesystems, and UNIX users and permissions into a world of shared-nothing (no shared memory, no shared filesystem), capabilities, new and extremely aggressive attack vectors, and a need to compartmentalize and virtualize at more fundamental layers even if it comes at a performance penalty.
You can't retrofit a microkernel-like abstraction on top of Linux. At the same time, a lot of the features you need for a shared multi-user system are basically cruft for modern mobile, single-user systems with little use for shared resources (not saying they're not shared; it's just that you can no longer trust apps installed in the user system so expecting apps to behave nicely is out of the window).
The new wave of OSes embraces formal correctness when possible, JIT, garbage-collected application programming languages, tightly-enforced resource boundaries, deny-by-default security models, provably-safe system programming languages (Rust and whatever else will come), immutability and copy-on-write at the cost of filesystem space, and secure memory abstractions for more RAM.
So why spend time supporting features that new OSes don't need, optimizing things that are no longer priority (HDD schedulers vs no-op SSD schedulers), when for once it _is_ actually easier to start over and fixing a lot of traditional pain points?
This is absurd. Fuchsia has all of shared libraries, filesystems, users and permissions. Probably even more of those than Linux.
And while I am a fan of microkernels, I can hardly claim that have become more interesting as of lately. In fact, I would even claim they have become even less interesting, since people are now taking seriously for some reason all the side channel attacks that practically make hardware-enforced privilege separation useless.
That's just not true. A "single-user" system running multiple "apps" where each app is actually endowed with its own user-like privileges is just a shared multi-user system by another name. There's no reason not to reuse the existing infrastructure, if perhaps with some tweaks.
To this date we still find bugs in sudo, interactive shells, weird env var interactions from su and inheriting variables. The Unix permissions system is complicated yet insufficient for protecting systems. There are multiple, orthogonal machineries for isolation (jails, chroot, namespaces,SELinux thingies, setuid and sticky bits) and they all interact in horrendous ways that leave huge security gaps.
Just reconsidering their use cases and redoing al lot of that having learned the lessons of the past twenty years is a huge advance.
In particular, one of the key design goals appears to be a heavy use of a capabilities-enabled handle-based API, even for more conventional syscalls (e.g., mmap). One of the benefits of this approach is that it simplifies a lot more cross-process management stuff; you can inspect (or edit!) another process's memory maps, for example, with the same system call that a process would use to edit its own. It would also enable something like CreateRemoteThread; it would definitely be far easier to write a debugger for Fuchsia than it is for Linux.
Right now your choices are a Realtime OS or Linux. Realtime OS don't support making GUIs and Linux has a lot of foot-guns.
Normally, updates to an appliance are one binary blob, this looks to support all of the various pieces having their own blob, and allow the OS to be updated independently from the application binaries, so security updates can happen without the appliance vendor needing to do anything.
My three favorite GUI operating systems, putting aside software support, are iOS, BeOS, and... Photon on QNX.
Of course, Apple is hard at work on iOS, but we don't know what sort of under the cover innovations that might good.
So. I'm glad to see something new.
Are you talking about Linux, or Android specifically? Either way, I don't really agree that there's "little" going on there.
Perhaps it is a corporate wide move to stop contributing to Linux. Or perhaps they plan on displacing Linux from the computing world.
As the longer-payoff/higher-risk companion to Chrome OS as the longer-payoff/higher-risk companion to Android, in a nested generalization of the Poseidon-and-Polaris strategy discussed as a model (among other places) in Mary and Tom Poppendieck’s Implementing Lean Software Development.
It’s kind of a go-to strategy for Google in important markets; when you are essentially made of more money than you can figure out ways to spend, internal diversification so that you literally don’t make the choice between the immediately useful but maybe future-limited approach and the longer-time-to-payoff, higher-risk approach less tied to what is currently optimal makes a lot of sense.
Their main issue with this is that OEMs like Samsung probably are not in any hurry whatsoever to jump on board and be even more dependent on Google. Without OEMs, app developers will drag their heels as well and Google is forced to maintain Android and not do a half-assed job of it. At this point Google has Android in cars, tvs, on phones, etc. Killing that would be suicidal; Google needs users interacting with their ads.
If they botch the Fuchsia launch somehow, they'd have more OEMs taking things in their own hands and cutting loose from Google and forking Android (like Amazon and Huawei already did). They clearly are not ready to pull the plug on Fuchsia just yet but at this point it's a more than likely outcome. IMHO, they should just rip off the band-aid and move on. Most of what is wrong with Android is fixable.
It’s certainly the best way to immediately get it a whole lot of real world use and feedback with basically zero sales effort, and its economical since it lets them transfer resources allocation from supporting a dead-end effort to a live one.
> A bold move would have been to put this on the next Pixel.
“Bold” is sexy, but not the same as smart long-term strategy in many cases.
That seems like a good thing to me. Personally I'm not very interested in an OS that's 'bold', I want an OS that's stable and well tested and releasing slowly on a limited set of devices seems a good way of doing that.
Which will delay the next Pixel at least several years while causing a unprecedented level of fragmentation in the Android ecosystem? BTW, I don't expect this kind of experimental projects can live without reaching any milestones. Replacing Android with Fuchsia is just not a feasible option at this moment.
It would be easier to do if you can target one hardware platform that does not change so that you don't have to also shift gears. If you're building the Great Pyramid, you don't want to also move it to a new construction site when it's half-completed.
Launching on hardware that was already released could mean they gave themselves that time. By the time they're finished (now), the hardware is old.
That is how you know Apple mean business.
And this is how you know fucsia/google will not.
Several years ago [0], the same ones here were calling Fuchsia dead since 2016 - 2018 and theoretically today it should already have died. Today Google has surprised the skeptics here and just released Fuchsia 1.0 on a real device (earlier than expected) and now you're already calling it dead again?
This whole thread sounds like a Linux meltdown club to me. In fact, Google is taking / controlling Fuchsia in the same direction as to what Apple has always done with iOS / macOS and its own silicon.
Perhaps when this decade ends, you will be looking at this comment (and this one [1]) via a phone running Fuchsia.
Apple quietly ramped it up year over year; at its initial release, it was just another "me too" phone ARM chip, but as they built it, after a few years they had their own chip design team and were no longer just popping in generic ARM Cortex designs. Then it quietly got 2, then 3x faster than the other phones on the market. Finally it reached full parity with common-market intel chips; apple made sure their "intel on arm" emulator was working well.
They still didn't release it! They waited a couple more years - until it was so fast that even emulated, it would be comparable with a brand new low-end intel machine, and then, finally, they branded it as the M1 and released it.
---
Google's strategy seems to be playing out really similarly. Put it out in the wild in some devices where they won't get flak for the usual teething problems. Work all of those out, and then, once it's pretty robust, make the big confident "sexy play" to deploy it on an android phone.
I have no idea why do you think M1 is such a green field effort when it obviously shares so much of it's design with A series SoCs you've been seeing in your favorite iDevice.
If Google would chose to launch Fuchsia as a base of next Android and force all OEMs on it, that would mean people managing release should be fired, as that's not how you stage major changes.
This not make much sense, but if Google launched it in his own, then at least some OEMs could go along (supposing Fucsia is good, I don't know which could their selling point)
This is a tragedy for Free Software. The Linux kernel (and specifically its GPL nature) is the best thing that has ever happened to Free Software drivers and embedded systems. The only reason that companies release open source drivers for their products is because they are legally required to in order integrate with the Linux kernel. Clearly Google wants to move away from this world.
I will mourn the day that a non-copyleft kernel supplants Linux and our only reason for free software hardware support comes to and end.
First, there are thriving non-copyleft driver projects, like mesa. No copyleft forces Intel to contribute to it. No copyleft forces AMD.
Second, even in Linux, many drivers aren't maintained by their vendors, but third parties. I think that an upstream driver is generally easier to deal with for most parties, so most parties would prefer it. If fuchsia is indeed as modular as it promises to be, users can swap out those drivers, at least in custom ROMs. Android custom ROMs already copy over proprietary drivers from the native OS upon installation.
Third, the GCC compiler has artificially restricted the ability to use it as a backend for third party languages, which led to many projects choosing LLVM instead. These projects now contribute to LLVM's success. Yes, some extensions to LLVM are proprietary. Still many companies contribute to LLVM directly.
Fourth, legal action doesn't turn a company into a good citizen. They might release the source code in the end but they become extremely hostile to free software projects coming forward, because suddenly the legal department got involved. Those employees who share the cause can't freely talk on mailing lists any more because all mails to the project first require approval by a company lawyer. Etc. The released source code might be unusable anyways because it's done to a fork of an outdated version of the kernel.
This is not entirely true. Mainline Linux has a longstanding policy of not including kernel-side graphics support in the officially-released tree unless it can be used with a totally Free userspace. So Mesa is, to some extent, piggybacking on incentives that have been established as part of the GPL'd Linux kernel.
Looking at the pleothora of BSD/Apache/MIT OSes appearing for embeeded devices it is clear what the future of Linux will become, when the generation that gave birth to it is gone.
I would be willing to accept some closed source drivers if it meant Linux actually worked reliably on most modern hardware (no it really doesn't).
Because Android is not GPL.
Google owns the software, so manufacturers really only make money from the device sales, and bundled spyware.
For most people, the only problem using a five year old phone today is the degraded battery. Almost all software is backwards compatible with the old operating systems and nobody simply outside IT cares about kernel updates. Journalists, human rights activists and American refugees like Snowden should fear kernel exploits, your average Joe is pretty unlikely to actually get infected. The massive segregation of Android devices is actually a good thing in this scenario, because you need to prepare your exploits for whole ranges of devices and several versions software versions, making "the Android botnet that ends all Android botnets" incredibly hard to build.
The Android privacy nightmare is all Google being built around spying; the security nightmare is mostly due to brands like Samsung not releasing timely updates, not necessarily because Broadcom and Qualcom don't build patches.
With medium to high end Samsung devices now reaching four years of Android security updates, the entire field is slowly becoming much better. The cheaper, low-end devices lag behind, but it figures that people who cannot afford a $300 phone can't pay for software support and the profit margins become razor thin the cheaper the phone gets. Five years of software updates for a $90 phone just isn't realistic.
This whole situation is why I lament Windows Phone's failure. Microsoft had the right idea, which carriers hated, that the operating system should be independent of the rest of the device. Carriers wanted to force their ugly branding everywhere and fought hard against MS, who themselves bumbled and failed spectacularly by breaking backwards compatibility with every major Windows Phone release, and the entire project was doomed to fail.
Android could have been similar to Linux; a Google-supported core repository with vendor packages for drivers, updatable in the same way Debian is. Nobody outside the hacker community seems interested in this approach, but it could have been.
This allows device vendors to use fuschia without releasing device specific software to the community resulting in further degraded software freedom.
Also, the reason so much hardware doesn't have drivers for Linux until after many years, when it has been reverse-engineered.
So, it is both an advantage, and a hindrance.
Darwin might be knocking. Evolve or die.
(And its a bit weird that the Linux kernel is so centralized with a cabal lead mostly by one dude who yells at everyone on the planet about their shitty driver code quality. If you're at all Libertarian or libertarian, that should probably bug you a bit that Free Software picked that as the ideal model.)
Eventually the parameters of the world and of user needs shift far enough from the original design that it's less expensive to develop something new than to adapt the old thing. Sometimes it's impossible to adapt the old thing: for practical purposes, no amount of work will make C secure.
EDIT: Apparently Fuschia uses C and C++, and uses them exclusively in the kernel (if I understand correctly), and Rust and Dart are permitted for some uses, if this document is up-to-date: https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/d...
It's an impressive run, but the ground has shifted, slowly, under our feet, and now Unix/Linux are no longer a good fit. Let's not be conservative; let's do what our smarter predecessors did and embrace change.
Fuschia is free and open source, per other comments in this thread. If that's true, let's be very thankful that the successor to Unix, if that's what Fuschia becomes, is FOSS. If Google put a proprietary OS on its phones, etc., even if they didn't charge for it, they'd have a lot of market power and they'd be competing with a 50 year old OS. It could be a terrible blow to FOSS.
Also the multitude of companies contributing together to the Linux kernel are often direct competitors. Yet due to the GPL all their contributions are available to everyone else - so even though you are technically helping your competition, they have to do the same thing for you.
With permissive license, you competition can take the code and run with it, never contributing anything back, kinda like how Sony did in the example above.
Unix is still a good fit for a kernel; e.g. it is used by Apple. The stuff built on top of the kernel (UI, etc.) can change, of course.
The POSIX APIs are not a good basis for designing a kernel. There are plenty of areas where it's widely agreed that the APIs are fundamentally utter garbage: POSIX signals, filesystem ACLs, async I/O, select, IPC. Arguably even some of the more less garbage APIs (e.g., regular filesystem calls) are extremely detrimental towards writing good software--imagine if we had filesystem APIs based on semantics such as "atomic file write" or "append-only files" (that guaranteed that a reader would only see old or new versions, not partly-written versions) instead of what we have now, where people attempt to recreate those APIs in userspace.
[1] https://stackoverflow.com/questions/5283032/i-o-completion-p...
Want the new networking APIs? They are exposed only to platform frameworks not POSIX.
The simple truth is that access control lists aren't up to the task of protecting systems with persistent internet connections and mobile code. A Windows or Linux machine can not ever be made secure.
A microkernel, with the smallest possible attack surface, that never trusts driver code is the way forward. I don't care if the eventual winner is Fuchsia or Genode, all I want is momentum forward out of the morass that is the current Linux/Windows world.
I look forward to trying out Fuchsia and Genode in the next few months, and porting a Forth interpreter to each.
The location of enemy radar sites was very tightly held information, as knowing what we knew could reveal means and sources of information. The actual airstrikes would eventually be known by the destruction of enemy targets. It wasn't possible at the time to have a computer system which could allow the mixing of these levels of secrecy. This meant everything had to be done by hand.
The development of Multilevel Secure systems by the Air Force in the 1970s is a direct result of that experience.
> The development of Multilevel Secure systems by the Air Force in the 1970s is a direct result of that experience.
BTW, this stuff is not just for Air Force folks, either. Multi-level security is the most principled approach around to efficiently mitigate pervasive information-disclosure vulnerabilities like Spectre. The current approach to mitigation has us flushing speculation contexts down the drain even when sensitive info is provably not at stake, which is wildly inefficient compared to what's theoretically possible.
In driver development I often see abstraction violations or very loose abstractions: news hw capabilities can't be accounted for when designing framework abstractions.
I have never done dev on windows, but I guess there is a reason why the form factor of things running windows is pretty limited. I don't see how you can have fixed interfaces in an ever evolving wold.
We all would, but that doesn't seem practical given the market dynamics explained elsewhere in this thread.
The first major open source kernel since Linux, and somewhat arguably OS X, has been released.
I was looking forward to commentary on that, not blinkered commentary complaining this exists when Android/ChromeOS do already (the error there is Android is a window manager + runtime on top of a kernel, ChromeOS is a window manager) or how performance reviews should be run.
Google has clearly and profoundly lost the confidence of the broader tech community.
In particular, Google's history of starting and cancelling random projects helps explain why people are wondering why Google is releasing Fuschia: without some understanding of their motivations, it's impossible to trust that it'll actually have any kind of extended lifespan.
For all we know, Fuschia, Android, and ChromeOS are basically the OS equivalent of Hangouts, Meet, Allo, and Duo, in which case becoming in any way reliant on it is a huge mistake.
Hangouts _is_ Meet and Allo, if it weren't for the constant migration notices leading to constant commentary no one would be the wiser, you log into Gmail and chat just like you did 10 years ago.
Duo's a featured product, people go too far and think it's "yet another video chat app", but, they're forgetting Google has to offer both FaceTime _and_ Zoom, it has consumer and corporate customers, the corporate one doesn't need stickers and hats, the consumer one doesn't need meeting links that work in a browser.
So, let's say that's true (and bluntly, after the Hangouts EOL notice I just jumped ship entirely to Signal as, frankly, I couldn't be bothered to figure out what the heck Google was doing), and that Allo and Meet--which are marketed as two different products--are somehow seamlessly integrated with the rest of the Google ecosystem so that you didn't actually need to grok the differences.
Assuming that was true, Google still completely botched the communication, and believe it or not, marketing and communication are really damn important. Google could have the greatest technology ever, but they're perceived as being unreliable, and both their words and their actions reinforce that perception.
So, maybe in this specific example, the transition wasn't as traumatic is the flat out cancellation of Reader or Plus. But in the end, the communication was so muddled that it ultimately doesn't matter because to the rest of the world outside the Google bubble it just looks like yet another example of Google being Google.
Depending on your definitions, OpenSolaris and Redox would object. And it's open sourced in a way that's designed to support making proprietary products, so you'll forgive my not really celebrating.
Android apps and Chrome can easily run on a different OS, the only problem are device drivers, but I’m sure Google is in a position to persuade manufacturers to provide drivers for their OS.
So they can cancel more products if they keep Fuchsia!
Linux also doesn’t have a stable kernel interface for drivers, which is probably a huge pain when dealing with supporting a device for many years. Either you don’t update the OS on the devices, or you have to modify all of your drivers every time you update the OS.
I guess a microkernel is pretty cool though, the academic ideal.
> netstack. Migrating netstack to another language would require a significant investment. In the fullness of time, we should migrate netstack to an approved language.
I returned mine as I had this happen to me, which completely invalidates its use as a clock.
This is an extremely crazy twist for a device that is supposed to play a star, core role in the home, and a strong indicator to me of where we are in the War Against General Purpose Computing.
There are definitely ways for 3rd parties to add to the experience, with the chatbot platform, but it's all expressed in Google's existing mold, via Actions with Google Assistant & other pre-baked systems of manipulation.
The smart home space has always been a shit show, from the radios up. It's a separate bag of rats from launching a research OS on real hardware.
It's inexcusably bad. I mean, the hardware was purpose built for this software. They should have designed the software to meet the constraints of the hardware they knew they were shipping on. And it's plugged into the wall with a big form factor so performance should be better than phones where power consumption and heat dissipation are much more constraining.
Maybe Kubernetes can be extended later to support Fuchsia nodes. It sounds really interesting to have a new target OS, with a different network and virtualization stacks.
However, I have never seen an explanation of why they need an OS written from scratch. The whole kernel and driver ecosystem, apps, development model, every single thing written from scratch. It took 6 years too for it to be productized. Why would anyone make that kind of an investment? It has to be extremely compelling. I would like to hear it from them
And... Even notorious Google couldn't completely pull their hands from Nest Secure although they decided to discontinue its production and sales. This is probably the problem they want to solve with Fuchsia. In this context, using Fuchsia is a pretty natural engineering decision. Fuchsia team can onboard its first customer while Nest team can outsource lots of its maintenance issues to a more appropriate team. I guess they already consider using Android before, but probably that's a no-go option since its support usually ends before 5 years.
Of course, Android and Chrome OS have completely different needs and environments, so I don't expect them to converge to Fuchsia in any foreseeable future. More likely scenario would be a shared ecosystem based on Play Store which enables more future strategic movements.
I could see the rest of their portfolio migrating to Fuchsia OS eventually, including both Chrome OS and Android.
*Fuchsia, sorry.
**German speakers will be fine.
Doesn't that make 5? (Potentially dumb question, I know...)
Do you have control over your device or can Google release updates and do whatever they want with it?
