It's not meant to be a competitor to JSTOR, as much as this is a statement in honor of someone.
A framework like that would be awesome, but that has a different meaning from the collection of personal pdf posts/uploads each individual on Twitter contributed.
For someone who has been working on OA and scholarly publications for a few years, it's a bit tricky to enter these kinds of debates. On the one hand, I want to respect Aaron's legacy, and am very touched by the spontaneous and organized moves to honor him. On the other hand, I am very interested in these issues, and love discussing them, seeing how we can do things better.
For smogzer, there is some interesting research on how knowledge from the research literature can be better represented. For example using concept mapping, see this great paper by Simon Buckingham-Shum (who has many others): http://oro.open.ac.uk/6463/1/kmi-04-28.pdf. Anita de Waard has given many presentations on semantic and executable papers, for example http://www.slideshare.net/anitawaard/executing-the-research-....
Wikpedia has one paragraph at http://en.wikipedia.org/wiki/WebKit#Origins "However, the exchange of code patches between the two branches of KHTML has previously been difficult and the code base diverged because both projects had different approaches in coding."
I can't comment on the state of things today, but I was active an active KDE core developer at the time from that original message to the time of the Zack's blog post (and I'm friends with both Dirk and Zack):
There was a huge amount of excitement at the announcement that Safari would be using KHTML. At that time, it was almost a given that the OSS rendering engine was Gecko. KHTML was KDE's little engine that could. But nobody ever expected it to be picked up by other folks. One of the original parts of the KHTML-to-OS X port was KWQ (pronounced, "quack") that abstracted out the KDE API portions that were used in KHTML.
Folks were pretty ecstatic at first. It seemed very validating.
But that changed quickly. As Zack's post indicates, WebKit became a thing of unmergable code-drops. Even inside of the KDE community there became a split between the KHTML purists and the WebKit faction. They'd previously more or less all been KHTML developers, but post-WebKit there was something of a pragmatists vs. idealists split. Zack fell on the latter side of that (for understandable reasons: there was an existing community project, with its own set of values, and that was hijacked to a large extent by WebKit).
A few years later WebKit transformed itself into a more or less valid open source project (see webkit.org), but that didn't close the rift in the KDE community between the two, at that point rather divergent, rendering engines. There's still some remaining melancholy that stems from that initial hope and what could have potentially been, but wasn't.
It's hard to argue that WebKit being open source has been a bad thing -- in fact, I don't believe that in the slightest. But I can also understand that it's pretty head-turning to have have a project transform in that way, especially for the original contributors (though, it should be noted, the original author of KHTML, who wasn't really active at the time of the transition, did eventually fall into the WebKit camp).
Final note: this is just my somewhat fractured recollection of things from being in KDE community. My contributions to KHTML / WebKit were very minor (the original spellchecking support) so this may not jive completely with the folks that were closer.
This matches my recollection of things as someone that followed WebKit from shortly after Safari was announced, and became actively involved when the open source project proper started up in 2005.
I have reread the comments, rechecked the current state of ruby code, and have an impression that might answer came off as ambiguous.
1. This commit changed two things: default file mode of open logs is no more sync in production (i.e. it is not automatically flushed by ruby write routines) AND it doesn't buffer log entries anymore (which is actually funny, since, you know, it is called ActiveSupport::BufferedLogger)
2. When IO#sync is false, which was the case, ruby didn't flush upon every write. That manifested itself in logfile entries not appearing immediately after write.
2.1. In some 3.2 release they've reversed that, so sync = true is by default in all latest versions of rails.
3. Since logger doesn't buffer requests anymore, the problem of interleaving messages should still be there, sorry for confusion.
3.1. To solve this, you can either use tag features of recent rails or port older buffered logger itself.
Are we seriously considering otherwise? Obviously the PR department managed it. Obama seems pretty lighthearted, so he has a bit of leeway in responding wittily, but much of it has to be planned.
They're not meant to do anything other than exist. It's used as a low end way to make a PC actually have a graphics card, you know, that can display Microsoft Word prettily enough with Aero. That's what Intel cards started out as.
Moving forward, they're giving the cards enough power to help render movie times, playing games such as League of Legends casually at low (think 1366 by 768, not 1080p) resolutions and medium settings, etc that can satisfy 90% of user needs.
Maybe in a few years Intel will make their own graphics cards that can compare in power to current Nvidia and ATI cards. Until then, these cards serve as cheap stuff that can be found on every computer.
That's the worst MBA vs Real life thinking ever. I hope the actual investors aren't nearsighted enough to think that kicking Zuck out will make facebook's stock value improve. As much as everyone loves to hate on facebook, it's not going anywhere without him.
A framework like that would be awesome, but that has a different meaning from the collection of personal pdf posts/uploads each individual on Twitter contributed.