I see that my teaser has successfully teased you, but apparently not enough to actually follow the link. To address what I think is bothering you most, there are good reasons to believe that bytecoded/tokenized apps offer better forward compatibility than binary ones - Java classes, for instance, are very good at running on, and exploiting, improved VMs.
Dotnet does have significant benefits for users and deserves some attention, but not, hopefully, slavish cloning that is doomed to never fully succeed.
As a LISP person, I'm surprised you're not pushing a third alternative - not Java, not a.NET clone, but a VM using a LISP-like intermediate language. Aside from the great features a proper dynamic language would have over C# and Java, just think of the benefits to Open Source if the only possible distribution format was (equivalent to) the source!
Well, does one of these support a cross-platform distribution format? That's going to be Linux's achilles heel relative to Dotnet, unless you count Java, since normal consumers won't run C compilers.
Personally I think there are good reasons for developing (and anointing as such) a Linux VM that takes the best of Dotnet and Java and adds some Open Source twists, without attempting any sort of code compatibility.
Well, can't argue with that. Question is, how meaningful is it to talk about 'the Linux platform' in all these debates (like today's Bob Young says Linux won't rule the desktop) if no one ever writes apps for it directly?
I'm sure even the most pragmatic Linux user can see the benefits from user-space convergence, e.g. Dotnet-conceptual-equivalent + RMS Scheme engine + PERL + Python etc.
The original post explicitly identifies platform as meaning 'hardware platform', sorry if you find the term confusing.
Whatever the virtues of Debian packaging, it's unlikely that commercial apps will use it, which I'm afraid for me rules it out as a viable platform. You are welcome to disagree with this, of course.
As it happens, phones are already running the Java VM, so it's clear that VMs can scale down to devices where C compilers cannot go.
Are you saying Dotnet is or is not a good place to find novel technology?
Well, given the number of ARM devices out there, and the chances that every app I want to use has a prebuilt Debian package available for it, I'd say that diversity is set to grow very quickly.
If I'm doing RMS an injustice and he's talked about doing the equivalent of Dotnet's VM, packaging, signing, verifying, versioning etc. with LISP I'd love to read about it. That would be a great way to go IMHO, if only because LISP is so well matched to the idea of open source - it's quite hard NOT to ship the source (or equivalent) with LISP/Scheme!
Right, they are running bytecode (or whatever) compilers, but without realizing it. Dotnet, and to some extent Java, take care of trust, dependencies and other aspects in a much more user-friendly manner than current Linux build systems.
As I think you're saying, ultimately the issue is not just source vs. bytecode, but of automatic vs. manual, trusted vs untrusted, vague dependencies vs. well defined, high resource requirements vs. low and probably a bunch of other things.
I recommend a trawl through the Dotnet docs, or the O'Reilly book ".NET Framework Essentials" to see what Linux is missing.
Yes, Java provides a VM for Linux, but last time I looked Linus et al weren't proposing that future apps be written in Java. That's the point - just what is the Linux platform that I will write SAP-for-Linux or Musicwrite-for-Linux on?
(Hmmm, don't think I could have wished for a better response!)
1) Windows is moving to something called Dotnet precisely because of cross-platform installation issues. The comparison to make is with Dotnet apps, not with current Win32 apps.
2) You're quite right that there's no reason that installers can't build software. This doesn't mean that this is a simple thing to do for typical Linux apps - I can't run a big build process on my palmtop, not have dependency, signing and other aspects been solved in the Linux world as they have in Dotnet. If MS thought that 'imagination' was the only thing lacking in Win32, presumably they wouldn't have bothered developing Dotnet.
Gosh, great... wonder what'll happen if I post something else?:)
As there is some interest, here's a quick pointer to an earlier post which waxes on and on about what a Linux VM could do for Open Source. Remember tokenized BASIC? Well, it's just like that really...
It would be very, very unfortunate if this debate just focused on the politics of Mono following Microsoft Dotnet. Miguel might be misguided in this aspect, but his strategic vision of what is critical for the future growth of Linux-the-platform is far more attuned to current trends than anything RMS, ER or LT have articulated.
He realizes that without a VM and the cross-(hardware)-platform capabilities it gives, Linux apps are going to be very hard to distribute in future. Normal consumers simply aren't going to run C compilers, yet the Linux "architecture" takes absolutely no account of this.
By the way, it is customary for the 'strategic VM' debate to be ignored in/. - of 27 postings on this topic (see my user info), only one was ever moderated up, and that was promptly moderated down again ('overrated'). Draw your own conclusions!
Indeed. Unfortunately, Linux doesn't even have a prospect of matching 'Longhorn' (Windows with SQL Server file system), let alone anointing a VM to match Dotnet. Yet these technologies are out there to be adapted and developed - Linus and co. just need to understand what 'platform' will mean in 2005.
You're missing one crucial difference - Windows with Dotnet is a single platform, Linux on 10 different devices is 10 different platforms, since Palm computer users will not generally run C compilers. If I can't download My Quantity Surveying App because there's no build for my Linux device, I'm going to switch to Windows.
You forget that cool devices still have to do useful things. The trouble with Linux is that it's not one platform like Java or Dotnet, it's a C-based system requiring apps to be built for every possible hardware variant. If I can't download an established app for my cool new device, I'm not going to buy it.
In a couple of years' time, Windows apps will be written to the Dotnet platform, which means that they can potentially run directly on many kinds of client devices, from phones to 'tablets' to big iron, just as Java apps do today.
Apart from the misguided 'Mono' effort, and perhaps Parrot (the VM for Perl 6), there is nothing equivalent for Linux, instead it remains completely wedded to the users run compilers mentality.
This will stymie development of commercial Linux consumer apps relative to Windows - for PowerPC and ARM users it is having this effect already.
Bob Young's reliance on non-commercial, open-source apps is just as risky for the client side as it is for the server.
The problem is not taking the ideas, that's fine. The problem is in taking ideas exclusively from Microsoft with the goal of creating a compatible product. This simply creates a rod for ones own back, "Mono" being eternally engaged on a quest for full compatibility so that some third-party app will run.
It's a hopeless quest that diverts resources away from real innovation, and that innovation is desperately needed for Linux to survive as a platform in its own right.
Can someone tell me what this part of the interview means, in particular the second sentence?
My main focus is the client. In the web services area there is not a big-buy-in to the Windows platform, because this is the first time they have brought it to Windows.
Well in the Windows world they use SOAP... they do not talk about proprietary protocols.
I don't follow the SOAP statement at all, since developers would normally use the proprietary Dotnet Remoting protocol rather than SOAP within the Windows environment as it is far more complete.
Why is it useful to you? It certainly won't be useful for many third-party applications.
The only thing you can mean is what The Register says in the last para - "the [open source] community... has failed to come up with [the] long term technical architectures that it needs".
If this is the case, it is a truly sad state of affairs, since there many fundamental ways to improve on C# and the CLR - start by asking the LISP community, for example.
I love the idea too, but Miguel has taken more than the idea, he's trying to clone the whole product.
It's hard to see what Linux gains from this since it clearly puts MS in the driving seat. A.NET Dreamweaver or SAP suite will be built and tested for Windows first, Linux will get crumbs off the table if it's lucky.
Two things that would be much better from a Linux/Open Source PoV:
1) The Mono and Parrot (Perl/Python) VMs merge
2) The VM is designed on the principle of lossless translation to it's intermediate language, where the bytecode or whatever is the 100% semantic equivalent of the source (like old tokenizing BASIC interpreters). That way open source happens by definition - you simply can't ship something that isn't equivalent to the source.
(Yes, Java bytecode is nearly 100% - pity about the comments - but LISPers will know that an AST representation is the ideal).
400 years being enough time for it to get acclimatized, one would think. However, I noticed that Americans still pronounce 'valet' in the French manner some 600 years after it came into the language, so you never can tell.
It's because language evolves with time that the exceptions are there - they are relics of different grammer rules, such as a vowel change for the plural from Germanic (mouse, mice etc.). This kind of evolution is not random mutation, so it is possible to say that competing variants are better or worse founded.
In this case, the Latin plural is being retrofitted - though mostly in the written form from what I've noticed.
Slashdot Mirror
I see that my teaser has successfully teased you, but apparently not enough to actually follow the link. To address what I think is bothering you most, there are good reasons to believe that bytecoded/tokenized apps offer better forward compatibility than binary ones - Java classes, for instance, are very good at running on, and exploiting, improved VMs.
Dotnet does have significant benefits for users and deserves some attention, but not, hopefully, slavish cloning that is doomed to never fully succeed.
Nope, I mean
pragmatic, the guy who doesn't care about strategy as long as there is something that works for him
versus
idealistic, someone pushing for minimum complexity, overlap and divergence as goals in themselves
As a LISP person, I'm surprised you're not pushing a third alternative - not Java, not a .NET clone, but a VM using a LISP-like intermediate language. Aside from the great features a proper dynamic language would have over C# and Java, just think of the benefits to Open Source if the only possible distribution format was (equivalent to) the source!
I've harped on about this before.
Well, does one of these support a cross-platform distribution format? That's going to be Linux's achilles heel relative to Dotnet, unless you count Java, since normal consumers won't run C compilers.
Personally I think there are good reasons for developing (and anointing as such) a Linux VM that takes the best of Dotnet and Java and adds some Open Source twists, without attempting any sort of code compatibility.
Well, can't argue with that. Question is, how meaningful is it to talk about 'the Linux platform' in all these debates (like today's Bob Young says Linux won't rule the desktop) if no one ever writes apps for it directly?
I'm sure even the most pragmatic Linux user can see the benefits from user-space convergence, e.g. Dotnet-conceptual-equivalent + RMS Scheme engine + PERL + Python etc.
The original post explicitly identifies platform as meaning 'hardware platform', sorry if you find the term confusing.
Whatever the virtues of Debian packaging, it's unlikely that commercial apps will use it, which I'm afraid for me rules it out as a viable platform. You are welcome to disagree with this, of course.
As it happens, phones are already running the Java VM, so it's clear that VMs can scale down to devices where C compilers cannot go.
Are you saying Dotnet is or is not a good place to find novel technology?
Er, maybe. But this is the 'political' discussion I was trying to avoid - please attach this to someone else's thread ;-)
Well, given the number of ARM devices out there, and the chances that every app I want to use has a prebuilt Debian package available for it, I'd say that diversity is set to grow very quickly.
If I'm doing RMS an injustice and he's talked about doing the equivalent of Dotnet's VM, packaging, signing, verifying, versioning etc. with LISP I'd love to read about it. That would be a great way to go IMHO, if only because LISP is so well matched to the idea of open source - it's quite hard NOT to ship the source (or equivalent) with LISP/Scheme!
Right, they are running bytecode (or whatever) compilers, but without realizing it. Dotnet, and to some extent Java, take care of trust, dependencies and other aspects in a much more user-friendly manner than current Linux build systems.
As I think you're saying, ultimately the issue is not just source vs. bytecode, but of automatic vs. manual, trusted vs untrusted, vague dependencies vs. well defined, high resource requirements vs. low and probably a bunch of other things.
I recommend a trawl through the Dotnet docs, or the O'Reilly book ".NET Framework Essentials" to see what Linux is missing.
Yes, Java provides a VM for Linux, but last time I looked Linus et al weren't proposing that future apps be written in Java. That's the point - just what is the Linux platform that I will write SAP-for-Linux or Musicwrite-for-Linux on?
(Hmmm, don't think I could have wished for a better response!)
1) Windows is moving to something called Dotnet precisely because of cross-platform installation issues. The comparison to make is with Dotnet apps, not with current Win32 apps.
2) You're quite right that there's no reason that installers can't build software. This doesn't mean that this is a simple thing to do for typical Linux apps - I can't run a big build process on my palmtop, not have dependency, signing and other aspects been solved in the Linux world as they have in Dotnet. If MS thought that 'imagination' was the only thing lacking in Win32, presumably they wouldn't have bothered developing Dotnet.
Gosh, great... wonder what'll happen if I post something else? :)
As there is some interest, here's a quick pointer to an earlier post which waxes on and on about what a Linux VM could do for Open Source. Remember tokenized BASIC? Well, it's just like that really...
More here
It would be very, very unfortunate if this debate just focused on the politics of Mono following Microsoft Dotnet. Miguel might be misguided in this aspect, but his strategic vision of what is critical for the future growth of Linux-the-platform is far more attuned to current trends than anything RMS, ER or LT have articulated.
/. - of 27 postings on this topic (see my user info), only one was ever moderated up, and that was promptly moderated down again ('overrated'). Draw your own conclusions!
He realizes that without a VM and the cross-(hardware)-platform capabilities it gives, Linux apps are going to be very hard to distribute in future. Normal consumers simply aren't going to run C compilers, yet the Linux "architecture" takes absolutely no account of this.
By the way, it is customary for the 'strategic VM' debate to be ignored in
Indeed. Unfortunately, Linux doesn't even have a prospect of matching 'Longhorn' (Windows with SQL Server file system), let alone anointing a VM to match Dotnet. Yet these technologies are out there to be adapted and developed - Linus and co. just need to understand what 'platform' will mean in 2005.
You're missing one crucial difference - Windows with Dotnet is a single platform, Linux on 10 different devices is 10 different platforms, since Palm computer users will not generally run C compilers. If I can't download My Quantity Surveying App because there's no build for my Linux device, I'm going to switch to Windows.
You forget that cool devices still have to do useful things. The trouble with Linux is that it's not one platform like Java or Dotnet, it's a C-based system requiring apps to be built for every possible hardware variant. If I can't download an established app for my cool new device, I'm not going to buy it.
It's worse than this.
In a couple of years' time, Windows apps will be written to the Dotnet platform, which means that they can potentially run directly on many kinds of client devices, from phones to 'tablets' to big iron, just as Java apps do today.
Apart from the misguided 'Mono' effort, and perhaps Parrot (the VM for Perl 6), there is nothing equivalent for Linux, instead it remains completely wedded to the users run compilers mentality.
This will stymie development of commercial Linux consumer apps relative to Windows - for PowerPC and ARM users it is having this effect already.
Bob Young's reliance on non-commercial, open-source apps is just as risky for the client side as it is for the server.
It does indeed make sense for embedded systems:
Toshiba signs for ARM mobile Java chip
ARM Jazelle Technology
The problem is not taking the ideas, that's fine. The problem is in taking ideas exclusively from Microsoft with the goal of creating a compatible product. This simply creates a rod for ones own back, "Mono" being eternally engaged on a quest for full compatibility so that some third-party app will run.
It's a hopeless quest that diverts resources away from real innovation, and that innovation is desperately needed for Linux to survive as a platform in its own right.
Can someone tell me what this part of the interview means, in particular the second sentence?
My main focus is the client. In the web services area there is not a big-buy-in to the Windows platform, because this is the first time they have brought it to Windows.
Well in the Windows world they use SOAP... they do not talk about proprietary protocols.
I don't follow the SOAP statement at all, since developers would normally use the proprietary Dotnet Remoting protocol rather than SOAP within the Windows environment as it is far more complete.
Why is it useful to you? It certainly won't be useful for many third-party applications.
The only thing you can mean is what The Register says in the last para - "the [open source] community... has failed to come up with [the] long term technical architectures that it needs".
If this is the case, it is a truly sad state of affairs, since there many fundamental ways to improve on C# and the CLR - start by asking the LISP community, for example.
I love the idea too, but Miguel has taken more than the idea, he's trying to clone the whole product.
.NET Dreamweaver or SAP suite will be built and tested for Windows first, Linux will get crumbs off the table if it's lucky.
It's hard to see what Linux gains from this since it clearly puts MS in the driving seat. A
Two things that would be much better from a Linux/Open Source PoV:
1) The Mono and Parrot (Perl/Python) VMs merge
2) The VM is designed on the principle of lossless translation to it's intermediate language, where the bytecode or whatever is the 100% semantic equivalent of the source (like old tokenizing BASIC interpreters). That way open source happens by definition - you simply can't ship something that isn't equivalent to the source.
(Yes, Java bytecode is nearly 100% - pity about the comments - but LISPers will know that an AST representation is the ideal).
Yes, I know this is a /. blind-spot, but for the record most JVMs are compilers, e.g. IBM's.
400 years being enough time for it to get acclimatized, one would think. However, I noticed that Americans still pronounce 'valet' in the French manner some 600 years after it came into the language, so you never can tell.
It's because language evolves with time that the exceptions are there - they are relics of different grammer rules, such as a vowel change for the plural from Germanic (mouse, mice etc.). This kind of evolution is not random mutation, so it is possible to say that competing variants are better or worse founded.
In this case, the Latin plural is being retrofitted - though mostly in the written form from what I've noticed.