Hacker News Reader

Comment by bayindirh | Hacker News Reader

For how long?

Fuchsia is in its infancy now. A little prototype. with its stable API and other features, it smells like a "hardware-vendor friendly" (or vendor-first or oriented) platform.

It may replace Android, maybe Linux in Google's own data centers. Then, we'll have another platform like OpenSolaris. Open, but not. The primary reason I like Linux is its transparency, openness, freedoms it provides and the resulting flexibility, and I'd hate to see these freedoms are eradicated with a so-called Open platform controlled by another mega-corporation called Google.

View on HN

The biggest problem with OpenSolaris was proprietary blobs required to build it. Do you know if Fuchsia has any of those?

If it doesn't, then just fork it.

What I'm trying to say it, it'll probably end like AOSP. Downloadable, buildable, but useless without vendor or closed source add-ons/drivers.

Forking is always easy, maintaining is hard. Also, we're not sure whether things will be made harder by Google when things get mature.

I think useless is going a bit far, isn't Fire OS a fully maintained fork? I believe there are some maintained forks in China as well but I know less about those

Yeah, useless a bit too far to generalize, you're right. But, in the end, it will won't be usable by general public or software hackers (in its original definition).

I don't have any Android devices, and I don't follow its forks, derivatives or general state too closely. If you have the money and the means, you can always make a fork of an open source software and make it work for you.

To be more accurate, maybe I can say it won't be very useful for the general public, but big companies can do whatever they want since they have the money and the man-hours.

Fire OS is a fully maintained fork, but it still requires proprietary blobs to be functional. As far as I know, there are no commercially-supported Android forks that have open-source drivers outside of the kernel.

A clean cut between a free core and the adtech layer should be a welcome property. Think Chrome/Chromium, not Android/AOSP. For AOSP, our perception is dominated by all the trouble that derives from hardware vendors forcing binaries into a kernel that actively rejects them.

I don't understand. Having a stable api is also good for researchers / amateurs as well?

API and ABI stability look nice on paper, and really useful in some circumstances, however, it creates two problems, so Linus opposes it (and I take Linus' side).

First of all, it allows hardware vendors to be lazy. If a driver compiles, unless there's a grave bug in the driver, the vendor won't do anything. Because it doesn't hurt their bottom line much (nVidia has some serious bugs with their closed source driver, and they play the deaf, but that's another issue). When the API is not stable, something will change/improve inevitably, and the driver will break. A non-compiling driver is guaranteed to wake the vendor up, and maybe they'll fix some of the smaller bugs while they are at it.

Second, it hampers kernel development. You have a killer feature you want to implement, and it needs new API calls to be a first-class implementation? No, you can't do that because the API is stable, you can't change it. You need to work around it, tuck it behind more generic calls, add overheads, etc.

Fuchsia's API stability mean that a vendor can write the driver once, and send it to integrators once. Unless someone complaints enough, they won't need to touch the code. When the ABI is stable, you can just distribute the .o files, and forget all about it. The driver is working somehow, the integrator is happy, the vendor is making money. This is the dream of commercial software. They can implement once, and deprecate once and for all. Hooray!

> First of all, it allows hardware vendors to be lazy.

This completely ignores the fact that most hardware vendors have no financial incentive to make driver updates for hardware that you have no choice to replace because it's a chip embedded in your phone and they get to choose between forcing you to pay them more money for a new one _or_ spending money for no reason to update the drivers for old hardware. Breaking compatibility very demonstrably does not get mobile device vendors to ship updates, but it _does_ fuck the device owners. Let the driver that works just fine keep working just fine! Don't make a billion people suffer on old kernels because you think that a hardware vendor should do extra work to support a chip that they already made their money from just because you decided to break something that was working just fine before you made your change.

Since the lines I want to quote are too long, I'll just snip the core parts.

> ...no choice to replace because it's a chip embedded in your phone...

My comment wasn't targeted at the embedded usage scenarios only. There are professional and consumer devices (hand-vein readers, printers from certain manufacturers, high end and high-speed scanners), which advertise Linux support on their boxes and documentation, but only provide binaries and modules for some archaic Linux distributions. This situation is hurting both sides of the equation. Some of these devices are very nice, expensive devices I'd (and many would) buy, but their non-existent Linux support keeps the users away from them. Their change in attitude will not probably change the stance in the long run due to trust issues.

The problems are not only at kernel level either. Some of these devices run translation layer binaries in userspace, and these binaries are written without following the standard coding practices in Linux. As a result, an ordinary library update breaks the binary for good. Again, the manufacturer does nothing because it has no incentive to do so, and my expensive device becomes a paperweight.

> Let the driver that works just fine keep working just fine!

Coming from this perspective shall we stop all development on Linux kernel and userspace, so everything works? Why Microsoft is constantly changing driver models ever so slightly, and every manufacturer is updating the drivers about the cards and chips they've already developed and embedded on my motherboard, NIC, sound card, etc.?

> ...just because you decided to break something that was working just fine before you made your change.

While Linux kernel API is officially unstable, there's a rule in its development: if userspace breaks after a kernel patch, the problem is in the patch. Kernel changes shall not break or change userspace behavior. Hence, nothing is broken on purpose in the kernel. The evolution makes things change, and we shouldn't stop this change if we want Linux to be a cutting-edge operating system and platform.

> My comment wasn't targeted at the embedded usage scenarios only.

I know, but I think that the Linux kernel developers should update their views on the impact of ignoring the embedded scenario.

> Coming from this perspective shall we stop all development on Linux kernel and userspace, so everything works?

