Yeah, AD does seem a little excessive in those situations, but on the other hand it is the kind of all-in-one solution that open source doesn't appear to easily offer at present. The biggest problem with AD in this situation is that, as far as I'm aware, the price doesn't scale down that far.
The weird thing that strikes me is that the project that MonoDevelop was originally based on, #develop on Windows, is pretty good, and they have comparable feature sets. Something has just never sat right with that IDE and me. I'm beginning to wonder if something based on Eclipse or NetBeans, mature systems as they are, might work a little better.
Still, though, the point remains. Unless the free alternative is just as easy to use for the task as the Windows one, the cost of Windows actually has to be really quite high before it starts to be cheaper to pay for the additional staff time to support the free solution. This is pretty much exactly how Microsoft can justify charging as much as they do. Of course, on top of this, there's the fact that many companies will choose paid support for the free solutions, which further mitigates the cost disparity.
Don't get me wrong, I think that the free solution can very often be the right one. But it's incredibly easy to forget just how much a person's time can cost relative to licensing fees.
Presumably you're only talking about the development tools (since open source implementations of XAML and.NET are available, and an open source version of Silverlight is on the way), but really if the technology is good enough open development tools should become available too. Just because Microsoft isn't providing them doesn't mean that it's impossible for them to exist.
I disagree with this; Mono is a great system which works extremely well (on Linux, at least - the OS X one is hampered by its not being made by Apple, as most stuff on that platform that isn't made by Apple is*). There's a reason a large number of newer Linux desktop projects use Mono.
The development tools for Mono, however, appear to suck hard compared to the.NET tools that are available on Windows.
* I know you've been comparing this with Java, but it's worth noting that Apple package and distribute (an altered version of) Java themselves, and getting the "vanilla" Java to work well on OS X isn't something that many people claim to have had a lot of success with. On the plus side Microsoft support Silverlight themselves on OS X so at least for this system it's not a problem anyway.
Dirac isn't production-ready, as far as I'm aware. Their FAQ indicates that the codec would not be suitable for the BBC's purposes until it's been further developed, although in the longer term it'd certainly be a good system to move to.
His discussion of running untrusted code in "prisons" is interesting, and I wonder what, if any, accomodation for this type of programming Windows has.
Windows Vista introduced Protected Mode for IE, which presumably does this sort of thing. I assume this sort of sandboxing can be applied to other processes too, but I've not looked into it.
How, exactly, is.NET bloated? Particularly considering what it provides?
low quality
.NET is not low-quality, and I don't recall any report of it ever being thought of as such.
error-prone
The whole VM-based typesafe language infrastructure thing isn't really error-prone. Quite the opposite, in fact.
semi-open standard
Very few people develop using the non-open parts, and they deserve what they get. The vast majority of useful features are open.
that contains references to proprietary (read as 'closed') MS information
Other than the aforementioned "non-open" components which it's silly to use (and don't work that well compared to their free alternatives anyway), I'm struggling to see where this is relevant.
In several situations MS has implied that MONO requires "patent protection"...
As far as I'm aware, very few widespread Mono apps actually use the components which are not obviously legally free. ASP.NET (XSP) is the only significant exception I can think of, and quite frankly I can only think of one common app which uses that, and it's not only a developer tool, it's available in an incarnation that doesn't need it.
The article summary is pretty accurate but it wouldn't apply to the case that you state there. This is something that can be done with mod_rewrite, although the obvious issue is whether it was done before, and whether it's an "obvious" use.
I seriously doubt that RICO or anti-trust will help, and the Amazon boycott by the FSF was abandoned years ago. Perhaps it'd have more effect now that open source is (even) more widely-known, but I wouldn't bet on it.
For what it's worth, that method seems to be entirely distinct from the method described in the patent, so it's probably safe from litigation. However, it also probably doesn't count as prior art.
El Lobo is a user who likes to troll Linux topics. He calls "Linux" "linuzzz". It's basically the same idea as the "Micro$haft", "Crapple" crowds, but with a different focus.
Does widespread trolling of Linux mean it is Ready For The Desktop, though? Only time will tell.
I'm pretty sure that here in Scotland — where the article is set — taxis already pay PRS royalties for the radio as well. I'm pretty sure I've seen a logo up in a taxi anyway.
Apple invested heavily in getting Swing to work right.
In my experience, the Apple Swing LAF is heavy and slow compared to that on other systems, actually. They seem to have wrapped their native widget set and put in a lot of layers of indirection to make the widgets behave like they should in Swing.
As for NetBeans being slower than Eclipse in general, I don't agree, although if you don't optimise it the garbage collection pauses can get very intrusive. I tend to have about 40 or more text buffers open at once, though, so hammering memory is to be expected.
NetBeans is an incredibly pleasant environment compared to Eclipse a lot of the time, but it does require some setup. The main configuration file has a set of "optimised" settings that are commented out; uncommenting these tends to make it as responsive as Eclipse.
Java on OS X with Swing widgets is often a pain because of Apple's Swing LAF implementation, though. It's heavier and much slower than Sun's implementation on other platforms.
Thanks for the clarification. That's a little stranger.
This is all quite annoying for me because the short, plain language of these licences is very attractive, it's just annoying they're not compatible with much else.
See, the license is GPL-incompatible. In fact it's about the most liberal GPL-incompatible license going, suggesting that the incompatibility is it's key feature.
This is an interesting point, yes. The other side of that coin, however, is that it's patent considerations (I think?) that make it incompatible, and Microsoft as a company have been trading a lot on the idea of patents recently, so this could also fit into that whole strategy.
"Shut up and show us the code" is the way these things go, though. The licence clearly qualifies as "open source", and if Microsoft and associated organisations actually contribute significant amounts of code in an open source form, that could overwhelm the downsides to the licence. The Apache Licence 2 is thought not to be GPLv2 compatible, either, but it still harbours a lot of (in particular more corporate) good code.
Tamarin is being integrated into Firefox for later versions (it's been open-sourced by Adobe) and so Pyro will get these advantages when that work is completed. There's no good reason to avoid doing work like this now just because optimisations in the back-end are not in place yet.
Well, yes, the argument that Windows users are less likely to install updates because they've been burned more frequently doesn't really pan out. But this basically backs up my original argument; that vulnerabilities for items which are going to be updated are not harmless in any way, shape, or form.
Many of the major Windows worms and so forth target vulnerabilities which have already been fixed (and the fixes pushed out) months before. Not only will many not upgrade to Leopard, if the OS X userbase is similar to the Windows userbase (I'm not sure if it is, but still), many will simply not click the button to install the updates, and leave themselves vulnerable.
Slashdot Mirror
Yeah, AD does seem a little excessive in those situations, but on the other hand it is the kind of all-in-one solution that open source doesn't appear to easily offer at present. The biggest problem with AD in this situation is that, as far as I'm aware, the price doesn't scale down that far.
The weird thing that strikes me is that the project that MonoDevelop was originally based on, #develop on Windows, is pretty good, and they have comparable feature sets. Something has just never sat right with that IDE and me. I'm beginning to wonder if something based on Eclipse or NetBeans, mature systems as they are, might work a little better.
Still, though, the point remains. Unless the free alternative is just as easy to use for the task as the Windows one, the cost of Windows actually has to be really quite high before it starts to be cheaper to pay for the additional staff time to support the free solution. This is pretty much exactly how Microsoft can justify charging as much as they do. Of course, on top of this, there's the fact that many companies will choose paid support for the free solutions, which further mitigates the cost disparity.
Don't get me wrong, I think that the free solution can very often be the right one. But it's incredibly easy to forget just how much a person's time can cost relative to licensing fees.
In the same way it'd be multiplatform if they used Java, I guess. CLR is an open standard.
Presumably you're only talking about the development tools (since open source implementations of XAML and .NET are available, and an open source version of Silverlight is on the way), but really if the technology is good enough open development tools should become available too. Just because Microsoft isn't providing them doesn't mean that it's impossible for them to exist.
I disagree with this; Mono is a great system which works extremely well (on Linux, at least - the OS X one is hampered by its not being made by Apple, as most stuff on that platform that isn't made by Apple is*). There's a reason a large number of newer Linux desktop projects use Mono.
The development tools for Mono, however, appear to suck hard compared to the .NET tools that are available on Windows.
* I know you've been comparing this with Java, but it's worth noting that Apple package and distribute (an altered version of) Java themselves, and getting the "vanilla" Java to work well on OS X isn't something that many people claim to have had a lot of success with. On the plus side Microsoft support Silverlight themselves on OS X so at least for this system it's not a problem anyway.
Dirac isn't production-ready, as far as I'm aware. Their FAQ indicates that the codec would not be suitable for the BBC's purposes until it's been further developed, although in the longer term it'd certainly be a good system to move to.
Windows Vista introduced Protected Mode for IE, which presumably does this sort of thing. I assume this sort of sandboxing can be applied to other processes too, but I've not looked into it.
Hmm.
How, exactly, is .NET bloated? Particularly considering what it provides?
.NET is not low-quality, and I don't recall any report of it ever being thought of as such.
The whole VM-based typesafe language infrastructure thing isn't really error-prone. Quite the opposite, in fact.
Very few people develop using the non-open parts, and they deserve what they get. The vast majority of useful features are open.
Other than the aforementioned "non-open" components which it's silly to use (and don't work that well compared to their free alternatives anyway), I'm struggling to see where this is relevant.
As far as I'm aware, very few widespread Mono apps actually use the components which are not obviously legally free. ASP.NET (XSP) is the only significant exception I can think of, and quite frankly I can only think of one common app which uses that, and it's not only a developer tool, it's available in an incarnation that doesn't need it.
The article summary is pretty accurate but it wouldn't apply to the case that you state there. This is something that can be done with mod_rewrite, although the obvious issue is whether it was done before, and whether it's an "obvious" use.
I seriously doubt that RICO or anti-trust will help, and the Amazon boycott by the FSF was abandoned years ago. Perhaps it'd have more effect now that open source is (even) more widely-known, but I wouldn't bet on it.
For what it's worth, that method seems to be entirely distinct from the method described in the patent, so it's probably safe from litigation. However, it also probably doesn't count as prior art.
El Lobo is a user who likes to troll Linux topics. He calls "Linux" "linuzzz". It's basically the same idea as the "Micro$haft", "Crapple" crowds, but with a different focus.
Does widespread trolling of Linux mean it is Ready For The Desktop, though? Only time will tell.
I'm pretty sure that here in Scotland — where the article is set — taxis already pay PRS royalties for the radio as well. I'm pretty sure I've seen a logo up in a taxi anyway.
In my experience, the Apple Swing LAF is heavy and slow compared to that on other systems, actually. They seem to have wrapped their native widget set and put in a lot of layers of indirection to make the widgets behave like they should in Swing.
As for NetBeans being slower than Eclipse in general, I don't agree, although if you don't optimise it the garbage collection pauses can get very intrusive. I tend to have about 40 or more text buffers open at once, though, so hammering memory is to be expected.
NetBeans is an incredibly pleasant environment compared to Eclipse a lot of the time, but it does require some setup. The main configuration file has a set of "optimised" settings that are commented out; uncommenting these tends to make it as responsive as Eclipse.
Java on OS X with Swing widgets is often a pain because of Apple's Swing LAF implementation, though. It's heavier and much slower than Sun's implementation on other platforms.
Honestly I find it hard to believe that this does not exist already. This is not an invitation to track it down and post links.
I'm personally bewildered by the very concept of pornography so computationally-complex that it requires extra CPU time.
Are you raytracing beads of sweat? Or trying to graph metrics for shame in real-time?
Thanks for the clarification. That's a little stranger.
This is all quite annoying for me because the short, plain language of these licences is very attractive, it's just annoying they're not compatible with much else.
This is an interesting point, yes. The other side of that coin, however, is that it's patent considerations (I think?) that make it incompatible, and Microsoft as a company have been trading a lot on the idea of patents recently, so this could also fit into that whole strategy.
"Shut up and show us the code" is the way these things go, though. The licence clearly qualifies as "open source", and if Microsoft and associated organisations actually contribute significant amounts of code in an open source form, that could overwhelm the downsides to the licence. The Apache Licence 2 is thought not to be GPLv2 compatible, either, but it still harbours a lot of (in particular more corporate) good code.
Tamarin is being integrated into Firefox for later versions (it's been open-sourced by Adobe) and so Pyro will get these advantages when that work is completed. There's no good reason to avoid doing work like this now just because optimisations in the back-end are not in place yet.
Well, yes, the argument that Windows users are less likely to install updates because they've been burned more frequently doesn't really pan out. But this basically backs up my original argument; that vulnerabilities for items which are going to be updated are not harmless in any way, shape, or form.
If only more Windows users were more sensible like this!
Many of the major Windows worms and so forth target vulnerabilities which have already been fixed (and the fixes pushed out) months before. Not only will many not upgrade to Leopard, if the OS X userbase is similar to the Windows userbase (I'm not sure if it is, but still), many will simply not click the button to install the updates, and leave themselves vulnerable.