I don't know why I'm replying to an AC who couldnt' tell the difference between an ACL and a hole in the ground, but... yeah.
First of all, POSIX permissions also includes setuid, setgid, and sticky. Just FYI.
Second, admins most certainly do bother with the more fine-grained permissions that NT allows. Any large business or sensitive data storage (with a competent admin) will make extensive use of ACLs. It's true that Deny ACEs are relatively rarely used, but they do exist, and are sometimes the most expedient solution to a situation. Technically you can deconstruct most (though not all) of NT ACLs into POSIX permissions - it just requires potentially ludicrous numbers of groups - but it's a lot easier to do that kind of control on NT.
Third, DOS had absolutely no permissions system at all; it didn't even have the concept of a user. Readonly, System, Hidden, and Archive are flags, not ACEs; they provided absolutely no actual security and weren't designed to. They were intended to inform users and prevent accidents, and they achieved nothing more. I have no clue why you'd bring up DOS unless you're either trolling or so computer-illiterate you hold the mouse with the "tail" toward you, though; all versions of Windows from the last twelve years have been NT based, not DOS based.
Because they have no way of knowing whether you're doing dev or not? I mean, there are two obvious legit reasons - development / testing and corporate or other internal apps - but how is MS going to tell the difference between you using it for those and you using it for "homebrew" apps that aren't on the store for whatever reason?
It's not like you have to go fill out some big contract to get this. It's a freaking powershell command! Unless they're doing some seriously deep monitoring, MS can't really stop you from using it for whatever you want.
Non-"retina" iPads have lower resolution than Surface, though. Yes, for $100 less, you can get generaton's model with half the storage, lower resolution, and still no peripherals. That's a *great* deal!!
Surface (and Windows 8 in general) is about as "free" as Android when it comes to apps. The process of unlocking Win8 for sideloading consists of "type a command into Powershell" (which is included with Windows RT, incidentally). After that you can grab all the.APPX files you want, from the web or from an alternate store or whatever, and install them. Additionally, unlike on prety much any commercial Android distribution, the ability to "get root" (run as Administrator) on Surface is built-in, just as it is on other Windows devices.
I'll grant you that Surface is quite a bit more than the cheap-end Android tablets, but the handful of 10" Android tablets that exist and have even vaguely similar specs are about the same price (most are a bit cheaper, but nowhere near $200). Don't assume that all tablet hardware is anywhere close to equal.
The 32GB Surface is the same price as the 16GB iPad. The 32GB Surface with keyboard/touchpad/cover is the same price as the 32GB iPad without any such accessory. The 64GB Surface with keyboard/touchpad/cover is the same price as the 64GB iPad without accessories. Additionally, Surface comes with Office. It doesn't *look* cheaper than the iPad, but the 32GB iPad, without accessories, is $100 more than the 32GB Surface without accessories.
Win8 apps don't have to be written in C# (native C/C++, Javascript, and any other.NET language are also supported). Most apps do need to have their UIs re-written to port them to "Windows 8" (Metro) style, but the program logic can remain in another language with just a recompile to ARM if needed. I grant that the number of apps which have been so transformed is small-ish thus far, but it's growing quite rapidly (download the x86 version of Win8 and take a look if you want).
Surface does support Windows networking natively, of course. The email client has excellent Exchange support. The RT (ARM) version doesn't support domain-joining, but the "Pro" version (64-bit Intel) does.
Only true for third-party apps. First-party software, such as Explorer, IE, Powershell, etc. are all Win32 apps and are included on Windows RT (and therefore Surface RT). Some native APIs, such as DirectX, are also supported for third-party apps on Windows RT.
Given that the GP started out talking about XP (an OS, not a hardware platform), I'm guessing the complaint is that Xcode 4.5 won't run on a two-year-old version of OS X.
I'll grant that OS X upgrades tend to be quite cheap, but they have atrocious forward compatibility; you *have* to upgrade to keep running modern software.
NetBSD is the "runs on any/everything" variant. It's absurdly portable. If you've heard stories / jokes about "BSD on a toaster", it was probably NetBSD.
It's not necessarily a great desktop system; "runs on everything" doesn't mean all internal or peripheral software support is going to be great (desktop-oriented BSD distros are usually FreeBSD based). However, it's a great choice if you have a very old or obscure computer that you want to run it on. I know a guy who runs NetBSD on one of the later-model VAXes.
The Office preview is quite usable (I've been running the x86 version, at least, and it's fine) and the full version will be released as a free update for Windows RT devices (including Surface).
Do you actually have any idea how many apps are available? It's not nearly so many as iPad, yet, but it's non-trivial and growing very quickly. You can see this yourself on Win8 (filter out "Desktop app" entries, since those won't run on Windows RT). Calling Office (which is actually a collection of apps) "one of the few applications even available" implies the existence of far fewer Win8/WinRT apps than actually exist, and the OS isn't even officially out yet.
The qoute from Reddit (that you are using as the basis for your "12 GB" comment) asked about OS plus Office plus apps. Now, I don't know how many apps the responder was suggesting would be included in that number, or how big they'd be, but it was much mor ethan just the OS, or even OS + Office (which can, I suppose, be considered part of the "Full OS" for Windows RT).
It's higher res than the previous iPads, which plenty of people use as e-readers. I doubt that's going to be a problem. It also has an extremely low-reflectivity screen, which results in better contrast and a clearer image when viewed with ambient light than you get from the iPad.
It's going to be hard for Valve to mitigate; most of the bugs found are in games that Valve doesn't develop, often even games that don't run Valve's game engine. Don't let the shit-heap of a summary fool you; there are ton of attacks you can do if you can pass artbitrary parameters to games. The whole "script in the startup folder" thing is *one* way that you could do this attack using *one* game engine (which happens to have been developed by Valve). The researchers list a bunch of other exploits too, ranging from memory corruption bugs to games which will install update packages from arbitrary locations specified on the command line. Game developers are, by and large, *terrible* at security.
It's actually quite simple in this case, though: you can specify, on the command line, a log file (with full path and extension). Then, you can specify "echo" commands which will be written to the log file. These lines will appear at the top of the log, before any of the game's usual log spew. So yes, you can guarantee that the lines for "download this arbitrary executable and run it" appear at the top of the batch script.
If you want to, you can even then put an exit instruction in the script, so the user doesn't even see the script window full of game spew. Of course, by that time they'd already be owned anyhow...
IE7+, when running in its sandbox ("Protected Mode"), will pop up a second warning message when clicking a link that invokes an external program. It doesn't really tell you anything that the first message didn't, except that the program will execute outside of the Protected Mode sandbox, but it's another chance to realize something is wrong and cancel it.
The summary is wrong/stupid. Not only is it poorly worded, it also adds BS like the line you quoted.
The researchers found an exploit in Steam itself. Specificlaly, in the image decoder used to show the game logo during game installation. Since steam:// URIs can be used to tell Steam to install a game from a "local" download, but allows specifying arbitrary UNC paths (which can specify Internet addresses), you can set up a server that hosts a corrupted image file and post steam:// links that use your server as an install location. No need to wonder about games the target may have installed...
For extra fun, which somehow didn't make it into the (atrociously bad) summary, those Install links can be used for exploits themselves. It turns out that there's a memory corruption bug in Steam (integer overflow on a malloc call), specifically in the.TGA image decoder. Steam URIs can be used to install a game from a "local cache" which can be at an arbitrary UNC path, including over the Internet (\\spoitserver.com\steam\steamexploit.tga) if the target server has Windows networking open to Internet traffic and set to permit anonymous access (neither is default, but you can configure it like that).
So no, you really don't have to know of a game that the victim has installed, and unless you want to break a *ton* of Steam functionality, disabling the steam:// URI scheme isn't a very good work-around.
I did semi-volunteer tech support for my university dorm floor. Every single instance of malware somebody came to me for help cleaning - and there was one at least once per month, on a floor of 70 guys - came from pirated software (typically Photoshop, not games, but sometimes games too). Some were from the outside Internet, some were from the DC++ system that everybody on campus seemed to be using, but they were pervasive.
One of the miggest examples of in-the-wild OS X malware was a trojan in pirate copies of iWork that would add the machines into a botnet.
Malware in pirated software isn't just a hypothetical; it's something that is very, very common. There are, I'm sure, groups who have a good reputation for removing DRM and not inserting their own money-maker (which is what malware is these days; it's all about money) but I'm sure there are also people who take that "clean" code, inject malware, and then re-distribute it. Undeniably, the malware gets into those game installers somehow!
More to the point, while the GP may not have bothered to set up the steam:// URI association in the host Linux system, within the Wine environment it will be working. Now, granted, most people who use Wine for gaming probably aren't also using it for something like running IE4Linux, but if you *were* to do that, you would (potentially) be vulnerable.
Admittedly, the risk is pretty damn minimal in that environment.
I get that you're going for a joke, but the sad thing is, this really shouldn't cost anything at all. Assuming the police are using a volume-licensed edition of either Win7 (sadly, it's quite possible that they're still on XP but I would truly hope not), they can use Bitlocker To Go, which is full-volume encryption for removable storage. It's typically protected with a passphrase (though you can use any of a number of things, including multi-factor auth with smartcards and the like as well) and utilizes very strong encryption. Aside from a few minutes to enable the encryption, and needing to enter the passwords when the drives are mounted, there's no extra cost. It's read-only on XP (since XP doesn't natively support Bitlocker) but otherwise, it's just about perfect for this situation.
There's also Truecrypt and GPG or some other PGP/openpgp implementation. Not as user-friendly as BL2Go, perhaps, but no requirements of OS version. That's just staying within the bounds of free (gratis) software; there are of course more options if they want to spend some cash. Hell, even using encrypted ZIP files would be an improvement...
Err what? The game *starts* in 2100 (the Unity launches in 2060 and spends 40 years in transit). You may be thinking of one of the earlier Civ games. Alpha Centauri, depending on difficulty level, ends (you reach "mandatory retirement age") on 2300, 2400, or 2500. Each turn is one year, unlike typical Civ games.
As a side note, MS definitely does care about gamers on Win8; they expressly allow native apps and graphics APIs (they encourage DirectX, of course) int he Win8 store. I'm not a fan of the content restrictions, to be sure, but you could just host those apps on a third-party site and have peopel sideload them (yes, sideloading is totally possible on Win8 / Windows RT).
Point #1: You just described AppArmor or SELinux. These already exist. They're a pain to configure, but they do what you want.
Point #2: This is, in fact, one of the things that "Metro-style" apps do. It's not just a "touch-first" UI; it's also a per-app sandbox with restrictions on the locations and access that each app has, independent of other apps or of the permissions of the logged-in user.
NT permissions are actually much more fine-grained than POSIX; you can for example permit all logged-in users to read, and all users of a specific group to write as well, but deny one specific user (who might even be a member of the aforementioned group) the right to do anything at all with the file. Write, append, and delete are different permissions. The same permission can be applied to multiple users and/or groups. The owner of a file (or other securable object; in POSIX these would all be files so I might as well call them that) can overwrite any permissions, as you'd expect, and the Administrator ("root") can take ownership of any file, but it's also possible to allow multiple users/groups the ability to take ownership of files. By default, directories use inherited permissions, but it's possible to add additional permissions (or to deny permissions, which overrides "allow" behavior), and it's possible to disable permission inheritance on a directory or file entirely.
Erm, the registry ha sa number of advantages over text config files (.INI or any other kind).
It's centralized. You don't have to search the whole disk, just the registry itself, which is pretty fast.
It's strongly typed. Strings are strings, integers are integers (well, DWORDs), and while arbitrary binary data is permitted, it's not the default.
It's compact. Text files are wasteful of space in several ways (representing numbers as unicode characters, filesystem entries, etc.).
It's hierarchical. A registry key can both contain values and sub-keys. Text config files are flat; unless you use the filesystem itself to provide hierarchy (which then means you have a large number of files potentially per application) you either end up with a long and structureless list, or with a structured file that a slight mistake in editing can break.
It's a standard format..INI is only one way to store config data; there's other forms of flat files, plus XML and so on. With the registry, you don't have to worry about whether the file needs to have a specific type of newline character or what the character to separate value names from data should be or anything like that.
It's fast. Because registry values are stored with known types and lengths, parsing them is faster than parsing numbers, hex values, etc. out of text files. Back when the registry was first designed (when the 386 was a new and fancy CPU), this mattered more than it does today, but it's still a valid technical point in the registry's favor.
To be sure, the registry has its issues, too. It's definitely less visible than text files are (although settings files are typically marked Hidden...), and it's slightly harder to back up. It also is much harder to find software for general-purpose registry editing than for general-purpose text file editing. Don't pretend that there is no point to the registry, though.
If those are walls, the gate is awfully big and easy to open. Win8 permits sideloading, and doesn't charge for it. Enabling it requires Powershell (oh the horror, a command line!!!!) but is quick and trivial to do.
Sideloading is permitted on Win8 as well, though. You don't even have to pay for it. The option is less public than on Android - it requires either having Visual Studio installed or using the command line (Powershell, sepcifically), but it's there, it's free, and the info isn't hard to find if you do a search for it.
Although you are almost correct in concept (legacy software won't run), you're almost entirely incorrect in details. I expect better on/. (at least around technology) and therefore I shall somewhat pedantically correct you.
First of all, Windows RT runs on the NT 6.2 kernel, same as Windows 8. Let's just get that out of the way. It's no more a "special version" much less "new operating system" of NT than the x64 or Itanium (or, going a bit back in history, MIPS, PPC, or Alpha) builds were... aside from the requirement that.exe files have Microsoft's signature. None of those historical NT ports could run "existing Windows applications" either, but they were still Windows.
Second, all of the standard Microsoft desktop components - which use the same APIs as third-party code, BTW - run just fine. Windows RT mandates Microsoft signatures for desktop apps, but assuming a third-party app could obtain such a signature (and was compiled for ARM), it would run. This is not some cloned OS that looks like Windows but is different underneath; aside from the instruction set, the same libraries are present on both.
Third, you say it "shares some of the original code base" but I doubt you can point to any binary that is on Win 8 (not Pro, just standard Win8) but not on Windows RT. As it happens, there are a few, but I doubt you can identify them. It *is* the same code-base, aside from the small (though certainly high-impact) change to the program loader.
Fourth, it comes with CMD, Powershell, and Windows Script Host, so scripts from older versions of Windows will run equally well on Win8 and Windows RT, provided they don't call into third-party software. Given how powerful Powershell scripting is, and the fact that you can create and use COM objects, this is actually a way to port entire apps to Win8 provided that they only use managed code (without requiring additions to the GAC, although I haven't actually confirmed that doing so is impossible) or built-in native COM objects.
Fifth, Windows RT can install third-party apps by sideloading (not be default, but you can unlock it), as well as from the store. "Metro-style" apps can be written in C++ and access the standard Win32 libraries just fine; your app may not be accepted into the store at that point, though. However, you can post the.appx package online for others to download if you want to. The unlock for sideloading is free and already available publicly from Microsoft.
Sixth, we have no actual info on the cost of Surface Pro yet. It could be "nearly a thousand bucks" as you claim - in fact, I'd say that's a decent guess - but that's only a guess. It could also be $700, or $1500. Even I don't know, and in case you couldn't tell, I've been following leaks and details of Surface fairly closely.
Slashdot Mirror
I don't know why I'm replying to an AC who couldnt' tell the difference between an ACL and a hole in the ground, but... yeah.
First of all, POSIX permissions also includes setuid, setgid, and sticky. Just FYI.
Second, admins most certainly do bother with the more fine-grained permissions that NT allows. Any large business or sensitive data storage (with a competent admin) will make extensive use of ACLs. It's true that Deny ACEs are relatively rarely used, but they do exist, and are sometimes the most expedient solution to a situation. Technically you can deconstruct most (though not all) of NT ACLs into POSIX permissions - it just requires potentially ludicrous numbers of groups - but it's a lot easier to do that kind of control on NT.
Third, DOS had absolutely no permissions system at all; it didn't even have the concept of a user. Readonly, System, Hidden, and Archive are flags, not ACEs; they provided absolutely no actual security and weren't designed to. They were intended to inform users and prevent accidents, and they achieved nothing more. I have no clue why you'd bring up DOS unless you're either trolling or so computer-illiterate you hold the mouse with the "tail" toward you, though; all versions of Windows from the last twelve years have been NT based, not DOS based.
Because they have no way of knowing whether you're doing dev or not? I mean, there are two obvious legit reasons - development / testing and corporate or other internal apps - but how is MS going to tell the difference between you using it for those and you using it for "homebrew" apps that aren't on the store for whatever reason?
It's not like you have to go fill out some big contract to get this. It's a freaking powershell command! Unless they're doing some seriously deep monitoring, MS can't really stop you from using it for whatever you want.
Non-"retina" iPads have lower resolution than Surface, though. Yes, for $100 less, you can get generaton's model with half the storage, lower resolution, and still no peripherals. That's a *great* deal!!
Surface (and Windows 8 in general) is about as "free" as Android when it comes to apps. The process of unlocking Win8 for sideloading consists of "type a command into Powershell" (which is included with Windows RT, incidentally). After that you can grab all the .APPX files you want, from the web or from an alternate store or whatever, and install them. Additionally, unlike on prety much any commercial Android distribution, the ability to "get root" (run as Administrator) on Surface is built-in, just as it is on other Windows devices.
I'll grant you that Surface is quite a bit more than the cheap-end Android tablets, but the handful of 10" Android tablets that exist and have even vaguely similar specs are about the same price (most are a bit cheaper, but nowhere near $200). Don't assume that all tablet hardware is anywhere close to equal.
The 32GB Surface is the same price as the 16GB iPad. The 32GB Surface with keyboard/touchpad/cover is the same price as the 32GB iPad without any such accessory. The 64GB Surface with keyboard/touchpad/cover is the same price as the 64GB iPad without accessories. Additionally, Surface comes with Office. It doesn't *look* cheaper than the iPad, but the 32GB iPad, without accessories, is $100 more than the 32GB Surface without accessories.
Win8 apps don't have to be written in C# (native C/C++, Javascript, and any other .NET language are also supported). Most apps do need to have their UIs re-written to port them to "Windows 8" (Metro) style, but the program logic can remain in another language with just a recompile to ARM if needed. I grant that the number of apps which have been so transformed is small-ish thus far, but it's growing quite rapidly (download the x86 version of Win8 and take a look if you want).
Surface does support Windows networking natively, of course. The email client has excellent Exchange support. The RT (ARM) version doesn't support domain-joining, but the "Pro" version (64-bit Intel) does.
Only true for third-party apps. First-party software, such as Explorer, IE, Powershell, etc. are all Win32 apps and are included on Windows RT (and therefore Surface RT). Some native APIs, such as DirectX, are also supported for third-party apps on Windows RT.
Given that the GP started out talking about XP (an OS, not a hardware platform), I'm guessing the complaint is that Xcode 4.5 won't run on a two-year-old version of OS X.
I'll grant that OS X upgrades tend to be quite cheap, but they have atrocious forward compatibility; you *have* to upgrade to keep running modern software.
NetBSD is the "runs on any/everything" variant. It's absurdly portable. If you've heard stories / jokes about "BSD on a toaster", it was probably NetBSD.
It's not necessarily a great desktop system; "runs on everything" doesn't mean all internal or peripheral software support is going to be great (desktop-oriented BSD distros are usually FreeBSD based). However, it's a great choice if you have a very old or obscure computer that you want to run it on. I know a guy who runs NetBSD on one of the later-model VAXes.
The Office preview is quite usable (I've been running the x86 version, at least, and it's fine) and the full version will be released as a free update for Windows RT devices (including Surface).
Do you actually have any idea how many apps are available? It's not nearly so many as iPad, yet, but it's non-trivial and growing very quickly. You can see this yourself on Win8 (filter out "Desktop app" entries, since those won't run on Windows RT). Calling Office (which is actually a collection of apps) "one of the few applications even available" implies the existence of far fewer Win8/WinRT apps than actually exist, and the OS isn't even officially out yet.
The qoute from Reddit (that you are using as the basis for your "12 GB" comment) asked about OS plus Office plus apps. Now, I don't know how many apps the responder was suggesting would be included in that number, or how big they'd be, but it was much mor ethan just the OS, or even OS + Office (which can, I suppose, be considered part of the "Full OS" for Windows RT).
It's higher res than the previous iPads, which plenty of people use as e-readers. I doubt that's going to be a problem. It also has an extremely low-reflectivity screen, which results in better contrast and a clearer image when viewed with ambient light than you get from the iPad.
It's going to be hard for Valve to mitigate; most of the bugs found are in games that Valve doesn't develop, often even games that don't run Valve's game engine. Don't let the shit-heap of a summary fool you; there are ton of attacks you can do if you can pass artbitrary parameters to games. The whole "script in the startup folder" thing is *one* way that you could do this attack using *one* game engine (which happens to have been developed by Valve). The researchers list a bunch of other exploits too, ranging from memory corruption bugs to games which will install update packages from arbitrary locations specified on the command line. Game developers are, by and large, *terrible* at security.
It's actually quite simple in this case, though: you can specify, on the command line, a log file (with full path and extension). Then, you can specify "echo" commands which will be written to the log file. These lines will appear at the top of the log, before any of the game's usual log spew. So yes, you can guarantee that the lines for "download this arbitrary executable and run it" appear at the top of the batch script.
If you want to, you can even then put an exit instruction in the script, so the user doesn't even see the script window full of game spew. Of course, by that time they'd already be owned anyhow...
IE7+, when running in its sandbox ("Protected Mode"), will pop up a second warning message when clicking a link that invokes an external program. It doesn't really tell you anything that the first message didn't, except that the program will execute outside of the Protected Mode sandbox, but it's another chance to realize something is wrong and cancel it.
The summary is wrong/stupid. Not only is it poorly worded, it also adds BS like the line you quoted.
The researchers found an exploit in Steam itself. Specificlaly, in the image decoder used to show the game logo during game installation. Since steam:// URIs can be used to tell Steam to install a game from a "local" download, but allows specifying arbitrary UNC paths (which can specify Internet addresses), you can set up a server that hosts a corrupted image file and post steam:// links that use your server as an install location. No need to wonder about games the target may have installed...
For extra fun, which somehow didn't make it into the (atrociously bad) summary, those Install links can be used for exploits themselves. It turns out that there's a memory corruption bug in Steam (integer overflow on a malloc call), specifically in the .TGA image decoder. Steam URIs can be used to install a game from a "local cache" which can be at an arbitrary UNC path, including over the Internet (\\spoitserver.com\steam\steamexploit.tga) if the target server has Windows networking open to Internet traffic and set to permit anonymous access (neither is default, but you can configure it like that).
So no, you really don't have to know of a game that the victim has installed, and unless you want to break a *ton* of Steam functionality, disabling the steam:// URI scheme isn't a very good work-around.
I did semi-volunteer tech support for my university dorm floor. Every single instance of malware somebody came to me for help cleaning - and there was one at least once per month, on a floor of 70 guys - came from pirated software (typically Photoshop, not games, but sometimes games too). Some were from the outside Internet, some were from the DC++ system that everybody on campus seemed to be using, but they were pervasive.
One of the miggest examples of in-the-wild OS X malware was a trojan in pirate copies of iWork that would add the machines into a botnet.
Malware in pirated software isn't just a hypothetical; it's something that is very, very common. There are, I'm sure, groups who have a good reputation for removing DRM and not inserting their own money-maker (which is what malware is these days; it's all about money) but I'm sure there are also people who take that "clean" code, inject malware, and then re-distribute it. Undeniably, the malware gets into those game installers somehow!
More to the point, while the GP may not have bothered to set up the steam:// URI association in the host Linux system, within the Wine environment it will be working. Now, granted, most people who use Wine for gaming probably aren't also using it for something like running IE4Linux, but if you *were* to do that, you would (potentially) be vulnerable.
Admittedly, the risk is pretty damn minimal in that environment.
I get that you're going for a joke, but the sad thing is, this really shouldn't cost anything at all. Assuming the police are using a volume-licensed edition of either Win7 (sadly, it's quite possible that they're still on XP but I would truly hope not), they can use Bitlocker To Go, which is full-volume encryption for removable storage. It's typically protected with a passphrase (though you can use any of a number of things, including multi-factor auth with smartcards and the like as well) and utilizes very strong encryption. Aside from a few minutes to enable the encryption, and needing to enter the passwords when the drives are mounted, there's no extra cost. It's read-only on XP (since XP doesn't natively support Bitlocker) but otherwise, it's just about perfect for this situation.
There's also Truecrypt and GPG or some other PGP/openpgp implementation. Not as user-friendly as BL2Go, perhaps, but no requirements of OS version. That's just staying within the bounds of free (gratis) software; there are of course more options if they want to spend some cash. Hell, even using encrypted ZIP files would be an improvement...
Err what? The game *starts* in 2100 (the Unity launches in 2060 and spends 40 years in transit). You may be thinking of one of the earlier Civ games. Alpha Centauri, depending on difficulty level, ends (you reach "mandatory retirement age") on 2300, 2400, or 2500. Each turn is one year, unlike typical Civ games.
As a side note, MS definitely does care about gamers on Win8; they expressly allow native apps and graphics APIs (they encourage DirectX, of course) int he Win8 store. I'm not a fan of the content restrictions, to be sure, but you could just host those apps on a third-party site and have peopel sideload them (yes, sideloading is totally possible on Win8 / Windows RT).
Point #1: You just described AppArmor or SELinux. These already exist. They're a pain to configure, but they do what you want.
Point #2: This is, in fact, one of the things that "Metro-style" apps do. It's not just a "touch-first" UI; it's also a per-app sandbox with restrictions on the locations and access that each app has, independent of other apps or of the permissions of the logged-in user.
NT permissions are actually much more fine-grained than POSIX; you can for example permit all logged-in users to read, and all users of a specific group to write as well, but deny one specific user (who might even be a member of the aforementioned group) the right to do anything at all with the file. Write, append, and delete are different permissions. The same permission can be applied to multiple users and/or groups. The owner of a file (or other securable object; in POSIX these would all be files so I might as well call them that) can overwrite any permissions, as you'd expect, and the Administrator ("root") can take ownership of any file, but it's also possible to allow multiple users/groups the ability to take ownership of files. By default, directories use inherited permissions, but it's possible to add additional permissions (or to deny permissions, which overrides "allow" behavior), and it's possible to disable permission inheritance on a directory or file entirely.
Erm, the registry ha sa number of advantages over text config files (.INI or any other kind).
It's centralized. You don't have to search the whole disk, just the registry itself, which is pretty fast.
It's strongly typed. Strings are strings, integers are integers (well, DWORDs), and while arbitrary binary data is permitted, it's not the default.
It's compact. Text files are wasteful of space in several ways (representing numbers as unicode characters, filesystem entries, etc.).
It's hierarchical. A registry key can both contain values and sub-keys. Text config files are flat; unless you use the filesystem itself to provide hierarchy (which then means you have a large number of files potentially per application) you either end up with a long and structureless list, or with a structured file that a slight mistake in editing can break.
It's a standard format. .INI is only one way to store config data; there's other forms of flat files, plus XML and so on. With the registry, you don't have to worry about whether the file needs to have a specific type of newline character or what the character to separate value names from data should be or anything like that.
It's fast. Because registry values are stored with known types and lengths, parsing them is faster than parsing numbers, hex values, etc. out of text files. Back when the registry was first designed (when the 386 was a new and fancy CPU), this mattered more than it does today, but it's still a valid technical point in the registry's favor.
To be sure, the registry has its issues, too. It's definitely less visible than text files are (although settings files are typically marked Hidden...), and it's slightly harder to back up. It also is much harder to find software for general-purpose registry editing than for general-purpose text file editing. Don't pretend that there is no point to the registry, though.
If those are walls, the gate is awfully big and easy to open. Win8 permits sideloading, and doesn't charge for it. Enabling it requires Powershell (oh the horror, a command line!!!!) but is quick and trivial to do.
http://msdn.microsoft.com/en-us/library/windows/apps/hh974578.aspx
Sideloading is permitted on Win8 as well, though. You don't even have to pay for it. The option is less public than on Android - it requires either having Visual Studio installed or using the command line (Powershell, sepcifically), but it's there, it's free, and the info isn't hard to find if you do a search for it.
http://msdn.microsoft.com/en-us/library/windows/apps/hh974578.aspx
Although you are almost correct in concept (legacy software won't run), you're almost entirely incorrect in details. I expect better on /. (at least around technology) and therefore I shall somewhat pedantically correct you.
First of all, Windows RT runs on the NT 6.2 kernel, same as Windows 8. Let's just get that out of the way. It's no more a "special version" much less "new operating system" of NT than the x64 or Itanium (or, going a bit back in history, MIPS, PPC, or Alpha) builds were... aside from the requirement that .exe files have Microsoft's signature. None of those historical NT ports could run "existing Windows applications" either, but they were still Windows.
Second, all of the standard Microsoft desktop components - which use the same APIs as third-party code, BTW - run just fine. Windows RT mandates Microsoft signatures for desktop apps, but assuming a third-party app could obtain such a signature (and was compiled for ARM), it would run. This is not some cloned OS that looks like Windows but is different underneath; aside from the instruction set, the same libraries are present on both.
Third, you say it "shares some of the original code base" but I doubt you can point to any binary that is on Win 8 (not Pro, just standard Win8) but not on Windows RT. As it happens, there are a few, but I doubt you can identify them. It *is* the same code-base, aside from the small (though certainly high-impact) change to the program loader.
Fourth, it comes with CMD, Powershell, and Windows Script Host, so scripts from older versions of Windows will run equally well on Win8 and Windows RT, provided they don't call into third-party software. Given how powerful Powershell scripting is, and the fact that you can create and use COM objects, this is actually a way to port entire apps to Win8 provided that they only use managed code (without requiring additions to the GAC, although I haven't actually confirmed that doing so is impossible) or built-in native COM objects.
Fifth, Windows RT can install third-party apps by sideloading (not be default, but you can unlock it), as well as from the store. "Metro-style" apps can be written in C++ and access the standard Win32 libraries just fine; your app may not be accepted into the store at that point, though. However, you can post the .appx package online for others to download if you want to. The unlock for sideloading is free and already available publicly from Microsoft.
Sixth, we have no actual info on the cost of Surface Pro yet. It could be "nearly a thousand bucks" as you claim - in fact, I'd say that's a decent guess - but that's only a guess. It could also be $700, or $1500. Even I don't know, and in case you couldn't tell, I've been following leaks and details of Surface fairly closely.