| |||||||||||||
Linux-2.6.33-libre releasedLinux-2.6.33-libre releasedPosted Mar 2, 2010 15:29 UTC (Tue) by dbruce (subscriber, #57948)In reply to: Linux-2.6.33-libre released by Janne Parent article: Linux-2.6.33-libre released
This (and similar projects like GnuSense or whatever it is precisely called) are useful as benchmarks. They provide something to give to OEMs who want to demonstrate that they really and truly support Free Software, with all the asterisks and gray areas removed.
If a few years from now we reach a point where new hardware routinely works in Linux without proprietary blobs, that would be a very valid thing to celebrate, and folks like these would deserve a lot of credit.
I agree that "Linux-libre" doesn't make a lot of sense for ordinary users. As another poster pointed out, it will only run on compliant hardware, in which case the proprietary blobs in the standard kernel would never have been loaded anyway.
(Log in to post comments)
Linux-2.6.33-libre released Posted Mar 2, 2010 22:52 UTC (Tue) by rahvin (subscriber, #16953) [Link]
If it became an issue that affected profits all the manufacturers would do is put the binary blob in some flash (and use proprietary updates that will probably require windows) or ROM on the hardware itself, lock it up so it can't be changed or updated and the live with any bugs that result. That USED to be the way things were, these hardware blobs were in a bit of rom on the hardware and weren't upgradeable. If you ran into a bug you had to buy new hardware.
These binary blobs are a good step in the evolution of hardware because they allow hardware patching for bugs discovered after release. Most of these binary blobs aren't for hardware like winmodems where the stuff is being run in the CPU, it's truly specific to the hardware and an attempt to make the hardware better by making it possible to fix firmware bugs.
The only possible thing this could ever change is to reverse this trend (towards firmware that's fixable after manufacture) and lock everything up back in ROM's on the hardware. Personally I think this is a terrible idea that's a waste of time at best and a disastrous degrading of capability at the worst. These firmware blobs aren't software, as others have noted a significant number of them aren't even code!
I have to wonder where people get these ideas, although hardware blobs like winmodems where code is being executed by the CPU should be replaced where possible, most of these hardware blobs are insignificant and unimportant in the sense of freedom of code and simply aren't a big deal.
Linux-2.6.33-libre released Posted Mar 3, 2010 0:22 UTC (Wed) by foom (subscriber, #14868) [Link]
> These firmware blobs aren't software, as others have noted a significant number of them aren't
> even code!
They *are* software, and not having the source *is* a problem. Take 802.11 adapters, for
Obviously, being able to modify the code to add that feature is of great value.
But I agree with the rest of what you say: the way to get there *certainly* isn't to prefer hardware
Again, if someone makes a linux distribution that only works on hardware not containing
Linux-2.6.33-libre released Posted Mar 3, 2010 10:53 UTC (Wed) by paulj (subscriber, #341) [Link] are less functional than the hardware allows.Never mind that - those blobs are often quite substantial bits of software running on quite capable hardware (particularly these days). Often these blobs have access to a DMA capable bus and hence have complete, unfettered access over your computer, while also interacting with remote entities, e.g. over a network.
False dilemma? Posted Mar 4, 2010 3:26 UTC (Thu) by lxoliva (subscriber, #40702) [Link]
It's hard to tell whether you're trying to portray a false dilemma or you honestly don't see that there are more than two possibilities involved, namely:
- build the firmware into permanent memory and keep it a secret
- build the firmware into permanent memory and set it Free so that users can contribute to it and find great new uses for the device so that it gets more popular (dlink anyone?)
- have the secret firmware uploaded to the device as needed
- set the firmware Free so that users can upload the original or modified versions thereof to the device as needed
Why do you jump from the conclusion that, by refusing to help hardware vendors impose their choices upon users, and helping users be aware of the problem so they make better purchases next time, vendors would retreat to permanent memory?
There are a number of real-life examples that show the opposite: vendors who, instead of retreating to proprietary territory, pursuing their own interests, embraced and extended freedom, quite often without extinguishing it.
Do you regard hardware manufacturers as particularly dumb people who would prefer to go back to the software dark ages over pursuing their own interests and profiting from the pursuit, or do you perceive any significant change to the hardware manufacturing and selling business in teh last 40 or so years?
You might remember (or have read) that, back then, hardware manufacturers would actually release complete source code to the computers they sold (that were *far* less powerful than today's peripheral computers), and users were glad to contribute to the process of perfecting the system.
It was only when third parties got in and started selling software separately from hardware that proprietary software took over. Why would hardware vendors, that still ship the corresponding software along with the hardware that's their primary business, behave so differently now from the way they did back then, given that there aren't third parties involved?
This is getting long already, but I'd like to also address the point that the ability to patch the firmware so as to fix bugs in it, which hardware vendors evidently perceive as an advantage, may actually turn out to be harmful to users in the long run.
The reason is that, when it's very hard to fix a problem, you'll work very hard to avoid the problem in the first place, but when it's easy to fix it, you're often sloppier on testing, because the customers will do the testing for you and help you shake the bugs out.
With the short shelf life of these products, odds are that many customers will end up finding bugs that the vendor will decide not to fix, either becuase it's not cost effective or because they've already moved on to other products. Fixing stuff that was already sold and that won't sell much anyway is of little economic interest to fix, and customers will be stuck with the problems unless they take it back to the shop for a refund, which few will do.
|
|||||||||||||