duncesplayed

Not all of these issues have disappeared, either. Anyone remember this headline from a couple years ago? The bottom 1MiB of memory space on x86 is just a minefield. It's impossible (like literally impossible) in general to know if certain parts of the address space are actual memory or are some weird part of your motherboard chipset or some other hardware. Windows I think still goes through the "wankery" of depending on chipset drivers to (accurately) know which parts of memory are actual memory.

Thankfully the 16-bit (though actually 20-bit but actually kind of more sometimes kind of but not totally) pains have all gone away. The move to flat 32-bit address spaces was a godsend.

RIP Bette Stephenson. In the same way that Al Gore invented the Internet, Bette Stephenson invented the ICON. She was a very stubborn politician who would not tolerate anything other than complete success from the project. Passed away 3 years ago.

I always coveted the Tandy 1000, but I never got one. Which one did you have?

The #1 defining moment for me has to be Second Reality by Future Crew. We got it an a local BBS not too long after it was released. It was kind of like the birth of a new era, like "ahh so this is what PCs are actually capable of".

these games are guaranteed to not have any in-app purchases or ads

That's a big plus. I also like that they have to use the keyboard, since the mouse can be a bit tricky when you're young.

I had no idea there was a Richard Scarry game! They love the books, so maybe I should give it a shot. (Though it does look pretty mouse-heavy)

Another Oregan Trail generation here.

I'm curious about what's going to happen with Gen Alpha. Any other moms and dads here exposing their kids to retrotech? I have two little ones that I've made a DOSBox installation for (Mixed-Up Mother Goose and Donald Duck's Playground are their favourites). I do wonder how they're going to think about old tech when they're older. I haven't told them that it's "old" or "retro" yet, so they just think they're normal fun games.

It's a bit more complicated than that. Windows 95 used MSDOS to boot, but once it was booted, it completely removed any trace of MSDOS and replaced it with its own MSDOS subsystem. It's more like MSDOS was a shell on top of Win95, but MSDOS was required to get the kernel loaded.

Yes, which is literally what OP is asking about. They mention system calls, and are asking, if a userland program can do dangerous thing using system calls, why is there a divide between user and kernel. "Because the kernel can then check permissions of the system call" is a great answer, but "hopefully you can't harm your computer with userland programs" is completely wrong and misguided.

dd if=/dev/zero of=/dev/sda is a userland program, which I would say causes harm.

It's come up in interesting cases. I can't remember which package it was, but there was one package that was distributed under the humourous "Don't Be Evil License", where you could "use this software for anything that's not evil" or something like that. This technically does not qualify as free software (freedom 0 must allow anyone to use it for evil), so Red Hat (I think it was?) had to get their lawyers to contact the developer and get him to give them an exemption to the licence, just in case one of their users used it for evil.

Indeed. Licensing usage of something is antithetical to free software culture anyway. It would violate the Free Software Foundation's Freedom Zero, that you should never have to accept a licence to use something. (This is why free software cannot ever have a EULA, for instance)

It's a bit more complicated than that. System load is a count of how many processes are in an R state (either "R"unning or "R"eady). If a process does disk I/O or accesses the network, that is not counted towards load, because as soon as it makes a system call, it's now in an S (or D) state instead of an R state.

But disk I/O does affect it, which makes it a bit tricky. You mentioned swapping. Swapping's partner in crime, memory-mapped files, also contribute. In both of those cases, a process tries to access memory (without making a system call) that the kernel needs to do work to resolve, so the process stays in an R state.

I can't think of a common situation where network activity could contribute to load, though. If your swap device is mounted over NFS maybe?

Anyway, generally load is measuring CPU usage, but if you have high disk usage elsewhere (which is not counted directly) and are under high memory pressure, that can contribute to load. If you're seeing a high load with low CPU utilization, that's almost always due to high memory pressure, which can cause both swapping and filesystem cache drops.