My blog post is direct and to the point. There's honestly no mystery about this, I laid out all the details, possibly excepting one.

We designed our infrastructure offering 3 years ago. We knew that the vast majority of websites would produce nearly read-only file I/O. GFS's less than stellar write performance isn't a problem in that typical case.

Along comes Github, and they have an entirely different disk I/O profile to the rest of our customers. Github was built on a shared-something architecture because GFS made it quick and easy to get up and running, developing features, and attracting users. This is a good thing!

Github has been very vocal about their dislike of the GFS filesystem we use for shared filesystem access. GFS doesn't scale forever, and we've never suggested it does. It could scale far larger than it has at Github, but fizx hit the nail on the head: we weren't willing to do it for free, and Github was unwilling to pay our price.

We warned Github many, many moons ago that given their growth rate, in order to scale their application smoothly and inexpensively, a shared-nothing architecture was eventually going to be needed. We offered to help them with that architecture, as we saw Github running wonderfully atop a cloud service such as EC2.

Rather than do the re-architecture now, they've chosen instead to move to a vendor who can provide them a high performance, high availability, non-commodity, proprietary network file server infrastructure. I suspect it will work well for them, and we'll all enjoy a faster Github. :-)

From my perspective, I really want everyone to understand that there's no bad blood on the EY side, and hopefully none on the Github side. Business is business, decisions need to be made each and every day.

On an unrelated note, why request a comment from a company at all if you're only going to wait 24 minutes for a response?

And it was more of a surprise when my mobile phone rang and a Scottish man said "Hello John. It's Gordon Brown."

It sounds odd Engine Yard hosts an entire for-profit company for free just in exchange for some complimentary accounts.

My imagination tells me GitHub is tired of being slow and Engine Yard couldn't do anything more to help them. Instead of the news being "GitHub Leaves Engine Yard Because It's Too Slow" the news is "Engine Yard Kicks GitHub To The Curb Because GitHub has Non-Ruby Repos."

I don't see either headline being positive towards Engine Yard.

Anyway there seems to be plenty of airchair quarterback on this one. The real story is that we can't afford to host them for free anymore.

GitHub has been working on a re-architecture since our last major feature release, which was GitHub Issues in April.

And we can't wait to roll it out.

http://www.techcrunch.com/2009/09/10/yeah-ok-so-facebook-pun...

Great study in knee-jerk reactions

Thankfully (for the authors and publishers), for some of us, that is reversed. The phrasing can be different.

"Tell me how and why you created a new language, and I am interested. Tell me how hard work and determination is how you made your money and the key to success for the rest of us and I lose interest"

EDIT: Ok I am reading the pdf version now and it is VERY enjoyable.

from the first chapter/interview

"Seibel: What about XScreenSaver—do you still work on that? Zawinski: I still write new screen savers every now and then just for kicks, and that’s all C.

Seibel: Do you use some kind of IDE for that?

Zawinski: I just use Emacs, mostly. Though recently, I ported XScreenSaver to OS X. The way I did that was I reimplemented Xlib in terms of Cocoa, the Mac graphics substrate, so I wouldn’t have to change the source code of all the screen savers. They’re still making X calls but I implemented the back end for each of those. And that was in Objective C, which actually is a pretty nice language. I enjoyed doing that. It definitely feels Java-like in the good ways but it also feels like C. Because it’s essentially C, you can still link directly with C code and just call the functions and not have to bend over backwards."

............................................

"Seibel: Six or seven being the whole Netscape development team or the Unix development team?

Zawinski: That was the whole client team. There were also the server folks who were implementing their fork of Apache, basically. We didn’t talk to them much because we were busy. We had lunch with them, but that was it. So we figured out what we wanted to be in the thing and we divided up the work so that there were, I guess, no more than two people working on any part of the project. I was doing the Unix side and Lou Montulli did most of back-end network stuff. And Eric Bina was doing layout and Jon Mittelhauser and Chris Houck were doing the Windows front end and Aleks Toti and Mark Lanett were doing the Mac front end for the pre–version 1.0 team. Those teams grew a little bit after that. But we’d have our meetings and then go back to our cubicles and be heads-down for 16 hours trying to make something work.

" ...........................................

"They thought just by virtue of being here, they were bound for glory doing it their way. But when they were doing it their way, at their company, they failed. So when the people who had been successful said to them, “Look, really, don’t use C++; don’t use threads,” they said, “What are you talking about? You don’t know anything.” Well, it was decisions like not using C++ and not using threads that made us ship the product on time. The other big thing was we always shipped all platforms simultaneously; that was another thing they thought was just stupid. “Oh, 90 percent of people are using Windows, so we’ll focus on the Windows side of things and then we’ll port it later.” Which is what many other failed companies have done. If you’re trying to ship a cross-platform product, history really shows that’s how you don’t do it. If you want it to really be cross-platform, you have to do them simultaneously. The porting thing results in a crappy product on the second platform.

They didn’t start from scratch with a blank disk but they eventually replaced every line of code. And they used C++ from the beginning. Which I fought against so hard and, dammit, I was right. It bloated everything;

"

...........................................

there's lots of interesting anecdotes and insights about his work with Peter Norvig at Berkeley, with Lucid and at Netscape and how he learned lisp and how he hates perl but uses it anyway and the hardest bug he ever encountered ( real doozy but i won't spoil the surprise for you) and so on .. And that's just Chapter 1.

I must be weird but I really enjoy reading stuff like that.

Matt Harwood: I call hoax. There is zero way Facebook would even consider this, nor use that god awful over-sized icon.

Jason Kincaid: It’s not a hoax, I’m seeing it when I browse photo albums. Might now be rolled out for everyone yet.