RijilV

The general arguments here are that CDNs have replaced tier1 ISPs as the predominant force on the Internet. Geoff Huston has written about this over the last ~10 years[0][1].

So the question as to alternatives is void - the problem is CDNs MitM'ing yur datas across multiple domains, and the loss of the nostalgia (or whatever) for the tier1 ISPs (who were all horrible in their own ways).

I don't particularly subscribe to the harms Geoff purports, but I cannot fault his analysis of the situation. If you haven't read it before, it is worth the read.

If you want a free and open Internet, then you don't want someone else's TLS proxy between every consumer and every producer. This ignores the problems of DDoS, scaling, etc. Buuutttttt.... 99% of websites don't have those problems, so why are you building a solution which trades decentralization for it?

Anyhow, sounds like you're into all the wonderful things Cloudflare (and every other CDN) provides. Great. That's fine, just don't be angry when the free and open Internet promised to all of us in the 1990s requires 3rd party gate keepers. And no, there aren't solutions to all the problems.

0: https://blog.apnic.net/2016/10/28/the-death-of-transit/ 1: https://www.thousandeyes.com/blog/internet-report-evolution-...

Find https://fabiensanglard.net/usbcheat/index.html to be quicker and easier to understand (posted a month or so ago)

14 of them. The first person to climb them all did so without supplemental oxygen.

https://en.wikipedia.org/wiki/Reinhold_Messner

I hate to be the one to break it to you, but high end skis make tradeoffs which are harmful to beginner or intermediate level skiers... also there's sorta no thing as "best ski". what you'd want for high speed bombing double blacks is going to be different from off piste or moguls or snow park fun.... double also, skis wear out. Depending on who you want to believe it's as low as 20-30 days. Which, granted the average skier is at something like 5 days a year. but if that's you... triple also?

As for how this relates to audio compression, in particular in the context of 2012. you are making a tradeoff of storage size and decompression cost. Maybe that doesn't matter to you, but maybe it either did in 2012 or still does.

If you've never had an opportunity to spend time in a datacenter as a software developer, that's unfortunate but also far too common. What things look like on the inside vary company to company. Generally you're in an OSHA-abiding environment, so safety shoes, ear and eye protection, sometimes gloves.

There's a variety of roles. Security, electricians, HVAC engineers, generally some type of site foreman-ask role, logistics (depending on the size of the place), and technicians (for a lack of a better word, feels like every place calls them something different). There's a variety of roles that often float between sites or oversee many sites, depending again on the scale of the place. AWS is huge. Bigger than you're imagining, so there's quite a few levels deep and include real estate folks as well as construction roles. If you go and look at job postings, you'll even see roles for nuclear engineers at some companies.

But generally what you're talking about here are what I'm calling the technicians. They're responsible for wheeling racks into place (depending on the company they may also be responsible for unloading the trucks). Cabling is nearly always outsourced these days (though not the design of the cables), so rolling a rack into place generally involves securing it to the floor and connecting power, data, and more often than not now-a-days liquid cooling.

The other part of their job is "troubleshooting" failed hardware. Again, really depends on the company. Big big shops have "dumbed down" troubleshooting as much as they can - for a lot of reasons. You don't have to pay folks as much because they're thinking and doing less, the more time they spend troubleshooting the longer the server is offline, and if there's no troubleshooting there's not much for them to screw up. I'm sure there are some great places to be a tech where you get to rip apart servers and bust out the multimeter, that to my understanding is not how the hyperscalers who actually hyper-scale do it.

There's some cleaning, parts management, destroying broken hard drives, shoveling snow off the roof (no lie), and a variety of other odd tasks.

If you ever have the opportunity to check out one of those places it can be a riot and a real eye opener. Depends again on the company though, some of those places have insane security (metal detectors, badge+pin, turnstile door procedures) which make visits super un-fun if they're even allowed outside of legit business reasons. Other companies... well I'm glad that's not where I store my data.

Back "in the day" (2005 give or take a handful of years) techs would often write their own automation and even build some simple services.

And yes, the jobs don't pay particularly well depending upon what it is. Electricians and such command decent wages, but the security guards and techs don't make crazy amounts. I think folks doing contract cabling can come out ahead.

Anyhow, SWEs are wildly insulated from the realities of what things look like on the ground. Maybe that's a good thing, IDK.

The methodology for validation seems a bit off, in my setup I return a local IP for all of the domains in that list and serve empty content for it. Thus it detects the ads getting through, but in reality they did not.

This is the study which is behind the recent news articles on the AMOC collapse:

https://www.science.org/doi/10.1126/sciadv.adx4298

Basically newer modeling has shown a stronger weakening of the system. Lots of uncertainty, but 1/3rd loss by 2100. There's a lot of unknowns with feedback loops and tipping points where the whole thing might collapse if a threshold is crossed.

