Slashdot Mirror
Intel Skylake & Broxton Graphics Processors To Start Mandating Binary Blobs
An anonymous reader writes: Intel has often been portrayed as the golden child within the Linux community and by those desiring a fully-free system without tainting their kernel with binary blobs while wanting a fully-supported open-source driver. The Intel Linux graphics driver over the years hasn't required any firmware blobs for acceleration, compared to AMD's open-source driver having many binary-only microcode files and Nouveau also needing blobs — including firmware files that NVIDIA still hasn't released for their latest GPUs. However, beginning with Intel Skylake and Broxton CPUs, their open-source driver will now too require closed-source firmware. The required "GuC" and "DMC" firmware files are for handling the new hardware's display microcontroller and workload scheduling engine. These firmware files are explicitly closed-source licensed and forbid any reverse-engineering. What choices are left for those wanting a fully-free, de-blobbed system while having a usable desktop?
Q: What guarantee do we have that these binary blobs don't contain root kits?
A: None.
This really isn't acceptable. :(
They aren't "mandating" anything. You buy their product, and they provide some closed source software with it that you need to get some of the functions. It sucks, but it isn't a "mandate".
You might want to consider letting it not bother you too much, though. After all, these chips have been full of proprietary code in the equivalent of ROM for a long time. The fact that some of it is migrating into RAM doesn't really change things very much.
If you really don't like loading proprietary blobs from RAM, use embedded processors; they usually don't do that because it wouldn't work very well in their environment.
If you really want to run a "fully-free, de-blobbed system", you need to get an open source processor and an open source motherboard.
What choices are left for those wanting a fully-free, de-blobbed system while having a usable desktop?
How about don't use these new systems? And keep on using what you have used in the past?
I am Slashdot. Are you Slashdot as well?
As long as the firmware blobs are readily available, why would I care that my drivers have to push the blobs to the device to get it to function? I just want to be able to use the hardware, which the driver+blob framework provides for me.
From a practical perspective, I don't find it surprising that the efficient operation of the video hardware requires custom coded binary firmware because the graphics cards are more like embedded computer systems than video cards today. The companies developing these cards pour a lot of resources into the development of the hardware in these embedded computation devices and they have a right to protect their investments by not showing the rest of the world how they did it (after all, there is a reason that developers are generally among the most highly compensated individual contributors in a company - they are paid that money because the things that they produce require high levels of skill and lots of labor and therefore have intrinsic value - giving away intrinsic value for nothing is a sure-fire way to go out of business).
...you care about modifying the display microcontroller and workload scheduling engine. I'm a proponant of open-source (open and free) software/firmware, but if your concern is that you can't wish open and free firmware from a company that is not open, then you are just like a Bible Thumper wishing your beliefs onto other people.
Final thoughts:
1) You have a problem with paying for the firmware, but not the hardware.
2) You are concerned that Intel's new processors will be "unusable" if not "de-blobbed."
3) You have too much time on your hands if you are concerned about being able to modify display microntroller firmware.
4) Even if documentation was publicly available, you probably don't have the skills to modify the display microntroller and workload scheduling engine....you sound like the Bible Thumper type.
I don't understand this presumption that you need 3D acceleration to have a usable desktop. There are plenty of older style cards that will work just fine with desktops that don't require 3D acceleration.
You may want 3D acceleration and you may want to play games, but that isn't required for a "usable desktop."
I do not fail; I succeed at finding out what does not work.
Has anyone kickstarted a completely open source video card yet?
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Unfortunately we're seeing a wave of new hardware that is dependent on proprietary software, integrating digital restrictions, and undermining users security. That's really bad for everybody regardless of how you feel about the ethical side of the the issue. Without the code games can't be optimized and bugs can't be fixed. There will be those who argue you don't need the binary blobs- but the truth is we do need these pieces short of an all perfect bit of software. Sometimes even the all perfect bits need tweaking. ath9k-htc firmware is a perfect example of this. The firmware wasn't buggy- but some USB controllers that people were using these chips with were. Changing a single line of code enabled people to use these chips on computers they otherwise wouldn't be able to use them on.
The good news is X86 is dead. The bad news is there is still a lot of work to do in order to introduce a truly free non-x86 computer and its unclear if there will be enough support from the community when the time comes to actually make it happen.
There are many people on the internet paid to agitate and make things difficult for those actually making progress. If have an interest in keeping our systems free or making the more free I welcome your comments. Otherwise go away. Your not contributing anything useful to the conversation.
That's some case of OCD fella.
Looks like Broadwell might be the last x86 cpu I buy (2nd hand of course).
By the time I need to replace it AMD will be gone and ARM should have taken over a good segment of the population, so Intel can smell me later.
That would be because any modern operating system (including most linux distros) uses 3D acceleration on a graphics card to put windows on a screen.
Be a conehead. Use that telex machine thing. Be a pepper. Go for it. Be all you can be. Aim high. Jump in a lake. Just not a skylake. Partake of toe jam and jelly not found in any store. Worship his holiness.
If you can run a given desktop with an SVGA driver, then you do not "require" 3D acceleration to use it.
I do not fail; I succeed at finding out what does not work.
> If you can run a given desktop with an SVGA driver, then you do not "require" 3D acceleration to use it.
Your dictionary pedantry adds no value and in fact obscures the issue. You should feel no pride in subtracting from the convseration instead of adding to it.
If the same blob was included in chip's ROM, nobody would think it's different from before right? The only difference here is that Intel is saving some money by not having a flashable ROM in the chip and instead having host OS provide the same blob on each boot. It's not like Windows driver gets a better blob or accesses some secret features not given to Linux developers.
If you are interested in open source hardware this is not in. But open sourcing all code running on main CPU is a significant step in itself and has many practical advantages (like being able to run/write whatever OS you want).
If community has done more with existing open hardware contributions like OpenSparc, I think we would see many new ones.
For such a short post, you've got plenty of wrong things.
You assume that this is only about 3D.
Now I don't know about Intel's plans but with the open source driver without the firmware blob, I can't even get my AMD card to work at more than 800x600.
No mode settings (screen resolution), no power management, no video decoding, no accelerated anything: neither 3D nor 2D.
Without the firmware blob, it's just an expensive power hungry 800x600 dumb frame buffer.
And there are _not_ plenty of cards out there.
Intel, NVIDIA, AMD (and Matrox) are the only choices if you want to buy new hardware. With Matrox not being present in the laptop market.
Intel was the last of the these which did not require a firmware blob.
Intel's latest gen APU hangs with AMDs, but it's also almost twice the price, and that's before you factor in that the AMD board is cheaper and they tend to have better combos on Newegg. I can get a 7850k with a good board and 8 gigs of ram for $236 bucks. The equivalent i5 setup is going to be $450.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
"These firmware files are explicitly closed-source licensed and forbid any reverse-engineering."
Forbidding any reverse-engineering? I guess Intel will not be released this in Europe then.
Maybe, but you'll have to have an awfully attractive proposal and back it with heavyweight talent that already had a good reputation for delivering the goods.
For example, if a major video card vendor went belly-up for reasons not related to their tech (i.e. for plain old poor business practices) and their best coders banded together and started a kickstarter with a goal of $5B above and beyond the $1B they were personally tossing into the pot, they'd get my attention. But then again, they probably would be looking for traditional venture capital funding rather than kickstarter-type funding.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
If it weren't for the fact that these binary blobs are updateable, no one would care. For example, your hard disk certainly has a "binary blob" in the form of its firmware, but because the OS isn't able to update it, no one cares and happily ignores it. However, the moment someone releases a hard drive where the OS can supply the binary blob so that the hard disk firmware is easily updated, the open source community will immediately reject this new device even though the only difference between it and the old device is that the old one, in the event of a firmware bug, could not be updated and simply remained unreliable for the lifetime of the device.
Indeed, that's probably what is happening here. Intel likely had such code in their cards all along, but previously the code was in a non-reprogrammable ROM. Now they've decided to add a new feature to their cards to allow bugs that are discovered in this code to be corrected, and everyone is simply going to complain about it. They were happy when no one could access the code and fix the bugs, but now that Intel can do it, they're not willing to accept not being able to do it themselves as well.
It's rather silly. Just imagine if the card could accept a binary blob, but refused it if it didn't match cryptographic checksums in the hardware that cannot be updated. It would be effectively the same as if the firmware were stored in a ROM in the hardware itself in that no one would ever be able to modify that code, but you can still bet that the open source community would be up in arms over not having access to the source code simply becase, whenever they can touch binary code, they're unable to accept the fact that they don't have the source to that binary code.
I can't tell if this was written by a computer or a person smoking something while reminiscing about pop-culture references from the past few decades.
If you are a person, what are you smoking and where can I get some?
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Beta dribblers created the SYNTHETIC concern about so-called 'binary blobs' (or what Alphas call "drivers that work properly and efficiently"). It is a NON-ISSUE, especially when you remember that such software 'binary blobs' run of HARDWARE 'binary blobs'- hardware that contains the DIRECT MATHEMATICAL EQUIVALENT to software.
Intel has been building NSA back-doors into its chips for years, and YES, in theory, if their hardware were 'open' there might be a chance of someone discovering the extent of the compromise. BUT open-source projects across time have suffered the scandal time and time again of having malicious code buried within for YEARS without discovery. Open source notably does not fix this issue.
A software binary blob is considered by every Alpha as merely extending the proprietary CLOSED SOURCE hardware on which the software runs, and is thus of no issue at all. Intel has reached the point where it needs to extend BY LAW DRM functionality already present in the hardware, and also wishes its rapidly improving integrated graphics to at least compete with AMD and Nvidia. It no longer has an incentive to provide SH*TTY drivers in order to please beta dribblers.
Idealism, far from being an 'ideal' pursuit, is broken BY DESIGN- which is why it is always sold to Betas by people creating anything BUT an ideal society. Decent, rational PRAGMATISM is the best hope in any situation, which means UNDERSTANDING the compromises, and ensuring they do not go too far.
Your dictionary pedantry adds no value and in fact obscures the issue.
Well said. Being right is never a substitute for feeling righteous.
You have exceeded the limits of my universal translator, and that's even after I installed the Yodaspeak and Tamarian-metaphor-interpretation modules (side-note: the latter is huge, it has to incorporate the entirety of the Tamarian race).
Then translator did make this out though:
"Mod parent post down"
"#UNCLEARCONTEXT# Operating System"
"#UNCLEARMEANING# Possible reference to poster making many recent repeated arguments related to either the current topic of discussion, BSDI, or both, and a possible relationship between the current topic of discussion and BSDI"
"#SPECULATIONCONTINGENTONPREVIOUSUNCLEARTRANSLATION# Possible insult related to the possible many recent repeated arguments mentioned above"
If you will kindly let me know what additional modules I need to install in my universal translator, I will be able to understand you better. Thank you.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
An open source GPU: https://github.com/jbush001/NyuziProcessor
And its wiki: https://github.com/jbush001/NyuziProcessor/wiki
And even some peer-review: http://www.cs.binghamton.edu/~millerti/nyami-ispass2015.pdf
We could have fixed this problem a decade ago if the FOSS community had gotten behind the Open Graphics Project, but they're not as interested in FOSS-friendly graphics as they say they are. This is because most FOSS enthusiasts are more interested in gratis than they are in freedom.
I did kernel hacking for 10 years. I've fixed bugs in Ethernet drivers and helped document (and work around) hardware errata. I've also had to deal with trying to rebuild Nvidia drivers when the binary blob was no longer compatible with the latest kernel source. Having open-source drivers is key for those of us that actually *do* work on this stuff.
I was wondering how long it would take for intel to develop a 3D graphics team to compete with nvidia, and AMD. The ATI & AMD merger was back in 2006? Now, intel feels their 3D tech is good enough for commercial use, be worth copying, and tell the niche open source world to piss off. Interesting that the number of 3D tech companies has gone up. There's ATI/AMD, nvidia, intel, imagination tech/MIPS, ARM/Mali. I wonder how much longer nvidia will hold out alone.
I thought that people were using Linux to get rid of windows? /duck
Get free satoshi (Bitcoin) and Dogecoins
With the increase of low-power devices moving towards desktop usage, and ARM already have opened up their GPUs, albeit under specific license, it looks like a clear path for Open Source today.
Yes. Mandating open firmware, awesome idea. Because we want to need X different compilers compiling code for Y different cpus/mcus running Z basic OSses just to compile our kernel and use our hardware. It will make our lives so much better. Why not just mandate that those embedded cpus must run Linux themselves?
Perhaps it makes sense to differentiate between binary drivers for Linux (bad) and binary blobs running on the embedded hardware taking to opensource drivers (ok)?
OpenBSD has been pretty strict about using including binary blobs in their distributions. I would think this requirement by Intel would leave Open out. Sigh..
Has anyone found out *why* Intel is doing this?
What springs to mind maybe they're using code from a third party (i.e. video codecs, HDMI/DRM management, etc.) and *that* third party is not open source (for whatever definition of 'open' you prefer.)
If, (let me stress again, if) that's the case, then providing Intel with an open source solution that works better *might* resolve the issue.
What did the previous versions do? Was the equivalent code baked into the hardware? It seems to me that the change here is to a runtime loaded secret firmware instead of factory loaded. If that is the case (and it might not be), then this seems slightly more open really. Remember: this is firmware: there are lots of places fully out of end user control you can put it, but they opted to let you have control over loading it. It would be much better if they released the source for it, and their custom compilation tool chain used to produce it (I bet its not compile anything like normal c kernel code) and the source for that tool chain, but there is no way they want to support third parties trying to use their tools, much less hand all their firmware tooling and the source of that over to the competition. The prohibition on reverse engineering is kinda nasty though, but at least you have access to it where you didn't before.
And really, at least they provided them in a way we can use. That much better than some companies who do the same thing, and then prevent you from actually using their hardware due to the issue.
So I'm not going to hate Intel for this. I already hate them for lots of things, but I need some more details before deciding if this new offense is worthy of my of reasons to hate intel list.
The solution to this is to make an open source counterpart.
There is already work under way to create counterparts to CPU-ISA's:
http://opencores.org/or1k/Main_Page
http://riscv.org/
And there is also already work under way to create counterparts to GPU-ISA's:
http://hackaday.com/2014/08/19/open-source-gpu-released/
http://gplgpu.com/
MIAOW: An Open-Source GPU Design Based On AMD's Southern Islands
http://www.phoronix.com/scan.php?page=news_item&px=MTgyNTE
https://github.com/VerticalResearchGroup/miaow
The OpenGPU Project
http://opengpu.net/EN/index.php?option=com_content&view=article&id=144&Itemid=132
http://opengpu.net/EN/index.php
Manufacturers are eyeing changing the blob when there are problems, mistakes in the blob, this will happen.
Not to mention in the near future manufacturers want to sell you everything as a service, a limited renting time would be mightily appealing to encode in the blob.
Being technically correct is never a substitute for understanding that you're completely wrong when applied to the pragmatic normal solution.
You can't forbid what is in the law.
It might be an API thing. Drivers will switch to 3D API support, making 2D even slower (and less tested?) than it used to be (i.e. "emulated"). There used to be 2D cards for desktop, I don't know what the support is now, less what it will be in the future. Not "unusable desktop" for 2D cards but stuff such as Gnome 2 will be better for older HW.
This sounds like an outstanding reason to help a major vendor go belly up.
see what happens with intel when AMD is out of the way they jack up prices and cut back on stuff first's cutting back on pci-e lanes in $350-$400 cpus now open source what is next locked boot loaders? What to boot linux you need to buy a $250+ (1 cpu) $400-$600 (2 cpu) server boards or the top of line $300-500 gamer boards
The opposition to "binary blobs" has long been used against Nvidia video cards and some network adapters, but it has always been a bit of a joke. The people foaming at the mouth over blobs have happily confused two entirely separate issues, probably for their own ideological reasons.
Sufficiently complex systems involve trade-offs between hardware and code; a WiFi vendor could, for example, make different chips for different parts of the world hard-wired for the locally-mandated frequencies, OR make one chip that can be programmed with microcode in a blob to meet local regulations. Another example is the programmable logic in so may systems; manufacturers can make a single PCB that can support different options and system configurations based on a different fuse pattern load - a binary blob whose differences from a microcode binary blob are insignificant. By making one chip or PCB and shipping these blobs, we all benefit from more-optimized mass-production, better quality, and lower prices. Many of the machines we all use contain such blobs but often where most people are not looking - like in patterns programmed into FPGAs and CPLDs, or updates loaded into CPUs to patch their microcode. Why scream about such blobs when the alternative would be a hard-wired chip that could be every bit as malicious or buggy?
I get the complaints about binary blobs that execute on the CPU at runtime along with the OS and apps and which may even link to the kernel in some manner, but a blob that is guaranteed to have been created by the designer of the hardware and will be uploaded into a device that is thus configured to serve as a peripheral is no less deserving of trust than it would have been had the designer simply burned those bits into a device at the factory. Until I see open-source purists screaming over the bits (whose source they cannot see and change) in the microcode of a CPU and the FPGAs in their systems, and for that matter whining about the fact that they cannot see-and-change the source schematics for all the ICs (given that these in many instances are doing things that could have been implemented with simpler hardware plus code) in their systems, I simply cannot get all worked-up over the blobs video chip vendors provide which must be uploaded onto their chips.
the i5-4460 can't hang with AMD on GPU performance. So you'll have to plunk down $100 bucks to close that gap. 4690k does much better, but it's also much pricier. Also the ASRock is kinda garbage, and you'll take a big performance hit for basing your machine around that. For $236 I get a good quality Asus mobo for a 7850k. Now, your 4460 absolutely spanks the 7850k as a cpu, but if you're counting your pennies it's a wide gulf...
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
Curse your sudden but inevitable betrayal!
You can run the SVGA drivers with virtually any modern 3D card. If you're that paranoid about the BLOBs, you have an option. How is that "wrong"?
It's not like Intel, AMD, or NVidia are going to start publishing the source code for their BLOBs just because you're paranoid about their contents.
I do not fail; I succeed at finding out what does not work.
While I feel the outrage over this move is probably overblown, it does vindicate the fairly extreme positions in regards to free software held by Richard Stallman. Basically the watered down idea of free software, called "open source", has taken off and really win the world over. Even Microsoft is embracing open source. Everyone sees the benefits. The problem is that they see that it can benefit their existing proprietary models quite well. So for example Microsoft, while being more open to open source and interoperability is as proprietary and closed as ever before.
Intel too has embraced open source and Linux, but the philosophy of free software is only embraced to the extent that it will help their business.
In the end then open source software has both won and lost. It hasn't changed the corporate attitudes like some of the earlier visionaries wanted. I fear we're all the losers here. This move by Intel confirms that to me. In this modern post stallman world, open source is mostly a way to placate the masses. And it works well. And is quite profitable.
You can run the SVGA drivers with virtually any modern 3D card. If you're that paranoid about the BLOBs, you have an option. How is that "wrong"?
It's not - but it's not practical in the context of any modern operating system's demands from a graphics card.
a WiFi vendor could, for example, make different chips for different parts of the world hard-wired for the locally-mandated frequencies, OR make one chip that can be programmed with microcode in a blob to meet local regulations.
Third option: include a small block of PROM in the chip package to store the region-specific parameters.
Another example is the programmable logic in so may systems; manufacturers can make a single PCB that can support different options and system configurations based on a different fuse pattern load - a binary blob whose differences from a microcode binary blob are insignificant.
The differences are insignificant technically but significant politically. Microcode stored on a nonvolatile memory in the CPU or chipset will work with whatever operating system is loaded. Microcode stored in volatile RAM works only with operating systems whose publisher has licensed the microcode.
Anonymous Coward wrote:
You can't forbid what is in the law.
Which jurisdiction's law were you talking about? In the United States, there is no right to reverse engineer. In the European Union, there is no right to immigrate from the United States.
It's perhaps not "wrong" for a certain restricted definition of "Useable", but it is for the "pragmatic normal solution". If you bought a graphics accelerator, it's almost certainly not because you wanted to be restricted to the VESA driver. If it was, you probably would've stuck with the hardware that you already had, which was also capable of running as VESA. The definition of "useable" that you're using basically excludes anything beyond text and static images. You're making a strawman argument. Your "solution" addresses a reduced problem, rather than the problem that the rest of us are trying to solve.
It is pitch black. You are likely to be eaten by a grue.
What the flying fuck is the "alpha" "beta" crap that you're talking about? You don't seem to be talking about the software development process. Nor do you seem to be making a reference to Brave New World, so I'm kind of at a loss. The nearest I can see is that you're using "beta" as a pejorative label for people who disagree with you and "alpha" as a laudatory label for those who agree with your position. Since the strength of your argument seems to rely on denigrating others, I've got to say: You aren't adding anything useful to the discussion.
well, so much for that experiment. Back to NVIDIA. I'll take performance/closed blob over crap performance/closed blob.
"The binary blobs are themselves dangerous - driver software is typically running with very high security clearance, and you have absolutely NO idea what is going on inside those blobs."
Then why not rewrite the (opensource) driver so the only thing it does is upload the binary blob to the graphics card? Then you're back to present behavior, a graphics card that runs closed-source microcode. Has anyone performed a security audit of any of today's top desktop CPUs?
The idea solution would be nothing less than building your own openware CPU/GPU.
Yes, I tend to see things as black or white. And yes, I could use more exercise. But I'm working on it.
Intel AMT/VPRO/VT
Hardware backdoor/spy (vnc server, remotely reenableable, also bus spy)
Do you have any idea how much it costs to license proprietary toolchains for embeddable microcontrollers and DSPs? The companies getting lambasted in the headline innovate on a competitive cadence, which necessitates using 3rd party IP. Everyone wants Moores law to keep enabling sweeter gaming experiences at cheaper prices but few seem willing to accept the necessity of embeddeding third party IP to enable that reality. If some billionaire out there wants to buy up Tensillica and their ilk and open source their IP we would all be thankful but until then shut up and deal with the realities of a free market economy.
RMS can eat bowl of [redacted] for all I care.
Yes, we would think it's different because it is different. When the functionality of that blob is in a ROM chip or circuitry, nobody can update it, including the proprietor, without hardware modification or hardware replacement. When the functionality is in software or any kind of reprogrammable device, the question becomes who is allowed to run, inspect, share, and modify that code. This is an important ethical distinction that the developmental philosophy of the younger open source movement was designed to never raise as an issue because that movement wants to pitch a message of cheap labor to businesses.
All the questions of software freedom enter the picture because you're dealing with software now. All the issues that the open source movement was designed not to raise (older essay on this topic, newer essay on this topic) the older free software movement raised over a decade before the open source movement began.
If this code were distributed as Free Software to its users, this could be great news for all of us (even the majority of computer users who will never fully take advantage of these freedoms because they're never going to become programmers). Programmers can accomplish wonderful practical benefits like putting in interesting features, fixing bugs, learning from the code, all while being friendly with others by giving or selling services based on improving that code, and helping to keep users safe from malware all along the way.
If this code is distributed as non-free user-subjugating software (a.k.a. proprietary software), the proprietor (Intel in this case) is the only party who can inspect, share, and modify that code. And users (regardless of technical ability) are purposefully left out of controlling their own computers, which is unethical.
Digital Citizen
Who CARES if they forbid reverse engineering? Do it anyway.
ALL ones and zeros, whether they are CPU code, GPU code, FPGA fuse maps, microcode patches, or even the database of a circuit board layout are now merely the binary expressions of human-readable source code and the dividing lines between static logic, malleable logic, and executable code have blurred so severely as to be essentially irrelevent. I personally trade-off hard logic, programmable logic and software all the time in designs to meet cost/performance requirements. I do not care if it's C code or VHDL code.
I find it amusing that there are people so myopic (or so willfully ignorant) that they think there is still a significant difference and get all upset about not having the source code for one binary blob but never even mention all the other blobs.
Yes, malicious code could be in a blob intended to be executed by a GPU, but a binary blob loaded into an FPGA could just as easily contain a small micro and executable code and even implement an alternate NIC or other I/O device or even non-volatile memory to store stolen data for later harvesting etc
The POINT is that if the blob is from the hardware manufacturer and is properly signed then you should trust it and upload it to the hardware. If you do not trust the particular vendor then you are an idiot to be using their hardware even without any binary blobs because they could easily have stored malicious bits in the device before they sold it to you. In fact, (and this will be unpopular in Linux-land) this is a good argument for some forms of binary signing and DRM... as we go forward it may only be safe to load DRM-protected encrypted and signed blobs.
BTW: your PROM idea is dumb; It offers absolutely nothing while pretending to be an alternative. Why would you trust the vendor to burn the blob into a PROM but not trust the vendor when he gives you the very same blob and tells you you can upload it from Windows or Linux or BSD etc????
The whole point of an uploadable blob is that it's pre-built and tested and can be uploaded to the hardware rather than being tightly-coupled to, or even actually being, code executing on your main CPU and probably as a component of a device driver tied to a specific version of a specific OS.
Aren't we rapidly approaching the day when we can just 3D print our own motherboards, chips and all, and just use open source hardware with our open source software?
Written on my iPhone 5S
Thought maybe he was Tamarian......
Donald Trump, on a crusade to make Nixon look respectable
The "pragmatic" solution would be to stop bitching that the BLOBs are proprietary and to just use what is made available to you.
I do not fail; I succeed at finding out what does not work.
I thought UEFI was about loading these blobs, not the OS.
He seems to be 14 and/or very stoned, and defo very confused about where the part that's just inside his own head ends.
I consider reverse engineering EULAs to be non-binding. As there are no considerations in such a contract nor does it have a reasonable duration for the contract or any option to cancel the contract. (at least most reverse engineering clauses I've read, there may be exceptions out there)
“Common sense is not so common.” — Voltaire
A compositing display server saves a lot of CPU, by just doing the rendering and rasterisation of windows once and then alpha blending the resulting windows. You don't need to redraw for expose events, you just composite the results. This saves even having to bring the background applications into the cache (or into RAM if they're swapped out). Within an application, you can get the same benefit, caching the rendered results of (for example) a complex data-driven view and not having to do a load of queries of a model object because an overlapping view needs redrawing.
The down side of this is that you end up doing a lot of compositing. Sure, you can do this on the CPU (and a modern CPU is fast enough to do it on the vector unit reasonably fast), but that consumes a lot more power than doing it on the GPU.
I am TheRaven on Soylent News
Since when are we setting the bar so low? We had a usable desktop two decades ago, if you're willing to just toss out modern features. We also had "usable cars" and "usable airplanes" fifty years ago, but I'll bet you'd prefer to fly cross-country in a modern Boeing 777 than an old turboprop, right?
Incidentally, there's really no such thing as "3D acceleration", with the possible exception of support for geometry-specific functions on the more modern cards. Much of the power of modern GPUs is dedicated to drawing pixels (a purely 2D operation), with many tiny programmable processors running in parallel used to make it happen. All the "3D" stuff is simply a transformation from world space into screen space, and then that's where most of the work happens. Modern desktops rely on hardware acceleration for all sorts of things nowadays. You really don't want your CPU to be wasting it's time performing pixel blending operations, especially with today's large, high resolution screens, sometimes several of them per computer.
Naturally, games are what drives the high end capabilities (some consider playing videogames part of being "usable", believe it for not), but many other applications benefit from ubiquitous video hardware acceleration. One example that comes to mind is medical imaging. A laptop that can visualize engineering plans is another potential application. Even web browsers benefit from hardware acceleration.
Irony: Agile development has too much intertia to be abandoned now.
Is this really even slashdot worthy? This is just more Linux people whining about how un-fair the world is. This is exactly why Linux will stay a hobbyist OS.
A heap overflow in the nvidia binary blob driver was discovered in 2006, the advisory released with a poc.
That vulnerability would allow someone to execute code as root simply by having a user view something otherwise innocuous that would allow definition of fonts, e.g. a website.
http://nvidia.custhelp.com/app/answers/detail/a_id/1971
Your "options" without using the binary blob are threefold:
1. Don't buy any Intel iGPU hardware beyond the Broadwell generation. Eventually this strategy will fail, because your hardware will become obsolete or fail, and replacements will stop becoming available. Even if you buy the highest-end Broadwell iGPU, this iGPU will *quickly* be overcome by the forward-marching momentum of system requirements in every application sector that's in any way related to graphics. Even webpages are now requiring way more rendering horsepower than they did 5 years ago, with dynamic elements and canvases all over the place.
2. Upgrade to a CPU beyond the Broadwell family, but don't use GPU hardware acceleration. The vast majority of modern desktop environments require some form of OpenGL. Running OpenGL on the CPU is ridiculously power-inefficient, slow, and leaves less headroom for other CPU-bound tasks, even if you use a heavily optimized software renderer like mesa llvmpipe. You could use a desktop environment that does not require any OpenGL, but then you are severely restricting your options. And your webpages will still render at a pathetic speed, severely degrading your user experience. Additionally, since the display controller code is in the blob, you will probably be limited to heinously low resolutions, and may not even be able to use certain types of display connector (e.g. HDMI).
3. Use another vendor/supplier of graphics hardware that has open blobs. Currently, none exist that I am aware of -- at least, none that are fast enough to support even a basic OpenGL 2.1 desktop with texture_from_pixmap.
Considering that there are very valid and reasonable concerns about what could be contained within firmware on the system -- bugs?, (unintentional) security vulnerabilities?, backdoors?, NSA? -- and that the experience is severely degraded and limited without the firmware, any reasonable person would conclude that you are NOT being reasonable by saying that the options of either (a) not using the blob and suffering the consequences or (b) using it and accepting the risks, are acceptable.
I fundamentally disagree with the assertion that you can have a usable desktop without 3D acceleration, mainly due to the enormous performance gains and power savings of having your desktop backed by a GPU. On a laptop on battery power, CPU rasterization makes it almost useless, reducing the battery life by a huge margin.
When there are no other options on the market for something, and all of the available offerings have firmware that provides a credible threat to privacy and security (plus the inability to fix any bugs that are encountered), it is NOT reasonable to say "take it or leave it".
However, on a more personal level, I think most of the outrage about this issue is not that Intel has done this, but that *Intel* has done this. Intel has long been considered to be a friend to those looking for fully open systems free of firmware, especially in regards to their iGPUs. This "about-face" leaves that niche who consider the firmware blobs to be unconscionable with no other options, besides sticking with already-released products that will quickly become obsolete (optimistically, they might last you 10 years before it's high-time to replace them).
So, it's pretty cute that you contextualize this technical/philosophical computer-security debate into your apparently-psychologically-important "Alpha/Beta" dichotomy, but I wonder if you aren't actually getting at an interesting Core Idea -- the psychology of ineffectual complainers ("Betas", in your consummately immature formulation), versus those who recognize the shape of reality as a current fact, and combine A) working within reality and B) moderately altering reality in places to further their goals (your "Alphas").
You're not necessarily right about Idealism across the board, though. Sometimes, it is a sincere effort by expert participants who perceive an Ideal Reality we have an obligation to strive for... but it needs to be leavened by pragmatism, as you note. Cognitively grasp your goals and don't needlessly reject valuable compromises as inherently evil.
They paid you by authorizing the decryption of the software from the installer package pursuant to 17 USC 1201(a).