Anyway, loading proprietary firmware from the eMMC image is a *feature*, because it means that it can be validated together with the rest of the OS. If you have firmware out of band, you need to perform explicit steps to verify that it hasn't been tampered with.
-
-
It's also, you know, less wasted work. There is zero user benefit to doing this stupid dance to get RYF certification; it's purely a bureaucratic hack that does nothing for user freedom, just panders to the FSF's clearly nonsensical rules.
1 reply 0 retweets 0 likes -
Replying to @marcan42
Even assuming that it has no benefit for the user (which I disagree with), a "bureaucratic hack that does nothing for user freedom" is very clearly a different thing than "eliminating user freedom".
1 reply 0 retweets 0 likes -
I disagree with "no benefit" because being able to just take and flash free distributions without having to include blobs/enable non-free repos is a thing that directly benefits the user. I was porting SHR to N900 back in the day and I really wished it had its blobs stored too.
1 reply 0 retweets 1 like -
We ended up including an initial setup page that pointed users to instructions on how to copy the blobs from Maemo installation. Not having to deal with such bullshit and being able to just install things like Debian without contrib/non-free is definitely an advantage for me.
1 reply 0 retweets 1 like -
Notice that this is exactly the PureOS case - there's no non-free stuff in PureOS repos at all (like Debian main). That flash is IMO a very practical thing to have for a hackable FLOSS-oriented device. And worst case you just won't use it if you don't care.
1 reply 0 retweets 0 likes -
Replying to @dos1
We're back to square one. What's the *point* of those nonfree repos? Again, this is misrepresentation. Either you have blobs, or you don't. If you do, why is it so important that you stash them so the user doesn't need to care or know about them? Enable the damn nonfree repos.
1 reply 0 retweets 1 like -
Like do you *realize* the blatant doublethink this whole thing reeks of? "Our users dislike blobs, so instead of asking them to enable blobs, were going to provide blobs in a way they don't have to care about so they won't be disgusted by our blobs"
2 replies 0 retweets 0 likes -
Replying to @marcan42
But the blobs are there anyway in much more places, even in the SD card or touchscreen controller - I doubt I have to explain that to *you* :P
2 replies 0 retweets 0 likes -
Replying to @dos1
Sure but why hide *more* of them? And the thing is, the FSF RYF policy encourages *precisely the reverse* of what benefits users. The ideal blob situation is that *everything* is loaded into RAM from /lib/firmware. That way the blobs are *transparent* and verifiable.
1 reply 0 retweets 0 likes
They are auditable and, if not signed at the hardware level, replaceable with free versions. Devices are not brickable. And yet RYF bans this and calls for the exact opposite: a distributed network of ROM/Flash memories that is impossible for a user to visualize or control.
-
-
Replying to @marcan42
That's a far fetched interpretation. The mere presence of such flash doesn't make it any less transparent. You may not see it as a valuable thing to have, which I can understand (even though my opinion is different), but it's not harmful. It's up to you how you use it.
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.