Re: How many of you actually only use Libreboot/RYF computers?
- Login o registrati per inviare commenti
Here're my last 2 comments from this thread, restored from trash:
"> It seems the 2 resources you linked to — versus.com and Asahi docs — make conflicting statements about the presence of TrustZone in M1. Perhaps Asahi is right after all and there's indeed no TrustZone in that SoC?
No? The mobile chips have it, but the M1 and later is a desktop class SoC.
"TrustZone technology was proposed in 2002, but did not get widely used until 2009, when Apple released iPhone 5s. In iPhone 5s, Apple leveraged TrustZone to protect its Touch ID, which ensures that even if the iOS is fully compromised, the user's fingerprint data can still be safe." https://www.researchgate.net/publication/330456325_Research_on_ARM_TrustZone
> We've been assuming different meanings of "works with free software", hence the disagreement. When I see a platform that requires signed blobs to even boot, I call it "fatal" regardless of the ability to run a 100% libre OS. And when I see a platform that boots without blobs but requires the OS to supply them for particular functionalities (e.g. video output, GPU acceleration, WiFi...) I call these "flaws" of "non-fatal" severity.
No. You haven't been specific with "software freedom", so I deliberately avoided other issues (no computer is usable blobless). The Respect Your Freedom program practically requires the bootloader/BIOS and operating system to be free, and that all hardware to be usable with it. Not everyone will settle with this.
> Your beliefs are rather cruel :c
I didn't mean to look down on you. It's for knowledgeable audience, so I won't expect anyone to understand it. My expectations are reasonable.
> me_cleaner and similar stuff are mostly interesting to me when it comes to giving advice to others.
I would advice against doing so, as that would imply a false sense of security (me_cleaner as solution). From what I read, me_cleaner is experimental and IME is tightly integrated within the CPU die and on chipset, some parts of the hardware will possibly stop working after it has been "neutered" and it can cause permanent damage, all while not disabling the backdoor. Here're solutions what I can recommend (for laptop form-factor):
legacy - Lenovo G505s (2013) - AMD A10, 16GB of RAM, 1TB harddrive, partially-free EC firmware, partially-open AtomBIOS, no Platform Security Processor (PSP), need 3rd party to install coreboot: http://dangerousprototypes.com/docs/Lenovo_G505S_hacking, should require blob for AMD GPU, non-free SMU (https://notabug.org/qmastery/libreboot/src/master/docs/candidates.md) - cost €150 + flashing
current - Pinebook Pro (2019) - free software out-of-the-box, 1080p IPS, privacy switches (cuts power from camera/wifi/microphone), keyboard 9/10 in my opinion, touchpad suitable for daily driving* (1001PX leagues ahead), speakers ok for voice (no complain at all), music doable but not suitable (bad), magnesium-alloy top and bottom (the rest is plastic), 4GB RAM (RK3399 can only use up to 3.5GB), 64GB eMMC, quickboot with levinboot, Manjaro KDE Plasma, should work 100% blobless at bootloader + OS level with external USB WiFi and no video output, internal PCIe wifi possible: https://github.com/TobleMiner/PBP-NGFF-A-E-adapter, but complex and unknown to work with ath9k-based cards, (there's more) - €150 second-hand
future - Apple M1/etc. (2020 and later) - preferably with 16GB RAM to prevent SSD failure. I saw a Macbook Air M1 8GB RAM/512GB brand new unopened for €400. Asahi GNU/Linux should be already usable on a Mac Mini M1 despite being alpha (no speaker support/etc. on Macbooks atm)
* firmware update + 0,5 sensitivity (Manjaro) / 0,75 (Armbian) + Brave browser (scrolling is much smoother than with Firefox) + Wayland (no screen tearing)
> Since not everyone has the means (intellectual, financial, etc.) to use a device with libreboot, deblobbed U-boot or similar, a device with Intel ME disabled and crippled might be considered the next best option.
I highly disagree. This is where I see the free software community as hypocritical. From one side, people here are vocal about using purely free operating systems and ethically compatible hardware and would wipe the whole OS if it would recommend any "unfree" software when there are better alternatives, while they also run and recommend non-free software and hardware to others. A Pinebook Pro or an Apple Silicon Mac should be sufficient for anyone with the latter being reasonably more secure than the x86 alternatives.
> I admit it is slightly better than I expected from Apple. If all this is true, this behavior is indeed a bit fairer than that of e.g. a stock Intel ME.
My opinion is clear. I believe *this* is the solution out from the backdoored x86 situation. Libreboot/pre-PSP was the only option at first, then Rockchip came as an intermediate solution with Libreboot on Asus C201 and RK3399 later on (most notably the Pinebook Pro). The x86 architecture is also flawed for its instruction-set (CISC), so a RISC-based replacement was always the solution down-the-road. But it wasn't until 2020 when this was fulfilled and it took Apple over a decade to happen. I would cite MicroLinux's YouTube channel intro here: "You are approaching the future.. and it is ARM ... based..": https://invidio.us/watch?v=5tfgLV520Gk "
And the answer to koszkonutek's reply:
"> Well, maybe. I admit instead of basing on your link I looked at other pages on versus.com where Apple M1 was marked as having TrustZone[1].
> [1] https://versus.com/en/apple-m1-vs-intel-core-i7-3635qm/trustzone
You're correct, I was looking at mobile chipsets. That's why I wasn't able to see the Mx's: https://versus.com/en/cpu?filter[]=trustzone=true.
> Then sorry for not realizing the specificity required in this discussion.
Trisquel follows the principles defined by the FSF (hence RYF), but I prefer a more open approach on lower-level hardware if possible. That means rewritable ROMs with updateable firmware, and free software firmware on e.g. SSD's. This can extend the lifespan of the hardware while making it more hacker friendly. I'm not attacking you. I'm attacking your beliefs.
> Well, good. Because for most of this discussion I am having the opposite feeling :/
I've already addressed this with my previous comment about hypocrisy.
> Actually, to high extent I agree with this statement. Not excluding POWER, MIPS and RISC-V, of course.
POWER is for the server sphere, MIPS I remember with the Yeeloong netbooks running gNewSense, RISC-V is mostly for embedded computing.
> Lol, the thing that keeps me in this thread is the shock from seeing M1 being recommended. With a bootloader that is not just nonfree and signed but also encrypted!
I could say the same the opposite way. Is it impossible to replace the bootloader with custom code like it is with IME/PSP?
> Although ARM laptops with free and mostly-free bootloaders might not yet be as powerful, the best solution seems to be patience
Patience doesn't move mountains. Waiting for something to happen just doesn't solve anything."
Hi again!
> > me_cleaner and similar stuff are mostly interesting to me when it comes to giving advice to others.
>
> I would advice against doing so, as that would imply a false sense of security (me_cleaner as solution).
I didn't actually mean it as a real solution. Just as a partial mitigation when better options are not reasonably available.
> > Then sorry for not realizing the specificity required in this discussion.
>
> Trisquel follows the principles defined by the FSF (hence RYF), but I prefer a more open approach on lower-level hardware if possible. That means rewritable ROMs with updateable firmware, and free software firmware on e.g. SSD's.
What exactly do you mean by "rewritable ROMs"?
I recall RYF treats ROMs executed by device's primary processor(s) and device's secondary processors differently. IIRC, for secondary processors the mere possibility of rewriting the ROM (as with ThinkPad's EC firmware which can be externally reflashed) does not need to be a hindrance to RYFing the device.
Is it the treatment of primary processor ROMs that you mostly disagree with?
Or maybe by "open approach" you mean e.g. that reasonable principles should not just *allow* but *require* ROMs with nonfree software to be easily rewritable?
With "free software firmware", I don't yet know what to respond because I don't even know FSF's current stance on the SSDs' firmware. An SSD that's not *meant* to ever have its firmware updated is certainly acceptable as a component in RYF devices. But what about SSDs that make firmware updates *optional*?
Want to know my personal approach to SSDs? Right now I don't care much and just use whatever drives are available without investigating whether they support firmware updates. And if at some point a reasonably usable SSD with free software firmware becomes reasonably well available, I shall gladly switch to buying and recommending it instead.
> This can extend the lifespan of the hardware while making it more hacker friendly.
Well, true
> I'm not attacking you. I'm attacking your beliefs.
Gotta remember that statement. It could enable me to say I am not attacking people while being pretty much free to attack them ^^
;)
> > Well, good. Because for most of this discussion I am having the opposite feeling :/
>
> I've already addressed this with my previous comment about hypocrisy.
You mean when you wrote the following?
> This is where I see the free software community as hypocritical. From one side, people here are vocal about using purely free operating systems and ethically compatible hardware and would wipe the whole OS if it would recommend any "unfree" software, while on the other hand, they also run and recommend non-free software and hardware to others.
Why at all call people out as hipocritical? Isn't it that the best way to have a fruitful discussion is with as little accusations as possible?
I recommend libreboot or deblobbed U-boot over coreboot with disabled Intel ME. And if the former is not an option, *then* (and only then) I recommend coreboot with disabled ME over several other possibilities. All this not including the ASUS laptop you mentioned (which I didn't know about before). Is this where you saw the hipocrisy or was it somewhere else or in someone else's statements?
> > Actually, to high extent I agree with this statement. Not excluding POWER, MIPS and RISC-V, of course.
>
> POWER is for the server sphere, MIPS I remember with the Yeeloong netbooks running gNewSense, RISC-V is mostly for embedded computing.
This thread sometimes focuses on laptops and sometimes on computers in general. If we were to discuss just laptops from now on, I admit I should have written "ppc64" instead of "POWER". Freedom-friendly laptops using some variant of ppc64 could possibly happen in the nearby future. As to MIPS, you're 100% correct, even though I actually thought about some newer MIPS hardware of interest hypothetically appearing at some point. With RISC-V — your word "mostly" is important and "embedded" can also be interpreted in different ways... Anyway, some RISC-V laptops have already shipped (unfortunately, I don't know if they use a free bootloader).
> > Lol, the thing that keeps me in this thread is the shock from seeing M1 being recommended. With a bootloader that is not just nonfree and signed but also encrypted!
>
> I could say the same the opposite way. Is it impossible to replace the bootloader with custom code like it is with IME/PSP?
It is indeed impossible to replace IME/PSP. It is also nonfree and also signed. The differences with IME are that
- part of it can be removed
- there are already tools available to at least decrypt it
- me_cleaner can disable it by flipping the same bit ("HAP bit") the NSA most likely flips on its own Intel-powered computers to make them more secure
That's what I was aware of when I looked at the topic long ago. If since then something changed with newer Intel processors (or rather *chipsets* because that's where Intel ME really runs), please forgive me my lack of recent knowledge.
Btw, if a way gets found to decrypt the Apple M1's bootloader, I might agree to call it and the Intel stuff equally-bad!
> > Although ARM laptops with free and mostly-free bootloaders might not yet be as powerful, the best solution seems to be patience
>
> Patience doesn't move mountains. Waiting for something to happen just doesn't solve anything."
Well, patience itself might not make external conditions improve, correct. It's a way to avoid making mistakes oneself, tho.
For example, it'd be sad to invest into an M1 device just to see some other comparably-powerful + more freedom-friendly ARM laptop appear within 2 years.
Still, if one is not keen on waiting, it might be a good idea to look closely at the recent ARM SoCs and perhaps add them to the famous FSF resources page[1]. I wonder how close all the uninvestigated chips are to booting blobless
Hi Wojtek,
> I didn't actually mean it as a real solution. Just as a partial mitigation when better options are not reasonably available.
I do believe that have already happened, as the Apple SoC now has accelerated iGPU, so it should be reasonably usable. There's a problem with 16K pages, but it doesn't seem to be dealbreaking:
https://github.com/AsahiLinux/docs/wiki/Broken-Software
https://news.ycombinator.com/item?id=33607994
> What exactly do you mean by "rewritable ROMs"?
Memory, holding device specific firmware. The hardware manufacturer can issue a firmware update to fix bugs later on (like with Samsung SSDs, etc.).
> I recall RYF treats ROMs executed by device's primary processor(s) and device's secondary processors differently. IIRC, for secondary processors the mere possibility of rewriting the ROM (as with ThinkPad's EC firmware which can be externally reflashed) does not need to be a hindrance to RYFing the device.
Correct. I was extending upon the current status of RYF certified devices as it would be preferable to have fully open, liberately licensed hardware designs down to the verilog (i.e. based around RISC-V).
> Is it the treatment of primary processor ROMs that you mostly disagree with?
I'm not disagreeing with anything (not sure what you mean), except that there should be no hardware level backdoors (hidden built-in 3G modems, tivoized hardware designs, secondary operating systems running independently, etc.).
> Or maybe by "open approach" you mean e.g. that reasonable principles should not just *allow* but *require* ROMs with nonfree software to be easily rewritable?
If it's possible, they should be rewritable (as opposed to intentionally making them read-only as with the Librem phones[1]). This would prevent firmware bugs to be fixed.
RYF is not necessarily enough as hardware components and peripherals can be built to be malicious (e.g. keyboards). There are even some vulnerabilities I read about a long time ago for reconstructing picture of a screen from a distance, or stealing encryption keys by touch or with a pita bread (mentioning really just for interest).
> With "free software firmware", I don't yet know what to respond because I don't even know FSF's current stance on the SSDs' firmware. An SSD that's not *meant* to ever have its firmware updated is certainly acceptable as a component in RYF devices. But what about SSDs that make firmware updates *optional*?
They don't care (they're okay with updated Embedded Controller as long it's not the user who updated it). Even a microSD card is running firmware. :)
> Want to know my personal approach to SSDs? Right now I don't care much and just use whatever drives are available without investigating whether they support firmware updates. And if at some point a reasonably usable SSD with free software firmware becomes reasonably well available, I shall gladly switch to buying and recommending it instead.
So do I.
> Gotta remember that statement. It could enable me to say I am not attacking people while being pretty much free to attack them ^^
I think there's a difference. I'm not personal outside of the topic. I do understand what you're meaning tho.
> Why at all call people out as hipocritical? Isn't it that the best way to have a fruitful discussion is with as little accusations as possible?
It's irritating to see people claiming one thing while practicing another, which means dual-booting Trisquel with Windows, using Librebooted machines and proprietary hardware at the same time *when* there's no need (I mostly mean on the long run). It just shows that they don't really care. But I agree with your *be civil* argument.
> I recommend libreboot or deblobbed U-boot over coreboot with disabled Intel ME. And if the former is not an option, *then* (and only then) I recommend coreboot with disabled ME over several other possibilities. All this not including the ASUS laptop you mentioned (which I didn't know about before). Is this where you saw the hipocrisy or was it somewhere else or in someone else's statements?
This is what I was criticizing, basically. Libreboot is not supporting any of the laptops that I would recommend, neither does RYF (even tho they technically could - outside of Apple SoC atm ofc.). People assume that either Libreboot/RYF or these pseodo-libre Purism-level notebooks are the options and so the recommendation are these or replacing the wifi card with Atheros (still viable if possible), recommending Intel GPUs (not viable because you can't get just the GPU alone), maybe some older Nouveau supported Nvidia cards (with no firmware blobs, i.e. GTX 780 Ti). Some of these were viable options many years ago when there wasn't any better option, but that has changed.
> This thread sometimes focuses on laptops and sometimes on computers in general. If we were to discuss just laptops from now on, I admit I should have written "ppc64" instead of "POWER". Freedom-friendly laptops using some variant of ppc64 could possibly happen in the nearby future. As to MIPS, you're 100% correct, even though I actually thought about some newer MIPS hardware of interest hypothetically appearing at some point.
I didn't think of PowerPC, which is somewhat different from POWER. I was seeing some PPC laptop design many years ago, but I don't believe this to be relevant. MIPS was interesting in the past, but I haven't heard about it since then. ARM is replacing x86 now, and RISC-V should be the next evolutionary step.
> With RISC-V — your word "mostly" is important and "embedded" can also be interpreted in different ways...
Well, basically anything outside it being used as the primary CPU as it isn't competitive with ARM/x86 for now. And even when it will be, it would need to have an libre licensed verilog for us to really matter. Just for interest, Intel was working on a RISC-V based CPU until recently.
> Anyway, some RISC-V laptops have already shipped (unfortunately, I don't know if they use a free bootloader).
https://www.alibaba.com/product-detail/DC-ROMA-RISC-V-Development-Laptop_1600610157163.html
I don't think there's anything free about it in terms of software/hardware freedom. Nothing viable here.
> It is indeed impossible to replace IME/PSP. It is also nonfree and also signed. The differences with IME are that
I was asking about the Apple SoC in particular. From what I understand, you're saying that the bootloader is signed which prevents any free software replacements in the future in case encryption will be broken (just as the case with Intel) and since the bootloader is run by the main CPU, it hampers would-be RYF certification (until someone find a way to disable it, like with Libreboot X200/etc.). Is this correct?
> That's what I was aware of when I looked at the topic long ago. If since then something changed with newer Intel processors (or rather *chipsets* because that's where Intel ME really runs), please forgive me my lack of recent knowledge.
JTAG access is as far as I'm aware this came:
https://github.com/ptresearch/IntelTXE-PoC
> Btw, if a way gets found to decrypt the Apple M1's bootloader, I might agree to call it and the Intel stuff equally-bad!
You mean Secure Enclave Processor = TrustZone? Apple doesn't list SEP for Apple SoC, and Asahi wiki says it "is optional and disabled by default". So, no SEP on M1/etc.
> Well, patience itself might not make external conditions improve, correct. It's a way to avoid making mistakes oneself, tho.
I really am not sure what to make out of the signed bootloader thing. There's U-Boot for the Apple Silicon booting via the m1n1 bootloader. However, ARM is otherwise already viable for basic, Chromebook-level use and I would say possibly a better option overall to the X200. Heck, I don't understand why Stallman is not using an ARM device yet (it could be possible to RYF certify the Pinebook Pro by installing a wifi card in it as some certified ThinkPads have shipped with a disabled AMD GPU).
> For example, it'd be sad to invest into an M1 device just to see some other comparably-powerful + more freedom-friendly ARM laptop appear within 2 years.
This argument came to my mind also, but it's not really a threat considering how far away the competition is and the shared code between each hardware generation.
> Still, if one is not keen on waiting, it might be a good idea to look closely at the recent ARM SoCs and perhaps add them to the famous FSF resources page[1]. I wonder how close all the uninvestigated chips are to booting blobless
They're very much investingated considering the unusually competent information provided by the linked (FSF) page. Just make your own research to understand.
[1] https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurdle/
> I was extending upon the current status of RYF certified devices [...]
> I'm not disagreeing with anything (not sure what you mean)
Ok, great to have it cleared. In the past people criticized RYF not just for having no requirements regarding low-level freedom but rather for having requirements that result in devices that are more restrictive and less hackable. When your wrote
> Trisquel follows the principles defined by the FSF (hence RYF), but I prefer a more open approach on lower-level hardware if possible.
it initially seemed like a statement similar to that criticism i mention.
> > Or maybe by "open approach" you mean e.g. that reasonable principles should not just *allow* but *require* ROMs with nonfree software to be easily rewritable?
>
> If it's possible, they should be rewritable (as opposed to intentionally making them read-only as with the Librem phones[1]). This would prevent firmware bugs to be fixed.
Yeah, the Librem case is a shame. Interestingly, the RYF's "secondary processor exception" does not seem to actually require a chip with such low-level firmware to be read-only. Even RYF'd ThinkPads' EC firmware is theoretically re-flashable from software (except it's just not known how to do it from Libreboot).
> RYF is not necessarily enough as hardware components and peripherals can be built to be malicious (e.g. keyboards).
Correct. The RYF criteria page even has a disclaimer like this
> Please be aware that we can't check products for spy features or back doors, but if we find out about any, we will drop our endorsement unless they are promptly removed.
> > With "free software firmware", I don't yet know what to respond because I don't even know FSF's current stance on the SSDs' firmware. An SSD that's not *meant* to ever have its firmware updated is certainly acceptable as a component in RYF devices. But what about SSDs that make firmware updates *optional*?
>
> They don't care [...]
Good to know
> It's irritating to see people claiming one thing while practicing another, which means dual-booting Trisquel with Windows,
Well, it's perhaps funny. And yet, if someone is making steps towards freedom, then getting rid of Windows is just one of possible steps. And replacing one's partially-free distro (e.g. Ubuntu) with a fully-free one (like Trisquel) is another possible step. While it might seem natural to make the first of those 2 steps before the second, some conditions might lead someone to stepping in a different order. As long as a step is being made, I'd be happy.
> It just shows that they don't really care.
Well, it's certainly true that some people don't
> Libreboot is not supporting any of the laptops that I would recommend, neither does RYF (even tho they technically could - outside of Apple SoC atm ofc.).
What do you mean by "technically could"? The Pinebook Pro?
> People assume that either Libreboot/RYF or these pseodo-libre Purism-level notebooks are the options
I'm willing to agree with the "pseudo-libre" adjective used here. The truth, however, is that there are generally rather few options. Pinebook Pro still has a bit less computational power than Librebooted ThinkPads and less maximum RAM (4G vs 8G) and actually gets presented as an "option" on this forum from time to time. Apple Silicon is not even pseudo-libre. The ASUS AMD laptop you mentioned currently is... but that's it.
> and so the recommendation are these or replacing the wifi card with Atheros (still viable if possible)
You meant "and" in place of "or", right?
> maybe some older Nouveau supported Nvidia cards (with no firmware blobs, i.e. GTX 780 Ti). Some of these were viable options many years ago when there wasn't any better option, but that has changed.
I admit I know far less about GPUs than about CPUs. What has changed?
> > This thread sometimes focuses on laptops and sometimes on computers in general. If we were to discuss just laptops from now on, I admit I should have written "ppc64" instead of "POWER". Freedom-friendly laptops using some variant of ppc64 could possibly happen in the nearby future. As to MIPS, you're 100% correct, even though I actually thought about some newer MIPS hardware of interest hypothetically appearing at some point.
>
> > I didn't think of PowerPC, which is somewhat different from POWER.
That's exactly why I wrote that I should have written "ppc64" instead of "POWER"
> I was seeing some PPC laptop design many years ago, but I don't believe this to be relevant.
>
> MIPS was interesting in the past, but I haven't heard about it since then.
That's exactly what I mean — that we should be watchful for opportunities. Before Raptor Engineering made Talos II, POWER was not something you could hear about often in freedom-friendly hardware discussions. And now Talos II is the most powerful RYF-capable workstation. A similar "twist" can happen in case of laptops.
> > With RISC-V — your word "mostly" is important and "embedded" can also be interpreted in different ways...
>
> Well, basically anything outside it being used as the primary CPU as it isn't competitive with ARM/x86 for now.
Whether and how competitive it will be largely depends on whether some company pays TSMC enough to manufacture it in a good process...[1] Still, currently existing RISC-V SoCs should be performant enough for a typical laptop usage.
> And even when it will be, it would need to have an libre licensed verilog for us to really matter.
I see it differently. Many RISC-V SoCs being manufactured right now are already based on publicly-available, freely-licensed Verilog cores. They might just have some extra bits added here and there. And yet, whether this yields us libre devices primarily depends on whether some semoinductor company decides not to impose boot code's signature checks in its chips. But I admit having publicly-available Verilog code might help because more companies can manufacture it and there's higher chance one of them will be fair with the users.
> > Anyway, some RISC-V laptops have already shipped (unfortunately, I don't know if they use a free bootloader).
> >
> > https://www.alibaba.com/product-detail/DC-ROMA-RISC-V-Development-Laptop_1600610157163.html
>
> I don't think there's anything free about it in terms of software/hardware freedom. Nothing viable here.
There was also nothing free about ThinkPads and now some of them run Libreboot :)
I count that RISC-V chip manufacturers will just find it easiest to make their chips work with U-boot and cooperate with U-boot's upstream. If this happens and there are no signature checks, a device might end up pretty freedom-respecting even without its manufacturer planning for it.
> > It is indeed impossible to replace IME/PSP. It is also nonfree and also signed. The differences with IME are that
>
> I was asking about the Apple SoC in particular. From what I understand, you're saying that the bootloader is signed which prevents any free software replacements in the future in case encryption will be broken (just as the case with Intel) and since the bootloader is run by the main CPU, it hampers would-be RYF certification (until someone find a way to disable it, like with Libreboot X200/etc.). Is this correct?
Seemingly correct. Except you phrased it as if the signed bootloader and RYF incapability were the things I want to point out. But these are the things we already know. And I wanted to point out the encryption which right now makes the biggest difference between those otherwise equally hopeless platforms of Intel and Apple.
> > Btw, if a way gets found to decrypt the Apple M1's bootloader, I might agree to call it and the Intel stuff equally-bad!
>
> You mean Secure Enclave Processor = TrustZone? Apple doesn't list SEP for Apple SoC, and Asahi wiki says it "is optional and disabled by default". So, no SEP on M1/etc.
When one reads them more thoroughly, the Asahi docs actually say that the SEP always runs on boot and just goes to sleep when a non-Apple operating system is booted. A sleeping coprocessor is definitely different from an absent one.
Also, I've been certain that TrustZone != SEP (even though they may serve similar purposes). Correct me if I am wrong here.
> Heck, I don't understand why Stallman is not using an ARM device yet (it could be possible to RYF certify the Pinebook Pro by installing a wifi card in it as some certified ThinkPads have shipped with a disabled AMD GPU).
I guess it's because nobody has done that yet :/ You can become the first to resell Pinebooks with RYF certification.
Well, RYF also happens to require that purchasing is possible without nonfree JS. I guess this is why stores like Pine64 and Olimex consider it too burdensome to care about.
> > For example, it'd be sad to invest into an M1 device just to see some other comparably-powerful + more freedom-friendly ARM laptop appear within 2 years.
>
> This argument came to my mind also, but it's not really a threat considering how far away the competition is and the shared code between each hardware generation.
If someone builts a laptop on rk3588 right now (i.e. 2 years before the line I drawn), wouldn't you prefer it over an M1 Macbook? Sure, this SoC might not have as much computing power as the high-end M1 processors. But it's definitely beyond the "Chromebook-level" we're used to.
> > Still, if one is not keen on waiting, it might be a good idea to look closely at the recent ARM SoCs and perhaps add them to the famous FSF resources page[1]. I wonder how close all the uninvestigated chips are to booting blobless
>
> They're very much investingated considering the unusually competent information provided by the linked (FSF) page. Just make your own research to understand.
What are you suggesting? That future RYF-capable SoCs are going to come from the same manufacturers? Or something different? I doubt a sentence like "make your own research to understand" is likely to move a discussion forward.
[1] I'm not saying it's the only factor that matters. The maturity of architecture specifications, HDL implementations and software support also matters. But I do think that in the case of RISC-V those 3 are no longer in their infancy
I am a translator!
This looks like an interesting discussion but I am terribly lost.
For a laptop, I need azerty keyboard layout so X200/T400 or similar old laptops seem to still be the best option now. MNT does azerty keyboard layout, if they eventually make something with their new board and make external display work blobfree, that will be a good solution. I am not aware of the Apple things being promissing at all, but perhaps I lack information.
For a desktop, in new hardware, Rockpro64 or Power9 look like good options. Not sure why you call RK3399 an "intermediate solution".
Saying that the FSF does not care about disk firmware looks ridiculous to me. The situation is just that there is no disk with free firmware today so not using non-free disk firmware means not using a computer. I consider making disks work with free firmware to a high priority.
For a laptop, I need azerty keyboard layout so X200/T400 or similar old laptops seem to still be the best option now.
There are many cheap options of stickers to get a AZERTY keyboard (you configure the layout in the settings of your desktop environment). For instance, https://lebonclavier.fr/11050-sticker-autocollant-azerty-touches-de-clavier-d-ordinateur-portable.html sells some for 3,50€.
I am a translator!
Thanks for the stickers link. That may be a good option for a cheap refurbished laptop but I would be hesistant to buy anything costly to use with stickers that I am not sure will fit well.
Besides, did you try that already with an ANSI physical layout? It would need to move *µ up-right (compared with ISO, ANSI has one more key above Enter and one less left of it) and I am not sure how to deal with the missing <> key next to left shift (on that row, ISO physical layout has one more key than ANSI).
I have never used such stickers. I am French and moved to Brazil more than 12 years ago. Since then, I have typed with the AZERTY layout on Brazilian keyboards, which are QWERTY. It now feels weird when I type with the layout actually corresponding to the physical keys. :-)
I am a translator!
This gave me the opportunity to learn about the terminology of physical, visual and functional functional layout from https://en.wikipedia.org/wiki/Keyboard_layout#Physical,_visual,_and_functional_layouts
I copied the picture on physical layouts (it only show the block of keys with letters) and counted keys, including the 3 keys with dotted border that seem to be optional:
101/104 - ANSI : 62
101/104 variant : 62
102/105 - ISO : 63
104/107 - ABNT : 64
103/106 - KS : 64
106/109 - JIS : 67
Do you have an ABNT physical layout?
I actually have put a laptop with an ANSI physical keyboard at my mother's running Trisquel but it is only used as a photo frame that I control remotely. Next time I visit her, I will try setting the functional keyboard layout to French and see whether I can type <> (which is the missing key on ANSI) from the laptop keyboard.
- Login o registrati per inviare commenti