Google Chrome: the Making of a Cross-Platform Browser
JG: In a nutshell, what inspired Google to create Chrome and how did it come about?
LJ: What is the Google Chromium Project?
EM: After we wrote the code for Google Chrome, we open sourced it under the name Chromium. Much like Firefox is a trademark of Mozilla, Google Chrome is a trademark of Google; the name Chromium is not, so distributions are free to use it to refer to the same project. We hope that developers and browser vendors take a look at the Chromium source code and that it will be useful for new projects built by the Open Source community in the future.
JG: This being our cross-platform development issue, we're curious to explore the challenges and innovations in that area. What have been the major issues in making Chrome great on all of its platforms?
EM: Much of the challenges we've encountered on Linux stem from how heterogeneous the user base is—which, surely, is also the strength of Linux. This ranges from how to port simple UI decisions (Chrome's shade of blue was chosen to look good next to the blue seen on every Windows computer), to getting boring technical details (a binary built on Ubuntu won't work on a Fedora machine), to real problems that will require engineering work to solve.
One good example of the latter is adapting our sandboxing model for Linux. Getting a process sandboxed in a way that's useful to us is challenging on Windows, with the relevant source code consisting of more than 100 files, but it needed to be implemented only once to work everywhere. On Linux, there are a variety of easier-to-use but different sandboxing systems available, and different Linux distributions ship with different (or no) sandboxing APIs. Here's an article about a kernel patch we've proposed for discussion toward that end: lwn.net/Articles/332974.
JG: What innovations does Chrome bring to browsing?
JG: Can you tell us more about V8, its history, your rationale for developing it and who the key people were behind it?
JG: What innovations and new approaches does V8 bring to the browser?
JG: What language(s) is Chrome/V8 written in?
JG: What platforms does V8 support?
MA: V8 runs on Windows, Linux and Mac.
MA: V8 supports IA32 and ARM.
JG: Are there plans to extend it to other CPU architectures?
MA: We are working on a 64-bit version.
JG: Is the code generation better on some architectures than others?
MA: There are different trade-offs for the different architectures, and we try to make the code generators as good as we can for the different architectures. The code generator for IA32 does register allocation and does more inlining than the code generator on ARM. In general, the IA32 code generator has been tuned more than the ARM one.
JG: Did you name it after the internal combustion engine or the vegetable drink?
MA: The internal combustion engine. It was developed in the context of Google Chrome, and we thought that there should be a powerful V8 engine under the “chrome”.
We think that numerous open-source projects are good for the entire space because they allow developers to make advances and share them quickly. We continue to have a great relationship with Mozilla, and many of our engineers actively work on features in Firefox through Mozilla's public participation process.
JG: What can you tell us about the status, road map and challenges regarding the Linux version? We're salivating here.
EM: The Developer version is available for a few Linux distributions already. Although this is an early release and not ready for your average user, we hope you get an idea of what Google Chrome for Linux will be like and keep following our development in the open as we make progress on a beta and stable version.
JG: How many developers in how many locations are dedicated to Chrome development, and how many solely to the Linux version?
EM: Although we don't go into details about the number of Google employees on any particular product, we have a core team of engineers who are working hard to get the Linux build of Google Chrome up and running. As a team, to prevent fragmentation, we try to have all developers work on all platforms—I refactor code on Windows to make it work on Linux, and if someone on the Mac team breaks the Linux build, it's his or her responsibility to fix it. Pieces like the networking stack can be worked on from any platform, so developers can just pick their preference.
At one point, I counted Google developers contributing from more than a dozen different locations (some work from their homes); we have even more once you count the contributions we receive from other developers. One of my favorite experiences of this project has been filing a bug one evening, then waking up the next day to see a patch to fix it from someone in Europe.
We've also received many patches from outside of Google, and have even promoted some of our best contributors to committers themselves.
JG: Was there a specific Google application that prompted Google to decide it needed a bigger/faster browser?
EM: I think of Google Chrome as being less about making Google applications faster and more about making the Web as a whole faster.
JG: What toolkits are used to build Chrome? And, are there any interesting issues regarding tools worth mentioning?
EM: Google Chrome on Linux relies on a ton of free software—about:credits lists more than 15 subprojects we include source from—as well as standard system libraries like FreeType, NSS (the Mozilla SSL/TLS implementation) and GTK+. There has been a lot of discussion on-line over toolkit choice; it was surprisingly uncontroversial within the team to choose the one that Firefox and Flash depend on and that we had more experience with. I think other options would have been just as good, and I would, in particular, love to see someone knowledgeable about Qt contribute patches.
Regarding tools, I'd like to especially call out gold, the fast linker that is little known but has been a lifesaver for us.
JG: How has the development of Google Chrome for Linux been going? Can you share some ups and downs you've experienced so far?
EM: I run only Linux at home. For me personally, the biggest up was after working on Windows for so long, to be able to install and use it finally myself.
JG: Is there a tentative date for when a beta release will be ready for Linux?
EM: Not yet, but we're working hard on it. You can track our progress on Linux development by running the in-progress version available at dev.chromium.org/getting-involved/dev-channel or via the mailing lists and source found on the Chromium developer site at chromium.org.
JG: Will the Linux and Mac OS versions one day catch up with and enjoy equal functionality with the Windows release?
EM: Yes, it is one of our highest priorities right now.
JG: Thanks to you both for your fascinating insights on Google Chrome!
James Gray is Linux Journal Products Editor and a graduate student in environmental sciences and management at Michigan State University. A Linux enthusiast since the mid-1990s, he currently resides in Lansing, Michigan, with his wife and cats.
James Gray is Products Editor for Linux Journal
Free DevOps eBooks, Videos, and more!
Regardless of where you are in your DevOps process, Linux Journal can help!
We offer here the DEFINITIVE DevOps for Dummies, a mobile Application Development Primer, and advice & help from the expert sources like:
- Linux Journal
Web Development News
- High-Availability Storage with HA-LVM
- DNSMasq, the Pint-Sized Super Dæmon!
- March 2015 Issue of Linux Journal: System Administration
- Localhost DNS Cache
- Real-Time Rogue Wireless Access Point Detection with the Raspberry Pi
- Days Between Dates: the Counting
- The Usability of GNOME
- PostgreSQL, the NoSQL Database
- Linux for Astronomers
- You're the Boss with UBOS