Pine thoughts
- Inicie sesión ou rexístrese para enviar comentarios
I recently sent some questions about Pinebook Pro to name at domain and received a somewhat weird response:
On Sunday, September 20, 2020 12:39 AM, TL Lim <name at domain> wrote:
> Hi Wojciech,
>
> At currently time, trackpad and keyboard vendor ha snot interest to
> release the firmware source code. For developer version, please check
> out jackhumbert at
> https://github.com/jackhumbert/pinebook-pro-keyboard-updater/
>
> Pine Store runs on wordpress
>
> No interest on Atheros 9K wifi chip due to thsi chip already EoL (End Of
> Life). Due to slim case design, not consider adding Ethernet port,
>
> Regards,
>
> Info team
>
> On 9/16/20 12:21, Wojtek Kosior wrote:
>
> > Hello,
> >
> > I'm looking for a 100% libre laptop and Pinebook Pro seems to be a
> > possibility. I wanted to ask some questions first, though.
> >
> > Is the trackpad and keyboard firmware ever going to be released as
> > freesw? I guess it's small enough it could possibly be
> > reverse-engineered... But what would be the point of geek-friendly
> > laptop if it required as much liberation effort as mainstream devices?
> >
> > Does the store work without nonfree js?
> >
> > Have You ever thought about using atheros wifi chip on your future
> > laptops? ;) And maybe adding an ethernet port?
> >
> > Regards,
> > Wojciech Kosior
The email failed domain authentication requirements...
What do You think?
Are Atheros chips really obsolete and should we look for some other libre ones?
Should I point it out to the Info Team in another email, that it's possible to use Wordpress to serve nonfree js?
Do You happen to know, if it's possible to make a purchase on pine64.org without nonfree js? (Pinebooks aside, there's also ROCKPro64 and its weaker friends)
Lastly, I have to admit - I earlier missed this[1] readme in keyboard updater repo. Had I read it, I obviously wouldn't be asking about about that in mail
[1] https://github.com/jackhumbert/pinebook-pro-keyboard-updater/tree/master/firmware
> Are Atheros chips really obsolete
They are pretty old and don't support 5GHz WiFi. The only reason to use one in a newly manufactured laptop would be to avoid the need for non-free firmware.
> should we look for some other libre ones?
There are no other libre ones.
> Do You happen to know, if it's possible to make a purchase on pine64.org without nonfree js?
If I recall correctly, when I ordered my Pinephone several months ago I found that the Pine64 store worked with JavaScript disabled up until the point where I had to pay, at which point I had to enable JS in order to pay with PayPal. I am not aware of a good alternative at this time. GNU Taler will fix this, but is not ready yet.
> Should I point it out to the Info Team in another email, that it's possible to use Wordpress to serve nonfree js?
No, that would be a waste of their time and yours. Answer your own questions by trying out the website yourself. If you find any specific problems, propose specific solutions.
> They are pretty old and don't support 5GHz WiFi.
This statement is laughable. Just for one example, My X40 uses one Atheros AR5001X (AR5212) mini PCI card (launched back in 2002), and it does support 5 GHz band. Every abg(n) card support 5 GHz band. See https://deviwiki.com/wiki/Atheros#tab=Wireless_chipsets
> This statement is laughable.
Not at all. It might possibly be partly inaccurate, that does not make it laughable in any sense.
Or do you seriously mean that a 2002 peripheral is still a recent device in 2020?
> They are pretty old and don't support 5GHz WiFi.
Nadebula seems to be right claiming that they do. Look at this RYF-certified one:
https://shop.libiquity.com/product/wifri-nd2h
> There are no other libre ones.
I know. I meant something along the lines of RE-ing a newer chip or prototyping one with SDR. Thinking long-term. Probably non of those is doable in less than a year anyway...
> If I recall correctly, when I ordered my Pinephone several months ago I found that the Pine64 store worked with JavaScript disabled up until the point where I had to pay, at which point I had to enable JS in order to pay with PayPal. I am not aware of a good alternative at this time. GNU Taler will fix this, but is not ready yet.
I think credit card payments are possible without js at all (I know, this kind of payment is kind of flawed, but it might be worth it if that makes it possible to avoid nonfree js). See [1]. Btw, RYF certification requires, that the product can be bought without running nonfree js. Btw2, that's the only reason Olimex didn't succeed in certifying its Freedombox...
And there's also crypto. Some shops related to software freedom accept it[2][3].
But yes, I'm also looking forward to GNU Taler kicking in :)
> No, that would be a waste of their time and yours. Answer your own questions by trying out the website yourself. If you find any specific problems, propose specific solutions.
Yeah, that's probably what I should do. In fact, I only asked about js in my mail, because I thought this way I might learn something I'd miss otherwise (+ I hoped I would save time).
Anyway, thank You for your response :)
[1] https://my.fsf.org/donate/
[2] https://store.vikings.net/payment
[3] https://www.thinkpenguin.com/cart/checkout
It's very easy to tell whether an Atheros card supports 5 GHz. Any abg(n) card supports 5 GHz whereas any bg(n) doesn't.
Of course, band support may be disabled in order to meet regional laws/regulations. For example, "802.11abg, a disabled" is a 2.4-GHz single band card, and "802.11 abgn, n disabled" is still 5-GHz capable but capped at 54 Mbit/s.
> Nadebula seems to be right claiming that they do. Look at this RYF-certified one:
Awesome! I'm glad to have been wrong about this.
> I know. I meant something along the lines of RE-ing a newer chip or prototyping one with SDR.
My understanding is that the ath9k-htc firmware was not liberated via reverse engineering, but by Chris from ThinkPenguin lobbying Qualcomm to free the source code. I don't know of a precedent for reverse engineering WiFi firmware, how much funding it would take, or what the liklihood of success is.
> I think credit card payments are possible without js at all... And there's also crypto.
They are. The problem is that many people are uncomfortable giving their credit card information directly to a small vendor. Many people are also uncomfortable or unfamiliar with crypto. So a vendor can have these as options, but risk driving some customers away unless they support a trusted method of paying with normal currency.
Some realtek wifi chips will work with a modern version of the linux-libre kernel without installing non-free firmware. Modern version as in newer than that supplied by Trisquel 8. Upgrade to something more recent than the 4.18 kernel with jxself's repo. I don't know which realtek chips work, but I have had one work for me and have read that some of the chips work. Might be some info available online if you do some creative duckduckgo or searx searches.
Yeah, I read about that in this topic[1]. Perhaps Chaosmonk doesn't consider those chips a reliable alternative to Atheros? Because it's difficult to predict which one will work and we don't know why some work? Idk why otherwise he could decide not to mention them here...
Unfortunately, Pinebook Pro's wifi is not a realtek, either. TERES I[2] has Realtek[3] (RTL8723BS). Would be cool if it happened to work.
I cannot find what chipset each chromebook has - I guess nobody includes such information in tech specs, because it would be meaningless for a typical John Smith buying a chromebook, lol. I only noticed, that some chromebooks have Atheros chipsets. What a shame those are the x86 ones :/
[1] https://trisquel.info/en/forum/usb-wifi-card-ar9271-does-not-work-after-update-debian-9-main
[2] https://www.olimex.com/Products/DIY-Laptop/
[3] https://github.com/OLIMEX/DIY-LAPTOP/blob/master/HARDWARE/A64-TERES/TERES-PCB1-A64-MAIN/Rev.C/TERES_PCB1-A64-MAIN_Rev.C.pdf
P.S. I just noticed some Realtek firmwares are only around 20-something or 30-something Kb in size[4]. Very little compared to several Mbs of Broadcom firmwares (if I recall correctly). If only we find out what the instruction set is, it should be a rather approachable RE-ing task. Btw, sometimes a big firmware might consist mostly of Linux or some other OS kernel used in it - in which case size might be misleading in judging the difficulty.
[4] https://github.com/rtlwifi-linux/rtlwifi_new/tree/master/firmware/rtlwifi
> Some realtek wifi chips will work with a modern version of the linux-libre kernel without installing non-free firmware.
I was under the impression this is because the non-free software is already burnt onto the device, but my only source for this is a discussion[1] on the Tails issue tracker which only makes this claim in passing:
"Do you think that a Realtek NIC that does not need uploaded firmware, but does use a burnt in ROM, cannot have a backdoor in its built in firmware, but a Broadcom NIC that requires firmware and does not use burnt in ROM can? That’s just silly."
and does not provide any evidence, but I have heard no other explaination as to how those WiFi cards work with Linux-libre given that there is no free firmware for them, other than nadebula's speculation that there is some bug.
Some have the stance that burnt in ROMs do not need to be free, as since the non-free software cannot be replaced, freedoms 2 and 3 would not be useful. However, I think that applying this principle to non-trivial software is a mistake. It creates a paradoxical, Tivoization-like loophole where something can be considered more free than something else when in practice the user actually has less freedom. It also ignores the importance of freedom 1. From the same Tails thread:
"If you select an FSF-endorsed distro, you are still running the same type of blob. The only difference is that it is bunt into your hardware, not in the kernel. If there is a backdoor, as you worry about, it will not be neutered just because it is distributed through a ROM rather than loaded by the kernel. If anything, loading
through the kernel is safer, because people are more willing to reverse engineer it or audit it (yes, closed source blobs can be reverse engineered and audited), whereas something burnt into a ROM will likely never be touched."
[1] https://gitlab.tails.boum.org/tails/tails/-/issues/5393
An unfortunate, and probably unintended, side effect of the FSDG's focus on the actions of distributions rather than the end result for users, is an overemphasis on *how* non-free software is distributed that leads to the problematic conclusion that non-free software is somehow not as bad if it is not loaded by the OS, which if accepted implies things like:
* You should keep running the specific version of the CPU microcode your computer came with when you bought it, even if there is a newer version that is no more non-free but less vulnerable to known security issues.
* A laptop that requires non-free software in order to use the built-in WiFi card is worse than one that requires non-free software in order just to boot.
* On a mobile phone with a modem kill switch, you should not install the firmware needed for your phone's WiFi card, even though doing so would make you less reliant on the also non-free and far more privacy-hostile modem.
You know, what? Sometimes it's diffucult to even decide if such software blob stored on ROM is really unmodifiable. Nowadays reprogrammable EEPROMs are common. Which means with an SPI flasher we would actually be able to read, reverse-engineer and rewrite ROM contents (well, that's the usual case with BIOSes). And even in case of a non-reprogrammable ROM chip it could be possible to desolder it and replace with our own, with changed contents. In most cases, the software code would have to be burnt in silicon during fabrication if we're to be sure it's unmodifiable. But even then, someone could lie and make us believe, that software is burnt in silicon, while in fact it would be stored on a reprogrammable non-volatile memory we don't know has been built into the chip...
If we assume the opposite of what You propose - that even unmodifiable software on ROMs should be free - we conclude, that either:
a) because we don't require HDL sources and other design files for hardware to be free, a device that does exactly the same thing entirely in hardware (i.e. without any software blob loaded from ROM) is entirely OK, even though it actually gives user less freedom (because, as I said, with some ROMs it'd be possible to read their contents and meddle with them...)
b) all hardware should be free, i.e. have sources available under a free license - I don't know how many ppl in Software Freedom Movement would give their support for that idea
What's more interesting, is that if we choose b), then even if we get some libre chip with sources, there is no feasible way to verify its circuitry has been synthesised from those sources ;)
That cited person's example of malicious blob assumes, that one's only motive to use libre OS and firmwares is for security+privacy. That's a trap we often fall into: to focus on what benefits free software can give us. That misses the point. As RMS said, looking for benefits of using free software is like looking for benefits of not being handcuffed...
Hey, don't think I think You don't know that :) I just thought this issue is worth mentioning.
Coming back to wifi chips - yes, using chip with on-ROM proprietary blob instead of OS-loadable one is not as good, as using a chip with free loadable firmware.
But are there really no benefits? The main reason nonfree sw is bad is because it puts users out of control. It usually shifts the control over a device from users to proprietary software vendor/developer. If we use OS-loadable proprietary firmware and update it from time to time, the creator of the firmware has more means of executing their control, that if the firmware was non-updatable.
Btw, it should be possible to put a hardware backdoor even on a chip, that uses free firmware. Perhaps it'd raise the cost of the device (adding to the chip a hidden ROM with malicious code, that starts executing under some special conditions?) and wouldn't be very feasible, but definitely possible ;)
I wrote all the above as if I wanted to oppose You here. But You know, what? I actually consider most of the points You made good. Just wanted to add something to the other side of the weight.
Sure, one could now conclude, that using OS-loadable proprietary firmware is OK freedom-wise, as long as we don't allow it to be updated...
If we want to resist nonfreeness, we have to draw a line somewhere. Only refusing OS-loadable proprietary firmware might seem a bit irrational for the reasons You presented. I just think - for the time being - it's more rational than other options, that come to mind. I don't exclude the possibility of later changing my mind on this matter :)
Btw, personally, unlike most ppl, I value software freedom over privacy and security. Sometimes it makes up for security features. E.g. if You only use free software on Your PC, then at least there's no proprietary program, that could make malicious use of some processor bug microcode would fix (doesn't apply to multi-user systems, I kno). If You don't use mainstream FF or Chrome, but some fork, then You might need to wait longer for some security updates, but if You additionally disable js, then You're more secure anyway
> You propose - that even unmodifiable software on ROMs should be free
That's not exactly what I meant. I meant that replacing non-free software with a non-free ROM does not give the user more freedom.
> That cited person's example of malicious blob assumes, that one's only motive to use libre OS and firmwares is for security+privacy. That's a trap we often fall into: to focus on what benefits free software can give us. That misses the point.
Sure, security and privacy should not be our only criteria. But when comparing two options, both of which are equally free or non-free, why ignore privacy or security?
> Sometimes it makes up for security features. E.g. if You only use free software on Your PC, then at least there's no proprietary program, that could make malicious use of some processor bug microcode would fix
I agree that proprietary software is more likely to be malicious than free software, but not all security vulnerabilities are intentional. Most are due to unintentional bugs that occur all the time even in free software. So even if you run a free userspace with free applications, you should still want the underlying system to be as secure as possible. Also, in the specific case of microcode, it is not a question of *whether* or not to have non-free microcode installed, but a question of *which version* of the non-free microcode you want (unless you are willing to buy a different computer). In "Who's afraid of Spectre & Meltdown?" by Alexandre Oliva, he writes
"Some of the mitigations depend on modified cpu microcode. That amounts to throwing non-Free Software at the non-problem. Who knows what undesirable features would be brought in along with the promised mitigations?"
Ok, lets accept for the sake of argument that newer microcode is more likely to have malicious features, and that we should be more worried about these hypothetical antifeatures than the known vulnerabilities that affect users of the older microcode. In that case, should users who buy new computers downgrade to older microcode? Should Trisquel provide older microcode in its repositories to help such users downgrade? I highly doubt that Oliva would argue this, because the FSF's framework for deciding what software to use is not about the freedom of users, but about making sure distributions don't get their hands dirty. So users should keep using whatever microcode version they received from their hardware manufacturer so that they don't have to get another version from their distro. Rather than focus on the fact that users have to run non-free software in the first place, they focus on how that software is distributed, even though that makes no difference to user freedom.
> If we want to resist nonfreeness, we have to draw a line somewhere.
I think this is the main thing I object to. Currently, it is impossible to avoid 100% of non-free software. If you "draw a line" between free and non-free software, the software on the "free" side will not form a useable stack that can run a complete operating system. We can come up with some loopholes and attempt to draw the line more cleverly so that the "free" side is usable, but the result is, as you seem to agree, irrational. More importantly, it makes people complacent by misleading them into thinking that we have already reached a point where we can live in complete software freedom, when in fact there is much more work that needs to be done. If we really want to resist nonfreeness, we need to influence reality like our enemies do, and we can't do that by drawing imaginary lines.
> Only refusing OS-loadable proprietary firmware might seem a bit irrational for the reasons You presented. I just think - for the time being - it's more rational than other options, that come to mind.
How about, instead of coming up with blanket rules for what is and is not acceptable and applying those rules to every situation even when this leads to silly conclusions, we do our best with the current state of affairs in each given situation, while in parallel working to improve the current state of affairs? This means not only taking into account what options we have now, but which options have more long term potential. This means recognizing when something is a dead end (like Purism's line of laptops) and when something might on paper look less free according to the FSF's flawed framework but does not suffer from the same fatal long-term flaws (Like Pine64's line of laptops). It also means acknowledging that certain problems can't be solved by telling someone to use different software. If someone's hardware needs non-free firmware, and there is no alternative firmware, the only solution is to buy new hardware or continue use the non-free firmware. If they can't afford to buy new hardware right now, but they want to start migrating to free software by replacing as much non-free software as they can, they ask the Trisquel forum how to get their hardware working. Our community guidelines are based on the FSDG, so we have to refuse to help them, and they either go back to whatever OS they were using before or choose another, less free distro. The result: the user is still running the non-free firmware that we didn't want them to run, and we've lost the opportunity to help them avoid other non-free software, all while probably hypocritically running non-OS-loaded non-free firmware or relying on SaaSS ourselves.
We have lost sight of the goal (user freedom) out of loyalty to a strategy (the FSDG) that was designed with good intentions and makes sense in theory, but when tested in the field has turned out to be flawed in practice. If we want to work torward our goal, we need to refine our strategy so that it leads to the desired outcome in more situations.
Here is an example of a forum thread here in which I was on the wrong side of an argument because I was biased by the FSDG: https://trisquel.info/en/forum/trisquel-arm-pinebook-pro-running-trisquel-trisquel-touch
I was overly dismissive of the Pinebook Pro because of the non-free WiFi card it comes with. Another user pointed out that any ARM laptop is superior freedom-wise to an x86 laptop due to x86's fatal freedom issues. I dismissed this argument at the time, but looking back they were right and I was wrong. The mistake I made was basing my evaluation on how well a hypothetical laptop would work out-of-the-box with a FSDG distro like Trisquel. An x86 laptop with an Atheros card would work fine, because none of the proprietary crap would be OS-loaded, which led me to ignore the significance of that proprietary crap and not give the Pinebook Pro enough credit for not having it.
Here's another time I was wrong: https://trisquel.info/en/forum/intel-wifi
A user wanted to switch to Trisquel, but their WiFi card didn't work. I wrote
"Since Trisquel is a free replacement for Ubuntu, including non-free software would defeat the purpose."
I remember that as I was writing that I thought "Well, I guess if someone was temporarily stuck with a non-free WiFi card but didn't want all of Ubuntu's other non-free crap, it would be objectively better for them to use a version of Trisquel where the only non-free software was WiFi firmware". But I didn't acknowledge this openly, because I was focused on defending the validity of the FSDG rather than on what was best for that user's freedom. They were driven away and never posted here again. I don't know what software they are using today, but if we had instead welcomed them into the community and got them started migrating to free software, maybe by now they would have had an opportunity to buy a new machine and we could have helped them choose one that was less freedom-hostile, and in the meantime they could have focused on migrating toward a free userspace.
I was writing an overly long response and accidently closed the browser tab :/
I'll try to keep it shorter in this attempt.
>> You propose - that even unmodifiable software on ROMs should be free
>
> That's not exactly what I meant. I meant that replacing non-free software with a non-free ROM does not give the user more freedom.
Sorry for this slight misunderstanding. The sentence "It also ignores the importance of freedom 1." made me think You mean that.
It indeed doesn't give users more practical freedom. But I still think ROMs are more acceptable ethic-wise. When we refuse to run nonfree software, we stand up against developer's unethical practice of releasing it as nonfree. There's less to stand up against in case of unmodifiable ROMs.
Perhaps calling ROMs less nonfree is not strictly correct. Perhaps we should say "less unethical". Idk.
> But when comparing two options, both of which are equally free or non-free, why ignore privacy or security?
If I indeed considered 2 options equally nonfree and equally unethical (which is not the case here), I would prefer the more secure&private one.
> Also, in the specific case of microcode, it is not a question of *whether* or not to have non-free microcode installed, but a question of *which version* of the non-free microcode you want
The same thinking can be applied here. There's slight difference - we could stand up against computers, that are designed to be more secure when used with future nonfree microcode. I find it reasonable to prefer ARM because of that. Still, a computer that can be used (although with poorer security) without BIOS-loaded or OS-loaded microcode updates is still more ethical than one, that would require those for normal operation.
Or maybe we should recommend against using processors without any microcode, because they don't give users more freedom? ;)
> [...] the FSF's framework for deciding what software to use is not about the freedom of users, but about making sure distributions don't get their hands dirty. So users should keep using whatever microcode version they received from their hardware manufacturer so that they don't have to get another version from their distro. Rather than focus on the fact that users have to run non-free software in the first place, they focus on how that software is distributed, even though that makes no difference to user freedom.
It makes, in the long term. Distributing nonfree microcode or firware with the distro would make this nonfreeness seem more OK, and would for example make use of x86 with ethical distros more appealing, thus hampering the migration to other hardware platforms.
>> If we want to resist nonfreeness, we have to draw a line somewhere.
>
> I think this is the main thing I object to. Currently, it is impossible to avoid 100% of non-free software. If you "draw a line" between free and non-free software, the software on the "free" side will not form a useable stack that can run a complete operating system. We can come up with some loopholes and attempt to draw the line more cleverly so that the "free" side is usable, but the result is, as you seem to agree, irrational.
Ever since learning about free software a few years ago, I had many lines drawn. As You have noticed, there's always some nonfree thing, that slips to the "free" side. Still, having an "imaginary line" or some "blanket rules" helps me get rid of those things, that are already on the other side of the line. And then I can redraw the line a few steps closer to full freedom.
In the past there were no computers with fully free boot firmware, and yet FSF didn't recommend ppl to completely stop using computers. Even further b4, when GNU project was starting, free compilers and OSes were not yet available and even first freesw enthusiast had too use nonfree ones (ever heard that joke about compiler backdoor possibly introduced into the first version of GCC?
> I was writing an overly long response and accidently closed the browser tab :/
Sorry, I hate it when that happens. I've gotten into a habit of periodically copying my draft to the clipboard in case I do something like that.
> When we refuse to run nonfree software, we stand up against developer's unethical practice of releasing it as nonfree. There's less to stand up against in case of unmodifiable ROMs.
As a thought experiment, let's take this to an hypothetical extreme. Imagine that all software is burnt onto a ROM. Your OS is burnt onto a ROM, and you upgrade it by buying a new computer. Applications are burnt into ROMS and inserted into the computer as cartridges. You upgrade them by buying a new cartridges to replace the old ones. This prevents developers from forcefully updating the software you run, but it also prevents you from modifying the software yourself, or even from running software that you wrote from scratch. All power would lie in the hands of hardware manufacturers, and the only way to exercise software freedom would be to become a hardware manufacturer. Maybe you can afford the equipment to produce your own cartridges to use for yourself and share with some friends, but in order to mass produce copies to share with the world you would need a factory, which in our current economic system is something only large companies can afford.
This would clearly be terrible for software freedom, and hopefully clarifies why I think it is a mistake to advocate non-free ROMS as a replacement for non-free OS-loaded firmware. It is at best a step sideways, if not a step backwards (since you are giving up on even the hypothetical possibility of reverse engineering the firmware in the future), and so treating it as a step forward misleads people into thinking that progress has been made when it hasn't.
> Or maybe we should recommend against using processors without any microcode, because they don't give users more freedom? ;)
If the microcode still exists and is just burnt onto a ROM and is still non-free, then that's right, it does not give users more freedom and should not be presented as a solution. If the processor simply does not need any microcode, then that's the equivalent of removing the need for a non-free dependency, so it does give users more freedom and should be recommended.
> Distributing nonfree microcode or firware with the distro would make this nonfreeness seem more OK, and would for example make use of x86 with ethical distros more appealing, thus hampering the migration to other hardware platforms.
By this logic, the FSDG should forbid distros from even supporting x86. The fact that Trisquel can be run on an X86 machine (actually, at this time it can *only* be run on x86 machines) implies that it is okay to do so, even though x86 processors require non-free microcode. The current microcode policy does not send the message than non-free software is wrong. It sends the message that non-free software is wrong when supplied by a distro, but okay when supplied by a hardware vendor. The only users who receive a different message are those who don't know what microcode is or that it is running on their processors when they use Trisquel. What is more unethical, being open about the need for non-free software to support certain architectures and informing users of the various tradeoffs between different approaches of dealing with this, or just not telling them about the non-free software and letting them believe they are more free than they are in order to keep your hands clean?
> In the past there were no computers with fully free boot firmware, and yet FSF didn't recommend ppl to completely stop using computers. Even further b4, when GNU project was starting, free compilers and OSes were not yet available and even first freesw enthusiast had too use nonfree ones
Exactly. And did the FSF waste time coming up with loopholes in order to declare this non-free software somehow okay? Or did they acknowledge this non-free software as a short-term necessary evil and work toward a world in which it would no longer be necessary?
> Sorry, I hate it when that happens. I've gotten into a habit of periodically copying my draft to the clipboard in case I do something like that.
It's OK. I think my final response was better, than the one I lost.
> This would clearly be terrible for software freedom
This would have nothing to do with software, and hence software freedom. It would be a hardware freedom issue. Should we care about hardware freedom? I think we should, at least to some extent. I just don't think we should mix the two (hardware freedom and software freedom) together.
Yes, cartridges could be considered software-like, since they are designed to be replaceable. Not the case with wifi chip on a motherboard.
> If the processor simply does not need any microcode, then that's the equivalent of removing the need for a non-free dependency, so it does give users more freedom and should be recommended.
How can it give user more it the thing other processor did using nonfree replaceable microcode, is now done in circuitry?
I know this is not always the case. Some architectures (RISC ones) just put more burden on the compiler to express complex operations using simpler instructions and trade small executable code size for design simplicity. Still, there definitely were processors, that did in circuitry, what current x86 does in microcode, so this example is not void.
> It sends the message that non-free software is wrong when supplied by a distro, but okay when supplied by a hardware vendor.
I still don't consider burntin microcode software, so I don't agree with this statement.
How would be ethical distros different from, say - Debian, if they started including nonfree microcode and firmware?
Coming back to Pine - Pinebook Pro has a "PCIe 4x for an NVMe SSD drive". Do You think it would be possible to use this PCIe slot for a wifi card? I've never done such thing. Could there be problems with stably mounting the card or something like that? I know I probably won't find an answer here, but I lose nothing asking.
> This would have nothing to do with software, and hence software freedom. It would be a hardware freedom issue. Should we care about hardware freedom?
Right now the tools necessary to exercise hardware freedom are not accessible to normal people. We should care about hardware freedom, but fewer people benefit from it than from software freedom right now. If some future technology resembling 3D printing made it possible to easily copy, modify, and redistribute hardware, then this might change.
Currently though, shifting things from the software domain into the hardware domain reduces user freedom. As an analogy to Service as a Software Substitute[1] we could call it Hardware as a Software Substitute. It takes something that could be within the user's control if it were in the form of software, and moves it to another domain in which it is out of the user's control, robbing them of their freedom.
[1] https://www.gnu.org/philosophy/who-does-that-server-really-serve.en.html
> How can it give user more it the thing other processor did using nonfree replaceable microcode, is now done in circuitry?
You didn't specify where the thing was now being done. You could have meant the kernel, or that the new thing did not need to be done anymore at all because the design had been simplified. If everything is the same except that something that could be done in software is now being done in hardware, then you're right. This would not improve user freedom either. You might as well just use non-free microcode.
>> It sends the message that non-free software is wrong when supplied by a distro, but okay when supplied by a hardware vendor.
> I still don't consider burntin microcode software, so I don't agree with this statement.
To clarify, we have been discussing two different situations: Burnt in ROMs, and updatable microcode. The updatable microcode is software. When you buy a new computer, it will likely ship with its microcode updated to the latest version. If a computer running Trisquel previously ran another operating system, that operating system was probably keeping the microcode up to date as well. Even if the microcode on your machine has not been updated since it was originally manufactured, it is still software. Choosing not to update software does not make it hardware, nor does it make it free.
> How would be ethical distros different from, say - Debian, if they started including nonfree microcode and firmware?
The main difference is that they would not include non-free userspace software like applications or drivers, or any documentation on how to install it.
However, this difference would not be enough. My other problem with the FSDG is that it only addresses what software should be excluded or ommitted. I have been relatively successful in my local community promoting the adoption of free software, not be pretending that non-free software does not exist and refusing to discuss it, but by proposing alternatives that meet people's needs. The FSDG does not require distros to do this, but a freedom-focused distro should be actively promoting free replacements for anything that users are likely to need. This includes not only replacements for non-free desktop software, but non-free web services/applications and tasks that users would otherwise do on their phones.
For example, most Trisquel users probably use their phones or use Google Maps in Abrowser to lookup directions. Some of them might have heard that OpenStreetMaps exists, but the web interface is so terrible, as are most desktop clients, that even if they have given it a try they probably don't use it regularly. Therefore, it would be good for user freedom if a distro were to promote the most usable OSM client they can find (the best I have found so far is GNOME Maps).
We should also consider the possibility that our actions will lead users to install non-free software when they didn't have to, even if we didn't mention that software by name. For example, Lutris is not something an FSDG distro could package as-is, even though it is free software, because it contains recipes for non-free games. Lutris might be includeable with modifications to remove these recipes. Otherwise it must be excluded entirely. Either way though, the most likely outcome for a gamer who has switched to Trisquel is not that they will give up every game that they like playing, but that they will instead go online and install Steam, unaware that they might have avoided the need to use Steam by installing their games through Lutris instead, and that there are also some free games out there that they might enjoy too.
Consider if instead, a distro were to package Lutris, but modify it so that non-free games only appear in the interface if the user specifically searches for them by name (and warns that the game is non-free), otherwise only suggests free games, and actively promotes high quality games under free licenses. This would not meet the letter of the FSDG, but I suspect that it would do more to prevent users from installing Steam and getting them to play and support free games than it would to guide users toward non-free games that they didn't already know about.
> Coming back to Pine - Pinebook Pro has a "PCIe 4x for an NVMe SSD drive". Do You think it would be possible to use this PCIe slot for a wifi card?
I'm not sure. I think this would be a reasonable question to ask Pine64.
> If some future technology resembling 3D printing made it possible to easily copy, modify, and redistribute hardware, then this might change.
FPGAs? :)
Well, joking here - FPGA bitstream is just software in FSF's sense.
Hardware is different conceptually from software. With sw, one distributes copies. With hw, one distributes physical objects. With nonfree sw one is prohibited from modifying the code and sharing copies with others. With hw one can legally modify the physical object they possess (except maybe some pathological EULAs we should object to) or lend it to a friend for some time.
Who knows what other differences we might notice if we think about it longer.
Also, accepting nonfree hw vendors poses lower long term freedom risk that with nonfree sw, because it's unfeasible to do complex things in hardware alone.
With ROMs it's maybe easier to make something complex than in pure circuitry, but still one would reach the point, where it becomes unfeasible, hence the same argument applies.
And also, as I mentioned at the beginning of this discussion, there are few kinds of ROMs. Some of them also considered problematic by the FSF (otherwise there'd be no free BIOS campaign). To use a true ROM is more unfeasible for hw manufacturer in many cases.
> If everything is the same except that something that could be done in software is now being done in hardware, then you're right. This would not improve user freedom either. You might as well just use non-free microcode.
That makes things complicated. Many online sources state, that ARM doesn't use microcode, because it implements everything in circuitry. That would make it worse than x86, but those online sources are likely to overlook the fact, that modern x86 is just RISC underneath and the microcode is likely used to abstract it to the CISC instruction set we know. That's what I referred to, when I wrote about RISC processors putting more burden on the compiler.
Now, to decide which processors are free-er, one needs to verify, how much of the instruction set is implemented in hardware and how much in microcode, which is not even possible until we know the inner workings of the microcode.
I'll just stick to preferring CPUs without any nonfree microcode.
> When you buy a new computer, it will likely ship with its microcode updated to the latest version. If a computer running Trisquel previously ran another operating system, that operating system was probably keeping the microcode up to date as well. Even if the microcode on your machine has not been updated since it was originally manufactured, it is still software. Choosing not to update software does not make it hardware, nor does it make it free.
I thought, that microcode updates performed by OS or BIOS are not made persistent in the CPU (at least in case of processors currently dominating the market), but rather they need to be reapplied on every boot. One source, that suggests this, is [1]. I shall consider this true unless You prove it wrong.
Now, if we have a free BIOS and a free OS, none of which loads microcode, the CPU shall be executing the default version of microcode, that's burnt in silicon, making it hardware.
> I have been relatively successful in my local community promoting the adoption of free software, not be pretending that non-free software does not exist and refusing to discuss it, but by proposing alternatives that meet people's needs.
Interestingly, I once saw a wave of hate towards ppl recommending freesw replacements for programs on Fediverse (can't find links for that atm). I'm glad at least You had some success.
> The FSDG does not require distros to do this, but a freedom-focused distro should be actively promoting free replacements for anything that users are likely to need. This includes not only replacements for non-free desktop software, but non-free web services/applications and tasks that users would otherwise do on their phones.
That itself doesn't sound bad.
> For example, most Trisquel users probably use their phones or use Google Maps in Abrowser to lookup directions.
I thought most ppl dedicated enough to switch to an FSF-endorsed distro would care enough to also switch to OSM... I guess that's not easy to verify, though.
> Consider if instead, a distro were to package Lutris, but modify it so that non-free games only appear in the interface if the user specifically searches for them by name (and warns that the game is non-free), otherwise only suggests free games, and actively promotes high quality games under free licenses. This would not meet the letter of the FSDG, but I suspect that it would do more to prevent users from installing Steam and getting them to play and support free games than it would to guide users toward non-free games that they didn't already know about.
Reading RMS' article on compromises we could say, that those ppl would indeed be using more freesw (Lutris instead of Steam), but wouldn't do so for right reasons and would be likely to go back to the proprietary tool once they notice something convenient in it.
I'm not saying I'm convinced. However, if You think You can make ppl start caring about actual software freedom this way, then start Your own distro.
I admit, I'm interested in how that would work out. You could just create a PPA to use on top of some other distro. It might be best to do that on top of an already-nonfree distro like Ubuntu, so as not to risk harming Trisquel.
But if it turns out it was a bad idea - well, You have been warned ;)
[1] https://libreboot.org/docs/hardware/c201.html#no-microcode
Regarding hardware/ROMs vs software: My argument was that due to the different nature of hardware, which you acknowledge, moving something from the software to the hardware domain reduces user freedom similarly to SaaSS. "Fixing" freedom issues by replacing non-free software with a burnt in ROM has the same problem as "fixing" them by replacing them with a service, which is that it's just a loophole that transfers power to someone other than the user. You didn't address this argument in your reply, but if you do address it I'm happy to keep discussing it. Maybe I'm wrong.
> Also, accepting nonfree hw vendors poses lower long term freedom risk that with nonfree sw, because it's unfeasible to do complex things in hardware alone.
Is your argument here that only sufficiently complex things require freedom, and that it is not as important for simple things? I definitely see an argument for that. If we were to draw a line between what does or does/not need to be free, doing so based on complexity would make a little more sense to me than doing so based on medium or domain.
> I thought, that microcode updates performed by OS or BIOS are not made persistent in the CPU (at least in case of processors currently dominating the market), but rather they need to be reapplied on every boot.
It seems you are right about this, and that I was mistaken about the mechanism used for microcode updates. This makes the situation more similar to that of burnt-in ROMs than I realized, though still distinct in that the user can choose between using the burnt-in ROM or alternative OS-loaded firmware. With this in mind, I'll have to think about this more and form a new opinion.
> I thought most ppl dedicated enough to switch to an FSF-endorsed distro would care enough to also switch to OSM...
That requires them to know that it exists and find a usable client. I didn't learn about OSM until well after I switched to Trisquel, and even then it was a long time before I found a usable client. After I upgraded from Trisquel 8 to Trisquel 9 and got a newer, less buggy version of GNOME Maps was I able to start using OSM regularly.
> I guess that's not easy to verify, though.
True, but any mailing list user can see how many Trisquel users are still using Gmail.
> Reading RMS' article on compromises we could say, that those ppl would indeed be using more freesw (Lutris instead of Steam), but wouldn't do so for right reasons and would be likely to go back to the proprietary tool once they notice something convenient in it.
Are you referring to this article[1] about non-free games? To adapt it for this discussion, I'm going to replace "GNU/Linux" with "Lutris" and "Windows" with "Steam".
"Nonfree game programs (like other nonfree programs) are unethical because they deny freedom to their users. (Game art is a different issue, because it isn't software.) If you want freedom, one requisite for it is not having or running nonfree programs on your computer. That much is clear.
"However, if you're going to use these games, you're better off using them [via Lutris] rather than [via Steam]. At least you avoid the harm to your freedom that [Steam] would do.
"Thus, in direct practical terms, this development can do both harm and good. It might encourage [Lutris] users to install these games, and it might encourage users of the games to replace [Steam] with [Lutris]. My guess is that the direct good effect will be bigger than the direct harm. But there is also an indirect effect: what does the use of these games teach people in our community?"
What I'm proposing is to optimize Lutris to maximize the potential good and minimize the potential harm, while clarifying to users the intent behind our actions in order to avoid teaching them the wrong lesson. Trisquel instead avoids addressing the messy issue of freedom in gaming, and as a result I would be willing to bet that there are more Trisquel users with Steam installed than there are Trisquel users with Lutris installed.
> However, if You think You can make ppl start caring about actual software freedom this way, then start Your own distro.
I am typing this from my own distro. :)
> I admit, I'm interested in how that would work out.
For the first couple years of my free software advocacy in my local community, I attempted to convert people to Trisquel. At first I tried to get them to use Trisquel as-is, with no non-free software. I purchased a bunch of USB WiFi dongles from ThinkPenguin to give to people whose internal WiFi cards would not work without non-free firmware. However, I quickly learned that this is simply too much to ask of busy students who need to keep up with their work and cannot afford to have their Internet connection interrupted every few minutes. The first few people I tried to convert (with the exception of one lucky enough to have an older computer with an internal Atheros card) eventually told me that although they otherwise liked Trisquel they would have to reinstall Windows or macOS unless they had working WiFi.
So I decided I would make one compromise: WiFi firmware. I was worried that this would become a slippery slope, but in the end it did not. I got more people to switch to Trisquel, with the only non-free software I installed being WiFi firmware, and within a year many people around me had gone from using mostly non-free software to using mostly free software.
I then began to look at what remaining non-free software they were still using. Most of it was either webapps like Gmail or Google Maps, or they had gone online and installed Spotify and/or Steam. I realized that it wasn't enough to provide people with a free base and desktop starting point, but also needed to provide them with tools and guidance to keep them replacing other non-free applications and services. So I would set people up with GNOME Maps, help them sign up for Disroot, show them Invidious, etc. (I only recently discovered Lutris but plan to try it out as something people can replace Steam with).
Eventually I got sick of having to make all of these customizations to Trisquel every time I installed it for someone (and various non-freedom-related problems of Trisquel and Ubuntu-derivatives in general). Instead I began working on distro that would be optimized to facilitate migration to free software using the strategies that I had found to be most effective through trial and error, and communication with and observation of users. I have not distributed it over the Internet, only in person, and it has gone through multiple iterations as I learn through experience what is effective for various kinds of users.
By the way, several of the people I partially converted to free software have since had an opportunity to buy a new computer, and when they did so they made their decision with free-software compatibility in mind, so in the end a compromise that I hoped would be both strategic and temporary indeed turned out to be so. I advocate solving as many problems as one can as soon as they can. That means not delaying migration to a free userspace by insisting that people *first* buy new hardware, but making sure that the problems with their hardware are understood so that they can solve those too when they have a chance.
> It might be best to do that on top of an already-nonfree distro like Ubuntu, so as not to risk harming Trisquel.
Originally it was based on Debian stable, with important applications backported from Debian testing in order to create a semi-rolling distro. I am currently trying out a new approach which only uses Debian for the base system and desktop, and uses Guix for applications.
Sorry, it looks like I can't keep sparing so much time on the discussion on FSF's analogy to circuitry.
If I decided to reply in this matter one more time, You would also reply and then I'd be pushed to reply yet again, spending more and more hours on it - I just can't do that.
> Are you referring to this article[1] about non-free games?
No, I was referring to https://www.gnu.org/philosophy/compromise.html
I didn't link to it, because I already did so in my earlier post and I assumed someone reading the entire discussion would remember it. Turns out that's not the case.
It's good to hear, someone actually succeeds in promoting sw freedom.
I'm a bit surprised, You didn't actually point us to that distro. I guess that could count as recommending nonfree sw, so maybe that's why?
Acknowledging successes, I'd still consider FSF-endorsed distros the ultimate goal for those, who truly care.
Btw, to bring the concept further, we could do with a browser extension, that would recommend replacement freedom-friendly services, whenever user opens a website of some hostile one. We could call it "Freedom Dictator" :)
> If I decided to reply in this matter one more time, You would also reply and then I'd be pushed to reply yet again, spending more and more hours on it - I just can't do that.
Fair enough. It's pretty far off from the original topic anyway.
> No, I was referring to https://www.gnu.org/philosophy/compromise.html
Ok, I was aware of that one too. I just thought you might be talking about the non-free games one since that is the most similar situation to Stean/Lutris that RMS has directly addressed.
> I'm a bit surprised, You didn't actually point us to that distro. I guess that could count as recommending nonfree sw, so maybe that's why?
I am not distributing it online yet. I want to keep working on usability and set up channels for online support first. I also want to continue experimenting with different approaches as to what actually works in terms of guiding users toward software. If a decision backfires with the small number of people currently using it, I would like to learn that and change course before I start trying to expand the user base. And finally, even when I am ready to distribute it online, I will probably not promote it here. The purpose of the distro is to be an effective migration tool toward freedom. The target audience is people who want to migrate to free software, not people who already have.
> Acknowledging successes, I'd still consider FSF-endorsed distros the ultimate goal for those, who truly care.
If you had said that "FSDG distros" are the ultimate goal that would be one thing, but since you said "FSF-endorsed distros" I have to bring up PureOS. PureOS does not even follow the FSDG, and the list of FSF-endorsed distros lost credibility when PureOS was added, even (or especially) if you agree with the FSDG itself. In addition to all the issues I identified here[1][2], here is their repo[3] for the Librem 5's non-free WiFi firmware. Unfortunately, the Librem 5 has been advertised as running an "FSF-endorsed" distro, so people have been preordering the device under the impression that it will not require firmware blobs. Right now Purism and the FSF are doing much more to guide users toward non-free firmware than I am. If you have a problem with non-free firmware, they are the ones to be arguing with.
> Btw, to bring the concept further, we could do with a browser extension, that would recommend replacement freedom-friendly services, whenever user opens a website of some hostile one.
Maybe someone could fork "Privacy Redirect" (which currently redirects YouTube->Invidious, Instagram->Bibliogram, Google Maps->OSM, and Twitter->Nitter) to create "Freedom Redirect", which adds additional redirects based on freedom in addition to privacy.
[1] https://trisquel.info/en/forum/another-path#comment-150090
[2] https://trisquel.info/en/forum/another-path#comment-150091
[3] https://source.puri.sm/Librem5/redpine-firmware-nonfree
[1] https://addons.mozilla.org/en-US/firefox/addon/privacy-redirect/
> No, I was referring to https://www.gnu.org/philosophy/compromise.html
> I didn't link to it, because I already did so in my earlier post and I assumed someone reading the entire discussion would remember it.
What earlier post of Yours are You referring to? Maybe it was part of the casualties when You accidentally closed that browser tab?
Without providing the appropriate psychoactive substances, one cannot reasonably expect people to remember links which were never posted.
Thanks for having initiated that illuminating discussion anyway.
Given that very few Realtek cards do work with Linux-libre without loading any non-free firmware, they are still designed to work with firmware. There are dedicated memory and processor to run firmware, and therefore can still be exploited to attack the host's (user's) system. The user cannot defend him/herself against such firmware-level attack, because the user cannot access internal working of such peripheral with dedicated memory and processor.
- Inicie sesión ou rexístrese para enviar comentarios