If you remove DNS servers from the equation, you need to write down records for other domains, too. This means you have to chase every domain for changes in CDN configuration, hosting provider or ISP migrations, IPv4 to v6 migrations and so on.

You don't have PTR records, which means you can't find out a name from its IP address.

You also miss other features of DNS, like SRV, MX and so on.

More subtly, you lose the ability to control DNS resolution over systems you can't control. If a DNS server says host.example.com is 192.168.0.4, a Windows desktop, a Linux server and your toaster will agree on that (especially if no local cache is enabled, but even then TTLs apply). If for some reason you cannot control a particular machine, you will never get it to consider that new DNS record. This can happen for a lot of reasons.

With —-all

Yes, there are alternatives to GDP, but context is key.

If you just to make more meaningful charts or rankings of top 10 countries, you just switch to another indicator and that's it. This could also impact, to some extent, real economic choices.

Other applications are more difficult.

For example, debt substainability. Governments issue bonds to finance stuff, but they eventually have to repay at least interests. This introduces a link between GDP and debt growth. If you replace GDP with another index things get more vague: a country may have the maximum happiness, but if it issues bonds and it cannot repay its interests, it's going to have some trouble anyway.

Monetary policy is also difficult to decouple from GDP. Alternative indicators often mix many aspects, which means the central bank can either

1) target the whole index, which means it could try to influence not just interest rates, but education, healthcare and so on (it essentially blends with the government), or

2) keep targeting inflation, but through non-GDP estimates, which means the price "signal" is mixed with other "noise".

If anyone, including your surgeon, can take that life insurance policy based on your life, things can go bad pretty quickly (hint: what happens if a profit-maximizing surgeon would earn a lot more money from your policy than from his regular job?).

That's why there is so much emphasis on signing or stamping projects in the "ordinary" engineering world: you're literally telling a potential third party (which may include a court of law at some point) that you reviewed the work and can be held responsible.

This doesn't rule out team work of course (just think about civil engineering, it's not something you can do alone most of the times), and this doesn't mean there are no unethical or even corrupt engineers, but there is in most cases a single person who is responsible from a professional, ethical, and legal point of view.

In my experience this never occurs with programming unless you're dealing with SWE in engineering-adjacent sectors (aerospace, ...), and even then I'm not sure as I have no personal experience in those areas.

It does mention IP concerns, but that's not the greatest existential threat posed by AI.

It’s like SMS vs MMS or modern chat. With pure text, you can at best add a link to a picture (which could get rotten or inaccessible for other reasons), but you cannot directly graphical content.

Not necessarily. I hate frontend tasks not because I don’t care about the user, but because I don’t have decent graphic skills. I can code but I don’t have a good istinct for colors, size, font styles, or other frontend issues that feel more art than science.

I’m honest about it, and luckily my job doesn’t involve frontend tasks, but this doesn’t mean that I don’t care about the users. In fact, you could say that I avoid frontend tasks precisely because I care about users and I don’t want them to be tormented by my awful UI choices :)

> Frontend problems are just easier to see — bad UI, confusing views, ugly design. Everyone notices. Backend problems are hidden — slow API response, bad errors, hard to manage code

That’s one way to see it. Another way is that frontend problems are subjective. The same UI could be confusing for someone and reasonable in someone else’s eyes. What’s ugly? “Beauty is in the eyes of the beholder”, as the saying goes.

Backend problems can be hidden and random but they are objective. If an API returns 500, there is something wrong. It may do so only when a plane passes by or when a cosmic ray happen to flip a bit, but everyone can agree that a 500 is not supposed to happen (unless your API intentionally returns 500 for success…). The root cause may be obscure, but the existence of an issue is objective.

But yes, you don’t always need cool technologies.

It probably doesn’t require consensus among all participants (pairwise consensus at every step should be fine), so there is very likely no voting.

It’s not even permissionless. It’s not like a random company could join this “chain” simply because they can generate a keypair.

It’s a fundamentally different problem, and it makes sense that the architecture is different.

Economics talks about “price elasticity of demand”. A good or service is elastic if small changes in price greatly affect the demand. An inelastic good is, at its extreme, one for which people would pay literally anything.

Basically YouTube is betting that their Premium subscription is so important, or will become so important, that it will pretty much become a necessity. Likely because of discounts (invite a friend and get a discount) and network effects (YouTube Premium becomes a new video-oriented social medium like Tiktok?) or because the standard free version will become so bad that you will pay the subscription to have a somewhat decent experience.