Shhh... remember that DotGNU and Mono have never specified meaningful objectives - that would allow their success to be measured, and this would affect the hype factor.
Real objectives would concern real value: the portability and interoperability of products/developments that organizations actually use. Better to stick to announcements about how the C# compiler is now self-hosting, or how someone somewhere is thinking about looking into the feasibility of implementing part of some Dotnet library.
A few months ago ISTR making comments like this to Miguel de Icaza. His response? That people once said the same things about Linux. This appears to be how these guys think - Dotnet is some static, open, well-defined, low-level API and that cloning it is a one-off effort that entails no risk ands cedes no control to MS.
Personally I wouldn't touch this stuff with a bargepole.
This is an excellent step forward for Microsoft on the desktop. As corporations begin to adopt Linux servers, Microsoft software will be able to dominate rather than being left out in the cold.
Congratulations to Microsoft for their success in subverting these open source developments.
Yes, though "technical" discussions often go astray too. We sometimes forget that IT is how technology manages information, rather than information about technology.
IMHO worthwhile subjects of discussion are things like the SQL-Server based file system that was supposed to appear with Longhorn, or maybe Dotnet security, or real real-time capabilties, or DRM.
I'd put these rather arbitrary GUI issues down at the relatively insignificant end of the feature list, along with ephemera such as tablet PCs, XML "technologies" and C#/Java syntax differences.
The problem is the combinatorial explosion of testing effort dictated by the support of a large number of packages on a large number of platforms.
To this there's no easy answer. However, I do not believe that the 'competition' will really come from source-based distributions such as Gentoo mentioned above - ultimately the amount of testing to be done is the same, by getting you to compile things yourself, Gentoo makes it no more likely that a combination will actually work.
Ultimately the threat to Linux as a platform is the Dotnet virtual machine - a software platform comprehensive and abstract enough to reduce the n*m testing needed for Linux and Windows today back towards the 'n' of a single platform. Once Dotnet gets established, the relative cost of writing cross-(hardware)-platform applications will plummet and Linux will be unable to catch up.
The only genuinely equivalent technology available to Linux is Java. Therefore the only viable strategy for a group such as Debian, meaning a group that is serious about having broad hardware support and comprehensive package support and some assurance of quality and comptibility, is to embrace Java, encouraging the development of Java applications and supporting the Java VM as comprehensively as possible.
These issues have of course been discussed on/. many times before, including the practicalities of building from C source, the relevance of Mono, standardization of the C Sharp language and the ownership of Java technologies.
To date, the only real counter-arguments that have stood up are those of simple denial, that is, putting off the day where cross-(hardware)-platform compatibility has to be addressed so far into the future that it is likely that Linux will already have become an irrelevance by the time convergence takes place, or the reckless and naive assumption that the open-source community can clone, and will be allowed to clone, the the Dotnet platform in its entirety.
It will be interesting to watch how key development streams such as Debian, KDE, StarOffice etc. attempt to reconcile these conflicting demands. From the perspective of Java developers like me, it's becoming hard to resist the rather depressing conclusion that at least some of these difficulties are self-imposed.
Really? Wow, food for thought there, and not even a +1 informative - moderators, huh?
My guess is that this might have something to do with their code bases predating Dotnet by 8-15 years, but please don't hold back from sharing your view.
Yes, the source is important to open source. Unfortunately it's generally in C. This means that it's much less easy to modify than Java, C# or Python.
So unfortunately, thanks to the legacy technology inherent in KDE and Gnome, we've already lost this battle relative to MS and spurned the only platform that could have competed.
Threading performance may be poor on Linux, though personally I haven't noticed it, other aspects are fine though. I'd say that big Java applications start up about 20% faster on my Linux partition than on my Windows one using Sun JVM 1.3.1_04.
In fact, Solaris LWP threading has caused me more headaches - it seems that the old N:M thread model can deadlock with native libraries such as the Oracle OCI drivers, theoretically using the alternate 1:1 model fixes this but I haven't yet proved the case to my own satisfaction. Read up on this new model here, or try it by putting/usr/lib/lwp in your LD_LIBRARY_PATH.
...new features very often impose new requirements on persistence format and hence break interoperability.
This does not necessarily follow - new features are usually additional features, implying that their persistent form will be an extension or compatible subtype of the existing format. Adding elements to well-formed (but not DTD-valid) XML file is a straightforward example.
Standards bodies move far slower than the companies implementing said standards, often making true interoperability difficult
This is a good realist position - interoperability is one thing, exact semantic equivalence allowing round-trip transfer of documents between MS Word, StarOffice, KDE Word etc. is quite another.
I suspect most people would put up with a lowest-common-denominator format such as RTF, as long as the bar wasn't set too low.
Right, of course, I met TVV in a later life so I should have remembered. Can't find a corporate history at Stratus.com though there is some at Tandem/Compaq/HP.
Yeah, no doubt. I'm just about old enough to remember IBM's ruthless account management tactics so no illusions there, but bottom line is that MS dominance is the reality we have to contend with today, and embracing Java doesn't give IBM or Sun much control since open implementations can easily be revived if necessary.
It's the least worst alternative to watching Linux disappear into irrelevance.
Unfortunately Mozilla apps are cross-platform only in the sense that Qt ones are, or Visix Galaxy ones used to be - you need a compiler and a decent size machine to build on.
Times are changing - platform today means a VM like Java or Dotnet. Tying builds to specific low-level hardware, whether Itanium in the server room or ARM in a phone, hobbles the process of development, distribution and support to such an extent that it renders the product uncompetitive.
Continuing to invest in this approach for Linux will do nothing more than marginalize it. At this rate, there will be no Linux platform, only cobbled together Linux/Java, Linux/Mono, Linux/Oracle etc. hybrids.
There are projects like Parrot, Guile and Kawa that could offer a way out, but the community is too busy worrying about Gnome vs. KDE, as if these "desktop managers", useful as they are today, were somehow of strategic importance.
Meanwhile, MS is outflanking the whole technical base with Dotnet. The more consistent and pervasive this is, the more Linux will be pushed out of the mainstream. The only combination that is likely to affect BillG's sleeping is a convergence on Linux+Java. Right now, Sun and IBM are effectively providing a lifeboat, but a lot of us don't seem to want to be rescued.
About 1980 Paul Green and (I think) other multicians started a successful fault-tolerant computer company called Stratus, an effective competitor to Tandem. VOS, the OS, was clearly inspired by Multics and had, or rather has, a consistency and reliability unparalleled in Unix.
Its Multics traits include PL/1 as the systems programming language (actually a subset), transparent networking (attach to any device or file anywhere, rather like Apollo Domain), an ancient Emacs port (or clone?) and other useful features like a transactional file system with indexing.
Lots of these expensive machines were sold to banks and other demanding users in the late 80s, there are plenty still around and indeed they're still available.
The boxes were large and well engineered. Quality seemed to be taken very seriously since any crash was a major event - I only remember one OS crash bug in 6 years of working with them. Machines were connected via dialup to the service centre, and core dumps uploaded for analysis automatically (security settings permitting).
All items of hardware, disks, CPU, memory, networking cards were duplicated - except the real-time clock (!) monitored for failures. Any failed device would be removed from service and could be replaced while the system was running - 'go on, pick a board to unplug' demos were always popular.
Coming back to Unix after platform was a pretty rude shock. What horribly eccentric and buggy shell commands! Why does it keep crashing? In many ways I'd quite like to have one today, certainly something like Java would complement it quite nicely.
Pity we don't have an equivalent roadmap (i.e. a common strategy) for Linux. This means that Linux-as-a-platform will ebb away to be replaced by Linux-as-a-Java-or-Dotnet-device-driver.
Emphasis was on getting the job done as quickly as possible
Probably true, but in the case of COM I think you're actually being a little too kind. COM was talked about for years before it emerged, and I believe its designers were more or less aware of the existence of NCS/DCE, CORBA, Sun RPC etc., but this didn't stop them making an astonishing number of misjudgements. Apartment threading, 'interface' references and UUIDs were just the tip of an iceberg, and ultimately they were only able to dig themselves out of this hole by copying Java.
At the time I put it down to having a balance tilted towards very young staff who had little experience of enterprise-level computing. TP, EAI, name resolution, security, concurrency etc. are not issues you can address straight from training.
Looking back I'm not so sure - lack of technical strategy was certainly part of the problem, but really the process was broken in that basic requirements like security, resilience, manageability etc. weren't factored into developments from the outset.
It would be nice to think that Linux's collaborative model protects it against equally shortsighted hacking, but it would help a lot if there was a truly common framework equivalent to J2EE or Dotnet to leverage.
Slashdot Mirror
You don't say! Moral high ground? I'll certainly raise this at the next XP rollout meeting in my company.
Meanwhile, the rest of us who sup with the devil will be taking long spoons, and praying that Parrot and Kaffe do not fall prey to MS-cloning zombies.
And why would I care about that?
Yes, the folks doing Kaffe would like to have access to the Sun test suites, but lack of certification will not stop my application from running.
Shhh... remember that DotGNU and Mono have never specified meaningful objectives - that would allow their success to be measured, and this would affect the hype factor.
Real objectives would concern real value: the portability and interoperability of products/developments that organizations actually use. Better to stick to announcements about how the C# compiler is now self-hosting, or how someone somewhere is thinking about looking into the feasibility of implementing part of some Dotnet library.
A few months ago ISTR making comments like this to Miguel de Icaza. His response? That people once said the same things about Linux. This appears to be how these guys think - Dotnet is some static, open, well-defined, low-level API and that cloning it is a one-off effort that entails no risk ands cedes no control to MS.
Personally I wouldn't touch this stuff with a bargepole.
This is an excellent step forward for Microsoft on the desktop. As corporations begin to adopt Linux servers, Microsoft software will be able to dominate rather than being left out in the cold.
Congratulations to Microsoft for their success in subverting these open source developments.
Yes, though "technical" discussions often go astray too. We sometimes forget that IT is how technology manages information, rather than information about technology.
IMHO worthwhile subjects of discussion are things like the SQL-Server based file system that was supposed to appear with Longhorn, or maybe Dotnet security, or real real-time capabilties, or DRM.
I'd put these rather arbitrary GUI issues down at the relatively insignificant end of the feature list, along with ephemera such as tablet PCs, XML "technologies" and C#/Java syntax differences.
.NET is in a position to make Win32 obsolete
Which will not greatly surprise Microsoft.
Unfortunately, it's also in a position to make Linux obsolete, since Linux has no VM.
The major open development streams (Kernel, Debian, KDE, Gnome, OpenOffice) have no plans for using a VM.
There's Mono, of course, but I'm not alone in having misgivings about that.
Which leaves Java... is it too late already?
These are really related:
/. many times before, including the practicalities of building from C source, the relevance of Mono, standardization of the C Sharp language and the ownership of Java technologies.
The problem is the combinatorial explosion of testing effort dictated by the support of a large number of packages on a large number of platforms.
To this there's no easy answer. However, I do not believe that the 'competition' will really come from source-based distributions such as Gentoo mentioned above - ultimately the amount of testing to be done is the same, by getting you to compile things yourself, Gentoo makes it no more likely that a combination will actually work.
Ultimately the threat to Linux as a platform is the Dotnet virtual machine - a software platform comprehensive and abstract enough to reduce the n*m testing needed for Linux and Windows today back towards the 'n' of a single platform. Once Dotnet gets established, the relative cost of writing cross-(hardware)-platform applications will plummet and Linux will be unable to catch up.
The only genuinely equivalent technology available to Linux is Java. Therefore the only viable strategy for a group such as Debian, meaning a group that is serious about having broad hardware support and comprehensive package support and some assurance of quality and comptibility, is to embrace Java, encouraging the development of Java applications and supporting the Java VM as comprehensively as possible.
These issues have of course been discussed on
To date, the only real counter-arguments that have stood up are those of simple denial, that is, putting off the day where cross-(hardware)-platform compatibility has to be addressed so far into the future that it is likely that Linux will already have become an irrelevance by the time convergence takes place, or the reckless and naive assumption that the open-source community can clone, and will be allowed to clone, the the Dotnet platform in its entirety.
It will be interesting to watch how key development streams such as Debian, KDE, StarOffice etc. attempt to reconcile these conflicting demands. From the perspective of Java developers like me, it's becoming hard to resist the rather depressing conclusion that at least some of these difficulties are self-imposed.
Really? Wow, food for thought there, and not even a +1 informative - moderators, huh?
My guess is that this might have something to do with their code bases predating Dotnet by 8-15 years, but please don't hold back from sharing your view.
Ah, /. in action. So much easier to mod down than provide a counter-argument.
The thread is about hardware platforms.
Yes, the source is important to open source. Unfortunately it's generally in C. This means that it's much less easy to modify than Java, C# or Python.
So unfortunately, thanks to the legacy technology inherent in KDE and Gnome, we've already lost this battle relative to MS and spurned the only platform that could have competed.
Cool. Developers that like to maintain binaries for 'dozens' of platforms - I'd never met any before.
something like autoconf
Just the thing for POSIX systems circa 1990.
Back in this century, Java and Dotnet have happened,
Or maybe Linux is about nostalgia?
Threading performance may be poor on Linux, though personally I haven't noticed it, other aspects are fine though. I'd say that big Java applications start up about 20% faster on my Linux partition than on my Windows one using Sun JVM 1.3.1_04.
/usr/lib/lwp in your LD_LIBRARY_PATH.
In fact, Solaris LWP threading has caused me more headaches - it seems that the old N:M thread model can deadlock with native libraries such as the Oracle OCI drivers, theoretically using the alternate 1:1 model fixes this but I haven't yet proved the case to my own satisfaction. Read up on this new model here, or try it by putting
...new features very often impose new requirements on persistence format and hence break interoperability.
This does not necessarily follow - new features are usually additional features, implying that their persistent form will be an extension or compatible subtype of the existing format. Adding elements to well-formed (but not DTD-valid) XML file is a straightforward example.
Standards bodies move far slower than the companies implementing said standards, often making true interoperability difficult
This is a good realist position - interoperability is one thing, exact semantic equivalence allowing round-trip transfer of documents between MS Word, StarOffice, KDE Word etc. is quite another.
I suspect most people would put up with a lowest-common-denominator format such as RTF, as long as the bar wasn't set too low.
Ah, OK, I defer to your compendious knowledge of agricultural implements... I'm glad to say I've never even seen a plough :-)
Sun owns Java
Sun owns the Java trademark, not the language/APIs/specifications, as I suspect you well know.
The C# standard is of limited value because it is such a small part of Dotnet, and unlike Java, other vendors aren't producing Dotnet implementations.
The difference is real diversity in the market vs. fig leaf endorsements.
Hmmm... the plough dates from approx 0001, the renaissance started in 1450. Delayed reaction? :-)
Right, of course, I met TVV in a later life so I should have remembered. Can't find a corporate history at Stratus.com though there is some at Tandem/Compaq/HP.
Yeah, no doubt. I'm just about old enough to remember IBM's ruthless account management tactics so no illusions there, but bottom line is that MS dominance is the reality we have to contend with today, and embracing Java doesn't give IBM or Sun much control since open implementations can easily be revived if necessary.
It's the least worst alternative to watching Linux disappear into irrelevance.
Unfortunately Mozilla apps are cross-platform only in the sense that Qt ones are, or Visix Galaxy ones used to be - you need a compiler and a decent size machine to build on.
Times are changing - platform today means a VM like Java or Dotnet. Tying builds to specific low-level hardware, whether Itanium in the server room or ARM in a phone, hobbles the process of development, distribution and support to such an extent that it renders the product uncompetitive.
Continuing to invest in this approach for Linux will do nothing more than marginalize it. At this rate, there will be no Linux platform, only cobbled together Linux/Java, Linux/Mono, Linux/Oracle etc. hybrids.
There are projects like Parrot, Guile and Kawa that could offer a way out, but the community is too busy worrying about Gnome vs. KDE, as if these "desktop managers", useful as they are today, were somehow of strategic importance.
Meanwhile, MS is outflanking the whole technical base with Dotnet. The more consistent and pervasive this is, the more Linux will be pushed out of the mainstream. The only combination that is likely to affect BillG's sleeping is a convergence on Linux+Java. Right now, Sun and IBM are effectively providing a lifeboat, but a lot of us don't seem to want to be rescued.
About 1980 Paul Green and (I think) other multicians started a successful fault-tolerant computer company called Stratus, an effective competitor to Tandem. VOS, the OS, was clearly inspired by Multics and had, or rather has, a consistency and reliability unparalleled in Unix.
Its Multics traits include PL/1 as the systems programming language (actually a subset), transparent networking (attach to any device or file anywhere, rather like Apollo Domain), an ancient Emacs port (or clone?) and other useful features like a transactional file system with indexing.
Lots of these expensive machines were sold to banks and other demanding users in the late 80s, there are plenty still around and indeed they're still available.
The boxes were large and well engineered. Quality seemed to be taken very seriously since any crash was a major event - I only remember one OS crash bug in 6 years of working with them. Machines were connected via dialup to the service centre, and core dumps uploaded for analysis automatically (security settings permitting).
All items of hardware, disks, CPU, memory, networking cards were duplicated - except the real-time clock (!) monitored for failures. Any failed device would be removed from service and could be replaced while the system was running - 'go on, pick a board to unplug' demos were always popular.
Coming back to Unix after platform was a pretty rude shock. What horribly eccentric and buggy shell commands! Why does it keep crashing? In many ways I'd quite like to have one today, certainly something like Java would complement it quite nicely.
Presumably because Mozilla, Java and StarOffice are seen as fully-fledged platforms on which all kinds of apps could be developed.
Hopefully Dotnet will make it clear that only one of these really qualifies, and that doesn't mandate any particular l&f.
Spot on.
Pity we don't have an equivalent roadmap (i.e. a common strategy) for Linux. This means that Linux-as-a-platform will ebb away to be replaced by Linux-as-a-Java-or-Dotnet-device-driver.
Emphasis was on getting the job done as quickly as possible
Probably true, but in the case of COM I think you're actually being a little too kind. COM was talked about for years before it emerged, and I believe its designers were more or less aware of the existence of NCS/DCE, CORBA, Sun RPC etc., but this didn't stop them making an astonishing number of misjudgements. Apartment threading, 'interface' references and UUIDs were just the tip of an iceberg, and ultimately they were only able to dig themselves out of this hole by copying Java.
At the time I put it down to having a balance tilted towards very young staff who had little experience of enterprise-level computing. TP, EAI, name resolution, security, concurrency etc. are not issues you can address straight from training.
Looking back I'm not so sure - lack of technical strategy was certainly part of the problem, but really the process was broken in that basic requirements like security, resilience, manageability etc. weren't factored into developments from the outset.
It would be nice to think that Linux's collaborative model protects it against equally shortsighted hacking, but it would help a lot if there was a truly common framework equivalent to J2EE or Dotnet to leverage.