Live data from Hacker News

A macOS terminal command that tells you if your USB-C cable is bad

kau.sh

151–160 of 197 posts

Re: A macOS terminal command that tells you if your USB-C cable is bad

#151

No, I don't get it. Firstly, the normal system command output is not hard to read, but secondly, this output doesn't list any of the capabilities of the cables, just the devices at the ends of them. Perhaps showing an example of the output when the device is plugged in through the wrong cable would have helped. Does the tool produce a similar warning to the system popup, that is "this cable and device are mismatched"…

As far as I understand, the idea is to determine whether the cable is the bottleneck from a hardcoded list of theoretical device capabilities with actually observed connection speeds as reported by the OS.

It would be nice to just compare with the device's reported maximum capability, but I'm not sure whether macOS exposes that in any API.

Re: A macOS terminal command that tells you if your USB-C cable is bad

#152

Earlier quoted context omitted.

And why should they care what's going on ? Do you care about your binary code inside your application, or what exactly happen, in silicon level, when you write "printf("Hello World")" ?

Yes. I verify dynamic linking, ensure no superfluous dylibs are required. I verify ABI requirements and ensure a specific version of glibc is needed to run the executable. I double-check if the functions I care about are inlined. I consider if I use stable public or unstable private API. But I don't mean that the author doesn't know what's going on in his snippet of code. I'm sure he knows what's going on there. I me…

All your stuff is still pretty high level compared to the pure metal inside CPU. Do you which register the compiler decied to use to store this variable, or does the CPU will take this execution branch or not ?

It's all abstraction, we all need to not know some low level layer to do our job, so please stop gatekeeping it.

Re: A macOS terminal command that tells you if your USB-C cable is bad

#153

Two years ago, I wouldn’t have bothered with the rewrite, let alone creating the script in the first place. The friction was too high. Now, small utility scripts like this are almost free to build. This aligns with the hypothesis that we should see and lots lots of "personalized" or single purpose software if vibe coding works. This particular project is one example. Are there a ton more out there?

I have a bunch at work, yes. Can't publish them. Just an hour ago I "made" one in 2 minutes to iterate through some files, extract metadata, and convert to CSV. I'm convinced that hypothesis is true. The activation energy (with a subscription to one of the big 3, in the current pre-enshittification phase) is approximately 0. Edit: I also wouldn't even want to publish these one-off, AI-generated scripts, because for o…

>Just an hour ago I "made" one in 2 minutes to iterate through some files, extract metadata, and convert to CSV.

Okay but lots of us have been crapping out one off python scripts for processing things for decades. It's literally one of the main ways people learned python in the 2000s

What "activation energy" was there before? Open a text file, write a couple lines, run.

Sometimes I do it just from the interactive shell!

Like, it's not even worth it to prompt an AI for these things, because it's quicker to just do it.

A significant amount of my workflow right now is a python script that takes a CSV, pumps it into a JSON document, and hits a couple endpoints with it, and graphs some stats.

All the non-specific stuff the AI could possibly help with are single lines or function calls.

The hardest part was teasing out python's awful semantics around some typing stuff. Why is python unwilling to parse an int out of "2.7" I don't know, but I wouldn't even had known to prompt an AI for that requirement, so no way it could have gotten that right.

It's like ten minutes to build a tool like this even without AI. Why weren't you before? Most scientists I know build these kind of microscripts all the time.

Re: A macOS terminal command that tells you if your USB-C cable is bad

#154
post #56

Earlier quoted context omitted.

I remember hearing it’s even possible to plug in a USB-A plug too slowly, making the legacy pins make contact first, which results in a 480 Mbps connection – despite the cable, the host, and the device all supporting superspeed!

Destroy the whole standard. That's literally insane.

That's the price of strong backwards compatibility. Otherwise, you wouldn't be able to use a USB 3 (superspeed) device on a USB 3 host port with a USB 2 cable at all.

And if you hate this, you should probably never look into these (illegal by the spec, but practically apparently often functional) splitters that separate the USB 2 and 3 path of a USB 3 capable A port so that you can run two devices on them without a hub ;)

Re: A macOS terminal command that tells you if your USB-C cable is bad

#155

Earlier quoted context omitted.

Yes. I verify dynamic linking, ensure no superfluous dylibs are required. I verify ABI requirements and ensure a specific version of glibc is needed to run the executable. I double-check if the functions I care about are inlined. I consider if I use stable public or unstable private API. But I don't mean that the author doesn't know what's going on in his snippet of code. I'm sure he knows what's going on there. I me…

All your stuff is still pretty high level compared to the pure metal inside CPU. Do you which register the compiler decied to use to store this variable, or does the CPU will take this execution branch or not ? It's all abstraction, we all need to not know some low level layer to do our job, so please stop gatekeeping it.

What's your point? That we shouldn't care about anything at all because there is 1 thing we truly shouldn't care about?

That we shouldn't care about spending $1 for a sandwich therefore managing home budget is pointless?

Re: A macOS terminal command that tells you if your USB-C cable is bad

#156
post #121

Interesting. Is there a way to adapt this for Linux or Windows? Many users, not just Mac users, face issues with USB-C cables. Practical cross-platform tools could be very helpful.

A useful tool for debugging USB devices on Windows: https://learn.microsoft.com/en-us/windows-hardware/drivers/d...

Re: A macOS terminal command that tells you if your USB-C cable is bad

#158

I was looking for a USB cable tester (where I would plug in both ends of my cable and it would test it (power, data, ...). There are plenty for Ethernet, but none such ones for USB. Was I looking with the wrong keywords or such device does not exist? Note: I have a dongle that measures the power when inserted between the laptop and the charger, this is not what I am looking for

https://caberqu.com/home/39-54-ble-caberqu-0611816327412.htm...

Re: A macOS terminal command that tells you if your USB-C cable is bad

#159
I feel like we kind of got monkey’s paw’ed on USB-C. I remember during the 2000’s-2010’s people were drowning in a sea of disparate and incompatible connectors for video, audio, data, power, etc. and we’re longing for “One Port To Rule Them All” that could do everything in one cable. We kind of got that with USB-C, except now, you see a USB-C cable/port and you have no idea if it supports data only, data + charging, what speeds of data/charging, does it support video? maybe it does, maybe it doesn’t. at least it can plug in both ways… most of the time

Re: A macOS terminal command that tells you if your USB-C cable is bad

#160

I feel like we kind of got monkey’s paw’ed on USB-C. I remember during the 2000’s-2010’s people were drowning in a sea of disparate and incompatible connectors for video, audio, data, power, etc. and we’re longing for “One Port To Rule Them All” that could do everything in one cable. We kind of got that with USB-C, except now, you see a USB-C cable/port and you have no idea if it supports data only, data + charging,…

I was just thinking the other day, if the connectors had been USB-C from the start.

No Type-A, no Type-B, no Mini, no Micro...

Post reply on HN