How many lines is duckduckgo? :-)
Google Is 2B Lines of Code, All in One Place
291–300 of 347 posts
Re: Google Is 2B Lines of Code, All in One Place
#292Earlier quoted context omitted.
Many larger external projects are hosted in other repositories (Chrome and Android are well-known examples). Smaller stuff (like, say, tcmalloc or protocol buffers) is usually hosted in Piper and then mirrored (sometimes bidirectionally) to an external repository (usually GitHub these days).
Thanks, but I guess I was asking more about how this affects the other development characteristics described. You still have to deal with the massive repository and infrastructure, but if you're Go, for example, and you want to change an API 1) you can't see the consumers because many or most won't be Google-internal, and 2) even if you could see them, you can't change them. Even the build/test/deploy systems are som…
Working with multiple source control systems, multiple issue trackers, and multiple build systems has its challenges.
It's true that you don't know about all callers if you're working on open source software. There's no magic there; you need to think about backward compatibility. (On the other hand, if it's a library, your open source users can usually choose to delay upgrading until they're ready, so you can deprecate things.)
The main advantage for an open source project is that, though you don't know about all callers, you still have a pretty large (though biased) sample of them. If you want to know how people typically use your API's, it's pretty useful. Running all the internal tests (not just your own, but other people's apps and libraries) will find bugs that you wouldn't find otherwise.
There were changes I wouldn't have been confident making to GWT without those tests, and bugs that open source users never saw in stable releases because of them. On the other hand, there were also changes I didn't make at all because I couldn't figure out how to safely upgrade Google, or it didn't seem worth it.
Re: Google Is 2B Lines of Code, All in One Place
#293How many lines is duckduckgo? :-)
Can't be that many, given they outsource the actual search engine to third parties.
Re: Google Is 2B Lines of Code, All in One Place
#294Earlier quoted context omitted.
I'd have to disagree with this. First the baseline: windows is very slow. Second I found later versions slower. Third (and most maddening) every version of windows I've ever used has gotten slower over time (including not installing new s/w and defragmenting).
Windows is slow? Compared to what? In what task? Running a game? Boot time? Opening Firefox? I have problems with Windows, but it's the fastest desktop os I think, mostly because it's graphics stack is way the best of all. Running a number crunching C code is exactly the same on Windows or Linux. (See all the benchmarks on the Internet.)
> Windows is slow? Compared to what? In what task?
I dual booted a laptop for a while with Vista. (I can't speak to anything later, because I use Linux now, and haven't looked back, so take the appropriate grain of salt.) So with Vista / Gentoo on exactly the same hardware (a Lenovo T61):
- boot time on Linux was orders of magnitude faster
- WiFi AP connect was significantly faster[1], esp. on resuming from suspend-to-RAM
- Windows had a tendency to swap things out if they weren't in use, and had to swap like crazy if you paged back to a program you hadn't used in a while; Linux, by comparison, will only swap if required to due to memory pressure.
[1] i.e., WiFi was reconnected before I could unlock the screen. No other OS I've had has been able to do this, and it's bliss.
> mostly because it's graphics stack is way the best of all.
Riiiight. The T61 had an nvidia in it, and it was fairly decent; drivers were decent between the two OSs, and performance on each was about on par with the other. (I used the proprietary drivers; nouveau performed unacceptably bad — bear in mind this was 7 years ago.)
> Running a number crunching C code is exactly the same on Windows or Linux. (See all the benchmarks on the Internet.)
This I will agree with; but what do you do after the number crunching? It's the scaffolding around the program that mattered to me: Linux has a real shell, with real tools. I can accomplish the odd task here or there. But yes, running a "number crunching C code" will perform about equally: you're really only testing the processor, maybe the memory — crucially, the hardware, not the OS.
Re: Google Is 2B Lines of Code, All in One Place
#295Earlier quoted context omitted.
I can't say. I work here, but I don't speak for the company.
Wouldn't it be nice if by working there you felt empowered to speak for the company? The company is you and your colleagues.
I'd bet he has a lot of colleagues more qualified to question what he cares to reveal about their collective private intellectual property than you
Re: Google Is 2B Lines of Code, All in One Place
#296Earlier quoted context omitted.
> the numbers Wired quotes for the lines of code in Windows are not even close to being correct OTOH you can't blame them for being incorrect if you (as in, Microsoft, not you personally) are being so secretive about the figures. I'm pretty sure everyone would love to see how Microsoft works internally, especially now that you teased us with that Windows build system.
Yes you can blame them for being incorrect. If they don't have a correct and relatively up-to-date figure, they should be clear about that. "Microsoft declined to comment on how many lines of code Windows has now" or "Windows XP used 45 million lines of code, but that was 14 years ago so it's not a very good comparison to anything".
They're not only incorrect but also stating facts out of context. Furthermore, Microsoft doesn't have any obligation to expose their real numbers if they don't want to.
If it's ever needed to cite numbers, at least tell what the context is instead of naming some number out of the blue from 15 years ago and assuming it's still the same windows
Re: Google Is 2B Lines of Code, All in One Place
#297Earlier quoted context omitted.
Note: windows programmer for 19 years now. Only because of the cash. You know why there's cash? Because Windows works for a lot of people.
I disagree. It isn't that it works well but merely that it is there. In fact the majority of Windows networks both corporate and small business I can safely say that it barely works and is usually a mismanaged unpatched mess or filled with crapware. Occasionally there's a nice tight network (our operations guys run a tight ship which is cool) but the general case is a pit of incompetence. The mantra among the consult…
In fact the majority of Windows networks both corporate and small business I can safely say that it barely works and is usually a mismanaged unpatched mess or filled with crapware.
You literally cannot manage SSO, patching, and config management on a non-Windows environment for more than a few hundred machine without the right tools. Shell scripts and Chef aren't going to cut it when you have 20,000 laptops to take care of.
Re: Google Is 2B Lines of Code, All in One Place
#298With 2 billion lines of code I would consider the problem of developers stepping on each other's toes essentially solved.
Re: Google Is 2B Lines of Code, All in One Place
#299Earlier quoted context omitted.
Every feature has a flag that you can turn on/off to your heart content. Releases are cut at head. No need to use the version control hammer to screw all the zippers.
Would that be analogous to, every feature is it's own git branch? and you choose which branches to merge when building? How are conflicts managed?
No, features are configurable at runtime. This allows A/B testing or slowly rolling out a new feature. Depending on the type of change, you might test it on 1% of users, 1% of servers, etc.
Re: Google Is 2B Lines of Code, All in One Place
#300Earlier quoted context omitted.
Many larger external projects are hosted in other repositories (Chrome and Android are well-known examples). Smaller stuff (like, say, tcmalloc or protocol buffers) is usually hosted in Piper and then mirrored (sometimes bidirectionally) to an external repository (usually GitHub these days).
Thanks, but I guess I was asking more about how this affects the other development characteristics described. You still have to deal with the massive repository and infrastructure, but if you're Go, for example, and you want to change an API 1) you can't see the consumers because many or most won't be Google-internal, and 2) even if you could see them, you can't change them. Even the build/test/deploy systems are som…
I've read that in the case of Go, Googlers develop in the public repo of Go, which is periodically synced back into the Google tree.
You can definitely see that Google uses a completely different build system than mainstream Go by the state of the mainstream Go build system though.