i agree that it will be faster, but I don't care. well I do, but only if it were enough to make me angry at my own program. I like the fact that I can distribute one jar, around 200k that has all my source and compiled classes, and I know that it will run for everyone without having to recompile. Once someone writes a good jar app manager it will be easiest way to install and update code. No linking or recompiling to worry about. IBM has VM's that will run at 90%+ performance times of c++, and the 1.3 with hotspot is really quite fast. I wrote a ftp client, not quite done, but I was able to write a nice swing app that is multithreaded and runs good on linux and win32. And the network performance, especially with the blackdown port, beats all the commercial clients I've tested it with. I think its the same argument with assembly. When processors hit 10 gigahertz, will performance be that big of a deal, when we get quantum computer:). I agree that some things should always be written natively, especially database, drivers. And I would like nothing more than to have a compiler so that I could write the oop stuff. But that is the real reason why there is not a good compiler, most things are dynamically allocated, so you would still have to have a good library running to help clean things up in the background. I'm sure someone will write a good one eventually, but if you want native performance, then you should probably be using c++ and not java. Everything exists for a reason, even visual basic, but I can't remember what it is, or even remember if I ever knew:)
When the java versus c article first appeared on slashdot there was a comment about java needing to be compiled. I think that people do not quite understand the importance of vm's in the future of computer science and of the pc ( or whatever it becomes) in the future.
Most problems arise in software is caused by lack of abstraction. Look at all the problems that games had early on. Remember trying to get quake to run in 800x600. You had to install the vesa bios extension. Which really wasn't all that hard, but it did stick the game to a very basic set of drivers. Now that gaming has moved over to the open/gl or direct x games can run on all kinds of different systems, and have made a lot of progress in a short amount of time. Mainly because it allows games to be hardware accelerated.
Today software is ran the same way it was ran 20 years ago. When it comes down to it, we still interact with our hardware using add, mov, lea, and a whole slew of other very simple instructions. In the case of RISC chips there is even less. Functions are totaly basic, but no chips out there allow you to define one on the chip, allowing it to be optimized. The time has come for us to move more of our common software structure into hardware.
Imagine if all your objects were not only stored in hardware, but managed by a hardware memory controller, and garbage collector. If threading was unified so that hardware could really do the switching, and the os would be left to kick things off and make sure things got scheduled correctly. Sun is already working on this and the next line of sparc hardware will have java acceleration built-in to the hardware. Servlets on sparc will take over as the leader in web based application performance.
Pick up the java vm specs from Sun and you'll find that the real magic is the java byte code. Java uses an single byte code. There are 202 op codes that can do almost everything that a non-gui program would ever have to do. From simple addition and all the object/function handling routines. When you start to look under the hood of a java vm you find that a large majority of it is acutally native code. java.system java.io, the major packages of classes, are all written natively. Bascially it creates a standard interface to hardware that can then be ported to each operating system. Now image that your video card, network card, sound card, and harddrive controller all have java acceleration or a part of a java vm running on them. Then a the core java vm, or java kernel would then coordinate all the transactions. Threading and IO performance would increase dramactically, and be much faster and robust then any simple intel like arch. running simple c code. The age of accelerated software is upon us, wake up. my $0.02
Now that we have the hardware, we need to have a email like protocol to handle the registration and traking people.
First the ip of the phone needs to be registered with the identifier of that phone. Friendly name would be like email. Something like somebody@phone.com or whatever the domain of the server. The mac of the phone would be it's identifier. The phone would have setup options that would allow it's owner to enter the server's it is to use to register itself, much like an email client would. Phone keypads would be replaced with small keyboards or touch screens.
Their might be a problem with security. If someone can make their device have the same mac as you, then they could take over your phone. I imagine we would have to have a password to keep people from changing your ip on the server side. If everyone runs their own server and registers their own domain, than there would be no risk.
Time for new last names. Come up with a domain name, and identify you family with it. When you get married come up with a new one.:)
As soon as slashdot posts a story, the site usually goes down, or least get's slow, and does not answer requests.
It seems to me that their is enough bandwith among some slashdot users to setup a kind of automatic temporary web mirror system.
The mirrorer's machine would one a small script that would listen for requests from slashdot and then would scrape the info from the other site. This could all happen before the story was even posted.
Of course if the site was running asp, cf, php, pearl, java servlets, or some other language generating the pages it would be harder. But chances are those kinds of sites would have the bandwith needed, or closer to then some of the random static html pages we see here from time to time.
Postgres is a much better system than MySQL in my opinion. It supports many more features that are common in the big boys ( oracle, sql server, sybase).
An idea I have about replication is to use stored procedures. Wrap all writes to the database in stored procedures. I'm not sure if postgres supports transactions, but if does use it, and update all data sources. Then when your program needs to read, it can safely do it from any server. The decision would have to be in your code,:( but I'm sure their is a way to find out how much load is on each server. Just an idea, and you would probably still have race conditions, but it might work.
Java Media Framework 2.0 supports a ton of media codecs. It is an api that would allow developers to easily integrate multimedia, including mp3 and mpeg into their application. In general java is slow, but will not always be. Their is currently a pure java implementation of jmf which mean that it would run anywhere. Sun has also put out packs that allow the api to hookup with the codecs natively, improving performance. JMF is also a plugin based, so codecs can be added and removed through the manager. If an open source player was written using the codec it would run on all platforms automatically, and run decent if the platform had native support.
I could see a newspaper being somewhat successful just printing what web sites had reported. They could print what slashdot put up the day before, and maybe corrections, and a filtered version of the discussion area. I have to ride the bus to work everyday, so I would enjoy reading a web log that wasn't printed on 8.5X11 sheets. Plus I usually read slashdot 4 or 5 times a day. But work has kept me from surfing the web a lot on my personal time, since I have very little of it.
This is Eric from the book. Just in case you guys have any questions of me, here is my email and icq. icq: 2055186 twilegar@icsp.net Btw, I'm in much better sorts since the writing of the book. I've changed jobs and I'm now in a much more geek friendly workplace.
Slashdot Mirror
i agree that it will be faster, but I don't care. well I do, but only if it were enough to make me angry at my own program. I like the fact that I can distribute one jar, around 200k that has all my source and compiled classes, and I know that it will run for everyone without having to recompile. Once someone writes a good jar app manager it will be easiest way to install and update code. No linking or recompiling to worry about. IBM has VM's that will run at 90%+ performance times of c++, and the 1.3 with hotspot is really quite fast. I wrote a ftp client, not quite done, but I was able to write a nice swing app that is multithreaded and runs good on linux and win32. And the network performance, especially with the blackdown port, beats all the commercial clients I've tested it with. I think its the same argument with assembly. When processors hit 10 gigahertz, will performance be that big of a deal, when we get quantum computer :). I agree that some things should always be written natively, especially database, drivers. And I would like nothing more than to have a compiler so that I could write the oop stuff. But that is the real reason why there is not a good compiler, most things are dynamically allocated, so you would still have to have a good library running to help clean things up in the background. I'm sure someone will write a good one eventually, but if you want native performance, then you should probably be using c++ and not java. Everything exists for a reason, even visual basic, but I can't remember what it is, or even remember if I ever knew :)
When the java versus c article first appeared on slashdot there was a comment about java needing to be compiled. I think that people do not quite understand the importance of vm's in the future of computer science and of the pc ( or whatever it becomes) in the future.
Most problems arise in software is caused by lack of abstraction. Look at all the problems that games had early on. Remember trying to get quake to run in 800x600. You had to install the vesa bios extension. Which really wasn't all that hard, but it did stick the game to a very basic set of drivers. Now that gaming has moved over to the open/gl or direct x games can run on all kinds of different systems, and have made a lot of progress in a short amount of time. Mainly because it allows games to be hardware accelerated.
Today software is ran the same way it was ran 20 years ago. When it comes down to it, we still interact with our hardware using add, mov, lea, and a whole slew of other very simple instructions. In the case of RISC chips there is even less. Functions are totaly basic, but no chips out there allow you to define one on the chip, allowing it to be optimized. The time has come for us to move more of our common software structure into hardware.
Imagine if all your objects were not only stored in hardware, but managed by a hardware memory controller, and garbage collector. If threading was unified so that hardware could really do the switching, and the os would be left to kick things off and make sure things got scheduled correctly. Sun is already working on this and the next line of sparc hardware will have java acceleration built-in to the hardware. Servlets on sparc will take over as the leader in web based application performance.
Pick up the java vm specs from Sun and you'll find that the real magic is the java byte code. Java uses an single byte code. There are 202 op codes that can do almost everything that a non-gui program would ever have to do. From simple addition and all the object/function handling routines. When you start to look under the hood of a java vm you find that a large majority of it is acutally native code. java.system java.io, the major packages of classes, are all written natively. Bascially it creates a standard interface to hardware that can then be ported to each operating system. Now image that your video card, network card, sound card, and harddrive controller all have java acceleration or a part of a java vm running on them. Then a the core java vm, or java kernel would then coordinate all the transactions. Threading and IO performance would increase dramactically, and be much faster and robust then any simple intel like arch. running simple c code. The age of accelerated software is upon us, wake up. my $0.02
Now that we have the hardware, we need to have a email like protocol to handle the registration and traking people.
:)
First the ip of the phone needs to be registered with the identifier of that phone. Friendly name would be like email. Something like somebody@phone.com or whatever the domain of the server. The mac of the phone would be it's identifier. The phone would have setup options that would allow it's owner to enter the server's it is to use to register itself, much like an email client would. Phone keypads would be replaced with small keyboards or touch screens.
Their might be a problem with security. If someone can make their device have the same mac as you, then they could take over your phone. I imagine we would have to have a password to keep people from changing your ip on the server side.
If everyone runs their own server and registers their own domain, than there would be no risk.
Time for new last names. Come up with a domain name, and identify you family with it. When you get married come up with a new one.
As soon as slashdot posts a story, the site usually goes down, or least get's slow, and does not answer requests.
It seems to me that their is enough bandwith among some slashdot users to setup a kind of automatic temporary web mirror system.
The mirrorer's machine would one a small script that would listen for requests from slashdot and then would scrape the info from the other site. This could all happen before the story was even posted.
Of course if the site was running asp, cf, php, pearl, java servlets, or some other language generating the pages it would be harder. But chances are those kinds of sites would have the bandwith needed, or closer to then some of the random static html pages we see here from time to time.
Postgres is a much better system than MySQL in my opinion. It supports many more features that are common in the big boys ( oracle, sql server, sybase).
An idea I have about replication is to use stored procedures. Wrap all writes to the database in stored procedures. I'm not sure if postgres supports transactions, but if does use it, and update all data sources. Then when your program needs to read, it can safely do it from any server. The decision would have to be in your code, :( but I'm sure their is a way to find out how much load is on each server. Just an idea, and you would probably still have race conditions, but it might work.
Java Media Framework 2.0 supports a ton of media codecs. It is an api that would allow developers to easily integrate multimedia, including mp3 and mpeg into their application. In general java is slow, but will not always be. Their is currently a pure java implementation of jmf which mean that it would run anywhere. Sun has also put out packs that allow the api to hookup with the codecs natively, improving performance. JMF is also a plugin based, so codecs can be added and removed through the manager. If an open source player was written using the codec it would run on all platforms automatically, and run decent if the platform had native support.
I could see a newspaper being somewhat successful just printing what web sites had reported. They could print what slashdot put up the day before, and maybe corrections, and a filtered version of the discussion area. I have to ride the bus to work everyday, so I would enjoy reading a web log that wasn't printed on 8.5X11 sheets. Plus I usually read slashdot 4 or 5 times a day. But work has kept me from surfing the web a lot on my personal time, since I have very little of it.
Why isn't nasa working on problems like these?
This is Eric from the book. Just in case you guys have any questions of me, here is my email and icq. icq: 2055186 twilegar@icsp.net Btw, I'm in much better sorts since the writing of the book. I've changed jobs and I'm now in a much more geek friendly workplace.