> B&M is different, Ads are there, but you aren't forced to look at them like Amazon does.
Ignorance is bliss. Unfortunately, even your physical Walmart store is also selling a lot of shelf space to manufacturers/advertisers (similar to how Amazon sell the first slot, or at this point first 'page'), especially those checkout lines (https://www.cbsnews.com/news/how-grocers-wring-extra-cash-ou...). That's why your on-boots retail staff can't change those planograms (which defines how to layout shelf space in a grocery store) willy-nilly, they're designed by the highest bidder. That's why those soda or chips seems placed in too convenient slots that are also 'coincidental' to those currently advertised in other ways, because it's, plain and simply, paid to be there.
Even if there's newer equipment, Protected Management Frames (PMF) compatibility with older laptops (for example) would be problematic. This is also the reason why WPA2/WPA3 co-existence mode fails on older equipment that is compatible with "normal" WPA2 (because PMF is mandatory in WPA2/3 coex mode).
This probably means that meeting the minimum price does not guarantee that you would be able to buy it due to other (probably opaque) criteria. For example, the seller might not want to sell to you/your company in particular, but is open to other people/companies.
I have a particularly valuable domain name that would be perfect for a museum that later opened with the same name.
I'd love to sell or even give it to the museum, but all my offers have been ignored. I don't blame them, since everything on the Internet is a scam these days.
But I won't just put it for sale to the highest bidder. Then it'll end up with a squatter. I'd rather sit on it.
Lots of HN readers located in countries outside of the US would find your answer infeasible (even the bank website requires their app for authentication, and this is the case for every bank).
Some CDNs (like Cloudflare) use solely BGP anycast steering for routing to the "nearest" server. Other CDNs (like Akamai, Fastly, Netflix, and YouTube) use a hybrid BGP-DNS steering because some ISPs have extremely questionable routing practices.
Unfortunately, if the CDN only rely on BGP steering (or conversely if you are a user who is stuck on an ISP monopoly), there are cases where this is not necessarily the nearest network-wise (or performant network-wise) if there are peering disputes. If the said ISP is a virtual monopoly or (worse) state-sanctioned to collect network "toll fees" (like in South Korea), non-preferred and international routes are (intentionally) congested.*
If you use a third-party DNS, you basically lose this DNS optimization, and ECS does not fully solve this (because sometimes the DNS override are placed only on the ISP's recursive DNS servers). You're basically in a lose-lose position: either use third-party servers and the IP addresses served to you on popular CDNs are in the congested path, or use the often-unreliable and heavily-logged ISP-provided DNS.
* Usually. There are exceptions, but this comment is just a simplification of the complexities of real-life networking (where RFCs and mutual cooperation die out without fanfare).
I would be curious if you could provide any examples for the issues you cite. They sound plausible to me, especially around peering disputes or in various Asia countries, but I wonder how in practice this looks in like a traceroute for the amount of added latency etc.
I would suspect some of non-optimized scenarios are eyeball network operator decisions on their networks that DNS providers and others do not have much control over. Like, Cloudflare resolves an IP that is closest to them, which is likely also the closest to the end user (and the eyeball ISP), but the eyeball ISP BGP path to that resolved IP takes a roundabout path because of their own BGP policy because $reasons.
BGP examples are easy to illustrate, although I don't have specific observations to share.
BGP's default route selection is to use the choice with the shortest AS Path.
If your ISP and your CDN peer in some locations, but not all, you can easily run into longer latency.
Ex: customer in Seattle, but ISP and CDN peer in Portland. CDN has a PoP in Seattle but not peered with the ISP.
BGP (without a lot of tuning) will prefer to send traffic through Portland, rather than through transit in Seattle, because the AS path through Portland is ISP -> CDN and the AS path in Seattle is ISP -> Transit ISP -> CDN
Of course, CDNs try to get peering in all common locations to address this, but that's not always possible, and not always because the ISP is unreasonably uncooperative. Sometimes the best path to resolution is by targetting the ISP dns server, but it doesn't catch all the customers.
Without disputing the added latency of CGNAT, the v6-only peering fights (not just the infamous Cogent-HE dispute but smaller regional ISPs peering only on v4) means that there are indeed cases where v6 is worse than v4 in practice. Again, nothing inherently wrong with v6 itself, but peering disputes means bad latency on v6, which means that protocols relying on TCP (like plain FTP, SFTP and rsync) really takes a hit in transfer speeds.
Also there are cases where the ISP didn't bother even optimizing their routing in v6. I understand that some ISPs in Asia (and especially in Japan, where it shows up on ordinary customers in terms like MAP-E and VNEs) have separate backplanes for v4 and v6 (some are legacy reasons, some are business reasons). Guess which one is being devoted more in practice (hint: not the one being devoted more by IETF).
This is their last hurrah where Sony is primarily in control (yes, the panels are from LG et al. and the main processor is a Mediatek, sheesh). The TCL JV will formally commence in FY 2027 (April 2027).
(note that this refers to the Windows NT kernel's operation because it had historically a POSIX emulation layer (NT Personalities), not the modern WSL which is just Linux in a Hyper-V)
Well, in that case it's a good thing I guess. Windows is orders of magnitude better when it comes to memory management on the desktop compared to Linux. Like why would I even want a single process killed by OOM killer? On Windows things just work, or get slow. On Linux it works and then mayhem ensues.
Last year I was writing a reply on a forum in Firefox on Linux when the OOM killer decided to nuke Firefox. Poof gone, mid keystroke. How does anyone think that's acceptable?
This was on a stock Linux distro, nothing special.
Actually, it depends on the Windows scheduler settings. On Windows Server, the default is to kill the foreground process (on the assumption that it is just a management app rather than a critical server component).
In either case, Windows tries a lot of things to avoid killing processes. Which at least in a desktop setting is an infinitely better approach than random beheadings without warning.
yeah. a lot of the issue with Linux's approach is that until recently, the kernel was the one making the choice, and it doesn't know which processes matter. The part Linus does a lot better if not getting to oom in the first place (and with the newish compressed ram stuff is getting even better)
Windows doesn't use fork/exec for process creation in any relevant way today
There are Native APIs for implementing fork (needed for the obsolete POSIX subsystem, primarily), but even on the Native API side, processes are usually spawned through NtCreateProcess or RtlCreateUserProcess, though there is a bunch of setup with regards to the Csr APIs for the Win32 CreateProcess[1]).
Basically, CT did indeed worked as designed, but there was no monitoring by the domain authors (which to be fair there are a dearth of solutions of the time).
On a related note, Let's Encrypt also issued the presumably-interception certificates. This can be possibly something that requires interception at the VPS level (otherwise we already detected the BGP leaks). Presumably, Hetzner was forced to do a raw interception and then redirecting all relevant ports to a middlebox for inspection and CA issuance (and since that the ACME spec is well-defined, they can simply check if the handshake contains the TLS ALPN challenge and then redirect them to special code that will reply with the correct things).
Ignorance is bliss. Unfortunately, even your physical Walmart store is also selling a lot of shelf space to manufacturers/advertisers (similar to how Amazon sell the first slot, or at this point first 'page'), especially those checkout lines (https://www.cbsnews.com/news/how-grocers-wring-extra-cash-ou...). That's why your on-boots retail staff can't change those planograms (which defines how to layout shelf space in a grocery store) willy-nilly, they're designed by the highest bidder. That's why those soda or chips seems placed in too convenient slots that are also 'coincidental' to those currently advertised in other ways, because it's, plain and simply, paid to be there.