Slashdot Mirror
Lost Opportunity? Windows 10 Has the Same Minimum PC Requirements As Vista
MojoKid writes Buried in the details of Microsoft's technical preview for Windows 10 is a bit of a footnote concerning the operating system's requirements. Windows 10 will have exactly the same requirements as Windows 8.1, which had the same requirements as Windows 8, which stuck to Windows 7 specs, which was the same as Windows Vista. At this point, it's something we take for granted with future Windows release. As the years roll by, you can't help wondering what we're actually giving up in exchange for holding the minimum system spec at a single-core 1GHz, 32-bit chip with just 1GB of RAM. The average smartphone is more powerful than this these days. For decades, the standard argument has been that Microsoft had to continue supporting ancient operating systems and old configurations, ignoring the fact that the company did its most cutting-edge work when it was willing to kill off its previous products in fairly short order. what would Windows look like if Microsoft at least mandated a dual-core product? What if DX10 — a feature set that virtually every video card today supports, according to Valve's Steam Hardware Survey, became the minimum standard, at least on the x86 side of the equation? How much better might the final product be if Microsoft put less effort into validating ancient hardware and kicked those specs upwards, just a notch or two? If Microsoft did raise the specs a notch or two with each release, I think there'd be some justified complaints about failing to leave well enough alone, at least on the low end.
Before we go any further, I think it'd be good to provide an example of what feature you believe Microsoft has failed to implement in order to keep the requirements low. I can't think of what that would be. Because failing the need to meet some specific requirement, I don't know why system requirements should need to keep going up, especially when you consider that we use our desktop/laptop computers for the same things as we did 10 years ago. Web browsing, word processing, spreadsheets. For games, you can support weaker/older systems and just scale the graphics down.
So unless there's a specific feature that would suck up resources, I'd actually kind of expect that an OS system requirements might go down. As code continues to be optimized, you'd get better performance on the same hardware. Of course, there's a limit to that. But why complain that the OS isn't an ever-bloating resource hog?
Well, you can't compare hz between differnt families of chips just like you can't compare RPM between a motorcycle and dump truck to definitely talk about power output.... but it definitely means a lot.
If they could crank CPUs up to 100 Ghz or 1 teraherz, they would because it's easy gains. In F1 race cars they use plastic pistons just to be able to rev it over 18,000 rpm (more than a standard motorcycle).
That's why overclocking still exists. Hz won't mean anything if they ever manage to pull of clockless chips. Considering how much circuitry/transistors are dedicated to timing in a modern CPU, that would be a huge gain. But AFAIK, it's still a pipedream.
I completely agree most people haven't needed a faster CPU in years, unless they're in the hard-core gamer category or doing serious computational work.
Memory, on the other hand, is something you've steadily needed more of over time.
Me, I'm betting with 1GB of RAM on a modern Windows version, and you'll already be using swap space before it's even done booting.
And then it's going to just be slow from there.
With "Outlook, Work, and a browser", it's going to be thrashing like mad.
Really, "able to run on a wide range of hardware, including older slower machines" means, yes, you can, it doesn't mean you'll like it or that it's a good idea.
Hell, our household machine with 4GB of RAM and XP Pro doesn't feel like it's got enough memory.
Lost at C:>. Found at C.
I've been saying this for years. All the idiots decrying "PC's are dead! Tablets are replacing them!". No, tablets aren't replacing PCs. Most people just have a PC that's fast enough for their needs and don't need to buy a new one because it's "slow". As a gamer, and a "geek", I have a box that's probably pushing 5 years old, and outside of adding an SSD, there's been no need to upgrade anything. I could probably stand to grab a new video card (gtx460's in SLI), but outside of that, it's fast enough for everything I do.
OS-X has penetrated into the market for highly sophisticated technical and scientific users forr easons which have nothing to do with security, but rather because such end users generally have their own choice of machines and often prefer OS-X for the reasons you listed.
Of course, in my own experience, getting open-source UNIX scientific software to work correctly on OS-X is often just as difficult as getting it to work under Windows with a UNIX emulator and SSHing into or virtualizing a Linux machine is my preferred solution, at least for a desktop computer.
More obscure programs not in standard Linux repositories tend to be equally painful to get set up on Cygwin, Linux, and OS-X, although at least commercial software like Matlab and Mathematica are much more easily set up on Windows or OS-X than Linux.
We have electrochemistry kit that is chugging along on a PC running Dos 6.2 and Win 3.11.
Getting your data off requires a floppy disk as an intermediate step. I have no idea what we'll do if that machine ever craps out - it would be a shame to have to retire the potentiostat because the computers that it was designed to talk to have effectively ascended to godhood in the meantime.
It's certainly not the only piece of analytical kit that is tied to legacy hardware. We have a couple of FTIR machines that look like props from Fallout: New Vegas but work just fine and I'm pretty sure the EPR computer is running Win95.
Overall, 64 bit has a 20% [or better] performance increase for most workloads. There are other factors other than just size of pointers.
Size of pointers is not the major factor in cache flush since most of the cache is taken up by data items and not pointers. These data items are more or less invariant across compilation mode.
64 bit compilers only use 64 bit fetch for non-pointers if you actually request them (e.g. long long). MS is the odd ball and defines a "long" to be 32 bits even in 64 bit mode [contrary to the compilation models used by everyone else]. "int" suffices for most data. Where it doesn't, one will [have to] code "long long" and that is invariant across 32/64, except that the 32 bit code will be slower [generating 2-3 instructions for each 64 bit one].
With x86_64, the first 6 arguments to a function are passed in registers and not on the stack (i.e. no wasteful push/pops for argument passing on entry/exit).
For a function that has a lot of automatic [stack] variables, in 32 bit, any non-trivial loop could spend a lot of time dumping a register to its stack frame solely for the purpose of making room for another variable that needs the register. This is register pressure and is considerably higher in 32 bit mode.
Once an address has been loaded in a register, access relative to that base register is identical speedwise between 64 and 32 bit.
64 bit has RIP-relative addressing which allows data to be addressed as small offset from the RIP [instruction pointer/program counter] register. Since it's relative to the RIP, two consecutive instructions that address the same data location will have slightly different offsets within each instruction.
You want a study? Try a google search on "performance 32 bit vs 64 bit".
Or, the easy reader version:
http://www.phoronix.com/scan.p...
Like a good neighbor, fsck is there