Hacker News new | past | comments | ask | show | jobs | submit login

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

or

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

or

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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: