Is that a claudeism? IMO that's a perfectly natural trope that'd be at home in my voice or any of a million generic blog people I've read since long before AI. It is a linguistic trope, sure, but that's an unrelated criticism.
I mainly object to AI writing when it’s excessively verbose. This was pretty information dense, a few AI-isms didn’t make it a waste of my time to read.
Yeah, I saw an oddly placed rule-of-three and closed the tab.
This website is going downhill, almost every blog post I open is just blatantly AI generated these days. It's like people don't have any self-awareness anymore, they just lazily prompt their AI to generate a post and then pat themselves on the back lol.
There seems to be a debugging pattern that arises when problems are in proximity to a poorly understood, highly complex part of the system: We tend to think that's where the problem probably is. And we can lose an inordinate amount of time looking for it there. It's like an inverse streetlight effect.
I've seen coding LLMs do it too. I have a well-tested, but complex, subsystem that constantly draws their attention when something non-obvious elsewhere goes wrong.
> As for my original sync problem? After all of that – decompiling an APK, reverse engineering a binary protocol, writing a BLE exploit script – it turned out the issue was on my phone the whole time. Not the cycling computer. The phone.
I think about troubleshooting like OBST with test cost. Systems are a linear chain of points of failure. The more knowledge you have about how hard components are to test and which components break more often, the easier it is to choose the tests that optimize your time.
I can't help imagining someone trying to debug this rigging their laptop to their bicycle handlebars, connecting to the ride computer and then going for a ride to get live data for the debug session.
It would be very hard not to die in a traffic accident while debugging in this way.
Tying to get a bike computer to work while riding is incredibly painful.
I’m a Garmin user and it blows my mind that the interface was chosen. Buttons and touch screen and confusion.
Not helped by both Garmin and Strava not putting enough arrows on the path of travel on their maps.
If you have a route the uses the same road in both directions (eg you ride to somewhere then back along the same path) it isn’t possible to tell when to turn off. Why can’t there be arrows indicating direction of travel?
And that’s when it’s working.
Garmin seem to break shit on software updates and then sync stops working, the radar disconnects, it won’t lock on a satellite etc.
Can Apple make a bike computer please? Or at least play nice and sync their watch with Garmin properly?
It’s frustrating that this isn’t completely typical. As the writeup pointed out, this “exploit” can only be performed by the device owner anyway, so nobody is harmed by the unlockability. But 95% of devices that are sold, besides non-Mac PCs, and SBCs, are locked down completely, prohibiting anyone from using the device as they like.
Agreed, many types of devices don’t need to be locked down so much.
I imagine the companies making the devices think they are “protecting” their secrets from competitors, though now it might be easier to ask an LLM for whatever feature they want to copy.
Yeah, the shifting with electronic components is so fast, easy and precise, but I don't love how many batteries are all over some of my bikes. I kind of enjoy bikes in order to get away from screens and tech and all that.
I found this really hard to read due to the Claude-isms. "Classic" chicken and egg problem? 39 em-dashes, random numbered lists, etc.
If you're not going to even bother to take the time to write an article, why should I waste my time reading it?
Started reading, saw "That was it, That was the whole reason", closed the page.
Is that a claudeism? IMO that's a perfectly natural trope that'd be at home in my voice or any of a million generic blog people I've read since long before AI. It is a linguistic trope, sure, but that's an unrelated criticism.
5 replies →
I read it and found it useful
\_(^ ^)_/
I mainly object to AI writing when it’s excessively verbose. This was pretty information dense, a few AI-isms didn’t make it a waste of my time to read.
I've begun to find the writing style nauseating regardless of use, but yes, at least it isn't used to pad length.
Welcome to Hell, Reader.
(I liked the article, personally.)
Yeah, I saw an oddly placed rule-of-three and closed the tab.
This website is going downhill, almost every blog post I open is just blatantly AI generated these days. It's like people don't have any self-awareness anymore, they just lazily prompt their AI to generate a post and then pat themselves on the back lol.
"How a Broken Bike Sync Led Me to Reverse Engineering My Wahoo's Hidden Debug Mode" - this is brain-dead AI slop right in the title.
There seems to be a debugging pattern that arises when problems are in proximity to a poorly understood, highly complex part of the system: We tend to think that's where the problem probably is. And we can lose an inordinate amount of time looking for it there. It's like an inverse streetlight effect.
I've seen coding LLMs do it too. I have a well-tested, but complex, subsystem that constantly draws their attention when something non-obvious elsewhere goes wrong.
> As for my original sync problem? After all of that – decompiling an APK, reverse engineering a binary protocol, writing a BLE exploit script – it turned out the issue was on my phone the whole time. Not the cycling computer. The phone.
I can feel the pain.
I think about troubleshooting like OBST with test cost. Systems are a linear chain of points of failure. The more knowledge you have about how hard components are to test and which components break more often, the easier it is to choose the tests that optimize your time.
I can't help imagining someone trying to debug this rigging their laptop to their bicycle handlebars, connecting to the ride computer and then going for a ride to get live data for the debug session.
It would be very hard not to die in a traffic accident while debugging in this way.
Welcome to hell, developer!
That just brought a whole new meaning to that message… and writing up a post-mortem.
Tying to get a bike computer to work while riding is incredibly painful.
I’m a Garmin user and it blows my mind that the interface was chosen. Buttons and touch screen and confusion.
Not helped by both Garmin and Strava not putting enough arrows on the path of travel on their maps.
If you have a route the uses the same road in both directions (eg you ride to somewhere then back along the same path) it isn’t possible to tell when to turn off. Why can’t there be arrows indicating direction of travel?
And that’s when it’s working. Garmin seem to break shit on software updates and then sync stops working, the radar disconnects, it won’t lock on a satellite etc.
Can Apple make a bike computer please? Or at least play nice and sync their watch with Garmin properly?
It’s frustrating that this isn’t completely typical. As the writeup pointed out, this “exploit” can only be performed by the device owner anyway, so nobody is harmed by the unlockability. But 95% of devices that are sold, besides non-Mac PCs, and SBCs, are locked down completely, prohibiting anyone from using the device as they like.
Agreed, many types of devices don’t need to be locked down so much.
I imagine the companies making the devices think they are “protecting” their secrets from competitors, though now it might be easier to ask an LLM for whatever feature they want to copy.
Title is: How a Broken Bike Sync Led Me to Reverse Engineering My Wahoo's Hidden Debug Mode
Yes, less fun, sorry for the lack of 1:1 match
yeah, it was more about the complete lack of hint about what the article was about. Could've included a bit Wahoo Debug Mode or something
How dare you have fun
I love reading these kinds of stories!
Love the punchline
That's pretty interesting; I've always wondered about the internals of those things, as I stared at mine while pedaling up some steep grade.
I'm also curious about what the electronic derailleurs and shifters run.
That’s a really good point.
They also never seem to fail (unless the batteries are flat).
Fun fact: my non e-bike has lots of batteries.
2 in the shifters 2 in the derailleurs 1 in the front light 1 in the rear light/radar 1 in the computer + phone AirPods (transparency mode!).
Yeah, the shifting with electronic components is so fast, easy and precise, but I don't love how many batteries are all over some of my bikes. I kind of enjoy bikes in order to get away from screens and tech and all that.
1 reply →
[flagged]