I don't remember from the site at the time what "monetization_box.php" would have been doing.
Also, my style of comments seem so tame and lame now :)
Facebook PHP Source Code from August 2007
61–70 of 154 posts
Re: Facebook PHP Source Code from August 2007
#62Earlier quoted context omitted.
It would seem that Facebook has been able to scale. Perhaps this line of code worked for them in 2007, and they changed it only when it started to be a problem.
It's probably still there and has probably never caused any problems. In other words I think iand is exaggerating.
It is certainly not still there given that facebook doesn't run PHP any more. They wrote a compiler to translate a subset of PHP to C++, which they then compiled into a massive executable. The compiler is open source and called hiphop, and it does not implement the PHP memory limits.
Re: Facebook PHP Source Code from August 2007
#63How did someone "expose the PHP source code"? Did they actually find a way to make the code show up client-side, or was it just someone who managed to get access to the backend stuff? The way it's worded makes it sound like the former, but that seems unlikely...
Sounds like it was an "accident". The web server served up the source code rather than compiling the PHP, which someone then saved.
Re: Facebook PHP Source Code from August 2007
#64Earlier quoted context omitted.
I can't think of a single reason a PHP script like this would need that much memory to serve a single user. Everything big would be handled by the database, what could 500MB possibly be used for?
They would be applying some search logic in memory in PHP. Depending on what you are doing it does make sense to load in a heap of data from the database then narrow it down in PHP.
That sounds grossly ineffective.
Reminds me of some production PHP I saw once, returned the entire database (`SELECT * from 'db'`) and manually walked through it with a for() loop. It wasn't very efficient at scale.
Re: Facebook PHP Source Code from August 2007
#65Does anyone else remember the friend graph visualization feature facebook used to have? It was an oddity, both because it seemed like a strange but useful feature, but also because it was a perl script. One time I clicked it and got the source code to the file instead of the graph. It's somewhere on one of my hard drives, but it seems wrong to leak, especially since it has database credentials hard-coded into it.
...do the credentials still work? :)
Re: Facebook PHP Source Code from August 2007
#66Earlier quoted context omitted.
A 100MB per request is going to seriously limit scalability (or inflate hardware costs at least)
It doesn't say it's 100MB per request, just that it's raised for safety in the rare case where it's actually needed. Would you prefer serving a 500 to that user instead?
Guess what happens when a lot of people search.
Re: Facebook PHP Source Code from August 2007
#67Earlier quoted context omitted.
My mantra: Shipped code > Well architected incomplete features. Your user does not care in the slightest if you're using a design pattern, or if you are using dependancy injection, or if there is 100% code coverage. Just make it work! Then make it faster! Then make it more readable! In that order.
That approach only works in the short-term though. When you've got an already large code-base you just 'made work' but with no tests (code-coverage), how do you 'make it faster' or 'make it readable' without breaking things? Especially as you are likely under pressure to be adding new features.
By being careful?
I'm all for tests but tests aren't the ONLY way to write software that you can modify without "breaking things." It does require more time to develop and test, but then again, you're saving some time by not writing and maintaing tests.
Again, I believe in automated testing because I think it hedges my risk but I'd caution against believing your own hype that there is only one way to do something..
Re: Facebook PHP Source Code from August 2007
#68How did someone "expose the PHP source code"? Did they actually find a way to make the code show up client-side, or was it just someone who managed to get access to the backend stuff? The way it's worded makes it sound like the former, but that seems unlikely...
I think it was a glitch in Apache that made it spill out the sourcecode
Re: Facebook PHP Source Code from August 2007
#69Earlier quoted context omitted.
They would be applying some search logic in memory in PHP. Depending on what you are doing it does make sense to load in a heap of data from the database then narrow it down in PHP.
That sounds grossly ineffective. Reminds me of some production PHP I saw once, returned the entire database (`SELECT * from 'db'`) and manually walked through it with a for() loop. It wasn't very efficient at scale.
Yeah, you're right... It's way better to do expensive joins on the database where horizontal scalability is just a fantasy than in the shared-nothing www frontends that can be duplicated in clusters ad infinitum.
If you're building SomeSimpleBasicSite.com and you do this, you're probably a bad programmer. If you're truly facing scalability problems, it's table stakes.
Based on your comments in this thread you're out of your depth, man.
Re: Facebook PHP Source Code from August 2007
#70Earlier quoted context omitted.
managed to save a copy of several files that appeared at the time - home.php, album, group, friends, photo, profile, readmessage ... code was an interesting read, as were the comments in it: // You fucking link h4x0rs just got pwned // Shortcut out of this CRAZY expensive garbonzle // What did we come up with? // don't display the Tuna album (aid=-1) // is this group a dummy meant to populate newsfeeds? // do not lis…
Can anyone explain the strange obsession with tuna? Even in this index.php: // make sure big tunas haven't moved around
I am going to guess one of their test environment has an album with pictures of Tunas.