We learned in 2016 that Google was working on an entirely new operating system called Fuchsia. Development continues with newfeatures and testing on a variety of form factors spotted regularly. Google has since hired 14-year Apple engineer Bill Stevenson to work on its upcoming OS, and help bring it to market.
[…]It’s not surprising why Google would want someone with that background and experience to bring up Fuchsia. In a LinkedIn post shared yesterday, Stevenson specifically notes “joining Google to help bring a new operating system called Fuchsia to market.”
That’s a serious name Google is adding to the already large Fuchsia team, and the focus on bringing the new operating system to market adds fuel to the fire that Fuchsia is definitely more than just a mere research or vanity project.
So I guess this is a thing that is going to happen, and in the fairly near term. Sigh. Fuchsia depresses me inordinately because, while I have no particular emotional attachment to Android, it was somewhere deep in its core Linux. Because Linux is GPL’d, having a vibrant Linux ecosystem gave us a bunch of almost documentation for a wide range of hardware that was never documented before. Software is lousy documentation, but it’s better than nothing at all.
Before Android we had a bunch of weird little pop up communities that lived and died with the hardware that supported them, which tended to be months rather than years. I’m thinking of things like handhelds.org that was chiefly supported by Linux on the iPaq. With Android there has been a flourishing of third party experiments that parasite on the Android ecosystem like Boot To Gecko and Sailfish, as well as even more esoteric individual projects.
But everything is going to die with Fuchsia, because it’s not like silicon vendors have had a come to Jesus moment in the past decade. They’re not joining hands round the campfire singing the Free Software Song, they’re just doing the minimum they have to do to meet the requirements of the GPL. Give them a BSD licensed kernel and they’re just going to ship closed source drivers. Turns out that freedom is actually slavery after all.
The irony is that Linux is the one with closed source drivers, not the BSD’s.
On the other hand, BSDs are used on places where the company does not want to give back their code to community and not risk using GPL software so, we have a draw here 🙂
It’s not a draw at all. You have it totally wrong.
Companies bypass the GPL obligations by using NDAs. Check the Linux kernel and the status with companies’ blobs. Read the facts, do not make assumptions.
Yea. I just took one step further with this line of thinking
– Companies bypass GPL with NDAs and they join the Linux Foundation to keep some “close relationship” with Linux steakholders, putting a curtain in this situation.
– Companies use BSDs on appliances whenever they see fit to avoid contributing back. The community keeps that “its all good, we are BSD” air but there is a bit of complaining on maillists once in a while.
Even appearing to be superiors on this matter(license/philosophy), BSDs are used on commercial appliances, and users at the maillists DO complain when there is a missing driver/feature that could have been ported by that company, that decided to keep it closed.
I also see the irony of the closed source blobs on Linux. But there is still a draw of excuses.
This kernel change will keep the situation the same with drivers so, a draw. And Google will be able to use the “GPL is bad for mobile business” as i said on my first comment. The irony of breaking GPL x The irony of justifying changing to BSD licensed software. Another draw…
Correct remarks, hadn’t thought about that.
BTW hardware vendors will never join hands round the campfire singing the Free Software Song, vendor X who has an edge in drivers (think the endless battles in PC gaming forums about who has the best drivers, AMD or NVIDIA) will never gift that advantage to vendor Y, not even in part.
Linux support for ARM SoCs may suffer when the move to Fuschia happens.
> (think the endless battles in PC gaming forums about who has the best drivers, AMD or NVIDIA)
Of course, the answer is always “they both suck!” and that the AMD ones usually (used to? I haven’t used Radeon hardware since they were ATI) bluescreen more.
Exactly. Vendor X whose driver suck less / bluescreen less will never gift that advantage to vendor Y, not even in part.
And yes, it was a big strategic mistake of Linux to allow blobs in the kernel under an exception in the license, and not adopting a stable driver interface. If they had kept the Linux kernel clean and fuly GPL there would be no need for customer kernels in ARMland.
But no… Let’s try to strongarm hardware vendors into making their drivers part of the kernel tree…
What are you talking about? You are so ignorant on the topic! LINUX HAS SO MANY BLOBS in the kernel that is not actually open source! Linux Blob policies is the reason for so many phones with closed drivers that leads to non upgradeable devices to newer versions of android! Graphic cards are not open source at all! Are you so much misinformed on the topic?
It is actually the BSD projects that SAY NO TO BLOBS!! Not Linux! Companies have signed so many NDAs with the Linux development team that sideload so much closed code to the Linux kernel that you can hardly consider it open source anymore!
The greatest efforts about open source drivers and hardware specifications are made by OpenBSD and FreeBSD teams!!! Thanks to them we have the mindset about open specifications!
Jesus, what are we going see next???
I am going for a coffee, you seriously outraged me.
> Companies have signed so many NDAs with the Linux development team that sideload so much closed code to the Linux kernel that you can hardly consider it open source anymore!
That’s quite an assertion to make, that there is closed source code in the Linux kernel. Some distros may ship blobs, but you’re saying something very different. Do you have a source for this claim?
Have you ever tried to compile a kernel? There is a specific toolset called “deblob”. Debian strives to ship open source only kernels but with those you have no modern game support…
There are many motherboard chipsets, NICs and SoC that are not supported by OSes other than Linux because there is no documentation about them! Companies like Dell and (of course) Apple.
A famous piece of hardware with blobs is the Raspberry Pi ! It’s drivers are closed! And there is a way to bypass the GPU blob, but the WiFi on the Broadcom chipset is not supported without the Linux blob… And here is the sick part of the story: it is promoted as a secure platform!
On the other hand there are platforms that are truly open sourced (like the BeagleBoards and PandaBoards by Texas Instruments, a company that gives documentation for everything).
This goes back to a cute little game of semantics that BSD people play to dodge the issue. In Linux land, a blob is a proprietary kernel module that runs on the main CPU(s). In BSD land, some of them don’t even HAVE loadable modules (looking at you, OpenBSD), and what they call blobs are on-peripheral firmwares like for Intel wifi or AMD graphics cards that in Linux are simply called “firmware”. Claiming that the BSDs don’t include these blobs is wildly dishonest because they all exist in the repos and installing said firmware is one of the first post-install tasks for most users. Claiming that the BSDs also don’t include the other kind of blobs is equally dishonest, because those BSD-based products that contain proprietary code in the kernel are gated off from release at -all- and often not branded as their original upstream project (see everything from Isilon storage arrays to the PlayStation 4), whereas the GPLv2 makes people aware of where and what Linux is.
I’d love to know where any BSD developer has claimed that they don’t include firmware blobs, and with only a few exceptions in FreeBSD like the nVidia drivers, nearly none of the drivers are what the Linux folks would call blobs.
At the time the two camps became divided in their definition of what constitute blobs, OpenBSD did in fact support loadable modules so I’m not sure what point you were trying to make by pointing out that it no longer does.
BSD products including kernel code gated off? Ever tried to build an android kernel for some random device? FML. Binary drivers kinda suck and you’re never gonna get source for many of these drivers. API churn FTL.
GPL “makes people aware of where and what Linux is”? Second clause in (for example) the “FreeBSD License:”
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
Pro Tip: Let’s not degenerate into a Linux vs BSD mess. The bigger news is how open will Fuschia be? Is this something Free Software folks (of all types) can fiddle with? Or will this be a new IOS?
It looks like you can grab the source code
https://fuchsia.googlesource.com/
https://github.com/fuchsia-mirror
and just build it
https://arstechnica.com/gadgets/2018/01/googles-fuchsia-os-on-the-pixelbook-it-works-it-actually-works/
This increases the probability that Fuchsia will become a commercially viable offering rather than remaining a research and development project.
Seamless unification of desktop and tablet user interfaces and hardened security appear to be likely benefits.
On the other hand, the use of the Linux kernel in Chrome OS meant that a team of developers well versed in Linux could contemplate putting together a version with minimal tracking from Google.
For example, NayuOS ( https://nayuos.nexedi.com/ ) based on the Chromium OS code base to provide a less tracked use experience for Chromebooks. Or, CloudReady ( https://www.neverware.com/#cloudready-introduction ), also based on the Chromium OS code base, to ease the conversion of older x86 based systems from their current MacOS X or Windows to a lightweight and more secure web experience.
It is unclear if similar projects would arise from the Fuchsia code base.