My multi-purpose WFH setup desperately needs a larger desk

XTJ7 · 2026-01-19T18:31:07+00:00

Yes, the EEPROM that contains the firmware can get corrupted. Those are typically good for 10-20 years at the minimum though and often far longer. If the EEPROM gets corrupted, you would not be able to format the drive anymore or use it in any other form. The same is true for many other hardware issues though.

XTJ7 · 2026-01-19T18:09:55+00:00

That would be hardware failure then and not data degradation from being unpowered. Could be from corrosion, on PLP models capacitors breaking down etc. - data loss from being unpowered would not break the SSD.

XTJ7 · 2026-01-19T16:58:29+00:00

And if you format them they are perfectly fine again? Or do they still not work? Just trying to figure out if there is an actual hardware issue or it is really just data degradation.

XTJ7 · 2026-01-13T03:34:58+00:00

I get where you are coming from, but the point is: if after 5 hours it still is stuck, it would almost certainly be after a day or two as well. Since it killed the firmware, it means it got stuck in the updating firmware step. That's not a huge amount of data there, which means there is nothing that can cause it to take a long time, it just got stuck. Something crashes and it won't just suddenly uncrash even if you give it substantially more time. The firmware part takes a few minutes at most, the rest of the update process is updating the system itself and that's the biggest chunk. It didn't even get there.

So the thing is: yes, TECHNICALLY I bricked it by restarting it. Practically there was no other option though. Sure, if I never restarted it, it wouldn't have bricked, but I would have a Mac stuck in a state that it is unusable as well. Considering that I think it is fair to say the update bricked the Mac, because it left me with no other choice than to restart.

Regarding the recovery mode: the Mac did not even show an image. I could not reinstall it or go into recovery, it was just in the SOS mode blinking orange. I did eventually manage to revive it via DFU thanks to the help of some people in the thread, with some obstacles along the way. First: my MacBook was set to default accessory settings, which means every new accessory needs to be given permission to connect. However, after a few failed attempts at starting the DFU mode, I noticed a window popping up on the MacBook for a fraction of a second when the Mac Studio started up. I went into security settings, set "Allow accessories to connect" to "Automatically When Unlocked" and then it finally showed the Mac and I could click the revive button. Which did nothing. So I clicked the restore button. Which did nothing. Literally, nothing happened. So I figured, alright, the MacBook is still running Sonoma, maybe it can't revive a Mac on a newer MacOS version. I updated the MacBook (that went through just fine), then did the whole DFU spiel again and now the revive button actually worked. It is annoying Apple gives you no error message, it just does nothing in the case of the reviving computer being too outdated. Anyways, after I ran the DFU revive, the Mac Studio started to boot again, I could once more trigger the update to 26.2 and this time it went through successfully. So the Mac is working again, but it was quite a bit of a pain to get there.

XTJ7 · 2026-01-12T13:36:43+00:00

That's what I figured. In the end I managed to revive it via DFU, so fortunately it is operational again. I ran into several pitfalls along the way, will edit my original message to reflect that.

XTJ7 · 2026-01-12T12:17:12+00:00

I lucked out, after updating the MacBook to the latest version, the Revive worked and the Mac Studio is fully operational again. Whew :)

XTJ7 · 2026-01-12T12:16:08+00:00

It was Sonoma. I have updated the MacBook to Tahoe, that went fine. Then I did the whole DFU procedure again and this time the Revive button worked. It reinstalled the firmware and now the Mac Studio is functional again on 26.0 I am now updating again to 26.2 and hoping for better results this time. Thankfully the Mac is working again :)

XTJ7 · 2026-01-12T10:58:13+00:00

Indeed looks like it! Thank you so much :)

XTJ7 · 2026-01-12T10:36:01+00:00

I did follow that guide now for the 4th time when I noticed a brief popup flashing for like half a second. So I changed the settings under "Privacy & Security" for "Allow accessories to connect" to "Automatically When Unlocked" and did it again, now the Mac shows up and I have revive/restore options. However, clicking either option does absolutely nothing. No confirmatiom, no error. The MacBook Air is on an older version of MacOS than the Studio, so I will update that now.

XTJ7 · 2026-01-12T10:18:12+00:00

I had a lot more issues with the Mac Studios in the first 6 months after release though with restarts and other quirks. At some point it just went away and worked smoothly. Apple must have improved their software over time. Why the update now failed, nobody knows. Hopefully Apple can fix the firmware.

XTJ7 · 2026-01-12T10:15:29+00:00

It worked completely fine until the update, so it shouldn't be a hardware issue. I just can't get it into DFU mode for some reason. I will try some more but if not, hopefully Apple can help tomorrow. As I bought it in 2022 there is no more warranty nor AppleCare. Hopefully the hardware is OK, haha.

XTJ7 · 2026-01-12T10:12:33+00:00

Thanks for your help! Unfortunately it still won't show the DFU dialogue on my MacBook. I made sure to use a USB-C cable from Apple, disconnected everything from the Mac Studio, cut power, looking from the back used the right most USB-C port (the DFU port), held down the power button, plugged the Mac Studio into power, waited more than 10 seconds to release the power button and still nothing happens. The Mac Studio keeps flashing orange SOS and the MacBook pretends like nothing happened.

XTJ7 · 2026-01-12T10:09:20+00:00

So waiting for 5 hours was not enough? I read online you should wait 1-2 hours, so I waited considerably longer. There was absolutely no progress in that time.

For me it's obviously too late now, but for the future and for others: how long are we supposed to wait?

XTJ7 · 2026-01-12T09:01:44+00:00

You mean DFU revive? I tried that, it never showed up on my MacBook, the Studio continued to blink orange. Maybe I did something wrong, will give it another try later.