careful what you wish for.

There's also https://hckrnews.com which is "a chronologic list of items that have made it onto the Hacker News homepage" regardless of the post-made-it-onto-the-homepage flagged status.

I keep on pestering folks who work at Apple to add color filters to the per-app accessibility options, who knows maybe there's someone there who'll read this. (Edit: there is an internal feature request already)

Since iOS of a couple of versions ago, you can trigger color filters on and off from shortcuts, and get a similar behaviour, but it isn't perfect and sometimes glitches. I do this so my photos app and a few others are in color, but the rest are in grey scale.

except of course on the wire, where it's wildly a mess.

TLS 1.3 version in the record header is 3.1 (that used by TLS 1.0), and later in the client version is 3.3 (that used by TLS 1.2). Neither is correct, they should be 3.4, or 4.0 or something incrementally larger than 3.1 and 3.3.

This number basically corresponds to the SSL 3.x branch from which TLS descended from. There's a good website which visually explains this:

https://tls13.xargs.org/#client-hello/annotated

As for if someone is correct or whatever for calling out TLS 1.x as SSL 3.(x+1) IDK how much it really matters. Maybe they're correct in some nerdy way, like I could have called Solaris 3 as SunOS6 and maybe there were some artifacts in the OS to justify my feelings about that. It's certainly more proper to call things by their marketing name, but it's also interesting to note on they behave on the wire.

So the internet is a series of pipes, or tubes, whatever. This quintessential personal blog website is hosted somewhere in this inter connected mess of things. There’s a hierarchy of these pipes/tubes, and they all have some ever diminishing capacity as they head from a mythical center to the personal blog website.

When the bad guys want to DDoS the personal blog website they don’t go and figure out the correct amount they need to send to fill up that pipe/tube that directly connects the personal blog website, they just throw roughly one metric fton at it. This causes the pipes/tubes before the personal blog website to fill up too, and has the effect of disrupting all the other pipes/tubes downstream.

The result is your hosting provider is pissed because their infrastructure just got pummeled, or if you’re hosting that on your home/business ISP they also are pissed. In both cases they probably want to fire you now.

There aren't winners in a trade war, one side just loses more slowly than the other.

Not for nothing, there’s a support group for those of us who’ve been hurt by WHU sev2s…

I have to wonder at $760/forever if this feature even pays for itself. The pure dystopian version of this is that VW loses money on this directly (never mind lost sales) because the hardware and service side costs more for all of the cars than what they get from the small percentage of owners who do pay.

Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should.

It feels really market by market. Where I live, the house I’ve been in is 50-75% mortgage cost vs rent on a comparable property. That mortgage is a bit over 10 years old, and has been below rent rates for nearly the whole time. Sure, I have upkeep, but I also get to make whatever modifications I want (and that’s a thing that’s appealing to me). And yes, I live in a major west coast city.

These broad numbers games feels like rationalizing a decision today. Maybe it’s true for a particular locale (I don’t live in the Bay Area), but these articles feel like they’re painting with too broad of a brush given I can’t maths out a negative for my situation.

Not much of an article. Do yourself a favor and read the LWN one:

https://lwn.net/Articles/961978/

tl;dr: The Linux kernel team view all bugs as a possible security issue. The CVE assignment teams tries to minimize the number of Kernel CVEs because corproate policies mandate fixing CVEs in 30/90 days. There's a lot of politics.

Daily sea surface temperatures:

https://climatereanalyzer.org/clim/sst_daily/

\0

Worth re-posting Theo's 2007 note about CPU security bugs again:

https://marc.info/?l=openbsd-misc&m=118296441702631&w=2

My hunch is that as they suspected these types of issues is what guided them away from things like AVX and other optimizations.

Sure, U-Haul. It's $19.95/day and $1.39/mile. Last time I rented one the automated "don't have to talk to anyone" app I couldn't figure out, but it took less than 120 seconds to navigate the in person exchange to get the key.

You don't need a pickup truck to go camping (they're actually not terribly useful for that) or yard sale shopping. Like seriously it's https://van.life not truck life.

That’s not really what a CDN is/does…

The value proposition of a CDN is being physically closer to customers around the world, which means renting space in (often) expensive carrier hotels.

Yes yes all the major CDNs have loads of developer and infrastructure wizbangs to keep you on their platform but that’s not the fundamental value.

It's been a quarter of a century since IPv6 launch.

There's some really good lessons learned here. IPv6 requires everyone, everywhere, needs to change their configuration to add IPv6 addresses and network connectivity to every node/endpoint. The madness of course is that all the underlying infrastructure software (routers, OS, standard libraries) all support IPv6. It would seem, at a large enough scale, that software is the easy part, configuration is the hard part.

