The important thing here is awareness and helping anyone affected, not trying to get Framework fined for a tiny sum.
161 karma · joined June 14, 2020
[ my public key: https://keybase.io/quantum5; my proof: https://keybase.io/quantum5/sigs/DYfDXm4paevvU_Bp1DPF5dQgxf8IH1k-RNk2uI-3PrY ]
The important thing here is awareness and helping anyone affected, not trying to get Framework fined for a tiny sum.
Thanks for linking the documentation! To be clear, when I wrote "header", I meant something with a connector that can be easily used for this purpose. Soldering on the connector is probably more difficult than the pogo pins that I used.
I also can't help but notice the linked connector is less than $1 in bulk on DigiKey and probably cheaper if ordered at Framework's scale.
What I found from my research while writing the post is that both Dell and HP have BIOS recovery options without having to open the laptop at all, so that's not quite true. I think there's more Framework could have done here to make this a much less painful experience.
Also, if you are doing the Raspberry Pi, you'd still need the level shifter since the Pi is a 3.3 V device.
> This is only true anecdotally. I have installed this BIOS version just fine on my 7040 series unit. It's not broken, works on my machine, my anecdote is worth exactly the same as theirs.
I linked an entire thread where people have had similar bricking issues with this exact update: https://community.frame.work/t/bios-update-stuck/83416
If it's just me, I would chalk it up to a freak accident, but it's not.
And in the repair thread, you see it's been happening on and off since last year: https://community.frame.work/t/success-in-recovering-from-ba...
This isn't an anecdote at this point, but a pattern. I don't think the BIOS updater is working as intended if every update is like playing Russian roulette.
> That said, Framework is already well above industry standard in this regard. There are not many laptops out there with non-soldered RAM and removable WiFi modules.
Yes, but they are below industry standard for BIOS flashing issues.
> The trouble here is that they invite this criticism upon themselves by offering repairability as a flagship benefit, but the reality is that it's not very practical for 100% of the computer to avoid every possible pitfall with long-term ownership.
The part that upsets me isn't that they aren't warrantying this. The problem is that they promised to make a laptop I can fix myself and provide all the documentation to do it with confidence long after the warranty ends. That's why I bought into the ecosystem in the first place.
Turns out, they claimed to do better and then does all the anti-repair design anyway for BIOS flashing. They didn't even provide any documentation for fixing it myself, which I would have done gladly and then praised them for having documentation.
Original author here. I like your optimism, but I've linked multiple threads on their forums with people doing the same problem going back over a year. I also pieced together most of the stuff from people doing external flashing on the forums. Still, no official guides, no changes as far as I can tell. This post is the most detail repair guide available right now.
If something happens after this, it would be because this post got to the top of HN and they have to respond to save face.
I was testing ECC previously in https://qt.ax/ecc and was trying to overclock the RAM to induce faults to confirm ECC was fixing them. Since I was using a cheaper board, I had to use keys to short the CLR_CMOS header and that got old really quick... I didn't ultimately succeed in creating a barely stable overclock that generated a ton of ECC errors, but that was a very awful experience.
Having some sort of BIOS recovery is definitely the baseline I'd expect these days, and having two BIOS chips so you can just keep using the device as if nothing had happened is the best solution.
It's actually surprisingly easy to get an ASN for yourself and speak BGP. If you find building something like this tool interesting, you should give it a try. I wrote an introduction of sorts earlier (https://qt.ax/asn) if that interests you.
Note that ARIN NRPM 4.10 now requires the requested range to be used exclusively for IPv6 transition and not anything else.
As for full table, several providers I recommended in the original post are able to do a full table for less than $10/month. You can also join an IX and ask nicely for transit from other members. Some may even offer you free transit the moment you join.
I believe this avoids the weird issues with setInterval but does not use as much CPU as requestAnimationFrame.
I got nerd-sniped into making a calendar following the original rules and tried to see how far I can push it with modern astronomy, and this is the result.
The default was chosen as 4 words due to usability concerns with longer passwords or more obscure words, but it is adjustable. The strength meter is yellow at 4 words to indicate the less-than-optimal entropy, but I felt it was better than turning a new user off by making it too hard to remember. But that's a decision I plan on revisiting.
If you are security conscious, you can save a more secure default for yourself (in local storage, nothing is ever transmitted to a server).
Recently, I decided to package it up with a nice domain name and publish it in hopes that it would be useful to others.