No. Preserve the old methods so that things that used to work keep working. Microsoft does this. Windows userspace apps from 20 years ago still work in Windows 10 today despite the system having advanced significantly since then. Windows 7 hardware drivers from 10 years ago still work in Windows 10 too. New functionality doesn't need to break old functionality.

> Why Microsoft is constantly changing driver models ever so slightly

They mostly don't. See above.

> every manufacturer is updating the drivers about the cards and chips they've already developed and embedded on my motherboard, NIC, sound card, etc.?

Bug fixes. Almost never interface changes.

> While Linux kernel API is officially unstable, there's a rule in its development: if userspace breaks after a kernel patch, the problem is in the patch.

You just said userspace. What is userspace? If I can't update my kernel because it means that my camera will stop working because I only have the one binary blob for it, then the kernel has broken _my_ userspace. But that scenario is explicitly ignored because the userspace rule doesn't apply to drivers.

The Linux kernel pushes GPL virality further than it should go by effectively mandating that one of three things must happen:

1) you give them your driver code

2) you keep doing work to re-certify and re-release your driver (but you could just mainline your driver code, hint hint!)

3) billions of people go fuck themselves

Mobile device vendors choose 3 because it makes them more money by obsoleting the devices more quickly. It's time to recognize that fact.

I'll again snip the core parts that I want to reply.

> Preserve the old methods so that things that used to work keep working... I have many old applications which compile without modification, or work without re-compilation given all the libraries are available. In Linux, most of the libraries are backwards compatible. Newer versions of the required libraries works with the said application unless the application gets the version and requires a strict version. For these libraries, the packages are always available (e.g. Spotify required libssl-1.0.0 for some time, but they updated it so it works with 1.0.{0,1,2}). Most of the low level libraries are API/ABI stable in Linux world.

> Microsoft does this. Windows userspace apps from 20 years ago still work in Windows 10 today despite the system having advanced significantly since then.

With the help of WindowsOnWindows (WoW32,WoW16), a complete embedded Windows XP image, a great hack called Compatibility Layer and other tidbits which makes things much more complicated and convoluted. Modern Windows 10 contains at least three complete Windows subsystems (or abstract installations) inside. This is hardly a good solution. You can install a complete 32 bit Linux subsystem to achieve the same thing, which is neatly called as multi arch support, and it's much simpler: a set of libraries, nothing more.

> Windows 7 hardware drivers from 10 years ago still work in Windows 10 too.

From my experience 7 to 10 compatibility is not universal. Despite having the same "foundation", 2K drivers didn't work on XP. XP drivers didn't work on Vista albeit advertised as compatible. Same for Vista to 7. 7 to 10 mostly works, and it's better than ever, but it's hardly bulletproof. Hardware vendors used this incompatibilities as an excuse to be lazy and obsolete lots of hardware. Been there, experienced that.

> Bug fixes. Almost never interface changes.

Sound card & TV tuner drivers are notorious because of the timing and direct access they required. Interface and access capability changes killed Creative's hardware EAX in XP to Vista migration IIRC. The cards are buried behind expensive API calls with the expense of latency. Most of the effects have vanished (since the card access in vanished) overnight. I had many of the Creative cards (Live, Audigy, Audigy2), and felt the hurt.

> If I can't update my kernel because it means that my camera will stop working...

Actually, I have a lot of hardware which were deserted by their manufacturers by not updating their drivers and Microsoft refusing to provide even a basic driver. Nearly all of these devices work under Linux, with better performance compared to their official drivers.

I had a printer which had a translation layer binary, but no kernel space driver. This translation layer binary is used as an intermediate CUPS filter to convert the PDF/PCL to printer's own language. The binary didn't conform to POSIX/Linux standard coding practices, and if you didn't provide the exact (old) library it wanted, it forked continuously and didn't work. So your print button was rigged as a slow death button for your PC. I can accept a binary blob, but code it right.

Similarly we have ~1000 servers at work. Some of them are ~10 years old, but they work with most modern distros without complaining. Everything is available, and stable. Even closed source drivers. I don't think the problem is the unstable API/ABI.

BTW, an interface change doesn't affect all the modules. Your module is affected if the interface you talk to changes. You only need to recompile the .o or the source since ABI is not stable due to non-stable API. This is not a real world problem from my experience with said servers.

> The Linux kernel pushes GPL virality further than it should...

I think we need that vitality, but it's another discussion topic, so I'll leave it here.

> 1) you give them your driver code

No, You can provide an .o file if you want.

> you keep doing work to re-certify and re-release your driver

Again, you can just update the .o file if the interface you talk to changes. Not a big deal if you're serious about Linux support.

> (but you could just mainline your driver code, hint hint!)

Unless you implement your magic in the driver (like a WinModem), and you didn't license closed IP from someone, you can open source your drivers. Even Broadcom open sourced their drivers. So it's not something scary if you plan it right.

> 3) billions of people go fuck themselves

The mobile vendors' choice is business related. Even if the code is open, they will obsolete it nevertheless. So, open source driver availability is not a factor here.

I also want to add some more information about this.

- AMD has re-designed its silicon to allow fully open drivers. This is a big gesture towards Linux and Free Software.

- Many high end hardware manufacturers (like Mellanox) open source their software stack (OFED, Subnet Manager) because the code is worthless as an IP without their silicon and hardware.

- Open source drivers prevent obsoletion, but driver cannot manufacture the chip itself, so it has no role on product lifecycle. Upcycling embedded hardware is not trivial for everyday user.

Reply on news.ycombinator.com