How likely is that? Someone will invent a drug to make you immune to incapacitating drugs, and we'll go back to bullets and explosions.
It'll be like Syndicate where some guy at a computer jacks up your squad's adrenaline levels and compels you to run around in leather trenchcoats killing people and blowing up vehicles, not even feeling the machine gun fire and flamethrower blasts the rival squads are hitting you with. And a cyberpunk background track pounds in your head to set the mood.
So the comments defending the 1k do-nothing app as somehow moral get modded up and the posts pointing out the immorality of it aren't. Is this a fluke of moderation or are slashdot readers really so warped?
If the climate change is actually a natural process then the attempt to control it has become our first great terraforming project. How convenient that we're trying this on the only planet we have and not some spare planet that wouldn't matter if it went awry.
And if the rapid climate change is not a natural process then we have already not just attempted but are in the middle of an effective terraforming project where the only definition of 'success' must be some form of 'not at all like what we had before'. That sounds much worse to me than your what-if.
The environmental people are either saying:
1) our climate is changing, lets make it like it's always been before
-or-
2) we've changed our climate to something different and unknown, lets change it back again.
Either way sound better to me that living in a completely unknown new climate. If our previous climate was good enough for Jesus, it's good enough for us.
Singularity is more like ".NET" taken to the next level, with the entire OS running without hardware memory protection (let alone hypervisors), so it can run anywhere... even as a module inside another application... without any specific hardware support.
Unfortunately it's really more like.NET taken to a previous level. With no JIT and no dynamic class loading, it's losing a lot. JavaOS is a better example of a typesafe kernel. Even though it didn't catch on, it was a production OS that had the features of Singularity and more before Microsoft "innovated" them.
I'm just suggesting that it looks like a lack of consistency between the use of the open brace and the close brace.
It is an inconsistency. Often something that is most practical or efficient is somewhat inconsistent.
I'm also saying that if that one small line is so important, then that other basically wasted line should be a consideration for those people as well, unless there is a good reason for it to have its own line (see below).
And I've seen code where ~20% of the lines are open braces. That's hardly "one small line". Again, "one small line" is dismissive and is a bogus argument.
For purposes of this discussion, say there are two styles: A and B. Some prefer A, some prefer B. I use A, you use B. I will continue to use A for whatever reasons I choose, but if you choose to use B, here is a suggestion on how you might optimize your use of style B, using the very reasoning that leads you to use B in the first place.
Hardly. More like, if people prefer B they are "only half right" and should be using style C instead. And C is a defective style since it (obviously) impedes editing. Therefor A is a better style than B.
I was always under the impression that whatever the coder groks best is the most efficient style. People think differently and thus prefer different code styles.
K&R style has more pro- points in its favor and fewer con-s than any of BSD, MS, or GNU styles. If you 'grok' a style better that is objectively less efficient and that makes you more efficient then so be it. To each his own.
But don't make up bogus arguments to justify that.
I prefer vertically aligning open and close braces, too. I was just making a point that the people who do the same-line open brace and use the vertical-space argument are only getting it half right. If the one line from the open brace is that important, they should also be doing something about the wasted line from the close brace.
But you must know that your argument is retarded, right? You are saying that if something is good then twice as much is better. Let alone that being a false argument, but the opening brace and the closing brace aren't even equivalent in the first place.
Putting the opening brace on the same line has few if any drawbacks, but putting the closing brace on the last line has drawbacks, such as the inability to add a later statement without moving the brace between lines, adding a properly scoped// NOT REACHED comment, or other things people do.
The fact that you would propose such a ridiculous argument tells me that you know that opening braces on their own line is at best a style choice with drawbacks, and that you are defensive about it and need to rationalize it. In other words, you know K&R is a more efficient style yet you would rather tear it down with false arguments than adopt it... what does that say about you as a programmer?
Well since bugs before the epoch were actual insects, judging by past precedent they'll get super powers... like wall-climbing ability or maybe spidey senses ??
The optimization was not "premature". We actually do need the speed and space.
And I'm sure decoding varints is really fast right (a branch on every byte, some shifts and xors)? And 25% of the available wire type codes being 'deprecated' is really space efficient? Or using ten bytes for any negative number unless the coder specifically declares an optimization?
It may very well be that most users don't need the speed, but switching formats down the road is pretty hard. It's not exactly like optimizing implementation details -- this is the format you use to communicate with other entities that you may or may not control.
What I like about protocol buffers is that the fields are identified by number. This makes it possible for different components to use different names to represent the same data format (for example for fixing spelling errors). But I think in most cases, in a general sense (I'm not talking google specifically), the downside of not being to make any sense out of the data without a.proto description outweights this.
And a data format like protocol buffers is essentially a custom compression algorithm, like for instance x86 instructions are. Unfortunately, it is really hard to make a custom compression that holds up over time. For instance, the two deprecated wire types could be used to optimize the first 32 fields rather than only the first 16 but instead they are just wasted.
I'm not trying to knock protocol buffers. It's a decidedly good effort. But the hackery involved in making it that slight bit faster and smaller probably isn't going to be worth while in the long run.
Note that protocol buffers give you the equivalent of a DOM -- an object representing the parsed message.
Actually no, they don't. If the parser has a different.proto file then it knows nothing about extra fields in the message, since the.proto info is not sent with the message (if it were, there would be no space savings over binary JSON for instance). This is not the equivalent of a DOM or a JSON object.
Though I think protocol buffers would still win just because there is less to parse and parsing length-delimited chunks is faster than character-delimited.
In most cases, trivially faster. The difference between 5aword and aword\0 mostly depends on how memory is allocated and how strings are referenced. For instance, in C in some cases the character-delimited string could be used in-place (with no copy or memory alloc) whereas the length-delimited one cannot (without first reimplementing all the string functions).
.. or did you not mean NULL when you said character-deliminated ??
The big difference is that a protocol buffer cannot be understood without the message format (.proto file). Now lets actually take a look at a real list, like say the developers for apache (as a list of {name:,email:} objects):
protobuf: ~1654 bytes
json: 1915 bytes
protobuf.lzop: ~744 bytes
json.lzop: 809 bytes
What you see is precious little difference in the size of the data even though the json is self-describing. The lzop version is essentially identically sized, and compressing and decompressing with lzo is wicked fast. So size is not a reason to use proto buffers.
Maybe speed is? Instead of using lzo compression just create a JSON binary format. This is trivial, and provides essentially the same size and speed benefits as protocol buffers while still being JSON in nature.
The only advantage to protocol buffers then is that they generate access and verify classes for you in you favorite language (if that language is C++, Java, or Python). Big deal, again this is absolutely trivial.
To me what this demonstrates is premature optimization. Instead, first use a simple text format like JSON then if that is too large compress it. Then if that is too slow send it in binary.
Note: I approximated the size of the proto buffers based on the descriptions of the binary format since I haven't downloaded the code (it actually compresses less well since I did not vary the 'length' bytes in my test file).
The problem is, you can only filter out the RST packets on your end of the connection.
That's only a temporary problem. The real problem -- for the ISPs -- is that the same software is running on each end of a p2p, so all of their efforts are guaranteed to fail eventually.
For instance, p2p programs can start using UDP spread spectrum... pass packets on random ports. The receiver then basically implements a quick and dirty tcp-like connection over this (ie much worse for an ISP than actual TCP). Add encryption and random length so it's harder to filter out. Or there can be a shared random number seed for the shared ports. Just for example...
There's probably some computer science or information theory law stating this, but they can't ultimately reduce the targeted traffic by more than the loss from encoding it as 'normal' traffic. For instance, if they limit torrents to 100k/s and the loss is 33% from 'base64' encoding the data as some kind of an html-ish doc then if normal web pages get more than 133k/s then torrents would be faster encoding them as 'normal' traffic.
... then they have to try to figure out what are real web pages/servers and what are really some other protocol pretending.
None of that matters if you get a keylogger on your system.
That's why level 4: Money, Banks is done from a livecd boot (or dual boot that is only used for offline/level 4 stuff).
Dividing the passwords into secure levels is nice because when you change passwords you can just shift them down a level... so there are fewer new passwords to remember -- your old highly secure 15 character password with numbers and punctuation becomes your web forum password (that you have firefox remember for you anyway).
Tell me you are not so desperate for a job that you would spend 25% of your time fixing a coworker's mistakes? Bring it up with your manager, have his faults explained to him, document it over a month or so, and fire him if he doesn't get better.
Because the other 75% of the time I get to code awesome stuff. He's friends with the CEO and went to college with a good portion of the company, so licensing or liability would help -- but your suggestions would not, Mr. Know-It-All.
As a software developer I spend about a quarter of my time rewriting code that one of our other developers writes. His code is like a rhesus monkey came in and started flinging shit all around. He 'keeps up' with the other developers because he does the absolute minimum, never ever rewrites code to fix problems, cuts and pastes, etc. One time he cut and paste a second copy of a 200 line function so he could change one loop constant.
There's lots of developers like him, and they and/or their company should get sued over that code. At least when it is from negligence. Or there should be a licensing requirement.... something so that the people who are irresponsible or incompetent are held responsible for it.
Pretty much the only thing that makes programming not worth while is that people can hack out a 80% working code, get credit for it, then move on and leave all the crap for competent developers to fix. I would gladly pay a malpractice insurance fee if it means less having to deal with bullshit code.
But many here suffer from Bush Derangement Syndrome, or less elegantly, are haters.
BDS? Bush Derangement Syndrome? Really?!
I have a hard time believing any person so uncreative and with such a misunderstanding of what elegance is would have an informed and reasonable opinion on, well, pretty much any matter.
and don't care about a civil liberty so important that the framers listed it above search and seizure and right to counsel, then of course you are not interested in an objective, fair view of the 43rd president.
Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof; or abridging the freedom of speech, or of the press; or the right of the people peaceably to assemble, and to petition the Government for a redress of grievances.
Even if we were to assume the amendments were in order of importance the inescapable conclusion is that the pen is mightier than the sword -- free speech is more important than having a handgun (handgun since the court upheld that you DO NOT have a right to bear Arms in general).
So what has this president been responsible for:
* rounding up and harassing muslims * free speech 'zones' * telecoms spying on every citizen (we assume) * so-called 'national security' letters that you can't talk about to even say that you received one * excluding non-republican from public events * intimidating reporters, threatening to jail them over leaked 'classified' information * and so on...
If we assume a ranking of amendments than these things would concern the FF way more than a 'handgun but no other guns' interpretation. The bible-thumpers that Bush appointed have even taken public stands against most of the 1st amendment. I won't even list all the shredding of the other amendments since you seem to hold the position that the 1st trumps the rest anyway.
The People don't have a 'bush derangement syndrome'. You use that term because a) you are retarded and b) you need some rationalization in order to hold your beliefs. My friend, 'BDS' is entirely about you, and once you admit that you have a problem then you can start to open your mind.
38 years? 10? What's the "correct" number? The "correct" number is one fixing of the system so that people can't "hack" grades by using a keylogger.
Plus branding this guy on his records as a cheater, plus having him apologize to each of this classmates 'or else'. Oh yeah, and take away his right to hold public office lest the Diebolds declare him president despite not being on the ballot -- we've seen what happens with a cheater in the ovaloffice.org and we can't afford it happening again.
You don't want to use svn with a large tree because it stores a second copy of only the revision you checked out (so that diffs are fast). Other systems like hg can typically store the entire repository, giving you access to all revisions, in less space (it's compressed) than svn can store just the working copy.
Furthermore, this second copy is stored in the same folder tree, which is both annoying (from a tools pov, like grep) and slow (OS has to stat a lot more inodes).
But seriously Java isn't the language you would use for high performance but rather high portability. That says a lot about how bad the original code was. Actually Java is a language you would use for a large, high performance system. It isn't a language you would use for extremely high performance though. In fact there really isn't much practical choice besides Java for large high-performance systems at this point.
Seriously what alternatives are there to Java for a large system like this? DotNet/CLR are far slower. C is too cumbersome to manage for large systems unless you have excellent developers and process, like say the kernel. C++ can be faster than Java, but are you seriously going to have developers that make constants called THREE with value 3 program in perhaps the most complex programming language yet created? If developers can't even create decent constants they certainly aren't going to avoid database queries in their copy constructors... since they lack even basic ability their C++ version is going to be ridiculously slow.
This FUBAR software almost certainly was programmed in C++ or worse. For one thing, it would have to be seriously screwed up for a Java build to take a day -- but this happens often with even just large-ish C++ projects.
He continues to insist that Bush and Cheney, somehow by making some "secret deal" have directly manipulated the oil market -- despite the fact that the oil futures markets are among the most competitive and transparent commodities markets in history. Oil is invested in now, driving up the price, because it has real value, like some kind of post-modern gold standard. The connection to the Bush administration is that eight years of complete incompetence and bungling have caused people to no longer invest in other things that had value before, like stocks and bonds, the dollar, and the U.S. in general. Our country under Bush is up shit's creek and pissing dollars into the wind.
That's where the connection to the Bush administration is. A recent survey of historians had 96% putting this administration in the bottom fourth and 66% that this has been the worst administration in history. But it's all just economics? Yeah, and that's why oil is so expensive and why people are now betting against our country being solvent in the next couple decades. Because we've been fucked big time by secret Cheney deal and all the rest of this dumbass president..
Compiling Smalltalk is harder than Lua, because all of the flow control is done via calls to closures (an if statement in Smalltalk is done by sending an ifTrue: message to an expression with a closure as an argument), while Lua has explicit flow control, so I'm not entirely surprised. I agree with most of your post. But above, the slowerness(?) isn't the fact that Smalltalk uses ifTrue and closures for loops, but because these are changeable. If you couldn't change the implementation of ifTrue once defined in a class or especially an instance then it could be fast.
they began by interpreting everything, but if you spent a lot of time executing a part of the code, it will aggressively optimise it. The newer Java VMs do the same thing. Newer as in since 1.2... ten years ago.
I have to disagree with you about Smalltalk. Before it in performance are LISP and on the great benchmark shootout even LuaJIT (!) is faster than VisualWorks smalltalk -- vw is pretty fast for a smalltalk. Smalltalk has been optimized a lot, but it's not really a 'fast' language.
For most JavaScript, this is a complete waste of time. It is very rare for JavaScript to run for more than a fraction of a second at a time and so latency caused by interrupting execution much worse than just running it slightly more slowly. The ActionScript VM in Flash is very different, since it is designed to run scripts that stay running for minutes at a time and are fairly CPU intensive. JavaScript will be the main programming language in the next decade at least, imo, and improving execution speed of JavaScript is never a waste of time. The faster it is, the more it will be used.
I took a look at some more of the benchmarks and they are pretty much universally meaningless once you throw in a good optimizing VM. For instance translating the method benchmark into Java and having it loop 2^31 times instead of 6 million times and Java is 29,000 times faster than Ruby 2.8.
Adding a simple global+=1 to the method body makes Java only 16,000 times faster than Ruby 2.8.
Replacing the +1 with global*=5 makes the Java version only 536 times faster than Ruby 2.8.
These are the kinds of optimizations MagLev is doing, and they don't translate into anywhere near the gains in actual code. So you see, you really need to rethink your tests. Even for something seemingly ok like modifying a global can depend on how it is modified and what the VM can optimize (+1 vs *5). Frankly I would just test these different Ruby implementations using the regular shootout code, since these have been designed not to be optimized out.
Slashdot Mirror
How likely is that? Someone will invent a drug to make you immune to incapacitating drugs, and we'll go back to bullets and explosions.
It'll be like Syndicate where some guy at a computer jacks up your squad's adrenaline levels and compels you to run around in leather trenchcoats killing people and blowing up vehicles, not even feeling the machine gun fire and flamethrower blasts the rival squads are hitting you with. And a cyberpunk background track pounds in your head to set the mood.
In other words... freakin' awesome.
The moderators are simply capable of making the judgement that your assertion that the sale was immoral is wrong.
Clearly the protestant work ethic has no place among slashdot readers.
So the comments defending the 1k do-nothing app as somehow moral get modded up and the posts pointing out the immorality of it aren't. Is this a fluke of moderation or are slashdot readers really so warped?
If the climate change is actually a natural process then the attempt to control it has become our first great terraforming project. How convenient that we're trying this on the only planet we have and not some spare planet that wouldn't matter if it went awry.
And if the rapid climate change is not a natural process then we have already not just attempted but are in the middle of an effective terraforming project where the only definition of 'success' must be some form of 'not at all like what we had before'. That sounds much worse to me than your what-if.
The environmental people are either saying:
1) our climate is changing, lets make it like it's always been before
-or-
2) we've changed our climate to something different and unknown, lets change it back again.
Either way sound better to me that living in a completely unknown new climate. If our previous climate was good enough for Jesus, it's good enough for us.
Singularity is more like ".NET" taken to the next level, with the entire OS running without hardware memory protection (let alone hypervisors), so it can run anywhere... even as a module inside another application... without any specific hardware support.
Unfortunately it's really more like .NET taken to a previous level. With no JIT and no dynamic class loading, it's losing a lot. JavaOS is a better example of a typesafe kernel. Even though it didn't catch on, it was a production OS that had the features of Singularity and more before Microsoft "innovated" them.
I'm just suggesting that it looks like a lack of consistency between the use of the open brace and the close brace.
It is an inconsistency. Often something that is most practical or efficient is somewhat inconsistent.
I'm also saying that if that one small line is so important, then that other basically wasted line should be a consideration for those people as well, unless there is a good reason for it to have its own line (see below).
And I've seen code where ~20% of the lines are open braces. That's hardly "one small line". Again, "one small line" is dismissive and is a bogus argument.
For purposes of this discussion, say there are two styles: A and B. Some prefer A, some prefer B. I use A, you use B. I will continue to use A for whatever reasons I choose, but if you choose to use B, here is a suggestion on how you might optimize your use of style B, using the very reasoning that leads you to use B in the first place.
Hardly. More like, if people prefer B they are "only half right" and should be using style C instead. And C is a defective style since it (obviously) impedes editing. Therefor A is a better style than B.
You can see how that is a bogus argument right?
I was always under the impression that whatever the coder groks best is the most efficient style. People think differently and thus prefer different code styles.
K&R style has more pro- points in its favor and fewer con-s than any of BSD, MS, or GNU styles. If you 'grok' a style better that is objectively less efficient and that makes you more efficient then so be it. To each his own.
But don't make up bogus arguments to justify that.
I prefer vertically aligning open and close braces, too. I was just making a point that the people who do the same-line open brace and use the vertical-space argument are only getting it half right. If the one line from the open brace is that important, they should also be doing something about the wasted line from the close brace.
But you must know that your argument is retarded, right? You are saying that if something is good then twice as much is better. Let alone that being a false argument, but the opening brace and the closing brace aren't even equivalent in the first place.
Putting the opening brace on the same line has few if any drawbacks, but putting the closing brace on the last line has drawbacks, such as the inability to add a later statement without moving the brace between lines, adding a properly scoped // NOT REACHED comment, or other things people do.
The fact that you would propose such a ridiculous argument tells me that you know that opening braces on their own line is at best a style choice with drawbacks, and that you are defensive about it and need to rationalize it. In other words, you know K&R is a more efficient style yet you would rather tear it down with false arguments than adopt it... what does that say about you as a programmer?
Wouldn't want to let anyone take over your system with yacc. Seriously.
I think if you've installed yacc with setuid bit then you have other problems to worry about. Seriously.
Well since bugs before the epoch were actual insects, judging by past precedent they'll get super powers... like wall-climbing ability or maybe spidey senses ??
The optimization was not "premature". We actually do need the speed and space.
And I'm sure decoding varints is really fast right (a branch on every byte, some shifts and xors)? And 25% of the available wire type codes being 'deprecated' is really space efficient? Or using ten bytes for any negative number unless the coder specifically declares an optimization?
It may very well be that most users don't need the speed, but switching formats down the road is pretty hard. It's not exactly like optimizing implementation details -- this is the format you use to communicate with other entities that you may or may not control.
What I like about protocol buffers is that the fields are identified by number. This makes it possible for different components to use different names to represent the same data format (for example for fixing spelling errors). But I think in most cases, in a general sense (I'm not talking google specifically), the downside of not being to make any sense out of the data without a .proto description outweights this.
And a data format like protocol buffers is essentially a custom compression algorithm, like for instance x86 instructions are. Unfortunately, it is really hard to make a custom compression that holds up over time. For instance, the two deprecated wire types could be used to optimize the first 32 fields rather than only the first 16 but instead they are just wasted.
I'm not trying to knock protocol buffers. It's a decidedly good effort. But the hackery involved in making it that slight bit faster and smaller probably isn't going to be worth while in the long run.
Note that protocol buffers give you the equivalent of a DOM -- an object representing the parsed message.
Actually no, they don't. If the parser has a different .proto file then it knows nothing about extra fields in the message, since the .proto info is not sent with the message (if it were, there would be no space savings over binary JSON for instance). This is not the equivalent of a DOM or a JSON object.
Though I think protocol buffers would still win just because there is less to parse and parsing length-delimited chunks is faster than character-delimited.
In most cases, trivially faster. The difference between 5aword and aword\0 mostly depends on how memory is allocated and how strings are referenced. For instance, in C in some cases the character-delimited string could be used in-place (with no copy or memory alloc) whereas the length-delimited one cannot (without first reimplementing all the string functions).
The big difference is that a protocol buffer cannot be understood without the message format (.proto file). Now lets actually take a look at a real list, like say the developers for apache (as a list of {name:,email:} objects):
protobuf: ~1654 bytesjson: 1915 bytes
protobuf.lzop: ~744 bytesjson.lzop: 809 bytes
What you see is precious little difference in the size of the data even though the json is self-describing. The lzop version is essentially identically sized, and compressing and decompressing with lzo is wicked fast. So size is not a reason to use proto buffers.
Maybe speed is? Instead of using lzo compression just create a JSON binary format. This is trivial, and provides essentially the same size and speed benefits as protocol buffers while still being JSON in nature.
The only advantage to protocol buffers then is that they generate access and verify classes for you in you favorite language (if that language is C++, Java, or Python). Big deal, again this is absolutely trivial.
To me what this demonstrates is premature optimization. Instead, first use a simple text format like JSON then if that is too large compress it. Then if that is too slow send it in binary.
Note: I approximated the size of the proto buffers based on the descriptions of the binary format since I haven't downloaded the code (it actually compresses less well since I did not vary the 'length' bytes in my test file).
The problem is, you can only filter out the RST packets on your end of the connection.
That's only a temporary problem. The real problem -- for the ISPs -- is that the same software is running on each end of a p2p, so all of their efforts are guaranteed to fail eventually.
For instance, p2p programs can start using UDP spread spectrum... pass packets on random ports. The receiver then basically implements a quick and dirty tcp-like connection over this (ie much worse for an ISP than actual TCP). Add encryption and random length so it's harder to filter out. Or there can be a shared random number seed for the shared ports. Just for example...
There's probably some computer science or information theory law stating this, but they can't ultimately reduce the targeted traffic by more than the loss from encoding it as 'normal' traffic. For instance, if they limit torrents to 100k/s and the loss is 33% from 'base64' encoding the data as some kind of an html-ish doc then if normal web pages get more than 133k/s then torrents would be faster encoding them as 'normal' traffic.
None of that matters if you get a keylogger on your system.
That's why level 4: Money, Banks is done from a livecd boot (or dual boot that is only used for offline/level 4 stuff).
Dividing the passwords into secure levels is nice because when you change passwords you can just shift them down a level... so there are fewer new passwords to remember -- your old highly secure 15 character password with numbers and punctuation becomes your web forum password (that you have firefox remember for you anyway).
Tell me you are not so desperate for a job that you would spend 25% of your time fixing a coworker's mistakes? Bring it up with your manager, have his faults explained to him, document it over a month or so, and fire him if he doesn't get better.
Because the other 75% of the time I get to code awesome stuff. He's friends with the CEO and went to college with a good portion of the company, so licensing or liability would help -- but your suggestions would not, Mr. Know-It-All.
As a software developer I spend about a quarter of my time rewriting code that one of our other developers writes. His code is like a rhesus monkey came in and started flinging shit all around. He 'keeps up' with the other developers because he does the absolute minimum, never ever rewrites code to fix problems, cuts and pastes, etc. One time he cut and paste a second copy of a 200 line function so he could change one loop constant.
There's lots of developers like him, and they and/or their company should get sued over that code. At least when it is from negligence. Or there should be a licensing requirement.... something so that the people who are irresponsible or incompetent are held responsible for it.
Pretty much the only thing that makes programming not worth while is that people can hack out a 80% working code, get credit for it, then move on and leave all the crap for competent developers to fix. I would gladly pay a malpractice insurance fee if it means less having to deal with bullshit code.
But many here suffer from Bush Derangement Syndrome, or less elegantly, are haters.
BDS? Bush Derangement Syndrome? Really?!
I have a hard time believing any person so uncreative and with such a misunderstanding of what elegance is would have an informed and reasonable opinion on, well, pretty much any matter.
and don't care about a civil liberty so important that the framers listed it above search and seizure and right to counsel, then of course you are not interested in an objective, fair view of the 43rd president.
Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof; or abridging the freedom of speech, or of the press; or the right of the people peaceably to assemble, and to petition the Government for a redress of grievances.
Even if we were to assume the amendments were in order of importance the inescapable conclusion is that the pen is mightier than the sword -- free speech is more important than having a handgun (handgun since the court upheld that you DO NOT have a right to bear Arms in general).
So what has this president been responsible for:
* rounding up and harassing muslims
* free speech 'zones'
* telecoms spying on every citizen (we assume)
* so-called 'national security' letters that you can't talk about to even say that you received one
* excluding non-republican from public events
* intimidating reporters, threatening to jail them over leaked 'classified' information
* and so on...
If we assume a ranking of amendments than these things would concern the FF way more than a 'handgun but no other guns' interpretation. The bible-thumpers that Bush appointed have even taken public stands against most of the 1st amendment. I won't even list all the shredding of the other amendments since you seem to hold the position that the 1st trumps the rest anyway.
The People don't have a 'bush derangement syndrome'. You use that term because a) you are retarded and b) you need some rationalization in order to hold your beliefs. My friend, 'BDS' is entirely about you, and once you admit that you have a problem then you can start to open your mind.
Plus branding this guy on his records as a cheater, plus having him apologize to each of this classmates 'or else'. Oh yeah, and take away his right to hold public office lest the Diebolds declare him president despite not being on the ballot -- we've seen what happens with a cheater in the ovaloffice.org and we can't afford it happening again.
You don't want to use svn with a large tree because it stores a second copy of only the revision you checked out (so that diffs are fast). Other systems like hg can typically store the entire repository, giving you access to all revisions, in less space (it's compressed) than svn can store just the working copy.
Furthermore, this second copy is stored in the same folder tree, which is both annoying (from a tools pov, like grep) and slow (OS has to stat a lot more inodes).
Seriously what alternatives are there to Java for a large system like this? DotNet/CLR are far slower. C is too cumbersome to manage for large systems unless you have excellent developers and process, like say the kernel. C++ can be faster than Java, but are you seriously going to have developers that make constants called THREE with value 3 program in perhaps the most complex programming language yet created? If developers can't even create decent constants they certainly aren't going to avoid database queries in their copy constructors... since they lack even basic ability their C++ version is going to be ridiculously slow.
This FUBAR software almost certainly was programmed in C++ or worse. For one thing, it would have to be seriously screwed up for a Java build to take a day -- but this happens often with even just large-ish C++ projects.
That's where the connection to the Bush administration is. A recent survey of historians had 96% putting this administration in the bottom fourth and 66% that this has been the worst administration in history. But it's all just economics? Yeah, and that's why oil is so expensive and why people are now betting against our country being solvent in the next couple decades. Because we've been fucked big time by secret Cheney deal and all the rest of this dumbass president..
I have to disagree with you about Smalltalk. Before it in performance are LISP and on the great benchmark shootout even LuaJIT (!) is faster than VisualWorks smalltalk -- vw is pretty fast for a smalltalk. Smalltalk has been optimized a lot, but it's not really a 'fast' language. For most JavaScript, this is a complete waste of time. It is very rare for JavaScript to run for more than a fraction of a second at a time and so latency caused by interrupting execution much worse than just running it slightly more slowly. The ActionScript VM in Flash is very different, since it is designed to run scripts that stay running for minutes at a time and are fairly CPU intensive. JavaScript will be the main programming language in the next decade at least, imo, and improving execution speed of JavaScript is never a waste of time. The faster it is, the more it will be used.
I took a look at some more of the benchmarks and they are pretty much universally meaningless once you throw in a good optimizing VM. For instance translating the method benchmark into Java and having it loop 2^31 times instead of 6 million times and Java is 29,000 times faster than Ruby 2.8.
Adding a simple global+=1 to the method body makes Java only 16,000 times faster than Ruby 2.8.
Replacing the +1 with global*=5 makes the Java version only 536 times faster than Ruby 2.8.
These are the kinds of optimizations MagLev is doing, and they don't translate into anywhere near the gains in actual code. So you see, you really need to rethink your tests. Even for something seemingly ok like modifying a global can depend on how it is modified and what the VM can optimize (+1 vs *5). Frankly I would just test these different Ruby implementations using the regular shootout code, since these have been designed not to be optimized out.