Not only the System/390.
Its also IBM i, AIX, and for many protocols the network byte order.
AFAIK the binary data in JPG (1) and Java Class [2] files a re big endian.
And if you write down a hexadecimal number as 0x12345678 you are writing big-endian.
(1) for JPG for embedded TIFF metadata which can have both.
The endianness of file formats and handwriting is irrelevant when it comes to deciding whether your code should support running on big-endian CPUs.
The only question that matters: Do your customers / users want to run it on big-endian hardware? And for 99% of programmers, the answer is no, because their customers have never knowingly been in the same room as a big-endian CPU.
Saying that (hand)writing is irrelevant is a bit of a strawman implying I said writing hexadecimal numbers big-endian on paper matters for coding.
The second sentence, weather your customers know if they have been in the same room with a big-endian system (CPU alone doesn't matter) is irrelevant when the point is to write correct code. Many of then aren't interested in this or other details and that is ok as they are not responsible for the implementation.
Changing the endianness either direction did have show bugs to me several times, that could be fixed, and it was worth it for that alone.
It's always interesting to see how are things build in the Lumafields "Scan of the month". The the most interesting scan from Lumafield I saw was not a Scan of the month, but in "Adam Savage’s Tested: Surprising Flaws in 18650 Lithium-Ion Batteries" [1]
Sometimes I miss the times where you had a compact development environment, wit one installer. Your source produced a mostly self contained binary in a reasonable size, you had nice debugging support and quick turnaround times for a compiled language even on a small development machines. And all that for attractive price for a perpetual license (Borland times).
Today it seems I have to give the producer my email address for the 'free' "Delphi History PDF".
Well, times have changed. :)
I have seen the topic a bit late, but nevertheless:
I have learned 6502 assembler (and assembler) in general with
"6502 assembly language programming by Lance A. Leventhal" (1979) [1] and
"Apple Machine Language by Don Inman & Kurt Inman" (1981) [2]
For the 'internals' of the machine, I had "What's Where in the Apple: A Complete Guide to the Apple Computer by William F. Luebbert" (1985) amazon:[3]
From the article:
"The consequences for a consumer buying a shady USB cable likely aren’t too bad".
I can't second that, but more to the software/driver side.
Without my knowledge, I once had a counterfeit cable that costed several days of my life.
At that time, the FTDI drivers recognized (and as I read did some other things [1]) that a counterfeit cable was connected, but instead of simply disabling the function, they impeded it.
In my case: After pressing the first few keys on terminal connection, the transmission from the device to the PC worked, but not the reverse direction.
A long search for the error came to an end after I replaced the USB/RS232 with a new one.
This was with windows, with Linux even the counterfeit worked.
(1) for JPG for embedded TIFF metadata which can have both.
[2] https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.ht...
reply