Something I think I'll point out. If you want a little toy database, consider HSQL. It's about as good of a database as MySQL (give or take), but it's written in Java (runs on anything), is about 300k or so in size, takes all of ten seconds to set up, and is actually much more SQL compliant than MySQL.
If a tiny easy to use database is all that you need, HSQL is for you. The one real gotcha though is that it can't handle datasets larger than 1/2 a GB. That's way too small for real database servers, but more than enough for most websites, even many commercial ones, I imagine.
In addition, HSQL can run within your java apps, which is really nice. I usually go for a dual pronged approach. use HSQL to handle all the file BS that you app might need (various config parameters, a small data cache that can be sifted efficiently in lots of different ways, other nastiness) and as (small) test databases to try a new idea.
For real DB work though, trade up to Postgres, and be sure to get 7.4, the 7.3.x line has a lot of crippling bugs.
The one real gripe I have about Postgres, is god, these people are in love with Hash joins. Any really good database should avoid hash joins like the plague unless it can guarantee that all the data that could possibly be returned by a subquery will fit into RAM. Postgres often wildly mis-estimates the size of a sub query, decides to hash it, and then gets killed when the query returns 100,000 rows, rather than 100.
A real database using a hash join when it doesn't know that it can take the whole table into RAM (if needed) is just begging to get run over. This is one of the few things that can really knock out an otherwise good database, and really should be considered more carefully. Hashjoins are for small reference data tables (few thousand rows), and should not be used unless you're guaranteed to be surprised.
HSQL of course doesn't have this problem, because it doesn't mess around with these "big" tables that are all the rage nowadays.
Answer is simple. Corporations are not people. The rights of people should always trump the rights of corporations, end of story. Unfortunately, with the republicans in office, the exact opposite is true. For instance, think about all the router manufacturers (and others) who are illegally distributing GPLed software. Under the current (anti music sharing) laws, that comes to 1/4 million dollars and 5 years in prison per offense, multiply that by a million or so, and we're talking a trillion dollars give or take, and at least 50 years per employee.....
Now, why have none of these cases ever gone to court? Oh, that's right, because corporations aren't subject to the laws of the land like mere pople are. Sorry, my bad.....
Downloading is not illegal unless they can prove that you don't have a license for the music, and you aren't going to use it in ways consistent with fair use. If I have a truck load of CDs and I decide to download MP3s of them rather than ripping them myself, that's perfectly legal.
The problem for the RIAA is that proving that a downloader doesn't have a valid license is essentially impossible, so they can't really bust you for downloading.
While this soudns like a good idea, it probably isn't. If you don't calibrate your functions correctly you can easily have blue-sky disasters. I know it sounds like I'm making these words up, but i'm not.:-)
A blue sky disaster is where one variable explodes to infinity at a specified point in time. This is easily caused by many classes of functions where they start to feedbackon each other. In fact, keeping stability when the median income is affected by the minimum wage, which is affected by the median income, etc... is a really hard problem. Most of chaos math is based on trying to figure out when systems like this will explode. Most of them have a way of slowly working their way into a regime where they catastrophically fail.
Very similar to a ship being rocked by waves or a skyscraper pushed by wind. You have to be very careful that there are no resonances, or you have to stay very far away from the "edge" of your safe zone to avoid being pushed over or capsized.
mod this guy down. This has got to be the stupidest comment I've ever seen. If you have nothing better to do than hack parking meters, then go ahead. In addition, I'd love to hear exactly how you plan to get actual access to the thing, and what you intend to accomplish.
I imagine the thing has at least tolerably strong wireless encryption (shoot the designer if it doesn't), and nothing to offer your average hacker, case closed.
Let us not forget that the US is the third largest country in the world, both in terms of land mass and in terms of population.
In population we're behind...
1) China 2) India.
In land mass we're behind....
1) Russia 2) Canada
Oh, and of course economically we're number 1 by a huge margin (though growing smaller under the republican leadership). Larger than at least numbers 2 and 3 combined, and probably a fair bit more besides.
So let's not go all european and claim that the US is some middle sized western country.
Lets be accurate here.... It's impossible for an object with INTRINSIC mass to reach the speed of light. A baseball has intrinsic mass when it's sitting still. When it's moving it has its intrinsic mass plus its mass due to velocity. A photon has no intrinsic mass and therefore it can never travel at any speed but the speed of light (little more convoluted here, but I won't bother to explain). Light can travel slower than the speed of light through media only because it is being canceled and regenerated by the electrons in the medium.
As for the faster than light stuff, well I never really studied that, so I won't comment, but the parent is at least mostly correct about that. In particular, the real problems only come about when information travels faster than the speed of light, because that violates causality.
Now, I'd like to also point out that there is no real reason why we can't violate causality, causality is in fact highly overrated. People always tell the metaphorical story about someone going back in time to kill his father, but they never really think about it. Quantum uncertainty indicates that each time you go back the result will be a little bit different, so there is no such thing as an infinite loop (it must break 'eventually' because quantum uncertainty will cause you to burst into flame or get hit by a bus or whatever). So, go back, kill your father, don't exist, don't go back (because you don't exist), nobody kills your father, so you exist, so you go back......get hit by a bus, and there we have it, the time line is correct again.
Actually, I was thinking about exactly that problem..... though I am perhaps a bit of a crackpot.
Here's what I figure. A device driver is really two parts. one part actually reads from and writes to the device, the other part is the actual code. The reading and writing part could be handled by allowing some sort of low level VM call (assuming the VM is somehow embedded in the OS, so you can have this sort of access, it would also have to run in system mode). Basically some sort of native code takes care of the bindings and then loads up your driver with some sort of context object that contains (perhaps) a bunch of byte[] objects that represent the memory the device driver will use to communicate with you. These arrays are pinned in ram, so they always exist at the right location.
Then you write your driver, use the byte[]s to communicate, are guaranteed that your memory addresses are always correct (if they started out correct) and all your code is safe. In addition, it would be nice if when you driver threw an exception (should never happen, but who knows) the System should just re-initialize the driver and reset the hardware (works better on video cards than harddrives, but I'm not a hardware hacker, so cut me some slack) and continue.
Basically, what I'm saying is that an OS should include a VM in system mode, and then throw everything possible into the VM to get security and protection. Even most of the device drivers could go into the VM (using a technique somewhat like that above) and leave only the basics of scheduling/memory management in the kernel. Less kernel code means fewer crashes (less code in system mode that can take down the system, especially the drivers), and Java programs could run in system mode (substantial performance increase) while native apps could run normally.
Planning to optimize for the platforms that don't exist yet? Some of us want our code to run (and run well) in a year, not just today. And no, moore's law isn't enough. It's expected that code from yesterday should run faster today, not the same speed, when used on better hardware.
So, compare the performance of a 5 year old binary vs. a 5 year old java program on your spiffy new computer, and tell me which one fares better. Use a modern JVM mind you, and you'll get advanced modern code from the old java file, but crappy code written for an old 386 from the old program.
Now lest you say that old programs don't need performance, allow me to point you to CLAPACK (written in C no less) and note the fact that it needs performance more than anything, but it's a pain in the A## because you need to be willing and able to recompile it in order to get anything out of it. It also has all the old crappy manual inlining and all that BS. I'm not advocating writing it in java (though I tried parts, it wasn't that bad, but I never got a good comparison) but at least if you did you wouldn't be carrying around decades old BS in a system that critically needs to be very fast.
I imagine that a java version (even with all the old cruft) would be de-crufted at runtime to the point where it would outrun the 5 year old binary version that is probably embedded in dozens of programs out there. You might even be able to read it without going insane, as well.
Guys, it's time to face the facts. C is a relic from a time when compilers were stupid. Declare all your variables before executing code, declare all your functions before using them, include headers that almost invariably break one another, hurrah.
I'm so glad that every time I write C I get to write each function signature several times, that's lovely. In addition, C takes much more time to compoile than Java/C# because all the stupid headers take forever to parse.
Now on to preprocessor macros. They are useful in statically compiled languages, but in dynamic (VM based) languages they are less than useless. The VM will take any code that it can and inline it, propagate constants, etc.... Macros are not needed.
Thirdly, pointers and "suggested" types. I say suggested because the type system isn't enforced, why bother with types at all if they don't mean anything. Pointers are a problem because they allow unsafe code that forces the hardware to make up for lack of security in the software. Repeat after me, security is a software problem. Memory protection is also a software problem. The modern computer throws away about 30% of its performance on various protection schemes. More than enough to make up for using a language like Java or C#.
So, in conclusion, C compatibility is a bug, not a feature.
True, I was partially keeping to cases where it could (and someday, presumably, will) be faster. Anyway, I'm not claiming that you can turn off garbage collection. I'm claiming that people can often write better algorithms when they don't have to manually manage memory than they can when they have to track down every pointer that might become unreachable and delete it.
I just don't like the assertion that much of slashdot makes that VM languages will always be slower. In the long run the reverse should be true. The first cars were slower than horses, but it was only fools who believed that would long be the case. Slashdot seems full of such fools.
1) Programmer time goes for about $50/hr. That means that a prrogrammer spending 20+ extra hours could have pretty easily bought you an extra dual CPU computer to run the thing on. That's only 2/3 days of work. Java can easily shave off much more than that.
2) Java isn't that slow. Depends on what you're doing and how you're doing it, but it's not crazy to get java to be less than 50% slower than C. It's also not really uncommon for it to be faster. When it is faster it's almost always because better algorithms are used, but that isn't an accident. It's much easier to write good algorithms with a garbage collector sometimes, as you don't have to track down and delete all the stuff you unlinked.
3) The one weakness of java (until VM sharing becomes available) is memory usage, but memory is really cheap now, same basic logic as CPU time, but even more so.
4) Lots of additional optimizations are possible in VM based languages that aren't tried by any modern VM. When they start to come online, expect the performance of the VMs to surpass compiled code. Here are some examples....
a) Escape analysis: all stack frame scoped data goes on the stack. Basically it makes optimal use of the stack, can't really be improved any. This is why C#'s "value" types are so stupid, they shouldn't be able to help (and would probably hurt) a good VM. Anything larger than a pointer should be a reference, the VM can put it on the stack if it's possible to do so.
b) Method virtualization: a good VM should strip down pretty much all of the V-tables and just regenerate what it actually uses. This is why the "virtual" keyword in C# is so stupid, it should have no effect on performance assuming a smart VM. Can also do all sorts of inlining that a normal compiler can't do (someone could link to your library, you can't inline away public functions).
c) "incorrect" optimizations: The VM can create optimal code that is not actually a valid representation of the given code for all inputs. Can then revert the code if an input is given for which it is not valid.
d) Profiling: a VM can (and modern ones do) profile the code and optimize the common cases at the expense of the uncommon ones.
e) Hardware knowledge: a VM can always produce code that is optimal for exactly your hardware, right down to cache sizes, processor model, and memory latency.
Just though I'd throw these things in. Those who expect VM based languages to always be slower will probably be in for a shock in the future. Remember, the cost of compilation is basically constant whereas the payoff from optimizations is linear in CPU speed. At one point the optimizations will exceed the cost of compilation. It's only a matter of time.
To make it simple it doesn't have to be flat. A classic example is a hyperbolic tax code. The function approaches an asymptotic limit (say 50%, if you want to do something similar to our current code), then what you pay is still very simple. Just plug it into a simple formula, Y = f(X) where X is your income and Y is your taxes. Simple.
The real thing that would help is a couple simple things.
1) Tax code based on continuous function. (not steps and other BS).
2) When you claim the value of something for property taxes the government can either accept your taxes, or buy the thing from you for the price you specified. Voila, no more property tax cheats.
3) Get rid of most of the subsidies. These are mostly corporate welfare. Conservatives always complain about welfare for poor people and arcane tax codes, but the corporate welfare rules are more bizarre, and cost far more than the welfare that puts food on the table of the poor.
4) The country should have one class of capital offenses. White collar crime and nothing else. The threat of the chair won't deter crimes of passion, insanity, or hopelessness (most crimes, murders, rapes, etc....) but it sure as hell will deter Embezzlement, bribery, and all manner of Enron/Halliburton style nastiness. White collar criminals are precisely the people who weigh the payoffs vs. the consequences and take whichever action is best on average. Tougher consequences will stop most of them.
This is the problem with Linux, unix, windows, and pretty much every other OS out there. Configuration is hard. Fedora Core 1 takes a fair amount of that difficulty out (as do other Linux distros), but seriously, they need to try hard to get to be more like OS X.
Here are some pointers......
1) XML. If it's going to be a config file, make it XML. The speed issue doesn't matter for config files, and the fact that it's self validating (xsd, dtd, whatever) helps immensely. It's not hard to write a simple program that can understand XML config files using basic XML toolkits, and people might even be able to understand them too. Better than files full of order sensitive key value pairs, yuck.
2) The second thing to do is to make GUIs. This is very important. Most necessary configuration should be available from the gui. I don't care about properly setting up anything, I just want to set my IP address (one of the things available in a GUI under modern linux) sort of thing.
3) God I wish people would store system wide settings in an actual database. It's nice that pretty much everything is stored in some sort of bastardized hashtable (registries, etc....), but seriously, there is a standard for databases, it's called SQL. A only moderately sucky SQL server is about 250K (Hsql), peanuts compared to a modern OS, and if you used it then you could garantee all sorts of integrity constraints on your data, and it would also be transactional, eliminating most of the nastiness of systemwide configuration (lots of reboots, etc.....). Another advantage might be that it would be great at helping you to truly know what's on your computer. The SELECT * FROM mappings m where NOT m.program IN (knownPrograms) sort of thing that can easily kill off spyware, etc.....
don't be a fool. It's clear to pretty much everybody that somethign you get for free doesn't have the same standards as something you have to pay for. If you badger me into building you a dog house, and it falls down and kills your dog, too bad. If you pay a contractor to build you a dog house, then you might have some recourse, as you bought a dog house, not a death trap, whereas we (if I built it for free) never really had any sort of agreeement, as there is no payment or contract to indicate that I even know you.
It seems like this could so easily be a non issue, and probably already is under current law.
I imagine this is covered by Clinton's good samaritan laws already. If you're trying to help by giving CPR, or giving someone free software that you believe will work, then you can't be held responsible for the consequences.
probably less than that. The stuff will be so diluted I'd be amazed if you could event detect the difference. Plunging reactor cores into the atmosphere isn't something you want to make a habit of doing every day, but doing it occasionally (200 years after the reactor has last run, to let the radioactivity die down) won't hurt anybody. This will certainly dose us with less radiation than your average solar storm, much less.
Ah, but this isn't a market. It's a deregulated monopoly, which always (ALWAYS) drives up prices. Unless people are willing to pay for ten cable lines to each home so you can pick your favorite one, there will never be a market in cable/phone/power/water/sewage/dsl/etc... end of story.
Deregulating them will result in the consumer getting fleeced at a tremendous rate.
I could go all political and indicate who would gain the most by said fleecing (cough* republicans, cough*) but I won't. Deregulation of natural monopolies is one of the stupidest ideas ever, right up there with Supply side economics.
People need to start to demand that their government policies at least pass the sniff test. If you can't see any way that it could be plausible, then for god's sake, try to stop it.
Classic case, Supply side economics, goes like this....
1) Give money to rich people. 2) ???? (maybe they spend it on bigger houses, or ship it to their swiss bank accounts, who knows what happens here). 3) More stuff is bought (we have just paid rich people to buy bigger limosines, essentially, the taxpayers have bought luxury items for the wealthy) 4) Everyone* is happier.
* Everyone may not include you if your annual income is less thatn 600,000 per year or if you are adverse to white collar crime. Results may vary.
Perhaps I'll propose "Tyler Side Economics" next. Just give your money to me. I'll spend some on strippers and booze, and stash the rest in switzerland, and as a result, who knows, maybe people will be happier and wealthier, why not, I'm sure I will.
Or how about we write in a language that has security built in and leave software security as a software problem, rather than making hardware even more byzantine, power hungry, expensive, and unstable.
But then again, maybe I'm crazy.
After all, not all operating systems will let just any random program randomly rewrite sectors of the harddrive with random data.
Unless the firewall was running as root that is, which I suppose in windows it would be, and maybe on Unix too, but then again, Unix tends to have good firewalls built in.
Basically, it wasn't relying on anything specific to windows, but then again, it's unclear that a firewall running on anything but windows would have been vulnerable in the same way....
and I also might add, why don't people program in Java, this sort of thing won't happen. This worm (like pretty much every other worm) takes advantage of one huge security flaw. The flaw is that programmers use an OS programming language to make general purpose apps. That is often the core of the problem.
This seems a strange assertion to me. I just got done using HSQL (google it, sourceforge page comes right up) for some DB work at work where I didn't want to screw around with installing a full fledged DB on my workstation but still wanted to query tables.
It's fully opensourced, written in java, a 250K jar file that can be dropped into pretty much any application to run embedded, as a server, memory only, whatever, and it work's quite well.
It loaded up about a GB of data into six databases, sifted and linked everything up correctly and then saved out the 18 MB (compressed) result in about an hour, not bad for juggling about 4 million rows and sending each one through a couple of transforms. This was on a pretty normal workstation 2.4 Ghz, 1 GB ram. I'm sure postgres could have done it in half the time (faster anyway) but that would have required installation, whereas HSQL requires you to add a jar to your class path and then pretend you're connecting (JDBC) to a server, which really (in this case) exists within your own application.
I'm not sure why OOO doesn't just embed HSQL and call it good. It's not a real DB (like postgres, oracle, etc.....) but it's probably on par with the fakers (mysql, access, etc.....). Oh, and apparently it can be used with OOO as a database backend, but they don't include it as the default, and I don't really know why.
This brings me to another point. The number of projects out there that think they need to spend precious effort manhandling text files is absolutely amazing. Two things to consider before you even consider writing a flat file....
1) XML, it's slow, but at least people might be able to understand your data, and you get all the format checking, etc... for free in pretty much any decent language (Java, C#, who knows, maybe even C).
2) HSQL, only an option if you use Java, but if you do, then just have HSQL load up all your prefs as a database, etc... It makes life much easier to know that your program has a DB embedded in it (only takes a couple megs of ram, and adds 250K to the download size) so you can save preferences and other data in a simple and consistent manner without juggling endless folders full of flat files (or XML). The classic example of where this needs to be done is in your average Java email server. There is no point in having a file storage mechanism. Force all storage to be JDBC, and then if you don't have a DB, it'll use HSQL embedded, or connect to the DB of your choice. Voila, 1/4 of the codebase is no longer needed, less stuff to configure, less stuff to break, everyone is happy.
Here's why. I'll take a small example.... Howard Stern. A while ago he came out against bush (he had formerly been a bush supporter) and two days later he was fired, for no apparent reason. It turns out that at least 8 other DJs have also been fired from Clearchannel for saying anything anti-bush, and most of them didn't have the star power to make it through, like Stern did.
Now, imagine a future where everything you ever bought (right down to the tolls on roads, medical records, and pretty much everything else) is in large databases held by companies like Clearchannel, who are clearly partisan (witness the firings) probably because they want more tax cuts. It's not hard to imagine that all of these databases will be neatly collected, and sifted for dirt on any opposition canidates that should come along.
Now, this won't prevent you from running for office, provided you're willing to pay off all the fines/penalties plus interest for anything you ever screwed up over the past 50 years of life.
Buy condoms when you were thirteen? Nobody wants to hear an explanation, even if you were doing your sister a favor, the evidence to prove that is long gone, only the incriminating parts remain. Round and round it goes. More frivolous laws would probably be passed just to ensure that anyone out there has sufficient dirt to prevent them from winning office and ensuring that the incumbents can remain forever.
It's not nearly so far fetched as it sounds.
Remember, just because you're paranoid doesn't mean they're out to get you. Never give information away to corporations, they are not your friends and doing so will only bring you grief.
More than that, there just isn't enough oil to be worth it for the country. Looks like we're going to spend about $300 billion on this mess, and that's pretty conservatively more money than the total worth of all the Iraqi oil, so oil as a motive for the american people doesn't make sense, there just isn't enough.
However, there is enough to enrich Bush's cronies (halliburton), and they get rich from war Profiteering, they don't even need the oil, though I'm sure they'll try to take it anyway. It's a huge net loss for the american people (even without considering other costs), but Bush's cronies can siphon off a few percent of that loss, and that's billions of dollars, enough to be very rewarding for them.
Don't think that americans want oil, it's not worth it. That's what oil barrons want though, and that's what we get for (almost) electing one, and then lettnig the judiciary appoint him without flat out lynching Scalia, Thomas and Renquist.
As horrible as it sounds, a good old fashiones lynch mob would have been much better for our country, and everyone else's as well.
It's not just an international thing. I'm american, but don't blame me, I voted with the majority. The fact is, Bush wasn't elected, he was appointed by an extremely corrupt judiciary. The mess in florida was only a small part of a larger problem. They had disqualified about 100,000 people for being felons, and only a few percent of them were felons, but they were almost all black, and therefore Democrats. Then bush wins by a hundred votes or so....
Fortunately, that kind of nastiness won't help unless the election is actually close, and I smell a landslide coming in November. Even with the help of diebold, if they defraud the election (not even an if, it's going to happen) and the exit polls say bush got killed whereas the electronic tallies say he won, it'll be impossible to deny, and there will be hell to pay.
None of this would be possible if we had a judiciary who was anything but Republican shills, and this is partly the Democrat's fault as well. For many years the democrats basically refused to play dirty and refuse Judicial appointments due to ideology, and so the republicans filled up the courts with the nasties most conservative judges you ever saw. Then when Clinton came to the white house, the republicans tried their hardest to block everyone he tried to push through. Only recently have the Dems started blocking Bush's judicial nominees, and that's only because many of them were pretty much full out Nazis.
Anyway, if (when) the Dems get the whitehouse back they really need to pull aside the curtain and have a real spring cleaning. There has been so much corruption in the last four years that I bet a suitably determined DA could send pretty much the whole republican party (and quite a few Dems, I'm sure) to prison.
Here's a brief rundown of some of the current scandals in flight....
1) Haliburton cheating teh taxpayers after paying Cheney 30 Million on the eve of his election.
2) WMD in iraq?
3) Blowing the cover of a CIA agent because her husband called them on their BS.
4) Trying to silence Howard Stern after he came out against Bush. They got him (and 8 other Clear Channel DJs fired) while at the same time Michael Powell (Colin's idiot brother) pushes back the consolidation rules....
5) Diebold promissed to deliver Ohio to Bush, while simultaniously doing their best to provide extremely insecure voting machines.
6) Scalia getting all chummy with Cheney while a case against Cheney is being heard in his court.
7) Bush proposes his corporate welfare drug plan, lowballs the cost, and threatens to fire the Medicare Actuary if he tells Congress how much it would really cost. He tells them (a few days ago) months after it's too late to do any good, people are not happy.
8) Worst debt in history, entirely due to his tax cuts for the rich. The economy isn't THAT bad that we would have had a 25% shortfall in tax revenue.
9) Worst economy in 5 decades, due to his horrible mishandling of everything.
10) Bribery on the very floor of the senate when a republican holdout's son was threatened if he didn't vote with the republicans. They offered him $100,000 on the spot (on the floor) for his vote, and promised to defeat his son if he didn't vote for it.
11) Senate republicans stealing files from the democrats. This sort of thing is a really severe crime, but the senate refuses to even look into it, because the republicans won't let them. This is the same sort of thing as Watergate, but the media is so in the pocked of Bush that the flat out refuse to cover it.
12) Media refuses to cover pretty much anything that is anti bush, while simultaniously he offers to reduce restrictions on them and offers up corporate welfare and tax cuts. What a coincidence.
And there are many, many more that I'm forgetting.
Maybe we should come up with a comprehensive list, sortof the 101 worst scandals of the Bush administration.
Fine, since the JVM is compiled for a P-II, compile the test apps for a P-II as well. Linux users aside (and many of them get binaries anyway) the vast majority of the world's software is distributed in binary form, and virtually all of that is compiled for the lowest common denominator of hardware, Sun's JVM probably is an example of this, which is why it is unfair to test it against a source ball that you compiled yourself targeting your own platform.
In any case, the trend seems reasonably well defined. Apps that are not distributed as source will face ever growing performance hurdles as it hurts more and more to be compiled for the lowest common denominator as CPUs become more complex. This seems inescapable. Furthermore, the performance cost of using a VM based language will diminish as VMs become more advanced, and the time required to compile code diminishes relative to the time required to execute it.
Basically, it seems that the performance of VMs will increase relative to the performance of statically compiled apps for the forseeable future. They have already made up much of the difference.
In the not too distant future it's not hard to believe that the two lines will cross. If Sun and IBM and Apple put serious work into java, those lines could mostly intersect within a couple of years.
People do use it for high load apps, like Tomcat, though granted many people use Tomcat behind apache.
The performance difference isn't nearly what you think it is. A program doesn't have to be written in java to be slow, Mozilla and OpenOffice should be decent examples of this.
I completely agree. The port binding should still be specific, but not root. For instance, every unix system should have a "network" user that is the only one that can bind to ports less than 1024, root cannot, nor can anyone else. That nicely sandboxes all the attack vectors into one user that can be easily controlled and chrooted.
But of course none of this would be necessary if everything possible was written in java. Then you wouldn't really have to worry because worst case scenario, you get an exception...
In addition, I'm going to go off on a tangent here about java performance testing. Basically whenever people compare performance they compile up a C version using the latest compiler, targeting their CPU specifically, and they compile up a java version and run them head to head. This is about the most unfair comparison you can make. In general, software is almost always older than hardware, and it's virtually never targeted for the CPU you're actually running it on. Try compiling the C source on a three year old compiler targeting a pentium II, then run the benchmark on the P4 and lets see how it turns out. That is the common case after all. One of java's largest advantages is that it knows everything about your hardware, so theoretically it should always be fairly well optimized for it. The comparative performance would be much closer (it's usually pretty close anyway) if things were tested in this real world scenario.
Slashdot Mirror
Something I think I'll point out. If you want a little toy database, consider HSQL. It's about as good of a database as MySQL (give or take), but it's written in Java (runs on anything), is about 300k or so in size, takes all of ten seconds to set up, and is actually much more SQL compliant than MySQL.
If a tiny easy to use database is all that you need, HSQL is for you. The one real gotcha though is that it can't handle datasets larger than 1/2 a GB. That's way too small for real database servers, but more than enough for most websites, even many commercial ones, I imagine.
In addition, HSQL can run within your java apps, which is really nice. I usually go for a dual pronged approach. use HSQL to handle all the file BS that you app might need (various config parameters, a small data cache that can be sifted efficiently in lots of different ways, other nastiness) and as (small) test databases to try a new idea.
For real DB work though, trade up to Postgres, and be sure to get 7.4, the 7.3.x line has a lot of crippling bugs.
The one real gripe I have about Postgres, is god, these people are in love with Hash joins. Any really good database should avoid hash joins like the plague unless it can guarantee that all the data that could possibly be returned by a subquery will fit into RAM. Postgres often wildly mis-estimates the size of a sub query, decides to hash it, and then gets killed when the query returns 100,000 rows, rather than 100.
A real database using a hash join when it doesn't know that it can take the whole table into RAM (if needed) is just begging to get run over. This is one of the few things that can really knock out an otherwise good database, and really should be considered more carefully. Hashjoins are for small reference data tables (few thousand rows), and should not be used unless you're guaranteed to be surprised.
HSQL of course doesn't have this problem, because it doesn't mess around with these "big" tables that are all the rage nowadays.
Answer is simple. Corporations are not people. The rights of people should always trump the rights of corporations, end of story. Unfortunately, with the republicans in office, the exact opposite is true. For instance, think about all the router manufacturers (and others) who are illegally distributing GPLed software. Under the current (anti music sharing) laws, that comes to 1/4 million dollars and 5 years in prison per offense, multiply that by a million or so, and we're talking a trillion dollars give or take, and at least 50 years per employee.....
Now, why have none of these cases ever gone to court? Oh, that's right, because corporations aren't subject to the laws of the land like mere pople are. Sorry, my bad.....
Downloading is not illegal unless they can prove that you don't have a license for the music, and you aren't going to use it in ways consistent with fair use. If I have a truck load of CDs and I decide to download MP3s of them rather than ripping them myself, that's perfectly legal.
The problem for the RIAA is that proving that a downloader doesn't have a valid license is essentially impossible, so they can't really bust you for downloading.
While this soudns like a good idea, it probably isn't. If you don't calibrate your functions correctly you can easily have blue-sky disasters. I know it sounds like I'm making these words up, but i'm not.
A blue sky disaster is where one variable explodes to infinity at a specified point in time. This is easily caused by many classes of functions where they start to feedbackon each other. In fact, keeping stability when the median income is affected by the minimum wage, which is affected by the median income, etc... is a really hard problem. Most of chaos math is based on trying to figure out when systems like this will explode. Most of them have a way of slowly working their way into a regime where they catastrophically fail.
Very similar to a ship being rocked by waves or a skyscraper pushed by wind. You have to be very careful that there are no resonances, or you have to stay very far away from the "edge" of your safe zone to avoid being pushed over or capsized.
mod this guy down. This has got to be the stupidest comment I've ever seen. If you have nothing better to do than hack parking meters, then go ahead. In addition, I'd love to hear exactly how you plan to get actual access to the thing, and what you intend to accomplish.
I imagine the thing has at least tolerably strong wireless encryption (shoot the designer if it doesn't), and nothing to offer your average hacker, case closed.
Let us not forget that the US is the third largest country in the world, both in terms of land mass and in terms of population.
In population we're behind...
1) China
2) India.
In land mass we're behind....
1) Russia
2) Canada
Oh, and of course economically we're number 1 by a huge margin (though growing smaller under the republican leadership). Larger than at least numbers 2 and 3 combined, and probably a fair bit more besides.
So let's not go all european and claim that the US is some middle sized western country.
Lets be accurate here.... It's impossible for an object with INTRINSIC mass to reach the speed of light. A baseball has intrinsic mass when it's sitting still. When it's moving it has its intrinsic mass plus its mass due to velocity. A photon has no intrinsic mass and therefore it can never travel at any speed but the speed of light (little more convoluted here, but I won't bother to explain). Light can travel slower than the speed of light through media only because it is being canceled and regenerated by the electrons in the medium.
As for the faster than light stuff, well I never really studied that, so I won't comment, but the parent is at least mostly correct about that. In particular, the real problems only come about when information travels faster than the speed of light, because that violates causality.
Now, I'd like to also point out that there is no real reason why we can't violate causality, causality is in fact highly overrated. People always tell the metaphorical story about someone going back in time to kill his father, but they never really think about it. Quantum uncertainty indicates that each time you go back the result will be a little bit different, so there is no such thing as an infinite loop (it must break 'eventually' because quantum uncertainty will cause you to burst into flame or get hit by a bus or whatever). So, go back, kill your father, don't exist, don't go back (because you don't exist), nobody kills your father, so you exist, so you go back......get hit by a bus, and there we have it, the time line is correct again.
IAAP (I am a physicist)
Actually, I was thinking about exactly that problem..... though I am perhaps a bit of a crackpot.
Here's what I figure. A device driver is really two parts. one part actually reads from and writes to the device, the other part is the actual code. The reading and writing part could be handled by allowing some sort of low level VM call (assuming the VM is somehow embedded in the OS, so you can have this sort of access, it would also have to run in system mode). Basically some sort of native code takes care of the bindings and then loads up your driver with some sort of context object that contains (perhaps) a bunch of byte[] objects that represent the memory the device driver will use to communicate with you. These arrays are pinned in ram, so they always exist at the right location.
Then you write your driver, use the byte[]s to communicate, are guaranteed that your memory addresses are always correct (if they started out correct) and all your code is safe. In addition, it would be nice if when you driver threw an exception (should never happen, but who knows) the System should just re-initialize the driver and reset the hardware (works better on video cards than harddrives, but I'm not a hardware hacker, so cut me some slack) and continue.
Basically, what I'm saying is that an OS should include a VM in system mode, and then throw everything possible into the VM to get security and protection. Even most of the device drivers could go into the VM (using a technique somewhat like that above) and leave only the basics of scheduling/memory management in the kernel. Less kernel code means fewer crashes (less code in system mode that can take down the system, especially the drivers), and Java programs could run in system mode (substantial performance increase) while native apps could run normally.
Planning to optimize for the platforms that don't exist yet? Some of us want our code to run (and run well) in a year, not just today. And no, moore's law isn't enough. It's expected that code from yesterday should run faster today, not the same speed, when used on better hardware.
So, compare the performance of a 5 year old binary vs. a 5 year old java program on your spiffy new computer, and tell me which one fares better. Use a modern JVM mind you, and you'll get advanced modern code from the old java file, but crappy code written for an old 386 from the old program.
Now lest you say that old programs don't need performance, allow me to point you to CLAPACK (written in C no less) and note the fact that it needs performance more than anything, but it's a pain in the A## because you need to be willing and able to recompile it in order to get anything out of it. It also has all the old crappy manual inlining and all that BS. I'm not advocating writing it in java (though I tried parts, it wasn't that bad, but I never got a good comparison) but at least if you did you wouldn't be carrying around decades old BS in a system that critically needs to be very fast.
I imagine that a java version (even with all the old cruft) would be de-crufted at runtime to the point where it would outrun the 5 year old binary version that is probably embedded in dozens of programs out there. You might even be able to read it without going insane, as well.
Guys, it's time to face the facts. C is a relic from a time when compilers were stupid. Declare all your variables before executing code, declare all your functions before using them, include headers that almost invariably break one another, hurrah.
I'm so glad that every time I write C I get to write each function signature several times, that's lovely. In addition, C takes much more time to compoile than Java/C# because all the stupid headers take forever to parse.
Now on to preprocessor macros. They are useful in statically compiled languages, but in dynamic (VM based) languages they are less than useless. The VM will take any code that it can and inline it, propagate constants, etc.... Macros are not needed.
Thirdly, pointers and "suggested" types. I say suggested because the type system isn't enforced, why bother with types at all if they don't mean anything. Pointers are a problem because they allow unsafe code that forces the hardware to make up for lack of security in the software. Repeat after me, security is a software problem. Memory protection is also a software problem. The modern computer throws away about 30% of its performance on various protection schemes. More than enough to make up for using a language like Java or C#.
So, in conclusion, C compatibility is a bug, not a feature.
True, I was partially keeping to cases where it could (and someday, presumably, will) be faster. Anyway, I'm not claiming that you can turn off garbage collection. I'm claiming that people can often write better algorithms when they don't have to manually manage memory than they can when they have to track down every pointer that might become unreachable and delete it.
I just don't like the assertion that much of slashdot makes that VM languages will always be slower. In the long run the reverse should be true. The first cars were slower than horses, but it was only fools who believed that would long be the case. Slashdot seems full of such fools.
several things....
1) Programmer time goes for about $50/hr. That means that a prrogrammer spending 20+ extra hours could have pretty easily bought you an extra dual CPU computer to run the thing on. That's only 2/3 days of work. Java can easily shave off much more than that.
2) Java isn't that slow. Depends on what you're doing and how you're doing it, but it's not crazy to get java to be less than 50% slower than C. It's also not really uncommon for it to be faster. When it is faster it's almost always because better algorithms are used, but that isn't an accident. It's much easier to write good algorithms with a garbage collector sometimes, as you don't have to track down and delete all the stuff you unlinked.
3) The one weakness of java (until VM sharing becomes available) is memory usage, but memory is really cheap now, same basic logic as CPU time, but even more so.
4) Lots of additional optimizations are possible in VM based languages that aren't tried by any modern VM. When they start to come online, expect the performance of the VMs to surpass compiled code. Here are some examples....
a) Escape analysis: all stack frame scoped data goes on the stack. Basically it makes optimal use of the stack, can't really be improved any. This is why C#'s "value" types are so stupid, they shouldn't be able to help (and would probably hurt) a good VM. Anything larger than a pointer should be a reference, the VM can put it on the stack if it's possible to do so.
b) Method virtualization: a good VM should strip down pretty much all of the V-tables and just regenerate what it actually uses. This is why the "virtual" keyword in C# is so stupid, it should have no effect on performance assuming a smart VM. Can also do all sorts of inlining that a normal compiler can't do (someone could link to your library, you can't inline away public functions).
c) "incorrect" optimizations: The VM can create optimal code that is not actually a valid representation of the given code for all inputs. Can then revert the code if an input is given for which it is not valid.
d) Profiling: a VM can (and modern ones do) profile the code and optimize the common cases at the expense of the uncommon ones.
e) Hardware knowledge: a VM can always produce code that is optimal for exactly your hardware, right down to cache sizes, processor model, and memory latency.
Just though I'd throw these things in. Those who expect VM based languages to always be slower will probably be in for a shock in the future. Remember, the cost of compilation is basically constant whereas the payoff from optimizations is linear in CPU speed. At one point the optimizations will exceed the cost of compilation. It's only a matter of time.
To make it simple it doesn't have to be flat. A classic example is a hyperbolic tax code. The function approaches an asymptotic limit (say 50%, if you want to do something similar to our current code), then what you pay is still very simple. Just plug it into a simple formula, Y = f(X) where X is your income and Y is your taxes. Simple.
The real thing that would help is a couple simple things.
1) Tax code based on continuous function. (not steps and other BS).
2) When you claim the value of something for property taxes the government can either accept your taxes, or buy the thing from you for the price you specified. Voila, no more property tax cheats.
3) Get rid of most of the subsidies. These are mostly corporate welfare. Conservatives always complain about welfare for poor people and arcane tax codes, but the corporate welfare rules are more bizarre, and cost far more than the welfare that puts food on the table of the poor.
4) The country should have one class of capital offenses. White collar crime and nothing else. The threat of the chair won't deter crimes of passion, insanity, or hopelessness (most crimes, murders, rapes, etc....) but it sure as hell will deter Embezzlement, bribery, and all manner of Enron/Halliburton style nastiness. White collar criminals are precisely the people who weigh the payoffs vs. the consequences and take whichever action is best on average. Tougher consequences will stop most of them.
This is the problem with Linux, unix, windows, and pretty much every other OS out there. Configuration is hard. Fedora Core 1 takes a fair amount of that difficulty out (as do other Linux distros), but seriously, they need to try hard to get to be more like OS X.
Here are some pointers......
1) XML. If it's going to be a config file, make it XML. The speed issue doesn't matter for config files, and the fact that it's self validating (xsd, dtd, whatever) helps immensely. It's not hard to write a simple program that can understand XML config files using basic XML toolkits, and people might even be able to understand them too. Better than files full of order sensitive key value pairs, yuck.
2) The second thing to do is to make GUIs. This is very important. Most necessary configuration should be available from the gui. I don't care about properly setting up anything, I just want to set my IP address (one of the things available in a GUI under modern linux) sort of thing.
3) God I wish people would store system wide settings in an actual database. It's nice that pretty much everything is stored in some sort of bastardized hashtable (registries, etc....), but seriously, there is a standard for databases, it's called SQL. A only moderately sucky SQL server is about 250K (Hsql), peanuts compared to a modern OS, and if you used it then you could garantee all sorts of integrity constraints on your data, and it would also be transactional, eliminating most of the nastiness of systemwide configuration (lots of reboots, etc.....). Another advantage might be that it would be great at helping you to truly know what's on your computer. The SELECT * FROM mappings m where NOT m.program IN (knownPrograms) sort of thing that can easily kill off spyware, etc.....
don't be a fool. It's clear to pretty much everybody that somethign you get for free doesn't have the same standards as something you have to pay for. If you badger me into building you a dog house, and it falls down and kills your dog, too bad. If you pay a contractor to build you a dog house, then you might have some recourse, as you bought a dog house, not a death trap, whereas we (if I built it for free) never really had any sort of agreeement, as there is no payment or contract to indicate that I even know you.
It seems like this could so easily be a non issue, and probably already is under current law.
I imagine this is covered by Clinton's good samaritan laws already. If you're trying to help by giving CPR, or giving someone free software that you believe will work, then you can't be held responsible for the consequences.
-Tyler
probably less than that. The stuff will be so diluted I'd be amazed if you could event detect the difference. Plunging reactor cores into the atmosphere isn't something you want to make a habit of doing every day, but doing it occasionally (200 years after the reactor has last run, to let the radioactivity die down) won't hurt anybody. This will certainly dose us with less radiation than your average solar storm, much less.
Move along folks, nothing to see here.
Ah, but this isn't a market. It's a deregulated monopoly, which always (ALWAYS) drives up prices. Unless people are willing to pay for ten cable lines to each home so you can pick your favorite one, there will never be a market in cable/phone/power/water/sewage/dsl/etc... end of story.
Deregulating them will result in the consumer getting fleeced at a tremendous rate.
I could go all political and indicate who would gain the most by said fleecing (cough* republicans, cough*) but I won't. Deregulation of natural monopolies is one of the stupidest ideas ever, right up there with Supply side economics.
People need to start to demand that their government policies at least pass the sniff test. If you can't see any way that it could be plausible, then for god's sake, try to stop it.
Classic case, Supply side economics, goes like this....
1) Give money to rich people.
2) ???? (maybe they spend it on bigger houses, or ship it to their swiss bank accounts, who knows what happens here).
3) More stuff is bought (we have just paid rich people to buy bigger limosines, essentially, the taxpayers have bought luxury items for the wealthy)
4) Everyone* is happier.
* Everyone may not include you if your annual income is less thatn 600,000 per year or if you are adverse to white collar crime. Results may vary.
Perhaps I'll propose "Tyler Side Economics" next. Just give your money to me. I'll spend some on strippers and booze, and stash the rest in switzerland, and as a result, who knows, maybe people will be happier and wealthier, why not, I'm sure I will.
Wake up people.
Or how about we write in a language that has security built in and leave software security as a software problem, rather than making hardware even more byzantine, power hungry, expensive, and unstable. But then again, maybe I'm crazy.
That is partially true.
After all, not all operating systems will let just any random program randomly rewrite sectors of the harddrive with random data.
Unless the firewall was running as root that is, which I suppose in windows it would be, and maybe on Unix too, but then again, Unix tends to have good firewalls built in.
Basically, it wasn't relying on anything specific to windows, but then again, it's unclear that a firewall running on anything but windows would have been vulnerable in the same way....
and I also might add, why don't people program in Java, this sort of thing won't happen. This worm (like pretty much every other worm) takes advantage of one huge security flaw. The flaw is that programmers use an OS programming language to make general purpose apps. That is often the core of the problem.
This seems a strange assertion to me. I just got done using HSQL (google it, sourceforge page comes right up) for some DB work at work where I didn't want to screw around with installing a full fledged DB on my workstation but still wanted to query tables.
It's fully opensourced, written in java, a 250K jar file that can be dropped into pretty much any application to run embedded, as a server, memory only, whatever, and it work's quite well.
It loaded up about a GB of data into six databases, sifted and linked everything up correctly and then saved out the 18 MB (compressed) result in about an hour, not bad for juggling about 4 million rows and sending each one through a couple of transforms. This was on a pretty normal workstation 2.4 Ghz, 1 GB ram. I'm sure postgres could have done it in half the time (faster anyway) but that would have required installation, whereas HSQL requires you to add a jar to your class path and then pretend you're connecting (JDBC) to a server, which really (in this case) exists within your own application.
I'm not sure why OOO doesn't just embed HSQL and call it good. It's not a real DB (like postgres, oracle, etc.....) but it's probably on par with the fakers (mysql, access, etc.....). Oh, and apparently it can be used with OOO as a database backend, but they don't include it as the default, and I don't really know why.
This brings me to another point. The number of projects out there that think they need to spend precious effort manhandling text files is absolutely amazing. Two things to consider before you even consider writing a flat file....
1) XML, it's slow, but at least people might be able to understand your data, and you get all the format checking, etc... for free in pretty much any decent language (Java, C#, who knows, maybe even C).
2) HSQL, only an option if you use Java, but if you do, then just have HSQL load up all your prefs as a database, etc... It makes life much easier to know that your program has a DB embedded in it (only takes a couple megs of ram, and adds 250K to the download size) so you can save preferences and other data in a simple and consistent manner without juggling endless folders full of flat files (or XML). The classic example of where this needs to be done is in your average Java email server. There is no point in having a file storage mechanism. Force all storage to be JDBC, and then if you don't have a DB, it'll use HSQL embedded, or connect to the DB of your choice. Voila, 1/4 of the codebase is no longer needed, less stuff to configure, less stuff to break, everyone is happy.
Here's why. I'll take a small example.... Howard Stern. A while ago he came out against bush (he had formerly been a bush supporter) and two days later he was fired, for no apparent reason. It turns out that at least 8 other DJs have also been fired from Clearchannel for saying anything anti-bush, and most of them didn't have the star power to make it through, like Stern did.
Now, imagine a future where everything you ever bought (right down to the tolls on roads, medical records, and pretty much everything else) is in large databases held by companies like Clearchannel, who are clearly partisan (witness the firings) probably because they want more tax cuts. It's not hard to imagine that all of these databases will be neatly collected, and sifted for dirt on any opposition canidates that should come along.
Now, this won't prevent you from running for office, provided you're willing to pay off all the fines/penalties plus interest for anything you ever screwed up over the past 50 years of life.
Buy condoms when you were thirteen? Nobody wants to hear an explanation, even if you were doing your sister a favor, the evidence to prove that is long gone, only the incriminating parts remain. Round and round it goes. More frivolous laws would probably be passed just to ensure that anyone out there has sufficient dirt to prevent them from winning office and ensuring that the incumbents can remain forever.
It's not nearly so far fetched as it sounds.
Remember, just because you're paranoid doesn't mean they're out to get you. Never give information away to corporations, they are not your friends and doing so will only bring you grief.
More than that, there just isn't enough oil to be worth it for the country. Looks like we're going to spend about $300 billion on this mess, and that's pretty conservatively more money than the total worth of all the Iraqi oil, so oil as a motive for the american people doesn't make sense, there just isn't enough.
However, there is enough to enrich Bush's cronies (halliburton), and they get rich from war Profiteering, they don't even need the oil, though I'm sure they'll try to take it anyway. It's a huge net loss for the american people (even without considering other costs), but Bush's cronies can siphon off a few percent of that loss, and that's billions of dollars, enough to be very rewarding for them.
Don't think that americans want oil, it's not worth it. That's what oil barrons want though, and that's what we get for (almost) electing one, and then lettnig the judiciary appoint him without flat out lynching Scalia, Thomas and Renquist.
As horrible as it sounds, a good old fashiones lynch mob would have been much better for our country, and everyone else's as well.
It's not just an international thing. I'm american, but don't blame me, I voted with the majority. The fact is, Bush wasn't elected, he was appointed by an extremely corrupt judiciary. The mess in florida was only a small part of a larger problem. They had disqualified about 100,000 people for being felons, and only a few percent of them were felons, but they were almost all black, and therefore Democrats. Then bush wins by a hundred votes or so....
Fortunately, that kind of nastiness won't help unless the election is actually close, and I smell a landslide coming in November. Even with the help of diebold, if they defraud the election (not even an if, it's going to happen) and the exit polls say bush got killed whereas the electronic tallies say he won, it'll be impossible to deny, and there will be hell to pay.
None of this would be possible if we had a judiciary who was anything but Republican shills, and this is partly the Democrat's fault as well. For many years the democrats basically refused to play dirty and refuse Judicial appointments due to ideology, and so the republicans filled up the courts with the nasties most conservative judges you ever saw. Then when Clinton came to the white house, the republicans tried their hardest to block everyone he tried to push through. Only recently have the Dems started blocking Bush's judicial nominees, and that's only because many of them were pretty much full out Nazis.
Anyway, if (when) the Dems get the whitehouse back they really need to pull aside the curtain and have a real spring cleaning. There has been so much corruption in the last four years that I bet a suitably determined DA could send pretty much the whole republican party (and quite a few Dems, I'm sure) to prison.
Here's a brief rundown of some of the current scandals in flight....
1) Haliburton cheating teh taxpayers after paying Cheney 30 Million on the eve of his election.
2) WMD in iraq?
3) Blowing the cover of a CIA agent because her husband called them on their BS.
4) Trying to silence Howard Stern after he came out against Bush. They got him (and 8 other Clear Channel DJs fired) while at the same time Michael Powell (Colin's idiot brother) pushes back the consolidation rules....
5) Diebold promissed to deliver Ohio to Bush, while simultaniously doing their best to provide extremely insecure voting machines.
6) Scalia getting all chummy with Cheney while a case against Cheney is being heard in his court.
7) Bush proposes his corporate welfare drug plan, lowballs the cost, and threatens to fire the Medicare Actuary if he tells Congress how much it would really cost. He tells them (a few days ago) months after it's too late to do any good, people are not happy.
8) Worst debt in history, entirely due to his tax cuts for the rich. The economy isn't THAT bad that we would have had a 25% shortfall in tax revenue.
9) Worst economy in 5 decades, due to his horrible mishandling of everything.
10) Bribery on the very floor of the senate when a republican holdout's son was threatened if he didn't vote with the republicans. They offered him $100,000 on the spot (on the floor) for his vote, and promised to defeat his son if he didn't vote for it.
11) Senate republicans stealing files from the democrats. This sort of thing is a really severe crime, but the senate refuses to even look into it, because the republicans won't let them. This is the same sort of thing as Watergate, but the media is so in the pocked of Bush that the flat out refuse to cover it.
12) Media refuses to cover pretty much anything that is anti bush, while simultaniously he offers to reduce restrictions on them and offers up corporate welfare and tax cuts. What a coincidence.
And there are many, many more that I'm forgetting.
Maybe we should come up with a comprehensive list, sortof the 101 worst scandals of the Bush administration.
Fine, since the JVM is compiled for a P-II, compile the test apps for a P-II as well. Linux users aside (and many of them get binaries anyway) the vast majority of the world's software is distributed in binary form, and virtually all of that is compiled for the lowest common denominator of hardware, Sun's JVM probably is an example of this, which is why it is unfair to test it against a source ball that you compiled yourself targeting your own platform.
In any case, the trend seems reasonably well defined. Apps that are not distributed as source will face ever growing performance hurdles as it hurts more and more to be compiled for the lowest common denominator as CPUs become more complex. This seems inescapable. Furthermore, the performance cost of using a VM based language will diminish as VMs become more advanced, and the time required to compile code diminishes relative to the time required to execute it.
Basically, it seems that the performance of VMs will increase relative to the performance of statically compiled apps for the forseeable future. They have already made up much of the difference.
In the not too distant future it's not hard to believe that the two lines will cross. If Sun and IBM and Apple put serious work into java, those lines could mostly intersect within a couple of years.
People do use it for high load apps, like Tomcat, though granted many people use Tomcat behind apache.
The performance difference isn't nearly what you think it is. A program doesn't have to be written in java to be slow, Mozilla and OpenOffice should be decent examples of this.
I completely agree. The port binding should still be specific, but not root. For instance, every unix system should have a "network" user that is the only one that can bind to ports less than 1024, root cannot, nor can anyone else. That nicely sandboxes all the attack vectors into one user that can be easily controlled and chrooted.
But of course none of this would be necessary if everything possible was written in java. Then you wouldn't really have to worry because worst case scenario, you get an exception...
In addition, I'm going to go off on a tangent here about java performance testing. Basically whenever people compare performance they compile up a C version using the latest compiler, targeting their CPU specifically, and they compile up a java version and run them head to head. This is about the most unfair comparison you can make. In general, software is almost always older than hardware, and it's virtually never targeted for the CPU you're actually running it on. Try compiling the C source on a three year old compiler targeting a pentium II, then run the benchmark on the P4 and lets see how it turns out. That is the common case after all. One of java's largest advantages is that it knows everything about your hardware, so theoretically it should always be fairly well optimized for it. The comparative performance would be much closer (it's usually pretty close anyway) if things were tested in this real world scenario.