147 karma · joined January 17, 2016
I won't deny that sometimes it works but there's much more coverage on when it does that when it fails which only serves to amplify the survivorship bias around it.
Or ZFS or DRBD or whatever homegrown or equivalent non-proprietart alternative is available these days and you prefer.
That of course would make it optional like with most programmable keyboards but then there's the need to manage pairing via their wireless dongles and then it quickly becomes necessary.
Outside of it all being intentionally proprietary I don't see why they couldn't take an approach similar to VIA in managing their devices. There's also prior work for flashing microcontrollers from the web browser, I'm thinking of ESP32s specifically.
I've noticed weird little detours in areas where I'm familiar with but engaged navigation merely for an ETA. To me those little detours that don't save time or avoid construction suggest I'm being used to probe those side streets. It's like being a human ICMP packet.
Both asymmetric routing and ECMP routing are visible from L3. In the latter case, the routing decision can utilize some L4 data, so some L4 frobbing to get useful data points in practice is necessary for useful real-world diagnosis.
I agree with others that the OSI model is a good metaphor and a framework for reasoning about networking, but it is far from perfect, and the reality for those designing and operating network protocols and devices is messy.
MPLS is admittedly invisible and there isn't a thing you can do about it in the same way that you can't expect traceroute to give you a view of the switch ports it went through on a LAN. Of course it is useful to understand and keep in mind the fact that there may be, sometimes huge, gaps in your traceroutes. A sudden huge jump in RTT from one hop to the next can be confusing when trying to understand and troubleshoot a network issue.
The explanation is great for a toy network bu in today's Internet the vast majority of routes are going to be asymmetrical and that requires running traceroutes from both ends and interpreting the results to find the faulty hop.
The author also doesn't cover equal cost multipath (ECMP) which is everywhere. With ECMP you have multiple ports that lead to the same. Next hop and packets are hashed based on some part of the fourtuple, sometimes five tuple including the input Port. In order to track down the faulty link, you need to pro each and every one of the ports which requires that you use a higher level protocol like UDP. Using icmp in this case will not show you an issue some percent of time, providing false negatives which makes it less useful.
Why not rig it with explosives around the sensitive components and avoid the messy endeavor of trying to orient the plane for maximum destruction after ejection when that is likely to be unreliable at best?
Consider the cost of ownership with maintenance, depreciation, loan interest (if applicable), and insurance compared to renting. Depending on the frequency and distance of your long trips you may actually save money by renting.
You can ride with them on a few practice runs on a weekend and then continue to do so on a weekdays. Once you're both comfortable with the route and their ability to navigate it safely you can cut back on how much of the route you do together or just let them run it on their own. That last bit is a call to be made based on a lot of factors including your kids desire to ride with you.
I am all for right to repair, but that is a pipe dream in our country, given our economic realities.
That's a fascinating stance that you've outlined and that others have parroted. A stance that HN has implied with the reply to OP.
I come for the link aggregation and stay for the comment sections, it feels like watching a train wreck but it's hard to stop.
There are of course diamonds in the rough, comments from experts that are always informative yet humble. Comments like your comment above about your experience as an on-site engineer. Thank you for the insight.
In the below paper an example given is migrating from one API to another. The paper describes a semantically-aware large-scale tool for refactoring a Google sized codebase using map-reduce.
Given the externally visible churn in Google products it isn't much of a stretch to imagine they have similar or worse internal churn. In fact I have heard from xooglers that it was common place to internally have competing systems in different states of development and adoption.
https://www.quora.com/What-is-the-role-of-a-data-engineer-at...
View it from the eyes of a guy that retired in 2001, or any reasonable person, and $50k for a domain is an absurd amount that should have been tantamount to "I'm not selling, take off."