I'll admit I don't understand all the ins-and-outs of DNSSEC, but isn't it supposed to protect against exactly this sort of thing? It would completely remove the ability for a man-in-the-middle to provide bogus DNS results to a client that validates DNSSEC signatures.

That sounds suboptimal, given that there's a reason GPUs tend to use GDDR (or HBM) rather than normal DDR. For comparison, a 5090 has around 1.8TB/s of memory bandwidth. Maybe better for some tasks, but that makes it a sidegrade to the 5090 at best.

The problem with the 10th is that the federal government will still grab as much power as they want, because they can just interpret their enumerated powers as broadly as they want. For example, the commerce clause - it's been made nearly worthless at this point, as the federal government is able to regulate things that are neither interstate nor commercial thanks to disastrous SCOTUS decisions. Fortunately, more recent decisions have backed away from those a little bit, but it has taken 80+ years just to chip away at it.

Sorry but this is still wrong on a number of counts.

GGP did not limit the scope to just system resources. System resources are usually not the issue anyway. Nobody says that an app is a "resource hog" because it left a few file descriptors open. They say it's a resource hog because it's using 4GB of RAM to do nothing. The socket to user mapping is merely an example - you're supposed to extrapolate it to whatever use case you have.

You absolutely should be thinking about this. I can tell you've probably never used Java Mission Control or similar, since it will outright show you how much memory is being wasted to duplicate strings. If you're, let's say, parsing XML files, you're going to see lots of small duplicate strings in the tag names. Same thing with a log parser, or anything else handling textual data. HTTP server? Yeah, you're gonna see a lot of similar strings in headers and such.

No, I'm thinking about memory because I don't want my program to eat all of a user's RAM for no reason, or to inflate cloud bills because we have to allocate twice the RAM for JVM instances.

Who says it's frustrating? Who says the language is the problem? Java code will typically use less memory than the equivalent in Python, JS, and other high-level languages. It packs objects' fields much more efficiently, and supports primitives. However, a bad programmer can still destroy that efficiency by thinking that they don't need to worry about memory. Just because the language handles garbage collection of unreachable objects doesn't mean you can just forget about memory usage.

Utterly embarrassing that Comcast's highest cable plan is 1.2gb/s down with a 1.2TB/mo cap. If you actually max out that download bandwidth, you blow through the cap in less than two and a half hours. You could download 388.8TB/mo with that speed, and the cap is less than 0.3% of that.

You still have to think about a lot of memory-related things to make applications memory-efficient and free of memory leaks.

For example, somewhere in my code, I might have a map from sockets to users, to keep track of which user is authenticated on any given socket. However, I need to either make absolutely sure that I am removing mappings from that when a socket terminates through any means - even unclean ones - or, I need to use weak references to make the garbage collector do that for me. The fact that just about every language with managed memory supports weak references should be a hint that you still have to think about it.

You also have to think about things like what strings to intern. If you know you're going to have tons of duplicate strings, it might make sense to intern them. But not if you're going to have many distinct streams, in which case you just inflate the string pool too much.

Part of the issue is that creators have their own sponsored segments in their videos, so you're still supporting them even if you block ads, and it means that YT premium isn't even an "ad-free" experience in the first place. I'd much rather support creators directly anyway, especially seeing as creators are often forced to alter their own content just to make advertisers happy.

Just be aware that the downloads are DRM'd, and you can no longer play it if your device hasn't phoned home recently (48h). So if you want them to be available for more than two days, it's a useless feature.

Which is kind of bullshit, if you think about it. The default HTML5 video player can already do that. I would not be the least bit surprised if it turned out that Youtube went out of their way to break it on purpose.

One thing I've noticed is that languages seem to be more likely to adopt features from other languages. For example, Java has virtual threads now, which reduces some of the advantage that Golang has over it in heavily asynchronous tasks. GIL-less Python will eliminate one of the major downsides of Python. Typescript has polished the JS turd enough to make it a usable language.

At this point, getting traction for a new language is incredibly difficult. You not only have to fight the uphill battle of other languages having massive collections of libraries, but also the fact that your language's killer feature could very likely be integrated into an existing language.

I don't have an issue with a site not wanting to serve users at a loss.

I do have an issue when they do that for nearly two decades, destroying every major competitor in the space, and then doing it.

It has also made many of these tasks far easier.

For example, if I want to host several different websites, possibly with different backend languages, it makes that easier - even if it's only on a single host. You would have to manually configure a web server to reverse proxy to the individual sites' directories or backend processes, figure out certificate provisioning for all of the domain names, update DNS records, deal with updates/deployments, and so on. That's not even considering things you'd need to be truly prod-ready, like blue-green deployments, failover, or limiting resources of each site so that it doesn't crash the host if it goes haywire.

In k8s, I can just push my containers to a registry, use ingress objects to specify the hostname/paths of each domain, do certificates automatically via LetsEncrypt or similar, blue-green, resource management, and many others. Sure, you could do all of that manually, with or without containers, but you'd essentially just be reinventing the same thing but not scalable.

It was also useful for crappy sites that show Googlebot the full content, but paywall or otherwise hide the content when you actually go there.

Did you miss the part where I said "I'm fine with segregating matchmaking based on input device"?

I don't choose input devices for the primary purpose of gaining a competitive advantage. I choose an input device based on what feels the most comfortable in the game. Any advantage is secondary, and is easily handled by just making separate matchmaking.

I don't know how I feel about the notion of "games that support it".

Having used the original Steam Controller, and now the Steam Deck, it's actually pretty cool how well those work for playing games that were never intended for controllers. I'm fine with segregating matchmaking based on input device, but the notion that you shouldn't be allowed to choose the peripheral that you wish to play a game with doesn't sit well with me (especially if it's a game where one type of input device is clearly better than others - e.g. a mouse in an FPS).