Hacker News Reader

Comment by cube00 | 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.

In my personal case nVidia stopped supporting my graphics card and eventually their binary blob stopped working with the newer Linux kernels so I had to chuck it away.

Now I've learnt the hard way that I'll never by nVidia again (or if I do I'll make sure it's open first). At the time nVidia was getting a lot of good press supporting Linux and I didn't realise that meant closed source blobs that would eventually stop working.

View on HN

What incentive do manufacturers have to release open firmware? Let's get serious, it's been 20+ years and desktop Linux usage isn't moving the needle or getting any of their attention.

IMHO it would be far better to put effort into change at a different level, like perhaps a broader push with right to repair legislation that expands it to include releasing firmware in addition to schematics, spare parts, etc. Change is going to have to come from a different source, you're just abusing users today for no benefit.

Everyone in the embedded space goes to kernel.org for WiFi stuff (firmware, regulatory info etc) regardless of which OS they're using. Being put at the top of the Wiki because you're "easy to work with" would be a massive advertisement.

By all means, the "free software community" should promote HW with free firmware, and giving the top spot on the kernel.org pages sounds like a good approach. And yeah, I spent a lot of time looking at wifi drivers when getting a wifi router. ath9k was the gold standard here with no blobs, and as a result was the favored platform for the wifi bufferbloat work. Unfortunately the follow-up ath10k needs a blob.

But I don't think punishing potential users who just want to get their laptop to work is particularly effective free software advocacy. Most likely the user has no clue what wifi chip their laptop has.

> 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?

> 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.

> 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.

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.

>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.

The only friction you're causing is to Debian users. My current laptop is Arch after 5 laptops that ran Debian. My Debian desktop is barely functional with the friendliest AMD GPU to Linux I could find.

By my next update cycle I will be Debian free for the first time in 20 years. Debian needs less friction if it wants to keep me as a user.

I doubt that has anything to do with "friction", Debian's release cycle just isn't compatible with wanting to run new hardware. Drivers are distributed via the kernel, Debian uses old kernels and can't afford to do the same kind of hardware enablement backports that Red Hat, SUSE and Canonical can do, so being stuck with the old kernel means poor support for brand new hardware.

Not sure why you're talking about new hardware. The graphics card is now 4 years olds.

>the only way we'll see long term change is to keep the friction on

... but there are two possible long term changes, right?

In one of them, the friction incrementally pushes manufacturers not to have proprietary firmware and the number of machines supported by the Debian official install improves.

In the other one, the friction incrementally discourages users from installing Debian, and they either give up on Linux or adopt a distribution that isn't quite so user-hostile.

Depends on how you define 'user-hostile'. There's already a link to the non-free image on the current installation page, and I wouldn't consider respecting your freedoms as hostile.

So if Debian were some megacorp, someone would already be complaining about the "dark pattern" that puts the link to the directory (n.b. not the actual images) for non-free images down the bottom of that page in small print inside a box labeled like a warning, and calls them "unofficial".

As opposed to making it clear that this is the one you need if you're doing something outrageous like ... using a laptop or something.

One way that vendors have released libre firmware is when someone already working on the proprietary firmware convinced their bosses that libre firmware is a good idea. This happened with two of the open WiFi firmware projects.

AMD and Intel GPUs also have closed source firmware.

As long as the code running on the Linux side is open and the closed source firmware stays on their chip that's fine by me. At least then you have a fighting chance to change the open source side up to date to allow the card to keep working.

I know it's not pure freedom but I'm picking my battles these days and if I can keep something working by bridging the gap between an evolving kernel and static closed firmware then that's good enough for me.

I have an Intel NUC based iGPU and it works with Linux-Libre + MESA. OpenGL and Vulkan. Ok, just libre games/engines, but they with all the FX'.

>it's this friction that forces the change of habit to support manufacturers who open their firmware.

You can only force anyone to do anything if you have power. If you don't have power you're just a weird guy screaming from a soapbox and people are going to ignore you. No offense but do you think nvidia cares about your boycott? There's no shortage of graphics card buyers.

I assume the non-free version of Debian sees significant amounts of downloads, maybe at this point more than the free version, so the situation is obviously quite awful or this post would not exist.

Reply on news.ycombinator.com