DNS is broken -- it is possible to ask your DNS to lookup "Bank of America", and if the hackers have screwed the DNS servers inbetween yours and root, you'll get the wrong machine. That allows someone to do a man in the middle attack: all your requests get relayed to your bank, but perhaps with different amounts or payees. That subverts two-factor methods also.
Because DNS is broken, even if the banks beef up their stuff, there's no hope for secure transactions.
E.g. suppose you need a pasword and a one-use number (from a list of magic numbers the bank gives you) to do a transfer. [this is how it is in some parts of Europe]. The bad boys do the transfer, but they transfer the money to themselves, not your payee. And they take as much as they want. And they use the magic number you've given them for your intended transaction.
So because of this potential problem, I don't do online banking.
I figure the average schmuck doesn't have a chance anyway; he's using the same OS and software as 99% of the victims, so he's an easy target.
Are there any better pictures than the ones in the article?
This one is looking spooky, like she just got a facelift, or saw a ghost. She's got that Real Doll look.
This one has a cheap looking hair-weave. She's also looking a bit angry.
"You're right, I forgot about LISP's kludgey macro system. Of course, this doesn't make it 'arbitrarily complex.'"
You are kidding, right? You can do arbitrary compuation at macro expansion time. With the wonderful template metaprogramming that you mentioned, you can't do as much as easily and you are at the mercy of the implementation (e.g. how many levels of expansion).
"Like what? You can't even declare a simple character array properly, what makes me think you know that they have no C++ equivalent?"
Look, you said LISP is a single paradigm language. I said it has more, and listed some of them. You've yet to explain how to somehow discount all those paradigms back down to one.
The fact that I made a syntax error in an array declaration doens't change the fact that LISP supports more than one paradigm -- and more paradigms than C++. The fact that you said "destructor" when you meant "constructor" is equally atrocious - by your own logic, I could argue you don't know C++.
If you want to troll, can't you at least troll about something juicy? Why troll about something that makes you look completely ridiculous? The facts are against you -- just troll on something entirely subjective, or don't make statements like, "LISP is a single paradigm language."
So what's the "single paradigm" that LISP supports, vs C++?
As far as I can tell, you can do functional, imperative and object-oriented programming in LISP. And with macros, you can do arbitrarily complicated programming when it parses things -- e.g. a macro that translates all strings from English to German, when it reads in the program. That's about 15 lines -- just look at Ron's blog.
That seems to be many paradigms to me -- and some of them have no C++ equivalent.
Yet you've written "LISP will end up taking far more time because of its limited language capabilities. The rest of the world prefers multi-paradigm langauges, and for good reason."
"Yes, it does. It wasn't just a typo, that indicates you have little to no experience with C++. That's not the kind of mistake anyone with significant experience would make."
Actually, I was just trying to make an example. I have plenty of experience with C++.
"First of all, a GC isn't not a magic cureall. Second of all, there is GC support for C++. Third of all, this is programmer induced race condition, it's a rare kind of error."
Well, in this case, the race condition was between the GC and the other thread. In a multi-threaded lisp, that problem would be eliminated; it just couldn't happen. You could have race conditions, but not between the GC and a thread. In this case, it would have been a cureall.
"Because programmers shouldn't be careful, right? And a person who makes a mistake isn't at fault for the mistake even though THEY made it?"
Well, that's why a C++ programmer gets less work done; he has to do tasks that a LISP programmer doesn't have to deal with. In this case, the performance penalty of a LISP, over C++ would be negligible -- so overall, the C++ programmer loses. An assembly programmer also has to manage a bunch of mind-numbing details -- but there's no reason, a priori, to say that a job has to be done with such a tool. If you say the solution must be done with a less powerful tool, then you need to get people who are good at managing such low-level details, and who feel content getting less accomplished.
Also, you talk about the problem as if it were being solved by a single programmer. As Ron makes clear, there were multiple programmers. So using C++ imposes more costs: the programmers have to talk to make sure they don't fuck themselves with little implementation details. If they were using LISP, they wouldn't need to talk about how to avoid the problems, so they'd get more work done.
"Using LISP doesn't remove the risk of making mistakes. It just forces you into a less powerful language and ends up giving you a headache, all for the sake of avoiding some trivial programming error."
What's the headache? Also, why do you say "less powerful"? I'm really not getting your point here. LISP is a more powerful language, because it has closures, a GC, arbitrarily complicated macros, runtime compilation, etc. Since the 1970's, Common Lisp has been faster than Fortran for problems where performance matters.
Furthermore, if you will argue that "C" or C++ is faster than LISP, because you can do machine-level things, then I'd ask why you just don't use assembly, to get the most "power". Whatver "C" has, assembly has more of it, right?
"I saw your code in your other and it has a very basic "newbie syntax error" in declaring a char array. This tells me you don't even know basic C/C++ and aren't really qualified in the slightest to comment on it. Whoever taught you C++, you should get a refund from."
So I made a basic syntax error, and now I don't know anything about C++? That's absurd. And there's no need to be so insulting.
I can't say anything about why they did what they did (I don't even know what they did), how they did the programming, etc.
My point was that if you wanted a simple program to do what they were doing, C++ would allow you to build a mostly working, but under some conditions horribly broken program very easily, and a language with a GC wouldn't.
Sure, their problem sounds like it was simple, and they could have just used some typical mechanism to make things work --- but it was very easy for them to do it so that it mostly worked, but was actually horrifically broken.
Your points about using wrappers or destructor Kung Fu are in keeping with the "always do things very carefully" attitude of C++: if someone makes a mistake, it is his fault. Someone like Ron, knowing that there's a chance of making a mistake, would prefer to use tools that remove the risk of him making a mistake from the get-go.
"I haven't used LISP, but I do have experience with a functional language (OCaml). Praytell how do you permit multithreaded access local variables of a function without severely destroying things?
See below.
"Stack variables" in C are variables local to the function (and parameters). To access the local variables within another thread you'd have to perform some very specific kludges to obtain a reference into another thread's stack..."
Actually, I think the problem is that it is very easy for a C++ programmer to get ahold of a pointer to stack-allocated data. No special tricks are required. I suspect this is how their program was (from reading the article carefully):
void period_writer(char *p){...}
void spawner(){
char[BIG_ARRAY_SIZE] x;
spawn(periodic_writer, x);
for(;;){... }/* under some circumstances, the body finishes.
}
main(){ ... spawner();
wait_for_all_threads_to_finish(); }
In this case, there are two threads -- the initial one that calls spawner and the one that gets spawned to run period_writer. Periodic_writer receives the pointer to the data to periodically write out.
Everything works, unless spawner exits too early, deallocating the buffer shared between the two threads. It isn't at all hard for spawner to pass the stack-allocated data to the thread, making it very easy to make this error -- no specific kludges are required.
X won't get deallocated prematurely in a multi-threaded implementation.
"If I understand your language correctly, what I understand to be happening in their C++ multithreaded system was bluntly impossible to do in LISP. You can't have the problem, because you can't solve it that way.
Right -- you can't solve it in such a risky fashion. And if you do something bad, the GC will keep around the data -- it won't allow some other thread to write in to the space. And in the event one thread writes some crap there that the other thread isn't expecting, you'll likely get a type error and the system will halt -- it won't just proceed blindly ahead with garbage.
The only way I can think to duplicate the error is if you allocated some bytes and treated them as untyped bytes, arranged to store/retrieve data in the untyped bytes, implemented a stack and duplicated the concurrency error in the C program. The nature of the language is such that you can't screw yourself if you do the normal thing, which is just to use lexical scoping to share the variable.
The typical C++ solution is to use shared globals and accurately protect them. I suppose there could be a kludge workaround to what I'm saying, but the general point I was making was that it's a kludge in C/C++ too. Trying something like that in a multithreaded LISP environment isn't something on my todo list, however."
Actually, they said they stored the shared data on the stack, as in my example. As long as you know that the thread with the data on the stack will always exit after any uses, that's going to work, and it isn't kludgey. As for it not being on your todo list, if you've got a lisp available, it won't be more than a few lines -- it isn't nearly as bothersome as the C++ version.
But hopefully this one case shows you why Ron was of the opinion that he could get work done around 10x faster with LISP than C++. Tracking down the bug probably cost them a lot of time and stress.
The problem turned out to be something called a race condition, which is one of the most pernicious and difficult kinds of bugs to find. (Those of you who are technically savvy can skip to the end.)
Most modern server code is multi-threaded, which means that it does more than one computation at once. This is important because computers do more than just compute. They also store and retrieve information from hard disks, which are much, much slower than the computers. Every time the computer has to access the disk things come to a screeching halt. To give you some idea, most modern computers run at clock speed measured in gigahertz, or billions of cycles per second. The fastest hard disks have seek times (that is, the time it takes the drive to move the read/write head into the proper position) of several milliseconds. So a computer can perform tens of millions of computations in the time it takes a hard disk just to get into position to read or write data.
In order to keep things from bogging down, when one computation has to access the disk, it suspends itself, and another computation takes over. This way, one computer sort of "pretends" that it is really multiple computers all running at the same time, even though in reality what is happening is that one computer is just time-slicing lots of simultaneous computations.
The ad server, the machine that actually served up ads in response to search terms, ran multi-threaded code written in C++, which is more or less the industry standard nowadays for high-performance applications. C++ is byzantine, one of the most complex programming languages ever invented. I've been studying C++ off and on for ten years and I'm still far from being an expert. Its designers didn't really set out to make it that complicated, it just sort of accreted more and more cruft over the years until it turned into this hulking behemoth.
C++ has a lot of features, but one feature that it lacks that Lisp and Java have is automatic memory management. Lisp and Java (and most other modern programming langauges) use a technique called garbage collection to automatically figure out when a piece of memory is no longer being used and put it back in the pool of available memory. In C++ you have to do this manually.
Memory management in multi-threaded applications is one of the biggest challenges C++ programmers face. It's a nightmare. All kinds of techniques and protocols have been developed to help make the task easier, but none of them work very well. At the very least they all require a certain discipline on the part of the programmer that is very difficult to maintain. And for complex pieces of code that are being worked on by more than one person it is very, very hard to get it right.
What happened, it turned out, was this: the ad server kept a count of all the ads that it served, which it periodically wrote out to the database. (For those of you wondering what database we were using, it was MySQL, which leads to another story, but that will have to wait for another post.) It also had a feature where, if it was shut down for any reason, it would write out the final served ads count before it actually quit. The ad counts were stored in a block of memory that was stack allocated by one thread. The final ad counts were written out by code running in a different thread. So when the ad server was shut down, the first thread would exit and free up the memory holding the ad counts, which would then be reused by some other process, which would write essentially random data there. In the meantime, the thread writing out the final ad counts would still be reading that memory.
"Not that I have an axe to grind against LISP'ers, but I'm not sure how better memory management would have prevented one thread from accessing another's now defunct stack data aside from not allowing it in the first place."
The basic idea is that the programmer doesn't manage the memory, so that problem just can't occur. You aren't supposed to be able to tell where the storage is (heap, stack, etc).
Were there to be a problem, it would be the fault of the LISP implementor.
The implementation of lexical closures (a Common LISP feature) requires keeping around the free variables associated with a procedure. So the implementation has to be able to routinely and efficiently do the sort of thing that a C program can't do, due to how it stores things. If you have a multi-threaded lisp, and the implementation is correct, you simply can't have the problem that Ron ran into.
You'll see there's a lisper who left JPL because managers decided to follow "best practices" of industry and move to C++. This is despite the fact that programming a space mission isn't a "standard" problem -- it is, in fact, a problem that a language like LISP is excellently suited, because people can deal with unclear/dynamic requirements as a project evolves.
So he goes to Google because they have some LISP guys there (not using LISP -- just smart guys) -- and then he gets told to do the first Java project. And later he gets told that LISP is out of the question.
And in fact, he details how a race condition in the C++ memory management leads to them billing clients nonsense amounts -- a problem that simply couldn't happen if they'd used a language like LISP (or Java) -- because the GC wouldn't reclaim something if the thing was still in use.
So Google can yet be beat -- they are not perfect. Of course, that doesn't mean there is anyone to beat them, yet.
Isn't the main issue how to power the balls? They'll need energy to hop around, make measurements and communicate.
I don't think the ad hoc wireless network aspect of things is likely to be the hard part: if people can solve the power problems, Siemens, Sony, Panasonic, Toshiba and Philips will likely take care of the network/software part in the course of solving our more earthly problems.
E.g. a security system built of these would seem to have wide appeal.
It looks like they'll have to err on the side of rejecting programs that just happen to look like rootkits. What would those be?
If the OS vendor wants to release a patch or extension, won't it look "evil" to the detector chip? It will be altering the OS -- so maybe it is a rootkit.
It seems like the marketing is running things here. With the trusted boot stuff that was a different story -- that has a good theoretical basis.
Carl Fogle seems like a really greasy bastard, promoting some schmaltzy Beatles memorabilia with an otherwise interesting cancer story.
Of course, the funny thing is that if he's misuing the PageRank of Slashdot, that increases the odds that geeks at Google will take note of what the greaseball Carl Fogle is doing, resulting in his sites getting bodyslammed in the future. That will hurt his business, and he won't be getting so much Geld when it is all over.
Now if Sun is giving away the processor, there's no reason for you to pay more for a PowerPC-based design -- someone will make a "cheapo" FPGA-extendable UltraSPARC.
You are purposefully dense here, but for the purposes of others who will read this, I will explain.
As I mentioned already, the religious beliefs of Jews, for the most part don't matter.
When Bob Dylan (nee Zimmerman) was a holy-roller Christian, he was Jew going through a phase.
When Trotsky, the atheist communist Jew, played chess in Vienna with capitalists Jews in Vienna, all that mattered was that they were from the same tribe, not their religion. Had ideology or religion mattered to them, they wouldn't have associated with each other. On the other hand, it is unthinkable that someone like Donald Trump would socialize with a communist, just because the person shared his ethnicity -- because Donald cares about ideology.
Jacob Schiff, a rich capitalist Jew who hated goyische imperialist Russia, helped communist Jews to take over Imperialist Russia. Why would a capitalist help communists to topple a country? Because ideology didn't matter to him -- just ethnicity.
With Jews, ethnicity trumps religion. E.g. the Lubavitchers (how I love them) would have gladly taken all of the above-mentioned Jews in and rehabilitated them. All that matters is that they were all ethnic Jews. You wanna make aliyah? Go right ahead -- you just need to show that you've got a Jewish grandparent. Your religion is immaterial. You can be an anarchist or Stalinist and make aliyah -- no problem.
On the other hand, if a non-Jew wants to become a Lubavitcher, the Lubavitchers will do all that they can to dissuade the guy. He's not welcome. Because ethnically, he's not a Jew. And gentiles can forget about immigrating to Israel; that's just not allowed. Yeah, you can convert and immigrate -- but that's pretty tough, and life won't be fun after you've done it. And if one day all the Arabs get smart and decide to convert to Judaism (so that they can take over the country), you can bet Israel will change the rules to stop them. Although if a bunch of Arabs were to convert in order to immigrate, I'd argue that they are Talmudic enough and belong "in" -- that sort of creative problem solving should be encouraged.
Of course, religion matters when talking about "posses" that are competing. E.g. Satmars vs. Lubavitchers. But these differences don't matter much, especially if there's something to gain by cooperating against other "outsiders" -- e.g. securlar Jews or goyim.
Given that ethnicity is so important in human affairs, and to the extent that the ethnic stereotypes are rooted in factual observations, I feel my statements are reasonable, if perhaps politically incorrect. If you want me to stop pointing out that the facts fit the stereotypes, I suggest you somehow try to get people to act less stereotypically.
To all the folks who replied to my question: thanks for the info!
I had no idea that roads were essentially non-existent, and that India has a pretty good (and heavily subsidized) passenger rail system. If you really have no highways whatsoever, there probably is a huge relative advantage to having some, as opposed to having yet more rail.
Knowing how bad cars in the US are, I'm inclined to think -- well, could you maybe build more rail (more lines), just for freight -- and perhaps some express trains, for those folks with more money (and less time)?
But that's probably dumber than building a few freeways -- and I'm showing my anti-car biases.
As fuel prices rise in the US, there are a number of communities that will likely be depopulated -- the folks living there now commute to population centers for work, and those commutes will probably become too expensive in the future.
Slashdot Mirror
DNS is broken -- it is possible to ask your DNS to lookup "Bank of America", and if the hackers have screwed the DNS servers inbetween yours and root, you'll get the wrong machine. That allows someone to do a man in the middle attack: all your requests get relayed to your bank, but perhaps with different amounts or payees. That subverts two-factor methods also.
Because DNS is broken, even if the banks beef up their stuff, there's no hope for secure transactions.
E.g. suppose you need a pasword and a one-use number (from a list of magic numbers the bank gives you) to do a transfer. [this is how it is in some parts of Europe]. The bad boys do the transfer, but they transfer the money to themselves, not your payee. And they take as much as they want. And they use the magic number you've given them for your intended transaction.
So because of this potential problem, I don't do online banking.
I figure the average schmuck doesn't have a chance anyway; he's using the same OS and software as 99% of the victims, so he's an easy target.
Are there any better pictures than the ones in the article?
This one is looking spooky, like she just got a facelift, or saw a ghost.
She's got that Real Doll look.
This one has a cheap looking hair-weave. She's also looking a bit angry.
I've noticed that when I troll on certain topics, the whole thread of trolls will get modded into oblivion.
This is usually the case when the trolls hit certain topics that the powers that be care about.
Complaints about Zonky's dupes, "Pickle-Pail" or "Beatles Beatles" seem to be esp. touchy.
Hey, I already listed them: OO, imperative, functional.
The language is strictly more powerful: closures suffice to prove that.
And yeah -- I was thinging "char x[SIZE]" when I wrote it too. It just came out that way.
And it wasn't code either -- it was just pseudocode. You didn't even write pseudocode, you bum.
Why a fan? Because you are very good at what you do.
"You're right, I forgot about LISP's kludgey macro system. Of course, this doesn't make it 'arbitrarily complex.'"
You are kidding, right? You can do arbitrary compuation at macro expansion time. With the wonderful template metaprogramming that you mentioned, you can't do as much as easily and you are at the mercy of the implementation (e.g. how many levels of expansion).
"Like what? You can't even declare a simple character array properly, what makes me think you know that they have no C++ equivalent?"
Look, you said LISP is a single paradigm language. I said it has more, and listed some of them. You've yet to explain how to somehow discount all those paradigms back down to one.
The fact that I made a syntax error in an array declaration doens't change the fact that LISP supports more than one paradigm -- and more paradigms than C++. The fact that you said "destructor" when you meant "constructor" is equally atrocious - by your own logic, I could argue you don't know C++.
If you want to troll, can't you at least troll about something juicy? Why troll about something that makes you look completely ridiculous? The facts are against you -- just troll on something entirely subjective, or don't make statements like, "LISP is a single paradigm language."
So what's the "single paradigm" that LISP supports, vs C++?
As far as I can tell, you can do functional, imperative and object-oriented programming in LISP. And with macros, you can do arbitrarily complicated programming when it parses things -- e.g. a macro that translates all strings from English to German, when it reads in the program. That's about 15 lines -- just look at Ron's blog.
That seems to be many paradigms to me -- and some of them have no C++ equivalent.
Yet you've written "LISP will end up taking far more time because of its limited language capabilities. The rest of the world prefers multi-paradigm langauges, and for good reason."
Can you explain that further, please?
Yeah, but do you guys say "sh-ch" or just "sht" when you say borscht?
If you are from the old country, it is the first.
"Yes, it does. It wasn't just a typo, that indicates you have little to no experience with C++. That's not the kind of mistake anyone with significant experience would make."
Actually, I was just trying to make an example. I have plenty of experience with C++.
"First of all, a GC isn't not a magic cureall. Second of all, there is GC support for C++. Third of all, this is programmer induced race condition, it's a rare kind of error."
Well, in this case, the race condition was between the GC and the other thread. In a multi-threaded lisp, that problem would be eliminated; it just couldn't happen. You could have race conditions, but not between the GC and a thread. In this case, it would have been a cureall.
"Because programmers shouldn't be careful, right? And a person who makes a mistake isn't at fault for the mistake even though THEY made it?"
Well, that's why a C++ programmer gets less work done; he has to do tasks that a LISP programmer doesn't have to deal with. In this case, the performance penalty of a LISP, over C++ would be negligible -- so overall, the C++ programmer loses. An assembly programmer also has to manage a bunch of mind-numbing details -- but there's no reason, a priori, to say that a job has to be done with such a tool. If you say the solution must be done with a less powerful tool, then you need to get people who are good at managing such low-level details, and who feel content getting less accomplished.
Also, you talk about the problem as if it were being solved by a single programmer. As Ron makes clear, there were multiple programmers. So using C++ imposes more costs: the programmers have to talk to make sure they don't fuck themselves with little implementation details. If they were using LISP, they wouldn't need to talk about how to avoid the problems, so they'd get more work done.
"Using LISP doesn't remove the risk of making mistakes. It just forces you into a less powerful language and ends up giving you a headache, all for the sake of avoiding some trivial programming error."
What's the headache? Also, why do you say "less powerful"? I'm really not getting your point here. LISP is a more powerful language, because it has closures, a GC, arbitrarily complicated macros, runtime compilation, etc. Since the 1970's, Common Lisp has been faster than Fortran for problems where performance matters.
Furthermore, if you will argue that "C" or C++ is faster than LISP, because you can do machine-level things, then I'd ask why you just don't use assembly, to get the most "power". Whatver "C" has, assembly has more of it, right?
"I saw your code in your other and it has a very basic "newbie syntax error" in declaring a char array. This tells me you don't even know basic C/C++ and aren't really qualified in the slightest to comment on it. Whoever taught you C++, you should get a refund from."
So I made a basic syntax error, and now I don't know anything about C++? That's absurd. And there's no need to be so insulting.
I can't say anything about why they did what they did (I don't even know what they did), how they did the programming, etc.
My point was that if you wanted a simple program to do what they were doing, C++ would allow you to build a mostly working, but under some conditions horribly broken program very easily, and a language with a GC wouldn't.
Sure, their problem sounds like it was simple, and they could have just used some typical mechanism to make things work --- but it was very easy for them to do it so that it mostly worked, but was actually horrifically broken.
Your points about using wrappers or destructor Kung Fu are in keeping with the "always do things very carefully" attitude of C++: if someone makes a mistake, it is his fault. Someone like Ron, knowing that there's a chance of making a mistake, would prefer to use tools that remove the risk of him making a mistake from the get-go.
"I haven't used LISP, but I do have experience with a functional language (OCaml). Praytell how do you permit multithreaded access local variables of a function without severely destroying things?
...}
... } /* under some circumstances, the body finishes.
... spawner();
... x ...))
... x ...)
See below.
"Stack variables" in C are variables local to the function (and parameters). To access the local variables within another thread you'd have to perform some very specific kludges to obtain a reference into another thread's stack..."
Actually, I think the problem is that it is very easy for a C++ programmer to get ahold of a pointer to stack-allocated data. No special tricks are required. I suspect this is how their program was (from reading the article carefully):
void period_writer(char *p){
void spawner(){
char[BIG_ARRAY_SIZE] x;
spawn(periodic_writer, x);
for(;;){
}
main(){
wait_for_all_threads_to_finish();
}
In this case, there are two threads -- the initial one that calls spawner and the one that gets spawned to run period_writer. Periodic_writer receives the pointer to the data to periodically write out.
Everything works, unless spawner exits too early, deallocating the buffer shared between the two threads. It isn't at all hard for spawner to pass the stack-allocated data to the thread, making it very easy to make this error -- no specific kludges are required.
To do it in a LISP (or just Scheme) with threads:
(let ((x (make-vector size)))
(spawn (lambda ()
X won't get deallocated prematurely in a multi-threaded implementation.
"If I understand your language correctly, what I understand to be happening in their C++ multithreaded system was bluntly impossible to do in LISP. You can't have the problem, because you can't solve it that way.
Right -- you can't solve it in such a risky fashion. And if you do something bad, the GC will keep around the data -- it won't allow some other thread to write in to the space. And in the event one thread writes some crap there that the other thread isn't expecting, you'll likely get a type error and the system will halt -- it won't just proceed blindly ahead with garbage.
The only way I can think to duplicate the error is if you allocated some bytes and treated them as untyped bytes, arranged to store/retrieve data in the untyped bytes, implemented a stack and duplicated the concurrency error in the C program. The nature of the language is such that you can't screw yourself if you do the normal thing, which is just to use lexical scoping to share the variable.
The typical C++ solution is to use shared globals and accurately protect them. I suppose there could be a kludge workaround to what I'm saying, but the general point I was making was that it's a kludge in C/C++ too. Trying something like that in a multithreaded LISP environment isn't something on my todo list, however."
Actually, they said they stored the shared data on the stack, as in my example. As long as you know that the thread with the data on the stack will always exit after any uses, that's going to work, and it isn't kludgey. As for it not being on your todo list, if you've got a lisp available, it won't be more than a few lines -- it isn't nearly as bothersome as the C++ version.
But hopefully this one case shows you why Ron was of the opinion that he could get work done around 10x faster with LISP than C++. Tracking down the bug probably cost them a lot of time and stress.
"According the blog, AdWords was written in Java, not C++. I didn't find the author said it's caused by race condition."
I guess you missed this:
Ron sez... oh wait, don't need that any more.
OK, time to wrap up this little soap opera.
The problem turned out to be something called a race condition, which is one of the most pernicious and difficult kinds of bugs to find. (Those of you who are technically savvy can skip to the end.)
Most modern server code is multi-threaded, which means that it does more than one computation at once. This is important because computers do more than just compute. They also store and retrieve information from hard disks, which are much, much slower than the computers. Every time the computer has to access the disk things come to a screeching halt. To give you some idea, most modern computers run at clock speed measured in gigahertz, or billions of cycles per second. The fastest hard disks have seek times (that is, the time it takes the drive to move the read/write head into the proper position) of several milliseconds. So a computer can perform tens of millions of computations in the time it takes a hard disk just to get into position to read or write data.
In order to keep things from bogging down, when one computation has to access the disk, it suspends itself, and another computation takes over. This way, one computer sort of "pretends" that it is really multiple computers all running at the same time, even though in reality what is happening is that one computer is just time-slicing lots of simultaneous computations.
The ad server, the machine that actually served up ads in response to search terms, ran multi-threaded code written in C++, which is more or less the industry standard nowadays for high-performance applications. C++ is byzantine, one of the most complex programming languages ever invented. I've been studying C++ off and on for ten years and I'm still far from being an expert. Its designers didn't really set out to make it that complicated, it just sort of accreted more and more cruft over the years until it turned into this hulking behemoth.
C++ has a lot of features, but one feature that it lacks that Lisp and Java have is automatic memory management. Lisp and Java (and most other modern programming langauges) use a technique called garbage collection to automatically figure out when a piece of memory is no longer being used and put it back in the pool of available memory. In C++ you have to do this manually.
Memory management in multi-threaded applications is one of the biggest challenges C++ programmers face. It's a nightmare. All kinds of techniques and protocols have been developed to help make the task easier, but none of them work very well. At the very least they all require a certain discipline on the part of the programmer that is very difficult to maintain. And for complex pieces of code that are being worked on by more than one person it is very, very hard to get it right.
What happened, it turned out, was this: the ad server kept a count of all the ads that it served, which it periodically wrote out to the database. (For those of you wondering what database we were using, it was MySQL, which leads to another story, but that will have to wait for another post.) It also had a feature where, if it was shut down for any reason, it would write out the final served ads count before it actually quit. The ad counts were stored in a block of memory that was stack allocated by one thread. The final ad counts were written out by code running in a different thread. So when the ad server was shut down, the first thread would exit and free up the memory holding the ad counts, which would then be reused by some other process, which would write essentially random data there. In the meantime, the thread writing out the final ad counts would still be reading that memory.
"Not that I have an axe to grind against LISP'ers, but I'm not sure how better memory management would have prevented one thread from accessing another's now defunct stack data aside from not allowing it in the first place."
The basic idea is that the programmer doesn't manage the memory, so that problem just can't occur. You aren't supposed to be able to tell where the storage is (heap, stack, etc).
Were there to be a problem, it would be the fault of the LISP implementor.
The implementation of lexical closures (a Common LISP feature) requires keeping around the free variables associated with a procedure. So the implementation has to be able to routinely and efficiently do the sort of thing that a C program can't do, due to how it stores things. If you have a multi-threaded lisp, and the implementation is correct, you simply can't have the problem that Ron ran into.
You'll see there's a lisper who left JPL because managers decided to follow "best practices" of industry and move to C++. This is despite the fact that programming a space mission isn't a "standard" problem -- it is, in fact, a problem that a language like LISP is excellently suited, because people can deal with unclear/dynamic requirements as a project evolves.
So he goes to Google because they have some LISP guys there (not using LISP -- just smart guys) -- and then he gets told to do the first Java project. And later he gets told that LISP is out of the question.
And in fact, he details how a race condition in the C++ memory management leads to them billing clients nonsense amounts -- a problem that simply couldn't happen if they'd used a language like LISP (or Java) -- because the GC wouldn't reclaim something if the thing was still in use.
So Google can yet be beat -- they are not perfect. Of course, that doesn't mean there is anyone to beat them, yet.
Isn't the main issue how to power the balls? They'll need energy to hop around, make measurements and communicate.
I don't think the ad hoc wireless network aspect of things is likely to be the hard part: if people can solve the power problems, Siemens, Sony, Panasonic, Toshiba and Philips will likely take care of the network/software part in the course of solving our more earthly problems.
E.g. a security system built of these would seem to have wide appeal.
Paul Graham has a new essay on this:
Does "Web 2.0" mean anything? Till recently I thought it didn't, but the truth turns out to be more complicated. Originally, yes, it was meaningless. Now it seems to have acquired a meaning.
He's resistant to buzzwords, so I found this interesting.
MIT is amazing!
I can't imagine anything else they could do to ensure that they'll get the very best from the entire world.
Do MIT alumni tend to donate money to the School? Berkeley students are notoriously cheap.
You are so refreshingly curmudgeonly!
I agree with your "podcasting" (in my book, "crapcasting") and "blog" assessment!
I recommend you get your degree from MIT, Berkeley, Stanford, etc.
People probably won't remember Tulane after a while, but those schools will still have engineering programs and a good reputation.
How will they decide what a rootkit is?
It looks like they'll have to err on the side of rejecting programs that just happen to look like rootkits. What would those be?
If the OS vendor wants to release a patch or extension, won't it look "evil" to the detector chip? It will be altering the OS -- so maybe it is a rootkit.
It seems like the marketing is running things here. With the trusted boot stuff that was a different story -- that has a good theoretical basis.
Carl Fogle seems like a really greasy bastard, promoting some schmaltzy Beatles memorabilia with an otherwise interesting cancer story.
Of course, the funny thing is that if he's misuing the PageRank of Slashdot, that increases the odds that geeks at Google will take note of what the greaseball Carl Fogle is doing, resulting in his sites getting bodyslammed in the future. That will hurt his business, and he won't be getting so much Geld when it is all over.
You can license ARM and PowerPC cores -- but they will probably get a bit cheaper if this one is available for free.
f pgas/virtex/virtex_ii_pro_fpgas/capabilities/power pc.htm
Right now Xilinx and Altera make user-configurable FPGA processors. Most of the processor is fixed, but you can encode what happens for special instructions. Here's one: http://www.xilinx.com/products/silicon_solutions/
Now if Sun is giving away the processor, there's no reason for you to pay more for a PowerPC-based design -- someone will make a "cheapo" FPGA-extendable UltraSPARC.
I'm guessing they aren't going to make noise about the fact that porn for the iPod is exploding. E.g. http://www.onthegox.com/index.php?a=70747&adtr
And that's just one site. There are tons.
It is hosed.
u nctionTypeReturned&search=(&ignoredRandomNumber=11 33805159922.7798 Line Number 2, Column 1:Warning: mysql_connect() [function.mysql-connect]: Can't connect to MySQL server on '127.0.0.1' (4) in /home/csourcesearch.net/include/php/GraphXML.php on line 309
I tried searching. Here's what I got:
XML Parsing Error: junk after document element Location: http://csourcesearch.net/performSearch.php?type=F
^
You are purposefully dense here, but for the purposes of others who will read this, I will explain.
As I mentioned already, the religious beliefs of Jews, for the most part don't matter.
When Bob Dylan (nee Zimmerman) was a holy-roller Christian, he was Jew going through a phase.
When Trotsky, the atheist communist Jew, played chess in Vienna with capitalists Jews in Vienna, all that mattered was that they were from the same tribe, not their religion. Had ideology or religion mattered to them, they wouldn't have associated with each other. On the other hand, it is unthinkable that someone like Donald Trump would socialize with a communist, just because the person shared his ethnicity -- because Donald cares about ideology.
Jacob Schiff, a rich capitalist Jew who hated goyische imperialist Russia, helped communist Jews to take over Imperialist Russia. Why would a capitalist help communists to topple a country? Because ideology didn't matter to him -- just ethnicity.
With Jews, ethnicity trumps religion. E.g. the Lubavitchers (how I love them) would have gladly taken all of the above-mentioned Jews in and rehabilitated them. All that matters is that they were all ethnic Jews. You wanna make aliyah? Go right ahead -- you just need to show that you've got a Jewish grandparent. Your religion is immaterial. You can be an anarchist or Stalinist and make aliyah -- no problem.
On the other hand, if a non-Jew wants to become a Lubavitcher, the Lubavitchers will do all that they can to dissuade the guy. He's not welcome. Because ethnically, he's not a Jew. And gentiles can forget about immigrating to Israel; that's just not allowed. Yeah, you can convert and immigrate -- but that's pretty tough, and life won't be fun after you've done it. And if one day all the Arabs get smart and decide to convert to Judaism (so that they can take over the country), you can bet Israel will change the rules to stop them. Although if a bunch of Arabs were to convert in order to immigrate, I'd argue that they are Talmudic enough and belong "in" -- that sort of creative problem solving should be encouraged.
Of course, religion matters when talking about "posses" that are competing. E.g. Satmars vs. Lubavitchers. But these differences don't matter much, especially if there's something to gain by cooperating against other "outsiders" -- e.g. securlar Jews or goyim.
Given that ethnicity is so important in human affairs, and to the extent that the ethnic stereotypes are rooted in factual observations, I feel my statements are reasonable, if perhaps politically incorrect. If you want me to stop pointing out that the facts fit the stereotypes, I suggest you somehow try to get people to act less stereotypically.
To all the folks who replied to my question: thanks for the info!
I had no idea that roads were essentially non-existent, and that India has a pretty good (and heavily subsidized) passenger rail system. If you really have no highways whatsoever, there probably is a huge relative advantage to having some, as opposed to having yet more rail.
Knowing how bad cars in the US are, I'm inclined to think -- well, could you maybe build more rail (more lines), just for freight -- and perhaps some express trains, for those folks with more money (and less time)?
But that's probably dumber than building a few freeways -- and I'm showing my anti-car biases.
As fuel prices rise in the US, there are a number of communities that will likely be depopulated -- the folks living there now commute to population centers for work, and those commutes will probably become too expensive in the future.