I trust you've been so good as to inform Microsoft that their attempts to make Dotnet part of the OS are doomed to failure? I'm sure that they would be interested in your "straightforward" explanation, as would we.
Your equally valuable insight regarding the nature of WinFS appears not to address its potential value to consumers, or the consequences of the lack of an equivalent in Linux. I would not myself care to make predictions regarding the number of Linux systems that will be developed for an obscure and very expensive database file system from Oracle, but if you would care to keep us informed of progress in this area I'm sure nobody would object.
Regarding Mono and dotGNU, the first thing that should be said is that are both highly dubious attempts at a dumb clone of Dotnet and, given its proprietary nature, represent a commercial risk that most corporations and many individuals are unlikely to find worthwhile.
The most successful VM on Linux both by number of available applications and (by several orders of magnitude) commercial investment is Java. Therefore embracing Java or, at minimum, developing an unencumbered and solution like the Perl VM is the only credible way for Linux to progress and thereby offer a competitive alternative to Longhorn.
Your main point is valid, but only if Linux seizes the opportunity to make strategic improvements. New Desktops, however pretty, will not be sufficient.
There have already been a number of extraordinarily complacent posts assuring us that there will be little worth having in Longhorn, that delays are being caused by minor security fixes, that features will be "borrowed" from OSX etc.
This is grossly misleading and potentially very damaging to Linux.
Right now, in 2003, Linux has no equivalent to Dotnet or WinFS nor any plan for such features. Such VMs and DBs that do exist are completely unexploited (and often impossible to exploit) from the kernel, the core tools and the popular desktops and office applcations.
WinFS and Dotnet do represent significant advances to the consumer platform and Linux is likely to have its 30 year heritage all too visible unless its different development groups start talking and planning.
Maybe we may even start seeing kernel optimisations designed to optimise the performance of Java - there may already be, but I'm not aware of any
Indeed. The fact that Linux development has still not planned for, investigated or acknowledged any kind of VM is an appalling indictment of the OS planning 'process'. It might have been excusable in 1999 to pretend that Java had never happened, or in 2001 that Dotnet was a passing fad, but in 2003 this attitude is nothing short of ludicrous.
If Linux carries on in this vein, Windows will breeze past it in a number of key areas, including security, integrity, packaging and portability.
In fact, Linux-the-platform will then cease to exist for all practical purposes, since only Linux+Java (or some other VM) will be a viable application environment for consumers.
They invented the lava lamp back in 1963, and are still going despite having to spend a fortune stopping far east manufacturers ripping off their designs. Quite a cute site so worth a plug.
It might be a generalization, but IME the remark does not deserve to be termed "bullshit".
In the UK, I've been working recently for a number of telcos and banks and without exception SuSE and RedHat are the only distros used for line-of-business applications.
Other distributions, where installed, are being replaced as part of general consolidation and management plans. Support for RH and SuSE from IT vendors such as Oracle and BEA is the main factor, but this coupled with the need to standardize results in an inexorable process of marginalization for the rest.
Well, you can both be right. IANAC but I think we're in an interglacial warm period, though glaciations are a feature of the relatively recent past (pleistocene?)
One angle to keep in mind is that the link between product and payment can be fairly loose.
For example, that fount of/. breaking news, the BBC Sci/Tech web site, is funded by a (broadly) universal tax.
Though of course BBC product is copyright, the interesting thing is that they could function without it. Not all creative effort that's valuable is dependent on copyright - various funding models for the "arts" can and have been tried.
(And, for what it's worth, my guess is that there would be little correlation between quality and commoditization).
Nope, sorry to mislead you - I misread the references to Mauve. At one stage they thought they were going to get access to the JCK and made some announcement to that effect, now a developer or user has to pay to join the JCP to get this.
Basically we're left with the specifications open / code closed situation as with the rest of the Sun's products.
Still trucking Multics spin-off Stratus VOS (see that little Multics link at the bottom?) has a lot (all?) of these "scalability" features. Worked nicely on a 6-way server in 1986 anyway, great little system.
I take umbrage with people making claims about "standardization" which turn out to be false, so tempting me to invest in a platform that will lead me into either
a) a half-baked solution than doesn't give me true portability (and it only takes one missing API to cost me bigtime)
or
b) causing me to infringe patents owned by Microsoft, which were expressly designed to prevent cloning and are likely to be enforced.
We already have two excellent open-source VM projects (Perl and Kaffe), and a wealth of open source code to run on them. Companies are making huge investments in Java-on-Linux - what value does Mono add apart from making headlines for Ximian?
You're welcome to expound on the benefits of the C Sharp language, but I think such details are unlikely on their own to change any responsible person's mind.
No, the SCSL is not a free license, but it applies to code, not to specifications.
Sun isn't making their Java implementation open source, but the critical point is that they are not preventing someone else from creating one. Of course, there are literally dozens of other Java implementations out there so this is a well-worn path.
As you've found, that's what the Kaffe folks are doing. That email is from a newbie asking whether he can "do a SCO" and mix Sun's code in with Kaffe - no he can't!
You can even get access to the test suites by joining the JCP. People can write their own, and there are open source efforts to do this.
The bottom line is that we are free to implement anything we like. Sun will still collect revenue based on the Java brand from the likes of BEA and IBM, but that is the only real difference.
My guess is that the reason that Kaffe is not particularly fast is that there are already three very high quality JVMs freely available for Linux.
In fact, I know that it is the existence of these VMs that are enabling a large number of major companies to move to Linux.
It would be interesting to compare the collective investment in Java-on-Linux to that of Mono-on-Linux. My guess would be about 6 orders of magnitude in favor of Java, but of course this might be slightly out...:-)
The fact that Mono developers had to resort to a general "HOW TO" guide to figure out details of the Dotnet implementation should set at least some people's alarm bells ringing.
(Assuming of course that they've overcome the shock of discovering that the bulk of Dotnet isn't published, specified or standardized at all, despite all that hype about ECMA).
Contrast this with Java, where we get a proper set of specifications and test suites, or with Perl/Parrot, where we get to write our own!
Perhaps more relevant to the Linux users here is the huge growth in Java on Linux due to the commercial (but generally free) JVM implementations from BEA, IBM and Sun. This is what places Java-on-Linux head and shoulders above Mono.
I agree, however, that there are valid alternatives to both, and people with a desire to do something creative rather than just cloning stuff might like to help out with Parrot, the Perl 6 VM, also targeting a bunch of other languages.
The issue was not what standards were involved, but whether those standards include Dotnet.
They do not.
I (and probably my boss, clients etc.) do not care what non-standard parts of Dotnet have been cloned. As the parent says, these are not covered by standards and are potentially at risk from patent claims.
Unfortunately, your web site is still misleading people into thinking that Mono is (now) an implementation of the Dotnet APIs. It is this kind of deceptive statement that is annoying people.
Slashdot Mirror
I trust you've been so good as to inform Microsoft that their attempts to make Dotnet part of the OS are doomed to failure? I'm sure that they would be interested in your "straightforward" explanation, as would we.
Your equally valuable insight regarding the nature of WinFS appears not to address its potential value to consumers, or the consequences of the lack of an equivalent in Linux. I would not myself care to make predictions regarding the number of Linux systems that will be developed for an obscure and very expensive database file system from Oracle, but if you would care to keep us informed of progress in this area I'm sure nobody would object.
Regarding Mono and dotGNU, the first thing that should be said is that are both highly dubious attempts at a dumb clone of Dotnet and, given its proprietary nature, represent a commercial risk that most corporations and many individuals are unlikely to find worthwhile.
The most successful VM on Linux both by number of available applications and (by several orders of magnitude) commercial investment is Java. Therefore embracing Java or, at minimum, developing an unencumbered and solution like the Perl VM is the only credible way for Linux to progress and thereby offer a competitive alternative to Longhorn.
Your main point is valid, but only if Linux seizes the opportunity to make strategic improvements. New Desktops, however pretty, will not be sufficient.
There have already been a number of extraordinarily complacent posts assuring us that there will be little worth having in Longhorn, that delays are being caused by minor security fixes, that features will be "borrowed" from OSX etc.
This is grossly misleading and potentially very damaging to Linux.
Right now, in 2003, Linux has no equivalent to Dotnet or WinFS nor any plan for such features . Such VMs and DBs that do exist are completely unexploited (and often impossible to exploit) from the kernel, the core tools and the popular desktops and office applcations.
WinFS and Dotnet do represent significant advances to the consumer platform and Linux is likely to have its 30 year heritage all too visible unless its different development groups start talking and planning.
Their government is more of a form of esocialism
esocialism? The alternative to eBusiness?
before we get a warm and fuzzy feeling about communism, let's not forget the cultural revolution in China
Ah yes, I believe Karl Marx was very hot on having students torture their teachers. Sure has a lot to answer for, that guy.
Maybe we may even start seeing kernel optimisations designed to optimise the performance of Java - there may already be, but I'm not aware of any
Indeed. The fact that Linux development has still not planned for, investigated or acknowledged any kind of VM is an appalling indictment of the OS planning 'process'. It might have been excusable in 1999 to pretend that Java had never happened, or in 2001 that Dotnet was a passing fad, but in 2003 this attitude is nothing short of ludicrous.
If Linux carries on in this vein, Windows will breeze past it in a number of key areas, including security, integrity, packaging and portability.
In fact, Linux-the-platform will then cease to exist for all practical purposes, since only Linux+Java (or some other VM) will be a viable application environment for consumers.
If so, it's rather unfortunate that MS has adopted one (Dotnet) and Linux has not (despite having Java, Perl etc. to choose from).
Which leads one to wonder which system will be most secure in 2 years time...
Oops, messed up the main link, sorry.
PS I rather like the contrast between the original inventor chappie and the today's female sharp cookie CEO.
I pass Mathmos HQ every day - nice window display.
They invented the lava lamp back in 1963, and are still going despite having to spend a fortune stopping far east manufacturers ripping off their designs. Quite a cute site so worth a plug.
The reference was clearly to Java-the-platform, therefore Java-the-language is irrelevant
It might be a generalization, but IME the remark does not deserve to be termed "bullshit".
In the UK, I've been working recently for a number of telcos and banks and without exception SuSE and RedHat are the only distros used for line-of-business applications.
Other distributions, where installed, are being replaced as part of general consolidation and management plans. Support for RH and SuSE from IT vendors such as Oracle and BEA is the main factor, but this coupled with the need to standardize results in an inexorable process of marginalization for the rest.
They have been around for a very long time. The Sequent Symmetry used 386s running at something like 20MHz in the late 1980s.
:-)
That old?
Try the Burroughs B5000 (1961)
Well, you can both be right. IANAC but I think we're in an interglacial warm period, though glaciations are a feature of the relatively recent past (pleistocene?)
On the contrary, there's plenty of doubt.
Ximian have just been taken over by Novell, for starters.
Or do you really think that they're more interested in Mono than Exchange Connector?
Multics didn't die in 1969 - it went on under the auspices of Honeywell to influence many more OSes than Unix.
And one could argue that the "enterprise" features of Unix were present in Multics some time before they were reintroduced to its descendant.
The last Multics machine was turned off in October 2000. More details here.
One angle to keep in mind is that the link between product and payment can be fairly loose.
/. breaking news, the BBC Sci/Tech web site, is funded by a (broadly) universal tax.
For example, that fount of
Though of course BBC product is copyright, the interesting thing is that they could function without it. Not all creative effort that's valuable is dependent on copyright - various funding models for the "arts" can and have been tried.
(And, for what it's worth, my guess is that there would be little correlation between quality and commoditization).
But not the decent laptops.
Looks like the JBoss people will be making use of the Sun test suites according to The Server Side. Maybe this will set a precedent for Kaffe.
Nope, sorry to mislead you - I misread the references to Mauve. At one stage they thought they were going to get access to the JCK and made some announcement to that effect, now a developer or user has to pay to join the JCP to get this.
Basically we're left with the specifications open / code closed situation as with the rest of the Sun's products.
Yeah.
Still trucking Multics spin-off Stratus VOS (see that little Multics link at the bottom?) has a lot (all?) of these "scalability" features. Worked nicely on a 6-way server in 1986 anyway, great little system.
Do you?
I take umbrage with people making claims about "standardization" which turn out to be false, so tempting me to invest in a platform that will lead me into either
a) a half-baked solution than doesn't give me true portability (and it only takes one missing API to cost me bigtime)
or
b) causing me to infringe patents owned by Microsoft, which were expressly designed to prevent cloning and are likely to be enforced.
We already have two excellent open-source VM projects (Perl and Kaffe), and a wealth of open source code to run on them. Companies are making huge investments in Java-on-Linux - what value does Mono add apart from making headlines for Ximian?
You're welcome to expound on the benefits of the C Sharp language, but I think such details are unlikely on their own to change any responsible person's mind.
Errrr... I'm pointing out the threat of legal action by someone else (and with good reason, based on past experience and various public statements).
No, the SCSL is not a free license, but it applies to code, not to specifications.
Sun isn't making their Java implementation open source, but the critical point is that they are not preventing someone else from creating one. Of course, there are literally dozens of other Java implementations out there so this is a well-worn path.
As you've found, that's what the Kaffe folks are doing. That email is from a newbie asking whether he can "do a SCO" and mix Sun's code in with Kaffe - no he can't!
You can even get access to the test suites by joining the JCP. People can write their own, and there are open source efforts to do this.
The bottom line is that we are free to implement anything we like. Sun will still collect revenue based on the Java brand from the likes of BEA and IBM, but that is the only real difference.
Nothing ironic here, move along :-)
:-)
My guess is that the reason that Kaffe is not particularly fast is that there are already three very high quality JVMs freely available for Linux.
In fact, I know that it is the existence of these VMs that are enabling a large number of major companies to move to Linux.
It would be interesting to compare the collective investment in Java-on-Linux to that of Mono-on-Linux. My guess would be about 6 orders of magnitude in favor of Java, but of course this might be slightly out...
The fact that Mono developers had to resort to a general "HOW TO" guide to figure out details of the Dotnet implementation should set at least some people's alarm bells ringing.
(Assuming of course that they've overcome the shock of discovering that the bulk of Dotnet isn't published, specified or standardized at all, despite all that hype about ECMA).
Contrast this with Java, where we get a proper set of specifications and test suites, or with Perl/Parrot, where we get to write our own!
Nope, Kaffe is the open source one that isn't based on Sun code. I suspect that there are a few clean-room embedded VMs out there too, but I can't prove it.
Perhaps more relevant to the Linux users here is the huge growth in Java on Linux due to the commercial (but generally free) JVM implementations from BEA, IBM and Sun. This is what places Java-on-Linux head and shoulders above Mono.
I agree, however, that there are valid alternatives to both, and people with a desire to do something creative rather than just cloning stuff might like to help out with Parrot, the Perl 6 VM, also targeting a bunch of other languages.
The issue was not what standards were involved, but whether those standards include Dotnet.
They do not.
I (and probably my boss, clients etc.) do not care what non-standard parts of Dotnet have been cloned. As the parent says, these are not covered by standards and are potentially at risk from patent claims.
Unfortunately, your web site is still misleading people into thinking that Mono is (now) an implementation of the Dotnet APIs. It is this kind of deceptive statement that is annoying people.