Wow, you both fail reading comprehension and basic knowledge about the industry.
MSR work goes into a *lot* of Microsoft products. Everything from little improvements to crypto techniques (which are still often huge news in the relevant community), to significant features like grammar checking, to full-fledged products (Surface is the best-known at present, but not only; for example MSR also delevoped the game Allegiance which was somewhat before its time but open-sourced when it wasn't a commercial success).
Also, if MS is "only interested in product crap" then why does so much of MSR's work end up in use? Why do they release cool new stuff like Kinect? If MS is "maintaining a monopoly at any cost" then why do they support projects like Mono or develop ways to run Linux better inside their hypervisor? Why would they bother with things like Bing, when they don't have anywhere near a monopoly on search?
It's a matter of convenince. There are more C++ libraries than.NET libraries, but that doesn't make it convenint to find or use a good game framework that provides the libraries you need and isn't a pain to use. XNA isn't a language, but it is a framework aimed specifically at developing games, and from what I've seen it's very good at that. It's based on.NET, and typically used with C#. Thus, for game development, XNA (and.NET) is a good choice because it largely avoids the "I need to find/write code that does X" and "I need to integrate this piece of code that does X with the other piece of code that does Y" problems.
There's nothing inherently wrong developing a game in C++, but it's a lot easier to do it if you start with the XNA framework (with the.NET language of your choice, possibly even C++).
There's also the ZuneHD, which while hardly a runaway success has nonetheless competed with some success for a year or so. It doesn't have the iOS glut of apps, but it deos support third-party apps and have a marketplace. The hardware is better than on the 43it, too, with a much better touchscren and things like HD Radio capability.
For the record, recent Windows versions won't even install on FAT32, so it doesn't really count. In fact, it's becoming encreasingly difficult to even format a drive as FAT32 from the GUI, which makes sense as removable drives are becoming large enough that it's worth using a more advanced filesystem.
Also, the main difference between ReadyBoost and just using flash storage for swap is SuperFetch, the (admittedly marketingly named) feature that caches data before you're expected to need it. Most caching schemes are reactive; "oh, you needed this so I'll hold onto it in case you need it again" or even "Oh, while grabbing this I'll grab this other things next to it in case you want that too." This works fairly well for most real-world cases, and works very nicely for most servers, but fails ina couple major ways on the desktop. The most obvious one is long application start times; if a program hasn't been run (recently) it has to all be fetched from disk when the user requests to run it.
Superfetch gets around that pretty smartly, by tracking application usage by various chronological triggers ("shortly after I start the computer" or "7 PM every weekday" or "11 AM on Saturday" or "pretty often but on no actual schedule, just whenever.") It then can figure out what to load before you (the user) ask for it. Obviously there's a training time, during which you don't get this benefit, but it can make some fairly sharp assumptions pretty quickly, and refine them over time. It's possibly to reset this training if you want to, although practically speaking it adapts to changes in your habits well enough.
The other (and actually more important) difference between ReadyBoost and what you described is that ReadyBoost is *NOT* swap. It doesn't represent memory mappings at all. This is vital, because it's created with the assumption that at some point the user will do something stupid like yank the media out without unmounting it, or remove it between putting the computer to sleep and waking it again. Doing those with swap could have horrible effects, from simple application crashes through to data loss or even disk corruption, if the OS operates on the assumption that once written to swap, data is *always* retrievable until overwritten. Besides, most removable media writes slowly, making a poor choice for swap, but reads quickly, making it ideal as a look-ahead cache for disk reads.
The thing that concerns me about all this "little ice age" business is what happens when it *ends* and we've been keeping temperatures artificually high through the greenhouse effect. Sure, that might make for a relatively nice few decades or evena century or two of what should be cold weather, but it will also mean skyrocketing temperatures once insolation (energy from the sun) returns to normal levels. What will we do then?
NT has been ported to a lot of architectures other than Alpha. In fact, there's a currently supported (though being phased out) port to Itanium, which is nothing like x86 despite coming from the same company.
The problem is that it does cost money to maintain ports, and therefore Microsoft won't do it unless they make more than it costs. Itanium has not been a great success, and is falling behind rapidly now, which is why it's being abandoned. Alpha went through something very similar, in a much shorter time-frame, during its heyday: a shiny new architecture with awesome capabilities and a Windows NT port that ran great, but the chip itself was not a commercial success (my personal understanding is that DEC screwed up the pricing and marketing, targeting only very expensive systems rather than commoditizing the CPU). Without sufficient financial incentive to keep it around, MS dropped the ARM port.
So far, ARM seems to be going the opposite direction. It's been around for a long time, but is only starting to be taken seriously for general-purpose computers. It's low-cost and already very commoditized, and PC OS developers are starting to look at it with interest as it becomes powerful enough to be relevent in a general-purpose PC. Because there's a ready-made market niche for it (low-power and low-cost systems, possibly portable and/or touchscreen based), adoption will probably be pretty quick (unlike many other non-x86 architectures of the past).
Do a clean reinstall. The difference, in terms of performance, install footprint, memory usage, boot time, and stability between an OEm image and a clean install is astounding. Vista had much the same problem - it actually would run happily on a 1.8GHz machine with 1280MB of RAM, far below the "unofficial minimum requirement," if you did a clean install. Win7 is better still.
Woth the last laptop I bought (from HP), the initial bootup of the OEM image, where it configures a dozen GB of crappy bundled software, took longer than the entire proces of formatting the disk, installing Windows cleanly, booting, and running through the standard out-of-box experience and configuration.
In any case, something aiming for a small, cheap and low-powered ARM device probably wouldn't run an OS intended for a primary home PC or a workstation. "Porting Windows to ARM" doesn't mean running Win7 on an ARM device. It means making sure that the kernel, userspace APIs, core libraries, and important apps (IE counts, Office might, Media Center probably doesn't) can be run on whatever the new trend in computing hardware leads to.
Microsoft ports software to hardware that will sell it. They aren't discontinuing Itanium support because they don't take it seriously, they're discontinuing Itanium support because the industry doesn't take it seriously, and therefore doesn't buy it, which makes it kind of pointless to sell software for it. Notice anything interesting about the architectures you mentioned? None of them are used in PCs or workstations anymore, and most of them haven't been in years (a decade or more, for many).
I have a friend who still bemoans the death of NT on Alpha, but even he - a Linux-using guy who avoids Microsoft stuff to the point of not even having Wine installed - says it was DEC's fault, not Microsoft's. They insisted that Alpha only go in high-end (expensive) systems, and that strategy was not commercially viable. If they'd made it a commodity PC platform, Microsoft woul have been happy to continue providing software for that platform.
ARM, by comparison, is a very up-and-comping PC architecture for low-power or highly-portable systems. The tech industry wants to buy ARM chips, and they're going to need software to run on them. That's where MS comes in. Also note x64, which is rapidly outpacing x86 in the conventional PC world, and which is strongly supported by MS to the point that they're releasing native versions of Office and such for it even though it can run the x86 versions fine.
Um, where does it say anything about porting Windows 7 (from anybody who knows the difference between a kernel and a colonel)? They're porting *NT* to ARM, and that makes all kinds of sense. For example, it lets the move WinPhone7 off of CE (which, despite all the work that has gone into it, is still an inferior kernel in many ways) and onto NT (much like Apple did with XNU/iOS, or Google with Linux/Android).
This frees up resources from developing and maintaining WinCE, and adds a lot of capabilities to WP7 at the same time. Hell, they might even release a native SDK at that point; if they've been planning to do this all along it makes sense to not publicly offer native apps on a platform that is going to have its kernel swapped out in a year or three.
Also, who ever said they aren't using that nice touch interface? Microsoft could put a WP7-style interface on a much larger device. Remember, this isn't about Windows 7, it's about future products. There's no reason a Metro-style UI couldn't run on NT, either on a phone/PDA-style device, or a much larger tablet/touchscreen computer.
IE already runs on ARM. WinPhone7 runs an (outdated) version of desktop IE, and will run IE9 in an upcoming update..NET framework was ported to ARM long ago; in the Windows Mobile/PocketPC days. Silverlight is the application runtime for Windows Phone 7, so it's fair to say it run on ARM. A browser plugin form of it for that platform is also forthcoming. Office itself already runs on ARM, again on WinPhone7. The degree of control you can exert over documents is limited (mostly a UI problem), but it will happily read them.
MSIL doesn't convert anything. It's the code that gets converted. MSIL (more commonly called CIL, for Common Intermediate Language, now that Mono is a working non-MS implementation) is analogous to Java bytecode.
What does get converted (using a Just-In-Time compiler) is CIL to native code. Typically, this native code is x86 or x64, but there are already JIT compilers for ARM as well. After the JIT completes, the result is saved locally so the overhead is only encountered once.
As for Win32 calls, there's no "conversion" at all. What happens is that after the CIL gets compiled to native code, it links into libraries (native DLLs) that implement functions for the OS (such as Win32 calls). For example, if a.NET function calls System.IO.File.Create(), when that code is run, a managed code function gets called, and it in turn calls an unmanaged function in the linked library. That library makes the necessary translation into the native API (let's say Win32 on NT), resulting in an unmanaged call to CreateFile(), which in turn goes into the Win32 user subsystem library and gets translated into a NtCreateFile() system call, which is sent to the kernel.
If you're on another platform, such as Linux, WinCE, OS X, or other, on any architecture at all, the only difference is that you need to write a library that has the same public interface (System.IO.File.Create()) and calls the correct native function on its own platform (open(), for example). The.NET API is large, so it's not trivial to write this layer, but there's nothing specific to Win32 or x86 about it. Mono has already done this (works on Linux, *BSD, OS X, and even Windows) and so has Microsoft (for WinCE).
As for pure torture, have you contacted the Mono devs recently to express your sympathy?
Dude, I've seen a *phone* run Office on ARM (and a WinCE kernel, but it could be ported to NT without so much trouble). You even brought it up yourself - WinPhone7. It's a limited version of Office, but it handles reading and writing the document format just fine; the rest is UI. Office also runs (well, ran) on PowerPC (Mac), and as with phones, the only maor difference is UI. What the hell makes you think it's not portable?
You have a valid point about apps, at least for un-managed code.
Re:Okay, here's a question ...
on
New IE Zero Day
·
· Score: 1
This year? No. Next year? Sure.
Make their account a limited user account only. Change the admin password, and don't tell him/her what it is. Enable the Remote Assistance feature just in case it's absolutely necessary. Set anti-virus to be updated automatically, and make the schedule locked to anybody but admin. In fact, turn off all AV controls to non-admins except for "run a scan now." MSE can do this, by the way. Do the same for Windows Update (force it on, don't let a non-admin turn it off).
Works best on Vista or Win7, though it's possible to use XP or 2000 as a limited user too (just more annoying). Giving a non-techie Admin on an Internet-connected box makes about as much sense as giving a Linux newbie a root login; it's easier to do everything, most notably shooting yourself in the foot.
Expect to get some calls related to "I need to install X" and be ready to handle them. Note that one advantage of this approach is that you can handle them by educating your relative about things that really should *NOT* get installed.
Windows Mobile (PocketPC) malware (Trojans, specifically) have nothing at all to do with Windows Phone 7. The application runtimes are completely different, and application sideloading is very limited on WP7 anyhow (which I personally dislike, but which nonetheless makes Trojans rather difficult to spread). There was definitely malware for WinMo, but that's a dying platform. Besides, any OS that allows users to install/run arbitrary software will have Trojans; it's happened to every significant platform including "secure" ones like OS X and Linux. WinPhone7 might be exploitable - no information on that yet - but it's not going to be easy to install a Trojan.
Nah, lots of residential ISPs will do contract plans too, with early termination fees and upgrade schedules and all that fun garbage. It's not yet mandatory where I live - you can still get month-to-month, though you either have to pay more or switch to inferior service - but a few years ago it didn't even exist, and lately it's becoming more common. The numbers are too thin to call it a trend (there only being a few providers at all) but it's happening.
How many of those are just re-selling other company's offerings? For a while here we could get DSL via Qwest or Verizon, but the Verizon was just re-sold Qwest.
That said, I suppose I'm lucky to have three options, sort of:
Comcast, which becomes unusable under weekend congestion. Clear, which usally works at least 22 hours a day (or 5 of any 6 hours I'm at my home computer) Qwest, which won't provide fiber-to-the-door here but will happily charge as much as FiOS for something that's not too much worse (~8 of a nominal 12 Mbps, with ~860 Kbps upload).
I'm in Seattle, a few minutes from Microsoft, Amazon, and a bunch of other tech companies.
First of all, acquiring the docs may be esionage, but posting them online is not. This has been discussed many times. Wikileaks does the latter, not the former. Second, you make a false analogy (which severely damages your credibility). The government is not a private citizen, and does not have a citizen's rights to privacy. Third, you can't subpoena what you don't know about. Did you know our government was kidnapping innocent German citizens and holding them for months without trial? Fourth, what enforces your ability to subpoena the government? The government has broken any number of its own laws; what makes you think they haven't broken this one? Fifth, you simultaneously bring up government secrets and arguments against Wikileaks with government transparency and free speech. Do you not see the contradiction?
I didn't know that about Twitter, but... how many levels deep will it nest that? I could easily have run this link through 5 different ULR shorteners, and ended up with one that still resulted in a DDoS. Of course, each redirect takes time, but it's still pretty easy to trick somebody.
Linux programming could have included CS, but doesn't necessarily do so. The rest (aside from other senior projects) is definitely IT, not CS.
I'm beginning to realize how lucky I was to have AP CS at my high school. The class itself wasn't a great environment due to the monkeys who just wanted an AP class on their transcripts and probably didn't use "memory" for both hard disks and RAM on a regular basis, but the curriculum and professor were fairly good. The class focused a bit too much on practice rather than theory - we learned how to do a simple linked list in Java, but not much on when we should use a linked list vs. an arraylist, and none on why. It was enough to cement what I wanted to study in college though, and was probably the only "first class of the day" course I took before university that I generally looked forward to.
Agreed about the heart of CS being AMath, but there's a non-trivial portion that creeps over from EE as well. I'll probably never design an ALU again, and while reading assembly is required for my job I generally avoid the binary representation if possible, but I know what it does and if necessary I could implement a simple x86 (we used MIPS in class) on a FPGA. You can be an excellent CS theorist and a decent programmer without knowing what the hardware is doing on at least an abstract level, but there are some fields that are definitely part of CS (compilers, security, and operating systems) where a level of knowledge that goes even past boolean logic is almost necessary today.
Of course, you could argue that it should be called "computer engineering" which is what my degree actually says, but the difference between the CS and CompE programs (this at one of the nation's top CS programs) was simply a matter of required courses, the majority of which were outside of the major (College of Arts and Sciences vs. College of Engineering). The in-major courses for both degrees were drown from a combined CSE department. CE had to take more implementation classes in the department including at least one capstone project course, an introductory course in analog EE, more hard science, and a college-required technical communication sequence; CS required more theory classes but in general was less constrained within the department, and included things like a college-mandated foreign language requirement. With only a little extra effort (and very few electives) you could have satisfied the requirements for both in the normal time requirement for a single degree.
I don't know of any really good analysis, but it's supposed to use the same engine and definitions as MSE, just with enterprise management tools and business licensing. That may be enough of a basis.
The other option, of course, is to simply ask Microsoft. You'd have to take what they say with a grain of salt, obviously, but that doesn't mean that they wouldn't know where to find some great reviews and/or case studies. After all, they would have plenty of motivation.
A software monoculture of any kind (including Windows itself, though it helps that there are three major versions out right now) is more likely to be subject to widespread attack. In fact, this applies to most monocultures; too many of one type of crop will generally spawn a disease that destroys that one crap, for example.
However, I don't see Symantec, McAfee, or the rest (including the free alternatives) disappearing any time soon, especially not down to Linux or even OS X-level market shares. MSE may eventually hurt itself with its own success, but not soon.
Also, Microsoft is already trying to reduce software monoculture as much as possible through better technology. For example, Address Space Layout Randomization makes it far harder to create a successful worm, because each computer loads its libraries at a different base address, making return-to-libc or return-oriented-programming attacks much more difficult. Even though it's the same software, the malware that works perfectly on one machine will fail with a harmless crash on another even if they are the exact same hardware and software versions. I'm not sure how to reduce monoculture in an antivirus program, but I'm sure people at MS are aware of the issue.
I am too, but in all honesty that's why I tend to use Windows for gaming. I'm not claiming that you *should* buy one or the other, just pointing out that if "supporting Linux" (distinct from "supported on Linux") is important to you, then go with AMD over nVidia if all else is sufficiently equal.
Well, the tower itself will be ridiculously hot, so I don't think many birds would voluntarily get near it. It's not like you cross a threshold and suddenly fry, it's more like walking toward a large fire. You'll feel uncomforatble long before it's actually dangerous, and if you keep approaching you're probably doing your species a favor.
The energy reflected from the mirrors isn't inherently dangerous. In any given beam, you'll get twice the solar energy that is expected; the normal part fromt he sun plus the reflected beam. This won't be fun to stand in on an already hot desert day, but it's not like you're walking through a high-powered microwave beam or something.
Slashdot Mirror
Wow, you both fail reading comprehension and basic knowledge about the industry.
MSR work goes into a *lot* of Microsoft products. Everything from little improvements to crypto techniques (which are still often huge news in the relevant community), to significant features like grammar checking, to full-fledged products (Surface is the best-known at present, but not only; for example MSR also delevoped the game Allegiance which was somewhat before its time but open-sourced when it wasn't a commercial success).
Also, if MS is "only interested in product crap" then why does so much of MSR's work end up in use? Why do they release cool new stuff like Kinect? If MS is "maintaining a monopoly at any cost" then why do they support projects like Mono or develop ways to run Linux better inside their hypervisor? Why would they bother with things like Bing, when they don't have anywhere near a monopoly on search?
It's a matter of convenince. There are more C++ libraries than .NET libraries, but that doesn't make it convenint to find or use a good game framework that provides the libraries you need and isn't a pain to use. XNA isn't a language, but it is a framework aimed specifically at developing games, and from what I've seen it's very good at that. It's based on .NET, and typically used with C#. Thus, for game development, XNA (and .NET) is a good choice because it largely avoids the "I need to find/write code that does X" and "I need to integrate this piece of code that does X with the other piece of code that does Y" problems.
There's nothing inherently wrong developing a game in C++, but it's a lot easier to do it if you start with the XNA framework (with the .NET language of your choice, possibly even C++).
There's also the ZuneHD, which while hardly a runaway success has nonetheless competed with some success for a year or so. It doesn't have the iOS glut of apps, but it deos support third-party apps and have a marketplace. The hardware is better than on the 43it, too, with a much better touchscren and things like HD Radio capability.
For the record, recent Windows versions won't even install on FAT32, so it doesn't really count. In fact, it's becoming encreasingly difficult to even format a drive as FAT32 from the GUI, which makes sense as removable drives are becoming large enough that it's worth using a more advanced filesystem.
Also, the main difference between ReadyBoost and just using flash storage for swap is SuperFetch, the (admittedly marketingly named) feature that caches data before you're expected to need it. Most caching schemes are reactive; "oh, you needed this so I'll hold onto it in case you need it again" or even "Oh, while grabbing this I'll grab this other things next to it in case you want that too." This works fairly well for most real-world cases, and works very nicely for most servers, but fails ina couple major ways on the desktop. The most obvious one is long application start times; if a program hasn't been run (recently) it has to all be fetched from disk when the user requests to run it.
Superfetch gets around that pretty smartly, by tracking application usage by various chronological triggers ("shortly after I start the computer" or "7 PM every weekday" or "11 AM on Saturday" or "pretty often but on no actual schedule, just whenever.") It then can figure out what to load before you (the user) ask for it. Obviously there's a training time, during which you don't get this benefit, but it can make some fairly sharp assumptions pretty quickly, and refine them over time. It's possibly to reset this training if you want to, although practically speaking it adapts to changes in your habits well enough.
The other (and actually more important) difference between ReadyBoost and what you described is that ReadyBoost is *NOT* swap. It doesn't represent memory mappings at all. This is vital, because it's created with the assumption that at some point the user will do something stupid like yank the media out without unmounting it, or remove it between putting the computer to sleep and waking it again. Doing those with swap could have horrible effects, from simple application crashes through to data loss or even disk corruption, if the OS operates on the assumption that once written to swap, data is *always* retrievable until overwritten. Besides, most removable media writes slowly, making a poor choice for swap, but reads quickly, making it ideal as a look-ahead cache for disk reads.
The thing that concerns me about all this "little ice age" business is what happens when it *ends* and we've been keeping temperatures artificually high through the greenhouse effect. Sure, that might make for a relatively nice few decades or evena century or two of what should be cold weather, but it will also mean skyrocketing temperatures once insolation (energy from the sun) returns to normal levels. What will we do then?
NT has been ported to a lot of architectures other than Alpha. In fact, there's a currently supported (though being phased out) port to Itanium, which is nothing like x86 despite coming from the same company.
The problem is that it does cost money to maintain ports, and therefore Microsoft won't do it unless they make more than it costs. Itanium has not been a great success, and is falling behind rapidly now, which is why it's being abandoned. Alpha went through something very similar, in a much shorter time-frame, during its heyday: a shiny new architecture with awesome capabilities and a Windows NT port that ran great, but the chip itself was not a commercial success (my personal understanding is that DEC screwed up the pricing and marketing, targeting only very expensive systems rather than commoditizing the CPU). Without sufficient financial incentive to keep it around, MS dropped the ARM port.
So far, ARM seems to be going the opposite direction. It's been around for a long time, but is only starting to be taken seriously for general-purpose computers. It's low-cost and already very commoditized, and PC OS developers are starting to look at it with interest as it becomes powerful enough to be relevent in a general-purpose PC. Because there's a ready-made market niche for it (low-power and low-cost systems, possibly portable and/or touchscreen based), adoption will probably be pretty quick (unlike many other non-x86 architectures of the past).
Do a clean reinstall. The difference, in terms of performance, install footprint, memory usage, boot time, and stability between an OEm image and a clean install is astounding. Vista had much the same problem - it actually would run happily on a 1.8GHz machine with 1280MB of RAM, far below the "unofficial minimum requirement," if you did a clean install. Win7 is better still.
Woth the last laptop I bought (from HP), the initial bootup of the OEM image, where it configures a dozen GB of crappy bundled software, took longer than the entire proces of formatting the disk, installing Windows cleanly, booting, and running through the standard out-of-box experience and configuration.
In any case, something aiming for a small, cheap and low-powered ARM device probably wouldn't run an OS intended for a primary home PC or a workstation. "Porting Windows to ARM" doesn't mean running Win7 on an ARM device. It means making sure that the kernel, userspace APIs, core libraries, and important apps (IE counts, Office might, Media Center probably doesn't) can be run on whatever the new trend in computing hardware leads to.
Microsoft ports software to hardware that will sell it. They aren't discontinuing Itanium support because they don't take it seriously, they're discontinuing Itanium support because the industry doesn't take it seriously, and therefore doesn't buy it, which makes it kind of pointless to sell software for it. Notice anything interesting about the architectures you mentioned? None of them are used in PCs or workstations anymore, and most of them haven't been in years (a decade or more, for many).
I have a friend who still bemoans the death of NT on Alpha, but even he - a Linux-using guy who avoids Microsoft stuff to the point of not even having Wine installed - says it was DEC's fault, not Microsoft's. They insisted that Alpha only go in high-end (expensive) systems, and that strategy was not commercially viable. If they'd made it a commodity PC platform, Microsoft woul have been happy to continue providing software for that platform.
ARM, by comparison, is a very up-and-comping PC architecture for low-power or highly-portable systems. The tech industry wants to buy ARM chips, and they're going to need software to run on them. That's where MS comes in. Also note x64, which is rapidly outpacing x86 in the conventional PC world, and which is strongly supported by MS to the point that they're releasing native versions of Office and such for it even though it can run the x86 versions fine.
Um, where does it say anything about porting Windows 7 (from anybody who knows the difference between a kernel and a colonel)? They're porting *NT* to ARM, and that makes all kinds of sense. For example, it lets the move WinPhone7 off of CE (which, despite all the work that has gone into it, is still an inferior kernel in many ways) and onto NT (much like Apple did with XNU/iOS, or Google with Linux/Android).
This frees up resources from developing and maintaining WinCE, and adds a lot of capabilities to WP7 at the same time. Hell, they might even release a native SDK at that point; if they've been planning to do this all along it makes sense to not publicly offer native apps on a platform that is going to have its kernel swapped out in a year or three.
Also, who ever said they aren't using that nice touch interface? Microsoft could put a WP7-style interface on a much larger device. Remember, this isn't about Windows 7, it's about future products. There's no reason a Metro-style UI couldn't run on NT, either on a phone/PDA-style device, or a much larger tablet/touchscreen computer.
IE already runs on ARM. WinPhone7 runs an (outdated) version of desktop IE, and will run IE9 in an upcoming update. .NET framework was ported to ARM long ago; in the Windows Mobile/PocketPC days.
Silverlight is the application runtime for Windows Phone 7, so it's fair to say it run on ARM. A browser plugin form of it for that platform is also forthcoming.
Office itself already runs on ARM, again on WinPhone7. The degree of control you can exert over documents is limited (mostly a UI problem), but it will happily read them.
Wow, you're wrong on so many levels!
MSIL doesn't convert anything. It's the code that gets converted. MSIL (more commonly called CIL, for Common Intermediate Language, now that Mono is a working non-MS implementation) is analogous to Java bytecode.
What does get converted (using a Just-In-Time compiler) is CIL to native code. Typically, this native code is x86 or x64, but there are already JIT compilers for ARM as well. After the JIT completes, the result is saved locally so the overhead is only encountered once.
As for Win32 calls, there's no "conversion" at all. What happens is that after the CIL gets compiled to native code, it links into libraries (native DLLs) that implement functions for the OS (such as Win32 calls). For example, if a .NET function calls System.IO.File.Create(), when that code is run, a managed code function gets called, and it in turn calls an unmanaged function in the linked library. That library makes the necessary translation into the native API (let's say Win32 on NT), resulting in an unmanaged call to CreateFile(), which in turn goes into the Win32 user subsystem library and gets translated into a NtCreateFile() system call, which is sent to the kernel.
If you're on another platform, such as Linux, WinCE, OS X, or other, on any architecture at all, the only difference is that you need to write a library that has the same public interface (System.IO.File.Create()) and calls the correct native function on its own platform (open(), for example). The .NET API is large, so it's not trivial to write this layer, but there's nothing specific to Win32 or x86 about it. Mono has already done this (works on Linux, *BSD, OS X, and even Windows) and so has Microsoft (for WinCE).
As for pure torture, have you contacted the Mono devs recently to express your sympathy?
Dude, I've seen a *phone* run Office on ARM (and a WinCE kernel, but it could be ported to NT without so much trouble). You even brought it up yourself - WinPhone7. It's a limited version of Office, but it handles reading and writing the document format just fine; the rest is UI. Office also runs (well, ran) on PowerPC (Mac), and as with phones, the only maor difference is UI. What the hell makes you think it's not portable?
You have a valid point about apps, at least for un-managed code.
This year? No. Next year? Sure.
Make their account a limited user account only.
Change the admin password, and don't tell him/her what it is.
Enable the Remote Assistance feature just in case it's absolutely necessary.
Set anti-virus to be updated automatically, and make the schedule locked to anybody but admin. In fact, turn off all AV controls to non-admins except for "run a scan now." MSE can do this, by the way.
Do the same for Windows Update (force it on, don't let a non-admin turn it off).
Works best on Vista or Win7, though it's possible to use XP or 2000 as a limited user too (just more annoying). Giving a non-techie Admin on an Internet-connected box makes about as much sense as giving a Linux newbie a root login; it's easier to do everything, most notably shooting yourself in the foot.
Expect to get some calls related to "I need to install X" and be ready to handle them. Note that one advantage of this approach is that you can handle them by educating your relative about things that really should *NOT* get installed.
Bullshit alert:
Windows Mobile (PocketPC) malware (Trojans, specifically) have nothing at all to do with Windows Phone 7. The application runtimes are completely different, and application sideloading is very limited on WP7 anyhow (which I personally dislike, but which nonetheless makes Trojans rather difficult to spread). There was definitely malware for WinMo, but that's a dying platform. Besides, any OS that allows users to install/run arbitrary software will have Trojans; it's happened to every significant platform including "secure" ones like OS X and Linux. WinPhone7 might be exploitable - no information on that yet - but it's not going to be easy to install a Trojan.
Nah, lots of residential ISPs will do contract plans too, with early termination fees and upgrade schedules and all that fun garbage. It's not yet mandatory where I live - you can still get month-to-month, though you either have to pay more or switch to inferior service - but a few years ago it didn't even exist, and lately it's becoming more common. The numbers are too thin to call it a trend (there only being a few providers at all) but it's happening.
How many of those are just re-selling other company's offerings? For a while here we could get DSL via Qwest or Verizon, but the Verizon was just re-sold Qwest.
That said, I suppose I'm lucky to have three options, sort of:
Comcast, which becomes unusable under weekend congestion.
Clear, which usally works at least 22 hours a day (or 5 of any 6 hours I'm at my home computer)
Qwest, which won't provide fiber-to-the-door here but will happily charge as much as FiOS for something that's not too much worse (~8 of a nominal 12 Mbps, with ~860 Kbps upload).
I'm in Seattle, a few minutes from Microsoft, Amazon, and a bunch of other tech companies.
So many things wrong here.
First of all, acquiring the docs may be esionage, but posting them online is not. This has been discussed many times. Wikileaks does the latter, not the former.
Second, you make a false analogy (which severely damages your credibility). The government is not a private citizen, and does not have a citizen's rights to privacy.
Third, you can't subpoena what you don't know about. Did you know our government was kidnapping innocent German citizens and holding them for months without trial?
Fourth, what enforces your ability to subpoena the government? The government has broken any number of its own laws; what makes you think they haven't broken this one?
Fifth, you simultaneously bring up government secrets and arguments against Wikileaks with government transparency and free speech. Do you not see the contradiction?
I didn't know that about Twitter, but... how many levels deep will it nest that? I could easily have run this link through 5 different ULR shorteners, and ended up with one that still resulted in a DDoS. Of course, each redirect takes time, but it's still pretty easy to trick somebody.
Not quite. Knowing what the site does, I probably wouldn't click that URL. Try something like http://bit.ly/eaHU1C instead.
Linux programming could have included CS, but doesn't necessarily do so. The rest (aside from other senior projects) is definitely IT, not CS.
I'm beginning to realize how lucky I was to have AP CS at my high school. The class itself wasn't a great environment due to the monkeys who just wanted an AP class on their transcripts and probably didn't use "memory" for both hard disks and RAM on a regular basis, but the curriculum and professor were fairly good. The class focused a bit too much on practice rather than theory - we learned how to do a simple linked list in Java, but not much on when we should use a linked list vs. an arraylist, and none on why. It was enough to cement what I wanted to study in college though, and was probably the only "first class of the day" course I took before university that I generally looked forward to.
Agreed about the heart of CS being AMath, but there's a non-trivial portion that creeps over from EE as well. I'll probably never design an ALU again, and while reading assembly is required for my job I generally avoid the binary representation if possible, but I know what it does and if necessary I could implement a simple x86 (we used MIPS in class) on a FPGA. You can be an excellent CS theorist and a decent programmer without knowing what the hardware is doing on at least an abstract level, but there are some fields that are definitely part of CS (compilers, security, and operating systems) where a level of knowledge that goes even past boolean logic is almost necessary today.
Of course, you could argue that it should be called "computer engineering" which is what my degree actually says, but the difference between the CS and CompE programs (this at one of the nation's top CS programs) was simply a matter of required courses, the majority of which were outside of the major (College of Arts and Sciences vs. College of Engineering). The in-major courses for both degrees were drown from a combined CSE department. CE had to take more implementation classes in the department including at least one capstone project course, an introductory course in analog EE, more hard science, and a college-required technical communication sequence; CS required more theory classes but in general was less constrained within the department, and included things like a college-mandated foreign language requirement. With only a little extra effort (and very few electives) you could have satisfied the requirements for both in the normal time requirement for a single degree.
I don't know of any really good analysis, but it's supposed to use the same engine and definitions as MSE, just with enterprise management tools and business licensing. That may be enough of a basis.
The other option, of course, is to simply ask Microsoft. You'd have to take what they say with a grain of salt, obviously, but that doesn't mean that they wouldn't know where to find some great reviews and/or case studies. After all, they would have plenty of motivation.
A software monoculture of any kind (including Windows itself, though it helps that there are three major versions out right now) is more likely to be subject to widespread attack. In fact, this applies to most monocultures; too many of one type of crop will generally spawn a disease that destroys that one crap, for example.
However, I don't see Symantec, McAfee, or the rest (including the free alternatives) disappearing any time soon, especially not down to Linux or even OS X-level market shares. MSE may eventually hurt itself with its own success, but not soon.
Also, Microsoft is already trying to reduce software monoculture as much as possible through better technology. For example, Address Space Layout Randomization makes it far harder to create a successful worm, because each computer loads its libraries at a different base address, making return-to-libc or return-oriented-programming attacks much more difficult. Even though it's the same software, the malware that works perfectly on one machine will fail with a harmless crash on another even if they are the exact same hardware and software versions. I'm not sure how to reduce monoculture in an antivirus program, but I'm sure people at MS are aware of the issue.
I am too, but in all honesty that's why I tend to use Windows for gaming. I'm not claiming that you *should* buy one or the other, just pointing out that if "supporting Linux" (distinct from "supported on Linux") is important to you, then go with AMD over nVidia if all else is sufficiently equal.
Well, the tower itself will be ridiculously hot, so I don't think many birds would voluntarily get near it. It's not like you cross a threshold and suddenly fry, it's more like walking toward a large fire. You'll feel uncomforatble long before it's actually dangerous, and if you keep approaching you're probably doing your species a favor.
The energy reflected from the mirrors isn't inherently dangerous. In any given beam, you'll get twice the solar energy that is expected; the normal part fromt he sun plus the reflected beam. This won't be fun to stand in on an already hot desert day, but it's not like you're walking through a high-powered microwave beam or something.