For an example of how NOT to code, why not check out some Perl Obfuscation? I think it's a great thing to look at, even though (or especially because) I really don't like Perl as a language (heresy! heresy! Don't flame me please, I've heard the arguments).
I wonder how this compares with Sun's MAJC processor, which also runs Java natively... personally, I would pay Bucks for a PCI card with a secondary CPU to which my Java apps would be offloaded (but not being a computer engineer, I don't even know if that's feasible).
I hereby patent Computational, Restorative, Active Segfault Heuristics (CRASH) which is a mechanism for ensuring system integrity in a small-scale, limited resource computer system (PC). The CRASH algorithm is implemented at the register level within the CPU, and works by examining every byte that is executed by the microprocessor, looking for operations that may eventually complete. The algorithm marks these processes as value-degrading (since finished processes result in less CPU utilization and therefore less value for the owner's money), and aborts all running processes on the machine.
CRASH then helpfully alerts the user to the problem with a friendly blue screen, and requires the user to reboot the machine in order to preserve data integrity and restore 100% CPU utilization.
I, as the rightful owner of this patent (I can demonstrate that I successfully CRASHed a computer as early as 1979), intend to sue any and all companies that infringe upon my patent, starting with Microsoft, who has deliberately implemented my C.R.A.S.H. algorithm throughout their operating system and applications. They are also the largest (and richest) violator of this patent.
I run a web site where users can submit music, reviews, and other stuff (Sessioneer); some of the music posted is probably copyrighted (I don't monitor it very effectively). I tried to address these issues by issuing a contract upon registration, which the user implicitly agrees to by using the site.
I "borrowed" the legal text from another site and modified the text to suit my needs. I'm not a lawyer, but I think it gets the point across. Also, the nature of the material on the site is such that copyrights are rarely enforced (it's Irish traditional dance music).... so far I haven't had a problem, but I'm probably still exposed to some degree.
A couple of years ago, Java was still very much in its infancy. Besides that, it's well-known that Java support in both major browsers sucked then and sucks now, hence the Java plug-in. Not that it's much better, but for different reasons (memory use, hassle, etc.). At least it's complete and pretty consistent; in any case it's the responsibility of the browser vendor to make sure its particular version of the JVM runs in a sandbox.
As I said before, JavaScript has little or no relationship to Java, and in browsers it's implemented by the browser vendor, so you can't really blame any security holes for JavaScript on Sun or Java.
You don't have a clue what you're talking about. For example:
- Most (and best) use of Java is on the server side, not the client side.
- Java applets on web pages are useless 90% of the time, but very useful the other 10% of the time. Try developing a complex web-based application (not a simple vanity page) without using client-side ActiveX, Java, Shockwave or DHTML and you'll find that these things can make a big difference in the either the usability or basic capabilities of the app.
- Java applets are not compiled on the user side; they're compiled by the developer and then executed by a virtual machine on the user side. If you're looking at actual code you're looking at JavaScript (as a previous reader pointed out). Java has absolutely nothing to do with JavaScript.
- Java offers many features that drastically improve the reliability and robustness of Java code: garbage collection, enforced error handling, the use of bytecode instead of machine code (which prevents buffer overflows, one of the biggest holes for hackers), great compile-time checking, clean frameworks for collections, multi-threading, distributed code, etc. etc. etc.
- In the implementations where Java is most used, its features allow designs which are more scalable and flexible than what you could get with a more limited language, despite its slower runtime speed. Check out any of the Enterprise JavaBean servers (WebLogic for example).
With regards to the original post (since we seem to have gotten a bit off-topic), I don't think people ought to blindly have faith in technology's ability to save the world. Our technologies have flaws because we have an imperfect understanding of both 1) our own goals and 2) how best to achieve them. But so what? That doesn't have any bearing on whether we ought to try to understand these things. Java is one example of a technology designed with a "make-it-better" goal, not a "make-it-cool" goal (though I think it's pretty cool).
I think (correct me if I'm wrong) that he's referring to situations where he doesn't want to keep a reference to the object, but wants to intervene when the object gets gc'd. Java allows you to do this, if I remember correctly, by using soft references with a ReferenceQueue (see the Java 2 java.lang.ref package). You can set it up so that you can "rescue" your object from being gc'd.
Likewise, this package allows you to keep references to objects but still let them be gc'd; in that case, you would need to check before you use it, and recreate it if necessary.
Mostly good points. However (playing devil's advocate) I have a few observations:
>>I would like to expand on them a little: there
>>are already so many laws that even a lawyer
>>can't know what all
Yes there are probably too many laws.
>>The world is a screwed up place because
>>there are people who want it that way.
That's one out of many possible reasons. Also don't forget laziness, ignorance, and a host of other reasons having to do with people's good intentions having unintended side effects. I think it's pretty simplistic and short-sighted to *just* pin it on "the bad guys".
>>if you'll check, you'll discover that
>>most of them went into law enforcement.
Law enforcement officers don't make the laws, at least in America. Of course, I'm sure quite a few bullies went into politics (politicians are by definition power-hungry).
>>People can be divided into two broad
>>emotional groups
This statement appears to me to be another attempt to "abstract" the problem into something simpler, but less accurate.
The whole system of law-making seems akin to that of developing requirements and specs for a software application. In both, you have to balance the simplicity of the laws/reqs versus the need for the application to actually address the subtle requirements of the business. Sure, you can simplify the app, but you can easily end up with a too-simple approximation of a solution. Or, you can design to the n-th degree and spend way too much time and money developing a bloated app that tries to address every little potential issue that might come up.
I think here in America, our bill of rights forces us to precisely address many issues that can be "approximated" through individual judgment, often unfairly, in other countries. Simply put, one reason we have a lot of laws is because people demand them.
Our system has no checks to prevent bloated legal code, and a few which promote it. Maybe we ought to stop finger-pointing and start thinking about how we can make the system better.
I agree completely - it's tremendously difficult to build a robust web app these days and still keep the code maintainable and clean, and BXXP sounds like something that (along with XML) could really clean things up and make the environment more like an environment and less like the wild west.
Speaking of XML, I wonder how this might fit in with XUL and/or other proposed standards for building XML-based GUI's? I think I see lots of potential for BXXP to provide a clean way to integrate an XML-based GUI with server processing. For example, the dependent-list problem - you can kluge this right now with DHTML and iframes, but I can see how BXXP might allow you to keep a channel open for updating the GUI on the fly....
I think a big reason that many people are switching, and have switched to Java is that Java blows VB out of the water on features - especially features critical for large, serious projects. By this I mean its superior error-handling, inheritance, documentation support, garbage collection, etc. etc. Raw speed is less of an issue for big apps than the maintainability and stability of the code, which is why people with real needs use a language that isn't a toy.
I think the only hope Microsoft has of getting back in the game is to starting supporting those features - I don't think they can compete on price, since free competition is available, and their large "mindshare" advantage is eroding rapidly. So VB 7, when (if) it comes out, is supposed to offer all the whiz-bang stuff Java has; in fact if you read the feature list, it looks like it was taken directly from Java. But it'll be years behind, and probably buggy until the third release.
So to fill the void MS announces C#... the only problem is that I don't see any features in C# that aren't already in Java, other than possibly "language independence". I suppose this means you can compile C# objects from source code in other languages, sort of how you can do ActiveX objects now (!) Big deal - you can already use other languages to create compiled Java classes, and that's not necessarily a good thing anyway, depending on how good/well-supported the other features of the other language are.
All in all, there's nothing in the C# announcement that would make me switch from Java, or even from VB 7 when it comes out (I'm a SCJP, but use VB for clients all the time).
I seem to remember reading somewhere that for most of the current batch of e-books, the orientation of the LCD screen is 90 degrees off - that is, it's rotated so that the pixels go R-G-B vertically, not horizontally. This makes the technique pretty useless for text on these devices.
Aside from the speed-of-fix argument, consider that NO good encryption/authentication protocol relies upon its algorithm being secret. People WILL find out how it works.
Any good encryption algorithm will still be effective, even if (and because) its algorithm is widely known; it will rely on 1) passwords or keys being kept secret by the users, and 2) hackers not having the computational power available to break in without the key.
Slashdot Mirror
Can't somebody just point a strong telescope at the moon and see if the flag is there? That should prove it once and for all, right?
For an example of how NOT to code, why not check out some Perl Obfuscation? I think it's a great thing to look at, even though (or especially because) I really don't like Perl as a language (heresy! heresy! Don't flame me please, I've heard the arguments).
I wonder how this compares with Sun's MAJC processor, which also runs Java natively... personally, I would pay Bucks for a PCI card with a secondary CPU to which my Java apps would be offloaded (but not being a computer engineer, I don't even know if that's feasible).
CRASH then helpfully alerts the user to the problem with a friendly blue screen, and requires the user to reboot the machine in order to preserve data integrity and restore 100% CPU utilization.
I, as the rightful owner of this patent (I can demonstrate that I successfully CRASHed a computer as early as 1979), intend to sue any and all companies that infringe upon my patent, starting with Microsoft, who has deliberately implemented my C.R.A.S.H. algorithm throughout their operating system and applications. They are also the largest (and richest) violator of this patent.
I "borrowed" the legal text from another site and modified the text to suit my needs. I'm not a lawyer, but I think it gets the point across. Also, the nature of the material on the site is such that copyrights are rarely enforced (it's Irish traditional dance music).... so far I haven't had a problem, but I'm probably still exposed to some degree.
As I said before, JavaScript has little or no relationship to Java, and in browsers it's implemented by the browser vendor, so you can't really blame any security holes for JavaScript on Sun or Java.
- Java applets are not compiled on the user side; they're compiled by the developer and then executed by a virtual machine on the user side. If you're looking at actual code you're looking at JavaScript (as a previous reader pointed out). Java has absolutely nothing to do with JavaScript.
- Java offers many features that drastically improve the reliability and robustness of Java code: garbage collection, enforced error handling, the use of bytecode instead of machine code (which prevents buffer overflows, one of the biggest holes for hackers), great compile-time checking, clean frameworks for collections, multi-threading, distributed code, etc. etc. etc.
- In the implementations where Java is most used, its features allow designs which are more scalable and flexible than what you could get with a more limited language, despite its slower runtime speed. Check out any of the Enterprise JavaBean servers (WebLogic for example).
With regards to the original post (since we seem to have gotten a bit off-topic), I don't think people ought to blindly have faith in technology's ability to save the world. Our technologies have flaws because we have an imperfect understanding of both 1) our own goals and 2) how best to achieve them. But so what? That doesn't have any bearing on whether we ought to try to understand these things. Java is one example of a technology designed with a "make-it-better" goal, not a "make-it-cool" goal (though I think it's pretty cool).
Likewise, this package allows you to keep references to objects but still let them be gc'd; in that case, you would need to check before you use it, and recreate it if necessary.
>>I would like to expand on them a little: there >>are already so many laws that even a lawyer >>can't know what all
Yes there are probably too many laws.
>>The world is a screwed up place because >>there are people who want it that way.
That's one out of many possible reasons. Also don't forget laziness, ignorance, and a host of other reasons having to do with people's good intentions having unintended side effects. I think it's pretty simplistic and short-sighted to *just* pin it on "the bad guys".
>>if you'll check, you'll discover that >>most of them went into law enforcement.
Law enforcement officers don't make the laws, at least in America. Of course, I'm sure quite a few bullies went into politics (politicians are by definition power-hungry).
>>People can be divided into two broad >>emotional groups
This statement appears to me to be another attempt to "abstract" the problem into something simpler, but less accurate.
The whole system of law-making seems akin to that of developing requirements and specs for a software application. In both, you have to balance the simplicity of the laws/reqs versus the need for the application to actually address the subtle requirements of the business. Sure, you can simplify the app, but you can easily end up with a too-simple approximation of a solution. Or, you can design to the n-th degree and spend way too much time and money developing a bloated app that tries to address every little potential issue that might come up.
I think here in America, our bill of rights forces us to precisely address many issues that can be "approximated" through individual judgment, often unfairly, in other countries. Simply put, one reason we have a lot of laws is because people demand them.
Our system has no checks to prevent bloated legal code, and a few which promote it. Maybe we ought to stop finger-pointing and start thinking about how we can make the system better.
Maybe Ingo would like to write us a JVM that runs in kernel space? ;-)
SlipJig
Speaking of XML, I wonder how this might fit in with XUL and/or other proposed standards for building XML-based GUI's? I think I see lots of potential for BXXP to provide a clean way to integrate an XML-based GUI with server processing. For example, the dependent-list problem - you can kluge this right now with DHTML and iframes, but I can see how BXXP might allow you to keep a channel open for updating the GUI on the fly....
I think the only hope Microsoft has of getting back in the game is to starting supporting those features - I don't think they can compete on price, since free competition is available, and their large "mindshare" advantage is eroding rapidly. So VB 7, when (if) it comes out, is supposed to offer all the whiz-bang stuff Java has; in fact if you read the feature list, it looks like it was taken directly from Java. But it'll be years behind, and probably buggy until the third release.
So to fill the void MS announces C#... the only problem is that I don't see any features in C# that aren't already in Java, other than possibly "language independence". I suppose this means you can compile C# objects from source code in other languages, sort of how you can do ActiveX objects now (!) Big deal - you can already use other languages to create compiled Java classes, and that's not necessarily a good thing anyway, depending on how good/well-supported the other features of the other language are.
All in all, there's nothing in the C# announcement that would make me switch from Java, or even from VB 7 when it comes out (I'm a SCJP, but use VB for clients all the time).
I seem to remember reading somewhere that for most of the current batch of e-books, the orientation of the LCD screen is 90 degrees off - that is, it's rotated so that the pixels go R-G-B vertically, not horizontally. This makes the technique pretty useless for text on these devices.
Any good encryption algorithm will still be effective, even if (and because) its algorithm is widely known; it will rely on 1) passwords or keys being kept secret by the users, and 2) hackers not having the computational power available to break in without the key.
Obscurity doesn't work.