I can't seem to find the old slashdot article that solved that problem...
Basically, it was just a site full of this guy who built an EMP gun that used a dish to direct it. It not only killed the radio, but the ignition (at least on modern cars... I don't know how it would on the old mechanical beasts of the 70's). If thugs are aloud to broadcast their undesired air pressure waves, I don't see why I can't send a few harmless electrons back their way.:)
Sadly, you'ld probably be classified as a terrorist for making such a device these days, since one could undoubtably be used to take down aircraft or satellites if powerful and directed enough (think about an array of old 10' dishes... or in slashdotian, a beowulf cluster of EMP generators).
It's the best way to learn assembler, and I think it would be a great class at a university. I have a 57 byte static-like snowy screen thing I created that will even exit when you press a key. I sacrificed a lot of speed for size, and it isn't that cool, but I just wanted to see how small it could be done in. If anyone wants the fully documented assembler code, it's definately short enough to post. It's fun to tell people that their monitor cable came un-done when the static comes up.
I like your post, but I have to say those people living in the Congo dieing of random diseases are probably just whiners too. If their leaders are so freaking rich, and they are so freaking poor, if the entire population of poor people arose with just rocks, the rich leaders would be doomed. They choose their destiny as much as anyone else. Everyone should exercise their rights to the fullest extent. Research and vote every election. Speak out about things you don't like. Carry a handgun. The population in general should be more respected, and would be, if it only exercised it's freedoms. Whining everytime you have a problem is just going to make everyone else apethetic to your cause. Do something or shut the hell up!
Before some other whiny bastard posts about how rocks vs AK47s just don't work, I would like to point out that killing your entire population would leave you with no one left to work in your Nike plant, thus you would go broke. They could at least refuse to work in the Nike plant. If you don't want to kill anyone, you could go the whole Ghandi route. Or you could stop mindlessly believing in whatever myth you were told that says having 20 children in a barren wasteland was a good idea.
You can't help anyone that isn't willing to help themselves, be it religion, lack of will to survive, or any other self placed obstacle in their way.
I'm sorry you can't wrap your mind around dynamic runtime optimizations...
But in any case, everything can be condensed to assembler, so why don't you just argue that he didn't use C++ to it's most optimum performance because he didn't do:
void main() {
asm {
xor %ax, %ax
} }
Using C++ the way it's supposed to be (cout, etc) is not cheating. There are things I could do to optimize his Java examples, but usually you never have to, because it's fast enough.
Another flawed arguement is: Java is written in C, it can only be as fast as C. That's a lie... Java runtime optimizes code with JIT for the target processor. It can inline functions at will. C can't do those things at runtime.
I don't know what kind of funding your projects have, but I don't have the time to spend optimizing algorithms for the last 10%... especially when most of my code is IO bound. Java gets your job done quicker, and plenty fast enough without needing any third party libraries usually.
Of course it will require twice the horsepower. I'm sorry you don't understand the power of asynchronous processing, so I'll explain it to you. You know computers spend most of their time doing nothing, even servers, because people sleep a lot of the day. If you use asynchronous processing, like message queues, the work load can be processed when the CPU is available, without you having to do batch updates at night either. Therefore, your system will work near instantly at low load, then when it gets hit hard, you can still serve people, then process orders later and email them back. It's a simple concept that J2EE does pretty good. You can do some of the same in.Net, but it's not as easy and not stressed as a good design strategy. People who verify credit cards on form post are asking for trouble.
As the other replier has said, Struts is simply a must in the J2EE world. I have rarely seen a job where MVC or Struts isn't mentioned, and they are used almost synonimously in the J2EE world.
The links you point to ask you to do inheritance to compensate for a lack of good MVC support. I've seen that strategy, and honestly, it sucks. Pages are set to post back to themselves. There is one Java MVC controller that has been ported to.Net, but it requires messing with IIS directly to install. In Java, I create a WAR or EAR file, and it will just work.
J2EE doesn't come with an MVC architecture by default, but anyone who has written J2EE code before Struts would generally still observe the front controller architecture. You create a single servlet to control all access to your site. You put HTML peices in other files, and you generally pass maps from form post data to action objects that process the form. Web designers can edit HTML forms, coders can write actions, and you can pretty much ignore the controller logic altogether. This is what I'm argueing is hard to do in.Net. Without something like struts for.Net, you probably won't see a great migration of complicated projects from J2EE to.Net.
It was my impression that Mono was going to use Eclipse, the Java IDE. I have had to work with.Net for academic projects, and thus I have used VS.Net. I've actually been a guest lecturer to teach J2EE to a class (half the class was J2EE, the second half was.Net). Here are my findings:
1) Students can learn most of J2EE in half a semester of a 3h course (up to Message Driven Beans) with difficulty. The.Net guest taught only dynamic website creation driven from a DB.
2).Net was easier for the students to create simple dynamic web sites, but they didn't have the restriction of asynchronous processing of requests. In the real world, the.Net applications they wrote would have required more than twice the horsepower.
3).Net is only easier if you use the non-MVC graphical development tools. Think front-page style generated html that hardly works in most browsers, and definately doesn't pass any kind of standards. Going back to update the site will require a developer who is a designer, two people at the same computer, or a designer that knows VS.Net and ASP.Net.
You can now do the same with JSF (Java Server Faces) which looks and feels like VS.Net for making those terrible websites.
Struts is still probably the best (as far as flexibility and features) MVC architecture out there, and if it were ported to.Net,.Net might actually have a chance of actually displacing a significant number of J2EE development.
On the other side, VS.Net has the BEST SOAP/WebServices development I have seen to date. You can create a SOAP object in seconds, and I have. So far, this is the only redeaming quality of.Net that I've seen for web development. Windows.Forms and XAML may turn out to be really cool for GUI development, but I haven't had the chance to play with it much. Java is still seriously lacking in the GUI building area.
As far as I know, there are no MVC frameworks for.Net. Does any know of any MVC-2 frameworks? (Front controller style) It may be a good project to actually find a way to leverage the use of Open Source into your work place if there was a defacto standard MVC architecture. In my opinion, that and the commercial backing is what has let JBoss into the production world. The fact that most companies use Struts and other Apache Jakarta software has given the open source process a better reputation in the commercial world.
I have to use.Net occassionally, so I would be very much interested in some book reccomendations and some pointers to making a real database driven application, web or otherwise, in.Net.
Why not write a supplementary license for the Linux kernel?
Just a section that defines the terms GPL, etc. and says if you report your software as GPL, you must release the source code, or be liable for debug time, corruption, etc. caused by your software and that this agreement supercedes any EULA the user may have agreed to.
That'll teach them, and it's fair enough. Don't lie unless you are ready to be held responsible for damages caused by your lie.
Man, I watched a guy write an exploit for this one. They're incredibly simple to write, and had he actually knew C or just wrote it in Perl, he would have had it done in less than 4 hours. He didn't release it obviously, but anyone worthy of the title "coder" or "software developer" can do it probably in a matter of minutes with a respectable library of code that makes template packets for you to fill in the fields and takes command line arguements. The hardest part seems to be working around the little quirks of C and tcp/ip libraries, which I helped him with for a while.
He does this as proof of concept and to test a fix... how else are you going to know if a machine is secure if you don't at least knock on the door a little? Sometimes he sends them up the corperate chain so they can know how serious the issue is and how can test various ways to fix the problem.
Exploits are probably easier to write than patches, and it's always been this way. The big deal is that it's a lot easier to exploit than distribute the patches.
Until the internet and software in general is redesigned by a group of people that weren't trained by baboons who prize speed above security, this kind of thing is going to plague the computing world. Code signing fixes a set of problems, and IPSec fixes another. Cryto-technology is the only real weapon there is against these kinds of things. Drop anything that isn't signed by someone you trust, and you'll never have a virus or exploit that doesn't involve the physical layer (looking over someone's shoulder, key loggers in the keyboard, untrustable users, etc.). If it's not signed by someone you trust, then you can't trust it.
That's certainly a very interesting thought... Unless you've played enough flight sims, or actually know about the real things, most people also don't consider that fuel weighs a lot. Having more fuel on a plane designed to be so aerodynamic will cause a shift in balance usually, which will cause it to be less aerodynamic, which will cause it to use more fuel for the same speed.
I think the general consensus is that we need a plane that's capable of going even higher into the atmosphere in order to get some place faster. Like the Borg show in star trek, it really doesn't matter how aerodynamic you are in space.
I assume that any plane capable of Mach 7 is going to be flying pretty high. Taking into consideration that the circumference of earth is greater at higher altitudes and that mach is slower at higher altitudes, I really wonder how much of a gain we are looking at in travel time. I know I'm not going to pay exponentially more for a flight that is linearly quicker. Hell, I prefer the greyhound. If only greyhound busses would float, I could afford to visit the far east like I've always wanted to. Greyhound looks a lot better these days considering you have to drive to the airport, and your travel time has been extended by 4h or more due to security. If you wanted to streamline travel, it seems to me that shaving some of those 4h off would be better than using more fuel to go marginally faster. Building a more secure plane would probably do more for travel times than a faster one with more fuel so that it is also more capable of destruction.
You know, considering that more people complain about jet lag than travel times, I think this is pointlessly academic. Anyone stupid enough to live in LA and work in NY deserves to not have a life.
>> IIRC that goes to the Apollo reentry capsules that routinely hit Mach 27 on re-entry. So the heat problem has been solved for quite a while.
Yeah, it's been solved as long as you can affix ceramics to the side of your jet.:)
The payload of something rocket powered is going to be much greater than a puny jet. I bet if you dropped down closer to sea level after getting spead up, just like any other plane, you would find your terminal velocity in a very unfullfilling way.:) I learned that lesson from MS Flight Sim. It's not a heat problem so much as a these-wings-weren't-built-for-this problem.
Have you not seen the commercials? Don't you know it comes with the Indicator(TM) lubricating strip? It has less irritation... even against the grain!
Seriously though, someone else said that Mach isn't 757 mph higher in the atmosphere. Considering that, and the known fact that air is thinner at higher altitudes, I don't think you would have as many problems as you think you might... I would be more worried about what happens when the thing hits a pair of migrating European swallows carrying a coconut.
(i) you distribute the Software complete and unmodified (unless otherwise specified in the applicable README file) and only bundled as part of, and for the sole purpose of running, your Programs,
I'm not sure if this means it's ok to bundle it if you don't ship programs to run it.
(ii) the Programs add significant and primary functionality to the Software,
I think this confirms my worries. Java doesn't provide significant or primary functionality to Debian.
(iii) you do not distribute additional software intended to replace any component(s) of the Software (unless otherwise specified in the applicable README file),
This means you can't ship GCJ, ClassPath, Kaffe, etc. if you ship SUN Java.
(iv) you do not remove or alter any proprietary legends or notices contained in the Software,
The only clause that makes sense so far.
(v) you only distribute the Software subject to a license agreement that protects Sun's interests consistent with the terms contained in this Agreement, and
So you can't ship it under a different license.
(vi) you agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software.
There is more than one way to not warrant the redistributed files, but that doesn't make sense either. Why should Debian be liable if SUN screws up Java and it eats someone's system? Since you can't modify Java, SUN should be liable should Java cause anyone any problems. This clause doesn't inspire any confidence amongst users/developers.
That said, I like Java. Kaffe is our best bet though. SUN is really shooting themselves in the foot because their strangle-hold control over Java is just promoting solutions cropping up that aren't even compatible with the real Java. I wouldn't be terribly surprised if Kaffe worked great on most platforms to the point that developers started promoting it. Then Kaffe could fork away from SUN, and SUN would have no power to influence it. I could download Kaffe, fork it, then redistribute it myself, and SUN would have no power to stop me. Right now this isn't a significant threat, but the closer Kaffe comes to compliance and performance, the greater the threat becomes. The same is true for GCJ.
I just find it ironic that the biggest excuse to not open Java is exactly backwards from the reality of the situation. If the open sourced Java, they would have more control through trademark law than they would if they let something like Kaffe build recognition. Don't take it lightly either, because a lot of Java people are very pro-open source. JBoss is being used in production these days, and it isn't certified by SUN yet. SUN offers their implementation for free, but it goes largly ignored.
Just for those curious... in my current work (which I've been using 1.5), I wrote an application that gets a zip file from an FTP site and reads the CSV data out and parses it as it downloads. The whole app takes about 15s to run on this givin data. If I do |wc instead of >>/dev/null, time tells me it takes 30s, so this is a rather large file.
So, the speed of linux pipes and wc are about the same as my java's network io, zip decompressor, character decoder, string tokenizers (my custom line grabbing one), my searching for characters to guess data types, java's dateformat date parser, output encoder, and dataformate date printer.
-prof tells me it spends most of it's time in output formatting.
I guess moderators don't realize that WUSB is pretty much a technology without a market?
Want fast? Get 802.11 for 30$ from a dept. store. Want low power? Get BT for 30$ from a dept. store.
The device I got works under Linux, Mac, and Windows. You can put both in your pocket, and you can plug them into your desktop, laptop, or even your friends laptop when they visit.
What does the WUSB standard give you that doesn't already exist in a better format?
For 65$ you can get an DLink 802.11g USB2 shipped to your door. (https://www.ewiz.com/detail.php?name=DL-G120) I don't know if this is supported under Linux, but it's a lot larger than the DWL-122 that I have, or the DLink BT that I saw at the store.
Want a wireless printer? You can get a wireless print spooler for it, so there is no need for WUSB printers.
DV will always be done through FireWire (it's just a better standard that is faster).
USB has been playing catch up for quite some time. USB has no technological merits. It's all about the politics to get it directly on your motherboard. Peer-to-peer technologies like BT, 802.11, and Firewire should rightfully rule the markets. BT for low power close range, 802.11 for high speed medium range, Firewire for connected ultra high speed. No WUSB standard is going to make my life any easier.
That's the kind of lack of thought/knowledge I'm talking about. (No offense to you, it's just "common knowledge" of VM architectures is just completely wrong.) JNI lets you call native libraries. It so much supported that you can even package native libraries with your Java application and deploy them through the web with WebStart. There is actually a very fast cross-platform OpenGL binding for Java, and some games that use it. (Arkanae for one.)
If a 3D game can use it, you probably can't think of anything more demanding off the top of your head.
I don't think you understand much about how VM's or Swing works. You can tell Swing to use the native LNF (Look'N'Feel) and it will now look like GTK, XP, 2K, Mac, etc. LNF's are pluggable too. There are LNF's that let users skin your app.
SWT uses native code, and is less extendable. AFAIK, it has yet to support the Mac, and lots of other systems. Swing is also very much easier to use.
You compile once for the VM, which then compiles for the platform it's running on. You can decompile Java programs and the source will be completely intact. In essense, the JVM compiles the Java code that has been condensed into native code for whatever processor you have. If you have a processor that can do IEEE Trig FP, then it will use those instructions, which are inaccurate and/or slow on x86, thus the poor trig performance.
Java does run on par with C under windows by way of processing. It takes more memory, but that's because it has a consistant API layer for the system, and it uses garbage collection to keep you from making buffer overflows. In Java1.5 all java applications are supposed to share a single VM, which will make memory considerations negligable.
Also consider that GCJ is the slowest Java implementation... even though it's compiled.
The whole situation actually harms my confidence in the open source community. Every post about Java I've ever seen on/. has been followed up with how slow and big it is. Then, you get letters like this showing envy for a commercial product. All the while, there has yet to be a decent competing open source product. Python comes the closest, but it really is the slowest development environment.
My question is: Why can't the open source community create their own VM not built on commercial ideas that rivals C for speed? (Java on Windows does for everything but trig functions.)
No, you don't have to rewrite them... http://sourceforge.net/projects/pcj/ is one such existing implementation. I'm sure there are plenty of them. Between Sourceforge and Apache, I'm sure you'll find any code that you need that isn't specific to your application:)
First, why are you exposing a collection to any class you don't have control enough over to know what you put in it?
Secondly, the easiest way to protect a Collection is to wrap it. That way you only cast and uncast in one place. It gets inlined, so no performance penalty. It also lets you change the data structure type at will. Say you want to change from a linked list to a dynamic array or a tree. It's simple, and great for fixing performance problems.
I don't recommend implementing the collections interface, unless you have to pass it to some untrusted code that could mangle things and only takes collections.
What you do have to do is create an iterator interface that returns A's instead of Objects. It's really not a whole lot of work, and you can control most of everything that happens. Sometimes you actually need to mess around with objects in a collection, and it beats putting the code around everywhere else.
I think it gives you a lot more flexibility if you do it yourself. If you're worried about having a huge collection, you could have it write the collection to disk and read it in as needed. You could have your own xml-encoder built into your collection. You could implement your own Serializer functions to store the object how you want to as opposed to the built in serializers for the internal types. Say someday you want to convert your collections API to a 3rd party alternative... you'll just have to change a few lines to hit the major points.
I like the control, and since Java is going to inline your functions anyhow, this won't noticably hurt your performance.
Personally, I've used this method to convert between objects being put in and objects being retrieved as well. It makes a good place to perform a two way adapter for your collections. You could implement Collection if you needed.
Slashdot Mirror
I can't seem to find the old slashdot article that solved that problem...
:)
Basically, it was just a site full of this guy who built an EMP gun that used a dish to direct it. It not only killed the radio, but the ignition (at least on modern cars... I don't know how it would on the old mechanical beasts of the 70's). If thugs are aloud to broadcast their undesired air pressure waves, I don't see why I can't send a few harmless electrons back their way.
Sadly, you'ld probably be classified as a terrorist for making such a device these days, since one could undoubtably be used to take down aircraft or satellites if powerful and directed enough (think about an array of old 10' dishes... or in slashdotian, a beowulf cluster of EMP generators).
So... how many MPG do you get? Do you run better on Gatorade or Powerade? :)
I still think the best demo maker is NASM. :)
It's the best way to learn assembler, and I think it would be a great class at a university. I have a 57 byte static-like snowy screen thing I created that will even exit when you press a key. I sacrificed a lot of speed for size, and it isn't that cool, but I just wanted to see how small it could be done in. If anyone wants the fully documented assembler code, it's definately short enough to post. It's fun to tell people that their monitor cable came un-done when the static comes up.
I like your post, but I have to say those people living in the Congo dieing of random diseases are probably just whiners too. If their leaders are so freaking rich, and they are so freaking poor, if the entire population of poor people arose with just rocks, the rich leaders would be doomed. They choose their destiny as much as anyone else. Everyone should exercise their rights to the fullest extent. Research and vote every election. Speak out about things you don't like. Carry a handgun. The population in general should be more respected, and would be, if it only exercised it's freedoms. Whining everytime you have a problem is just going to make everyone else apethetic to your cause. Do something or shut the hell up!
:)
Before some other whiny bastard posts about how rocks vs AK47s just don't work, I would like to point out that killing your entire population would leave you with no one left to work in your Nike plant, thus you would go broke. They could at least refuse to work in the Nike plant. If you don't want to kill anyone, you could go the whole Ghandi route. Or you could stop mindlessly believing in whatever myth you were told that says having 20 children in a barren wasteland was a good idea.
You can't help anyone that isn't willing to help themselves, be it religion, lack of will to survive, or any other self placed obstacle in their way.
That's the end of my rant.
I'm sorry you can't wrap your mind around dynamic runtime optimizations...
But in any case, everything can be condensed to assembler, so why don't you just argue that he didn't use C++ to it's most optimum performance because he didn't do:
void main() {
asm {
xor %ax, %ax
}
}
Using C++ the way it's supposed to be (cout, etc) is not cheating. There are things I could do to optimize his Java examples, but usually you never have to, because it's fast enough.
Another flawed arguement is: Java is written in C, it can only be as fast as C. That's a lie... Java runtime optimizes code with JIT for the target processor. It can inline functions at will. C can't do those things at runtime.
I don't know what kind of funding your projects have, but I don't have the time to spend optimizing algorithms for the last 10%... especially when most of my code is IO bound. Java gets your job done quicker, and plenty fast enough without needing any third party libraries usually.
Thanks... I wasn't aware that there was a version of Spring for .Net.
I wished they had a usable product already though.
Of course it will require twice the horsepower. I'm sorry you don't understand the power of asynchronous processing, so I'll explain it to you. You know computers spend most of their time doing nothing, even servers, because people sleep a lot of the day. If you use asynchronous processing, like message queues, the work load can be processed when the CPU is available, without you having to do batch updates at night either. Therefore, your system will work near instantly at low load, then when it gets hit hard, you can still serve people, then process orders later and email them back. It's a simple concept that J2EE does pretty good. You can do some of the same in .Net, but it's not as easy and not stressed as a good design strategy. People who verify credit cards on form post are asking for trouble.
.Net, but it requires messing with IIS directly to install. In Java, I create a WAR or EAR file, and it will just work.
.Net. Without something like struts for .Net, you probably won't see a great migration of complicated projects from J2EE to .Net.
As the other replier has said, Struts is simply a must in the J2EE world. I have rarely seen a job where MVC or Struts isn't mentioned, and they are used almost synonimously in the J2EE world.
The links you point to ask you to do inheritance to compensate for a lack of good MVC support. I've seen that strategy, and honestly, it sucks. Pages are set to post back to themselves. There is one Java MVC controller that has been ported to
J2EE doesn't come with an MVC architecture by default, but anyone who has written J2EE code before Struts would generally still observe the front controller architecture. You create a single servlet to control all access to your site. You put HTML peices in other files, and you generally pass maps from form post data to action objects that process the form. Web designers can edit HTML forms, coders can write actions, and you can pretty much ignore the controller logic altogether. This is what I'm argueing is hard to do in
It was my impression that Mono was going to use Eclipse, the Java IDE. I have had to work with .Net for academic projects, and thus I have used VS.Net. I've actually been a guest lecturer to teach J2EE to a class (half the class was J2EE, the second half was .Net). Here are my findings:
.Net guest taught only dynamic website creation driven from a DB.
.Net was easier for the students to create simple dynamic web sites, but they didn't have the restriction of asynchronous processing of requests. In the real world, the .Net applications they wrote would have required more than twice the horsepower.
.Net is only easier if you use the non-MVC graphical development tools. Think front-page style generated html that hardly works in most browsers, and definately doesn't pass any kind of standards. Going back to update the site will require a developer who is a designer, two people at the same computer, or a designer that knows VS.Net and ASP.Net.
.Net, .Net might actually have a chance of actually displacing a significant number of J2EE development.
.Net that I've seen for web development. Windows.Forms and XAML may turn out to be really cool for GUI development, but I haven't had the chance to play with it much. Java is still seriously lacking in the GUI building area.
.Net. Does any know of any MVC-2 frameworks? (Front controller style) It may be a good project to actually find a way to leverage the use of Open Source into your work place if there was a defacto standard MVC architecture. In my opinion, that and the commercial backing is what has let JBoss into the production world. The fact that most companies use Struts and other Apache Jakarta software has given the open source process a better reputation in the commercial world.
.Net occassionally, so I would be very much interested in some book reccomendations and some pointers to making a real database driven application, web or otherwise, in .Net.
1) Students can learn most of J2EE in half a semester of a 3h course (up to Message Driven Beans) with difficulty. The
2)
3)
You can now do the same with JSF (Java Server Faces) which looks and feels like VS.Net for making those terrible websites.
Struts is still probably the best (as far as flexibility and features) MVC architecture out there, and if it were ported to
On the other side, VS.Net has the BEST SOAP/WebServices development I have seen to date. You can create a SOAP object in seconds, and I have. So far, this is the only redeaming quality of
As far as I know, there are no MVC frameworks for
I have to use
What, no one else uses the GNU Public Will?
RMS would probably insist that my proper title would be GNU/Sam.
Why not write a supplementary license for the Linux kernel?
Just a section that defines the terms GPL, etc. and says if you report your software as GPL, you must release the source code, or be liable for debug time, corruption, etc. caused by your software and that this agreement supercedes any EULA the user may have agreed to.
That'll teach them, and it's fair enough. Don't lie unless you are ready to be held responsible for damages caused by your lie.
Man, I watched a guy write an exploit for this one. They're incredibly simple to write, and had he actually knew C or just wrote it in Perl, he would have had it done in less than 4 hours. He didn't release it obviously, but anyone worthy of the title "coder" or "software developer" can do it probably in a matter of minutes with a respectable library of code that makes template packets for you to fill in the fields and takes command line arguements. The hardest part seems to be working around the little quirks of C and tcp/ip libraries, which I helped him with for a while.
He does this as proof of concept and to test a fix... how else are you going to know if a machine is secure if you don't at least knock on the door a little? Sometimes he sends them up the corperate chain so they can know how serious the issue is and how can test various ways to fix the problem.
Exploits are probably easier to write than patches, and it's always been this way. The big deal is that it's a lot easier to exploit than distribute the patches.
Until the internet and software in general is redesigned by a group of people that weren't trained by baboons who prize speed above security, this kind of thing is going to plague the computing world. Code signing fixes a set of problems, and IPSec fixes another. Cryto-technology is the only real weapon there is against these kinds of things. Drop anything that isn't signed by someone you trust, and you'll never have a virus or exploit that doesn't involve the physical layer (looking over someone's shoulder, key loggers in the keyboard, untrustable users, etc.). If it's not signed by someone you trust, then you can't trust it.
That's certainly a very interesting thought... Unless you've played enough flight sims, or actually know about the real things, most people also don't consider that fuel weighs a lot. Having more fuel on a plane designed to be so aerodynamic will cause a shift in balance usually, which will cause it to be less aerodynamic, which will cause it to use more fuel for the same speed.
I think the general consensus is that we need a plane that's capable of going even higher into the atmosphere in order to get some place faster. Like the Borg show in star trek, it really doesn't matter how aerodynamic you are in space.
I assume that any plane capable of Mach 7 is going to be flying pretty high. Taking into consideration that the circumference of earth is greater at higher altitudes and that mach is slower at higher altitudes, I really wonder how much of a gain we are looking at in travel time. I know I'm not going to pay exponentially more for a flight that is linearly quicker. Hell, I prefer the greyhound. If only greyhound busses would float, I could afford to visit the far east like I've always wanted to. Greyhound looks a lot better these days considering you have to drive to the airport, and your travel time has been extended by 4h or more due to security. If you wanted to streamline travel, it seems to me that shaving some of those 4h off would be better than using more fuel to go marginally faster. Building a more secure plane would probably do more for travel times than a faster one with more fuel so that it is also more capable of destruction.
You know, considering that more people complain about jet lag than travel times, I think this is pointlessly academic. Anyone stupid enough to live in LA and work in NY deserves to not have a life.
>> IIRC that goes to the Apollo reentry capsules that routinely hit Mach 27 on re-entry. So the heat problem has been solved for quite a while.
:)
:) I learned that lesson from MS Flight Sim. It's not a heat problem so much as a these-wings-weren't-built-for-this problem.
Yeah, it's been solved as long as you can affix ceramics to the side of your jet.
The payload of something rocket powered is going to be much greater than a puny jet. I bet if you dropped down closer to sea level after getting spead up, just like any other plane, you would find your terminal velocity in a very unfullfilling way.
Have you not seen the commercials? Don't you know it comes with the Indicator(TM) lubricating strip? It has less irritation... even against the grain!
Seriously though, someone else said that Mach isn't 757 mph higher in the atmosphere. Considering that, and the known fact that air is thinner at higher altitudes, I don't think you would have as many problems as you think you might... I would be more worried about what happens when the thing hits a pair of migrating European swallows carrying a coconut.
(i) you distribute the Software complete and unmodified (unless otherwise specified in the applicable README file) and only bundled as part of, and for the sole purpose of running, your Programs,
I'm not sure if this means it's ok to bundle it if you don't ship programs to run it.
(ii) the Programs add significant and primary functionality to the Software,
I think this confirms my worries. Java doesn't provide significant or primary functionality to Debian.
(iii) you do not distribute additional software intended to replace any component(s) of the Software (unless otherwise specified in the applicable README file),
This means you can't ship GCJ, ClassPath, Kaffe, etc. if you ship SUN Java.
(iv) you do not remove or alter any proprietary legends or notices contained in the Software,
The only clause that makes sense so far.
(v) you only distribute the Software subject to a license agreement that protects Sun's interests consistent with the terms contained in this Agreement, and
So you can't ship it under a different license.
(vi) you agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software.
There is more than one way to not warrant the redistributed files, but that doesn't make sense either. Why should Debian be liable if SUN screws up Java and it eats someone's system? Since you can't modify Java, SUN should be liable should Java cause anyone any problems. This clause doesn't inspire any confidence amongst users/developers.
That said, I like Java. Kaffe is our best bet though. SUN is really shooting themselves in the foot because their strangle-hold control over Java is just promoting solutions cropping up that aren't even compatible with the real Java. I wouldn't be terribly surprised if Kaffe worked great on most platforms to the point that developers started promoting it. Then Kaffe could fork away from SUN, and SUN would have no power to influence it. I could download Kaffe, fork it, then redistribute it myself, and SUN would have no power to stop me. Right now this isn't a significant threat, but the closer Kaffe comes to compliance and performance, the greater the threat becomes. The same is true for GCJ.
I just find it ironic that the biggest excuse to not open Java is exactly backwards from the reality of the situation. If the open sourced Java, they would have more control through trademark law than they would if they let something like Kaffe build recognition. Don't take it lightly either, because a lot of Java people are very pro-open source. JBoss is being used in production these days, and it isn't certified by SUN yet. SUN offers their implementation for free, but it goes largly ignored.
Just for those curious... in my current work (which I've been using 1.5), I wrote an application that gets a zip file from an FTP site and reads the CSV data out and parses it as it downloads. The whole app takes about 15s to run on this givin data. If I do |wc instead of >>/dev/null, time tells me it takes 30s, so this is a rather large file.
So, the speed of linux pipes and wc are about the same as my java's network io, zip decompressor, character decoder, string tokenizers (my custom line grabbing one), my searching for characters to guess data types, java's dateformat date parser, output encoder, and dataformate date printer.
-prof tells me it spends most of it's time in output formatting.
I guess moderators don't realize that WUSB is pretty much a technology without a market?
Want fast? Get 802.11 for 30$ from a dept. store.
Want low power? Get BT for 30$ from a dept. store.
The device I got works under Linux, Mac, and Windows. You can put both in your pocket, and you can plug them into your desktop, laptop, or even your friends laptop when they visit.
What does the WUSB standard give you that doesn't already exist in a better format?
For 65$ you can get an DLink 802.11g USB2 shipped to your door. (https://www.ewiz.com/detail.php?name=DL-G120) I don't know if this is supported under Linux, but it's a lot larger than the DWL-122 that I have, or the DLink BT that I saw at the store.
Want a wireless printer? You can get a wireless print spooler for it, so there is no need for WUSB printers.
DV will always be done through FireWire (it's just a better standard that is faster).
USB has been playing catch up for quite some time. USB has no technological merits. It's all about the politics to get it directly on your motherboard. Peer-to-peer technologies like BT, 802.11, and Firewire should rightfully rule the markets. BT for low power close range, 802.11 for high speed medium range, Firewire for connected ultra high speed. No WUSB standard is going to make my life any easier.
DLink makes some great wireless USB stuff don't they? I just got a keychain 802.11b Prism2.5 that I'm using at this moment to post for 30$ at BestBuy.
That's the kind of lack of thought/knowledge I'm talking about. (No offense to you, it's just "common knowledge" of VM architectures is just completely wrong.) JNI lets you call native libraries. It so much supported that you can even package native libraries with your Java application and deploy them through the web with WebStart. There is actually a very fast cross-platform OpenGL binding for Java, and some games that use it. (Arkanae for one.)
If a 3D game can use it, you probably can't think of anything more demanding off the top of your head.
Oh, I forgot to say... If you chose Python or Perl, you could run it everywhere...
You talk as if the Open Source community only runs on Linux. That's just not true.
I don't think you understand much about how VM's or Swing works. You can tell Swing to use the native LNF (Look'N'Feel) and it will now look like GTK, XP, 2K, Mac, etc. LNF's are pluggable too. There are LNF's that let users skin your app.
SWT uses native code, and is less extendable. AFAIK, it has yet to support the Mac, and lots of other systems. Swing is also very much easier to use.
You compile once for the VM, which then compiles for the platform it's running on. You can decompile Java programs and the source will be completely intact. In essense, the JVM compiles the Java code that has been condensed into native code for whatever processor you have. If you have a processor that can do IEEE Trig FP, then it will use those instructions, which are inaccurate and/or slow on x86, thus the poor trig performance.
Java does run on par with C under windows by way of processing. It takes more memory, but that's because it has a consistant API layer for the system, and it uses garbage collection to keep you from making buffer overflows. In Java1.5 all java applications are supposed to share a single VM, which will make memory considerations negligable.
Also consider that GCJ is the slowest Java implementation... even though it's compiled.
The whole situation actually harms my confidence in the open source community. Every post about Java I've ever seen on /. has been followed up with how slow and big it is. Then, you get letters like this showing envy for a commercial product. All the while, there has yet to be a decent competing open source product. Python comes the closest, but it really is the slowest development environment.
My question is:
Why can't the open source community create their own VM not built on commercial ideas that rivals C for speed? (Java on Windows does for everything but trig functions.)
Oh, that's what they are calling .Net today.
No, you don't have to rewrite them... http://sourceforge.net/projects/pcj/ is one such existing implementation. I'm sure there are plenty of them. Between Sourceforge and Apache, I'm sure you'll find any code that you need that isn't specific to your application :)
First, why are you exposing a collection to any class you don't have control enough over to know what you put in it?
Secondly, the easiest way to protect a Collection is to wrap it. That way you only cast and uncast in one place. It gets inlined, so no performance penalty. It also lets you change the data structure type at will. Say you want to change from a linked list to a dynamic array or a tree. It's simple, and great for fixing performance problems.
I don't recommend implementing the collections interface, unless you have to pass it to some untrusted code that could mangle things and only takes collections.
What you do have to do is create an iterator interface that returns A's instead of Objects. It's really not a whole lot of work, and you can control most of everything that happens. Sometimes you actually need to mess around with objects in a collection, and it beats putting the code around everywhere else.
I think it gives you a lot more flexibility if you do it yourself. If you're worried about having a huge collection, you could have it write the collection to disk and read it in as needed. You could have your own xml-encoder built into your collection. You could implement your own Serializer functions to store the object how you want to as opposed to the built in serializers for the internal types. Say someday you want to convert your collections API to a 3rd party alternative... you'll just have to change a few lines to hit the major points.
I like the control, and since Java is going to inline your functions anyhow, this won't noticably hurt your performance.
Personally, I've used this method to convert between objects being put in and objects being retrieved as well. It makes a good place to perform a two way adapter for your collections. You could implement Collection if you needed.