This is missing that all the early consoles had major price drops during their lives, and most of the sales happened after those price drops. Relatively few people paid the full original retail prices for the NES, SNES, Genesis, etc. Games varied somewhat more but older games tended to be a little cheaper too.

Meanwhile the last couple generations of consoles have stayed close to their launch prices, had a "Lite" version released, or have even gone *up* in price for various reasons.

I'm not sure why you think it has to be charging to have thermal runaway. You can find plenty of videos of lithium/etc batteries having thermal runaway without being actively charging. All it takes is a charged battery and physical damage.

Whether this particular case was warranted or not I can't answer, but it does say it had shown signs of deformation from the seat moving around.

Office 95, 97, and Netscape both used to do it too, and I think even Office 4.3 or whatever the last version for Windows 3.1 had a quicklaunch toolbar that sped up launch using similar methods. I'm blanking on others but I remember some other big software having agents that sat in the systray to speed up launch. I usually kept all that disabled because they just sat there eating memory when unused and the improvement in launch speeds wasn't worth it.

Everything old is new again.

My recollection with the early days of ReactOS was it was intended as much to enable using Windows drivers and underlying frameworks back when Linux and other options had much more limited hardware support, especially on the leading edge, as it was just for running Windows applications. Especially for stuff like graphics and wifi and DirectX where there was relatively limited support and being able to use vendor drivers and such would have been a big deal.

These days that's much less of a problem and stuff like WINE seems like it'd largely be the superior. Linux supports most hardware out of the box or very quickly, and what can't run is more of a software issue than an underlying lack of support issue. ReactOS might slot in as a replacement for embedded or specialized industrial uses, or maybe as an option for ancient/low end computers for people who still need to run Microsoft stuff, but I feel like it's increasingly irrelevant as time marches on. Windows is a moving target and they're still trying to get it to run Windows 2000-level stuff.

By and large NT 3.5x outperformed NT 3.1 on identical hardware. They optimized 3.5x a bunch and many people consider 3.51 to be the first "good" version.

As for using leaked XP code, that'd be an absolute nightmare from a licensing and legal perspective. I would expect Microsoft is constantly going over any project that claims to implement Windows features with fine toothed combs to make sure nobody has used leaked code. They've already plonked a couple projects like the kind of hilariously named OpenNT based on the NT4 leaks, someone trying to release an XP-based OS from leaked source would be in trouble real quick.

Most developers with much sense would avoid ever even the appearance of looking at leaked code. It could jeopardize them on any future project they might work on that happens to tangentially be related to either Windows core development or work on competing products/projects. When ReactOS did their big code audit they had to be wary of developers who had looked at it or were submitting patches clearly based on it, intentionally or not.

I've noticed that Google's AI summary stuff has started showing links to the pages its using to generate its answers for citations, but that it still occasionally comes up with completely off the wall stuff from having snarfed bad links with bad information on them. So it's still not completely trustworthy for being correct, but at least it's not completely mysterious where it came from.

I feel like Win2k (and XP) service packs were reasonably decent. I also don't remember having too much issue with even general updates with those, at least from a user perspective. I suppose towards the end XP got a little bit creaky from all the stuff bolted onto it while Vista/7 were delayed but I have mostly positive memories of it. I didn't do a whole lot with the server versions of those so can't really speak to the Server experience.

Win3.x and before mostly scraped by through the benefit of just not really having a whole lot of updates. There were Y2k fixes for 3.1 and up, and the 3.1 to 3.11 update (which was distinct from the WFW311 thing) which tweaked a few things, but there weren't a lot of other system-level updates to those like you saw later on. Especially not layers upon layers of them where later updates depended on earlier updates or it failed or having mixed versions of things blew up, or you installed IE4, then 5, then 5.5, then 6 on something and hoped for the best. I guess Win32s counts but since it was a whole separate subsystem it mostly left the base 3.x OS alone and was pretty easy to disable if it screwed something up.

Most remotely modern cars detect a passenger with electrical fields (capacitance? Something), not weight. So various electronics tend to be more likely to trip the sensors than a lot of other things.

That was a standard error message on IBM PC compatible BIOSes from pretty much the beginning through to more or less today.

The idea being that booting a computer without a keyboard was generally considered useless, so if it didn't detect one it made you plug it in and prove you had one.

Not sure why so many people don't understand why the error actually makes sense. You could also disable it in most BIOSes by at least the 486 era, and probably even some 386 ones, on the chance you had a machine you didn't need a keyboard attached to.

If we're talking the classic MS-DOS experience on a PC that most people mean when they're talking about DOS on PCs, there's more to it than just x86. It's also the whole legacy of "IBM PC Compatible" from the BIOS to the memory map to the way it interacts with peripherals and the applications it can run. After all, there were a handful of non-IBM PC Comptaible MS-DOS machines that, while they ran DOS, wouldn't run the same things.

