The common thing is that there were no desired results because the west decided to do some half-assed thing and just go with the minimum amount of force and troops. Also, some parts of the west decided to start/intervene/participate, while others abstained. In short, nobody cared enough about the goals and about their respective western allies to go in with a heavy force, accept some losses and do the job properly.
Of course circumstances, reasons, participants and histories beyond that were different.
Old lines were never gone. All the talk about Europeans finally doing a common thing always carry some footnotes like "the Republic of France reserves the right to deviate in matters of military, security and production of sparkling wines and demands a 45% part in all tenders". Trump just needs to threaten champagne tax and France will surrender, or car tax and Germany will. Absent outside pressure, it is even worse. European treaties consist of more national exceptions than commonalities.
After the cold war has ended, the western nations focused on not giving a fuck about military strength, allies or facing opponents the size of Russia or China. Instead some small-time infantry campaigns like Iraq, Syria and Afghanistan were started and then basically abandoned without any decisive result or even with a total failure. But even back in the 2000s, there were no common goals and no real alliances, just some commitments to save face and keep up appearances.
So now, Russia in Ukraine and Iran in the Persian Gulf have called the bluff that is Western military power and decisiveness. I'm guessing those were just the first instances of a long line of wars that should have been prevented by the US-lead West, that are now possible because the West is fractured and aimless.
That's because phone browsers have the insane braindead default of scaling everything into tiny unreadableness. You have to explicitly say "stupid browser, nobody ever wanted this shit, behave sensibly by including <meta name="viewport" content="width=device-width, initial-scale=1.0">. No idea why this idiotic custom still hasn't been purged from mobile browsers, but I guess it's just a valuable tradition now...
Before mobile browsers arrived, everything was fine and nobody needed meta viewport stuff. That's why this 1997 era page doesn't have it.
> And yes, no more cross-border workers either way.
Well, that will be a problem especially for Swiss industry. Tons of workers from neighboring Italy, France, Germany and Austria work in Switzerland, commuting each day. They do this because workers are paid better in Switzerland than in neighboring countries. If those workers aren't available anymore, Swiss production of all kinds of stuff will take a huge hit.
For the same reason of wage differences, not a lot of Swiss people cross the border for work, and all neighbors are larger (except of course Liechtenstein, but that's a very special case anyways). So for those neighboring countries, it isn't that much of a problem.
Have been looking for something like this and will immediately try it out.
Logseq is cool, but the desktop client is slow and keyboard usability is low.
Also, my "favourite" problem: cleaning up git conflicts that somehow got into the Markdown via my Android phone. I'm syncing via termux there, and somehow I didn't quite get the script right yet...
What Prusa is that? Last one I've used (not my own, community lab), I had to level the bed using the sheet-of-paper-method. Which is the reason why I got a Bambu for myself.
IMHO all this whining about "layering violations" is stupid. One will always need some kind of layer glue, neighbors bordering on each other need to know something about each other, correlate addresses, etc. It is impossible to do anything practical without such violations. And it doesn't really matter if that glue protocol belongs to the below layer, the above layer or is a weird hybrid of both. Because in the end, the glue will necessarily be a hybrid and it will be specific to the combination of both those layers.
The only thing one should really really really avoid is the TCP mistake of not just having some minimally necessary glue, but that tight coupling of TCP connections to IP addresses in the layer below.
Mobile IPv6 support is theoretically possible. Practically, like so many cool things you could do with your network, ISPs won't have it. The best you can do is hide it from your ISP by using some tunnel, but then you might as well just use a VPN.
> For instance, IPv6's NDP is built on actual IPv6 packets (ICMPv6), rather than some spoofed IP-lookalike thing. No layering violation, and, thanks to multicasting, no need to dump a bunch of broadcast traffic on the layer 2 network.
Only if the L2 network actually supports L2-multicast. Ethernet doesn't, except if your switches are intelligent enough. With cheap ethernet switches, multicast will be simulated by broadcast.
And actually, you can never avoid a layering violation. The only thing that NDP avoids is filling in the source/destination IP portions with placeholders. In NDP, you fill the destination with some multicast IPv6 address. But that is window dressing. You still need to know that this L3-multicast IPv6 address corresponds to a L2-multicast MAC address (or just do L2 broadcast). The NDP source you fill with an L3 IPv6 address that is directly derived from your L2 MAC address. And you still get back a MAC address for each IPv6 address and have to keep both in a table. So there are still tons of layering violations where the L2 addresses either have direct 1:1 correspondences to L3 addresses, or you have to keep L2/L3 translation tables and L3 protocols where the L3 part needs to know which L2 protocol it is running on, otherwise the table couldn't be filled.
Well, I can do that with OpenWRT, no idea which prosumer devices already implement this, but it isn't rocket science: Announce the Prefix of the currently active connection, invalidate the other one. Will interrupt all your TCP connections, but they are toast anyways, most software should handle this just fine. It's quite the same as a Wifi-to-Cellular handover.
h264 and h265 are patent-encumbered and therefore very expensive and/or dangerous. Patent trolls would rip Mozilla apart and eat all their money. The only reason H.264 works atm is that Cisco sponsors a plugin for that.
I'm having my own and my girlfriend's router (in different flats) connect to each other with a wireguard tunnel, so I can print on her printer. Non-colliding addresses make this a lot easier.
> For example, in IPv4 each host has one local net address, and the gateway uses NAT to let it speak with the Internet. Simple and clean.
That's only true for smalltime home networks. Try to merge 2 company IPv4 networks with overlapping RFC1918 ranges like 10.0.0.0/8. We'll talk again in 10 years when you are done sorting out that mess ;)
> In IPv6 each host has multiple global addresses. But if your global connection goes down, these addresses are supposed to be withdrawn. So your hosts can end up with _no_ addresses.
Only a problem for home users with frequently changing dialup networks from a stupid ISP. And even then: Your host can still have ULA and link-local addresses (fe80::<mangled-mac-address>).
RFC6724 is still valid, they are only debating a slight update that doesn't affect a lot.
> Then there's DHCP.
DHCPv6 is an abomination. But not for the reasons you are enumerating.
> With IPv4 the almost-universal DHCP serves as an easy way to do network inspection.
IPv4 DHCP isn't a sensible means to do network inspection. Any rougue client can steal any IP and MAC address combination by sniffing a little ARP broadcast traffic. Any rogue client can issue themselves any IPv4 address, and even well-behaved clients will sometimes use 169.254.0.0/16 (APIPA) if they somehow didn't see a DHCP answer. If you want something sensible, you need 802.1x with some strong cryptographic identity for host authentication.
> Stateful DHCPv6 is not supported on Android (because its engineers are hell-bent on preventing IPv6).
Yes, that is grade-A-stupid stubborness. On the other hand, see below for the privacy hostname thingy in IPv4 and the randomized privacy mac addresses that mobile devices use nowadays. So even if Android implemented stateful IPv6, you will never be reliably able to track mobile devices on your network. Because all those identifiers in there will be randomized, and any "state" will only last for a short time. If you want reliable state, you need secure authentication like 802.1x on Ethernet or WPA-Enterprise on Wifi, and then bind that identity to the addresses assigned/observed on that port.
> With IPv6 there's literally _nothing_ similar.
Of course there is. DHCPv6 can do everything that IPv4 DHCP can do (by now, took some time until they e.g. included MAC addresses as an option field). But in case of clients like Android that don't do DHCPv6 properly, you still have better odds in IPv6: IPv6 nodes are required to implement multicast (unlike in IPv4 where multicast was optional). So you can just find all your nodes in some network scope by just issuing an all-nodes link-local multicast ping on an interface, like:
(The interface ID (like eth0, eno1, "Wired Network", ...) is necessary here because your machine usually has multiple interfaces and all of those will support those multicast ranges, so the kernel cannot automatically choose for you.)
> And even when it's supported, the protocol doesn't require clients to identify themselves with a human-readable hostname.
DHCP option 12 ("hostname") is an option in IPv4. Clients can leave it out if they like. There is also such a thing as "privacy hostname" which is a thing mobile devices do to get around networks that really want option 12 to be set, but don't want to be trackable. So the hostname field will be something like "mobile-<daily_random>".
What you skipped are the really stupid problems with DHCPv6 which make it practically useless in many situations: DHCPv6 by default doesn't include the MAC address in requests. DHCPv6 forwarders may add that option, but in lots of equipment this is a very recent addition still (though the RFC is 10 years old by now). So if you unbox some new hardware, it will identify by some nonsensical hostname (useless), an interface identifier (IAID, useless, because it may be derived from the MAC address, but it may also be totally random for each request) and a host identifier (DUID, useless, because it may be derived from the mac address, but it may also be totally random for each request). Whats even more stupid, the interface identifier (IAID) can be derived from a MAC address that belongs to another interface than the one that the request is issued on. So in the big-company usecase of unboxing 282938 new laptops with a MAC address sticker, you've got no chance whatsoever to find out which is which, because neither IAID nor DUID are in any way predictable. You'll have to boot the installer, grab the laptop's serial number somewhere in DMI and correlate with that sticker, so tons of extra hassle and fragility because the DHCPv6 people thought that nobody should use MAC addresses anymore...
Of course circumstances, reasons, participants and histories beyond that were different.