Hacker News Reader

Comment by majormajor | Hacker News Reader

> As bad as it is in the short term the only way we'll see long term change is to keep the friction on. It's this friction that forces the change of habit to support manufacturers who open their firmware. If it's seamless then there's no incentive to seek out the open option next time you buy.

My experience is the same as the author's: there's more today that needs non-free support to use Linux on the desktop than there was in the past.

So the friction isn't doing its job.

So why bother if the friction is just pushing users to distros which bundle the blobs more directly, instead of pushing manufacturers at all?

View on HN

> My experience is the same as the author's: there's more today that needs non-free support to use Linux on the desktop than there was in the past.

Is that a function of Linux Desktop simply being more capable nowadays?

Also, there is a world of difference between not publishing signed closed-source firmware for a driver that does not exist vs having an open source driver with published firmware.

I wouldn't say the Linux Desktop has gotten any more capable since Compiz, so no. (Nor have most desktops - depending on how much you value things like iMessage integration in modern Macs.) Before that, since... Phoenix/Firebird/Firefox and the decline of IE-only sites? Office file format compatibility?

It's more the examples provided in the original article: cpu firmware blobs, network firmware blobs, same as always, just even more.

That's a good point. I think the author might be forgetting using ndis wrapper to run Windows drivers (so that's non-free software on the same machine as your OS) for unsupported network cards. We've come farther and have new, different problems now. The situation then looked bleak much like the situation now.

That's still where we are for a lot of modern Broadcom wifi, which was also the biggest issue in the ndiswrapper days.

> Is that a function of Linux Desktop simply being more capable nowadays?

I don't think so - it's more a function of hardware becoming more complicated, and vendors choosing to put a lot of the logic in firmware rather than putting it in ROM because there's a much lower chance of them getting it right first time now than there was in the past.

Is hardware becoming more complicated without being more capable? I just think that we’re taking lots of things for granted nowadays, which require complexity to be managed successfully.

ROM to firmware creep is understandable, given flexibility that you mentioned. But to an end-user, is there a difference between having a blob in ROM vs firmware, if both are closed source?

> Is hardware becoming more complicated without being more capable?

I don't think so. Every component on my system that runs firmware is significantly more complicated than the iterations that didn't. 802.11ax is much harder than 802.11b, for instance.

> But to an end-user, is there a difference between having a blob in ROM vs firmware, if both are closed source?

Yeah, bugs that are discovered after release can be fixed.

> Yeah, bugs that are discovered after release can be fixed.

I definitely understand that real benefit.

But I was questioning the premise that having blob in ROM is somehow better than needing same blob in firmware, simply because that one doesn’t need/want to distribute non-free firmware on media.

If one wanted libre hardware, then both cases are not great.

> But I was questioning the premise that having blob in ROM is somehow better than needing same blob in firmware, simply because that one doesn’t need/want to distribute non-free firmware on media.

Oh right! I absolutely believe that having non-free firmware on media is preferable - in some cases this has led to free implementations that replace the non-free firmware, and even outside that, given the choice between non-free code that doesn't work and non-free code that does, I'd prefer to take the latter.

Reply on news.ycombinator.com