"Metro" is (was?) a lot more than just being full-screen. There's integration with the task switcher, support for snapping windows side-by-side, support for notifications, and so on. Making all that stuff work on something that wasn't written from the ground up to be a "Windows Store app" is hard. Chrome does it, but Google has a lot more resources than Mozilla.
Some particular reason you chose to spend money instead of getting the free and open-source Classic Start Menu (from Classic Shell)? Seems kind of silly.
Anyhow, I happen to think you're an idiot if you can't use the same UI (and by far the most productive one) that's been present in Windows since Vista, namely "hit Start (or the Windows key), type a few letters of the program name, hit Enter". It's faster than any mouse-driven interaction and doesn't require manually finding anything in cascading menus *or* scrolling screens of tiles. But that's just, like, my opinion, man...
You are (very) mistaken. WinRT (Windows RunTime) is an API set, a platform for running what Microsoft has (at various times) called "Metro", "Modern", "Immersive", and "Windows Store" apps. While you can make a full-screen touch-friendly UI without using WinRT, you need to use WinRT to integrate with the other "app" stuff that Win8.x does (the new task switcher, the sandboxing, the snapping, the automatic suspension in the background, etc.). To be fair, Firefox probably wasn't really trying to do that (the sandbox part, in particular, would be Really Good for them to have but would be a lot of work) so I expect it was more like what Chrome is doing, where they tack some Win32 UI functions onto their otherwise-traditional browser.
Windows RT, on the other hand, is completely different from WinRT. It can run WinRT apps, but saying they're the same thing would be like saying that Linux and the JVM are the same thing. Well, aside from the fact that those are made by different companies and don't have idiotically similar names... To the best of my knowledge, there was no real effort to port Firefox to Windows RT. I've tried doing that port myself (as a desktop application for jailbroken RT systems, not as a "Metro"/WinRT app) and it would be a tremendous amount of work.
Let's see... Well, the obvious counterpoint to your argument is that PayPal *did* succeed. I happen to hate what it's become (all the abuses of banks, plus a few others, but even less regulation), but back when Musk was starting it up the idea was pretty revolutionary. Even further back, though, there's his startup Zip2, which was sold for over $340 million back in 99.
Since then, his *three* companies (people always forget SolarCity...) all seem to be doing fine. SpaceX has huge contracts, Tesla can't manufacture fast enough to keep up with demand, and SolarCity is one of the top installers of photovoltaic panels in the USA. Sure, they *could* fail, but so could IBM or Google or Coca-Cola. None of them are *likely* to, though. In fact, in the last decade Tesla is just about the only US-based car company that hasn't gone bankrupt...
As for whether the NJ law is aimed at Tesla, you'd have to be a worse nutjob than you claim Musk is to not see it. Let's see, a proposed bill that prohibits a car sales model which happens to be used by exactly one company in the world, right as that company is getting hugely successful? Yeah, there's no evidence at all that this is aimed squarely at Tesla... </SARCASM>
Some people think still using 12-year-old OSes is a good idea.
"And having used Apple's AutoEngineStarterCrank, it's one of the slickest ways to start your car. Sure, early Apple cars required you to turn the crank by hand, but these days you just get out, plug the AutoEngineStartCrank into the front of the car, and it does the work for you!"
As "no crapware", somebody hasn't looked very closely at the Apple drivers... Feature-crippled and riddled with security vulnerabilities compared to the standard ones that Apple often keeps just barely incompatible with their otherwise-standard hardware. Report the latter problem and Apple might fix it in the version of BootCamp for the next OS X release. Unless that's any time soon, in which case you'll have to wait for the version after that. In my more cynical moments, I figure it's because Apple has a vested interest in making Windows appear insecure, so long as it can't easily be traced back to their hardware or software being the problem.
Seriously crappy drivers, mind you (I've found trivial EoP-to-kernel-from standard-user bugs in them), but at least they exist...
The "Metro" version is also free. The non-free apps are scams.
"WinRT" != "Windows RT". This is even discussed in the linked article (yeah, yeah).
Microsoft's branding people should be lined up along a wall, beaten with baseball bats, shot, and then pitched out a fifth-story window onto rusted spikes. OK, maybe that's excessive. There's no need to waste the bullets.
WinRT is an API set, intended for use with "Windows Store apps" (a.k.a. "Metro" or "Modern" apps). It is intended to be sandbox-friendly (for example, having functions to let the user pick a file via a trusted, out-of-process component), battery-friendly (apps are notified when no longer in the foreground, and by default suspend themselves), touch-friendly (you can do the UI in a number of ways, but the standard ways use the "Metro" paradigm with big, swipe-able screens), and responsive (the default behavior is for anything which is likely to block for a while - such as accessing network resources - to be moved of the UI thread). WinRT is usable on x86, x64, and ARM. You can code for it in C++,
Windows RT is an operating system, an edition of Windows 8 (or now of Windows 8.1) compiled for ARM processors. Aside from the target architecture and a feature set somewhere between the normal and Pro x86 editions (it includes some stuff like BitLocker that the normal edition didn't have at least in 8.0, but is otherwise not very Pro-ish), and the removal of a bunch of legacy compatibility stuff, it's very much a straightforward port. The main difference from a user's perspective is that in RT, Windows enforces signature validation on all binaries loaded outside of an app sandbox, preventing third-party "desktop" programs from running. RT 8.0 was "jailbroken" to remove this restriction; it's just a kernel-mode flag that if changed, reverts the OS to basically just another Win8 platform. Windows RT can run Windows Store apps just fine, so long as they're written in an architecture-independent language (JS, or anything on the
VLC is being ported to Windows RT as we speak. The port to the WinRT platform means they just need to re-compile it for RT (ARM). Unfortunately, while this should be simple, VLC doesn't currently compile under MSVC and GCC doesn't know how to target Windows RT. The VLC team is tackling both of these problems; fixing either one will let them proceed with the port. (Personally, I hope they fix the latter one; there's a lot of open-source software we could port to jailbroken RT except that it only compiles under GCC and GCC doesn't know how to target Win32/THUMB-2 yet.)
Porting to RT (ARM) is ongoing. The problem is that GCC doesn't know how to target Win32-THUMB2, and VLC doesn't compile under MSVC yet. They're looking at solving both of those problems, and will go with whichever one bears fruit sooner.
Personally, I hope for the former. GCC being able to target RT would allow us (the users of jailbroken RT devices, which are basically low-power Windows laptop/tablet things with great battery life but you have to re-compile native apps) to port a bunch more open-source software. An awful lot of OSS only builds under GCC and its ilk, so while porting to RT is nominally very easy (in Visual Studio, it's mostly a matter of changing a drop-down in Platform Configuration), many of the apps we have source code to can't be ported without a lot of work.
It's worth noting that
Oh, and one other reason to port it to RT: Once you've ported to WinRT (the API set used for Store/"Metro" apps) and to THUMB-2 (the instruction set Microsoft uses on ARM processors), you can port to WP8 as well. *That* would be a real boon; there are probably a lot more WP8 devices than Windows RT devices, and having VLC on them would be great.
Good to know, thanks! WP7 used MTPZ (Zune-extended/encrypted MTP) and was very Linux-unfriendly, but WP8 appears to use bog-standard MTP. I hadn't tried it on Linux yet but am not surprised that it's reported to work well.
There have been WP-exclusive games since launch. I believe Wordament was exclusive when it launched two years ago, and it's only just recently appeared on non-MS platforms. A number of Microsoft/Xbox-franchise titles (like Halo and Fable) have WP-exclusive games that are either parts of the overall series, or companions to specific games in it. I'm sure there are tons of others.
Windows Phone has TouchDevelop, which is essentially a scripting IDE that allows the developer to select objects by touch rather than needing to type everything out. You can develop apps with it, and even publish them on the store. It's created by Microsoft Research, and was first launched on WP7 something like three years ago. https://www.touchdevelop.com/
They aren't actually very light. Between the battery cells and the armor plate protecting them, the Model S weighs over two tons (4647 lb, or 2108 kilo). That said, the Beast weighs a few times as much, due to being armored on all sides (instead of just the underneath). With that said, they do save weight elsewhere when possible (aluminum for the body except the structural/safety parts, for example).
You *could* make an electric Beast, but it would have relatively short range hauling that much armor around.
This is why you should use unique email addresses for each account. Gmail kind of supports this (they ignore . characters, and anything after a + character, when figuring out the mailbox to send a message to). So you can, for example, use email@example.com to sign up for Slashdot (not that you, AC, would ever do such a thing) and use firstname.lastname@example.org when signing up for online banking, and be secure against the attack you describe unless somebody really clever figures out your naming scheme.
There are other webmail providers that do an even better job of handling unique, disposable addresses.
Wow, you're trying (and I appreciate that) but you really need to think this through a lot harder!
1) Password "guessing" isn't done by a human who will get bored. It's automated, and *extremely* fast. Let's say I can submit 10 password attempts per second (practically speaking, even a shitty home connection can probably manage closer to 50; a botnet could manage tens of thousands easily if the login server is up to it). Just because your password isn't in the 10 most commonly used ones doesn't mean it isn't in the 600 most commonly used ones. Oh no, instead of one second, it took my automated proxy a full minute to break into your account! As if that's a meaningful delay for a targeted attack...
2) How the heck is the user going to "run out" of strong passwords? I mean, even if the site prohibits re-using the old password after a reset, there are a quite literally infinite number of possible passwords. I'll grant that if you kept this attack up until the heat death of the universe, it would eventually reach the point where my "password" might need to longer than a typical sentence in English, but whoop-de-do. You could keep this kind of attack up all year without running the user out of dictionary words, so long as they aren't logging in 20 times a day! You couldn't run somebody out of pairs of such words in a natural human lifetime. That's ignoring case, and using the stupidest possible password generation scheme (choose the next word [pair] from the dictionary). A decent password scheme would be vastly more secure.
3) This user notes that somebody is *constantly* trying to brute force their password. Let's say you've managed to keep it up for months without getting your IP blocked or getting arrested under the CFAA or some such thing. The target of the attack has run through dozens of passwords. Why the hell would they decide to use a really weak one (knowing there's a constant attack going on) for their next one? Wouldn't it make a lot more sense at that point to hammer on the keyboard for five seconds when asked to create their password, knowing full well they will need to reset it next time they want to log in anyhow, due to that asshole wasting their time forcing resets constantly?
Yeah, you *really* didn't think about that one very hard, did you?
Detecting weak passwords is trivial. Here's how you do it: take a password database (there have been lots of leaked passwords from various insecure sites). Sort it by how common the password is, descending order. Require that the user's new password not be in the upper portion (upper thousand or so would probably be a good start) of the list. Update that list periodically, to account for the possibility of password shift.
For bonus points, do the following:
Hash every password in the list to make it marginally more difficult to reverse (for practical reasons, you can't use a strong password verification function like SCrypt or PBKDF2-with-lots-of-iterations here, but you shouldn't use plain text). Make sure the user's proposed password's hash isn't one of the commonly used ones. Then, once it's accepted (and protected much more strongly, with salt and so on), add it to the list (incrementing the count if already present) and re-sort. That way, if you block the 1000 most common passwords and a bunch of people start using the 1001st-most-common, that password will itself quickly become unusable for new accounts and password changes or resets.