Hacker News Reader

Comment by jwildeboer | Hacker News Reader

Most drivers are upstreamed anyways, nowadays. We get some early access and work with that, but the resulting code is always upstreamed and open source, so feel free to use that code at any time.

View on HN

There's a difference between drivers being upstreamed to the Linux kernel, and a datasheet being available. The source code is not the datasheet, and if there are bugs in the driver, where is the datasheet to compare the implementation to?

When it comes to hardware, source code availability is not sufficient.

Other OS platforms can have different driver architectures, different kernel ABIs and other platform quirks in comparison to Linux, and having to reverse engineer a driver for another platform from a Linux kernel driver is not very open. And then there are licensing considerations to be taken into account as well.

Linux is not the only opensource operating system in existence :-/ And for a project like Haiku, we don't have the people-power to reverse engineer Linux drivers, and again, the question of the GPL also applies when our kernel & drivers are MIT licensed.

As a software maintainer/distributor, I don’t think we at Red Hat are the ones responsible to publish data sheets. That’s the job of the hardware manufacturer/vendor. When they decide to only offer it in non-public ways but allow us to help with getting the drivers upstream AND open source, it is a deal you might not like, but I, as a pragmatist can accept. We’re not the only Linux distributor working this way. Ubuntu/Canonical and SUSE don’t work that different from us on this. Again. You may not like it, and I understand that, but it has lead to making Linux a first class OS on Lenovo with an upstream first goal. I like it that way, even if it can become even better and more open.

Of course not. It just gets more to the point of the original article. Whilst publishing and upstreaming driver source code for Linux is awesome, it's still only a half-measure in the overall picture of things being truly open, and we should try to demand more from hardware manufacturers. But we don't really have much sway in those regards, and it's disappointing as an OS-enthusiast, and a Haiku developer.

> As a software maintainer/distributor, I don’t think we at Red Hat are the ones responsible to publish data sheets.

I don't think the parent commenter suggested you are responsible for publishing the material. However, it would be great to have vocal support from distro maintainers to encourage hardware manufacturers to publish them in order to provide better support across all systems. If only, to have more transparency about what parts of "supported hardware" are actually supported by the distro drivers, and what specific datasheet references could be requested through other venues (such as directly asking the manufacturer).

> the resulting code is always upstreamed and open source

Are you saying there is 0 binary blobs involved in running a modern Thinkpad? I find that hard to believe (although i would love it). I'm guessing there's a few blobs in the kernel tree itself, and even more firmware blobs the kernel doesn't even know about.

On the topic of how Linux deals very little with actual hardware on modern machines, i really enjoyed this talk called "It's time for operating systems to rediscover hardware" [0]

[0] https://www.youtube.com/watch?v=36myc8wQhLo

I think it is quite possible there is few if any binary blobs. I have a Lenovo X1 and everything pretty much works out of the box on base Arch Linux (and Debian before that). I think it also helps that my X1 has Intel graphics, Intel Wi-Fi, etc which has very good support which I know is not a given for others (e.g. Broadcom Wi-Fi, Nvidia graphics, et al). It is easily the best Linux experience I've ever had.

> I have a Lenovo X1 and everything pretty much works out of the box on base Arch Linux

I'd be curious to know if it actually works well with linux-libre (Linux without the binary blobs). It's apparently not maintained as a distro package but is available on the AUR.

Moreover, I'm still curious if all hardware functions without its own binary blobs. For example, is the networking firmware really free and replaceable, or is the proprietary firmware interoperable with a FLOSS driver? Likewise, is the entire system libreboot-able?

Sorry for nitpicking, i'm just looking for precise answer to a topic that's not widely questioned/debated to my knowledge.

I believe none of the major wireless NIC vendors these days ship cards that will do anything useful without a nonfree firmware blob, for example.

If you wanted to use Linux-libre, wouldn't you just use Parabola?

GP is talking about drivers, you seem to be talking about firmware.

Correct, i'm slightly abusing semantics. I'm mixing them both under the category of "software that should be under user control", and interested about the FLOSS support for both.

When firmware was stored in ROM/EEPROM, most FOSS folks had no problem with it. It was considered part of the hardware, so not that relevant. But when these were moved out of non-volatile memory (mostly for cost reasons), that changed the picture for some. While the result, after booting, is effectively the same. So no, I am not on the side that sees firmware blobs as something that MUST be made open. It would be good if it were, definitely. But it’s not a deal breaker for me, as long as the blobs are freely redistributable, for example via fwupd. Again, that’s my personal opinion.

> While the result, after booting, is effectively the same.

I'm not sure it's exactly the same. First, because having embedded firmware formed an incentive for hardware manufacturers to test stuff and fix bugs before hitting the market. Second, because who gets to push updates to our machine has serious political/security implications. We have reached a situation where the OS we choose to run has less and less control over our computing, and i find that worrying.

> it’s not a deal breaker for me, as long as the blobs are freely redistributable

Thanks for your explanation. I can completely respect this position, although i personally disagree. If you ever get the chance to bring up the issue (libre firmware/drivers and librebooting), please spare a minute to raise our disenchantment and mention the possibility to work with other distros (such as Debian, who also has ties to Lenovo) hand-in-hand with hardware manufacturers to improve the situation for everyone.

I don't exactly have any hope for it, but having Lenovo publish its entire hardware specs and playing nice with maintainers to provide libre firmware would definitely inspire confidence in their hardware. For the moment, it seems only Librem and Pine64 (and a few others) are manufacturers that can be approached on that topic. But like the original author (mmu_man) suggested, software freedom should be for everyone, not just people investing in specific hardware... and i'm pretty sure he would be thrilled to work on Haiku support for his Lenovo hardware given proper documentation ;)

No. I specifically said drivers, not firmware blobs. As long as these blobs are freely redistributable, I personally have no problems with them. I understand some people do and that is understandable, but I don’t subscribe to that. This started at a time where non-volatile memory for firmware became a cost factor and companies decided to save a few bucks on the BoM and upload the blob as part of the initialisation/boot process. Which is fine with me.

Reply on news.ycombinator.com