I think it would be fair to summmarise as Weimar politics being complicated, so votes and alliances need a lot of analysis - the conventional conservatives were convinced they could manipulate Hitler, for instance, once they'd let him in the govt.
Michael Burleigh's Third Reich has a good section on this.
Thank you for this important contribution. Many of us would have previously been unaware that all Arab states were totalitarian, or indeed that Arab states and Muslim states were synonymous. And regarding the universal intolerance of other religions, one dreads to think what might have happened if it had become known that Iraq's former Deputy Prime Minister was actually a Christian!
Heaven forbid that we should descend to the level of making sweeping remarks about cultures we know little about! And is it too much to ask that Slashdot not limit the plaudits we can confer on such incisive comments to merely 'insightful'? Surely a new category of 'revelatory' is justified, nay, demanded, for postings such as these?
Indeed. I couldn't believe this when I encountered it, but it's true. My desktop now only does powersaving when in Linux!
I heard that Win95 worked OK, but somebody at MS decided that as they couldn't figure out how to do IRQ allocation right for the supposedly more complex 'server market', they wouldn't do it at all, and everyone would get to share IRQ 11. Or something.
I hope that the above post is part of an elaborate joke. Otherwise, looking at this and the 455 other messages comprising the debate so far, I don't think/. is about to improve its its position in the 'where to come for Java enlightenment' stakes.
1) Re: swapping. Java memory management will always be superior to that of the OS - OS constraints should never be greater than those applied by the VM. The memory limit of a Java process is defined with the -Xmx=nnn parameter. For production use, this should never be more than the physical memory actually available to the Java process.
2) Re: CPU cache: By the time a CPU executes compiled code, bytecodes are nowhere near the CPU cache (they were never near the instruction cache). The fact that the code was earlier produced from bytecodes is completely irrelevant. Furthermore, bytecode compilation is persistent - compiled code is never destroyed for memory management purposes.
3) Java and C++ optimizations: by definition, a Java JIT compiler can make all the optimizations a static compiler can make, and then some. This is because: a) the bytecode is the semantic equivalent of the source, so all source optimizations can be applied; b) it additionally has access to the complete code base, not just the equivalent of a single source file and c) it has access to the dynamic characteristics of a program, such as "branch taken" metrics, meaning that potentially indefinite refinements of the program structure are possible.
For those that are true seekers after knowledge, I think it is safe to say that your reading time will be better spent with Sun's papers on GC or VM design, starting here, and perhaps comparing mechanisms with those of LISP machines, Dotnet or the Parrot VM.
I also recommend getting up to speed with the new I/O, printing and regexp features found in 1.4 - a good start is Travis's JDK 1.4 tutorial, though it does not cover everything new. .
Apparently the 'serious study' of Java GC you refer to has yet to absorb the fact that there are several dozen implementations widely available, many based on radically different algorithms.
In fact, the 1.4.x Sun VM itself offers two alternatives for both the new and tenured heaps, not to mention the dozens of others available in IBM, BEA and other vendors' products.
I thought you were going to go on and suggest that a late-compile language like Scheme would overcome Linus's objection to microkernels.
Idea being that glue code necessary for modularization disappears as a result of run-time optimization, as in Java.
Portable apps come to Linux
on
Eyes on Karamba
·
· Score: 2, Insightful
Ah, Linux, dontcha luv it?
How bizarre would it be if this means that developers finally find a reason to settle on a Linux VM (that's Python) as part of creating kewl desktop themes?
Who needs a strategic plan anyway? And would Dotnet be enjoying more success if it offered semi-transparent weather reports?
Because software needs to be thoroughly tested before it can be called reliable.
This is not strictly true. I know that my Java program will never have a buffer overrun because it is impossible for me to produce JVM instructions that corrupt buffers or alter pointers. Therefore, I can download and run any Java program to my Java smartphone without invalidating the phone's network certification.
Throughout this discussion, I've noticed that/. contributors have consistently ignored the role played by trusted components such as VMs and safe compilers. Bottom line is that we all need to get away from the mindset engendered by years of Unix and C hacking and recognise that not all problems are going to be solved by employing programming whizzes or spending a fortune on testing.
I doubt if many people with a day-to-day concern with reliable software would find this very insightful.
Buggy software is often also late software: both are symptoms of deficient processes and tools, whether it's failing to properly track requirements at the beginning or that huge overrun at the end referred to as 'integration testing'.
For example, it is a fact that choosing Java or C# for a project over C++ will eliminate whole classes of potential faults from the product. Something like Eiffel might do better still. Yet simple conservatism will ensure that many projects (especially Linux projects) will ignore such basic factors and proceed to develop systems that take inordinate amounts of time to reach acceptable levels of quality.
I don't see that groups taking such decisions deserve the level of sympathy you imply.
You stated that opening the source code was "unnecessary and even risky" to the notion of auditing it. There is no such relationship.
It is also immaterial what the source of a change is - you appear to be agreeing with me insofar as what matters is simply whether the code is that which was certified or not. Any change will invalidate this guarantee.
Regarding whether source or binaries are signed, you are touching on the notion of a Trusted Computing Base, itself a set of certified components, which might encompass an OS and compiler. If only the OS is in the TCB, then the certifier would be obliged to ship binaries, whereas if the compiler is included he can ship source.
In the early 80s, software mostly came as BASIC source code
...or as tokenised BASIC "executables", of course.
The interesting point here is that the interpreter approximated a secure platform, meaning that the whole class of buffer overflows and wild pointer problems we got used to later were absent. This level of assurance only reappeared in mainstream IT with the advent of Java.
Auditing CAN be done better by trusted 3rd parties--which makes opening the source code unnecessary and even risky in some cases.
I think you're conflating the idea of visibility and control. There's no reason that a 3rd party can't sign a distribution - this happens already. Of course, if a recipient changes the code then the certificate no longer applies.
I doubt that you'd accept the idea that cars should be exempt from safety standard if they provided you with the blueprints
Quite right, but a car represents a package that has very little value if it is unsafe, as opposed to, say, a collection of car parts. Free Software, by contrast, may well have value without proof of quality.
In time, I think the distinction between distributing information and distributing programs will blur and elements of trust and certification will apply similarly to both. We do this already to a certain extent, ascribing greater trust to an the Reuters than to a rumour board.
Indeed. In fact, Java is probably the greatest example of IT innovation in the last decade or so, and that was specifically designed to address security requirements.
Don't forget that you can separate the role of a certifier (of integrity, of quality etc.) from the software owner or the development group.
In fact, this probably happens inside a commercial shops anyway.
Just as I trust SuSE to pull together a decent set of Linux apps for me, I might trust them or some other organization to certify a package by signing the code or similar technique.
Perhaps it's not who is first with an innovation that matters, but who recognises its importance and exploits it?
By all means point out that Dotnet is a clone of Java. The key issue is that MS have now altered their whole OS strategy to embrace it, while Linux is left with a comparatively unintegrated and confused strategy.
One example: an earlier comment boasted that MS would never have a package distribution model to match Linux (presumably a reference to RPM or Debian). Thanks to Dotnet, it now appears that Windows is about to leave Linux far behind in this area.
the.NET Framework, which many of us see as a "hub" for object integration
While, unsurprisingly, many others of us simply see Dotnet as a rehash of Java.
The hard problems of interoperability are not addressed by either. For example, something as simple as pass-by-reference or pass-by-value should be dictated by configuration rather than hard-coded, yet practitioners seem to be under the impression that the solution lies in implementing 'value objects' rather than fixing the platform itself.
As long as technologists continue to delude themselves that 'bridges', 'hubs' or other integration band-aids represent progress, efficient distributed or component-based systems will elude us.
RPC-like mechanisms can never be solutions in themselves.
a) I'm not quite sure what your perspective is, but it is not that of a typical technology consumer. Such people are not going to compile C++ applications.
b) There are plenty of examples of non-platform specific Java apps - across phones, PDAs and mainframes. Nothing else comes close in achieving portability.
c) I'm not sure how you gauge this, anyway, appeals to vague sentiment are of little value in such a debate. I trust you will be making Microsoft aware of your findings so that they can halt their efforts porting Office to C#?
I wonder if this is a legacy of its Windows origins?
I think it's a legacy of its C++ origins - applications like this should be moving to Java.
Anyone know when Microsoft will have moved Office to Dotnet (CLR)? Certainly when this happens they'll gain a lot of agility insofar as supporting different hardware platforms is concerned.
Slashdot Mirror
I think it would be fair to summmarise as Weimar politics being complicated, so votes and alliances need a lot of analysis - the conventional conservatives were convinced they could manipulate Hitler, for instance, once they'd let him in the govt.
Michael Burleigh's Third Reich has a good section on this.
Thank you for this important contribution. Many of us would have previously been unaware that all Arab states were totalitarian, or indeed that Arab states and Muslim states were synonymous. And regarding the universal intolerance of other religions, one dreads to think what might have happened if it had become known that Iraq's former Deputy Prime Minister was actually a Christian!
Heaven forbid that we should descend to the level of making sweeping remarks about cultures we know little about! And is it too much to ask that Slashdot not limit the plaudits we can confer on such incisive comments to merely 'insightful'? Surely a new category of 'revelatory' is justified, nay, demanded, for postings such as these?
Are you sure? All musical texts and scores I've seen have this symbol as a superscript. I don't think proper books use # for sharp.
Indeed. I couldn't believe this when I encountered it, but it's true. My desktop now only does powersaving when in Linux!
I heard that Win95 worked OK, but somebody at MS decided that as they couldn't figure out how to do IRQ allocation right for the supposedly more complex 'server market', they wouldn't do it at all, and everyone would get to share IRQ 11. Or something.
I hope that the above post is part of an elaborate joke. Otherwise, looking at this and the 455 other messages comprising the debate so far, I don't think /. is about to improve its its position in the 'where to come for Java enlightenment' stakes.
1) Re: swapping. Java memory management will always be superior to that of the OS - OS constraints should never be greater than those applied by the VM. The memory limit of a Java process is defined with the -Xmx=nnn parameter. For production use, this should never be more than the physical memory actually available to the Java process.
2) Re: CPU cache: By the time a CPU executes compiled code, bytecodes are nowhere near the CPU cache (they were never near the instruction cache). The fact that the code was earlier produced from bytecodes is completely irrelevant. Furthermore, bytecode compilation is persistent - compiled code is never destroyed for memory management purposes.
3) Java and C++ optimizations: by definition, a Java JIT compiler can make all the optimizations a static compiler can make, and then some. This is because: a) the bytecode is the semantic equivalent of the source, so all source optimizations can be applied; b) it additionally has access to the complete code base, not just the equivalent of a single source file and c) it has access to the dynamic characteristics of a program, such as "branch taken" metrics, meaning that potentially indefinite refinements of the program structure are possible.
For those that are true seekers after knowledge, I think it is safe to say that your reading time will be better spent with Sun's papers on GC or VM design, starting here, and perhaps comparing mechanisms with those of LISP machines, Dotnet or the Parrot VM.
I also recommend getting up to speed with the new I/O, printing and regexp features found in 1.4 - a good start is Travis's JDK 1.4 tutorial, though it does not cover everything new.
.
Apparently the 'serious study' of Java GC you refer to has yet to absorb the fact that there are several dozen implementations widely available, many based on radically different algorithms.
In fact, the 1.4.x Sun VM itself offers two alternatives for both the new and tenured heaps, not to mention the dozens of others available in IBM, BEA and other vendors' products.
Were you running with -Dcompiler=none? If not, how did you manage to get Java running in interpreted mode?
Yes, they're copying. It's called capitalism
Ah, so P2P file traders are entrepreneurs... jolly good!
Y'know, I had a feeling that Capitalism involved something along the lines of:
1) Defining something as a commodity
2) Protecting ownership of it
3) Providing a means of exchanging it in a competitive marketplace
Hmm... these principles don't seem to explain that 'copying' thing very well - what else could be wrong?
Indeed.
I thought you were going to go on and suggest that a late-compile language like Scheme would overcome Linus's objection to microkernels.
Idea being that glue code necessary for modularization disappears as a result of run-time optimization, as in Java.
Ah, Linux, dontcha luv it?
How bizarre would it be if this means that developers finally find a reason to settle on a Linux VM (that's Python) as part of creating kewl desktop themes?
Who needs a strategic plan anyway? And would Dotnet be enjoying more success if it offered semi-transparent weather reports?
The LEO veterans have a web site with some interesting pics here.
Y'know, that Leo 1 desk looks awfully like the computer that terrorized Emma Peel in The House that Jack Built. Spooky!
Surely it's obvious that adding angle brackets can turn any dull old sequence of name/value pairs into a powerful data warehouse?
Well, it delegates them to a much smaller, more generic, more easily testable unit - is that what you mean? I'd say that this counts as progress.
Because software needs to be thoroughly tested before it can be called reliable.
/. contributors have consistently ignored the role played by trusted components such as VMs and safe compilers. Bottom line is that we all need to get away from the mindset engendered by years of Unix and C hacking and recognise that not all problems are going to be solved by employing programming whizzes or spending a fortune on testing.
This is not strictly true. I know that my Java program will never have a buffer overrun because it is impossible for me to produce JVM instructions that corrupt buffers or alter pointers. Therefore, I can download and run any Java program to my Java smartphone without invalidating the phone's network certification.
Throughout this discussion, I've noticed that
I doubt if many people with a day-to-day concern with reliable software would find this very insightful.
Buggy software is often also late software: both are symptoms of deficient processes and tools, whether it's failing to properly track requirements at the beginning or that huge overrun at the end referred to as 'integration testing'.
For example, it is a fact that choosing Java or C# for a project over C++ will eliminate whole classes of potential faults from the product. Something like Eiffel might do better still. Yet simple conservatism will ensure that many projects (especially Linux projects) will ignore such basic factors and proceed to develop systems that take inordinate amounts of time to reach acceptable levels of quality.
I don't see that groups taking such decisions deserve the level of sympathy you imply.
You stated that opening the source code was "unnecessary and even risky" to the notion of auditing it. There is no such relationship.
It is also immaterial what the source of a change is - you appear to be agreeing with me insofar as what matters is simply whether the code is that which was certified or not. Any change will invalidate this guarantee.
Regarding whether source or binaries are signed, you are touching on the notion of a Trusted Computing Base, itself a set of certified components, which might encompass an OS and compiler. If only the OS is in the TCB, then the certifier would be obliged to ship binaries, whereas if the compiler is included he can ship source.
The interesting point here is that the interpreter approximated a secure platform, meaning that the whole class of buffer overflows and wild pointer problems we got used to later were absent. This level of assurance only reappeared in mainstream IT with the advent of Java.
Auditing CAN be done better by trusted 3rd parties--which makes opening the source code unnecessary and even risky in some cases.
I think you're conflating the idea of visibility and control. There's no reason that a 3rd party can't sign a distribution - this happens already. Of course, if a recipient changes the code then the certificate no longer applies.
I doubt that you'd accept the idea that cars should be exempt from safety standard if they provided you with the blueprints
Quite right, but a car represents a package that has very little value if it is unsafe, as opposed to, say, a collection of car parts. Free Software, by contrast, may well have value without proof of quality.
In time, I think the distinction between distributing information and distributing programs will blur and elements of trust and certification will apply similarly to both. We do this already to a certain extent, ascribing greater trust to an the Reuters than to a rumour board.
Indeed. In fact, Java is probably the greatest example of IT innovation in the last decade or so, and that was specifically designed to address security requirements.
Don't forget that you can separate the role of a certifier (of integrity, of quality etc.) from the software owner or the development group.
In fact, this probably happens inside a commercial shops anyway.
Just as I trust SuSE to pull together a decent set of Linux apps for me, I might trust them or some other organization to certify a package by signing the code or similar technique.
Perhaps it's not who is first with an innovation that matters, but who recognises its importance and exploits it?
By all means point out that Dotnet is a clone of Java. The key issue is that MS have now altered their whole OS strategy to embrace it, while Linux is left with a comparatively unintegrated and confused strategy.
One example: an earlier comment boasted that MS would never have a package distribution model to match Linux (presumably a reference to RPM or Debian). Thanks to Dotnet, it now appears that Windows is about to leave Linux far behind in this area.
the .NET Framework, which many of us see as a "hub" for object integration
While, unsurprisingly, many others of us simply see Dotnet as a rehash of Java.
The hard problems of interoperability are not addressed by either. For example, something as simple as pass-by-reference or pass-by-value should be dictated by configuration rather than hard-coded, yet practitioners seem to be under the impression that the solution lies in implementing 'value objects' rather than fixing the platform itself.
As long as technologists continue to delude themselves that 'bridges', 'hubs' or other integration band-aids represent progress, efficient distributed or component-based systems will elude us.
RPC-like mechanisms can never be solutions in themselves.
a) I'm not quite sure what your perspective is, but it is not that of a typical technology consumer. Such people are not going to compile C++ applications.
b) There are plenty of examples of non-platform specific Java apps - across phones, PDAs and mainframes. Nothing else comes close in achieving portability.
c) I'm not sure how you gauge this, anyway, appeals to vague sentiment are of little value in such a debate. I trust you will be making Microsoft aware of your findings so that they can halt their efforts porting Office to C#?
I wonder if this is a legacy of its Windows origins?
I think it's a legacy of its C++ origins - applications like this should be moving to Java.
Anyone know when Microsoft will have moved Office to Dotnet (CLR)? Certainly when this happens they'll gain a lot of agility insofar as supporting different hardware platforms is concerned.