DJB wrote this up two decades ago[0] and it remains relevant. In particular the comparison between IPv6 and MX records. It took me a little while to wrap my brain around just extending existing software to support sometimes 32bit and sometimes 128. Ultimately it wasn't hard to dream up a few solutions for how that would work.

The other thing, FWIW, which has been slowing IPv6 adoption is business owners not asking for it as a high priority item from their providers. I've seen this happen way more often that I would like where provider asks a customer what they want and the customer never mentions IPv6, and when prompted shrugs it off because they don't see it as a business critical (and in fairness, it hasn't been). Yes provider isn't asking the 'nerds' at their customer's businesses, but those folks also aren't the ones paying the bills so...

0: https://cr.yp.to/djbdns/ipv6mess.html

Welp, their TLS cert expires second week of the new year. I really hope for them that’s an automated process.

> SMS is a terrible solution that really only solves "you used the same password across two sites

Right. That’s the sole purpose. People pick bad passwords and reuse them, but you already know that.

As much as tech tries to make this easy people, it’s a horse-vs-water problem. Even smart people refuse to use to use password managers. Most of those people have figured out how to receive text messages.

Seriously, go find someone who owns a JitterBug phone and watch them create a new account on the website of your choice. We’ve got a long way to go.

I find this one handy:

#!/bin/bash echo |\ openssl s_client -connect ${1:?Usage: $0 HOSTNAME [PORT] [x509 OPTIONS]}:${2:-443} 2>&1 |\ sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' |\ openssl x509 ${3:--text} ${@:4} 2>/dev/null |\ sed '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/d'

It’s a good read, and I really wish time was always that simple. Sometimes you have multiple platforms on different clock systems and distributed systems running across them. Did you know google and amazon smear leap seconds? GPS/Galileo/that-China-one don’t have leap seconds (but all are different TAI offsets) but that Russian GPS one does have leaps. They all have slightly different versions of utc.

Most of the time none of that matters and you can just install chronie and point it to whatever.pool.ntp.org and you’re off to the races. But boy does it suck when you have to to know.

In the same city on the same bike ride I and a friend have been accosted by police for both riding on the sidewalk and in the street. Different cops, blocks apart.

The law is subjective and when you’re rolling around in spandex on a multi thousand dollar road bike and a paramilitary USA “peace officer” stops you, the law doesn’t really matter. You just “yes sir” and hope to be allowed to move on

doubles the cost of implementing anything. Say a customer wants feature-X. Unless you're magically at the point where in your 2-3 year cycle where you're switching, both the A and B team need to implement feature. Of course, that's assuming you don't just tell the customer to stuff it and wait 2-3 years.

You're also assuming that you know ahead of time all use cases and interfaces. It's surprising how dependencies are taken. I've seen large scale systems break when a HTTP 204 was changed to a HTTP 206, or a base36 field changed to base62. Now again maybe you're thinking the consumer can stuff it and update everything whenever you decide to switch over, or that you'll have captured everything and have tests around it. But.. for any sufficiently complex system with a sufficiently large customer base everything about your interface becomes your customer contract. Changing everything all at once is going to break a ton of things nobody ever thought about.

Doing upgrades every 2-3 years means you're pretty much never going to be good at them. Institutional knowledge seems to have a 2-3 year memory horizon. Sure, you get that one person who is a bit of an archeologist/historian but tenure at most shops is not long ("The median number of years wage and salaried employees stayed with their current employer in 2018 was 4.2 years" - first hit on Google). While you're upgrading every 3 years, each team only does so every 6 years. Nobody is gonna remember what it looked like.

There's also a meta point, which is what are you actually trying to solve? Is it so hard to go from architecture A.v0 -> A.v1 -> architecture B that you need to build A, maintain A and simultaneously build B? If moving between architectures is so hard but moving between versions of an architecture isn't - why is that the case and why can't you make the former case easier?

I'm assuming that your plan has you upgrading the A-architecture within those 2-3 years. Maybe you're saying you wouldn't touch it at all and just hope there are no security issues or features or scaling you need to do.

There's also another point which is you've coupled all changes to a particular cadence. Maybe you want to upgrade your network, servers, storage systems, OS, application services, etc on different cycles. At the very least you're sorta hoping that all of those things have similar release cycles, which realistically you're going to be picking some network switch that's been out for 2 years and marrying it to a storage product that was released last month (because the previous one is 5 years old and will be out of support before your next refresh).

And scaling... what happens when you can't get the same server you were ordering 2 years ago? Tell users they can't have nice things until the other team rolls out their massive platform shift in a year? Or would you adopt a new platform to scale on, in which case, why are you doing this A and B team thing again?

And not only do you need two teams, but you need two sets of hardware which means you need twice as much datacenter space, etc etc. Do folks need to two desk phones when you roll that out?

And ... I'm gonna stop here...

T9 if you’re good with paraffin based product.