Hacker News Reader

Comment by kuschku | Hacker News Reader

Windows has mostly kept a stable driver API.

And whenever they broke that API, that actually happened — suddenly updates stopped being usable by your system.

Also, be aware that ARM has nothing to enumerate devices, has no BISO or UEFI. An OS image will only ever work on a single device.

As I detailed in another comment in this thread, the issue is this collision of the Linux concept of mainlining everything, short support windows, manufacturers that can't update drivers for every microchip they sell all the time, and Google and OEMs somewhere in there.

It's always been a clusterfuck, Google didn't create it, but they sure made it worse.

View on HN

Windows driver API has been far from stable from Windows Vista. One of my computers came with Windows Vista (a 2009 Dell Pentium Dual Core - not the Core 2 Duo I referenced) and it still runs Windows 10.

Microsoft provided drivers for the standard PC hardware that was in my 2006 Core Duo Mac Mini and Windows 7 recognized all of my hardware - usb, sound, graphics, Bluetooth, Ethernet etc.

Microsoft goes out of its way to provide drivers for the most popular PC hardware. Mac OS is Unix (i.e certified by the Open Grouo) and doesn't have that problem.

Edit Rant:

But why are printer drivers still a thing? Apple introduced AirPrint for iOS 4 back in 2010 and for MacOS a few years later. I never have to worry about printer drivers when I update my OS. New printers bought in 2017 work perfectly with my 7 year old iPad without having to worry about drivers.

> But why are printer drivers still a thing? Apple introduced AirPrint for iOS 4 back in 2010 and for MacOS a few years later.

Have you looked at the unimaginable amount of crap a typical Windows printer driver forces upon you? It's not just the driver, it's usually also a stripped down license of some image editor, an "update agent" (because Windows 7 does not have an "app store" or a centralized driver distribution that does not phone home like Windows Update does and often enough carries fossilized drivers only), a toolbar for multifunction printers, a watcher that nags you to buy new original cartridges, a scanner agent because there is still no standard for scanning without drivers, much less so over network or cross platform, a selection of adware... and God help you if you have printers or MFDs from different vendors.

The only way to not have this ridiculous mess is buying enterprise printers - for example, the Z2100 plotter drivers are 4MB for Windows, and 16MB for the manager app, while the Photosmart printer driver can only be had as a part of a 145MB download, there is no such thing as a "driver only" package in the consumer space. In enterprise environments (or small offices) the situation sucks even more because you can't really deploy them via GPO, you have to extract the drivers by hand.

Your problem may be more your choice of vendors than anything else. HP's big printers (e.g. M600 family) are still pretty nice, but I've started to avoid them for anything smaller, and god help you if you look at the truly low print volume stuff from them.

HP printers are excellent in terms of hardware build quality: the Z2100 plotter in my company is a decade old, of which it stood 6 years around unused - gave it a full cleaning, new cartridges and heads a new carriage belt and it was back to mint condition. Oh, and there are still new cartridges and ink tanks made, and there are still recent drivers.

And for most of the consumer gear from HP it's the same: even for really old stuff you can find new tanks/cartridges, drivers for new and old OSes and I've yet to see a HP printer fail in a way I could not fix myself with a service manual.

The problem I always ran into was customers getting the consumer gear and wanting me to make it print from their server, with drivers only from HP and no support for server operating systems.

My response to anything HP that wasn't good-sized obviously-business-targeted printers became "I can probably make that work, but it's going to cost you more in my time fiddling around with it than just getting a more appropriate printer."

One area in which MS was lackluster upon drivers was some of their own products - for example the force feedback joysticks, still on sale at the time, never got a Vista driver out of MS and became a glorious paper weight overnight.

That and apart from an initial few months of unstable GFX drivers, was utterly solid.

On a side-note, I believe Core Duo2's was the last Intel chips to not include any form of inbuilt `management` silicon and as such,still favoured by some paranoid/security prudent types.

Have you looked at the unimaginable amount of crap a typical Windows printer driver forces upon you?

Yes. I go out of my way to run a clean crap free Windows PC. Even going as far as either buying from the business line of laptops or buying from the Microsoft store. But the minute I install a printer driver....

It's even worse for people like my parents, they search online for printer driver and usually end up downloading crapware from a third party site unaffiliated with the printer manufacture.

Check printer specs first and select something with built in PCL or (better) Postscript support. With native Postscript you may even be able to just get a PPD file as the "driver."

Won't help as much if you want color though, particularly inkjet color.

And for your parents, see if they're putting the current year on searches - on Bing and DDG that ends (or did end recently) in much worse results because the original sites often don't include dates but malicious ones have all the same keywords plus the year. In my recent experience adding the year meant > 90% malware results on the first page.

Google was much better about this a month or two back.

Still, Google could impose update requirements for Play Store access, for example.

Regardless of stable driver API or not, it is up to the OEMs to make it happen, if they actually cared about it.

