Benefit society, or go to support a pharmaceutical company that will in some way benefit society in exchange for making a few people rich?

No ethical consumption working conditions under capitalism.

What I’d like for a configuration language is a parser that can handle in-place editing while maintaining whitespace, comments, etc. That way, automatic updates don’t clobber stuff the user put there, or (alternatively) have sections of ### AUTOMATIC GENERATION DO NOT CHANGE###.

You need a parser that handles changes on its own while maintaining an internal representation. Something like XML DOM (though not necessarily that exact API). There’s a handful out there, but they’re not widespread, and not on every language.

I’m not sure where you’re getting that Nintendo sells at a loss. They don’t have amazing margins on hardware, but they don’t like selling at a loss. IIRC, commodity prices and a price drop meant the GameCube was briefly sold at a loss, but it wasn’t long, and it wasn’t by much.

Whatever else you can say about Nintendo, they are really good at managing manufacturing costs.

There’s a little wiggle track burned into PSX discs that’s impossible to duplicate with burners, and it won’t boot up unless it sees that. There’s workarounds that eventually came out, but console copy protection doesn’t have to last forever. It only has to last most of its primary life until the next gen comes out, and PSX managed that.

There was a project where the next console would have been the Genesis, 32X, and CD in one box with a new name. I don’t know if that would work, or if it’d be viewed as something of an in-between generation, like the Turbografx, and people ignore it.

It’s probably be easier to develop games for, unlike the Saturn. It’s not the only thing that held the Saturn back, but it didn’t help.

Not sure about GP, but that’s basically what we did under “SAFe” (Scaled Agile Framework). PI planning means taking most of a sprint to plan everything for the next quarter or so. It’s like a whole week of ticket refinement meetings. Or perhaps 3 days, but when you’ve had 3 days of ticket refinement meetings, it might as well be the whole work week for as much a stuff as you’re going to get done otherwise.

It’s as horrible as you’re thinking, and after a lot of agitating, we stopped doing that shit.

There’s almost always at least a little ASM sprinkled into any kernel, so that’s not a big deal.

OTOH, there is the factor of “you know how Chrome takes up 2GB per tab? What if that was a whole OS?”

You’re probably in a country that got a ton of allocations in the 90s. If you came from a country that was a little late to build out their infrastructure, or even tried to setup a new ISP in just about any country, you would have a much harder time.

The Rust compiler tends to turn my impostor syndrome to 11. I assume she has some kind of humiliation kink and I do not consent.

Nope. There is an industry standard way of measuring latency, and it’s measured at the halfway point of drawing the image.

Edit: you can measure this through Nvidia’s LDAT system, for example, which uses a light sensor placed in the middle of the display combined with detecting the exact moment you create an input. The light sensor picks up a change (such as the muzzle flash in an fps) and measures the difference in time. If you were to make this work on a CRT running at NTSC refresh rates, it would never show less than 8.3ms when in the middle of the screen.

If you are measuring fairly with techniques we use against LCDs, then yes, CRTs have latency.

JSON and XML can be “real” languages. Mostly because of people who didn’t stop to ask if they should.

He mangles some of the pros and cons of CRTs towards the end.

They aren’t going to be indefinitely reliable. The phosphor goes bad over time and makes for a weaker image. Doubly so for color phosphors. Some of them are aging better than others, but that’s survivorship bias. We might be looking at the last decade where those old CRTs can still be in anything close to widespread use. Will probably be a few working examples here or there in private collections, of course.

CRTs do have latency, and this is something a lot of people get wrong. A modern flatscreen display can have better latency than CRTs when the hardware takes advantage of it.

The standard way of measuring latency is at the halfway point of the screen. For NTSC running at 60Hz (which is interlaced down to 30fps (roughly)), that means we have 8.33ms of latency. If you were to hit the button the moment the screen starts the next draw, and the CPU miraculously processes it in time for the draw, then it takes that long for the screen to be drawn to the halfway point and we take our measurement.

An LCD can have a response time of less than 2ms. That’s on top of the frame draw time, which can easily be 120Hz on modern systems (or more; quite a bit more in some cases). That means you’re looking at (1 / 120) + 2 = 10.3ms of latency, provided your GPU keeps up at 120 fps. Note that this is comparable to a PAL console (which runs at 50Hz) on CRT. A 200Hz LCD with fast pixel response times is superior to NTSC CRTs. >400Hz is running up against the human limit to distinguish frame changes, and we’re getting there with some high end LCDs right now.

When talking about retro consoles, we’re limited by the hardware feeding the display, and the frame can’t start drawing until the console has transmitted everything. So then you’re looking at the 2ms LCD draw time on top of a full frame time, which for NTSC would be (1 / 60) + 2 = 18.7ms. Which is why lightguns can’t work.

This is the same language where you have to say PLEASE sometimes or it won’t compile. But if you say PLEASE too much, the compiler will think you’re pandering and also refuse to compile. The range between too polite and not polite enough is not specified and varies by implementation.

import tensorflow # we don't actually use this anywhere, but my boss told the client we use AI

Every time I see a defense of IPv4 and NAT, I think back to the days of trying to get myself and my roommate to play C&C: Generals together online, with a 2v2 game, with one of us hosting. Getting just the right combination of port forwarding working was more effort than us playing C&C: Red Alert on dial up when we both lived at home.

With IPv6, the answer is to open incoming traffic on the port(s) to the host machine (or just both since the other guy is might host next time). With IPv4, we have to have a conversation about port forwarding and possibly hairpin routes on top of that. This isn’t a gate for people “who know what they’re doing”, it’s just a bunch of extra bullshit to deal with.

There’s one practical thing. Routers have had years to optimize IPv4 routing, which has to be redone for IPv6. Same with networking stacks in general.

In theory, IPv6 should be faster by not having to do bullshit like CGNAT. There’s every reason to think it’ll match that advantage if we just make it happen.

The other app off the top of my head is VoIP. You should be able to “dial” a number directly. Most solutions go through the company’s data center first in order to pierce through NAT. Which makes it more expensive, less reliable, slower, and more susceptible to snooping.

There’s a “if you build it, they will come” effect here. Once you can address hosts directly, a whole bunch of things become better, and new ideas that were infeasible are now feasible. They don’t exist now because they can’t.

There ought to be more servers.

Will the app for the smart thermostat be updated three years from now and still be useful? If it was instead a web server app on a routable IP, it wouldn’t matter provided they didn’t fuck up the authentication and access control.

I exercised JavaScript out of some of my apps, and I’m happier for it.

I tried, but the infrastructure collapsed on me.