yusyusyus

and commercialization wasnt done until the like 1994. OSI as a successor was still proposed when the first BGP4 rfc came out.

before commercialization happened, IP was mostly the realm of government and education.

still good reasons to choose IS-IS for greenfield :) hell, they took IS-IS and did TRILL with it for DC (rip TRILL).

but yeah, I saw one piece of SONET crap hanging off a ctunnel that spoke CLNP back in maybe 2012 or 2013? haven't seen much of it, but still learned the ctunnel stuff back in '09 because it still could occasionally rear its head.

if the firmware is totally nuked, you'd need backup firmware. at some point, all of this crap can be made non-recoverable, but that isn't the real problem to solve.

imma take your comment one step further and say that the emphasis on security is coming at the expense of discussions on resilience. and security matters a lot less, especially financially, than resilience.

it certainly ends in somewhere resembling cost-effective. "reliable" has its meanings in context, and backhoe issues aren't so much of a problem architecturally for starlink.

they have incentive and capability to get that traffic off the shared fate should it occur (even if that extends up to starlink serving one of their IP transit providers for OOB). that's why i question the wisdom of being overly concerned with starlink's particular paths.

even with KMZs supplied, this still happens. complications in some cases. but an IP product (like starlink), i dont see the same equivalence. at what point does fate sharing analysis end in such a scenario?

why? from my pov, once i’ve bought the service from the provider, their job is to deliver however they can; not my business, not my problem. my problem is making sure my redundancy (if required) isnt fate sharing.

> With the right preprocessing, it should be possible to essentially stream from NIC straight to CPU, process some stuff, and output it straight to the NIC again without ever touching RAM

this already exists [0]

[0] https://www.intel.com/content/dam/www/public/us/en/documents...

I appreciate this comment. In my world of packet pushing, I try to promote vendor diversity for this reason.

The practical downsides of this diversity live in the complexity of the interop (often slowing feature velocity), operations, and procurement/support.

But issues like the AT&T 4ESS outage have occurred before in IP networks, as an example, in some BGP bug. Diversity alleviates some of the global impact.

iirc mikrotik supports netflow. that's how i account for proto balance. FWIW, owing to the nature of residential traffic, I've typically seen high (60-70% of traffic) as v6.

software distribution had a quite different model in that era.

>Stupid has to hurt bad, and that just isn't palatable to polite society.

What does this actually mean from your POV?

Way back in the day when I worked for some server rental place, we had an AUP and all of that, but an internal policy: if the cops came knocking about your stuff, we were gonna shut it all down.

Basic reason is that the effort involved in such an account cost us more money than we made in dealing with it. Easier to just cut the relationship.

I strongly disagree on all points, but I think it is a useful perspective overall as a comparison of what the future could or should look like.

I simply disagree that it moves up. We have had a clear delineation between what is "restrictive private property" and what is "open access private property". That separation is clearly delineated at the IP network + related necessities. This model has worked well, and I don't see how it is breaking now.

Someone else mentioned as well, but some very specific monopoly/necessity cases could change this delineation, however I could only see this being necessary with a much different environment than we have today (that is, situations without feasible common carrier alternatives, _maybe_ google search would be an example today).

I won't speak to your particular motives because I don't know you from anyone else, but I sometimes wonder if a core driver behind wanting to mess with section 230 is because people feel entitled to an audience at low/no cost to them, at the expense of platform owners, to blather on about whatever they please. To this end, I say "nope, you're not entitled... we have an open internet, drive your own damn traffic".

What model makes sense and why should it be treated differently than other forums with moderation?

I'm a big fan of the idea that internet providers, DNS registrars, etc. need to be neutral to content in the way common carriers are, but I'm not convinced yet that platforms should have similar obligations. It seems that the appropriate response to schismatic disagreement with the "SysOps of the BBS" is to build another BBS as the "telephone network" is open to all.

How about we regulate them instead? We can force them to change using the power of the state.

Yep, but windows apps are typically distributed as binaries, so the OS doesn't help when you need OS+architecture to make things run and folks build for x86.

For my work, macs have never been really useful to develop on without additions. The whole "I can run virtualbox" and having a good out-of-the-box unixy setup is what has kept me coming back. Linux/others are not a realistic option as a daily driver for what I do.

No x86, no virtualbox. No virtualbox and I'd rather just get (with much sighing, complaining, and general ill will) a windows laptop. I mean, the terminal is becoming slightly more useable in windows, right? And sometimes you just need to run a windows VM, so you need x86 virtualization.

There are downstream effects to losing the "nerd" base and I suspect this move is a bad idea, but apple has a track record of pulling rabbits out of hats and knowing what really matters. Maybe this customer segment just doesn't matter.

>I have yet to find an easy way to implement a simple "Press any key to accept this call" where the first person to answer AND press any key gets the call

Would you be interested in a functions script that does this? I've got one kicking around I can share.

The capacity is not fungible, even if with force of law. Further, even if this had been started 3 months ago, I sincerely doubt that the work would be bearing much fruit even now.

Ventilators, generally, may be "well known", but the design and operation of a modern ventilator is probably not something that is "well known".

Doing this kind of stuff is much more complex than our ability to scramble. The key is to think about this kind of crap before it becomes necessary. Without that, we won't have what we need on time. Things like this are just not solvable by throwing money at it after the fact.

Workplace attendance tracking is certainly not universal.

When I teach classes, if a student does not perform the requisite work to complete the course, I’ve no interest in their success. I am an instructor, not a motivator.

funny enough.. my team probably killed off (one of anyway) the last tier 1 internet multicast deployments over the past few years.

Multicast has dataplane resource scaling issues and, frankly, CDN has become the solution to what multicast solves.

easier explanation is that they were doing troubleshooting and had removed the filter to do that.

maybe not the exact correct solution (some of those MCUs are wayyyyy too tiny, slow, and stupid for something as complicated as DTLS), but this is not a horrid thought. The bootstrapping problem can be resolved via Microsoft's secureboot certificate and letting the firmware sort out the initial "trusted boot USB sticks" or however.

hell, simply through acquisition and acquiescence, the market already accepted locked-down platforms. at this point, we ought to have more benefits from this instead of just making these platforms hard to install Linux on.

I don't know which particular "9000 series" you're referring to, but C9K (which the article refers to) isn't EOL. It should be straightforward to get parts for these, via multiple channels.

The deployment model for grey market bit is usually on networks that run on cheap models. They'll do things like buy one of the devices through white channel market and get SW access. Then, they'll turn around and buy a bunch more grey channel devices and use the SW access to upgrade, etc. As long as the device can handle the PPS and bitrates needed, its good enough for these networks. If it dies, buy another one and let it hang until it gets replaced. There are plenty of networks that just don't care about the operational issues.. and they love to keep cisco because of talent pipeline and training ecosystem.

Anyway, running equipment without vendor support is fine. If its a config issue, the docs are okay. If it is a bug, 9 times out of 10 TAC throws a random bug ID and tells you to upgrade. Naturally, It becomes an issue more when you run on the periphery of what is supported.

QEMU and Tianocore works in some cases.

Which is, tbqh, a useless solution. Oh wow, now an attacker just has to include some obfuscated javascript encryption lib. Bam. Exfil detection completely bypassed.

having a copy of a single ISO standard is virtually never gonna work. too many references.

How exactly? Sources have to pass RPF check following ucast path and receivers have to follow the path either to RP or source, or the packets don't get there.