Postgres scored 778 on a probably more expensive machine with twice the RAM of the MySQL machine which scored 720. You call an 8% improvement "smoking it"?
who does not give a shit about how Google employees go to work, are fed or have their asses wiped for them. I thought this Slashdot was a tech blog, not Entertainment Tonight. All this Google gushing is getting tedious.
Maybe people just want to be reminded that some vestiges of March 2000 still exist?
Offtopic - my slashdot posting image confirmation word was "offshore" - should I be concerned?
It is very simple. The text google({"foo":"bar"}) is valid javascript when included and parsed via a script tag. The JSON text {"foo":"bar"} is not valid Javascript when included parsed via a script tag. It is a syntax error in Firefox, Mozilla, IE6 and every browser I've tried.
I only mentioned XmlHttpRequest because some have incorrectly argued that you could still make an XHR call to a foreign website and get the raw JSON information. XHR prevents this with its site-of-origin policy. This bug was solely caused by Google's incorrect use of Javascript.
JSON is fine for use in AJAX web sites, and the sky is not falling.
XML has no special cross-domain security over plain JSON.
JSON is not the problem here. The problem was the stupid google({}) function call wrapped around the JSON in the reply. Remove that stupid function call and everything is fine. Since you cannot receive or send data via XmlHttpRequest to a domain other than the one that served up the HTML, you will not be at risk if only JSON is returned.
C++ could greatly benefit from ONE standard object file and bytecode format for all OSes and CPUs. Yes, I'm a heritic. The linker or loader should be responsible for translating the standard object file format to the host's native machine code. Bjarne's biggest failure in C++ was giving too much flexibility in C++ compiler implementations. This aided early adoption of C++, but this flexibility has led to needless incompatibility - even with compilers on the same architecture and OS. LLVM's bytecode format is as good a candidate for such a universal intermediate format as any (and probably better than most). Just having a standard C++ ABI is not good enough to carry C++ forward. C++ needs a proper architecturally neutral distrobution format and a standard set of libraries. With such a format in place C++ developers might mirror the 3rd party library support success that Java and its ubiquitous.jar files currently enjoy.
When someone writes code in java here is the process:
1. Google for feature X.
2. Grab.jar file for X - almost never download the actual code.
3. write 2 lines of code in Java to call the function in question.
4. done.
When someone tries to do the same in C++, here is the process:
1. Google for feature X and C++.
2. Find something written in 1997 on some C++ compiler/platform that is different than your own.
3. download the code and see if it is compatible with your own C++ code and its myriad of compiler flags and libraries on your system.
4. try to compile it - this step usually ends in failure.
5. even if it does compile when you go to run the code it will invariably crash due to some invalid type size assumptions in the library code.
6. hack the 3rd party library source to get it to work, but you realize that it does not do what you want it to do.
7. go to step 2.
8./*NOTREACHED*/
When evaluating a computer language people often concentrate on generated code quality. Very few languages can rival C++ in this area. But what is often neglected is code build times. The code generated by C++ templates is pretty amazing - huge chunks of C++ code can sometimes be reduced into a few machine opcodes, but few people have the hundreds of hours per year to spare waiting for their compilers to actually build the code. I like the power and expressiveness of C++, but javac build times puts C++ to shame. Even if you rebuild your entire project from scratch in Java it is still 10 times faster than an incremental build in C++. God forbid you change a key C++ header file or something drastic. Knowing that C++ compile times are so horrendously slow, people often keep lousy base classes in place and puts hacks in derived classes that should not be there. Yes, pointer forward declarations help. Yes, Distcc and ccache are also helpful. But these techniques and tools do not address the basic shortcomings of the static C++ build process. If your build cycle is fast you can get more work done, plain and simple.
I set up fasterbubblesorts.sourceforge.net so we can compare notes. I've been working on a promising branch of research the past few months - I think we could get some extra performance if we invert the "FOR I" and the "FOR J" loops.
If you believe that SuperPi is representative of real-world CPU performance, then you will be very happy with the new Intel chip. I personally care more about multiprocess/multithreaded server loads using largely integer math with working datasets several orders of magnitude larger than the on-chip memory cache. Under such a scenario you want very fast memory transfer speeds between CPU and main memory. I have not seen any Conroe benchmarks related to that. I wonder why. We'll see how well the chip performs when it actually ships and is tested under conditions not dictated by Intel.
When a CEO says he is "Desperate For Developers" it means that he want to hire developers who work more hours for less money.
What dipshit marked the parent post as a troll? This is an absolute fact. Supply and demand has taught us there is no such thing as a shortage if you are willing to pay for it. Reminds me of the whiners crying about Google "stealing" all the top talent. I hope another 20 Googles come along to create better competition. Here's a clue to the employers - just pay more to retain/acquire better talent. Either that or be willing to pay for the 5 years of training that it would take to get a green programmer to that level of skill.
Three digits were turning to zero for God's sake! We're lucky to escape with our lives. Remember what happened to people in the year 1000? Of course not - because they did not adjust their computer code to handle Y1K and they all perished.
We are in violent agreement. True, your program can be kill -9 safe but it does not mean that your program cannot simply exit() when some pre-defined condition arises. (A traditional exit() is also a good way to check for memory leaks with such programs purify and valgrind - but that's another matter). But these ideas are not revolutionary by any means. I thought everyone who writes fault-tolerant servers follows these practices.
You're completely wrong. Pirate solution is crap.
on
Defining Google
·
· Score: 1
If I were was only going to get one piece of gold while another pirate was going to get 98 pieces then I'd just as soon get none and vote the lead pirate down. The proposed solution of "98 0 1 0 1" is nonsensical. The solution makes the fatal assumption that no one would gamble with their life. The pirates did not get that far based solely on logic - they're criminals for crying out loud! Gambling with their lives for monetary gain is in their blood. Someone who would blindly accept that solution as an answer is not someone I would want working on my team. This is the sort of faulty logic that lead to the fall of Long-Term Capital. One must always question the validity of their assumptions. A more realistic solution to the pirate problem would involve running a Monte Carlo simulation with more realistic payout scenarios given their likelihood to gamble with their lives.
Use the same code for the start-up sequence of your program as you do for crash recovery - treat them the same. Fewer lines of code leads to less chance of an error. That's all.
If I had an R&D budget a quarter the size of Google (say only $50 million) I could have the damn browser code a complete office suite in Javascript while riding a unicycle while reciting the complete works of William Shakespeare - and I'd still have money left over for lunch.
Slashdot Mirror
But he didn't sign it - "a Thai journalist walked out ... over a controversial NDA"
Big deal. I'm bored now. Can this non-controversial supposed NDA controversy be any less boring?
Who is the president of the controversy deciding committee? I demand a seat!
then what's he bitching about?
Think of the children!
(Why is this story interesting in the least?)
Postgres scored 778 on a probably more expensive machine with twice the RAM of the MySQL machine which scored 720. You call an 8% improvement "smoking it"?
who does not give a shit about how Google employees go to work, are fed or have their asses wiped for them. I thought this Slashdot was a tech blog, not Entertainment Tonight. All this Google gushing is getting tedious.
Maybe people just want to be reminded that some vestiges of March 2000 still exist?
Offtopic - my slashdot posting image confirmation word was "offshore" - should I be concerned?
It is very simple. The text google({"foo":"bar"}) is valid javascript when included and parsed via a script tag. The JSON text {"foo":"bar"} is not valid Javascript when included parsed via a script tag. It is a syntax error in Firefox, Mozilla, IE6 and every browser I've tried.
I only mentioned XmlHttpRequest because some have incorrectly argued that you could still make an XHR call to a foreign website and get the raw JSON information. XHR prevents this with its site-of-origin policy. This bug was solely caused by Google's incorrect use of Javascript.
JSON is fine for use in AJAX web sites, and the sky is not falling.
Die Hard uses the Flux Capacitor technology.
Man, that's lame even by my standards.
I agree completely. It is a Google bug, plain and simple. JSON in a browser is perfectly safe if used correctly.
XML has no special cross-domain security over plain JSON.
JSON is not the problem here. The problem was the stupid google({}) function call wrapped around the JSON in the reply. Remove that stupid function call and everything is fine. Since you cannot receive or send data via XmlHttpRequest to a domain other than the one that served up the HTML, you will not be at risk if only JSON is returned.
The sky is falling!
The sky is falling!
Sheesh.
If you want to slander someone with unsubstantiated crap, please tell us who you are to add credibility to your claim.
C++ could greatly benefit from ONE standard object file and bytecode format for all OSes and CPUs. Yes, I'm a heritic. The linker or loader should be responsible for translating the standard object file format to the host's native machine code. Bjarne's biggest failure in C++ was giving too much flexibility in C++ compiler implementations. This aided early adoption of C++, but this flexibility has led to needless incompatibility - even with compilers on the same architecture and OS. LLVM's bytecode format is as good a candidate for such a universal intermediate format as any (and probably better than most). Just having a standard C++ ABI is not good enough to carry C++ forward. C++ needs a proper architecturally neutral distrobution format and a standard set of libraries. With such a format in place C++ developers might mirror the 3rd party library support success that Java and its ubiquitous .jar files currently enjoy.
.jar file for X - almost never download the actual code.
/*NOTREACHED*/
When someone writes code in java here is the process:
1. Google for feature X.
2. Grab
3. write 2 lines of code in Java to call the function in question.
4. done.
When someone tries to do the same in C++, here is the process:
1. Google for feature X and C++.
2. Find something written in 1997 on some C++ compiler/platform that is different than your own.
3. download the code and see if it is compatible with your own C++ code and its myriad of compiler flags and libraries on your system.
4. try to compile it - this step usually ends in failure.
5. even if it does compile when you go to run the code it will invariably crash due to some invalid type size assumptions in the library code.
6. hack the 3rd party library source to get it to work, but you realize that it does not do what you want it to do.
7. go to step 2.
8.
When evaluating a computer language people often concentrate on generated code quality. Very few languages can rival C++ in this area. But what is often neglected is code build times. The code generated by C++ templates is pretty amazing - huge chunks of C++ code can sometimes be reduced into a few machine opcodes, but few people have the hundreds of hours per year to spare waiting for their compilers to actually build the code. I like the power and expressiveness of C++, but javac build times puts C++ to shame. Even if you rebuild your entire project from scratch in Java it is still 10 times faster than an incremental build in C++. God forbid you change a key C++ header file or something drastic. Knowing that C++ compile times are so horrendously slow, people often keep lousy base classes in place and puts hacks in derived classes that should not be there. Yes, pointer forward declarations help. Yes, Distcc and ccache are also helpful. But these techniques and tools do not address the basic shortcomings of the static C++ build process. If your build cycle is fast you can get more work done, plain and simple.
I set up fasterbubblesorts.sourceforge.net so we can compare notes. I've been working on a promising branch of research the past few months - I think we could get some extra performance if we invert the "FOR I" and the "FOR J" loops.
If you believe that SuperPi is representative of real-world CPU performance, then you will be very happy with the new Intel chip. I personally care more about multiprocess/multithreaded server loads using largely integer math with working datasets several orders of magnitude larger than the on-chip memory cache. Under such a scenario you want very fast memory transfer speeds between CPU and main memory. I have not seen any Conroe benchmarks related to that. I wonder why. We'll see how well the chip performs when it actually ships and is tested under conditions not dictated by Intel.
When a CEO says he is "Desperate For Developers" it means that he want to hire developers who work more hours for less money.
What dipshit marked the parent post as a troll? This is an absolute fact. Supply and demand has taught us there is no such thing as a shortage if you are willing to pay for it. Reminds me of the whiners crying about Google "stealing" all the top talent. I hope another 20 Googles come along to create better competition. Here's a clue to the employers - just pay more to retain/acquire better talent. Either that or be willing to pay for the 5 years of training that it would take to get a green programmer to that level of skill.
Fork in the Open Source Java world.
<get><a><clue>duh</></></>
See - just thinking of Y2K made me post to the wrong story.
Three digits were turning to zero for God's sake! We're lucky to escape with our lives. Remember what happened to people in the year 1000? Of course not - because they did not adjust their computer code to handle Y1K and they all perished.
We are in violent agreement. True, your program can be kill -9 safe but it does not mean that your program cannot simply exit() when some pre-defined condition arises. (A traditional exit() is also a good way to check for memory leaks with such programs purify and valgrind - but that's another matter). But these ideas are not revolutionary by any means. I thought everyone who writes fault-tolerant servers follows these practices.
If I were was only going to get one piece of gold while another pirate was going to get 98 pieces then I'd just as soon get none and vote the lead pirate down. The proposed solution of "98 0 1 0 1" is nonsensical. The solution makes the fatal assumption that no one would gamble with their life. The pirates did not get that far based solely on logic - they're criminals for crying out loud! Gambling with their lives for monetary gain is in their blood. Someone who would blindly accept that solution as an answer is not someone I would want working on my team. This is the sort of faulty logic that lead to the fall of Long-Term Capital. One must always question the validity of their assumptions. A more realistic solution to the pirate problem would involve running a Monte Carlo simulation with more realistic payout scenarios given their likelihood to gamble with their lives.
Use the same code for the start-up sequence of your program as you do for crash recovery - treat them the same. Fewer lines of code leads to less chance of an error. That's all.
If I had an R&D budget a quarter the size of Google (say only $50 million) I could have the damn browser code a complete office suite in Javascript while riding a unicycle while reciting the complete works of William Shakespeare - and I'd still have money left over for lunch.
Your sane view of reality is not welcome on Slashdot. You must repeat only slight variations of what the others are saying.
So in 19 years when their patents expire we'll all be done with this mess. In 2024 we'll finally be free from this stupidity.
call it the "Growser".
I can already see how it will revolutionize the english language:
Joe: "Hey Hank, did you growse that info?"
Hank: "Yeah, my growser growsed it up real good."
Joe: "That's some mighty fine growsing, Hank."