Especially if those automated software deployment packages like SCCM are Microsoft products.

Thanks for the bug report :)

Those shiny distributed file systems run on top of boring local filesystems.

Tux3 is a better design. Tux2 was more along the lines of ZFS and Btrfs, that is, multiply-rooted trees sharing subtrees. Tux3 is a single tree with exactly one pointer to each extent. Considerably easier to check and repair. Of course we need to see if it turns out that way so please stay tuned.

Indeed, different aims. Tux3 has the modest goal of being a light, tight and fast filesystem without ambition of also being a volume manager.

Even if such a platform exists, how does that preclude Microsoft from suing? Remember that the thesis here is that Microsoft would disregard the licenses already granted for C#, .NET Framework, compilers etc and just sue to exhaust your funds. Why couldn't they claim that you infringed an algorithm (or whatever) even if you were using Java or Python? After all, they have no legal standing but are considered *so* malicious that they will sue even when they have no legal standing.

The whole "Microsoft will sue!" is nothing but FUD.

In reality - because of the promissory estoppel of the community promise - users of .NET and any other technology under the community promise is much better protected than when using alternatives. This is because the promissory estoppel can be used to dismiss a lawsuit outright.

None. Zero. Zilch.

I guess it depends on what you're doing, doesn't it? If you're trying to provide Microsoft Sharepoint access to Microsoft Office documents to users or Microsoft Exchange email access, then, yes, it probably is cheaper and quicker to do it with Microsoft stuff. It's a pretty ludicrous claim to say that the TCO of Linux is higher than Microsoft unless you are also clear about what your company expects your IT to do... If you're just trying to use Linux to emulate Windows, then of course that's probably a waste of time and resources.

$client = new-object System.Net.WebClient
$client.DownloadFile( $url, $path )

Probably works on Powershell 2 however I think it requires the .NET framework installed. Powershell wasn't that good until later versions. I have to say, current versions are actually extraordinarily powerful, when working with other Microsoft technologies, like Hyper-V or Exchange but the early versions were no reason to leave VBScript.

Ha! I'd give you mod points for that if I could. That's the first time I have ever tried to post using the new Beta interface on a mobile and it munted the link badly.

http://technet.microsoft.com/en-us/library/hh849901.aspx is the link.

That requires powershell 3. Prior to that you could use: System.Net.WebClient but the Invoke-WebRequest is far easier.

http://technet.microsoft.com/e... Using an old version of powershell?

Invoke-WebRequest http://www.google.com/ -OutFile c:\google.html

This does not make sense to me at all. While I agree that's the way they should have taken (IMHO using MVVM instead of MVC), it is almost exactly the way they took. They didn't have all the ducks in row at the first iteration, but it was the plan all the way. They said so at the time.

You did not belive the FUD about Microsoft abandoning .NET did you? .NET is very, very much in the game. At /Build// Microsoft just announced Universal Apps.

MSDN has documentation

With universal apps you build one app for phone, tablets and laptops/desktops. The same app can share views and viewmodels (MVVM) across the form factors, or they can have completely different view/viewmodels. A view/viewmodel can also "adapt" to the formfactor - showing only primary and essential information on phones, more on tablets and include secondary/tertiary information on desktops.

When deployed, the universal apps are deployed as IL/CLR code. When a device installs an app, the cloud service will perform the compilation and serve a native app to the device, compiled for the architecture, memory requirements and core count. The delivery system will only serve resources used by the specific device, i.e. even if the universal app is distributed with extensive resources for desktop users, the package that is downloaded to a phone will strip those resources.

Metro was never mutually exclusive with .NET. Microsoft made plenty of blunders both with their messaging on Metro as well as the initial Dr. Jekyll-and-Hyde two-personality Windows 8. But they have been consistent on their messaging on .NET and apps.

No they haven't. You just do not want slashdot readers to read them, because they do not say what you claim.

http://www.internetnews.com/de...

Quote from that article:

GP is correct, those who took a look at it indeed came away with the impression that it was quite pristine.

You, OTOH, are just lying.