I am pretty negative about Project Treble, it won't change anything, because only Oreo devices have it (0.3% currently) and OEMs are still expected to be the ones pushing the updates.

Why does the kernel and driver ABI matter for upgrading userland? On desktop Linux I can by and large use a new kernel and chroot into an old install, or vice versa, and things still work. It would seem that Android userland is unnecessarily coupled to a specific kernel version. It should be able to upgrade independently.

Agreed in principle, but a decent amount of the new security features present in more recent Android phones are due to new kernel features. It's just a sign of the relative immaturity of the platform that this is the case.

Can you provide some detailed examples of that being the case? Genuinely curious to know.

Usually I hear that sort of thing and think somebody isn't being creative enough with fallback behaviors for when the feature isn't there, but I guess it would depend heavily on what the feature is.

I guess I probably misspoke. I was thinking about https://android-developers.googleblog.com/2017/08/hardening-... ... but those certainly don't require userspace changes (probably). And even the case where you'd want the new kernel features (but can't upgrade due to driver ABI incompatibilities), they've backported to several old kernels that are in wide use in Android... though I note that my 2-year-old phone is on an older kernel than most of those features were backported to.

> Also, be aware that ARM has nothing to enumerate devices, ...

Isn’t that the purpose of a device tree?

Your kernel brings in the device tree with itself.

It is primarily to allow the drivers linked in the kernel to detect whether they should load and try to talk to hardware. It doesn't replace bus enumeration when running on totally unknown hardware.

Basically yes, but that's often not good enough either. Lots of third party code OEMs end up with in their kernels, unmaintainable, and often incompatible with anything.

Well, it's not true that "ARM has no method to enumerate devices". It does have that; it's just that hardware manufacturers are bad at using it properly. (That's not to say it's not a huge problem; it's just that it's an economic/business/social one, not a technical one.)

I mean, it sort of does and sort of doesn't, but the hardware manufacturers just aren't used to thinking about things in the proper way. Just like the hardware is a black box with no user serviceable parts inside, as far as they're concerned the firmware (because that's still how they think of the OS and everything on it) is a single binary blob with no user serviceable parts inside, even if it's actually just linux and Android. And just like all the hardware parts are designed and qualified for a particular design, the same goes for the software: when you buy your hardware you get a software with it and that's that. As far as they're concerned it's just another component like a screen that gets customized to work with everything else and goes in the box, then is never touched again.

Now waitasec...

I own Crappy unupdated Android one of. And the drivers use the Linux kernel. Last I checked, they need to release source for their drivers.

So where is it? And why can't we upstream those patches and "fix" android?

Maybe they pull the stuff Nvidia does: write an interface kernel module, then have the driver itself in a library that the module loads. Since the actual driver is never part of the kernel tree...

It's much simpler.

The OEM never releases the source.

And courts have decided that it's not enough if you have some contributions to the kernel yourself or are a user to force them to release it, you have to have made significant contributions to force them to release it via the courts.

And Torvalds and the major kernel maintainers all refuse to enforce the GPL, and actively campaign against doing so.

> And Torvalds and the major kernel maintainers all refuse to enforce the GPL, and actively campaign against doing so.

Two questions: why? and why use the GPL if you’re not going to enforce it?

Are kernel drivers subject to the GPL just because they use the Linux ABI?

It'd be a long legal discussion to properly answer your question, but luckily OEMs make it easy for us:

On most phones, there are zero external kernel modules loaded. The SoC vendor bakes it all into the ketnel, and the OEM gets the kernel as a blob. Which means all of it is subject to the GPL.

Yep, I had to go sleep (yeah, that dreadful thing!).

But this was my main area of attack. You compiled the drivers directly into the kernel. Making it all GPL. Now, as a strict reading, I have to have the device to make the request. That's not difficult. Ive phones from a lot of US named companies.

I just want the rights enumerated in the GPL as granted to end users. I'm no kernel maintainer. Just a cranky person who wants the GPL enforced as any license.

> I just want the rights enumerated in the GPL as granted to end users. I'm no kernel maintainer. Just a cranky person who wants the GPL enforced as any license.

Yeah, it turns out it’s not that easily enforcable. There are still court cases going on, but the current legal situation seems to be that unless you’ve contributed significant code to the kernel, you have no legal leg to stand on.

Because the OEM is simply saying "yes, we violated the GPL, and infringed the copyright of the developers", but the only ones who could sue against that would be devs that contributed significant amounts of code.

> And why can't we upstream those patches and "fix" android?

It's a lot of work, who is supposed to do that?

Some bits of the N900 kernel are still in the process of being upstreamed afaik.

It doesn’t help that not every manufacturer (especially ones from China) don’t release the source code. And when they do, they sometimes contain opaque binary blobs that don’t tell you what is happening.

Most of the time, such a source release means "patching binary blobs into the source".

The source helps little since it's just opaque garbage with little to no meaning.

Reply on news.ycombinator.com