Thank you for a voice of sanity and reason. The fact that you can embed COM objects in the latest version of Silverlight does nothing to harm Silverlight on other platforms; it simply means that if you (as a developer) are willing to limit yourself to Windows users, you can now embed third-party controls written in C++ into your desktop app (what a bizarre concept, I know...) If you want portability, you don't use this feature (any more than if a Java developer wants portability, he doesn't rely on a native code module that does registry I/O).
I don't know where they are in terms of language support (not great, if Acid3 is any indication), but IE8's JavaScript engine was a massive step up from IE7's and an even more massive step up from IE6. It's more standards-compliant (i.e. less incorrect behavior), implements more of the spec (not necessarily any of the newest changes to the spec, but more of the language as a whole), and is much, much faster than before.
Don't get me wrong, it's still way behind the other big-name browsers, but claiming 9 years since MS updated the javascript engine is a bald-faced lie.
Moonlight. From the same folks who brought you Mono (and sharing much of the code), Moonlight is a free, open-source implementation of Silverlight runnable on Linux, *BSD, and so forth. It's under pretty heavy development, and like Mono itself tends to lag somewhat behind the MS version (unsurprisingly), but it's usable for many of the things that require Silverlight.
As somebody who has frequently participated in beta tests of lots of software, including Microsoft's, this is spot-on. Sure, their infrequent betas get some good feedback and some good bug reports, but they also get absolutely drowned in a deluge of people on the discussion boards (newsgroups, actually) who complain about: A) Nothing particular at all, they just signed on to complain. B) Stuff that's completely unrelated to the beta (such as a complaint about IE6 on the IE8 beta discussion) C) Stuff that's completely unrelated to the product (complaints about Excel on the IE8 board) D) "How dare Microsoft release [a beta of] this product with such-and-such [known, sometimes in release notes] bug!" E) "WTF I installed the latest version of X, and now I can't access my Y, so I'm switching to competitor Z and never buying anything Microsoft again!" F) Complaints about Beta 1 bugs during Beta 2 or RC test phases. G) Complaints from people who installed the software on a production machine, and expect Microsoft to provide support for it.
These are the types of morons that Microsoft has to deal with. I've seen some of this type of behavior in other betas, to be sure, but some of the problems, especially D, E, and G, are most common on the MS betas. People just seem to expect that any code from MS will be production-ready and expects the company to stand behind their software as though it were a released product.
Microsoft would be *insane* to release nightly builds to a group like that. A closed beta nightly program, maybe (participants culled from those who are actually useful and productive on the public beta) but certainly not open. Especially considering point F above; people already can't always keep up with the pace of the infrequent releases, and asking them to identify the build number they're using would be an exercise in futility for far too many.
I'd also like to point out that while exoplanets are obviously relevant to people seeking extraterrestrial life, they are scientifically interesting in other ways too. They can suggest things about the history or future of our solar system, and about star systems in general. Additionally, the more we learn about them, the easier it becomes to find additional ones, and the easier it is to create and test hypotheses about them.
From the title, you'd expect that these telescopes were listening for signals that the SETI folks spend so much time decoding, or something of that nature. I suppose searches for distant planets and distant dark matter don't make sufficiently "strange bedfellows" for a proper/. headline, though.
It's worth noting that Google isn't actually under any obligation to keep Chrome/Chromium open-sourced. Just because they released a version (for desktop web browsing) that is F/OSS doesn't mean they can't later close it, or simultaneously release another version (for netbooks on their custom OS) that is closed-source. They own the copyrights; they can use whatever license (including proprietary) that they want. The only things they can't do are close somebody else's code (Linux kernel, WebKit, etc.) or retroactively change the license on the stuff that they've already released (though they could state that as of tomorrow, all further development of Chrome will be proprietary).
Sorry, not really relevant to the article, but it bothers me when people arbitrarily assign the GPL powers it doesn't have. That's exactly the kind of idiocy that makes commercial vendors leery of using it.
Considering that historically the NSA has improved cryptographic implementations against attacks that were (at the time) unknown to the public, I'd say that's almost certainly BS. For example, DES. Even when their modifications appeared to be weakening the encryption algorithm, once the algorithm was a standard and other parties got around to hunting weaknesses for it, it was found that the modified version (which had become the standard) was far more resistant to attack. Turns out the attack had been known but kept secret, yet the algorithm had been modified to make the attack weaker.
TL;DR: No, the NSA uses their extensive cryptanalysis knowledge to take backdoors *out* of encryption, rather than to put them in. Remember: we (the US, including the government) use it too, and enemy forces might stumble upon any backdoor they leave/put in place.
the difference is that Microsoft, by default, has traditionally made all accounts Admin, and a lot of software vendors have come to depend on that so making a Limited user is an exercise in deep frustration in Windows
The first part of your statement above isn't actually true. Windows has always made the *first* account an Administrator, but upon creating subsequent accounts it strongly urges you to make them standard users (and has that option selected by default). The problem is that most Windows installations just use the default account and never create another, even if multiple people share the computer.
The second part is quite true, although with some clever tweaking of file/folder/registry security settings it's less of an issue. Still, going from XP (standard user) to Vista (UAC) was a major step forward in terms of ease of use and user-friendliness (so many things on XP just inexplicably fail for non-admins).
I suspect you can mess around with user rights in Windows to give much finer grained capability permission
While slightly beyond what I expect a normal user to get, this is very true. Got a game which insists on storing user data in its install folder? Change the permissions on that folder (or preferably only on the files that need changing, or whatever). You can also use Deny permissions to block off access to certain files/folders/registry keys for specific users/groups, even if they would normally have enough permissions to access the protected item.
I've tweaked UAC to behave very nicely for me - new installs or changing system settings still requires approval, but programs that run on a regular basis do so just fine.
Interesting that they mention a browser which will run on Maemo, but neglect tin include MicroB (the browser that *comes* with Maemo). To be fair, until the N900 is in stores around here (is it even available internationally yet?) we don't really have a modern Maemo-running phone to test it on, but still.
MicroB supports flash, and does it well. Low RAM and CPU meant that complex applets took a while to load, but things like Pandora were perfectly usable, and YouTube looked pretty good. The last version of MicroB I tried was built on the same rendering engine as Firefox 2.0 (Gecko 1.6? I forget) and as such didn't do splendidly on Sunspider or Acid3 (or even Acid2) but it beat the hell out of IE6 (the Trident 6 engine is apparently what Microsoft decided to use for IE Mobile on the latest version of WinMo; don't ask me why). This was a couple years ago, though; I'm sure they could have updated to a newer rendering engine.
Mark poster as Foe (the little silver orb takes you to the Change Relationship page). Set a modifier on Foe (-6) that guarantees they'll never appear at over -1, and ignore any post with the little red orb. If you want, you can even adjust the modifiers so that any other post will never go below zero, and then only read things at 0 or above.
Yes, it enforces a "no tolerance" policy for people being completely out of line. I don't see this as such a disadvantage.
QT3 and QT4 have substantial API differences - the amount of effort to port a KDE3 app to QT4 would be far above what you are implying. While I agree with the intentions of your post, and strongly support backward compatibility, you might as well be asking for GNOME to be ported to KDE4. It could happen, and there are people already considering going about it, but it's a massive undertaking that won't bear fruit any time soon and will only ever see the light of day in enough people care (which right now, they don't... KDE4 apps, even in the 4.3 release, do lack some things that 3.5.x has... but they also have some things 3.5.x lacks, and most 4.3 users seem fairly content with their feature-sets).
This is going to sound weird, but if your version of Windows supports it, Remote Desktop may solve the problem. You can specify the size of the RD window, and a full-screen application running on the server's remote session will treat that as the maximum display resolution (meaning your graphics card should be able to stretch StarCraft to a 1280x960 RD window happily enough).
Technically this even works for 3d-accelerated games (the DirectX commands are sent across the network and executed on the client's GPU) but for something as old as StarCraft that won't even matter.
The catch is that client (non-server) versions of Windows don't allow you to RD from computer X into computer X again, so you'd need to have another computer somewhere with StarCraft installed, preferably located on a LAN.
Virtualization should also work just fine, especially since there's no risk of 3D acceleration stuff being a problem with games that old. If you have Win7 (Business or higher), you don't even need to install a second copy of Windows yourself; just install Virtual XP mode, have it start in a window (rather than the rootless mode usually used) and set the window's size appropriately.
.NET Micro is intended to run on embedded systems which may not even have an OS kernel, let alone a complete network stack. Thus Microsoft needed a lot more than just wrappers for the socket API (which is essentially what normal.NET does); if.NET Micro supports TCP/IP on such devices, it's because Microsoft implemented the protocols within the framework directly.
Or rather, it sounds like a third party implemented IP and TCP in the.NET Micro framework, and thus Microsoft doesn't come complete control over the license on that code.
It's also worth noting that just because the source is C# doesn't mean the binary is bytecode. It's completely possible to compile C# to native code (.NET does this just before execution normally, but you can do it in advance if you want). When targeting an embedded microcontroller, I doubt that emitting bytecode is even an option - you select the platform and the compiler produces assembly which goes to an assembler for that platform and gives you a native binary. Sure, it costs you write-once-run-anywhere, but in practice that isn't why people use C# - they use it because it's a very easy language to quickly write highly verifiable code in. Rapid application development, not portability, is its killer feature.
Close, but still too high-level. You're confusing the Compact framework (WinCE/WinMO, primarily) with the Micro framework, which is intended to run directly on embedded devices that may not even have an OS kernel (i.e. the program runs on the hardware with no abstraction). It will run on CPUs far less powerful than a modern ARM chip such as you find in a smartphone, and requires only a fraction of a megabyte of total storage.
That said, MS open-sourcing this isn't going to hurt projects like Mono in any way - just don't be too sure it will help. This version of.NET is really better thought of as a SDK for putting C# code on a microcontroller, rather than as a full-blown runtime that sits on top of an operating system (say what you will about WinCE, it's a hell of a lot more OS than your watch, for example, has).
True, and for that matter, Microsoft's command-line build tools (compilers, libraries, etc.) are also available free of charge. Visual Studio is nice, but you can just as easily write.cs files in Notepad.exe and compile them manually, or perhaps with the help of Microsoft's makefile parser (also included in the SDK).
Most of KDE4 has actually been ported to Windows as native binaries (using qt4, which is open-source across all platforms). http://windows.kde.org/ . Still very much a work in progress, but many things (like Kate, possibly my favorite text editor) work great. It has a simple graphical package management tool that allows you to select the KDE packages you want, update them, or uninstall them (and will automatically grab dependencies for you).
For other Unix-y programs, I've found that the native POSIX support in NT is good enough that quite a few programs simply compile and run without a problem. You'll need to install Interix (operating environment for the POSIX subsystem of NT) and its build toolchain (GCC based, though you can use the Microsoft build tools instead if you want). You'll probably also want to grab some of the nice pre-compiled binaries (such as bash, subversion, X11R7 libraries, and gcc4) from the SUA Community folks. Lots of info on this here: http://suacommunity.com/
In theory, you could actually compile KDE on Interix. Not sure anybody has put in the effort though; porting something that size is sure to run into hassles.
Poor WiFi? Hmm... I have a laptop that has run openSuse since 10.0, and over the last couple of releases the WiFi works even while installing (and no, it's not a liveCD, just a graphical installer program). I was able to download updates and such before the OS was actually installed.
Intel Pro Wireless 802.11abg, I forget the exact chipset designation.
Actually, one of the major advantages of Yast is that it has an excellent NCurses-based terminal interface, which works beautifully over ssh. Easiest distro to remotely manage that I've ever tried (also, back in the day, easiest one to fix on the occasion that a graphics driver update made X stop working).
For those who don't know, Yast is basically the configuration tool for *everything* - repository and package management, network configuration, video driver configuration, user accounts, runlevel and login behavior, configuring a hypervisor, re-partitioning, managing GRUB... basically, it's a centralized management tool. It's graphical and designed for user-friendliness, with help info for every setting, but it will also display the relevant config files and allow you to edit them manually too. I've actually found it useful when trying to learn the format of a given config file, since Yast's help info + comparing the options on the graphical display with the generated config file = an easy way to learn the format and options of a config file.
It's worth pointing out that this was not in any way an actual recruiting tour. I'm sure it interested some people who may now go apply, but there was nobody from HR there, and nobody was taking resumes or discussing internships. Instead, Mundie was basically traveling through several leading universities to talk with administrators, faculty, students, and the general public. The big presentation (in the linked video) is the "general public" one; although much of the audience was connected with UW in some way, many were not. The meeting with students (of whom I was one) was much smaller (10 of us) and more of a roundtable discussion (mostly consisting of us asking Mundie questions and him answering them, with occasional small reversals of that).
He said the purpose of the tour was to see what students were thinking about, and where they saw technology going in the future.
Project Natal was actually part of the demonstration. Not only in its current form (no, Mundie did not get up and play a game of 3D-Breakout using his hands as paddles, but he showed a video of it from, IIRC, E3) but also as a PC input device; using gestures in open air to do things like manipulate a 3D model in a CAD program.
I wouldn't want that to become the *primary* input means, but it certainly makes sense as an option for certain types of input.
First off, I wouldn't call it a recruiting tour. Nobody was taking resumes. Nobody from HR was present. There were no references to internships or other openings. Heck, I spoke to Mundie in person before the talk, attended the talk, and attended the reception afterwards, and nobody (Mundie or anybody else) made any reference at all to recruitment.
Second, the people who were laid off were not Microsoft's engineers and programmers, but instead were people in fields such as marketing and legal affairs. They've never stopped hiring new programmers, a fact which has been made clear on every occasion that the layoffs were discussed.
My point is that it would have taken a package maintainer a moment to fix../configure --use-sudo (I think that was the option; been a while since I tried building KDE from scratch) && make Obviously either nobody had filed a bug (meaning nobody had tested it at all, since you'll probably hit a privilege elevation dialog pretty quickly after an installation) or this high-impact, low-complexity bug had simply been completely ignored.
Hmm, interesting (and logical). This was several years back, on a KDE 3.5 system, but I'm pretty sure that it was called kdesu.
This was somebody who, aside from our school's Linux lab computers (which we don't get any root privileges on anyhow), had never used Linux and wanted to install it on their own system. It was not a pleasant experience.
Slashdot Mirror
Thank you for a voice of sanity and reason. The fact that you can embed COM objects in the latest version of Silverlight does nothing to harm Silverlight on other platforms; it simply means that if you (as a developer) are willing to limit yourself to Windows users, you can now embed third-party controls written in C++ into your desktop app (what a bizarre concept, I know...) If you want portability, you don't use this feature (any more than if a Java developer wants portability, he doesn't rely on a native code module that does registry I/O).
I don't know where they are in terms of language support (not great, if Acid3 is any indication), but IE8's JavaScript engine was a massive step up from IE7's and an even more massive step up from IE6. It's more standards-compliant (i.e. less incorrect behavior), implements more of the spec (not necessarily any of the newest changes to the spec, but more of the language as a whole), and is much, much faster than before.
Don't get me wrong, it's still way behind the other big-name browsers, but claiming 9 years since MS updated the javascript engine is a bald-faced lie.
Moonlight. From the same folks who brought you Mono (and sharing much of the code), Moonlight is a free, open-source implementation of Silverlight runnable on Linux, *BSD, and so forth. It's under pretty heavy development, and like Mono itself tends to lag somewhat behind the MS version (unsurprisingly), but it's usable for many of the things that require Silverlight.
Download link (may also be in repositories): http://www.go-mono.com/moonlight/
Download for development version (2 beta 8): http://go-mono.com/moonlight-beta/
Project page (including links to source): http://www.mono-project.com/Moonlight
As somebody who has frequently participated in beta tests of lots of software, including Microsoft's, this is spot-on. Sure, their infrequent betas get some good feedback and some good bug reports, but they also get absolutely drowned in a deluge of people on the discussion boards (newsgroups, actually) who complain about:
A) Nothing particular at all, they just signed on to complain.
B) Stuff that's completely unrelated to the beta (such as a complaint about IE6 on the IE8 beta discussion)
C) Stuff that's completely unrelated to the product (complaints about Excel on the IE8 board)
D) "How dare Microsoft release [a beta of] this product with such-and-such [known, sometimes in release notes] bug!"
E) "WTF I installed the latest version of X, and now I can't access my Y, so I'm switching to competitor Z and never buying anything Microsoft again!"
F) Complaints about Beta 1 bugs during Beta 2 or RC test phases.
G) Complaints from people who installed the software on a production machine, and expect Microsoft to provide support for it.
These are the types of morons that Microsoft has to deal with. I've seen some of this type of behavior in other betas, to be sure, but some of the problems, especially D, E, and G, are most common on the MS betas. People just seem to expect that any code from MS will be production-ready and expects the company to stand behind their software as though it were a released product.
Microsoft would be *insane* to release nightly builds to a group like that. A closed beta nightly program, maybe (participants culled from those who are actually useful and productive on the public beta) but certainly not open. Especially considering point F above; people already can't always keep up with the pace of the infrequent releases, and asking them to identify the build number they're using would be an exercise in futility for far too many.
I'd also like to point out that while exoplanets are obviously relevant to people seeking extraterrestrial life, they are scientifically interesting in other ways too. They can suggest things about the history or future of our solar system, and about star systems in general. Additionally, the more we learn about them, the easier it becomes to find additional ones, and the easier it is to create and test hypotheses about them.
From the title, you'd expect that these telescopes were listening for signals that the SETI folks spend so much time decoding, or something of that nature. I suppose searches for distant planets and distant dark matter don't make sufficiently "strange bedfellows" for a proper /. headline, though.
It's worth noting that Google isn't actually under any obligation to keep Chrome/Chromium open-sourced. Just because they released a version (for desktop web browsing) that is F/OSS doesn't mean they can't later close it, or simultaneously release another version (for netbooks on their custom OS) that is closed-source. They own the copyrights; they can use whatever license (including proprietary) that they want. The only things they can't do are close somebody else's code (Linux kernel, WebKit, etc.) or retroactively change the license on the stuff that they've already released (though they could state that as of tomorrow, all further development of Chrome will be proprietary).
Sorry, not really relevant to the article, but it bothers me when people arbitrarily assign the GPL powers it doesn't have. That's exactly the kind of idiocy that makes commercial vendors leery of using it.
Considering that historically the NSA has improved cryptographic implementations against attacks that were (at the time) unknown to the public, I'd say that's almost certainly BS. For example, DES. Even when their modifications appeared to be weakening the encryption algorithm, once the algorithm was a standard and other parties got around to hunting weaknesses for it, it was found that the modified version (which had become the standard) was far more resistant to attack. Turns out the attack had been known but kept secret, yet the algorithm had been modified to make the attack weaker.
TL;DR: No, the NSA uses their extensive cryptanalysis knowledge to take backdoors *out* of encryption, rather than to put them in. Remember: we (the US, including the government) use it too, and enemy forces might stumble upon any backdoor they leave/put in place.
the difference is that Microsoft, by default, has traditionally made all accounts Admin, and a lot of software vendors have come to depend on that so making a Limited user is an exercise in deep frustration in Windows
The first part of your statement above isn't actually true. Windows has always made the *first* account an Administrator, but upon creating subsequent accounts it strongly urges you to make them standard users (and has that option selected by default). The problem is that most Windows installations just use the default account and never create another, even if multiple people share the computer.
The second part is quite true, although with some clever tweaking of file/folder/registry security settings it's less of an issue. Still, going from XP (standard user) to Vista (UAC) was a major step forward in terms of ease of use and user-friendliness (so many things on XP just inexplicably fail for non-admins).
I suspect you can mess around with user rights in Windows to give much finer grained capability permission
While slightly beyond what I expect a normal user to get, this is very true. Got a game which insists on storing user data in its install folder? Change the permissions on that folder (or preferably only on the files that need changing, or whatever). You can also use Deny permissions to block off access to certain files/folders/registry keys for specific users/groups, even if they would normally have enough permissions to access the protected item.
I've tweaked UAC to behave very nicely for me - new installs or changing system settings still requires approval, but programs that run on a regular basis do so just fine.
Interesting that they mention a browser which will run on Maemo, but neglect tin include MicroB (the browser that *comes* with Maemo). To be fair, until the N900 is in stores around here (is it even available internationally yet?) we don't really have a modern Maemo-running phone to test it on, but still.
MicroB supports flash, and does it well. Low RAM and CPU meant that complex applets took a while to load, but things like Pandora were perfectly usable, and YouTube looked pretty good.
The last version of MicroB I tried was built on the same rendering engine as Firefox 2.0 (Gecko 1.6? I forget) and as such didn't do splendidly on Sunspider or Acid3 (or even Acid2) but it beat the hell out of IE6 (the Trident 6 engine is apparently what Microsoft decided to use for IE Mobile on the latest version of WinMo; don't ask me why). This was a couple years ago, though; I'm sure they could have updated to a newer rendering engine.
Mark poster as Foe (the little silver orb takes you to the Change Relationship page). Set a modifier on Foe (-6) that guarantees they'll never appear at over -1, and ignore any post with the little red orb. If you want, you can even adjust the modifiers so that any other post will never go below zero, and then only read things at 0 or above.
Yes, it enforces a "no tolerance" policy for people being completely out of line. I don't see this as such a disadvantage.
QT3 and QT4 have substantial API differences - the amount of effort to port a KDE3 app to QT4 would be far above what you are implying. While I agree with the intentions of your post, and strongly support backward compatibility, you might as well be asking for GNOME to be ported to KDE4. It could happen, and there are people already considering going about it, but it's a massive undertaking that won't bear fruit any time soon and will only ever see the light of day in enough people care (which right now, they don't... KDE4 apps, even in the 4.3 release, do lack some things that 3.5.x has... but they also have some things 3.5.x lacks, and most 4.3 users seem fairly content with their feature-sets).
This is going to sound weird, but if your version of Windows supports it, Remote Desktop may solve the problem. You can specify the size of the RD window, and a full-screen application running on the server's remote session will treat that as the maximum display resolution (meaning your graphics card should be able to stretch StarCraft to a 1280x960 RD window happily enough).
Technically this even works for 3d-accelerated games (the DirectX commands are sent across the network and executed on the client's GPU) but for something as old as StarCraft that won't even matter.
The catch is that client (non-server) versions of Windows don't allow you to RD from computer X into computer X again, so you'd need to have another computer somewhere with StarCraft installed, preferably located on a LAN.
Virtualization should also work just fine, especially since there's no risk of 3D acceleration stuff being a problem with games that old. If you have Win7 (Business or higher), you don't even need to install a second copy of Windows yourself; just install Virtual XP mode, have it start in a window (rather than the rootless mode usually used) and set the window's size appropriately.
.NET Micro is intended to run on embedded systems which may not even have an OS kernel, let alone a complete network stack. Thus Microsoft needed a lot more than just wrappers for the socket API (which is essentially what normal .NET does); if .NET Micro supports TCP/IP on such devices, it's because Microsoft implemented the protocols within the framework directly.
Or rather, it sounds like a third party implemented IP and TCP in the .NET Micro framework, and thus Microsoft doesn't come complete control over the license on that code.
It's also worth noting that just because the source is C# doesn't mean the binary is bytecode. It's completely possible to compile C# to native code (.NET does this just before execution normally, but you can do it in advance if you want). When targeting an embedded microcontroller, I doubt that emitting bytecode is even an option - you select the platform and the compiler produces assembly which goes to an assembler for that platform and gives you a native binary. Sure, it costs you write-once-run-anywhere, but in practice that isn't why people use C# - they use it because it's a very easy language to quickly write highly verifiable code in. Rapid application development, not portability, is its killer feature.
Close, but still too high-level. You're confusing the Compact framework (WinCE/WinMO, primarily) with the Micro framework, which is intended to run directly on embedded devices that may not even have an OS kernel (i.e. the program runs on the hardware with no abstraction). It will run on CPUs far less powerful than a modern ARM chip such as you find in a smartphone, and requires only a fraction of a megabyte of total storage.
That said, MS open-sourcing this isn't going to hurt projects like Mono in any way - just don't be too sure it will help. This version of .NET is really better thought of as a SDK for putting C# code on a microcontroller, rather than as a full-blown runtime that sits on top of an operating system (say what you will about WinCE, it's a hell of a lot more OS than your watch, for example, has).
True, and for that matter, Microsoft's command-line build tools (compilers, libraries, etc.) are also available free of charge. Visual Studio is nice, but you can just as easily write .cs files in Notepad.exe and compile them manually, or perhaps with the help of Microsoft's makefile parser (also included in the SDK).
Most of KDE4 has actually been ported to Windows as native binaries (using qt4, which is open-source across all platforms). http://windows.kde.org/ . Still very much a work in progress, but many things (like Kate, possibly my favorite text editor) work great. It has a simple graphical package management tool that allows you to select the KDE packages you want, update them, or uninstall them (and will automatically grab dependencies for you).
For other Unix-y programs, I've found that the native POSIX support in NT is good enough that quite a few programs simply compile and run without a problem. You'll need to install Interix (operating environment for the POSIX subsystem of NT) and its build toolchain (GCC based, though you can use the Microsoft build tools instead if you want). You'll probably also want to grab some of the nice pre-compiled binaries (such as bash, subversion, X11R7 libraries, and gcc4) from the SUA Community folks. Lots of info on this here: http://suacommunity.com/
In theory, you could actually compile KDE on Interix. Not sure anybody has put in the effort though; porting something that size is sure to run into hassles.
Poor WiFi? Hmm... I have a laptop that has run openSuse since 10.0, and over the last couple of releases the WiFi works even while installing (and no, it's not a liveCD, just a graphical installer program). I was able to download updates and such before the OS was actually installed.
Intel Pro Wireless 802.11abg, I forget the exact chipset designation.
Actually, one of the major advantages of Yast is that it has an excellent NCurses-based terminal interface, which works beautifully over ssh. Easiest distro to remotely manage that I've ever tried (also, back in the day, easiest one to fix on the occasion that a graphics driver update made X stop working).
For those who don't know, Yast is basically the configuration tool for *everything* - repository and package management, network configuration, video driver configuration, user accounts, runlevel and login behavior, configuring a hypervisor, re-partitioning, managing GRUB... basically, it's a centralized management tool. It's graphical and designed for user-friendliness, with help info for every setting, but it will also display the relevant config files and allow you to edit them manually too. I've actually found it useful when trying to learn the format of a given config file, since Yast's help info + comparing the options on the graphical display with the generated config file = an easy way to learn the format and options of a config file.
Nice link, thanks.
It's worth pointing out that this was not in any way an actual recruiting tour. I'm sure it interested some people who may now go apply, but there was nobody from HR there, and nobody was taking resumes or discussing internships. Instead, Mundie was basically traveling through several leading universities to talk with administrators, faculty, students, and the general public. The big presentation (in the linked video) is the "general public" one; although much of the audience was connected with UW in some way, many were not. The meeting with students (of whom I was one) was much smaller (10 of us) and more of a roundtable discussion (mostly consisting of us asking Mundie questions and him answering them, with occasional small reversals of that).
He said the purpose of the tour was to see what students were thinking about, and where they saw technology going in the future.
Project Natal was actually part of the demonstration. Not only in its current form (no, Mundie did not get up and play a game of 3D-Breakout using his hands as paddles, but he showed a video of it from, IIRC, E3) but also as a PC input device; using gestures in open air to do things like manipulate a 3D model in a CAD program.
I wouldn't want that to become the *primary* input means, but it certainly makes sense as an option for certain types of input.
First off, I wouldn't call it a recruiting tour. Nobody was taking resumes. Nobody from HR was present. There were no references to internships or other openings. Heck, I spoke to Mundie in person before the talk, attended the talk, and attended the reception afterwards, and nobody (Mundie or anybody else) made any reference at all to recruitment.
Second, the people who were laid off were not Microsoft's engineers and programmers, but instead were people in fields such as marketing and legal affairs. They've never stopped hiring new programmers, a fact which has been made clear on every occasion that the layoffs were discussed.
My point is that it would have taken a package maintainer a moment to fix. ./configure --use-sudo (I think that was the option; been a while since I tried building KDE from scratch) && make
Obviously either nobody had filed a bug (meaning nobody had tested it at all, since you'll probably hit a privilege elevation dialog pretty quickly after an installation) or this high-impact, low-complexity bug had simply been completely ignored.
Hmm, interesting (and logical). This was several years back, on a KDE 3.5 system, but I'm pretty sure that it was called kdesu.
This was somebody who, aside from our school's Linux lab computers (which we don't get any root privileges on anyhow), had never used Linux and wanted to install it on their own system. It was not a pleasant experience.