Hacker News Reader

Comment by devit | Hacker News Reader

If you have a reversible connector, then you might be entangled in a dilemma of which way is the "better" or "optimal" or "canonical" way, while with a non-reversible one there is only one way and thus no dilemma.

And in fact USB-C is not really physically reversible, because the hardware detects which way it's plugged in and permutes the signals, as opposed to mirroring all the wires, so there is indeed a "right" way of inserting an USB-C plug, except it's impossible to tell which it is without a dedicated hardware tester.

View on HN

> the hardware detects which way it's plugged in and permutes the signals

For USB3/4 signals, yes. But the hardware needed to interact with those signals is complex enough that making it also support swapping pins is a minor detail.

The USB2 and power lines, on the other hand, are all present on both sides. This means that simple devices don't need to detect orientation; they can connect the duplicated pins together and everything works.

A USB 2.0 device is usually supposed[1] to just short the two possible positions of each data pin in its USB-C port (the four power pins are always shorted, of course, as are the four ground ones). Orientation sensing only comes into play when you start using the SuperSpeed lanes (for signal interference reasons).

[1] https://www.microchip.com/en-us/application-notes/an1953, 1.3.1

> permutes the signals

Does that cause a noticable difference, for example lower speeds?

No, there are dedicated high-speed "mux chips" for this[0]. You can get them with integrated redrivers to compensate for the inevitable signal quality degradation, if needed.

Once you get into the USB 4 range you're going to need all four lanes anyways, so you can just do the permutation in software.

[0]: https://www.ti.com/product/TUSB1142

And indeed there are usb-c hubs that only work in one orientation so we now have the worst of all possible worlds.

I would argue those hubs do not work

It's the same with usb-c extension cords. Our extension cords now need microcontrollers in them, what a time to be alive.

Given those microcontrollers are 0.05 USD at worst, meh, though I acknowledge it sounds a bit crazy if you don’t recognize how cheap micros can be nowadays. Laptop chargers have used similar schemes (perhaps with bare serial EEPROMs instead of MCUs) since forever, FWIW.

The absurdity to me is not the cost, but the complexity. Our (or at least my own) intuition of an extension cord is as a dumb cord just relaying signals, but they are more complex than that, now.

I'm reluctant to consider shoddy or noncompliant implementations as counting against a technology. If I did, then it'd follow that there's no such thing as a good idea, and I could only agree with that if I were having a bad episode of ennui.

> I'm reluctant to consider shoddy or noncompliant implementations as counting against a technology.

I find it interesting that it is typically done with programming languages. "This programming languages allows people to write complicated, unreadable code, hence the language is bad".

In fairness there are plenty of people who think one should not consider it a language flaw if you can shoot yourself in the foot. See: basically every C programmer.

That's my point: where do you put the limit? A gun allows you to shoot yourself in the foot. Does that make it a bad gun? I think most of us would agree here: if you are at high risk of shooting yourself in the foot, you should not be given a gun.

Nobody ever says "oh, this laptop is bad, because if you take it in the bath you will probably break it". But for some reason, for professional programmers, we consider it is absolutely unbearable to request that they know their tool.

Well, my point is that not everybody thinks that it's unbearable to require programmers to be careful with their tool. So I'm not sure if your point really works as a result.

But that said, I personally am one who thinks we should try to do better with programming languages, so I'll give you my $.02 for what little it's worth. The difference between something like a gun being able to blow your foot off, and the C programming language being able to metaphorically blow your foot off, is the complexity of avoiding the failure state. With a gun, even the most beginner gun handler understands that whatever the gun is aimed at will have a bad time when you fire it. They therefore can very easily know the answer to "when I fire this, will I shoot my own foot" is "no, because I'm not aiming at my foot".

With C, it's more like "the gun will shoot your foot if you aim directly at it - but also it'll shoot your foot without aiming at it if it's the third Tuesday of the month, or if Venus is in conjunction with Saturn, or if your aim is tilted exactly 1.4 degrees off target". That is, the ways you can hurt yourself in C are vastly more complicated, and include plenty of situations where even an experienced practitioner may not realize that they're in for a bad time.

I think that is why you see a push to eliminate sharp edges with programming languages that you don't see elsewhere. If it were readily obvious when you're in for some pain with programming languages, people wouldn't object so much.

> Well, my point is that not everybody thinks that it's unbearable to require programmers to be careful with their tool. So I'm not sure if your point really works as a result.

Oh, I had misunderstood it, sorry (I thought it was a criticism of "those weird C people").

> With a gun, even the most beginner gun handler understands that whatever the gun is aimed at will have a bad time when you fire it. They therefore can very easily know the answer to "when I fire this, will I shoot my own foot" is "no, because I'm not aiming at my foot".

I tend to disagree: usually people do spend some time learning how to use their gun before we give them the responsibility of carrying one. There are many rules to follow, and still there are accidents (even from professionals). I wouldn't say that a gun is "fool-proof". I wouldn't give an assault rifle to somebody, let them fire a few rounds, and then bring the rifle in my car while I'm driving without checking anything. Actually I would pay attention to everything they do and I would check that the gun is unloaded myself.

Sure, getting a loaded gun, removing the safety and firing is easy. Carrying and using a gun correctly is not. To compare that to C, copy-pasting a `main` function and running it is easy. Writing good C code is not. But writing good Rust or Kotlin code is not easy either. That's what it takes to be a professional: you have to learn to use your tools.

I can swear I've felt that when I incorrectly plugged my USB-C to dock station, then I had some crazy issues e.g related to bluetooth. I tried restarts, adapter unplugs, etc, etc.

But when I unplugged the cable and reversed it then the issue disappeared

Reply on news.ycombinator.com