don't put dark matter in the same boat as relativity. People question because there arre obvious (to a physicist) problems in modern physics. There are no obvious problems in thermodynamics, so if you want to question that, then the burden of proof is EXTREMELY high. This is especially true given that TD rests upon a RADICAL statement that goes something like this "more probable things are more probable", which is reallly pretty hard to dispute.:-)
Anyone who actively disputes TD without showing the next Nobel prize winnign theory is a quack, plain and simple.
Don't just blame the oil companies. Most of them have even admitted it. It's the lunatic administration that's holding on to this insanity. This is the same guy who wants to teach Intelligent Design in school, he's never seen a piece of junk science he didn't like.
I don't particularly agree with even the first part of that asessment. I've worked at Microsoft, and now at several financial firms as well. The work I do for in house programs is MUCH more interesting than anything I ever did at Microsoft. The pay and hours are better, and the work is wildly more interestings. Perhaps I'm a bit biased though.
Really hard to know that there are no US citizens in gitmo, when nobody will tell us who these people are. How do YOU know there are no citizens there, especially since I seem to remember the gov publicly admitting that there are several US citizens (who were nabbed in Afghanistan) currently rotting in Gitmo.
That is what scares me, too many secrets. If the gov wants to keep something secret, that's fine, if they want to keep a trial secret, they should require a vote of the senate or something, for each instance. At least then there would be some oversight, such as it is.
First of all, they do have some data. They can simulate the models of weapons they had before and make sure the simulations match up with what actually happened in the test. This sort of thing is also useful for things like fusion/fission reactors, and other far out stuff.
At the end of the day, it's pure research. There is very little pure research that is not (eventually) worth it. This is a cost that gets to be amortized over the remainder of human civilization, conservatively pegged as at least 100 years.
The shuttle is hardly a lemon, and the problems it has come from the fact that it pushed well beyond the contemporary technologies of the day. If we did it again, it would be much better. It also largly predated good CAD and DFE analysis tools.
Look at modern cars for a good example. They are designed down to every last screw by computers. They take less material to make, they are more efficient, and they are more reliable than older cars. The same will be true of the next reusable orbital craft. It will be intensely designed, it will be better than the shuttle in every way, and presumably safer as well.
This is exactly correct. Appservers are often used for backend data processing. Usually something like, run a JMS server, let people publish data on it. Take the data, do something with it and a bunch of other data in a database. Make the results available through EJB, or possibly a web page. These tend to not be used for just webpages based on databases (simple shopping carts), but more for realtime trading, risk analysis, data processing, etc...
Ruby on Rails and a J2EE appserver are completely different. However, it is possible to use an appserver to do the sort of things you'd do with Rails, the reverse is not true.
A JSR-168 compatible portal might be a good solution. It would take care of things like single sign on, and they usually have a fair number of useful modules. You should be able to find some forum and wiki modules, among others.
These things take some substantial work to configure and set up, but once set up, they tend to work very well. You could look at Jetspeed or JBoss, for starters.
These modules are also (slowly) starting to become comodities, so you should be able to get lots of useful functionality stuffed in there without having to write too much code. The various departments and such can each write their own little portlet, and get it all integrated into the whole.
These things tend to be more for dynamic sites, but I could see one working pretty well even for a static site. They often have lots of content management features, etc... Usually they are DB backed, but a good postgres install shouldn't be too hard to come by.
Hardly. They would have to do something that was significantly likely to hurt outsiders, and those sorts of "innovations" should be discouraged. At the very least, make the investors take the risk. The real problem with the current situation is that all the rewards go to the investors, but much of the risk is born by the guy who lives down the street from the factory. All the risk should be born by the investors, that's part of what investing is.
This train of thought is actually very common in our world today. For instance, you can take products back to the stores if they are defective. That's because business bears the risk, not the customers, that's a large part of what business is, risk analysis, so it makes sense to put as much of it in one place as possible. My grandmother isn't a risk analyst, I (to a degree, more precisely, my software is) am, consequently, making the risk come through my doors keeps me employed:-), and keeps my grandmother from having to worry about whether or not her car is going to spontaniously explode. It's a separation of responsibilities that is at the core of all modern economics. The fisher fishes, because he's better at it (and better equipped) than I am, the bankers take the risks, the autoworkers build the cars, etc.... I pay them each for their services, and we all come out better than if we each had done every job ourselves.
Exactly. There are a lot of programmers who don't understand that less is better. Java has already allowed too much, though my gripes are likely a little non-standard. For instance, curly braces after an if/for/while should be mandatory, not optional....
The whole point of a language is to codify thought in a unambiguous and easy to understand manner. Having 20 ways of doing anything doesn't help. The guys who love C++ also tend to be the loudest, most obnoxious bunch when it comes to standards. If java was released, they would push and push until they go operator overloading, function pointers, pointers, malloc, free, etc... into the language. This is what happened to C#, and it makes the thing unbearable to use if you don't care about the religion, but just want to do your job.
Furthermore, most of the suggestions would fundametally undermine the (supposed) purpose of Java, protected memory through type safety alone. This is provably possible with java (provided you have a competent VM and no JNI), but provably impossible with any system that allows unrestricted pointers and similar trash.
Java remains futureproofed as long as it is well defined enough that it doesn't depend on underlying hardware. Throw in too much trash, and you'll lose that, and people will (like they did with C++) wonder just why the language sucks so bad, and where all these bugs came from.
You're right about most things, but in the case of Sun's java, you can read the source behind the core classes. Rarely would the source behind the hotspot compiler (doubtless one of the most complicated pieces of software ever written) help you.
Not that I disagree that opensource would be better, but I'm not sure that it's best to spend the effort to attack a system that is very close, when there are so many that are not close at all.
That being said, it's good to have large, complex systems like this opensourced. Maybe then it can finally be put in as the top level of Linux and dispell all the libc/x11/posix/kde/GTK nastiness once and for all. One API to rule them all.....
You overshoot the mark somewhat. Any system that is fundamentally sound from a gametheory standpoint would work, it wouldn't have to be our current system. Often it is not exactly like what we see in the wide world. For instance, academia has an economy all its own, based on paper publishing and such, this is vaguely similar to the financial economy, but not exactly the same. There are many similar examples.
You perfectly well can "dream of a better system", but the system needs to be viable. That is to say, you need to envision a system where you desire the Nash Equilibrium that would arise from that system. In this light, there are probably many changes that could be made to our current system to improve (or at least alter) it, without being nonviable. Communism isn't one of them, but accountability probably is. To claim that the only possible system is the current system shoots far beyond what is actually supported by (ironically) economic and game theory. That line of thought will lead you to disregard viable solutions to serious problems out of a pseudo-religious zeal, which is fairly common these days where economics are concerned.
I'm with you, except for limited liability. It badly distorts the game theory when a corporation can take a tremendous gamble, if that gamble wins, the investors get money, if it loses, the corporation goes bankrupt and people other than the investors are left holding the bag.
This causes a lot of questionable behavior, for instance, the actions of the tobacco industry, and various environmentally unsound practices are supported by this sort of logic. Get your money now, when your past catches up with you, go bankrupt while the investors retire in Bermuda.
Investing in a corporation is a one way transaction. Everything good crosses over and goes to the investors (in theory at least), while everything bad stays with the corporation. That's hardly fair. Granted, our financial system would need some overhauling in the situation where limited liability was gone, but it would be workable. The simplest means would be to just sell insured shares, where for a fraction of the dividend (or whatever) an insurance company is willing to take the hit if the company goes under. Would probably only cost a few clicks, but it would be readily apparent which corporations were engaging in questionable behavior, because their insurance rates would be higher.
First of all, the cost of virtual memory. As we all know, it is not free. Google "virtual memory cost TLB percent" and hit "I feel lucky", you should come to this page...
This is talking about a common case where an app causes a lot of TLB misses, using a substantial proportion of the execution time doing nothing but VM translation. Notice that the performance penalty is (in their example) roughly 30%, due to TLB misses causing floating point pipeline stalls. This is a commonly accepted figure. EVERY TLB miss will cause a few hundred clock cycles. A TLB miss rate of even 1% will have a SUBSTANTIAL effect on performance. Running without Virtual Memory (in system mode) completely eliminates the TLB and all of this performance is reclaimed. This is possible with any truly typesafe system, such as JAVA.
Secondly, compilers..... Yes, some of the compiler/verifier is on the client, however you could just as easily say that the hardware underneath is a compiler itself (translating CISC x86 instructions to RISK opcodes), so this terminology isn't particularly meaningful. It becomes totally misleading when you consider that there exist hardware platforms that can execute java bytecode directly. My meaning should have been clear from context to someone of your credentials. In any case, most of the checks are done within the compiler (Hotspot), though that compiler happens to reside on the client machine. If you dislike this being referred to as a compiler, then that is your business.
Third, you include some extremely bad examples of runtime checks. Modern Virtual Machines already eliminate a lot of array bounds checks with compiler passes (though granted, this particular compiler pass is performed on the client machine), and null pointer checks are handled by a hardware interrupt, just like an integer divide by zero. Both of the examples you gave are very unfortunate, as they are two checks that rarely actually must be performed by software.
As for your question of whether or not the software checks in java are more expensive than the hardware means, there is very little direct research available, but Java is commony accepted to be around 95% of the performance of straight C, and Virtual Memory is commonly accepted to be about 70% of the performance of System mode, so you tell me. For instance, see... http://www.idiom.com/~zilla/Computer/javaCbenchmar k.html
I wouldn't have assumed you were junior if you didn't make such classic mistakes.
Once again, it is very foolish to make claims about my chip designing skills. Everyone who has investigated the issue accepts that modern CPUs do the best they can GIVEN that they are running unsafe languages. It is also commonly accepted that dramatic efficiencies could be realized (I just gave one example, no TLBs needed, saving around 30%) if the software itself could be proven safe. It would be another mistake expected of a novice confuse this rather clear cut situation and claim that I was calling the Intel designers idiots.
Who knows, perhaps in your zeal to call me out as a fool you skimmed over some implications and said things that didn't sound particularly well founded.
However, since you asked... I'm a BA in Physics from an Ivy League institution. I currently work in computational finance. I spend a great deal of time working with java, and occasionally native code. We are largly performance bound, so I have studied this issue extensively.
Pick up an OS text book once in awhile. Memory protection (stuff running in User mode, with virtual memory turned on) is around 30% slower than stuff running in system mode (with memory protection turned off). This is true regardless of things like context switches and system calls. The whole page table doesn't fit into the TLB, so you have to have cache misses from time to time, and they are EXPENSIVE.
I'm not saying they're idiots, they did the best with what they had. If you have to support unsafe languages, then you're going to take a hit making them safe with hardware. Making them safe in software costs a few percent (compare simple java programs to simple C programs, their speed is very close if they are similar enough), hardware takes a few tens of percent.
You are a poser, and you know next to nothing about computers. Go to college, take an operating systems class, and actually try to learn the material.
Good points all around, I'd like to just add a few things...
First of all, a massive reimplementation is underway. Software is migrating to VMs at a fairly impressive pace. The only ones who seem to be holding out are the shrinkwrap vendors, but even then are starting to buckle. When Microsoft moves significant code to.NET (if it ever happens), the others may move as well.
Already, custom coded apps are almost always writting in Java, or (shudder) VB and.NET. When this increases further, you can probably expect to see the VMs take over, relegating much of that 30 year old code to the dustbin of history. After everything is VM based, the virtual memory will probably also head for the trash heap, and hardware would likely become much cleaner and simpler.
I'm mostly disappointed with Apple for holding off on this to the degree that they have. Java is a natural fit for them. Write a VM that looks and feels native, then make all their apps in Java and sell them on windows as well. By blazing the trail they might be able to get others to similarly write in java, and level the playing field for themselves. If the linux geeks would bury their long held animosity, then they could make a similar move, and attempt to take a real position on the desktop. Instead, they thrash against a a technology that is not only a natural fit for them, but is also, almost indisputably, the future, and they remain relegated to server closets where the admins install java on them anyway and they are workhorses for JBoss. Grow a brain guys.
We are not going to use it up. Uranium is more common than Tin, and present in fairly significant quantities throughout seawater. If there wasn't so much high grade ore lying around, it would be cost effective to get Uranium from seawater rather than give up our nuclear reactors (which are all cash cows now that they're running at 90+% capacity 24x7), and this source would last for thousands, if not millions, of years.
Anyway, it's not going to come to that, there is just too much Uranium to plausibly even have to look very hard for it for hundreds of years. However, since pretty much all the world's current supply comes from a half a dozen motherload mines in Australia and Canada, those might run out within 50 or 100 years, at which time we'll have to pay slightly more for it, and the cost of nuclear power might go up by a few hundreths of a percent, but still be dramatically cheaper than any other major source of power available, even coal.
You just need part of the compiler to run on the client machine. Java, OCaml, etc.... They all do exactly this, and they work very well....
It is likely that a machine that could only run java would be faster running java than a normal machine is running C. The reason is that a java only machine could turn off all memory protection (as everything would have to be safely inside the VM, except the kernel, which wouldn't be protected anyway). Memory protection verifiably costs you something like 30% of your performance. That number was from a few years ago, it has doubless gotten worse, not better. That much performance would overcome the couple percent performance handicap java has, and give it the edge. The same would apply to OCaml, etc... Anything that's VM based would have this advantage...
Think java. There is no "writing binary by hand" because the JVM still verifies it. It is not possible to construct a valid.class file that will compromise system security.
This point is correct about EXACTLY one city in the United States, NYC. No other city is even remotely tolerable without a car. NYC is almost intolerable with a car, so you're better off taking the subway.
Not that the feds haven't done everything in their power to shaft the NYC transit system, but that's another story, and that's probably just because it's about as blue as they come, and the repubs don't want it to become any bigger, rather than them trying to make sure there's a market for our Oil Barron in Chief's wares.
1) P ?= NP 2) Memory protection through typesafety alone. Would give all computers a 30+% boost to performance if the security was handled by the compiler, and not the hardware. 3) IPv6, static IPs for everyone... 4) Diamond semiconductors. Smaller features than silicon (the carbon atoms are physically smaller), able to withstand immense temperatures, higher performance, more efficent...pretty much just better in every way. 5) Non volatile ram that doesn't burn out. Instant on computers, and more...
How's that for a top 5 list of things to do before 2025?
Be very careful about trying to "fix everything" after hours. That's how we do some things (and did the same thing at my previous place), and it's a nightmare. If anything is wrong in the morning, then it's hard to go back and re-run the previous night's batch processing. Often it takes too long, often you would just corrupt data further, etc... Very often this results in us having to just have incorrect data for a day, and then get it right the next day. In addition, due to global expansion, we only have 2 hours each day in which to run this stuff. If a market were to stay open an extra little while, or we try to expand somewhere in the forbidden slot, I don't know what would become of us.
You are far better off trying to get everything to be realtime, as much as possible, and build in mechanisms for the system to recover from corruption and incrementally do batching throughout the day. Do NOT rely on the fact that the system goes offline for 8 hours each night, that's an easy way to produce a system that costs you your job.
Lets leave all this BS on the table for a second. It seems to me that politicians are responsible for making the game such that society is the winner. If they let a company price its drugs at obscene rates, and yet require it to be covered (and don't punish the companies for letting people die), then you've effectively created a wonderful monopoly, while simultaniously claiming to use the free market. Here's a hint, markets don't work when the alternatives are "pay us whatever we ask, or die".
Similarly, these crimes weren't perpetrated by a single man, it required the willing negligence of thousands, perhaps millions, of people to bring them about. If you can charge the hacker with manslaughter, then you can charge Microsoft and the Hospital that chose their software too. Those people were dead as fried chicken from the moment the hospital bought microsoft, for it was certain that someone was going to turn out to be more sinner than saint eventually.
The only logical approach to security is to require ALL players to take reasonable action to protect the system and themselves. Then, if the system is carefully designed and deployed, and yet it comes under careful and concerted attack, then you have actual resources to track down the offenders, rather than just sweeping through colleges looking for delinquents. It's hard to bust someone for trespassing if you don't have a fence around your property. This columnist would support shooting someone who steps on your property, even if it's totally unmarked and unprotected. This is totally unacceptable in any sane legal framework. Maybe if you have a fence to keep out the neighborhood kids, but some punk jumps it anyway, well then maybe, but even that is stretching the limits of belief.
Agreed. The Pro-death-penalty crowd always relies on at least one of the following two arguments....
1) They deserve it, and it will make the victims feel better.
Personally, I do not like the idea of living in a society where our justice system is based on inflicting misery on some people to make others feel better. End of story. By that logic (about to invoke goodwin's law) you could easily justify any genocide by saying "it makes me feel better".
2) IT is a deterrent.
Criminals are not perfectly logical beings, many of them are clinically insane. This doesn't even pass the laugh test.
Here's the problem. Design a system that is completely succeptable to malicious people, and be shocked when somewhere, among the 6 billion people out there, one is malicious. Here are your two solutions....
1) Make the system less succeptable to the darker aspects of human nature.
2) Just take out your fury on the guy who installed seti at home on a work computer.
In the physical world, this argument doesn't even pass the laugh test. Lets say there's a military base, but it has no fence around it. When children wander in and screw with things (perhaps causing serious damage), they are shot. That's hardly a solution. Put up a fence so some five year old doesn't wander in and drive a tank on the freeway, then maybe talk about giving more severe punishments to organized and competent attackers.
Here's another example. At Columbia a few years ago, an elevator in one of the dorms plunged several floors, though fortunately nobody was hurt. They had to repair the elevator. Let's assume that the cost of this came out to $100,000. Columbia blamed the students for jumping up and down in the elevator, nobody knows if those claims are true. In the end, it doesn't matter. An elevator is a moving piece of floor, if jumping on a piece of floor endangers you and causes damage to the building, it's the designer's fault, not yours. If you try to steal $100,000 from a liquor store you'd be shot, should you be shot for jumping in an elevator? No, because reasonable precautions would have prevented that. Save severe punishments for serious malicious attacks that threaten human life and for which there is very little that can be done. If you can build a fence, or a decent elevator, then just start with that, and worry about your bloodthirst later.
Slashdot Mirror
don't put dark matter in the same boat as relativity. People question because there arre obvious (to a physicist) problems in modern physics. There are no obvious problems in thermodynamics, so if you want to question that, then the burden of proof is EXTREMELY high. This is especially true given that TD rests upon a RADICAL statement that goes something like this "more probable things are more probable", which is reallly pretty hard to dispute.
Anyone who actively disputes TD without showing the next Nobel prize winnign theory is a quack, plain and simple.
Don't just blame the oil companies. Most of them have even admitted it. It's the lunatic administration that's holding on to this insanity. This is the same guy who wants to teach Intelligent Design in school, he's never seen a piece of junk science he didn't like.
I don't particularly agree with even the first part of that asessment. I've worked at Microsoft, and now at several financial firms as well. The work I do for in house programs is MUCH more interesting than anything I ever did at Microsoft. The pay and hours are better, and the work is wildly more interestings. Perhaps I'm a bit biased though.
Really hard to know that there are no US citizens in gitmo, when nobody will tell us who these people are. How do YOU know there are no citizens there, especially since I seem to remember the gov publicly admitting that there are several US citizens (who were nabbed in Afghanistan) currently rotting in Gitmo.
That is what scares me, too many secrets. If the gov wants to keep something secret, that's fine, if they want to keep a trial secret, they should require a vote of the senate or something, for each instance. At least then there would be some oversight, such as it is.
Bluetooth and Airport become standard. 14" model gets a superdrive, both models get more RAM.
It's a substantial improvement all around.
First of all, they do have some data. They can simulate the models of weapons they had before and make sure the simulations match up with what actually happened in the test. This sort of thing is also useful for things like fusion/fission reactors, and other far out stuff.
At the end of the day, it's pure research. There is very little pure research that is not (eventually) worth it. This is a cost that gets to be amortized over the remainder of human civilization, conservatively pegged as at least 100 years.
The shuttle is hardly a lemon, and the problems it has come from the fact that it pushed well beyond the contemporary technologies of the day. If we did it again, it would be much better. It also largly predated good CAD and DFE analysis tools.
Look at modern cars for a good example. They are designed down to every last screw by computers. They take less material to make, they are more efficient, and they are more reliable than older cars. The same will be true of the next reusable orbital craft. It will be intensely designed, it will be better than the shuttle in every way, and presumably safer as well.
This is exactly correct. Appservers are often used for backend data processing. Usually something like, run a JMS server, let people publish data on it. Take the data, do something with it and a bunch of other data in a database. Make the results available through EJB, or possibly a web page. These tend to not be used for just webpages based on databases (simple shopping carts), but more for realtime trading, risk analysis, data processing, etc...
Ruby on Rails and a J2EE appserver are completely different. However, it is possible to use an appserver to do the sort of things you'd do with Rails, the reverse is not true.
A JSR-168 compatible portal might be a good solution. It would take care of things like single sign on, and they usually have a fair number of useful modules. You should be able to find some forum and wiki modules, among others.
These things take some substantial work to configure and set up, but once set up, they tend to work very well. You could look at Jetspeed or JBoss, for starters.
These modules are also (slowly) starting to become comodities, so you should be able to get lots of useful functionality stuffed in there without having to write too much code. The various departments and such can each write their own little portlet, and get it all integrated into the whole.
These things tend to be more for dynamic sites, but I could see one working pretty well even for a static site. They often have lots of content management features, etc... Usually they are DB backed, but a good postgres install shouldn't be too hard to come by.
Hardly. They would have to do something that was significantly likely to hurt outsiders, and those sorts of "innovations" should be discouraged. At the very least, make the investors take the risk. The real problem with the current situation is that all the rewards go to the investors, but much of the risk is born by the guy who lives down the street from the factory. All the risk should be born by the investors, that's part of what investing is.
This train of thought is actually very common in our world today. For instance, you can take products back to the stores if they are defective. That's because business bears the risk, not the customers, that's a large part of what business is, risk analysis, so it makes sense to put as much of it in one place as possible. My grandmother isn't a risk analyst, I (to a degree, more precisely, my software is) am, consequently, making the risk come through my doors keeps me employed
Exactly. There are a lot of programmers who don't understand that less is better. Java has already allowed too much, though my gripes are likely a little non-standard. For instance, curly braces after an if/for/while should be mandatory, not optional....
The whole point of a language is to codify thought in a unambiguous and easy to understand manner. Having 20 ways of doing anything doesn't help. The guys who love C++ also tend to be the loudest, most obnoxious bunch when it comes to standards. If java was released, they would push and push until they go operator overloading, function pointers, pointers, malloc, free, etc... into the language. This is what happened to C#, and it makes the thing unbearable to use if you don't care about the religion, but just want to do your job.
Furthermore, most of the suggestions would fundametally undermine the (supposed) purpose of Java, protected memory through type safety alone. This is provably possible with java (provided you have a competent VM and no JNI), but provably impossible with any system that allows unrestricted pointers and similar trash.
Java remains futureproofed as long as it is well defined enough that it doesn't depend on underlying hardware. Throw in too much trash, and you'll lose that, and people will (like they did with C++) wonder just why the language sucks so bad, and where all these bugs came from.
You're right about most things, but in the case of Sun's java, you can read the source behind the core classes. Rarely would the source behind the hotspot compiler (doubtless one of the most complicated pieces of software ever written) help you.
Not that I disagree that opensource would be better, but I'm not sure that it's best to spend the effort to attack a system that is very close, when there are so many that are not close at all.
That being said, it's good to have large, complex systems like this opensourced. Maybe then it can finally be put in as the top level of Linux and dispell all the libc/x11/posix/kde/GTK nastiness once and for all. One API to rule them all.....
You overshoot the mark somewhat. Any system that is fundamentally sound from a gametheory standpoint would work, it wouldn't have to be our current system. Often it is not exactly like what we see in the wide world. For instance, academia has an economy all its own, based on paper publishing and such, this is vaguely similar to the financial economy, but not exactly the same. There are many similar examples.
You perfectly well can "dream of a better system", but the system needs to be viable. That is to say, you need to envision a system where you desire the Nash Equilibrium that would arise from that system. In this light, there are probably many changes that could be made to our current system to improve (or at least alter) it, without being nonviable. Communism isn't one of them, but accountability probably is. To claim that the only possible system is the current system shoots far beyond what is actually supported by (ironically) economic and game theory. That line of thought will lead you to disregard viable solutions to serious problems out of a pseudo-religious zeal, which is fairly common these days where economics are concerned.
I'm with you, except for limited liability. It badly distorts the game theory when a corporation can take a tremendous gamble, if that gamble wins, the investors get money, if it loses, the corporation goes bankrupt and people other than the investors are left holding the bag.
This causes a lot of questionable behavior, for instance, the actions of the tobacco industry, and various environmentally unsound practices are supported by this sort of logic. Get your money now, when your past catches up with you, go bankrupt while the investors retire in Bermuda.
Investing in a corporation is a one way transaction. Everything good crosses over and goes to the investors (in theory at least), while everything bad stays with the corporation. That's hardly fair. Granted, our financial system would need some overhauling in the situation where limited liability was gone, but it would be workable. The simplest means would be to just sell insured shares, where for a fraction of the dividend (or whatever) an insurance company is willing to take the hit if the company goes under. Would probably only cost a few clicks, but it would be readily apparent which corporations were engaging in questionable behavior, because their insurance rates would be higher.
Then why are you wrong... Lets start.....
First of all, the cost of virtual memory. As we all know, it is not free. Google "virtual memory cost TLB percent" and hit "I feel lucky", you should come to this page...
http://developers.sun.com/solaris/articles/optimi
This is talking about a common case where an app causes a lot of TLB misses, using a substantial proportion of the execution time doing nothing but VM translation. Notice that the performance penalty is (in their example) roughly 30%, due to TLB misses causing floating point pipeline stalls. This is a commonly accepted figure. EVERY TLB miss will cause a few hundred clock cycles. A TLB miss rate of even 1% will have a SUBSTANTIAL effect on performance. Running without Virtual Memory (in system mode) completely eliminates the TLB and all of this performance is reclaimed. This is possible with any truly typesafe system, such as JAVA.
Secondly, compilers..... Yes, some of the compiler/verifier is on the client, however you could just as easily say that the hardware underneath is a compiler itself (translating CISC x86 instructions to RISK opcodes), so this terminology isn't particularly meaningful. It becomes totally misleading when you consider that there exist hardware platforms that can execute java bytecode directly. My meaning should have been clear from context to someone of your credentials. In any case, most of the checks are done within the compiler (Hotspot), though that compiler happens to reside on the client machine. If you dislike this being referred to as a compiler, then that is your business.
Third, you include some extremely bad examples of runtime checks. Modern Virtual Machines already eliminate a lot of array bounds checks with compiler passes (though granted, this particular compiler pass is performed on the client machine), and null pointer checks are handled by a hardware interrupt, just like an integer divide by zero. Both of the examples you gave are very unfortunate, as they are two checks that rarely actually must be performed by software.
As for your question of whether or not the software checks in java are more expensive than the hardware means, there is very little direct research available, but Java is commony accepted to be around 95% of the performance of straight C, and Virtual Memory is commonly accepted to be about 70% of the performance of System mode, so you tell me. For instance, see...
http://www.idiom.com/~zilla/Computer/javaCbenchma
I wouldn't have assumed you were junior if you didn't make such classic mistakes.
Once again, it is very foolish to make claims about my chip designing skills. Everyone who has investigated the issue accepts that modern CPUs do the best they can GIVEN that they are running unsafe languages. It is also commonly accepted that dramatic efficiencies could be realized (I just gave one example, no TLBs needed, saving around 30%) if the software itself could be proven safe. It would be another mistake expected of a novice confuse this rather clear cut situation and claim that I was calling the Intel designers idiots.
Who knows, perhaps in your zeal to call me out as a fool you skimmed over some implications and said things that didn't sound particularly well founded.
However, since you asked... I'm a BA in Physics from an Ivy League institution. I currently work in computational finance. I spend a great deal of time working with java, and occasionally native code. We are largly performance bound, so I have studied this issue extensively.
Pick up an OS text book once in awhile. Memory protection (stuff running in User mode, with virtual memory turned on) is around 30% slower than stuff running in system mode (with memory protection turned off). This is true regardless of things like context switches and system calls. The whole page table doesn't fit into the TLB, so you have to have cache misses from time to time, and they are EXPENSIVE.
I'm not saying they're idiots, they did the best with what they had. If you have to support unsafe languages, then you're going to take a hit making them safe with hardware. Making them safe in software costs a few percent (compare simple java programs to simple C programs, their speed is very close if they are similar enough), hardware takes a few tens of percent.
You are a poser, and you know next to nothing about computers. Go to college, take an operating systems class, and actually try to learn the material.
Good points all around, I'd like to just add a few things...
.NET (if it ever happens), the others may move as well.
.NET. When this increases further, you can probably expect to see the VMs take over, relegating much of that 30 year old code to the dustbin of history. After everything is VM based, the virtual memory will probably also head for the trash heap, and hardware would likely become much cleaner and simpler.
First of all, a massive reimplementation is underway. Software is migrating to VMs at a fairly impressive pace. The only ones who seem to be holding out are the shrinkwrap vendors, but even then are starting to buckle. When Microsoft moves significant code to
Already, custom coded apps are almost always writting in Java, or (shudder) VB and
I'm mostly disappointed with Apple for holding off on this to the degree that they have. Java is a natural fit for them. Write a VM that looks and feels native, then make all their apps in Java and sell them on windows as well. By blazing the trail they might be able to get others to similarly write in java, and level the playing field for themselves. If the linux geeks would bury their long held animosity, then they could make a similar move, and attempt to take a real position on the desktop. Instead, they thrash against a a technology that is not only a natural fit for them, but is also, almost indisputably, the future, and they remain relegated to server closets where the admins install java on them anyway and they are workhorses for JBoss. Grow a brain guys.
We are not going to use it up. Uranium is more common than Tin, and present in fairly significant quantities throughout seawater. If there wasn't so much high grade ore lying around, it would be cost effective to get Uranium from seawater rather than give up our nuclear reactors (which are all cash cows now that they're running at 90+% capacity 24x7), and this source would last for thousands, if not millions, of years.
Anyway, it's not going to come to that, there is just too much Uranium to plausibly even have to look very hard for it for hundreds of years. However, since pretty much all the world's current supply comes from a half a dozen motherload mines in Australia and Canada, those might run out within 50 or 100 years, at which time we'll have to pay slightly more for it, and the cost of nuclear power might go up by a few hundreths of a percent, but still be dramatically cheaper than any other major source of power available, even coal.
You just need part of the compiler to run on the client machine. Java, OCaml, etc.... They all do exactly this, and they work very well....
It is likely that a machine that could only run java would be faster running java than a normal machine is running C. The reason is that a java only machine could turn off all memory protection (as everything would have to be safely inside the VM, except the kernel, which wouldn't be protected anyway). Memory protection verifiably costs you something like 30% of your performance. That number was from a few years ago, it has doubless gotten worse, not better. That much performance would overcome the couple percent performance handicap java has, and give it the edge. The same would apply to OCaml, etc... Anything that's VM based would have this advantage...
Think java. There is no "writing binary by hand" because the JVM still verifies it. It is not possible to construct a valid
This point is correct about EXACTLY one city in the United States, NYC. No other city is even remotely tolerable without a car. NYC is almost intolerable with a car, so you're better off taking the subway.
Not that the feds haven't done everything in their power to shaft the NYC transit system, but that's another story, and that's probably just because it's about as blue as they come, and the repubs don't want it to become any bigger, rather than them trying to make sure there's a market for our Oil Barron in Chief's wares.
How about a few of relevance....
1) P ?= NP
2) Memory protection through typesafety alone. Would give all computers a 30+% boost to performance if the security was handled by the compiler, and not the hardware.
3) IPv6, static IPs for everyone...
4) Diamond semiconductors. Smaller features than silicon (the carbon atoms are physically smaller), able to withstand immense temperatures, higher performance, more efficent...pretty much just better in every way.
5) Non volatile ram that doesn't burn out. Instant on computers, and more...
How's that for a top 5 list of things to do before 2025?
Be very careful about trying to "fix everything" after hours. That's how we do some things (and did the same thing at my previous place), and it's a nightmare. If anything is wrong in the morning, then it's hard to go back and re-run the previous night's batch processing. Often it takes too long, often you would just corrupt data further, etc... Very often this results in us having to just have incorrect data for a day, and then get it right the next day. In addition, due to global expansion, we only have 2 hours each day in which to run this stuff. If a market were to stay open an extra little while, or we try to expand somewhere in the forbidden slot, I don't know what would become of us.
You are far better off trying to get everything to be realtime, as much as possible, and build in mechanisms for the system to recover from corruption and incrementally do batching throughout the day. Do NOT rely on the fact that the system goes offline for 8 hours each night, that's an easy way to produce a system that costs you your job.
So, pricing your cancer drug at $100,000 per year is manslaughter too, right?
http://www.nytimes.com/2005/07/12/business/12canc
Lets leave all this BS on the table for a second. It seems to me that politicians are responsible for making the game such that society is the winner. If they let a company price its drugs at obscene rates, and yet require it to be covered (and don't punish the companies for letting people die), then you've effectively created a wonderful monopoly, while simultaniously claiming to use the free market. Here's a hint, markets don't work when the alternatives are "pay us whatever we ask, or die".
Similarly, these crimes weren't perpetrated by a single man, it required the willing negligence of thousands, perhaps millions, of people to bring them about. If you can charge the hacker with manslaughter, then you can charge Microsoft and the Hospital that chose their software too. Those people were dead as fried chicken from the moment the hospital bought microsoft, for it was certain that someone was going to turn out to be more sinner than saint eventually.
The only logical approach to security is to require ALL players to take reasonable action to protect the system and themselves. Then, if the system is carefully designed and deployed, and yet it comes under careful and concerted attack, then you have actual resources to track down the offenders, rather than just sweeping through colleges looking for delinquents. It's hard to bust someone for trespassing if you don't have a fence around your property. This columnist would support shooting someone who steps on your property, even if it's totally unmarked and unprotected. This is totally unacceptable in any sane legal framework. Maybe if you have a fence to keep out the neighborhood kids, but some punk jumps it anyway, well then maybe, but even that is stretching the limits of belief.
Agreed. The Pro-death-penalty crowd always relies on at least one of the following two arguments....
1) They deserve it, and it will make the victims feel better.
Personally, I do not like the idea of living in a society where our justice system is based on inflicting misery on some people to make others feel better. End of story. By that logic (about to invoke goodwin's law) you could easily justify any genocide by saying "it makes me feel better".
2) IT is a deterrent.
Criminals are not perfectly logical beings, many of them are clinically insane. This doesn't even pass the laugh test.
Here's the problem. Design a system that is completely succeptable to malicious people, and be shocked when somewhere, among the 6 billion people out there, one is malicious. Here are your two solutions....
1) Make the system less succeptable to the darker aspects of human nature.
2) Just take out your fury on the guy who installed seti at home on a work computer.
In the physical world, this argument doesn't even pass the laugh test. Lets say there's a military base, but it has no fence around it. When children wander in and screw with things (perhaps causing serious damage), they are shot. That's hardly a solution. Put up a fence so some five year old doesn't wander in and drive a tank on the freeway, then maybe talk about giving more severe punishments to organized and competent attackers.
Here's another example. At Columbia a few years ago, an elevator in one of the dorms plunged several floors, though fortunately nobody was hurt. They had to repair the elevator. Let's assume that the cost of this came out to $100,000. Columbia blamed the students for jumping up and down in the elevator, nobody knows if those claims are true. In the end, it doesn't matter. An elevator is a moving piece of floor, if jumping on a piece of floor endangers you and causes damage to the building, it's the designer's fault, not yours. If you try to steal $100,000 from a liquor store you'd be shot, should you be shot for jumping in an elevator? No, because reasonable precautions would have prevented that. Save severe punishments for serious malicious attacks that threaten human life and for which there is very little that can be done. If you can build a fence, or a decent elevator, then just start with that, and worry about your bloodthirst later.