You don't know how bad I want to attach a Citation Needed to that. Most of Microsoft's contributions have been fixing their other ones, along with threat of patent suits....
Because of course, Linux and other OSS is bug free. :bang: Software is big and complex stuff. There will be bugs in any codeset over a certain size, unless using one of the languages specifically designed to be tested through mathematical analysis to determine there are no bugs.
If you use an IDE it's likely trivial software will also have bugs as that software will draw on other common libraries. The issue in software development for me is not if the software has bugs. It's how those bugs are managed. I think over all GNU/Linux distributors do a better job of documenting and managing bugs.
That's a pretty bold statement. Who are the Microsoft engineers contributing to Linux? What did they contribute? Were they working for Microsoft when they made the contribution? Are they active package maintainers or have they abandoned their work? I ask these questions because there are only three projects right now that come to mind where Microsoft may have had a hand in things. One is the virtualisation code Microsoft was forced to release or face court action for copyright infringement. The other is Samba. And with Samba It think it was more consultation and information sharing rather than actual coding. Which Microsoft also had to be dragged kicking and screaming into. The third is Mono. Which was pushed by Novell SuSE developers and has now been hived off into it's own unique organisation that's hanging around in limbo. Mono for those who don't know is a Linux compatible implementation of .Net. Which has in turn often been called a Microsoft rip-off of Java. But then again the same could be said for Python or any other recently developed cross-platform language.
It was well publicised a few weeks ago. I think they were doing a lot of work on Hyper V, so yes, they were working for Microsoft at the time, which is a big deal if you consider it in the light of a growing spirit of cooperation between the two OSs. As above, I think most of it was the virtualisation module, but those legal issues didn't mean they had to continue to throw resources at it. It's not 100% selfless, but it is still a lot of code and a big step forward compared to the Microsoft/Linux relationship that existed only a few years ago. .NET has little relation to Java, so I'll assume you are referring to C#. They certainly started off similar, but C# has changed a lot in its 4 (soon to be 5) versions. Frankly, it's a much nicer language than Java, nowadays. None of this changes the fact that slamming something simply because it's Microsoft is a stupid reason for criticism. How many of the new features of Windows 8 will start to leak out into Linux distributions over the next 5 years? The honest answer would be 'all of the good ones'.
Growing spirit of co-operation? LOL! Ok. Microsoft had no choice but to release the Hyper-V code. It also had little choice in maintaining the code and sorting bugs. Given that Linux is so ubiquitous in data-centres these days it's every bit in Microsoft's interest to have Windows run as smoothly as possible on top of Linux and have Linux run as smoothly as possible on top of Windows. That's just plain business strategy. Without that work Microsoft was facing total obscurity in the data centre. It takes years to develop something like a really good virualisation hypervisor. If Microsoft had ditcher Hyper-V and started from scratch they'd have been a good decade or more behind the field. Microsoft really only had one option no matter which way they chose to spin it. Hyper-V incidentally didn't make Linux a viable OS. It was already the server OS of choice long before Hyper-V came along. It is and it isn't. People make judgements based on past experience. So those who have had bad experiences will typically form an understandable negative and dismissive point of view. But mostly it's just ore fun. Version 5 will likely be the last if Microsoft gets it way. Was that sarcasm? Which good features are you talking about? I'm genuinely interested. I've seen Windows 8. From what I can fathom this Metro nonsense is the only major new feature. Aside from the fact Microsoft are demanding PCs come with UEFI secure boot enabled by default. Metro is just a sort of tiling window manager that seems to be either part of Windows main window manager, a new front end of IE or an unholy union between IE and the taskbar. I'm currently leaning towards the IE/taskbar unholy union. The reason being Metro can be switched off and the Windows 7 taskbar restored with a registry tweak. The Apps Metro runs are nothing more than HTML5 wrapped in a special Metro application wrapper similar to the way many iOS and Android applications work. Which is similar to how Google used to implement it's applications on Linux before it went native. So Metro effectively already exists in the Linux world. I also consider the concept to be similar to Clutter. Which has been in development since Android rumours first surfaced and has made it's way into main stream Linux products already. What Metro does show us is exactly why Microsoft considered leverageing the power of the GPU in a web browser to be so important. From what I've seen of Windows 8 thus far. It's just another version of Vista with a new skin and not worth the likely asking price. I don't yet see that it has any compelling features over Windows XP, Vista or 7. Sorry didn't mean to make that post so long
Microsoft want developers to concentrate on Metro and ditch the old APIs. I don't know how much the bloggers and reporters have been over hyping the situation. But apparently Microsoft pretty much said it in as many words at their developer events where Metro was first shown off. And apparently developers aren't happy. With every major Windows release Microsoft have broken their APIs or ditched them completely in favour of something new.
You can code Metro with C#. The WPF developers are probably a bit unhappy...or at least the bad ones are. Good developers understand that technologies come and go. Hitching your wagon to any one technology is always a stupid idea. Metro is an opportunity.
Metro is an opportunity for more people to write more nonsense applications. Or to have all your stuff held hostage in the "cloud". The success of Metro I think will really depend on how well it serves corporate users. What it does definitely bring to the table is a version of desktop Windows with decent touch screen functionality. All be it limited to the Metro interface. I think though Microsoft may have bitten the tablet bug in a fatal way. They seem to be trivialising the uses for tablets and PCs by ignoring their core corporate user base.
That is very open to debate. In terms of support and resolving bugs, I've always had much more success working with Microsoft than open-source communities. There are some who near match a commercial distributor for service (Nagios, Smoothwall) but in general they are not particularly responsive. First three articles I found (plenty more, but couldn't be bothered looking through). - http://www.theregister.co.uk/2010/04/01/microsoft_open_source_gm/ - http://www.networkworld.com/news/2011/030111-microsoft-php-opensource.html - http://www.ciozone.com/index.php/Op...ource-Contributions-Not-Merely-a-Gesture.html Then you've also got one of the largest open-source project sites in existence, funded and run by Microsoft and with many projects set up by Microsoft employees and engineers (codeplex). Hmm. You obviously don't follow a huge number of projects. See the articles above, and codeplex. :bang: .Net isn't a language in the first place. It's a collection of APIs in a model which allows them to be used in multiple languages so that everything can run on a single platform (C#, VB.NET, F#, IronPython, and so forth). Do you actually do any coding? Java derives from C and C++, which both predate it by a long way. Stunningly C# is a new iteration of the C language concept, so amazingly it is similar to java. Shocking that languages taken from the same root language might have similarities. Must mean it's a rip-off. .Net meanwhile is a language-agnostic API library and programming model which can be used to provide standardised data exchange between code modules written in different languages. We should take note that they started off similarly because Java was derived from C, which predates it by over a decade, rather than the other way around. But Microsoft must be evil! They have patents! (paraphrase from an iPhone using fanatical OSS monkey) Actually, since Microsoft have their own distribution of Linux as well as close ties to various other commercial distributors of Linux, they could easily have kept the code limited only to commercial entities. It wouldn't have touched their business as anyone capable of building a decent datacentre will be using one of the main Linux distributions. They had several different options. Many places stick with Microsoft server platforms for the ease of administration and the fact that training/expertise is cheap, very much so compared to Linux. These places aren't going to be sold on RHEL or ESXi unless they're made as easy and standardised as the Microsoft solutions, not to mention as tightly integrated across the platform (the System Center software platform is effective out of the box and easy to customise - the various solutions you need to get the same integration and functionality out of OSS require huge amounts of customisation and time). No. Linux was the web server of choice. This is not even remotely the same thing as being the server of choice. As an example - your average corporation will be using Microsoft servers for almost all of their internal networks. So that'll be Exchange, CRM, AD, File sharing, SharePoint, SCOM, SCSM, SCCM, SCVMM and so forth. They may also use a Linux server to host their website. Honestly, your comments on languages really don't suggest much in the way of past experience with either Microsoft or other programming languages. I noticed this story about the secure boot complaints. I just want to make quite sure that I understand - all the OSS monkeys who usually whine about how insecure Windows is and how super-protected their own systems are, are complaining about an incredibly effective boot-time security feature and demanding that it not be used (even though Microsoft are recommending that it be optional to turn on or off)? A little more than that - they only put this restoration in after enough end-user whining, same reason they've had to go back on new technologies before, the end-users are whiny. Well, there's also Silverlight being used which provides a little more than HTML5. As for the Clutter project, I really don't see why you're comparing an interface to a software library. You seem to have trouble making distinctions between the two, but to try and help you could potentially compare Clutter to Silverlight, or indeed to HTML5. Or would actually sticking to reasonable comparisons not allow you to complain as much? Unsurprising, given that so far it's a tech demo - and they've not announced it as anything more than that.
I quoted Clutter because it's the basis of several desktop Linux interfaces. Gnome Shell uses Mutter as it's window manager which is based Clutter as do several other interfaces. It's Clutter that brings the comparable feature set. The complaint about UEFI secure boot isn't so much that it's being used. It's the way Microsoft are leverageing it and basically forcing OEMs and ODMs to use it. The fear is GNU/Linux OSs will be frozen out of the market if there is no option to disable the secure boot function.
Nonsense programs appear in every language, on every framework and on every platform. Most corporate stuff is moving to the web anyway. Microsoft know that. You need to have a really good reason to justify building an enterprise desktop application nowadays.
Clutter is still a software library - a fair comparison would be Silverlight rather than a particular single interface. I could equally say that clutter is nothing but a rip-off of WinForms, or any other library for interface building. Oh dear. Evil Microsoft, how dare they try and encourage OEMs to include an optional secure boot option which might inconvenience the supposedly more security-conscious OSS community. It's completely up to OEMs whether or not to include a disable option. Microsoft aren't pressuring them to implement signed boot in a particular way, just to implement it. OEMs who do not make it optional will lose business against those who do, therefore the smart OEMs will make it optional. It's pretty much a storm in a teacup mixed with a touch of conspiracy theory. I keep on hearing people say this, and I suppose it's possible that it's true, but I've yet to see any sign of it happening. Some stuff is going towards web-based - particular tasks which are well-suited to it - but other roles are best fulfilled by the workstation model rather than the mainframe model which web-based involves. This may change, but it'll require a lot more bandwidth and much more reliable services.
My company is currently in the process of costing up a project that will replace the last remaining piece of desktop software we develop. Obviously, that's anecdotal, but I'm struggling to think of very many cases where a web based solution doesn't do the job at least as well as a desktop solution.
No they are forcing OEMs to implement secure boot by default. It's a requirement of the Windows 8 logo program. Which large OEMs will clearly want to be a part of. They just love designing awesome looking kit and then spoiling it with a dozen irrelevant tacky stickers. I think it's more likely companies will build privet "clouds" rather than actually use the web. Which functions are best done on the workstation model?
Since I work in network administration, my requirements are probably a little difference so my view is skewed. Microsoft do not force OEMs to be part of their logo programs. OEMs choose to be part of the logo programs. There's no coercion in place here, and you still haven't addressed what's wrong with a secure boot - particularly if OEMs do the sensible thing and allow it to be disabled. Bear in mind that many OEMs offer a choice of operating system on their hardware. If they are doing that, then they are either going to need a signed version of Linux to offer Linux (which is feasible, it's just that the OSS fanatics say it'll involve too much work and they shouldn't have to do it anyway) or to be able to disable the secure boot. Still not seeing why any of this is a problem - except for the paranoia from the OSS fanatics of course. Most software development (deploying to a lab environment for testing/debugging is fine, but a lot of the time you just want to quickly run something locally and don't want to risk it getting out), anything involving large amounts of data processing on locally generated data (bandwidth limitations), anything involving secure/privileged information, systems administration (yes, having a management service is great, but when it goes down you need a local system which can still plug into things and carry out recovery). Just a few examples. Also - anything where you want to mitigate risk. The cloud model, as has been shown by a nice set of high-profile failures, is vulnerable to catastrophic collapse. If my workstation crashes and takes a day to bring back up, I've lost a day of work (8 hours), probably less with central storage and a decent re-imaging system. If on the other hand my LOB server providing a service for 200 people collapses, stutters, or even goes into failover and takes ten minutes to come back up, then I've just lost 33 hours for the company.
When you consider modern networks, bandwidth considerations are pretty insignificant for all but the biggest datasets. You can toss the data up into your server, have the server carry out the processing and pull the results back to the client. In a lot of cases, you can get that done a lot faster than if it were happening locally (particularly when the processing is complex and needs the additional power provided by a cluster etc) The cloud model is by its nature, highly resilient to failure. That's the true cloud at least. The faux cloud (a few servers hitched together and labelled 'the cloud') is of course significantly less resilient. And in many of those cases, particularly in a corporate environment, the client on the desktop is still hooked up to a central data server, which is prone to the exact same reliability issues, so you're not getting any of those resiliency benefits of locally held software. Your 200 people might be able to access the software, but there'll be no data for the software to access.
