| |||||||||||||
|
| |||||||||||||
If you mean "largest monolithic piece of code" then yesIf you mean "largest monolithic piece of code" then yesPosted Sep 2, 2008 17:16 UTC (Tue) by khim (subscriber, #9252)In reply to: The Google Chrome comic book by njs Parent article: The Google Chrome comic book
There are over 100 different libraries open-sourced by Google (and don't forget about SoC) so and I think they all combined are bigger then Chrome codebase, but yes, it's probably the largest monolithic piece of code ever open-sourced by Google (though Android probably rival that - but it's not open-source... yet).
(Log in to post comments)
If you mean "largest monolithic piece of code" then yes Posted Sep 3, 2008 5:11 UTC (Wed) by njs (subscriber, #40338) [Link]
Basically I mean "largest potential development community" -- the vast majority of Google code releases are API demos, little libraries written by 1 or 2 people, etc. You know, the sort of code that doesn't attract much external development whether it came from Google or just got posted on SourceForge. (And SoC is irrelevant, since the whole motivation for how it's put together is that Google didn't want to get into the business of building development communities, they wanted to leverage the existing experts, i.e. FOSS projects.)
Chrome OTOH has both a large and active team inside Google, and is likely to attract a large number of interested developers, so it seems to create a new challenge for them -- can they build a viable community of external contributors, and collaborate effectively with them?
And yeah, Android will be interesting to watch in this regard as well.
(...WTH did Google reimplement nscd? http://code.google.com/p/gnscd)
If you mean "largest monolithic piece of code" then yes Posted Sep 4, 2008 19:28 UTC (Thu) by pphaneuf (subscriber, #23480) [Link] Have you looked at nscd? ;-)
If you mean "largest monolithic piece of code" then yes Posted Sep 4, 2008 23:23 UTC (Thu) by nix (subscriber, #2304) [Link]
I've looked at glibc nscd. Neat, fast, efficient, config file format and
means of operation entirely undocumented (who needs network serialization when you can just shared-mmap() sparse files and read directly from the deserialized representation of the service files).
It's enormously more efficient than the Solaris ncsd used to be back in
|
|
||||||||||||