Portability is indeed good. I guess the factor for everyone to evaluate is the value Mono has when full portability is missing, or when special portable libs have to be used.
To my mind this puts it in precisely the same cetegory as Java (or Python), where Mono becomes a platform in its own right. Of course if this trend continues, there's no point in being constrained by MS compatibility at all - you might as well invent your own stuff.
Why Mono is still being touted as "an implementation of the Dotnet Framework" is still a bit of a mystery.
Not given the number of times this has already been discussed on/. I suppose.
My impression (from a far from neutral viewpoint) is that each time it comes up the discussion has progressively become less "that's a neat thing to do" and more "sounds risky, a bit unimaginative, and isn't it ultimately pointless?"
Probably the hardest thing to gauge is the risk from MS - we'll carry on debating this until, and probably after, the C&D orders hit the doormat.
The "unimaginative" and "pointless" accusations are easier to get a handle on. Once it's conceded that portability of an application from Windows to Linux is unlikely to be fully realized (at least, not without an equally comprehensive yet-to-appear WINE layer), then the bottom-line value of Mono is immediately suspect. If I can't actually port my source code, what's it to me whether Mono uses the same bytecode format or not?
As has been mentioned before, DotGNU is perhaps more worthy of support since it has tied itself less completely to MS's apron strings - Java bytecode is supported in principle if not in practice, for example. However, the Python and Parrot efforts are perhaps the projects closest to the goals of OSS that are capable of delivering the same benefits as Java and Dotnet.
Lastly, it should be kept in mind that Java on Linux is huge, probably the biggest factor driving Linux in the enterprise - IBM, BEA and Sun all have high quality JVMs for Linux. If it were possible to compare investments. The investment going into Mono is infinitesimal in comparison.
That would be C Sharp and the CLR, which comprise about 120 of the ~1200 classes in Dotnet.
Thanks, we feel a lot better now.;-)
Re:Keep putting it off. Please !
on
Longhorn in 2006
·
· Score: 1
From which we are forced to admit that no platform is completely secure. (One trusts that readers of a delicate disposition have prepared themselves for this disturbing result).
However, we can reasonably ask which approach is more likely to provide a secure environment:
A) users having machines that do not execute arbitrary content, that check access based on trust relationships and provide a means of ensuring message confidentiality and integrity
or
B) a special device responsible for implementing all security checks and controls, to which all potentially risky communication is delegated (no cheating by going round the back with those laptops!), able to understand the import of all oommunications (including encrypted ones), the trustworthiness of their origin, their integrity and their direct and indirect consequences of receiving them for all users using any kind of device.
Certainly security is involved in both of these approaches. The difference is that one offers an adequate and appropriate solution, the other looks like it will only ever be a limited band-aid for systems which have shown themselves to be designed without due regard for the environment in which they will be used.
Re:Keep putting it off. Please !
on
Longhorn in 2006
·
· Score: 1
An indulgence with which even the most autere debater can sympathise, I'm sure.
Might one enquire what particular method of logical analysis was applied to yield this gratifying conclusion?
I ask only because I am certain that those of us that daily face difficulties in formulating coherent arguments on technical subject matter would benefit greatly from the innovative perspective that you have developed. Indeed, to deny this audience the prospect of such great personal satisfaction for so little intellectual outlay could, I fear, be interpreted as an act of selfishness on your part, and thereby put at risk the unrivaled esteem accorded to your pronouncements in this forum.
As a very rough indication of how likely this is, here's a posting I made very recently proposing this kind of development for Linux, together with the extensive (not) discussion it provoked.
Elsewhere, meanwhile, huge volumes of space were taken up with the minutiae of new kernel scheduling models and packaging schemes. This appears to be the level of planning that typical OSS developers feel comfortable with, unfortunately it looks like it will be insufficient to keep Linux-the-platform competitive in the longer term.
Lucky we have Java I guess.
Re:Keep putting it off. Please !
on
Longhorn in 2006
·
· Score: 1
As anyone who actually works with security can tell you, if your network is letting in Trojans and other mail-borne problems, what OS you are running is the least of your concerns.
Oh really?
And how does this wonder detector work? By predicting every potential flaw in your email processing path? You appear to rely on your virus scanners to anticipate every attack, yet the virus scanners did not anticipate Sobig, and in general the strategy is highly questionable as has been pointed out in this forum many times.
A secure system requires a secure platform. Punting the problem to some supposedly omniscient intermediary sounds like an act of either complacency or desperation.
Your little rant has at best a tenuous connection with what I wrote.
I suggest that people will cooperate if it is in their interest to do so. If the idea of organizing the activities of a group repels you then you are probably best suited to a project small enough for you to accomplish on your own.
Whereas on a Windows 9x machine we press Escape for similar privileges...
You should distinguish between Lisp and Symbolics machines. There are plenty of reasons for believing that a Lisp-like language is a better foundation for information security than the C-like ones - the aspect of integrity that you mention is just one.
Security is about enforcing a complex set of policies, many of which can only be evaluated at run-time. It is at least questionable whether we are really better off building such models on the Windows of today that the Lisp machines of yesterday.
Perhaps he was assuming that the rationalisation effort would be rational?
E.g. a set of requirements gathered based on usage scenarios then prioritized based on popularity and a solution meeting as many of those requirements as possible designed and implemented.
Irrational developers can have their own project - I hear Mono could use more help;-)
Evidence, if any were needed, of the huge disconnect between what/. thinks is important for Linux and what the IT market thinks.
Out there, Java is probably the number one reason use of Linux is spreading in large organizations. Not unrelatedly, MS are betting the farm on their Java clone - Dotnet will be the biggest thing in the next version of Windows.
Linux really needs a VM. (It could also benefit from that other rumored Longhorn feature, a database-backed file system, but that's another story...).
OK, we can add Java or Python to our systems, but this still leaves Linux-the-platform facing two big challenges:
1. Support apps for kernel functions have to be written in lowest-common-denominator C/C++, making, say, ALSA configuration difficult
2. The number of very different frameworks providing essential functions (desktops, config management, web servers, security admin) is large, also these frameworks do not compare particularly well with Java or Dotnet/Longhorn equivalents.
3. VMs have intrinsic advantages which, when widespread in Longhorn could make Linux-the-platform look obsolescent quite quickly. Security guarantees are one obvious area, application portability is another.
When I think of secure programs, I think of qmail, postfix and djbdns
Sounds like you are working in a very narrow field - a field, apparently, without any business applications at all (unless we count the mail server).
Out where I am we have application servers running web services, ERM and CRM systems, telco provisioning, financial trading and settlement systems, military logistics systems etc.
A very large proportion of these applications both use Java and rely on the Java security framework.
In fact, it's probably a fair bet that Java is the number one choice for building enterprise applications with non-trivial security requirements.
But not generally at the level of granularity of a thread or window, as clearly stated in the parent but omitted in your quote.
Re:C/C++ is not secure? Setting the record straigh
on
The Next Path for Joy
·
· Score: 1
1. The term "mission critical application" does not refer to components like the OS.
2. I am interested in discussing the security of "business information systems", the proposition being that they would be better written in Java than in C/C++. If your points are intended for some other kind of audience then make that clear.
3. The reason your non-OS examples aren't convincing is because they predate Java by a long way. They also belong to a restricted class of established infrastructure components which evolve very slowly and are not suceptible to being replaced by newer alternatives, even when better.
4. Despite such obstacles, Java databases having the qualities you mention do exist - I'm surprised you have not encountered Cloudscape or Pointbase, noticed the number of Java components in Oracle Lite.
5. I don't see the relevance of your exposition on disk access, and I fear your knowledge of security models may be less advanced than you suppose. The Java security model does augment the kernel security model - from a Java application's point of view its controls are as completely and effectively enforced as those of the OS.
As I said before, your facts are mostly undisputed but they say little one way or the other regarding how a secure application can best be written. What clues we do have from your examples, where Oracle does not support C stored procedures but does support Java ones, imply that application code should preferably be written in Java.
In fact, I find that it's the general shallowness of analysis on display here and in similar technical threads that distinguishes/. from other forums.
This is partly a consequence of an editorial policy that sustains a band of partisans rather than appealing to an audience with problems to solve, and partly a reflection of the conservative and derivative nature of the prominent open source developments. (Of course there's lots of wonderful innovation out there, but it won't get a fraction of the coverage that something like Mono gets).
This thread alone must have over a dozen examples of vacuous, uninformed, aggressive and semi-literate statements moderated to +5. Do we care? Well, it simply reinforces the impression of those/. "tendencies" that rule it out as a usable source of information about IT: technology for its own sake; a poor grasp of fundamentals; noticeable difficulties in appreciating general qualities and requirements.
With a little more work,/. could be a whole lot better. Enhance the moderating, archiving, categorizing and searching so that people can share and locate information that is really interesting or insightful (or funny) and you would certainly improve the service, perhaps even to the extent that people would consider paying for it.
Java can do some things by default that C can't, by default--buffer overflow checks, for example--but that doesn't make it necessarily "better".
Strange as it may seem, it does.
Of course, I should immediately qualify this assertion by adding "in the context of implementing general-purpose business information systems", but I doubt if that will be too far from the territory of most of the/. audience.
The reason is simple. While I can build a system that doesn't suffer from buffer overflows in C, the only way I can guarantee this is by looking through the code - a code audit, in security parlance. In Java, I know up front that there are no such vulnerabilities. With lots of lines of code to check, this guarantee is worth a lot of money, and is therefore clearly and demonstrably better for this (very broad) class of applications.
Similar reasoning can be applied to other intrinsic features of Java as discussed elsewhere, - trusted code, portability guarantees, GC etc.
Not really. If one had to describe Windows' vulnerabilities in a few phrases, buffer overflows, untrusted code and uncontrolled access would be a reasonable summary.
These vulnerabilities are all properly and intrinsically addressed in Java. It is not possible to circumvent the controls by sloppy or malicious programming, therefore Java does enforce secure behaviour.
Joy's comments might represent an exaggeration or simplification, not unreasonable considering the intended audience, but they clearly demonstrate more "insight" than the superficial blather offered above.
Re:Imagine that you are an alcoholic...
on
The Next Path for Joy
·
· Score: 2, Informative
[Java] isn't ready to be used for anything with a GUI
Better warn those C/C++ developers using Borland's C++BuilderX IDE.
It's written in Java and uses Swing, just as JBuilder has for years.
Slashdot Mirror
Freibier is gratis? Hah, interesting.
Why "umsonst" and not "kostenlos" though?
Thanks for the informative update.
Portability is indeed good. I guess the factor for everyone to evaluate is the value Mono has when full portability is missing, or when special portable libs have to be used.
To my mind this puts it in precisely the same cetegory as Java (or Python), where Mono becomes a platform in its own right. Of course if this trend continues, there's no point in being constrained by MS compatibility at all - you might as well invent your own stuff.
Why Mono is still being touted as "an implementation of the Dotnet Framework" is still a bit of a mystery.
Not given the number of times this has already been discussed on /. I suppose.
My impression (from a far from neutral viewpoint) is that each time it comes up the discussion has progressively become less "that's a neat thing to do" and more "sounds risky, a bit unimaginative, and isn't it ultimately pointless?"
Probably the hardest thing to gauge is the risk from MS - we'll carry on debating this until, and probably after, the C&D orders hit the doormat.
The "unimaginative" and "pointless" accusations are easier to get a handle on. Once it's conceded that portability of an application from Windows to Linux is unlikely to be fully realized (at least, not without an equally comprehensive yet-to-appear WINE layer), then the bottom-line value of Mono is immediately suspect. If I can't actually port my source code, what's it to me whether Mono uses the same bytecode format or not?
As has been mentioned before, DotGNU is perhaps more worthy of support since it has tied itself less completely to MS's apron strings - Java bytecode is supported in principle if not in practice, for example. However, the Python and Parrot efforts are perhaps the projects closest to the goals of OSS that are capable of delivering the same benefits as Java and Dotnet.
Lastly, it should be kept in mind that Java on Linux is huge, probably the biggest factor driving Linux in the enterprise - IBM, BEA and Sun all have high quality JVMs for Linux. If it were possible to compare investments. The investment going into Mono is infinitesimal in comparison.
The parts of .NET that are standard are safe
;-)
That would be C Sharp and the CLR, which comprise about 120 of the ~1200 classes in Dotnet.
Thanks, we feel a lot better now.
From which we are forced to admit that no platform is completely secure. (One trusts that readers of a delicate disposition have prepared themselves for this disturbing result).
However, we can reasonably ask which approach is more likely to provide a secure environment:
A) users having machines that do not execute arbitrary content, that check access based on trust relationships and provide a means of ensuring message confidentiality and integrity
or
B) a special device responsible for implementing all security checks and controls, to which all potentially risky communication is delegated (no cheating by going round the back with those laptops!), able to understand the import of all oommunications (including encrypted ones), the trustworthiness of their origin, their integrity and their direct and indirect consequences of receiving them for all users using any kind of device.
Certainly security is involved in both of these approaches. The difference is that one offers an adequate and appropriate solution, the other looks like it will only ever be a limited band-aid for systems which have shown themselves to be designed without due regard for the environment in which they will be used.
An indulgence with which even the most autere debater can sympathise, I'm sure.
Might one enquire what particular method of logical analysis was applied to yield this gratifying conclusion?
I ask only because I am certain that those of us that daily face difficulties in formulating coherent arguments on technical subject matter would benefit greatly from the innovative perspective that you have developed. Indeed, to deny this audience the prospect of such great personal satisfaction for so little intellectual outlay could, I fear, be interpreted as an act of selfishness on your part, and thereby put at risk the unrivaled esteem accorded to your pronouncements in this forum.
It would be nice to think so.
As a very rough indication of how likely this is, here's a posting I made very recently proposing this kind of development for Linux, together with the extensive (not) discussion it provoked.
Elsewhere, meanwhile, huge volumes of space were taken up with the minutiae of new kernel scheduling models and packaging schemes. This appears to be the level of planning that typical OSS developers feel comfortable with, unfortunately it looks like it will be insufficient to keep Linux-the-platform competitive in the longer term.
Lucky we have Java I guess.
As anyone who actually works with security can tell you, if your network is letting in Trojans and other mail-borne problems, what OS you are running is the least of your concerns.
Oh really?
And how does this wonder detector work? By predicting every potential flaw in your email processing path? You appear to rely on your virus scanners to anticipate every attack, yet the virus scanners did not anticipate Sobig, and in general the strategy is highly questionable as has been pointed out in this forum many times.
A secure system requires a secure platform. Punting the problem to some supposedly omniscient intermediary sounds like an act of either complacency or desperation.
Drooling over that?
Yuk! Look at those ugly borders!
This one is much better. Unique in fact - they use lenses to craftily spread the pixels out, covering the panel edges..
Ah yes. A most subtle aspect of the problem which I confess had previously eluded me.
Your little rant has at best a tenuous connection with what I wrote.
I suggest that people will cooperate if it is in their interest to do so. If the idea of organizing the activities of a group repels you then you are probably best suited to a project small enough for you to accomplish on your own.
Whereas on a Windows 9x machine we press Escape for similar privileges...
You should distinguish between Lisp and Symbolics machines. There are plenty of reasons for believing that a Lisp-like language is a better foundation for information security than the C-like ones - the aspect of integrity that you mention is just one.
Security is about enforcing a complex set of policies, many of which can only be evaluated at run-time. It is at least questionable whether we are really better off building such models on the Windows of today that the Lisp machines of yesterday.
Perhaps he was assuming that the rationalisation effort would be rational?
;-)
E.g. a set of requirements gathered based on usage scenarios then prioritized based on popularity and a solution meeting as many of those requirements as possible designed and implemented.
Irrational developers can have their own project - I hear Mono could use more help
Evidence, if any were needed, of the huge disconnect between what
Out there, Java is probably the number one reason use of Linux is spreading in large organizations. Not unrelatedly, MS are betting the farm on their Java clone - Dotnet will be the biggest thing in the next version of Windows.
Meanwhile, here at
Hmmmm...
Linux really needs a VM. (It could also benefit from that other rumored Longhorn feature, a database-backed file system, but that's another story...).
OK, we can add Java or Python to our systems, but this still leaves Linux-the-platform facing two big challenges:
1. Support apps for kernel functions have to be written in lowest-common-denominator C/C++, making, say, ALSA configuration difficult
2. The number of very different frameworks providing essential functions (desktops, config management, web servers, security admin) is large, also these frameworks do not compare particularly well with Java or Dotnet/Longhorn equivalents.
3. VMs have intrinsic advantages which, when widespread in Longhorn could make Linux-the-platform look obsolescent quite quickly. Security guarantees are one obvious area, application portability is another.
When I think of secure programs, I think of qmail, postfix and djbdns
Sounds like you are working in a very narrow field - a field, apparently, without any business applications at all (unless we count the mail server).
Out where I am we have application servers running web services, ERM and CRM systems, telco provisioning, financial trading and settlement systems, military logistics systems etc.
A very large proportion of these applications both use Java and rely on the Java security framework.
In fact, it's probably a fair bet that Java is the number one choice for building enterprise applications with non-trivial security requirements.
But not generally at the level of granularity of a thread or window, as clearly stated in the parent but omitted in your quote.
1. The term "mission critical application" does not refer to components like the OS.
2. I am interested in discussing the security of "business information systems", the proposition being that they would be better written in Java than in C/C++. If your points are intended for some other kind of audience then make that clear.
3. The reason your non-OS examples aren't convincing is because they predate Java by a long way. They also belong to a restricted class of established infrastructure components which evolve very slowly and are not suceptible to being replaced by newer alternatives, even when better.
4. Despite such obstacles, Java databases having the qualities you mention do exist - I'm surprised you have not encountered Cloudscape or Pointbase, noticed the number of Java components in Oracle Lite.
5. I don't see the relevance of your exposition on disk access, and I fear your knowledge of security models may be less advanced than you suppose. The Java security model does augment the kernel security model - from a Java application's point of view its controls are as completely and effectively enforced as those of the OS.
As I said before, your facts are mostly undisputed but they say little one way or the other regarding how a secure application can best be written. What clues we do have from your examples, where Oracle does not support C stored procedures but does support Java ones, imply that application code should preferably be written in Java.
It does look that way, doesn't it?
/. from other forums.
/. "tendencies" that rule it out as a usable source of information about IT: technology for its own sake; a poor grasp of fundamentals; noticeable difficulties in appreciating general qualities and requirements.
/. could be a whole lot better. Enhance the moderating, archiving, categorizing and searching so that people can share and locate information that is really interesting or insightful (or funny) and you would certainly improve the service, perhaps even to the extent that people would consider paying for it.
In fact, I find that it's the general shallowness of analysis on display here and in similar technical threads that distinguishes
This is partly a consequence of an editorial policy that sustains a band of partisans rather than appealing to an audience with problems to solve, and partly a reflection of the conservative and derivative nature of the prominent open source developments. (Of course there's lots of wonderful innovation out there, but it won't get a fraction of the coverage that something like Mono gets).
This thread alone must have over a dozen examples of vacuous, uninformed, aggressive and semi-literate statements moderated to +5. Do we care? Well, it simply reinforces the impression of those
With a little more work,
I'm sure you didn't mean that as a serious comment - it would betray serious misunderstanding of computing fundamentals otherwise.
1. An OS is not an application
2. There are several databases written in Java
3. All your examples pre-date Java (but three of them find it useful enough to include)
Nothing in your comment implies that C/C++ is more secure than Java, it is simply flag-waving.
Java can do some things by default that C can't, by default--buffer overflow checks, for example--but that doesn't make it necessarily "better".
/. audience.
Strange as it may seem, it does.
Of course, I should immediately qualify this assertion by adding "in the context of implementing general-purpose business information systems", but I doubt if that will be too far from the territory of most of the
The reason is simple. While I can build a system that doesn't suffer from buffer overflows in C, the only way I can guarantee this is by looking through the code - a code audit, in security parlance. In Java, I know up front that there are no such vulnerabilities. With lots of lines of code to check, this guarantee is worth a lot of money, and is therefore clearly and demonstrably better for this (very broad) class of applications.
Similar reasoning can be applied to other intrinsic features of Java as discussed elsewhere, - trusted code, portability guarantees, GC etc.
That's ludicrous.
Not really. If one had to describe Windows' vulnerabilities in a few phrases, buffer overflows, untrusted code and uncontrolled access would be a reasonable summary.
These vulnerabilities are all properly and intrinsically addressed in Java. It is not possible to circumvent the controls by sloppy or malicious programming, therefore Java does enforce secure behaviour.
Joy's comments might represent an exaggeration or simplification, not unreasonable considering the intended audience, but they clearly demonstrate more "insight" than the superficial blather offered above.
[Java] isn't ready to be used for anything with a GUI
Better warn those C/C++ developers using Borland's C++BuilderX IDE.
It's written in Java and uses Swing, just as JBuilder has for years.
Links for the other two products FYI (they both support extensive Web Service dev functions):
JBuilder Enterprise
IBM WebSphere SDK for Web Services (free)