Right across the water on Peaks!
273 karma · joined February 11, 2021
Right across the water on Peaks!
This has never happened to me, but I am absolutely 100% positive some companies just shut your access off, send you an email to an account you can't log into any more, and move on without a second thought.
Did you mean 'having no slack or resilience'?
Assuming you did and I understand your point, I disagree with it insofar as it applies to knowledge. Yes, JIT manufacturing of real things can be easily tripped up and it screwed us during the pandemic, but does that apply here? The author is saying "when you figure out what you need to read, go out and get it" rather than "keep a bunch of tabs and bookmarks hanging around in case you need them".
I mean, yeah, I guess if you only read things you can get from the library or in dead tree form, but if you really want to read something there's ebooks and audiobooks galore out there, and if we have a supply chain mess that's so bad that you can't get an electronic book, we're all kinda screwed anyways.
And yeah, it's excellent.
Don't sleep on these finance companies, they're big development shops.
LDP also enabled L2VPN and was an IGP-bound mechanism to enable MPLS VPN, which was always the killer app for MPLS.
LDP by itself? Meh. But it opened up a whole lot of other possibilities.
Bandwidth engineering, like Bruce said, was religion for some people and anathema for others. It saved at least one company from bankruptcy, letting them run the network they had much hotter than IP would have.
FRR, though, was an absolute game-changer. Local protection to failure and sub-50ms (often sub-10ms) protection switching in an IP network? Immensely valuable. Link connectivity protection was easy to deploy and I will argue made a massive difference in an Internet network's ability to provide real-time services in the face of failure. Node protection and bandwidth protection? Less so. But MPLS-TE-based FRR was the first local protection mechanism that didn't require you to have a specific topology and which could cover 100% of all connectivity failures.
I'm surprised Bruce didn't call out this distinction, because they really are two separate things using the same underlying tech.
There's a perl 5.
There's no perl 6 because it's too much not like perl.
There's a perl 7 but it looks like it'll have two totally different syntaxes for stuff
And maybe there's a perl 8 but maybe with the same syntax as one of the flavors of 7?
I still see no compelling reason to get interested in perl. I have python for some stuff and go for some other stuff. What does perl do for me that these two can't?
https://www.wsj.com/articles/ibm-a-pioneer-of-remote-work-ca...
1. ad blockers are still so niche that it's not worth it to them
2. static IP addresses are dead-simple to block in a router or (probably? not a browser coder) in a browser plugin
3. static IP addresses aren't a real great cloud pattern, they're hard to scale out to meet demand
This will usually give you the right answer, but it might be an old cached version."
Is that really ever a problem? Who changes authoritative nameservers for a domain? This is by far the easiest way and the whole blog post could have just been six lines long.
They missed a huge opportunity to call it FLOWR (flow-er as in one who flows, or flower as in the thing that grows).
And no, setting QoS bits on the packet will not help.