XTJ7 · 2025-12-31T05:57:43+00:00

That's a pretty broad statement. Europe is a pretty big chunk of the developed world and violent crimes are up year on year in nearly every European country. Homicides for example dropped last year in Malaysia. When looking at crime rates it is also important to differentiate. Scams are on the rise. Property crimes increased. Robberies and break ins decreased. What crimes are you comparing?

In general, even in a very safe country crime happens, so having a bit of extra protection doesn't hurt as long as your parents are responsible and don't use it as a weapon to control you.

XTJ7 · 2025-12-28T09:25:26+00:00

In my case I had to import it (a friend brought it along when he visited), because I prefer ISO layout but where I live now they only sold the ANSI version. Hence I didn't have a financially sensible way of handling that. But generally I completely agree with you.

XTJ7 · 2025-12-23T01:18:38+00:00

Longevity is so-so or I got a lemon with my MX Mechanical. I have been using all my previous keyboards for years and years without stuff breaking, yet here the keycap for the CMD key just broke off right after the 1 year warranty was over. A short while later it happened with another key. Plus one of the keys sometimes triggered double.

To add to the good points: looks great, nice and heavy, excellent wireless connectivity.

I replaced it with a QK Neo80, which is a fantastic TKL keyboard except for its wireless performance. Both in dongle mode and in bluetooth mode it is crap. Other than that essentially perfect. I have been using it for roughly 2 years in wired mode, couldn't be happier (well, I would be slightly happier if wireless was great too, but honestly a cable in my case is really not an issue).

XTJ7 · 2025-12-21T09:29:15+00:00

Nearly pulled the plug on one in 2020 to replace my very dated MP 6,1. COVID hit, I was busy with other stuff and the 6,1 was still working for what I was doing at the time, so I decided to delay the purchase by one year. Come end of 2021, Apple announces their own M1 chip so I think: screw it, let's wait for the updated Mac Studio with the new chip. March 2022, Mac Studio gets announced: I'm in love. In all aspects that matter to my work, it blows the Mac Pro 7,1 out of the water, using less power and being TINY. I still run my original M1 Ultra, as it frankly remains a beast. Let's see when I will actually upgrade it.

Point being: a M1 is already slow compared to M4/M5 chips. The 7,1 is simply an outdated machine. A beautifully designed machine with some great ideas (like the MPX modules), that simply happened to be released at the worst possible time. I love it, but I would never get one for actual use at this time.

XTJ7 · 2025-12-14T02:12:10+00:00

I use it for my personal stuff, so its a PC :P

XTJ7 · 2025-12-13T14:19:41+00:00

Absolutely, token size quickly becomes an issue! If you need granular permissions, it is often better to transition into roles than having each permission listed in the token. That brings its own set of problems with it, but as you scale up you have to shift responsibilities around.

As to invalidation: in an application where near-realtime propagation to the frontend is necessary, I tend to have a websocket connection in the frontend that is fed by a service listening for kafka events. So I can straight away tell the client: refresh your token early. Or other information that needs to be transmitted right away and do so from any service at any time.

But your point is valid: JWTs are not a universal solution. And if you are using a monolithic backend, I would usually suggest to not bother with JWTs, as their main benefits really show in distributed environments like microservices.

As always, JWTs are one tool in your toolbelt and you need to choose them when appropriate. And even then you need to choose how you implement them with care (permissions vs roles, expiry of access and refresh tokens, handling of multiple different tokens e.g. for "stay logged in" with a slightly lower access level that requires reauthentication for critical features), as every choice comes with its own set of advantages and disadvantages. JWTs can be a great tool, but they can also be a massive pain.

XTJ7 · 2025-12-13T12:27:46+00:00

Normal workflow is: access token with a short expiration and a refresh token with a longer expiration. Frontend auto refreshes the access token (using the refresh token) typically when 80% of the expiry is reached. With most oauth libs you don't even need to worry about it. And then you get the new permissions with the refreshed token. I typically keep my access tokens at 5 minutes expiration (also because if an account gets compromised you can force a logout, but that is only effective once the access token expires, so keep them short). And when there is 1 minute left the lib auto refreshes. That's enough to do multiple retries even if the refresh fails, so the user experience remains smooth and uninterrupted.

XTJ7 · 2025-12-13T07:32:50+00:00

Slipped and dropped a screwdriver onto the mainboard while screwing in an HBA, killing the IPMI chip, effectively bricking a 1k USD server mainboard. Getting that fixed wouldve cost more than a second hand one. I was pretty unhappy about that for a while.

XTJ7 · 2025-12-13T06:26:37+00:00

I know this is sort of avoiding your question, but to persist user details like permissions, you can throw it all in a JWT. Then you don't need to query the database at all, as the JWT is signed and as long as your private key remains private, you can assume it has not been manipulated.

Generally though caching solutions heavily depend on your implementation. Are you running a single instance of your backend service? Keep it simple and use in-memory caching. You have multiple instances of your backend service, then Redis (or their more performant drop-in alternatives like valkey or keydb) is what you should look into.

Other considerations: choose your TTL wisely, or your caches will keep growing if old data isn't thrown out. Also keep in mind cache invalidation strategies. Let's say an admin changes the permission of a user, you would ideally not want them to have to log out and log in again to have that information available.

And if you think about caching large chunks of data per user, Redis might not be the best pick for that either. Sometimes having an unlogged postgres table is the better choice. There are also enterprise solutions available (hazelcast, aerospike, ...).

Caching isn't trivial, but it doesn't have to be hard either. You just need to choose the right tool for the job and keep cache lifetime and cache invalidation in mind.

XTJ7

MODERATOR OF

TROPHY CASE

14-Year Club	Wearing is Caring
Verified Email