quantum5

Author here. I am not even sure how much damage I can actually claim given that I spent $20 on tools to fix the laptop. If I bought a new board, I might be able to claim that, but filing small claims over $20 is likely not worth anyone's time.

The important thing here is awareness and helping anyone affected, not trying to get Framework fined for a tiny sum.

I checked the pictures of my board, and there are 3 unpopulated headers that I can see. There's also the unpopulated BIOS chip socket, which is similarly cheap. I think I would pay the extra $3 per laptop for better repairability, which is Framework's entire sales pitch anyway.

Original author here:

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.

> Any other laptop is going to have the same risk of a failed BIOS flash, and will likely require the same degree of manual intervention to fix.

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.

Original author here. I have a Raspberry Pi, but I still recommend the CH347 instead of the Pi since it's $5 on AliExpress and you can buy it at the same time as the pogo pins probe, which you need. The advantage of the CH347 is that you don't need to fiddle around with the pinout and risk frying the chip if you screw up. You can just plug the probe in (via the level shifter) and you are good to go.

Also, if you are doing the Raspberry Pi, you'd still need the level shifter since the Pi is a 3.3 V device.

But the problem isn't buying the specific broken part here? I would have gladly replaced the BIOS chip if they made it socketed or something, but what Framework support told me is to throw away the perfectly working CPU and buy a new one because it happened to be soldered to the same board as the BIOS chip with incorrect data.

Original author here:

> 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.

It's not a gimmick when the serious overclocking people do custom VBIOSes. Similarly for miners. That's when you need the recovery switch if things go wrong.

> I would bet that this story of a failed BIOS update reaches the support anytime soon and they provide a repair guide or maybe a replaceable BIOS chip. Stories like this are somehow sad but at least they help to improve.

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.

Original author here, and I agree. When overclocking, the most important feature is probably resetting the CMOS with one easy to reach button.

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.

> BGP is the protocol that gives the Internet its shape, and you can’t directly speak it yourself.

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.

The whole BGP process with a private ASN that the ISP strips out and replace with their own ASN on the Internet is how "BYOIP" (bring your own IP) usually works.

You don't actually need an ASN to get PI though? You can use PI just fine with BYOIP. Actually... I don't think you are even required to announce them on the Internet.

(original author here)

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 am curious which leap day system you use for the French Republican calendar. Most popular versions of the calendar I see floating around just use the Gregorian leap year system, which I don't like because it yields the wrong results in the year the calendar was in use. Yet, I don't see mental math as a viable option when using the original date-of-equinox method used during the revolution.

It's actually using setTimeout. Every time the callback fires, it calculates exactly how many milliseconds it would take before the next second arrives, and schedules another timeout exactly that many milliseconds later. This is done separately for both decimal and 24-hour time to ensure the most accurate time is shown.

I believe this avoids the weird issues with setInterval but does not use as much CPU as requestAnimationFrame.

Thanks for reporting! I didn't notice since I always navigated directly to the page while testing, but it is rather annoying when linked. I just pushed a fix.

The original French Republican Calendar determined the start of the year with the date of the autumnal equinox at the Paris Observatory. This made the calendar somewhat unpredictable, as it required a lot of astronomy to figure out the start of the year (and thus whether the previous year was a leap year). These days, it's common to see versions floating around with the same leap year rules as the Gregorian calendar instead of the original rules, leading to weird cases like having the wrong leap years compared to what happened historically.

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.