For crying out loud, stop the stupid Java bashing. Yes, the SO/OO GUI is quite slow - especially on Linux - but it's not because of Java. StarOffice/OpenOffice is NOT WRITTEN IN JAVA. So go bashing C/C++ instead, which is what it IS written in, as far as I know.
(1) OpenDivx != DivX. OpenDivX is 100% legal. DivX is a hacked version of Microsoft's MPEG 4 codec. OpenDivX isn't quite as good as DivX at the moment, but I'm sure it will get there soon enough.
(2) If you believe MPEG-1 yields better quality than MPEG-4, then you're either on some bad drugs or you haven't got a clue what you're talking about. A good SBC DivX has *great* quality; give it 2 CDs for space and you practically have the DVD.
/ Peter Schuller
----------------
E-Mail: peter.schuller@infidyne.com
URL: http://www.scode.org
Sci-Fi author don't have it wrong. You have it wrong. In all Sci-Fi movies/series I've seen, FTL travel is achieved thorugh "non-conventional" means. Warp travel (i.e. moving the warp bubble a FTL speeds, not the ship), hyperspace, worm holes - whatever.
One might debate the realism of those various techniques, but relativity is *NOT* an issue. No sci-fi series/movies that I know of claims that you can achieve FTL travel in any practical sense by just accelerating long enough. / Peter Schuller
----------------
E-Mail: peter.schuller@infidyne.com
URL: http://www.scode.org
The cryptography part is interesting, but what about the prospect of communication across unlimited distances?
I have read about quantum entanglement many times before, but I assumed there were some form of problem with it that prevent it to be used for actually communicating data directly.
However this article seems to imply that quantum entanglement *can* indeed be used to directly communicate. Well, that's a *big* deal in my opinion - and on a larger scale than cryptography. If we ever *do* figure out a way to achieve FTL travel, we're still going to have to have some form of near-instant way of *communicating* across such great distances.
Ok, so space travel might not be what everyone was thinking; but I'm surprised I haven't seen quantum entanglement hailed as a communication method in general, if indeed it's currently in a state such that it is possible./p. / Peter Schuller
----------------
E-Mail: peter.schuller@infidyne.com
URL: http://www.scode.org
I agree about mixing HTML and code - however, first of all JSP *does* support the ability to separat presentation from logic, though the use of custom tag libs.
But there are other Java based laternatives, such as Enhydra's XMLC solution where you have 100% complete separation (you modify the HTML through DOM).
And as for "neutreal" JVMs, they *are* fast nowadays. The days of interpreted Java is long gone. LInux, Solaris, WinXXX, True64, AIX - almost anything, has a modern JVM with JIT:ing or some kind of mixed-mode solution (Hotspot style).
/ Peter Schuller
----------------
E-Mail: peter.schuller@infidyne.com
URL: http://www.scode.org
I agree with the conclusion however. At least, if you don't know PHP, perl nor Java, servlets are obviously more difficult than PHP or Perl, simply because it's just yet another application of Java. And in order to use it efficiently, you need to understand OOP, and be familiar with the Java API.
/ Peter Schuller
----------------
E-Mail: peter.schuller@infidyne.com
URL: http://www.scode.org
First of all, servlets *ARE NOT* a scripting language. A servlet is a class that extends javax.servlet.Servlet. Period. The most common form is the javax.servlet.http.HttpServlet. They are classes that implement a certain interface. It's got nothing to do with scripting.
And as has already been pointed out, comparing servlets with PHP is ludicrous. What they should be comparing is *JSP*. JSP (Java Server Pages) are HTML that gets converted into a servlet (and then compiled and run) by the Web Application Server. So yes, servlets are involved. But JSPs clearly fit the description "Java equivalent of PHP" much better than servlets. Servlets are the building blocks of JSP; but comparing PHP to servlets is like comparing JSP to PHP pages without HTML in them (i.e. everything is done in the form of code).
/ Peter Schuller
----------------
E-Mail: peter.schuller@infidyne.com
URL: http://www.scode.org
What I've been able to tell from digging through mailinglist archives is that the bug in 2.95.2 is only triggered for i386 targets - or at least not i686.
PGP is available for many platforms, including Linux. And many E-Mail UA:s support them (mutt, pine, XFMail, etc). It's also free if you use GnuPG, or at least free for non-commercial use if you use the commercial PGP.
Hopefully all code used to communicate with the outside world is written in Java. If this is the case, there will be no buffer overflows and hopefully no bugs related to some script using an insecure command line parameter.
It's a valid concern of course. I personally think that the use of Java (or Smalltalk, etc, etc) is a good choice of platform to lessen the likelyhood of security issues.
The ONLY reason Java is not TRADITIONALLY suitable for a real-time system is because of the garbage collection. HOWEVER, there ARE real-time garbage collection algorithms, and I'm told there are already real-time JVMs in existense.
Garbage collection is not something that it done once in 10 minutes. You make it sound like a Java based server would suddetly "stop" after a few minutes - WRONG.
Point number 1) Even given a PRIMITIVE Java Virtual Machine, GC tends to get done at least once every few seconds, or more often.
Point number 2) Moden JVMs should handle it perfectly with generational and/or incremental GC. Just try running some huge application like Enhydra (www.enhydra.org) and you'll notice it's not a problem.
GC is NOT a problem unless you want a 200 fps in some game and a GC paus takes 10 milliseconds...
It may be fun to shake you aheads against these things when you read about them, and wonder "what's the world coming to?".
But things are really getting out of hand. We constaly learn of how companies (mostly companies anyway) come up with really truly stupid things (like this AT&T business, stupid patents, etc).
I fear that soon these things are going to start to catch on! What if that happens? The world (well, the US anyway unless the madness spreads) will become a greater hell whole than it already is.
Imagine you paying someone for walking on the pavement, for using their broadband access, for looking at a web page, for each key stroke you do on your keyboard.
Something has to be done to prevent this madness (and it really is madness, and I believe those that are behind it know it too - they just think they can still make money off of it, madness or not). Is there no procedure through which citizens or organizations can propose law changes to make these things impossible?
It's not like you're local representative (congressmen I believe it is in the US) is gonig to listen, since the person in question probably have no idea what the "broadband connection" really is, and what role it plays. Similar arguments apply to most of these things.
I am truly scared of this outrageous development.
JavaServer Pages (for smaller stuff) and full-blown Java based web applications (with, for example, Enhydra (www.enhydra.org)) for anything large.
Why?
* Java is fast (and please, don't start dissing Java because it's not natively compiled). Java executes much faster than, say, perl, ASP or PHP. The inital overhead in displaying a JSP is larger than invoking a perl script (assuming you're using mod_perl), but that's not because Java is slow, it's because of all the features the servlet/JSP runner implements.
* Java is OO. IMO, this is a great advantage, although I guess many will disagree (especially here on/.).
* Java is very much suitable for writing anything from small hit counters to large-scale web applications. The reason for this would be obvious to anyone who has programmed Java for a while. I personally can't imagine writing anything large in perl.
* Java is cross-platform.
* Java is a GC:d language (this argument doesn't apply "against" perl of course).
Slashdot Mirror
In Smalltalk there is always #become...
For crying out loud, stop the stupid Java bashing. Yes, the SO/OO GUI is quite slow - especially on Linux - but it's not because of Java. StarOffice/OpenOffice is NOT WRITTEN IN JAVA. So go bashing C/C++ instead, which is what it IS written in, as far as I know.
(1) OpenDivx != DivX. OpenDivX is 100% legal. DivX is a hacked version of Microsoft's MPEG 4 codec. OpenDivX isn't quite as good as DivX at the moment, but I'm sure it will get there soon enough.
(2) If you believe MPEG-1 yields better quality than MPEG-4, then you're either on some bad drugs or you haven't got a clue what you're talking about. A good SBC DivX has *great* quality; give it 2 CDs for space and you practically have the DVD.
/ Peter Schuller
----------------
E-Mail: peter.schuller@infidyne.com
URL: http://www.scode.org
Sci-Fi author don't have it wrong. You have it wrong. In all Sci-Fi movies/series I've seen, FTL travel is achieved thorugh "non-conventional" means. Warp travel (i.e. moving the warp bubble a FTL speeds, not the ship), hyperspace, worm holes - whatever.
One might debate the realism of those various techniques, but relativity is *NOT* an issue. No sci-fi series/movies that I know of claims that you can achieve FTL travel in any practical sense by just accelerating long enough.
/ Peter Schuller
----------------
E-Mail: peter.schuller@infidyne.com
URL: http://www.scode.org
That's what I thought.
/ Peter Schuller
----------------
E-Mail: peter.schuller@infidyne.com
URL: http://www.scode.org
The cryptography part is interesting, but what about the prospect of communication across unlimited distances?
I have read about quantum entanglement many times before, but I assumed there were some form of problem with it that prevent it to be used for actually communicating data directly.
However this article seems to imply that quantum entanglement *can* indeed be used to directly communicate. Well, that's a *big* deal in my opinion - and on a larger scale than cryptography. If we ever *do* figure out a way to achieve FTL travel, we're still going to have to have some form of near-instant way of *communicating* across such great distances.
Ok, so space travel might not be what everyone was thinking; but I'm surprised I haven't seen quantum entanglement hailed as a communication method in general, if indeed it's currently in a state such that it is possible. /p.
/ Peter Schuller
----------------
E-Mail: peter.schuller@infidyne.com
URL: http://www.scode.org
I agree about mixing HTML and code - however, first of all JSP *does* support the ability to separat presentation from logic, though the use of custom tag libs.
But there are other Java based laternatives, such as Enhydra's XMLC solution where you have 100% complete separation (you modify the HTML through DOM).
And as for "neutreal" JVMs, they *are* fast nowadays. The days of interpreted Java is long gone. LInux, Solaris, WinXXX, True64, AIX - almost anything, has a modern JVM with JIT:ing or some kind of mixed-mode solution (Hotspot style).
/ Peter Schuller
----------------
E-Mail: peter.schuller@infidyne.com
URL: http://www.scode.org
I agree with the conclusion however. At least, if you don't know PHP, perl nor Java, servlets are obviously more difficult than PHP or Perl, simply because it's just yet another application of Java. And in order to use it efficiently, you need to understand OOP, and be familiar with the Java API.
/ Peter Schuller
----------------
E-Mail: peter.schuller@infidyne.com
URL: http://www.scode.org
First of all, servlets *ARE NOT* a scripting language. A servlet is a class that extends javax.servlet.Servlet. Period. The most common form is the javax.servlet.http.HttpServlet. They are classes that implement a certain interface. It's got nothing to do with scripting.
And as has already been pointed out, comparing servlets with PHP is ludicrous. What they should be comparing is *JSP*. JSP (Java Server Pages) are HTML that gets converted into a servlet (and then compiled and run) by the Web Application Server. So yes, servlets are involved. But JSPs clearly fit the description "Java equivalent of PHP" much better than servlets. Servlets are the building blocks of JSP; but comparing PHP to servlets is like comparing JSP to PHP pages without HTML in them (i.e. everything is done in the form of code).
/ Peter Schuller
----------------
E-Mail: peter.schuller@infidyne.com
URL: http://www.scode.org
Thanks...
What I've been able to tell from digging through mailinglist archives is that the bug in 2.95.2 is only triggered for i386 targets - or at least not i686.
It certainly wasn't out of it in my copy of 2.4.1.
Unless the Debian guys put it back in.
Does anyone know if 2.4 still requires an old version of gcc?
Or; can anyone confirm that I'm "safe" when compiling to the i686 target with gcc 2.95.2?
Sure. Might be a good idea too... It was done with good effect in The 13th Floor.
And of course, one can never know whether the "real" world is a simulation or not...
Right. And since PGP is avilable for so many platforms, point the person you are communicating with to it aswell. Problem solved.
PGP is available for many platforms, including Linux. And many E-Mail UA:s support them (mutt, pine, XFMail, etc). It's also free if you use GnuPG, or at least free for non-commercial use if you use the commercial PGP.
Hopefully all code used to communicate with the outside world is written in Java. If this is the case, there will be no buffer overflows and hopefully no bugs related to some script using an insecure command line parameter.
It's a valid concern of course. I personally think that the use of Java (or Smalltalk, etc, etc) is a good choice of platform to lessen the likelyhood of security issues.
You clueless anti-Java people need to shut up.
The ONLY reason Java is not TRADITIONALLY suitable for a real-time system is because of the garbage collection. HOWEVER, there ARE real-time garbage collection algorithms, and I'm told there are already real-time JVMs in existense.
How are script kiddies in any way related to Java?
And on the latest Volano benchmarks, IBM JDK 1.3 BEATS TowerJ. Native code can't be beaten my ass.
Garbage collection is not something that it done once in 10 minutes. You make it sound like a Java based server would suddetly "stop" after a few minutes - WRONG.
Point number 1) Even given a PRIMITIVE Java Virtual Machine, GC tends to get done at least once every few seconds, or more often.
Point number 2) Moden JVMs should handle it perfectly with generational and/or incremental GC. Just try running some huge application like Enhydra (www.enhydra.org) and you'll notice it's not a problem.
GC is NOT a problem unless you want a 200 fps in some game and a GC paus takes 10 milliseconds...
Smalltalk!
I'm a huge Java fan, but I've always felt Smalltalks 100 % OO-ness and it syntax is a good
thing.
It may be fun to shake you aheads against these things when you read about them, and wonder "what's the world coming to?". But things are really getting out of hand. We constaly learn of how companies (mostly companies anyway) come up with really truly stupid things (like this AT&T business, stupid patents, etc). I fear that soon these things are going to start to catch on! What if that happens? The world (well, the US anyway unless the madness spreads) will become a greater hell whole than it already is. Imagine you paying someone for walking on the pavement, for using their broadband access, for looking at a web page, for each key stroke you do on your keyboard. Something has to be done to prevent this madness (and it really is madness, and I believe those that are behind it know it too - they just think they can still make money off of it, madness or not). Is there no procedure through which citizens or organizations can propose law changes to make these things impossible? It's not like you're local representative (congressmen I believe it is in the US) is gonig to listen, since the person in question probably have no idea what the "broadband connection" really is, and what role it plays. Similar arguments apply to most of these things. I am truly scared of this outrageous development.
Then take a proper multiple-process JVM and compare THAT with you're native code, and see which one hogs the most resouces...
You are making a complete unfair comparison.
JavaServer Pages (for smaller stuff) and full-blown Java based web applications (with, for example, Enhydra (www.enhydra.org)) for anything large.
/.).
Why?
* Java is fast (and please, don't start dissing Java because it's not natively compiled). Java executes much faster than, say, perl, ASP or PHP. The inital overhead in displaying a JSP is larger than invoking a perl script (assuming you're using mod_perl), but that's not because Java is slow, it's because of all the features the servlet/JSP runner implements.
* Java is OO. IMO, this is a great advantage, although I guess many will disagree (especially here on
* Java is very much suitable for writing anything from small hit counters to large-scale web applications. The reason for this would be obvious to anyone who has programmed Java for a while. I personally can't imagine writing anything large in perl.
* Java is cross-platform.
* Java is a GC:d language (this argument doesn't apply "against" perl of course).
It does indeed, just as 1.1.8/Linux/IBM.