This has been the case on approximately all platforms for many decades. Such a micro-VM is called a process.

I think this here is the big one. We have largely stopped making software that tries to help the user do what they want to do, and instead have started making software that tries to guide the user into doing what WE want them to do. This has gotten nearly omnipresent in both the web, and commercial software development.

When you are writing software that aims to guide the user into doing what you want, actively against their wishes, and that tries to discourage them from doing what you don't want them to do, then having a good user interface is something you actively want to avoid. This is why most of the remaining good UI in 2021 is found in the free software world, and even there it's a minority.

That is true, but that can not usually be fixed with a larger sample size. If your experiment's testing procedure is bunk, then increasing the sample size is not going to help one bit. Only very, very rarely can a poorly designed experiment be saved by throwing more samples at it.

There are ten thousand different ways to get misleading results out of a poorly designed experiment. One of those ways is interpreting noise in your data as a meaningful signal, where by the barest chance you get a bunch of data points that are all weird outliers by sheer luck.

The other nine thousand nine hundred and ninety-nine ways involve introducing bias into your data -- your experimental procedure is such that you systematically are measuring the wrong thing. Perhaps your experimental subject selection procedure is such that it tends to disproportionately select the weird outliers, or perhaps the phrasing of your questions causes people to answer a different question than the one you were aiming for. This is the broad category is mistakes that social science experiments are particularly vulnerable to.

Choosing a large sample size, and other statistical methods, help avoid the error where you are measuring noise and interpreting it as a useful signal. It does not do anything whatsoever to deal with bias problems. If your experiment falls prey to one of the nine thousand nine hundred and ninety-nine mistakes where it's measuring a biased signal, then making sure you have a large number of samples will not help in the slightest. Performing your experiment with a million subjects will prove oh so definitely that you are not looking at noise -- you have measured something, all right. But that something could either be a genuine result, or the consequence of bias in your data, and to tell the difference you'll have to examine your experimental procedure in a way that has nothing to do with statistics or sample sizes.

Large sample sizes are a remedy against one specific way to ruin your experiment, out of ten thousand gotchas to watch for. It doesn't mean your procedure is sound, only that it's one mistake you didn't make. And conversely, it's not a silver bullet to avoid the other nine thousand nine hundred and ninety-nine problems either -- if your sample size is large enough to avoid the noise-based problems, then making it even larger will not help with the other gotchas.

I don't think this follows at all.

Posting to cancel mistaken moderation.

I hate to break it to you, but trying to extort the customer for maintenance IS bad intent towards them.

Of course not. When every yahoo on my segment fires up bittorrent, everyone's available bandwidth gets limited to the total available bandwidth divided by the number of people. As long as I am using less bandwidth than that number, my traffic outprioritizes any and all data by users that exceed it. No content-based prioritization required.

As a service, you may prioritize MY voip traffic against MY torrents. But under no circumstances can there be tradeoffs between MY torrents and YOUR voip traffic -- that tradeoff is based on your and my traffic in general, without caring about the type.

I was talking about the more general case of locked-down phones, smart TVs, bluray players, and cars. I think that's currently legal in most of the world, but it shouldn't be.

Damn right I do.

And it's HIGH time this became very illegal.

If Google truly believed this, three quarters of the Android base operating systems would be individually installable and removable packages.

Is it? I'm not sure I agree.

If my connection is saturated while I am using both VOIP and FTP, it is entirely acceptable to me that my ISP prioritizes my VOIP traffic over my FTP traffic.

If my ISP's total uplink connection is saturated (whether or not this should happen is another discussion), it is entirely acceptable to me that the ISP throttles its users that are currently using the highest amounts of bandwidth. Ideally, they throttle every user using more than X amounts of bandwidth down to X, where X is the highest number that they can sustain; and not do anything for all the users using less than X. This done without looking at the type of traffic of the different users, only the total bandwidth use. Of course, within the scope of a given user's such-throttled bandwidth, that's user's VOIP traffic may be prioritized over that user's FTP traffic, per the above clause.

But it is not acceptable to me if your VOIP traffic is prioritized over my FTP traffic independent of our total bandwidth usages. If I am trying to use 100 Mbit/s of FTP and you are trying to use 100 Mbit/s of VOIP and the ISP can only sustain 120 Mbit/s total, then it can throttle us both down to 60 Mbit/s, but it must not throttle me down to 20 Mbit/s instead because VOIP outprioritizes FTP. And when I am trying to use 50 Mbit/s with my FTP and you are trying to use 100 Mbit/s with your VOIP, then you go down to 70 Mbit/s, while my bandwidth stays intact.

Then I highly doubt they calculated all legal positions in the game. They probably calculated all legal positions of the board, but that's a different thing.

The number of possible positions of the board is upper-bounded by 3^(19^2), with 19^2 positions that each can hold a black stone, a white stone, or no stone at all. This exact number was probably computed by this research.

But the possible positions of the game include not just the current board position, but also the set of all previous board positions; after all, the same board position can admit different future games, and be won by different players, depending on the previously-seen board positions. Thus, the possible positions of the game is vastly huger than the number of possible positions of the board, upper bounded by 2^(3^(19^2)).

The exact same consideration applies on desktop windows, and microsoft doesn't give a crap about such complaints in that area. Why would they feel differently for WinIoT?

What you can't get away from entirely, you may still wish to minimize.

I don't think anyone will dispute the claim that (for instance) platform independence is an important sysvinit feature that systemd has sacrificed, and that (say) being a single point of failure for dozens of mostly-independent subsystems is a significant architectural downside of systemd. I make no claims as to the relative importance most people attach to those downsides versus the real upsides of systemd, but downsides they be.

This is very true. Most people will also agree that it accomplishes this at the cost of significant downsides inherent to the design of systemd, and sacrificing important features that the old alternatives do offer. The controversy is about whether the upsides are worth the downsides.

Depending on your position regarding the aforementioned tradeoff.