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.
They have x86_64 models.
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.
Yes, everyone forgets them. Mostly for good reasons.
Arm is better because there are more than three companies who can design and manufacture one.
Edit: And only one of the three x86 manufacturers are worth a damn, and it ain’t Intel.
Edit2: On further checking, VIA sold its CPU design division (Centaur) to Intel in 2021. VIA now makes things like SBCs, some with Intel, some ARM. So there’s only two x86 manufacturers around anymore.
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.
You’re right on. As long as you’re otherwise following best practices for storing passwords, there’s no downside.
Those (?=...) bits are positive lookahead assertions:
Lookaround assertions are zero-width patterns which match a specific pattern without including it in $&. Positive assertions match when their subpattern matches, negative assertions match when their subpattern fails. Lookbehind matches text up to the current match position, lookahead matches text following the current match position.
The one (?!...) is a negative lookahead assertion.
The $& var doesn’t really matter outside of Perl. It contains the text of the pattern you just matched, but even within Perl, capture groups are preferred. Once used at all, it will slow down your program every time a new regex is hit, which is especially bad in long running web server environments. Gets used sometimes in short scripts, though.
What really matters is that the lookaheads don’t consume any text. In other words, the pointer that shows where in the text we are doesn’t increment; once we’re outside of the lookahead, we’re still right back in the same place.
So let’s break this down using the /x modifier to make it somewhat sane.
/^
(?!.*\s) # no whitespace allowed
(?=.{8,256}$) # between 8 and 256 characters (the '$' here indicating the end of the string)
(?=.*[a-z]) # has to be a lowercase ASCII alphabet char somewhere
(?=.*[A-Z]) # has to be an uppercase ASCII alphabet char somewhere
( # need a number, or a list of special chars on a US keyboard
(?=.*[0-9])
| (?=.*[~!@#$%^&*()-=_+[\]{}|;:,./<>?])
)
.* # consumes the whole string
$/x
Notes:
That last one has some nuance. We often say you shouldn’t put any upper limit, but that’s generally not true in the real world. You don’t want someone flooding an indefinite amount of data into any field, password or not. A large limit like this is defensible.
Also, lots of devs are surprised to learn that bcrypt and scrypt have a length limit of 72 bytes. A way around this is to run your input through SHA256 before giving it to bcrypt or scrypt.
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.
I exercised JavaScript out of some of my apps, and I’m happier for it.
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.