Yeah, we remember FireWire. And all the burned out FW ports due to poor power regulation on cameras and devices. I don't think I've ever seen a connection protocol more likely to damage a device on either end of the connection. USB is a massive imporovement here.
I remember powering two 3.5" 7200rpm from a single firewire port for years. Even a third disk daisy chained from a single port didn't require an external power supply. I miss the user experience made possible by the high bus voltage. USB PD is worse.
FireWire is a much better design than USB in many ways. I still use a FireWire audio interface purchased not that long ago (though now it has to go through a Thunderbolt adapter).
The problem with USB 1 and 2 is that it was designed by insane committee. This resulted in stuff like those versions not using true differential signaling (like USB3 does) even though that was common technology at the time. Instead they have end of packets delimited by single-ended conditions. That, coupled with a single ground wire for power and data makes for a world of ground loop issues.
And then they made the frame rate 1kHz, which is right in the peak of human hearing sensitivity. And so, USB's terrible design is single-handedly responsible for a huge amount of, even most, noise and interference issues in audio systems involving it. Especially in low cost consumer hardware, but it has made its way into many professional productions. Any time you hear a constant 1kHz beep of interference, mixed with some fuzzy crackling, nine times out of ten that's a ground loop with USB and audio involved. It's everywhere once you listen closely. Headphone output on your laptop or phone is noisy when you access a USB drive, or has a 1k beep? USB. USB audio widget has background fuzz and a beep? USB. Slight 1k beep in the background of a news cast? Someone had the bright idea of using USB somewhere along the line.
It didn't have to be this way. Ethernet, SATA, plenty of other protocols use proper differential signaling and don't have this issue. How to do this properly was well established long before USB existed.
And to add insult to injury, while USB 2 specifies a transaction translator, so you can run USB 1 devices on a USB 2 bus, USB 3 does not. And so, while USB 3 devices don't have this problem any more, you can't plug in a USB 2 device into a USB 3 bus or a USB 3 hub. And nobody uses USB 3 for low channel count audio interfaces, so this problem will remain forever. Oh sure, you can plug it into a USB 3 port, which is actually a USB 3 port and a USB 2 port in one. And you can plug it into a hub labeled "USB 3" which actually has a whole USB 2 hub along side it in parallel. The communication from USB 2 devices remains USB 2 all the way to the host. And so, not only do USB 2 devices only get 480Mbps of total bandwidth on a USB "3" hub (minus a ton of overhead, because the protocol is terrible), it doesn't fix this issue! And did I mention USB 2 is impossible to galvanically isolate in any kind of cost-effective way?
I could go on and on about how the polled architecture causes performance bottlenecks, about how it's impossible to tunnel without unfixable corner cases, about how its latency requirements preclude lots of innovative ideas, about how the descriptor and device inquiry protocols are practically designed to guarantee that implementations are vulnerable and have exploitable bugs (yes, your USB stack is vulnerable. They all are. This is how the PS3 got hacked. And the Switch. And tons of other devices. USB developers like me know misbehaving USB devices crash hosts all the time).
I'm aware; as you say though, sadly, it's unobtainium (and non compliant, so it's guaranteed to have compatibility problems with some devices and drivers).
Real transaction translators in USB 2 work with host cooperation and specific support for USB 1 devices in the protocol, while this is trying to do transparent protocol conversion. Sadly, due to USB's design, this runs into the same corner case problems as any other kind of tunneling.
The main problem is the polled architecture. Host asks device for data; translator has to reply immediately so it has to say there is no data yet and ask the device for data. Translator buffers data and delivers it to the host the next time it asks. Except the host is allowed to never ask, again. Now the translator has data it has to drop on the floor. Not good. And this all requires heuristics to decide what to do. It's a mess.
These factors don't come close to negating the incredible convenience that USB has afforded me over the last couple of decades. So, the committee must have done something right.
Just because a technology is better than nothing or became popular doesn't mean it's good. There is plenty of bad engineering in the world that might be better than no engineering, but that doesn't mean we wouldn't have all been better off with a good design from the start.
But it's not just better than nothing. It is good, even great. It does exactly what I need without issue and has worked reliably for me for decades. It may not be perfectly elegant and beautiful in every technical aspect of its design but that doesn't really matter to me.
You might say Firewire could have provided the same for me, but Firewire wasn't widely deployed or adopted. Therefore it could not have replaced USB for my use cases. That may not be a technical issue, but I don't really care as a user if the failure of Firewire is technical or not. Technical superiority is only a small piece of the puzzle. Plus, I think you are underestimating the technical advantages which led to USB's success (e.g. low cost).
> It is good, even great. It does exactly what I need without issue and has worked reliably
USB1 and USB2 still work fine despite being less than ideal engineering. Tolerances are big enough at lower speeds. USB3 can be unreliable (e.g. for cameras) because limits set by the laws of physics get too close for cheap implementations. That's no longer good. Especially if we are forced to use that in professional set-ups, where a couple of cents or even Euros/dollars would not harm. The problem is now that you cannot put that tiny bit of money on the table and you get a reliable product. As the discussion showed even certified and known brands' USB3 products can be unreliable.
Some of these merits depends on DMA support on IEEE1394 but it's actually an security risk without separation by IOMMU that implemented on CPU since around 2012.
