Back in the day you needed a modified cable for this with RX/TX swapped on one end but nowadays probably all nic chips have auto-detect so you can take a normal patch cable and do it.

Gigabit Ethernet sends and receive over the 4 pairs simultaneously using echo cancellation, so it doesn't need crossover cables.

Yeah, I remember those. When setting up an ad-hoc network, you were like; "where the eff is the crossover cable!" :D

it was the red one, right?

Mine was just a custom made gray one, but I have seen those red ones, yes :D

I bought bunch of ready made 10 meter cables for lan party dunno 15 or 20 years ago... Used with switch... Grey with nice paper label at end with "Cross over"...

Haven't had any issues with them ever in regular use... So pointless even back then...

If using a switch, there isn't any need for crossover cables, is it?

yes

(, except if you lack an additional power slot or have no switch available)

Mine were grey same as the normal patch cables but had red Hellerman sleeves at the ends.

Look at you with your fancy red Cat5 ;-)

Yeah so called crossover cables. But that's like decades ago.

Yeah it's been about 20 years since there was a risk this didn't work.

In fact you just need one of the two ends to be able to auto swap RX/TX.

When I hacked a USB2-GigE adapter into my old Toughbook CF-m34 to replace the stock 10/100 adapter, it wasn't for the speed. I didn't need the speed, and of course USB2 wouldn't let me use the whole gig anyway.

But GigE uses all four pairs, so the hardware has transceivers behind all four pairs, which means even when they're running at 10 or 100, the chipset can choose which pairs to transmit and receive on. Thus all GigE adapters are Auto-MDIX, and it meant I no longer needed to carry a crossover cable, no matter what other device I was talking to.

It's funny how 10/100 cards with Auto-MDIX capability were exotic and expensive, but once GigE had it by default, it became ubiquitous, cheap, and quickly forgotten.

Not really modified, you could buy them pre terminated or put on your own rj45 and just wire it as crossover.

If page has 15 requests and needs data from all of them to work correctly, then with 20% failure rate you are suddenly close to 100% non-functional page from the user perspective.

+1. This is a very real problem in practice.

A technique we've used to deal with this situation: in the overloaded backend (that has to reject some percentage of incoming requests), group the incoming requests by the parent request (the one with the 1:15 fan out) and reject according to the parent request. One way to put it, simply (though somewhat inaccurately), would be: reject 100% of traffic from 20% of users, rather than 20% of traffic across all users (causing essentially full failure for all users).

We typically implemented this by propagating an ID of the parent request down to the backend. I'm simplifying a lot in this description (e.g. have to deal with the parent requests landing on different backend tasks; also rotate the IDs gradually to introduce some fairness).

A nice technique to learn of this situation is to fail ("black hole") random resources in synthetic loads of the frontend. This lets you find out 'bout these single points of failure, and then you can start adding fallbacks.

This is a pretty ancient thing as far as the FE goes: https://www.stevesouders.com/blog/2010/06/01/frontend-spof/

It's easier to create a nice worst-case failure UX this way too. Rather than a page that sorta kinda loads but doesn't actually work at all you can unambiguously put up a "oops we're broken right now try again later" page whenever that top-level endpoint returns a non-retryable error.

But that of course begs the question--why is the frontend retrieving all these data from 16 different endpoints instead of just one? It would be less overhead (http, auth, serialization, compression) to just serve it all in one request even if the http layer needs to fan out 15 rpc calls... this is why we can't have nice things.

There is no rule that there has to be a single payment per authorization, if you read for example mastercard API https://in.gateway.mastercard.com/api/documentation/integrat... it says you can partially capture, you can extend authorization. So for all you know when you buy at amazon it just updates the authorization and charges you later but keeps authorization going and amazon might just check if they have auth token for your card and if they do system allows you to continue and to you it seems instant.

It’s a lot more complicated and nuanced than that. The API docs you link too are for an API that covers a tiny fraction of what can be expressed in the actual ISO 8583 messages which are the real “API” of the card networks. The docs for those are hundreds of pages long.

Plus you need to analyse how the different messages types and sequence of messages interact with the transaction processing rules, which are also hundreds of pages long.

Suffice to say, the entire system is insanely complicated, and just about everyone out there implements it all incorrectly, with the whole system on working because partners are only allowed to complain about the insanity if they actually loose money. Until that point they’re expected to just handle everything as best they can.

That would make sense, and I guess if you tried something suspicious (larger order to a new address), you would get the full auth flow

This is only true if people stick to a version of a language and don't upgrade.

If you upgrade then, for example, you can't run all of your PHP 5 code in PHP 8, most of it you can but you will have to change the parts that are broken, which are the areas that are repaired in PHP 8.

Same goes for other languages like C# or Python

They are only sensitive to vibration while running, if turned off then just checks and re-calibration needed before turning them on again.

Is that just sloppiness on their part or is it LLM chat bots being used with a prompt "hey give me current versions of these languages" without verifying the result?

I think by crash they mean program stopping execution and being unable to continue, so by that metric Erlang didn't fully crash.

Erlang is designed with a mechanism that makes it easy for external processes to monitor for crashes (or hardware failures), rather than an in-process mechanism like exception handling used in many other programming languages.

Erlang was designed with the aim of improving the development of telephony applications.

The Erlang runtime system provides strict process isolation between Erlang processes (this includes data and garbage collection, separated individually by each Erlang process) and transparent communication between processes on different Erlang nodes (on different hosts).

The "let it crash" philosophy prefers that a process be completely restarted rather than trying to recover from a serious failure. Though it still requires handling of errors, this philosophy results in less code devoted to defensive programming where error-handling code is highly contextual and specific.

It is ongoing project but there doesn't seem to me enough financing, the money that EU allocates only cover about half of the required budget so they are looking for investors.

Correct it is a new rail line not an alteration of existing tracks, but it goes into some existing and new (mostly cargo) stations so some stations will have both gauges of track.

I don't think it is fair to compare Netherlands to other countries like UK or France because Netherlands has a well established culture around bikes and bike lane infrastructure is one of the best in the world, so it will be the last country that will have any issues because of e-bikes.

Well, we (in NL) are used to bikes going mostly the same speed and people in cars and bikes following the rules. With overpowered fat-bikes, it's now much more chaotic than a decade ago.

The established road / bike path system here runs so smoothly that changes like this cause problems. People can't seem to improvise. I've also been to Cairo a lot and had a bit of a traffic culture shock. I believe that the chaotic Cairo traffic seems to cope much better with unexpected situations.