Really there's two different use cases for something like FreeDOS - running legacy code and using it as a minimal environment for things like firmware flashers and such. There's nothing keeping FreeDOS from keeping up to date with the times and continuing to boot on the latest and greatest 64-bit only, EFI only machines and staying in its niche as a minimal OS for specialized/embedded use cases. On the other hand, running legacy code will need all that compatibility stuff to still be around - x86_64 CPUs that still support Real Mode, legacy BIOS compatibility modes, various memory map and interface setups that date back to the beginning, etc. FreeDOS updated to run on an entirely different x86_64 arch that doesn't actually run anything legacy is not really any different to, say, porting it to ARM or RISC-V or whatever since functionally it's basically completely different anyway. I would expect heavier-weight OSes to have compatibility layers and handlers within its HAL for most stuff, but for low level bare metal OSes like DOS that sort of defeats the purpose of a slim, direct OS like it's aiming to be.

They keyboard connector is physically the same, but the protocol is different. The original PC and XT used a different protocol than AT and later, which continues all the way up through today for machines that still have PS/2 keyboard ports.

You aren't incorrect, exactly, except that if you end up with (potentially important/critical) applications depending on quirks and bugs they can end up promoted to features, and then have to be maintained so as not to break said applications. And like Raymond Chen of Old New Thing has said a few times, if a new version of Windows breaks an application because the application misbehaves, the user is going to blame Microsoft for breaking their perfectly working application, not yell at the application vendor for some programming thing he doesn't understand. There's a lot of interesting stories of some of the hoops Microsoft has had to jump through to keep misbehaving games and apps running on newer versions of Windows specifically for that reason.

This is even more true if you're trying to develop a Windows clone or a compatibility layer - you're already on shaky ground, and trying to convince a potential user that it's actually their application's fault it won't run on WinClone XP For Workgroups 2.11 when it runs fine on every real version of Windows that they should go back to their application vendor and ask them to fix their application for some random Windows clone is going to be a non-starter. Even if by all rights it is a problem with how the application is behaving.

ReactOS already uses a lot of Wine code for certain aspects, but Wine is pretty heavily aimed at translating Windows API stuff to their Linux equivalents while ReactOS is aiming to reimplement the entire Windows NT kernel and services layer. There was a fork of ReactOS called Arwinss (linked from that page) that aimed to make it easier to use Wine code but that seems to have petered out over 10 years ago.

There were also some mostly-minor disagreements (which you can also get a bit of a taste of on that link) where Wine was more amenable to hacks and tricks to get applications working (especially major ones) whereas ReactOS was more focused on making sure things worked The Right Way since ReactOS is aiming to be feature for feature, bug for bug reimplementation of Windows vs. Wine being a compatibility layer where the main goal was getting things running whether they worked "right" behind the scenes or not.

Pretty much the same for me. It's a smart light and couple other things controller, occasionally weather, occasionally music (the speaker grouping has been pretty nice for, say, playing music all throughout the house). I hate trying to do any sort of shopping with it, there's a couple fun skills I occasionally play with like Question of the Day, but by and large I don't use or like any of the actual assistant features. It can be okay for quick, fairly easily answered queries but if I'm trying to search for something and need a cycle or four of query refinement, it's slow and annoying to constantly re-ask it. I used to use it for a shopping list, because I'm the kind of person that forgets what I need if I don't put it somewhere, but got out of the habit of that at some point.

I certainly don't need a conversational AI out of it. I have enough real people to talk to if I really want, I don't need to chat with a machine and I don't have any use cases a conversational AI would be any better than what it already does. I use it with Home Assistant as a smart home controller, and there are some third party/open source voice assistants that are probably good enough to cover my needs and use cases. Mainly a matter of hardware at this point - Between the handful of random Echo devices I collected myself for super cheap when they've blown them out at super low prices when new ones come out to a handful given to me by friends who don't need them, I have a pile of the things all over the house now. It'd be nice if they could be hacked/repurposed since by and large they're decent quality microphones and speakers and running Android. There's an XDA forum for them but nobody really seems to have gotten much past a couple bootloader unlocks and some ADB access on a couple of them.

Usually for me it's because I've gotten stuck somewhere late, it's 9:45PM, I'm starving, and all I want to do is get home. All the mom-and-pop places are long closed, the slightly better chain places might still be open but would take a lot longer to get food and would probably be more expensive, and I don't really want to go home and cook something.

Fast food ain't great but you know what you're getting and it's usually pretty fast. Maybe in some places there's better places open late but around here there really isn't.