Other Unixes

March 25, 2010

Various people interested in running Chrome on non-Linux unixes have sniffed around the project and eventually someone stepped up: there's a FreeBSD port that seems to work for some people. (I notice they've recently updated their page to ask for money; I'll note it seems pretty legit to me, since I have firsthand experience to tell you that author has put a lot of time into it.)

But dumping a multi-hundred-kb patch file is not enough to consider a product ported -- all of the code ought to land the upstream Chrome tree, and quickly since it will rot quickly. This burden has fallen instead to an enthusiastic OpenBSD developer, who has taken the FreeBSD patch and started on this perhaps larger task: tediously splitting the patch up into bite-sized reviewable chunks, and then modifying each through the code review process (frequently resulting in larger changes than the original port). I feel like I've looked at twenty patches from him so far and more come every week.

Not to be left behind, recently I've also been seeing and reviewing patches from someone working on getting things to run on Solaris, though my perception is that it is much farther from working. Had I time to get multiple interns perhaps I'd have allocated some to these projects; in retrospect they also would've been good summer of code projects.


Porting from Linux in theory shouldn't be too much harder than just recompiling, but practice is practice because it differs from theory. The bulk of the patches just extend the ifdefs and build rules to add the new platforms. When we only had three platforms to worry about, we didn't go to much effort to make a distinction between Linux-specific bits, marked with OS_LINUX, and "stuff that generally is used on free Unix-like operating systems", such as making dotfiles in your home directory, X11 clipboard behaviors, or GTK.

For the decent amount of code we do share between Linux and the Mac (e.g., the IPC subsystems between Mac and Linux are nearly identical, and implemented in terms of Unix domain sockets) there is a shared OS_POSIX define already in use, but there is also some code that is Linux-specific; it's a waste of time to try to anticipate in advance the right layer for abstractions (like, say, how we currently find our binary path by looking in /proc). The majority of the shared code, however, is in bits like GTK that are going to be literally identical across Linux/*BSD/Solaris and perhaps others.

The initial temptation was to make some sort of OS_UNIX_THAT_ISNT_MACOSX define. But nobody could come up with a good way to describe what that actually means, and instead we now we have a larger set of feature-related defines, like TOOLKIT_GTK (that is, the UI is implemented matching the GNOME interface guidelines), USE_X11 (necessary for all of our backing store tricks), and even USE_NSS (the crypto library used for SSL). The last one is especially a victory of generalization done by porters because it turns out for various reasons we're moving towards using NSS on Windows, and to bring that previously Linux-specific code up on Windows mostly involved flipping a few defines.

With that said, there's kind of an endless long tail of configurations that will get progressively harder and harder to support -- even Linux at all is something like 1% of our user base, and I imagine the BSDs are 1% of that. I expect in the longer term, it will probably be the case that these ports will work like the FreeBSD one, where they get a working tree snapshot going every few months without consistently-working code in the interim. But on the other hand, free software means that if someone wants to run our code on NetBSD, they just need to step up with their editor.