You're close, I think, but the key element is the use of a VM like Java - maybe Mono or Parrot. This gives the modularity required, as you describe, but also takes care of cross-platform code distribution and, because it can do things like JIT compilation, it can literally eliminate the overheads of modularity in the kernel that Linus is so famously against.
Nope. Nothing about placing a file in an SCM system implies anything about it ultimately being part of a release. Committing code should merely be the first step in a long QA journey, with ultimately guarantors such as Linus, SuSE etc. being responsible for the quality of releases that they put together.
We hope that products generally have common kernels, but there's no reason to require it as part of their production process. Meanwhile, Linux-for-chinese-dishwashers etc. can fork and merge as necessary.
This is a perfectly reasonable evolutionary model, it's just unfortunate that C is such a poor language for building modular code. A move to a Java-like VM is seriously overdue for non-kernel code, both for this reason and for cross- hardware platform code distribution in general.
Huh? Committing files to CVS does precisely nothing w.r.t. a labelled release, and subsequent releases can be made with or without each contribution. The only thing you need to do is to disable 'delete' privileges to prevent files useful to someone from being removed.
Parallel development needs some effort to control it, but there's no reason to think it is uncontrollable by nature - same goes for any large, distributed development.
C is dominant in Linux apps, but the number of Java projects on Sourceforge is of the same order of magnitude as C/C++ (6600 C; 5700 C++; 4100 Java).
Unfortunately, C/C++ apps will prove to be the achilles heel of "Linux the platform". Java or.NET apps will be accessible for any device, while Linux C/C++ apps will effectively be limited to selected x86 systems. The 'consumers use compilers' mindset is extraordinarily pernicious among Linux contributors, and by the time it is cast off it will be too late.
Presumably this is Linux on i86? Yes, I'm on a PC too, right now, but if trends are to be believed Linux is going to be high-volume on ARM and other chips.
All attempts to target 'the Linux platform' for mainstream app development are therefore doomed unless the platform includes a VM (as in Java VM). Why can't Borland support Parrot or Mono rather than contributing to this proliferation of non-portable "electronic concrete"?
Your reference for the fundamental reason why VMs are slower than static compilers would be...?
And why is porting a VM harder than porting a compiler?
On the basis of these eternal truths which you have generously shared with us, I suggest you tell Microsoft to abandon their Blackcomb development now, as it clearly won't be competitive.
You know, just maybe the emergence of systems that try to build the whole shebang from source is a way of telling us that we need a better way to distribute programs for different platforms?
Rather than assume that everyone can download the 386 version or compile their own on their embedded Linux PDAs, let's address the real requirement and make some progress, however small, towards practical cross-platform code distribution.
Eric and the rest of the 'visionaries' can ignore it as long as they want, but the fact is that Linux as a platform is going nowhere relative to.NET and Java unless it adopts a VM. Cross-hardware platform distribution issues are already affecting PPC and ARM users and this will get worse as small non-x86 devices spread.
While code distribution requirements alone would be sufficient to justify a 'Linux VM', there is another possible benefit here which gets precisely zero attention. Ever thought what might happen if the source code and compiled code were semantically equivalent? Right now, this is almost the case now with Java bytecode, in that decompilers such as JAD can turn compiled.class files back into source. Real equivalence (a bit like old tokenised BASIC systems) would mean that all that ever needs to be distributed is the 'compiled' form and, by its very nature, this code is always open.
Sound tempting? Well, it's hardly rocket science to implement these days - we have Java, Mono and Parrot VM work going on anyway, and the commercial world has pretty much left the goalposts wide open for an improved bytecode or AST representation of programs.
Why is the investment of time and money going into such a parade of half-assed solutions?
Take a look at the first article quoted above for a suggestion as to how a VM could radically improve on the current situation for Open Source supporters. Hint: Java bytecode is nearly 100% semantically equivalent to the source.
Yes, we can cut MS a bit of slack here, right now, and assume that signing originated as an integrity improvement. However, you don't have to be as paranoid as some people here to envisage a situation where non-trusted code cannot be installed without breaking some support agreement etc., particularly in the corporate environment.
Actually, I'd better complete that statement/ramble and say that I think this is probably the right thing to do from an MS support PoV. The 'remedy', if required, would be to allow other support organizations to certify their own combinations of drivers.
Forget it, it's a hopeless quest. Linus and co. won't realise that the platform is stymied without an anointed VM until it's too late, and current VM work (Mono, JVM, Parrot) is too fragmented.
I've mentioned this severaltimes before on/. but didn't prompt a single reply. That gives you some idea of how big a hill we have to climb.
What of it? Well, at the risk of stating the transparently obvious, you appear to have just negated your argument. If you accept that the motivation of.NET was to compete with Java, you are obliged to agree that, in a discussion of MS's control of the marketplace, the relative merits of CLR vs. JVM are irrelevant.
Yes, it is demonstrably better in some aspects, but not others, and not significantly so either way, which is what the original comment stated. For example, my simple maths with the.NET CLR distributed with VS beta 2 run several times slower than on JVM 1.4 beta.
As a matter of a fact, I can subclass a Java class in Python and LISP, and vice-versa - is this what you mean by integration at the object level?
It's only a counter argument if it makes the original statement less true. Of course, you are welcome to believe that MS invested in.NET primarily to give us these small improvements over the JVM, but I think you'll find that most people believe the motivation was to crush Java.
This discussion is about openness and control, or interoperability and portability in heterogenous environments, if you prefer. The modest improvements of the CLR over the JVM have no more to do with this than the capitalization of C# method names vs. Java method names.
Not at all, I'd be delighted, providing there was a reasonable prospect of getting KDE features into a Motif-based project. After all, one XFree86 seems to be enough.
Putting aside the interesting philosophical question of whether a corporation can be evil for a moment, the following can be asserted with a degree of confidence:
1. The interoperability aspect the article is concerned with is that between platforms, not between languages. The latter is interesting, if overstated, but irrelevant here.
2. CLR may be specified, but other APIs and services are not, therefore it is trivially easy to lock in developers, just as was attempted with the proprietary GUI API MS provided for J++.
3. For some reason, it is not yet widely appreciated that the public SOAP specification already has a proprietary MS extension called.NET Remote. While SOAP cannot pass object references around, or serialize objects like RMI,.NET Remote removes both of these restrictions, making it much more attractive than straight SOAP, which doesn't even provide object-level access in its standard form.
Come in moderators! The reason this should be modded up is that it makes the bulk of Jamie's commentary redundant - i.e. the aspect of control is already addressed with current technology.
But of course the mods can't answer, and nobody appears to want to answer for them. How very unsatisfactory... perhaps/. needs meta-threads as well as meta-moderators?
Are you saying that the type names themselves (DOC, RTF, TXT etc.) are a good way of categorising files, regardless of whether they appear as extensions or resource forks etc.? And what would be the purpose of the type name other than to relate files to applications?
As to the implementation details of what type information is stored where, I don't think it's terribly useful to preclude the use of file headers on the grounds that the headers must be stored contiguously with the rest of the file - the alternatives you mention are only like HFS in the way they are stored (non-contiguously), they are not like HFS in how they are used (the file header and body are always inseparable).
To say that file extensions are 'good idea in general' is a questionable statement, to say the least. They may be more practical than Mac OS meta-data forks, but they are hopeless at providing an adequate guarantee of readability or compatibility, as Word's own history shows, to say nothing of the day-to-day confusion of whether the extension is part of the file ID in various contexts.
What's needed is a header (stored in the index if you like, to observe the unwritten/. law that one starts from implementation details and works backwards) that can express types and subtypes, and an OS that can figure out the best match of program to data.
Perhaps one of the moderators perceiving such insight in the above would like to share with the rest of us his method of avoiding forced duplication of effort in all code depending on such duplicated functionality.
For example, the Java SWT library is currently being ported to Motif and GTK+, those of us using KDE are out of luck until yet more resources can be found for what on Windows is a single task.
Slashdot Mirror
You're close, I think, but the key element is the use of a VM like Java - maybe Mono or Parrot. This gives the modularity required, as you describe, but also takes care of cross-platform code distribution and, because it can do things like JIT compilation, it can literally eliminate the overheads of modularity in the kernel that Linus is so famously against.
Nope. Nothing about placing a file in an SCM system implies anything about it ultimately being part of a release. Committing code should merely be the first step in a long QA journey, with ultimately guarantors such as Linus, SuSE etc. being responsible for the quality of releases that they put together.
We hope that products generally have common kernels, but there's no reason to require it as part of their production process. Meanwhile, Linux-for-chinese-dishwashers etc. can fork and merge as necessary.
This is a perfectly reasonable evolutionary model, it's just unfortunate that C is such a poor language for building modular code. A move to a Java-like VM is seriously overdue for non-kernel code, both for this reason and for cross- hardware platform code distribution in general.
Huh? Committing files to CVS does precisely nothing w.r.t. a labelled release, and subsequent releases can be made with or without each contribution. The only thing you need to do is to disable 'delete' privileges to prevent files useful to someone from being removed.
Parallel development needs some effort to control it, but there's no reason to think it is uncontrollable by nature - same goes for any large, distributed development.
C is dominant in Linux apps, but the number of Java projects on Sourceforge is of the same order of magnitude as C/C++ (6600 C; 5700 C++; 4100 Java).
.NET apps will be accessible for any device, while Linux C/C++ apps will effectively be limited to selected x86 systems. The 'consumers use compilers' mindset is extraordinarily pernicious among Linux contributors, and by the time it is cast off it will be too late.
Unfortunately, C/C++ apps will prove to be the achilles heel of "Linux the platform". Java or
Presumably this is Linux on i86? Yes, I'm on a PC too, right now, but if trends are to be believed Linux is going to be high-volume on ARM and other chips.
All attempts to target 'the Linux platform' for mainstream app development are therefore doomed unless the platform includes a VM (as in Java VM). Why can't Borland support Parrot or Mono rather than contributing to this proliferation of non-portable "electronic concrete"?
(Related post here).
Your reference for the fundamental reason why VMs are slower than static compilers would be...?
And why is porting a VM harder than porting a compiler?
On the basis of these eternal truths which you have generously shared with us, I suggest you tell Microsoft to abandon their Blackcomb development now, as it clearly won't be competitive.
You know, just maybe the emergence of systems that try to build the whole shebang from source is a way of telling us that we need a better way to distribute programs for different platforms?
.NET and Java unless it adopts a VM. Cross-hardware platform distribution issues are already affecting PPC and ARM users and this will get worse as small non-x86 devices spread.
.class files back into source. Real equivalence (a bit like old tokenised BASIC systems) would mean that all that ever needs to be distributed is the 'compiled' form and, by its very nature, this code is always open.
Rather than assume that everyone can download the 386 version or compile their own on their embedded Linux PDAs, let's address the real requirement and make some progress, however small, towards practical cross-platform code distribution.
Eric and the rest of the 'visionaries' can ignore it as long as they want, but the fact is that Linux as a platform is going nowhere relative to
While code distribution requirements alone would be sufficient to justify a 'Linux VM', there is another possible benefit here which gets precisely zero attention. Ever thought what might happen if the source code and compiled code were semantically equivalent? Right now, this is almost the case now with Java bytecode, in that decompilers such as JAD can turn compiled
Sound tempting? Well, it's hardly rocket science to implement these days - we have Java, Mono and Parrot VM work going on anyway, and the commercial world has pretty much left the goalposts wide open for an improved bytecode or AST representation of programs.
Why is the investment of time and money going into such a parade of half-assed solutions?
Pardon me, but don't you mean 'all you Linux PDA/phone/settop box lusers' need to embrace Java? That's where x-platform capabilities count, no?
Thanks! I feel a lot better.
Take a look at the first article quoted above for a suggestion as to how a VM could radically improve on the current situation for Open Source supporters. Hint: Java bytecode is nearly 100% semantically equivalent to the source.
Yes, we can cut MS a bit of slack here, right now, and assume that signing originated as an integrity improvement. However, you don't have to be as paranoid as some people here to envisage a situation where non-trusted code cannot be installed without breaking some support agreement etc., particularly in the corporate environment.
Actually, I'd better complete that statement/ramble and say that I think this is probably the right thing to do from an MS support PoV. The 'remedy', if required, would be to allow other support organizations to certify their own combinations of drivers.
Forget it, it's a hopeless quest. Linus and co. won't realise that the platform is stymied without an anointed VM until it's too late, and current VM work (Mono, JVM, Parrot) is too fragmented.
/. but didn't prompt a single reply. That gives you some idea of how big a hill we have to climb.
I've mentioned this several times before on
LOL. I will add 'knob-gobbler' to my list of phrases not to use in /. for fear of upsetting the delicate sensibilities of moderators.
Points for style aside, the point made is very important, and I for one am sorry that it's just disappeared from sight.
What of it? Well, at the risk of stating the transparently obvious, you appear to have just negated your argument. If you accept that the motivation of .NET was to compete with Java, you are obliged to agree that, in a discussion of MS's control of the marketplace, the relative merits of CLR vs. JVM are irrelevant.
Yes, it is demonstrably better in some aspects, but not others, and not significantly so either way, which is what the original comment stated. For example, my simple maths with the .NET CLR distributed with VS beta 2 run several times slower than on JVM 1.4 beta.
As a matter of a fact, I can subclass a Java class in Python and LISP, and vice-versa - is this what you mean by integration at the object level?
It's only a counter argument if it makes the original statement less true. Of course, you are welcome to believe that MS invested in .NET primarily to give us these small improvements over the JVM, but I think you'll find that most people believe the motivation was to crush Java.
Read the comment again. The poster is referring to the choice of whether to use MS's CLR, not what language to use.
In what way was the comment reactionary, BTW?
Informative this might be. Relevant, it's not.
This discussion is about openness and control, or interoperability and portability in heterogenous environments, if you prefer. The modest improvements of the CLR over the JVM have no more to do with this than the capitalization of C# method names vs. Java method names.
Not at all, I'd be delighted, providing there was a reasonable prospect of getting KDE features into a Motif-based project. After all, one XFree86 seems to be enough.
Putting aside the interesting philosophical question of whether a corporation can be evil for a moment, the following can be asserted with a degree of confidence:
.NET Remote. While SOAP cannot pass object references around, or serialize objects like RMI, .NET Remote removes both of these restrictions, making it much more attractive than straight SOAP, which doesn't even provide object-level access in its standard form.
1. The interoperability aspect the article is concerned with is that between platforms, not between languages. The latter is interesting, if overstated, but irrelevant here.
2. CLR may be specified, but other APIs and services are not, therefore it is trivially easy to lock in developers, just as was attempted with the proprietary GUI API MS provided for J++.
3. For some reason, it is not yet widely appreciated that the public SOAP specification already has a proprietary MS extension called
Come in moderators! The reason this should be modded up is that it makes the bulk of Jamie's commentary redundant - i.e. the aspect of control is already addressed with current technology.
But of course the mods can't answer, and nobody appears to want to answer for them. How very unsatisfactory... perhaps /. needs meta-threads as well as meta-moderators?
Not sure I follow your clarification.
Are you saying that the type names themselves (DOC, RTF, TXT etc.) are a good way of categorising files, regardless of whether they appear as extensions or resource forks etc.? And what would be the purpose of the type name other than to relate files to applications?
As to the implementation details of what type information is stored where, I don't think it's terribly useful to preclude the use of file headers on the grounds that the headers must be stored contiguously with the rest of the file - the alternatives you mention are only like HFS in the way they are stored (non-contiguously), they are not like HFS in how they are used (the file header and body are always inseparable).
To say that file extensions are 'good idea in general' is a questionable statement, to say the least. They may be more practical than Mac OS meta-data forks, but they are hopeless at providing an adequate guarantee of readability or compatibility, as Word's own history shows, to say nothing of the day-to-day confusion of whether the extension is part of the file ID in various contexts.
/. law that one starts from implementation details and works backwards) that can express types and subtypes, and an OS that can figure out the best match of program to data.
What's needed is a header (stored in the index if you like, to observe the unwritten
Perhaps one of the moderators perceiving such insight in the above would like to share with the rest of us his method of avoiding forced duplication of effort in all code depending on such duplicated functionality.
For example, the Java SWT library is currently being ported to Motif and GTK+, those of us using KDE are out of luck until yet more resources can be found for what on Windows is a single task.
...is the correct answer! (I think). I believe ALL nazi spies had been 'turned' by this point so poor old Adolf had little to go on.