But with auto MDI-X, each device would notice "hey, I'm sending but not receiving anything," and would try flipping its Transmit and Receive functions around (transmitting on the RX pin and receiving on the TX pin). Since each device waited a random period before doing that, it was very unlikely (nigh-impossible) that they would both flip at the exact same moment. And if they did, the second interval would most likely not be identical either.
I'm simplifying a bit in the explanation above, but that's the broad strokes. And that's how my carefully-labeled crossover cables started gathering dust. (And then I realized "hey wait, I can just use these as normal cables now", and pulled them back out of storage and mixed them with my normal patch cables).
/looks longingly out the window, and catch my aging face in the reflection
Last time I used a crossover cable I was still using dialup, probably about 20 years ago. Once I had DSL I also had a router, so the crossover cable became redundant.
They'll think hard about a beautiful unrealistic idealisation of the problem, and/or treat a software abstraction as if it's the underlying reality, e.g. (of the latter) thinking networking starts with HTTP and languages start with JavaScript.
Haven't had any issues with them ever in regular use... So pointless even back then...
Look at you with your fancy red Cat5 ;-)
Wait there's more: a couple of simple plastic glasses joined with a string under tension also does the trick.
However more seriously, while being snarky about "obvious" things can be fun, we should all remember to acknowledge the xkcd's "Ten Thousand" effect as a very real law of life.
# ping all link-local devices on an interface:
ping ff02::1%eth0
And then do your socat/rsync/whatever to the only IP that responds.mDNS / Avahi is also great if the machine advertises itself: just use machinename.local after plugging it.
Though the interface needs to be configured for link-local addresses. In my experience, NetworkManager now periodically resets the link if it can't get a DHCP server to respond. I understand the rationale, but it used to be simpler to plug into a headless machine and be confident that you could just ssh in.
Something like this should work:
ifconfig enX inet6 fd42:dead:beef::1 prefixlen 48
No ned to bring it up as it should already be up. enX should be your USB/thunderbolt ethernet adapter, e.g. en6.Then you can go ahead and transfer with socat to your other machine, even if it's a Linux machine. I tend to use nc but socat will definitely be faster.
Why the deadbeef network one might wonder? It's private space so won't conflict with public addresses.
That being said though, in 99% cases of big files I'll just airdrop the files!
Used to play Duke Nukem 3D over a null modem serial cable.
In the days of the spectrum where you loaded via an analog audio input from a tape, and saved via the output, you could move from one to another in the same way, skipping the tape.
Apparently this was about 1kbit per second.
If you get away from BASIC commands and copy the tape routines up into RAM you can mess with the timing values, and with care you can get it from an average of 1800bps up to around IIRC 12000bps before things really fall apart. Probably with better interfacing you'd get even faster.
With more conservative values, this is how "speedloaders" worked. In the late 80s or early 90s one publisher released games on CD where it would load in the loader at normal rate then ramp up to some unholy speed that CD had the bandwidth and stability for but tape did not.
https://git.kernel.org/pub/scm/linux/kernel/git/westeri/thun...
Receiver: socat -u TCP6-LISTEN:1234,reuseaddr STDOUT | zstd -d -c | tar -xpf - -C /destination
Sender: tar -C /source -cf - directory | zstd -T0 -6 -c | socat -u STDIN 'TCP6:[fd42:dead:beef::2]:1234'
-T0 uses all cores. Bump the level above -6 for more compression, drop it for more speed, but if your CPU can't keep up, high levels will actually slow it down. Already compressed data won't see much benefit.
Traditionally (pre-2000?), one had to use a special "crossover cable" to do direct connections like this, but apparently modern Gigabit ethernet adapters are able to detect this situation automatically?
Patch cables are outside of walls and designed to be moved around and plugged and replugged. They are terminated with 8p8c "male" connectors, commonly called rj45. Stranded cable is used because it's much more flexible.
edit: as for length, it depends. you won't get a gigabit over 150m of crap cat3, but you will get a link, even if it's 10 half-duplex.
The main difference between patch and "normal" is that the former is using stranded conductors and the latter solid conductors.
That makes the patch cable more flexible (physically)
It's just a holdover from the telephone networks, where you used a short cable to actually phsyically connect - patch[0] - two lines. Therefore - patch-panel and patch-cord or patch-cable.
And some had a switch to select the mode of the uplink port.
https://en.wikipedia.org/wiki/Structured_cabling
So I believe that, in the realm of Ethernet in particular, "patch" vs. "structured" is not a useful distinction.
To regular people it's probably enough just to say Ethernet cable. Outside of structured cabling you don't really need to care and probably don't have a choice anyway. If someone says patch cable they probably know a bit about structured cabling and couldn't help themselves.
Within structured cabling the rabbit hole is quite deep. Even within a single standard like Cat6 there are many possible cable constructions with different types of shielding and wire gauge etc. It becomes important when you need the network to certify as Cat6 and support PoE in a high noise industrial environment, for example. And, of course, Ethernet can run over other cable types anyway, like fibre.
Also probably a more flexible jacket and thinner. Vs fire resistant / plénum cables for fixed / in wall stuff.
[1]Most people don't realise how much power ethernet consumes. Even 100Mbps ethernet consumes about 0.5W per port and it goes up with higher speeds.
"Computer to computer should not be seen without a device in between (unless playing ROTT with your housemates)"
35 years ago maybe :) I had serial and parallel socket, and routerless networking happening on my home systems :)
Use cases? Emergencies and maybe dedicated backup.
> Removable storage is quite slow unless you are willing to spend a lot of money.
An SSD good enough to copy tens of GB quickly is not cheap.
Not Warcraft though - some ancient DOS game.
For every standalone building that has a ground, that building also has an electrical potential. This potential is not necessarily the same between two neighboring buildings. When you stretch a copper line between them, you are tempting fate, electrically, not to mention the dangers of lightning strikes and the elements attacking that connection.
It is generally recognized that fiber optics are not only very efficient and durable, but also impervious to electrical troubles of the type that may plague inter-building connections. Simply grab switches or routers that support at least one fiber-optic connection, and link up!
Because of this they were an early adopter of fiber-based networking. I remember being wowed by ATM over fiber running between closets at a blazing 155Mbps (with tons of 10BASE-T clients connected to FORE chassis switches).
Besides you worry too much. Entire cities were wired with cat5 hanged off steel cable between 9 to 15 story buildings in early 2000s, before fiber. Nothing burned down.
Unshielded cable is theoretically isolated at both ends but who actually knows with some chinesium equipment?
Carry a couple USB-C to RJ-45 dongles ;)
Configuring all this manually adds extra complexity when it seems that the goal is simply to connect up your cable and let 'er fly.
Occasionally we had someone who knew what they were doing and had their Windows 95 settings set up correctly, and then all we had to do was activate their room's Ethernet port and add their MAC address to the DHCP server's list of authorized MACs. But most often I or one of the other techs had to head down to the person's dorm room and set up their computer's network settings correctly before it would work. Once the 169.254 address was replaced by 192.168, my job was finally done. But there were times when that took some doing.
Also, why is he talking about "ethernet"? Its the IP layer, not the ethernet layer...