New Generation of Intel Graphics for Linux Requires Proprietary Firmware
01.org
01.org
You never know when you pop a hidden write trigger, and subsequently fill the ROM of your expensive hardware with garbage.
I recall reading about such a incident involving a DVD burner, where the OEM had reused a seldom used signal (stupid on their part, but still) as the trigger for a firmware update...
Anyways, smart manufacturers these days put some sort of a signature on the firmware (even just a CRC will do), and don't write updates to flash unless they have a good signature. That makes it much more difficult to accidentally trigger an update.
That said, these rants themselves take much more time to prepare than a simple "we're not going to do that, sorry". Theo strikes me as someone who takes joy from hurling insults, rather than simply being busy and therefore curt.
Is it cool these days for open source OS/kernel development efforts to be run by these self-indulgent egotists?
-- someone who has had to triage an email list for an open source project
This kind of OP is terrible for any community. Its one thing to not understand something ... its another thing to write messages as if you deeply understand the problems in the space. OP is making all kinds of elaborate requests about what the project should do ... based on what? What made him decide to make these requests? Think about that. Its just ridiculous that someone could sniff some little bit of scent somewhere about something, and then make sweeping prescriptions about what should be done for the project.
Proprietary firmware is not a good thing, but it's not a very bad thing until we have open hardware, in my opinion.
You can get a product out the door much faster if it use a off the shelf microcontroller and a EEPROM than a custom IC.
Here, we're talking about a new micro-architecture for Intel's premium product line; I would be very surprised to hear Intel licensed anything in the design from third-parties. If Intel wanted their tool-chain to be available, they could make it so.
The GuC itself is basically a pentium processor running a very simple OS.
However, the question I care about is "does the original manufacturer have more power over the physical device I paid for than I do". If my Ivy Bridge GPU has on-board firmware, that I can't change, well, Intel probably can't change it either. Or if they can, they haven't documented it and so the kernel driver doesn't provide the facility and so effectively they can't, short of NSA-type hackery, an answer I am happy enough to truncate to "no".
However, for Skylake the answer to "Does the original developer have more power over the device I paid for than I do" is "very obviously yes" and no amount of handwaving or approximation will suffice.
a) Pragmatism dictates that in order to use the `new shiny' we use non-free firmware.
b) Ethical concerns dictate that no amount of `new shiny' is tempting enough to compromise our ideals.
I guess there are points in between and maybe these are poles in the debate with yer Stallman-types tending towards (b) and yer Torvalds-types tending towards (a).
I'd like a world without scary binary blobs and the Stallman in me chides me on my bad decision-making and lack of character. On the other hand, ooh look at the new shiny.
I'm highly suspicious this idea is patent encumbered.
They're using doorbells instead of schedulers. That's different, right? ;)
They're actually being more open than most vendors, since skylake isn't even shipped yet.
Hacking firmware is another matter. But a vendor distributing malicious firmware code that generates network traffic? Not wittingly, it doesn't make sense. Of course if it's for some sensitive piece of machinery and the vendor has been compromised. But then if you're buying sensitive parts maybe you should be extra-cautious to ensure they operate as intended. But consumer hardware? I'm not seeing it. Call me naive or not tin-foil-hatty enough :)
So please hand in your badge and tinfoil hat.
https://github.com/sstjohn/thundergate
additionally, how often do you do a firmware dump of your network card to ensure that what's flashed to it is what's intended to be there?
I am sure everyone is tired of this argument. But keep hoping - we love you for it.
But on the server side it's great. The majority of my servers run some form of Linux. I used to run FreeBSD but have moved Linux.
On a more serious note, I can't really understand the claim about a big difference in power-saving between Windows and (GNU/)Linux. It's not been an issue on my (admittedly rather old) devices. One thinkpad t420s (whose battery could use a replacement, due to age) and an ageing netbook.
I mean, you better not pass opinions like that one as "a clever lifehack".
The entire Android UI layer is open source, from the graphics stack to the window manager to the UI widgets. A commercial venture run by an autocrat developed it, but there it is, with a permissive open source license. I'd argue that Android 5.x is the most elegant and sophisticated UI and app environment available today.
I would also argue that alternative open source Android distros like CyanogenMod are more relevant to more users than Ubuntu.
The main "problem," if you want to call it that, is that Android doesn't play nice with legacy Linux desktop software. You can't easily have Android and a Linux desktop in the same device. If you WANT it badly enough, I could point you to some people who could deliver exactly that. It takes some doing to have a merged UI and graphics stack other than by using an emulator, but it's been done.