New Intel graphics will require non-free firmware
- Inicie sesión o regístrese para enviar comentarios
Sad news. Integrated Intel GPU is no longer a safe bet.
https://www.phoronix.com/scan.php?page=news_item&px=Intel-SKL-BXT-Firmware-Blobs
Down with Intel! At least nvidia has powerful hardware, and nouveau is making progress with the re-clocking support[1]. I actually bought the GTX 650 hoping it will get good support for 2016.
[1] http://www.phoronix.com/scan.php?page=article&item=phx-open-11&num=4
Are you aware Nouveau will require proprietary, signed blobs starting from Maxwell cards?
Fully free/libre graphics are not possible anymore, with current generation hardware. All Intel, NVIDIA, AMD require binary blobs for their free drivers to function.
Yes, that's why I bought the GTX 650, because Kepler is one that has good support from nouveau (without any blobs as far as I know). The reasons why I bought the GTX is because Intel is freaking expensive, and also because I believe the GTX 650 will give me better performance than any Intel graphics.
Tryed 7300gt, gtx460, gtx970, yes, it says me that I have 3d acceleration, but everything moving with extreme lag. Useless gpus.
Will 650 run better that 4000hd? sure?
They are useless without the proprietary drivers. In CS:GO, its at least 200+ FPS with max settings at 1080p.
Hmm...Larabel seems to be the only one who drew that particular conclusion so far, so I still hope it doesn't happen.
If this is really the case, it is a big problem for us. A mate in the Spanish forum was just writing about it.
https://trisquel.info/en/forum/la-nueva-microarquitectura-de-intel-skylake-va-requirir-un-blob-binario-en-el-m%C3%B3dulo-i915-drm#comment-70941
We agree that we, as libre software users can do 2 things. Send a letter to INTEL each on our own or unite all our signatures into one letter and send it - union makes us strong!
If, and I repeat IF this proves to be true, I think letting Intel hear our voice is a good idea.
Cheers!
Try both :)
I'm actually curious if the design is such that these blobs are going to be loaded by the "BIOS" first and updated later by the OS if needed similar to how the CPU microcode already works. The reason is if this component is mandatory for video then how would it work within a BIOS / UEFI? If not then I'm guessing its probably only mandatory for 3D acceleration as is the case with NVIDIA/AMD graphics chips already.
In any even none of this really changes the fact that this is unwanted and going in a direction nobody here wants to see it go. It's bad. Real bad.
Unfortunately I'm not seeing a bright perfect solution on the horizon for the masses. Any solution is likely to only be adopted by a handful of die-hard free software advocates. And that's making the assumption that there is enough demand to solve the problem in the first place via manufacturing a free software friendly non-x86 laptop/system.
This just reinforces that the long-term strategy for RYF-certifiable machines will have to be moving away from x86.
Yup- it's what I've been saying!
There has been progress on the ARM front too. Whatever you read/heard about AllWinner recently was a bit off. While in good part correct it was more an issue of one hand not knowing what the other was doing. Once it was communicated to the right people hire up the chain of command the issue got addressed. On that note there is another unknown to me person involved who deserves some credit. They apparently did some work translating documents and going around the barriers to communicate the problem to those who could correct it.
There are still issues on the graphics front. However there is hope. Not so much on the mali-400 as originally thought. Its looking more like a next-generation situation. However we still need to hold our breath and see how it unravels.
The real issues I'm seeing are on the wifi front. There are fewer and fewer companies competing in the wifi chipset market and those who are have lost critical people who were enablers to getting code released. I think we're just going to have to buckle down for now. The good news is we got our hands on 802.11n M.2 cards with an Atheros chipset which is properly supported and free software friendly (ohh AND free bluetooth- but ONLY on the M.2 cards- not the older PCIE cards). The bad news is these cards aren't being widely used in laptops/desktops. Everybody is shipping with 802.11ac now pretty much and none of those chips are free software friendly. If you want this chip instead your going to have to install it yourself and unfortunately with the digital restrictions it won't work with a good percentage of systems on the market.
Another problem is the wifi chips are getting integrated in the SOCs which means you won't really have a choice for wifi chips. Even on X86 where this hasn't been a problem and even where it's not in the SOC companies are soldering down the chips. 3/4 of Intel's latest models have integrated wifi where you can't replace the wifi chip.
After talking with Nico (who is the developer of Bananian, a Debian based OS for the Banana Pi board, you can visit his website at www.bananian.org) the Banana Pro has a wifi chip that is supported by an open source driver. I made that specific question and his answer was this:
"3.) The wifi driver is open source.
Compare these two commits (merged from LeMaker) adding ap6210 support to
our kernel:
https://github.com/Bananian/linux-bananapi/commit/8049c152337806b5c2ea8c456a673bacc6770b5b
https://github.com/Bananian/linux-bananapi/commit/0ceb311d369b9f334f5b1391b73ba065cb9aa738"
I agree that we should move away from the x86. That is why sooner or later I will get a Banana Pro and run it with only free software (which is possible if you are willing to sacrifice 3d for now, work is being done to take care of it).
EDIT: Forgot to mention that there is already hardware decoding of some video formats with free software for the Mali 400. Look up "vdpau" if my memory serves me correctly.
Old post, but I guess I forgot to say this isn't free as in freedom. I also contact Nico and I pointed out the blobs and he confirmed it wasn't free as in freedom. It's just got some sources with a proprietary core. Nothing of interest. The better bet is going with the Banana Pi (original) and LibreCMC.
Anyway is this really happening?
Of course it is. Why would you not believe that it is? This is just some joke thread? Sadly, it is not.
"Why would you not believe that it is?"
Well, because Larabel, the last time I searched, was the only guy to explicitly say that it's happening without linking to Phoronix.
False hope on my part, huh?
Nope, not just Phoronix. Even Intel.com. It's real. It's happening. It's not a joke.
I haven't been checking enough then :(
And there's no effing way out that's newer than Broadwell?
Not with Intel, unless someone manages to reverse engineer stuff or Intel changes their mind. First they had the proprietary BIOS. As if that wasn't bad enough, enter Boot Guard. To make things even worse now this with the video. Switching to AMD can address (some) of these three problems but the long-term solution for RYF-capable hardware, really, will eventually have to be leaving x86 entirely. I am once again reminded of http://files.jxself.org/build.ogv
From a software freedom perspective, x86 is like the Titanic. It's going down and it's time to get off. Now where's my lifeboat?
Our safest bet is 32-bit? Why is it better than x86? (Sorry I'm not very knowledgeable, but willing to learn)
If I'm not mistaken x86 is actually nowadays used to refer to 32-bit x86 processors while x86-64 (or AMD64) is used to refer to 64-bit so I'm not sure what you mean.
Huh, I always had the impression that 64-bit and x86 were synonyms :P
Thanks!
x86 and ARM are instruction set architectures (the format and semantics allowed for machine code). 32 bits or 64 bits in this context refers to the “word width”: the size in bits of the general purpose registers and it is usually the same as the size of memory addresses. Both ARM and x86 have 32 bits and 64 bits versions (and they differ in more than the word width). Most laptop, desktop, and server computers use x86‐64 CPUs (Also called “AMD64”, “EM64T”, “Intel 64” and incorrectly, “x64”).
(duplicate, removed)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On Fri, Jun 12, 2015 at 02:44:43PM +0200, name at domain wrote:
> Not with Intel, unless someone manages to reverse engineer stuff or Intel
> changes their mind. First they had the proprietary BIOS. As if that wasn't
> bad enough, enter Boot Guard. To make things even worse now this with the
> video. Switching to AMD can address (some) of these three problems but the
> long-term solution for RYF-capable hardware, really, will eventually have to
> be leaving x86 entirely. I am once again reminded of
> http://files.jxself.org/build.ogv
Do you happen to have the full libreplanet talk by RMS?
- --
Regards,
Andreas
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJVfCosAAoJEFuF+bX1dqZn6tgP/j9zMwQ6fQxJWMFi8WpnUkhu
+5WmtomFAjkJKCNP11a7n4iHv9vSAzFL6qLwaAkiLbMYXQzIH2sJmqscv/YBPfQw
DiYcn3b+yqhAWL/RPvdbzN6iJjEQHJwus8Q6w4aK6MhkFaOHKs4Fz4zZoJs4tQC+
nKm7W3y3dNV8Q4FvVWdvTnV7XWricRo1iZdsHLdpUr4fbYbWgz7QieZ5WsR+yRhp
La2yFPnEB8YT9BFWOeCbAtKhdb/hW6xKh9iC3WGc3v3tWtMpH/Gec/RAixZbRZQ3
IMGKY9z+SQ8qlwNJj86HQtSrp0ghXq+ILox9Buvvud995dprwEqzOmAq/3/25Wrp
CQYgekQVouy0KTJzzKw71xRMYP3XkaduuHE5Y8/4CPTjnxh+4lflGoXj/nEkAwB8
W+hLkHZTFqRweAwa4KAPtv0gnB6sTHWJz7unNawqJeJrY+SWMnKnwtw5+2PVe6iq
Qyy3m8Qig+XtkA82Fk3FXGpl1ZNU5rexHHY6qbetldeCvr1cHTKGcAzmd2FMhsul
2cCemREfCWn1mjzi5+LimUs1DVO9Jbd8faeorpDAI9IbxKSrnVyXfmJVfpCgLPPD
CBtevCL3BkVQfCAhXkX4dTPenGUMKRRuPnB+a8bTGKYhmlmYYpoO89HRtRLSrkeB
qBsdQyUFJqEuThG/KOur
=UDVS
-----END PGP SIGNATURE-----
"Do you happen to have the full libreplanet talk by RMS?"
http://mtjm.eu/releases/lp2015/lp-123-1426946502.ogv
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On Sat, Jun 13, 2015 at 03:26:44PM +0200, name at domain wrote:
> "Do you happen to have the full libreplanet talk by RMS?"
> http://mtjm.eu/releases/lp2015/lp-123-1426946502.ogv
Thanks.
The one you linked is from latest libreplanet. I think
http://files.jxself.org/build.ogv is from 2013 or 2014.
- --
Regards,
Andreas
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJVfDKkAAoJEFuF+bX1dqZnv6gQANEpxKxhxJMImMrQXLbfKMCu
IZjMGtJL7si6X5DHNwZTSyWy9xyeexHOHWW9LzdU+sRLcQYAyEis7bF6Fkr6fEdF
bIVFb8+pxnTmlLZqCQ/BSoN85GHWJd1F+t4ln5MhKpkqlqgT+mBHsawBHMMV+eKG
jdaF4FATTvRaecaeBWEaX41qYdbfg1cKLoi3SBUREDBbiDe+4HJITBZhE6Zy2mT5
hg1ExJxPMyTSOovJvS2X6G8bUi21wSChChaRUOzrl+Dp/VLLrJWwqujiy9OvFaA+
MvEgS+rBG4zDg1rT1r3zoLwwCILeA13nuv2LBR0eq9YmjS5GBqkgYReNHmXe5AwF
U53TzmFesBh8tKZ3j+v6W33WTTIIKNGLUZu8F+sr9jndHcdDZA7g3d1khSdLLOqu
8rIlzcr+UkvBjvV9QdnDn6F/Le/lqd/TanrWqvpVTHsZyF3+uGGoF4gcy+BCVFx8
ieruW5qQ+NAWdbUmO0UOPjQ7GAmP9jHcvZ6b2x0SJDqpfO9Cm2F9agWV7qvlT2x+
HExu4N8copIDA+y966VwqJfYar49G84BcM4TwfqDiYrrUjxyeK61efxkTGMJJosL
uyCC/9OV/S0El+6OnJzGA3uswG4OcrZq+KMHA+Y9roMHk5shanxR9RESbiTDB3mU
WDzBaG1Uz8piRMhXrclg
=Vy5E
-----END PGP SIGNATURE-----
not sure about 2013 but you can find all the 2014 stuff here:
http://mtjm.eu/releases/lp2014/
Sorry for the late reply, this is the one from 2013:
https://trisquel.info/en/forum/rms-talk-libreplanet
Respectfully, Adonay.
Have a nice day.
Just when we thought the world couldn't get any worse...
thx bananna magique for that link!
tom too!
EDIT: and now I see the link you posted is the 2015 talk. I thought you were posting the 2013 one..
Nevermind. thx anyway
Well, There is people who dont like free software, Like Apple and Friends. But Now intel has Nonfree Firmware? Guess we wont have a choice when it comes to the hardware side.
"Guess we wont have a choice when it comes to the hardware side."
we can always use older hardware
and do are best to reverse engineer newer hardware
Reverse engineering won't work. This stuff is being signed and it won't load anything that isn't signed. Reverse engineering would merely produce a free driver that we couldn't use.
* I'm still not 100% sure though that it won't work without the non-free component. It might just be needed for something that isn't necessary (power management) even if desirable.
- Inicie sesión o regístrese para enviar comentarios