Yep, I have a Facebook account (that I almost never use), and also use both Google and Bing. Yet, neither of them has any access to that Facebook account; I keep it separate. Bing *offers* to let me connect my searches to Facebook, but doesn't do so automatically in any way.
If you sign into G+ and then go use Google, is the search integration opt-in or opt-out? This is an honest question; I don't use G+ so I have no idea.
Wow, you really are an idiot. The toolbar installer explained that it could send your searches to Microsoft in order to improve results. It was obviously (except, oddly, to Google's completely brilliant and utterly unbiased engineers) a feature you enabled if you wanted to guide Bing towards better (from your perspective) search results. Google engineers deliberately enabled this behavior, then poisoned the results with nonsense searches that *had* no legit results, so the only info Bing had on those queries were the poisoned values. They then claimed that the fact that Microsoft was using the poisoned values that Google had deliberatesly sent them meant that Microsoft was "copying" Google.
A number of... individuals... such as yourself not only believed Google's absurd bullshit, they kept on repeating it long after Google themselves retreated when they realized their attempt to smear a competitor was having a counterproductive effect.
Also, DuckDuckGo uses Bing (and not in a "Bing copies Google results!!1!" sense, but as in some of its searches are actually directly executed through Bing), among other search engines. So, guess what, you're using Microsoft products. Who's the fool, again?
YaST2 (Yet another Setup Tool) on Suse/openSuse is pretty much just what you describe: a powerful and user-friendly all-in-one-place GUI configuration tool, that works by simply modifying the underlying config files. It will also show you the relevant config files, so you can modify them by hand and/or see the changes that the GUI causes. It's got front-ends written for a bunch of interfaces (various versions of QT/KDE, GTK/GNOME/XFCE/probably others, and an ncurses-based terminal UI that works great over SSH and can be used to fix your system when the X11 server explodes.
I've often wondered why something like YaST (or YaST itself; it's GPLed and making it work on other distros wouldn't be terribly hard) isn't more commonly a part of Linux distros. It allowed me to learn the basics of many config files simply by tweaking options in the GUI (which comes complete with item-by-item help info) and seeing what happened in the file. It was easy to use when I needed my hand held, and didn't get in the way when I knew exactly what I wanted to change.
Incidentally, Windows does actually support a number of command line administrative tools. Net and netsh can be used to control a user's interaction with the network (mounting drives, setting home folders, etc) and control network interfaces, respectively, for example. Both are clear enough to be usable from the command line, and are designed to support scripting. There are many other tools like this too. Another one I find handy is manage-bde, which allows greater control over BitLocker drive encryption than the GUI offers.
What an hour for my remaining mod points to expire. +Informative on this. It's different from (but serves the same purposes as) ifconfig and iwconfig, and it's different (although has a slight feature overlap) from ipconfig on Windows, but netsh is very much oriented at users like the GP of this post. To a complete newbie, it's confusing and a bit scary; to somebody who is comfortable with the command line and/or likes to use scripts to automate system administration, it's excellent.
Although kernel major version numbers are allowed to break driver compatibility, it turns out that most NT5.x (XP being 5.1) drivers load just fine in NT6.x (Win7 being 6.1). Have you actually tried installing that driver on a newer version? The whole driver compat thing was a huge red herring for me with Vista; the only drivers that I found I couldn't get to work perfectly were network and printer drivers, both of which saw substantial changes in the API. Sound, video, webcam, internal components, and other peripherals worked fine, although sometimes you had to run the installation in "compatibility mode" to trick the installer into thinking it was on XP.
These things already exist. Businesses (mostly things like governments actually, I think) pay MS vast quantities of money to keep things like NT4 on life support.
It really is a huge cost to MS, though. In addition to paying the salaries of all the people neccessary to support, backport, fix, test, regression test, etc. all that shit, there's an opportunity cost to the company: those people now can't be working on similar projects for Win8 or Office on Windows Phone or whatever. These are usually long-term people (where else are you going to find folks who know a system that old?) who command high salaries and really could be putting that experience to better use elsewhere.
It's not just developers and testers, either. They have to keep power- and space-inefficient ancient hardware around to test compatibility, because an OS that old won't run on modern hardware, and that's compatibility lab space that can't be used for testing Win8 tablets or drivers for some Brazillian piece of scientific equipment that's probably used by an order of magnitude more people than still run NT4. They have to internationalize any important changes they make that are visible in the UI (though probably they only bother with i18n for countries where people pay these support rates). Their internal IT people must deal with these dinosaurs that would otherwise long since have been killed off. It is, all in all, a huge and expensive mess.
Congratulations, you have identified yourself as *exactly* the target market for Virtual XP Mode, included at no extra cost with any edition of Win7 that a half-sane business large enough to even *have* two business-critical apps would ever run!
I'm still not sure where all these "won't run on XP" apps come from, mind you... between compatibility modes and permissions edits, I've been able to run pretty much anything (for a fairly wide class of anything, including some things that the developer stated flat-out wouldn't work on Vista or Win7). For the rest, unless you need direct access to the GPU, Virtual XP Mode works fine.
What the hell do you think "phase out XP" actually means? Keeping the server running for old patches is easy - last I checked, you could still get old Win2k patches, for example - but that is definitely not supported. Support means providing bug fixes, especially security patches. You talk about "user runs into a problem that can't be solved by XP" as if lack of security patches isn't very much exactly that kind of problem. Only an idiot would wait until they need a patch that they can't get before upgrading, when the writing has been on th wall for this long.
By your argument, there's really no reason not to still be running WIndows 2000. In fact, there's hardly any reason not to run Windows 98 (there's a lot of software that won't run on versions that old, but then, there's already software that won't run on XP as well, and the point of this story is that more and more software is moving into that camp). There are of course improvements to the OS between Win2k and XP... not nearly so large of improvements as between XP and Win7, though.
Simplest and most obviously, you're starting from a false position. XP doesn't "work perfectly well" at all compared to modern systems. Its security is literally a decade out of date, for example (no support for ASLR, no support for process integrity levels, no BitLocker, a big pain to operate as anything other than Administrator, requires third-party anti-malware and preferably firewall too, LM hashes of all goddamn things although those can of course be disabled). It has terrible hardware utilization (32-bit only unless you don't actually need drivers at all, aggressively pages everything to disk and leaves huge amounts of free RAM wasted). It is missing a bunch of important APIs for modern software (CNG comes immediately to mind; can you tell I'm a security type?) Instant search is a *huge* productivity enhancement... that everything since XP has but XP doesn't. For that matter, Aero (in particular, the abilities to peek at windows when switching and to snap windows to half the screen) is also a productivity enhancer. For legacy stuff that just won't go away, the Virtual XP mode not only works well, it's surprisingly close to seamless (the Remote Dekstop protocol is used to bring the app windows from the VM, which is hidden, onto the host desktop).
When you say "does this now and costs us nothing", don't forget to count the ancilliary costs of using XP. How much do you have to spend on IT dealing with malware? Win7 is much less succeptible. What is the productivity cost to your people, who have to use an OS that mismanages RAM so badly and doesn't handle a multi-program workflow very well?
I'd agree for Star Wars (the Force in particular pushes it over that line) but I disagree for Star Trek. Some of the tech was actually explained in moderate detail - the weapons and tractor beams, for example, and certain elements of the sensors, shields, impulse drive, warp drive, combadges, transporters, replicators, etc. We may not know how to do any of it right now, and some of the details are certainly wrong, but that's normal even for moderately hard sci-fi when viewed decades after it was written (not that I'm claiming Trek is particularly hard... but it's not "futuristic fiction" either). For example, we currently can't even manufacture enough antimatter for a photon topedo, much less keep it around long enough to store in an armory and then launch as a self-guided projectile against an enemy ship, but the basic scientific concept of an anti-matter weapon is reasonably sound. Aside from a bad case of SciFi Writers Have No Sense Of Scale (the range at which ships battle, the time it would take to get anywhere at impulse, the sheer size of a planet, etc.), there aren't many consistent and obvious scientific mistakes that occur throughout the series. The telepath/empath stuff is probably the hardest to buy, aside from entities like Q.
A few of the things in Trek are actually pretty realistic. Hyposprays, for example, are a real thing, if not currently quite as advanced as what we saw on the screen. Some of the astronomical phenomena they explored were also well done. Aside from their range and lack of anything we'd recognize as a power source today, combadges are possible Right Now (as in, there exist wifi-based versions for use in hospitals, complete with the ability to identify people by voice and locate the nearest apropriate recipient). Touchscreens and voice-driven and/or handheld computers (if not "true AI") are already in use. Considering when Star Trek was written, a lot of that stuff was pretty forward-looking, even if off by couple centuries
Besides, sci-fi isn't really about the tech itself, a lot of it is about "if we have this tech, what can we do with it?". Some places this wasn't very well applied - the transporter has a lot of potential purposes that it's rarely if ever used for, for example - but there were some surprisingly clever things too. If we assume the presence of a transporter that can identify a life-form, and pick it out of its surroundings without either destroying those surroundings or bringing them along, then having filters on it that can detect known harmful life forms and remove them makes sense. If you've got a universal translator that can quickly learn the syntax and vocabulary of any new language (admittedly, the way this happens seems pretty magical, but hey, sufficiently advanced tech...), it makes sense that it would be confounded if it encountered a being that spoke entirely in metaphor rather than literal meaning (or rather, it would translate the metaphors, but not the background that makes them meaningful). There are tons of examples like that, ranging from well-played-out ones (aggressive AIs, strange diseases, hive minds, time travel, "the [THING] stopped working!", genetic engineering for supersoldiers, etc.) to very novel (preserving memory of your dying civilization in a system that lets other being re-live the lives of your people, the Greek gods as highly advanced aliens, diplomacy with alien races [at the time, aliens were almost always either implacable enemies and/or utterly incomprehensible], and so on).
Copy-pasting a retarded statement doesn't make it less retarded, it makes you look more retarded. Why does an extra $100 cost translate into a $200 price increase? That implies you're tacking on an extra $100 profit just so you can try to make a point (hint: it's not working, unless your point is that you have no understanding of even basic economics).
Incidentally, you've got the cost wrong. There's a license cost for Android if you want to use Google's stuff, plus most Android-using OEMs pay patent licensing costs on top of that. Android, as used in mainstream devices (other than Kindles and the like, which don't use any Google features), is definitely not free. Additionally, Windows RT is less than $100. The total price difference might be as much as $50, but I doubt it.
Nor is.NET tied to IIS, or GNU to Linux for that matter. The other direction also applies. PHP/Apache seems like a reasonable enough way to express the poster's obvious meaning.
Now, whether you agree with the rest of the post or not is a completely different issue, but if you want to do that, go ahead.
Off-topic, but you can actually already run an entire Linux OS in the browser. Of course, first you have to emulate an x86-based computer to run it on.
Um... no. No part of any of the attacks I described requires any interception or replacement of the crypto code (I thought I made that clear). You're still going to have to serve a webpage though. In fact, in order to use these new crypto functions, you're going to have to serve script as well.
I (the attacker, whether via MitM or server control or some other mechanism) can modify that to my heart's content. I don't even have to modify the existing scripts; just inject my own that captures every keystroke sent to the web page and sends them to a server I control (for example). All the crypto in the world won't protect you against that, no matter where it's implemented or what protections it has.
Perhaps slightly OT, but what do you mean, "unlike Windows"? The NT kernel, which powers what most people think of as "Windows", has been portable for longer than Linux (the kernel) has!
The first portable version of Linux was 1.2 (released March 1995) and supported x86, Alpha, SPARC, and MIPS. The prior release, 1.0 in March 1994, was x86 only.
Windows NT, by comparison, wasn't even developed initially on x86 (explicitly to avoid x86-specific behavior from creeping in), although it was of course ported to x86 before release. The very first release (numbered 3.1 to match the DOS-based Windows version of the time) supported x86, Alpha, and MIPS in July 1993.
I will grant you that only recently has MS bothered to port NT to ARM, but that's because they had another kernel (CE) which they've been using to power ARM devices since at least 1997. However, despite recent massive improvements to CE, it's still inferior to NT for a general-purpose computer (though it has other useful characteristics, such as being hard-realtime and able to run on extremely minimal systems).
This. Providing proper crypto primitives in the JS standard library is a good thing, I suppose, but it doesn't solve any (and I do mean any) of the underlying problems with things like CryptoCat. CC actually had quite good crypto primitives (implemented from scrach in JS, but apparently implemented well).
The problem was that every time a user wanted to use CC, they had to download the page (and its JS) from the CC server... and there are so many ways to attack that. An obvious one is to insert a backdoor in the code sent from the server (like what Hushmail did). Crypto primitives in the script library won't help here. Another obvious one is to use SSLStrip to MitM the connection, and inject your own backdoor script along with the server response. Finally, there's attacks against the SSL itself, including things like CRIME.
Essentially, the degree to which you can trust something like CryptoCat is entirely based on the degree to which you trust the server and the connection. It's still host-based security, even though it pretends not to be. No amount of making it easier to implement CryptoCat (which is what you'll get out of this change) is going to make it any more secure.
Revenue, not profit. This is standard, even introductory, economics. The sites apparently turned about about 5M in profits, which makes 20M very much in line with an expected buyout price.
There are also actually some useful features of IE that no other browser has be default (there are halfway-there implementations of some in Firefox extensions, and full implementations of a few others). I use IE, Firefox, and Chrome on a daily basis (Opera and Safari are also installed but rarely get used). For example, I prefer the built-in tab management in IE over both of the others, although I'm a little annoyed that they disabled Quick Tabs by default in IE9 (easy to restore it though). This is one area where Firefox extensions surpass the built-in behavior of IE, though.
Why the hell would you do it that way? All major OSes, including NT (XP, Vista, Windows *, Windows Server *), have the ability to *automatically* run a program as a specific user, even if that user is different from the user that launched the program. On POSIX systems, this is enshrined in the filesystem permission bits; setUID and setGID.
Win8 actually does this for apps installed from the Marketplace. Each one gets a new, unique SID (security identifier, essentially a user account except without things like the ability to log into it), and install and data folders are created for each app that are accessible by that app's SID. There *are* ways to break out of this sandbox - some apps need more system-wide access, even if still only at standard user privileges - but the application developer must intentionally enable the app to do so, and the app must declare its ability to do so in its manifest (which contains the capability list).
Windows Phone 7 (despite being based on the CE kernel, which normally doesn't really have user accounts) and of course WP8 (NT kernel) also do this, and I believe both Android and iOS do as well (although I haven't yet checked).
Managed / memory-safe languages aren't a guaranteed protection, though.
First of all, there can be bugs in the runtime that lead to possible exploits. I have a friend who manages to generate segfaults in Java about once every two weeks (no idea how many of them are the same bug being hit multiple times; maybe all of them). In case you're confused, a segfault (as opposed to a NullPointerException) means the runtime thought it could access the memory there, after running all its checks... and found out otherwise when it tried and the CPU had to slap it down. The eqivalent term for segfault on Windows would be "access violation" and in both uses, it boils down to a security bug , potentially exploitable by triggering memory corruption. For that matter, JavaScript itself should be memory-safe.
Which brings us to the second issue: when you're trying to JIT-compile a script, the actual processing of the script is done in the compiler. You could write all of that in the safest language in the world... and it wouldn't do you any good if there's a bug in the compiler's code generation (note: not in the parsing of the script) that causes the resulting code, when executed, to be memory-unsafe. It's much, much harder to verify the safety of generated code (for a reasonably complex language; JS certainly being one) than it is to verify the safety of the code generator itself (even if written in C++).
Completely wrong, as it happens, although I'm honestly not sure how you could have gotten that idea. Drive-by exploits, in the sense of "you visit a website and are pwned", have existed for all major browsers.
To be fair, most of these are pretty old; 2010 or sometimes before. I could have chosen a 2012 for Chrome, but chose to look explicitly at the browser, not at the Flash plugin (even though it's bundled with the browser and enabled by default...) Secunia's database also isn't comprehensive; for example, there were vulns found (by a white-hat, so patched before release and not included here) in Chrome earlier this year. That said, if you filter advisories to "extremely critical", IE has a much longer list than the other browsers (although part of that will just be market penetration making it the thing people have been targeting most). I also ignored browser version; that list for IE includes IE6 for example.
Trek really wasn't "hard" sci-fi... it was harder than some (Star Wars, for example, though I like SW too) but it was both too futuristic and too mass-market targeted to go much into really hard sciency explanations.
I believe if you read the various "supporting materials" (Star Trek encyclopedias and such) you'll find information on how warp is supposed to work canonically, but the details are obviously a bit fuzzy. We know it involves the generation of a "warp field" of normal space that surrounds the ship, and in a handful of episodes the drive was referred to using terms like "space-time warp" which would potentially be consistent with the Alcubierre drive. Additionally, the starship drives of the main shows and movies are anti-matter powered, which is in line with the energy requrements suggested here (smash 250 kilos each of matter and antimatter together, get 500kg-equivalent of energy).
I forget any technical details I ever may have known of Cochrane's ship's warp drive beyond the general details of it having a warp field and such. I'm not even sure if it was AM powered - but then, it flew only a very short distance at a "slow" (for ST warp drive) speed.
Also, you are of course welcome to hold your own opinions, but I personally think that First Contact wasn't bad at all. Not the best of Trek as an entire series (IMO), but generally considered one of the best movies by fans.
Although an outside observer would say that the light beam is travelling only very slightly faster than you, *you* would see the beam travel at exactly 1.0*c away from you. From your frame of reference, light in a vacuum *always* travels at this speed relative to its source.
The apparent discrepency is resolved by noting that at that speed, the time dialation you'd be experiencing is so great that after one second (as you experience it), the wave front of the light is one light-second ahead of your curent position. To an outside observer, one second after you turn on the light the wave front has progressed by one light-second from its initial position and you're only about 30m behind it... but that's because, to you, only a tiny fraction of that second has occurred yet.
By Dec 2011, WP7 had been out for just over a year. 5M in one year isn't very good for a smartphone, true. Now, consider that Nokia has sold 7M Lumia devices this year alone - putting them on track for at least 10M and probably more (consider the holiday season). That's just the Nokia WP7 devices; there are a lot of other manufacturers.
15M by the end of this year, even if we discount everything except the Lumia sales for this year, is 3% market share (possibly a bit less, since the market is growing) and 200% growth in a year. The Lumia 920 has garnered a *lot* of interest too; I expect that the sales rate of WinPhone will continue increasing.
Yeah, it'll take it quite a while to be a serious competitor to the established players... but then, Android launched with aalmost insignificant blip and relatively little growth until the release of the Droid and the huge amount of marketing that went into promoting it. Android surpassed iOS some time ago and has gone on growing since, but they're not unassailable.
Slashdot Mirror
Yep, I have a Facebook account (that I almost never use), and also use both Google and Bing. Yet, neither of them has any access to that Facebook account; I keep it separate. Bing *offers* to let me connect my searches to Facebook, but doesn't do so automatically in any way.
If you sign into G+ and then go use Google, is the search integration opt-in or opt-out? This is an honest question; I don't use G+ so I have no idea.
Wow, you really are an idiot. The toolbar installer explained that it could send your searches to Microsoft in order to improve results. It was obviously (except, oddly, to Google's completely brilliant and utterly unbiased engineers) a feature you enabled if you wanted to guide Bing towards better (from your perspective) search results. Google engineers deliberately enabled this behavior, then poisoned the results with nonsense searches that *had* no legit results, so the only info Bing had on those queries were the poisoned values. They then claimed that the fact that Microsoft was using the poisoned values that Google had deliberatesly sent them meant that Microsoft was "copying" Google.
A number of... individuals... such as yourself not only believed Google's absurd bullshit, they kept on repeating it long after Google themselves retreated when they realized their attempt to smear a competitor was having a counterproductive effect.
Also, DuckDuckGo uses Bing (and not in a "Bing copies Google results!!1!" sense, but as in some of its searches are actually directly executed through Bing), among other search engines. So, guess what, you're using Microsoft products. Who's the fool, again?
YaST2 (Yet another Setup Tool) on Suse/openSuse is pretty much just what you describe: a powerful and user-friendly all-in-one-place GUI configuration tool, that works by simply modifying the underlying config files. It will also show you the relevant config files, so you can modify them by hand and/or see the changes that the GUI causes. It's got front-ends written for a bunch of interfaces (various versions of QT/KDE, GTK/GNOME/XFCE/probably others, and an ncurses-based terminal UI that works great over SSH and can be used to fix your system when the X11 server explodes.
I've often wondered why something like YaST (or YaST itself; it's GPLed and making it work on other distros wouldn't be terribly hard) isn't more commonly a part of Linux distros. It allowed me to learn the basics of many config files simply by tweaking options in the GUI (which comes complete with item-by-item help info) and seeing what happened in the file. It was easy to use when I needed my hand held, and didn't get in the way when I knew exactly what I wanted to change.
Incidentally, Windows does actually support a number of command line administrative tools. Net and netsh can be used to control a user's interaction with the network (mounting drives, setting home folders, etc) and control network interfaces, respectively, for example. Both are clear enough to be usable from the command line, and are designed to support scripting. There are many other tools like this too. Another one I find handy is manage-bde, which allows greater control over BitLocker drive encryption than the GUI offers.
What an hour for my remaining mod points to expire. +Informative on this. It's different from (but serves the same purposes as) ifconfig and iwconfig, and it's different (although has a slight feature overlap) from ipconfig on Windows, but netsh is very much oriented at users like the GP of this post. To a complete newbie, it's confusing and a bit scary; to somebody who is comfortable with the command line and/or likes to use scripts to automate system administration, it's excellent.
Although kernel major version numbers are allowed to break driver compatibility, it turns out that most NT5.x (XP being 5.1) drivers load just fine in NT6.x (Win7 being 6.1). Have you actually tried installing that driver on a newer version? The whole driver compat thing was a huge red herring for me with Vista; the only drivers that I found I couldn't get to work perfectly were network and printer drivers, both of which saw substantial changes in the API. Sound, video, webcam, internal components, and other peripherals worked fine, although sometimes you had to run the installation in "compatibility mode" to trick the installer into thinking it was on XP.
These things already exist. Businesses (mostly things like governments actually, I think) pay MS vast quantities of money to keep things like NT4 on life support.
It really is a huge cost to MS, though. In addition to paying the salaries of all the people neccessary to support, backport, fix, test, regression test, etc. all that shit, there's an opportunity cost to the company: those people now can't be working on similar projects for Win8 or Office on Windows Phone or whatever. These are usually long-term people (where else are you going to find folks who know a system that old?) who command high salaries and really could be putting that experience to better use elsewhere.
It's not just developers and testers, either. They have to keep power- and space-inefficient ancient hardware around to test compatibility, because an OS that old won't run on modern hardware, and that's compatibility lab space that can't be used for testing Win8 tablets or drivers for some Brazillian piece of scientific equipment that's probably used by an order of magnitude more people than still run NT4. They have to internationalize any important changes they make that are visible in the UI (though probably they only bother with i18n for countries where people pay these support rates). Their internal IT people must deal with these dinosaurs that would otherwise long since have been killed off. It is, all in all, a huge and expensive mess.
Congratulations, you have identified yourself as *exactly* the target market for Virtual XP Mode, included at no extra cost with any edition of Win7 that a half-sane business large enough to even *have* two business-critical apps would ever run!
I'm still not sure where all these "won't run on XP" apps come from, mind you... between compatibility modes and permissions edits, I've been able to run pretty much anything (for a fairly wide class of anything, including some things that the developer stated flat-out wouldn't work on Vista or Win7). For the rest, unless you need direct access to the GPU, Virtual XP Mode works fine.
What the hell do you think "phase out XP" actually means? Keeping the server running for old patches is easy - last I checked, you could still get old Win2k patches, for example - but that is definitely not supported. Support means providing bug fixes, especially security patches. You talk about "user runs into a problem that can't be solved by XP" as if lack of security patches isn't very much exactly that kind of problem. Only an idiot would wait until they need a patch that they can't get before upgrading, when the writing has been on th wall for this long.
By your argument, there's really no reason not to still be running WIndows 2000. In fact, there's hardly any reason not to run Windows 98 (there's a lot of software that won't run on versions that old, but then, there's already software that won't run on XP as well, and the point of this story is that more and more software is moving into that camp). There are of course improvements to the OS between Win2k and XP... not nearly so large of improvements as between XP and Win7, though.
Simplest and most obviously, you're starting from a false position. XP doesn't "work perfectly well" at all compared to modern systems. Its security is literally a decade out of date, for example (no support for ASLR, no support for process integrity levels, no BitLocker, a big pain to operate as anything other than Administrator, requires third-party anti-malware and preferably firewall too, LM hashes of all goddamn things although those can of course be disabled). It has terrible hardware utilization (32-bit only unless you don't actually need drivers at all, aggressively pages everything to disk and leaves huge amounts of free RAM wasted). It is missing a bunch of important APIs for modern software (CNG comes immediately to mind; can you tell I'm a security type?) Instant search is a *huge* productivity enhancement... that everything since XP has but XP doesn't. For that matter, Aero (in particular, the abilities to peek at windows when switching and to snap windows to half the screen) is also a productivity enhancer. For legacy stuff that just won't go away, the Virtual XP mode not only works well, it's surprisingly close to seamless (the Remote Dekstop protocol is used to bring the app windows from the VM, which is hidden, onto the host desktop).
When you say "does this now and costs us nothing", don't forget to count the ancilliary costs of using XP. How much do you have to spend on IT dealing with malware? Win7 is much less succeptible. What is the productivity cost to your people, who have to use an OS that mismanages RAM so badly and doesn't handle a multi-program workflow very well?
I'd agree for Star Wars (the Force in particular pushes it over that line) but I disagree for Star Trek. Some of the tech was actually explained in moderate detail - the weapons and tractor beams, for example, and certain elements of the sensors, shields, impulse drive, warp drive, combadges, transporters, replicators, etc. We may not know how to do any of it right now, and some of the details are certainly wrong, but that's normal even for moderately hard sci-fi when viewed decades after it was written (not that I'm claiming Trek is particularly hard... but it's not "futuristic fiction" either). For example, we currently can't even manufacture enough antimatter for a photon topedo, much less keep it around long enough to store in an armory and then launch as a self-guided projectile against an enemy ship, but the basic scientific concept of an anti-matter weapon is reasonably sound. Aside from a bad case of SciFi Writers Have No Sense Of Scale (the range at which ships battle, the time it would take to get anywhere at impulse, the sheer size of a planet, etc.), there aren't many consistent and obvious scientific mistakes that occur throughout the series. The telepath/empath stuff is probably the hardest to buy, aside from entities like Q.
A few of the things in Trek are actually pretty realistic. Hyposprays, for example, are a real thing, if not currently quite as advanced as what we saw on the screen. Some of the astronomical phenomena they explored were also well done. Aside from their range and lack of anything we'd recognize as a power source today, combadges are possible Right Now (as in, there exist wifi-based versions for use in hospitals, complete with the ability to identify people by voice and locate the nearest apropriate recipient). Touchscreens and voice-driven and/or handheld computers (if not "true AI") are already in use. Considering when Star Trek was written, a lot of that stuff was pretty forward-looking, even if off by couple centuries
Besides, sci-fi isn't really about the tech itself, a lot of it is about "if we have this tech, what can we do with it?". Some places this wasn't very well applied - the transporter has a lot of potential purposes that it's rarely if ever used for, for example - but there were some surprisingly clever things too. If we assume the presence of a transporter that can identify a life-form, and pick it out of its surroundings without either destroying those surroundings or bringing them along, then having filters on it that can detect known harmful life forms and remove them makes sense. If you've got a universal translator that can quickly learn the syntax and vocabulary of any new language (admittedly, the way this happens seems pretty magical, but hey, sufficiently advanced tech...), it makes sense that it would be confounded if it encountered a being that spoke entirely in metaphor rather than literal meaning (or rather, it would translate the metaphors, but not the background that makes them meaningful). There are tons of examples like that, ranging from well-played-out ones (aggressive AIs, strange diseases, hive minds, time travel, "the [THING] stopped working!", genetic engineering for supersoldiers, etc.) to very novel (preserving memory of your dying civilization in a system that lets other being re-live the lives of your people, the Greek gods as highly advanced aliens, diplomacy with alien races [at the time, aliens were almost always either implacable enemies and/or utterly incomprehensible], and so on).
Ok, getting off the nerd box now.
Copy-pasting a retarded statement doesn't make it less retarded, it makes you look more retarded. Why does an extra $100 cost translate into a $200 price increase? That implies you're tacking on an extra $100 profit just so you can try to make a point (hint: it's not working, unless your point is that you have no understanding of even basic economics).
Incidentally, you've got the cost wrong. There's a license cost for Android if you want to use Google's stuff, plus most Android-using OEMs pay patent licensing costs on top of that. Android, as used in mainstream devices (other than Kindles and the like, which don't use any Google features), is definitely not free. Additionally, Windows RT is less than $100. The total price difference might be as much as $50, but I doubt it.
It uses ActiveSync, so there's some central admin you can do, but it doesn't support domain joining for some reason.
Nor is .NET tied to IIS, or GNU to Linux for that matter. The other direction also applies. PHP/Apache seems like a reasonable enough way to express the poster's obvious meaning.
Now, whether you agree with the rest of the post or not is a completely different issue, but if you want to do that, go ahead.
Off-topic, but you can actually already run an entire Linux OS in the browser. Of course, first you have to emulate an x86-based computer to run it on.
You think I'm joking...
Um... no. No part of any of the attacks I described requires any interception or replacement of the crypto code (I thought I made that clear). You're still going to have to serve a webpage though. In fact, in order to use these new crypto functions, you're going to have to serve script as well.
I (the attacker, whether via MitM or server control or some other mechanism) can modify that to my heart's content. I don't even have to modify the existing scripts; just inject my own that captures every keystroke sent to the web page and sends them to a server I control (for example). All the crypto in the world won't protect you against that, no matter where it's implemented or what protections it has.
Perhaps slightly OT, but what do you mean, "unlike Windows"? The NT kernel, which powers what most people think of as "Windows", has been portable for longer than Linux (the kernel) has!
The first portable version of Linux was 1.2 (released March 1995) and supported x86, Alpha, SPARC, and MIPS. The prior release, 1.0 in March 1994, was x86 only.
Windows NT, by comparison, wasn't even developed initially on x86 (explicitly to avoid x86-specific behavior from creeping in), although it was of course ported to x86 before release. The very first release (numbered 3.1 to match the DOS-based Windows version of the time) supported x86, Alpha, and MIPS in July 1993.
I will grant you that only recently has MS bothered to port NT to ARM, but that's because they had another kernel (CE) which they've been using to power ARM devices since at least 1997. However, despite recent massive improvements to CE, it's still inferior to NT for a general-purpose computer (though it has other useful characteristics, such as being hard-realtime and able to run on extremely minimal systems).
This. Providing proper crypto primitives in the JS standard library is a good thing, I suppose, but it doesn't solve any (and I do mean any) of the underlying problems with things like CryptoCat. CC actually had quite good crypto primitives (implemented from scrach in JS, but apparently implemented well).
The problem was that every time a user wanted to use CC, they had to download the page (and its JS) from the CC server... and there are so many ways to attack that. An obvious one is to insert a backdoor in the code sent from the server (like what Hushmail did). Crypto primitives in the script library won't help here. Another obvious one is to use SSLStrip to MitM the connection, and inject your own backdoor script along with the server response. Finally, there's attacks against the SSL itself, including things like CRIME.
Essentially, the degree to which you can trust something like CryptoCat is entirely based on the degree to which you trust the server and the connection. It's still host-based security, even though it pretends not to be. No amount of making it easier to implement CryptoCat (which is what you'll get out of this change) is going to make it any more secure.
Revenue, not profit. This is standard, even introductory, economics. The sites apparently turned about about 5M in profits, which makes 20M very much in line with an expected buyout price.
There are also actually some useful features of IE that no other browser has be default (there are halfway-there implementations of some in Firefox extensions, and full implementations of a few others). I use IE, Firefox, and Chrome on a daily basis (Opera and Safari are also installed but rarely get used). For example, I prefer the built-in tab management in IE over both of the others, although I'm a little annoyed that they disabled Quick Tabs by default in IE9 (easy to restore it though). This is one area where Firefox extensions surpass the built-in behavior of IE, though.
Why the hell would you do it that way? All major OSes, including NT (XP, Vista, Windows *, Windows Server *), have the ability to *automatically* run a program as a specific user, even if that user is different from the user that launched the program. On POSIX systems, this is enshrined in the filesystem permission bits; setUID and setGID.
Win8 actually does this for apps installed from the Marketplace. Each one gets a new, unique SID (security identifier, essentially a user account except without things like the ability to log into it), and install and data folders are created for each app that are accessible by that app's SID. There *are* ways to break out of this sandbox - some apps need more system-wide access, even if still only at standard user privileges - but the application developer must intentionally enable the app to do so, and the app must declare its ability to do so in its manifest (which contains the capability list).
Windows Phone 7 (despite being based on the CE kernel, which normally doesn't really have user accounts) and of course WP8 (NT kernel) also do this, and I believe both Android and iOS do as well (although I haven't yet checked).
Managed / memory-safe languages aren't a guaranteed protection, though.
First of all, there can be bugs in the runtime that lead to possible exploits. I have a friend who manages to generate segfaults in Java about once every two weeks (no idea how many of them are the same bug being hit multiple times; maybe all of them). In case you're confused, a segfault (as opposed to a NullPointerException) means the runtime thought it could access the memory there, after running all its checks... and found out otherwise when it tried and the CPU had to slap it down. The eqivalent term for segfault on Windows would be "access violation" and in both uses, it boils down to a security bug , potentially exploitable by triggering memory corruption. For that matter, JavaScript itself should be memory-safe.
Which brings us to the second issue: when you're trying to JIT-compile a script, the actual processing of the script is done in the compiler. You could write all of that in the safest language in the world... and it wouldn't do you any good if there's a bug in the compiler's code generation (note: not in the parsing of the script) that causes the resulting code, when executed, to be memory-unsafe. It's much, much harder to verify the safety of generated code (for a reasonably complex language; JS certainly being one) than it is to verify the safety of the code generator itself (even if written in C++).
Completely wrong, as it happens, although I'm honestly not sure how you could have gotten that idea. Drive-by exploits, in the sense of "you visit a website and are pwned", have existed for all major browsers.
Firefox: much like this IE9 bug; only requires you to execute some script
Chrome: buffer mismanagement in SPDY or bad casts in SVG
Safari: visit a website and automatically execute a shell script from it
Opera: buffer overflow using file download name in the prompt (can trigger automatically)
To be fair, most of these are pretty old; 2010 or sometimes before. I could have chosen a 2012 for Chrome, but chose to look explicitly at the browser, not at the Flash plugin (even though it's bundled with the browser and enabled by default...) Secunia's database also isn't comprehensive; for example, there were vulns found (by a white-hat, so patched before release and not included here) in Chrome earlier this year. That said, if you filter advisories to "extremely critical", IE has a much longer list than the other browsers (although part of that will just be market penetration making it the thing people have been targeting most). I also ignored browser version; that list for IE includes IE6 for example.
Trek really wasn't "hard" sci-fi... it was harder than some (Star Wars, for example, though I like SW too) but it was both too futuristic and too mass-market targeted to go much into really hard sciency explanations.
I believe if you read the various "supporting materials" (Star Trek encyclopedias and such) you'll find information on how warp is supposed to work canonically, but the details are obviously a bit fuzzy. We know it involves the generation of a "warp field" of normal space that surrounds the ship, and in a handful of episodes the drive was referred to using terms like "space-time warp" which would potentially be consistent with the Alcubierre drive. Additionally, the starship drives of the main shows and movies are anti-matter powered, which is in line with the energy requrements suggested here (smash 250 kilos each of matter and antimatter together, get 500kg-equivalent of energy).
I forget any technical details I ever may have known of Cochrane's ship's warp drive beyond the general details of it having a warp field and such. I'm not even sure if it was AM powered - but then, it flew only a very short distance at a "slow" (for ST warp drive) speed.
Also, you are of course welcome to hold your own opinions, but I personally think that First Contact wasn't bad at all. Not the best of Trek as an entire series (IMO), but generally considered one of the best movies by fans.
Although an outside observer would say that the light beam is travelling only very slightly faster than you, *you* would see the beam travel at exactly 1.0*c away from you. From your frame of reference, light in a vacuum *always* travels at this speed relative to its source.
The apparent discrepency is resolved by noting that at that speed, the time dialation you'd be experiencing is so great that after one second (as you experience it), the wave front of the light is one light-second ahead of your curent position. To an outside observer, one second after you turn on the light the wave front has progressed by one light-second from its initial position and you're only about 30m behind it... but that's because, to you, only a tiny fraction of that second has occurred yet.
By Dec 2011, WP7 had been out for just over a year. 5M in one year isn't very good for a smartphone, true. Now, consider that Nokia has sold 7M Lumia devices this year alone - putting them on track for at least 10M and probably more (consider the holiday season). That's just the Nokia WP7 devices; there are a lot of other manufacturers.
15M by the end of this year, even if we discount everything except the Lumia sales for this year, is 3% market share (possibly a bit less, since the market is growing) and 200% growth in a year. The Lumia 920 has garnered a *lot* of interest too; I expect that the sales rate of WinPhone will continue increasing.
Yeah, it'll take it quite a while to be a serious competitor to the established players... but then, Android launched with aalmost insignificant blip and relatively little growth until the release of the Droid and the huge amount of marketing that went into promoting it. Android surpassed iOS some time ago and has gone on growing since, but they're not unassailable.