Linux Vendor Firmware Service

Re:Linux Vendor Firmware Service by brudgers on Thursday November 30, 2017 @10:18AM (#15816370)

Assuming that the vendors act as they do out of fear biases causal analysis away from simple business cases. One of those cases is that vendors may have developed their firmware with software that limits the ways the firmware can be distributed. Another case is that vendors may have incorporated software licensed from other companies and that license agreement prevents release of the source code...or more simply the third party software may have been distributed as a binary. Finally, the source code may have been developed with custom or proprietary tooling, build systems, etc. that are not generally available and so releasing the source code doesn't mean that people can use it or understand it.

Theoretically, it is possible to untangle a big ball of string. Theoretically, it is not possible to untangle a big ball of mud.

[ Parent | on HN ]

Re:Linux Vendor Firmware Service by Anticapitalist on Thursday November 30, 2017 @12:26PM (#15817530)

You missed the most likely business case.

The hardware across a family with different prices and features is identical. Features are then enabled/disabled by firmware alone.

This is frequently done to save on silicon manufacturing costs, but still allows marketing/sales to negotiate on features.

[ Parent | on HN ]

Re:Linux Vendor Firmware Service by JepZ on Thursday November 30, 2017 @05:28PM (#15820205)

Well, yeah that is a problem. Does anybody here have an idea how that could be solved?

I mean if the firmware would be released with its source everybody could buy the cheap version and load the full-featured firmware version to their hardware. Even if the manufacturer would place some kind of memory on the hardware which holds the feature-level, someone could patch the firmware to ignore that value.

[ Parent | on HN ]

Re:Linux Vendor Firmware Service by korethr on Thursday November 30, 2017 @07:31PM (#15820977)

There probably could still be some market segmentation based on the results of what comes out of the silicon fab. Recall that in the case of CPUs, the circuits on dies of processors from the same line (and different lines!) are the same, but some sections are disabled (blown fuses, cut traces, etc) because those sub-sections didn't make the grade during testing prior to packaging. I've not looked, but I'd not be surprised if that weren't also the case with GPUs as well. Sure, you can enable the extra sections of $mid_range_GPU to make it on-paper-equivalent to $top_shelf_GPU, but it's on you to meet its now-unreasonable power and cooling requirements.

[ Parent | on HN ]

Re:Linux Vendor Firmware Service by brudgers on Thursday November 30, 2017 @01:20PM (#15818085)

Thanks for pointing out the additional use case that can receive more consideration once fear is removed as a primary motivation.

I think that order to be a primary motivating behavior, it would have to also be the case that none of the licensing/tooling issues apply. This suggests that logically it may be less likely as a primary cause due to the dependency.

[ Parent | on HN ]