lsusb will get you this info in Linux, but I like the idea of a little wrapper tool to make the output easier to parse.
480 vs. 5000 Mbps is a pernicious problem. It's very easy to plug in a USB drive and it looks like it works fine and is reasonable fast. Right until you try to copy a large file to it and are wondering why it is only copying 50MBytes/second.
It doesn't help that the world is awash in crappy charging A-to-C cables. I finally just throw me all away.
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!
Couldn't figure out why my 5-disk USB enclosure was so ungodly slow. Quickly I saw that it was capping suspiciously close to some ~40MB/s constant, so 480Mbps.
lsusb -v confirmed. As it happened I did some maintenance and had to unplug the whole bay.
Since the port was nearly tucked against a wall I had to find the port by touch and insert somewhat slowly in steps (brush finger/cable tip to find port, insert tip at an angle, set straight, push in) but once in place it was easy to unplug and insert fast...
This was driving me "vanilla ice cream breaks car" nuts...
It's more complicated than "this cable is good/bad". I had a suspicion about one of my cables for months, but just last week I confirmed it with a device that shows the volts/amps/watts/total kwh passing through it: I have a USB-C cable with orientation. Plugged in one way it transfers about 5x more power than the other way, and in the lower orientation it's low enough for the earbud case I use it with to not charge.
I think that I have a specific cable-device-orientation that is broken. Meaning, I think a particular USB C cable won't charge my phone if it's plugged in 'backwards'.
I always assumed that USB C cables use different pins depending on orientation, and that some pins on the cable wore down.
My guess would be they used a one-sided pcb to connect the cable to and used half the wires. Some sockets internally link the power and ground pins, so it works both ways, but you get no resistor network and thus only standard 5v which gives you 500ma max (at best). With the resistors connected by the cable it's about 900ma to 3a which is probably what happens plugged in "correctly". Or some other magic happens on one side of the PCB to fool the charger into pushing the full 3A.
It is not unheard of to have single damaged lines/connector-joints within a cable. The question is whether your cable was designed that way or whether it was damaged in a way that made it do this.
Content wise a nice idea, but I also like the conclusion about how AI made this possible in the first place. The author itself mentions this motivation. AI is undoubtedly perfect for utilities, small (even company internal) tools for personal use where maintainability is secondary as you can ditch the tool or rebuild it quickly.
> 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.
> That’s the real story. Not the script, but how AI changes the calculus of what’s worth our time.
> The script parses macOS’s system_profiler SPUSBHostDataType2 command, which produces a dense, hard-to-scan raw output
I couldn’t find source (the link in the article points to a GitHub repo of a user’s home directory. I hope for them it doesn’t contain secrets), but on my system, system_profiler -json produces json output. From that text, it doesn’t seem they used that.
Presumably there is a sensible way to do this in go by calling an API and getting the original machine-readable data rather than shelling out to run an entire sub-process for a command-line command and parsing its human-readable (even JSON) output. Especially as it turns out that the command-line command itself runs another command-line command in its turn. StackExchange hints at looking to see what API the reporter tool under /System/Library/SystemProfiler actually queries.
> But you didn't see that the source was one level up in the directory tree from the untrustworthy binary blob?
No, silly me. Shortly searched for a src directory, but of course, should have searched for a bin directory, as that’s where vibe coding stores sources /s.
I hope this doesn't become a trend. Moving it to go means you need to compile it before you run it, or blindly run an uninspected binary from some random guy
It's not like the performance of this could have motivated it
vibe coding in my understanding is losing/confusing the mental model of your codebase, you don't know what is what and what is where. i haven't found a term to define "competently coding with ai as the interface".
I mean, they seem to address that pretty directly in the post
> 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.
> That’s the real story. Not the script, but how AI changes the calculus of what’s worth our time.
"My static blog templating system is based on programming language X" is the stereotypical HN post. In theory the choice of programming language doesn't matter. But HNers like to mention it in the title anyway.
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?
+1 here, with the latest Chrome v3 manifest shenanigans, the Pushbullet extension stopped working and the devs said they have no interest in pursuing that (understandable).
I always wanted a dedicated binary anyway, so 1 hour later I got: https://github.com/emilburzo/pushbulleter (10 minutes vibe coding with Claude, 50 minutes reviewing code/small changes, adding CI and so on). And that's just one where I put in the effort of making it open source, as others might benefit, nevermind the many small scripts/tools that I needed just for myself.
So I share the author's sentiments, before I would have considered the "startup cost" too high in an ever busy day to even attempt it. Now after 80% of what I wanted was done for me, the fine tuning didn't feel like much effort.
Definitely.... I just bought a new NAS and after moving stuff over, and downloading some new movies and series, "Vibe coding" a handful of scripts which check completeness of episodes against some database, or the difference between the filesystem and what plex recognized, is super helpful. I noticed one movie which was obviously compressed from 16:9 to 4:3, and two minutes later, I had a script which can check my entire collection for PAR/DAR oddities and provides a way to correct them using ffmpeg.
These are all things I could do myself but the trade off typically is not worth it. I would spend too much time learning details and messing about getting it to work smoothly. Now it is just a prompt or two away.
Absolutely. I can come home from a long day of video meetings, where normally I'd just want to wind down. But instead I spend some time instructing an AI how to make a quality of life improvement for myself.
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 one they're for specific niches, and for two they're AI generated so, even though they fulfilled their purpose, I don't really stand behind them.
For me, claude churns like 10-15 python scripts a day. Some of these could be called utilities. It helps with debugging program outputs, quick statistical calculations, stuff I would use excel for. Yesterday it noticed a discrepancy that lead to us finding a bug.
So yes there is a ton but why bother publishing and maintaining them now that anyone can produce them? Your project is not special or worthwhile anymore.
I don't know if that necessarily helps though, because I've seen USB3 cables that seemingly have the bandwidth and power capabilities, but won't do video.
Capabilities are printed on the side of ethernet cables and the text printed on the cable rarely seems related to the actual capabilities of the ethernet plug. Some cat5e cables are rated for 1000mbps but will happily run 5000mbps or 2500mbps (because those standards came after the text on the cable was last updated), other "cat6" cables are scams and struggle achieving gigabit speeds without packet loss.
Plus, it doesn't really matter if you put "e-marker 100W USB3 2x2 20gbps" on a cable when half those features depend on compatibility from both sides of the plug (notably, supposedly high-end devices not supporting 2x2 mode or DP Alt mode or charging/drawing more than 60W of power).
Vibe coding. Producing code without considering how we should approach the problem. Without thinking where exactly is the problem. This is like Electron, all over again.
Of course I don't have any problems with the author writing the tool, because everyone should write what the heck they want and how they want it. But seeing it gets popular tells me that people have no idea what's going on.
fwiw, it would take 10 minutes to download a linux docker image and build it in go to test. The harder part is getting the information from a different API on Linux.
480 vs. 5000 Mbps is a pernicious problem. It's very easy to plug in a USB drive and it looks like it works fine and is reasonable fast. Right until you try to copy a large file to it and are wondering why it is only copying 50MBytes/second.
It doesn't help that the world is awash in crappy charging A-to-C cables. I finally just throw me all away.
Couldn't figure out why my 5-disk USB enclosure was so ungodly slow. Quickly I saw that it was capping suspiciously close to some ~40MB/s constant, so 480Mbps.
lsusb -v confirmed. As it happened I did some maintenance and had to unplug the whole bay.
Since the port was nearly tucked against a wall I had to find the port by touch and insert somewhat slowly in steps (brush finger/cable tip to find port, insert tip at an angle, set straight, push in) but once in place it was easy to unplug and insert fast...
This was driving me "vanilla ice cream breaks car" nuts...
Let's say for C-to-C, are you talking about swapping the head/tail? Or simply connecting at a different angle (180 degrees)?
Is there any way to check this other than experiment?
My "solution" so far has been to not buy cheap cables and just hope I get quality in return.
Well sure, a standards-compliant cable will work in either orientation, but it's always possible for some but not all of the pins or wires to break.
I always assumed that USB C cables use different pins depending on orientation, and that some pins on the cable wore down.
Maybe that's what happened here?
> 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.
> That’s the real story. Not the script, but how AI changes the calculus of what’s worth our time.
(which is inconvenient because USB 3.2 Gen 2x2 20 Gbps external SSD cases are much cheaper than USB 4 cases for now).
Also, he is calling a binary a script, which i find suspicious. This task looks like it should have been a script.
I couldn’t find source (the link in the article points to a GitHub repo of a user’s home directory. I hope for them it doesn’t contain secrets), but on my system, system_profiler -json produces json output. From that text, it doesn’t seem they used that.
First Go source: https://github.com/kaushikgopal/dotfiles/blob/f0f158398b5e4d...
* https://github.com/kaushikgopal/dotfiles/blob/master/bin/usb...
Presumably there is a sensible way to do this in go by calling an API and getting the original machine-readable data rather than shelling out to run an entire sub-process for a command-line command and parsing its human-readable (even JSON) output. Especially as it turns out that the command-line command itself runs another command-line command in its turn. StackExchange hints at looking to see what API the reporter tool under /System/Library/SystemProfiler actually queries.
No, silly me. Shortly searched for a src directory, but of course, should have searched for a bin directory, as that’s where vibe coding stores sources /s.
started out as a shell script but switched to a go binary (which is what is linked).
It's not like the performance of this could have motivated it
> 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.
> That’s the real story. Not the script, but how AI changes the calculus of what’s worth our time.
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?
https://janschutte.com/posts/program-for-one.html
I always wanted a dedicated binary anyway, so 1 hour later I got: https://github.com/emilburzo/pushbulleter (10 minutes vibe coding with Claude, 50 minutes reviewing code/small changes, adding CI and so on). And that's just one where I put in the effort of making it open source, as others might benefit, nevermind the many small scripts/tools that I needed just for myself.
So I share the author's sentiments, before I would have considered the "startup cost" too high in an ever busy day to even attempt it. Now after 80% of what I wanted was done for me, the fine tuning didn't feel like much effort.
https://github.com/shepherdjerred/homelab
These are all things I could do myself but the trade off typically is not worth it. I would spend too much time learning details and messing about getting it to work smoothly. Now it is just a prompt or two away.
This is currently the vibe on consulting, possible ways to reduce headcount, pun intended.
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 one they're for specific niches, and for two they're AI generated so, even though they fulfilled their purpose, I don't really stand behind them.
So yes there is a ton but why bother publishing and maintaining them now that anyone can produce them? Your project is not special or worthwhile anymore.
I don't know if that necessarily helps though, because I've seen USB3 cables that seemingly have the bandwidth and power capabilities, but won't do video.
Plus, it doesn't really matter if you put "e-marker 100W USB3 2x2 20gbps" on a cable when half those features depend on compatibility from both sides of the plug (notably, supposedly high-end devices not supporting 2x2 mode or DP Alt mode or charging/drawing more than 60W of power).
Of course I don't have any problems with the author writing the tool, because everyone should write what the heck they want and how they want it. But seeing it gets popular tells me that people have no idea what's going on.
if I got a hold of the output and commands run, would gladly modify it.
On Linux that produces a lot of info similar to the macos screenshots, but with values and labels specific to the Linux USB stack.
I wonder if AI could map the linux lsusb output to a form your tool can use...
(/s)
https://github.com/tuna-f1sh/cyme