Harsh Words From Google On Linux Development

jeevesbond writes "The alpha version of Google Chrome is now available for GNU/Linux. Google Chrome developer and former Firefox lead Ben Goodger has some problems with the platform though. His complaints range from the lack of a standardised UI toolkit, inconsistencies across applications, the lack of a unified and comprehensive HIG, to GTK not being a very compelling toolkit. With Adobe getting twitchy about the glibc fork and previously describing the various audio systems as welcome to the jungle, is it time to concentrate on consolidation and standardisation in GNU/Linux in general, and the desktop in particular?"

Comments

RTFA, they did

[Kupfernigk]

After extensive discussion, the Chromium developers decided to build the Linux port with GTK+, the toolkit that is used by the popular GNOME desktop environment

They argue, and I would not say that they are wrong, that GTK+ even so does not give the necessary functionality to allow all the Chrome features.

Re:No Link to Actual Content

[K. S. Kyosuke]

I will squirt it up for you: here. Alternatively, you could have binged it.

Article by Slashdot completely distorts reality

[Anonymous Coward]

Follow the discussion, and you'll find it's not about complaints at all, at all, at all. Google is trying to figure out the best way to do Chrome for Linux, while making it something that Linux users will actually like, and that means more choices. That's all. No, it's not about needing to standardize, so could someone at Slashdot quit with that FUD? GNU/Linux is about choice, and it always will be.

RTFA

[jipn4]

What is really going on is that they have wrapped a new layout engine ("views") and other tools around the "impoverished" (their words) Windows toolkits. Then, they started depending on their wrapper for features they added to Chrome. Now, when porting to Linux, they are suddenly discovering that, geez, both Gtk+ and Qt already does what "views" is doing, they just do it differently and in a way that doesn't connect well with the rest of Chrome. That's what they are complaining about.

Ben Goodger, here's a hint: pick Gtk+ or Qt as your toolkit, Linux users really don't care that much. And both of them are much better toolkits than what Windows offers. I'm sorry that the completeness of Linux GUI toolkits inconveniences you, but, well, too bad.

Or, if you like, don't port to Linux; we don't really care all that much, since there are several great browsers on Linux already that pretty much do what Chrome does.

Re:Yes!

[Enderandrew]

If only the Linux Standard Base existed! Oh, wait, it does!

http://www.linuxfoundation.org/collaborate/workgroups/lsb

That is why Skype can build a distro-agnostic package with static linked libraries that just works on every distro, even though they also make distro-specific packages as well.

Re:To "Anonymous Coward"

[pizzach]

My wishes:
While I don't mind gtk, I am really hoping gnome3 brings some good changes to it. One of the big things I wish for is more free functionally for base widgets. Things like spell checking for more elements, auto-connecting default actions for cut-copy-paste menues, user toolbar editing, etc. It's pure busy work.

My what the hells
Why do some programs only have a quit menu and some only have a close (epiphany)? Why does the quit quick-key not work if the focus is in a text-view? While I can do ctrl-q to quit firefox, I have to close all the documents in gedit to get ctrl-q to work. What is wrong with having both close and quit for most apps?

My what is going to happen?
I know they are working on a app driven interface over a window driven one (ala Mac OS X). You can tell just by looking at some of the preferences hidden in gconf, recent changes in gimp, and many others. What does this mean to the gtk developers and the future of their applications?

Re:Qt

[cygnusx]

> Chrome should have been built on top of Qt from day 1.

RTFA.

I sincerely wonder, why didn't you just use Qt for the UI from the
beginning? It blends very well with the native look&feel on each
platform, while still letting you implement the distinctive Chrome
features. Qt 4.5 will even have native look in GNOME.

Ben Goodger:

In general, we've avoided cross platform UI toolkits because while
they may offer what superficially appears to be a quick path to native
looking UI on a variety of target platforms, once you go a bit deeper
it turns out to be a bit more problematic. As Amanda says, your app
ends up "speaking with a foreign accent".

Our experience is that using these frameworks also limits what you can
do to a lowest common denominator subset of what's supported by that
framework on each platform. ...
The architecture of Chrome has converged over the past few
months on a solid separation of view from state, and this has given us
the flexibility to make these decisions and choose from the widest
range of alternatives.

Re:Yes

[Enderandrew]

He did call for it to be built on top of Qt, not KDE. I know better, and honestly can't tell you why I typed KDE instead of Qt.

Re:It's been time for YEARS

[jacksonj04]

A standardised API doesn't mean that there can only be one operating system, it just means there's a generally accepted way of making the operating system do what you want without having to alter your code for every different platform.

Re:it's why Windows took over in the first place

[Limerent Oil]

... that means binary compatibility must stop being broken from OS update to OS update.

It's simply the arrogance of Linux developers that have crippled Linux adoption.

IMHO, this is the biggest barrier that keeps commercial development out of Linux. Basically, the Linux philosophy assumes that all applications are open source, so it doesn't matter if the ABI changes with every point release of the kernel, since the distros can just recompile all their binaries when packaging. This philosophy is incompatible with the commercial software method of distributing apps as binary blobs.

Re:Use Qt....

[ultrabot]

No his problem is that QT has an execution loop which incompatible with the Chrome engine. What makes QT so cool for event driven programming is an event handler that can't be easily changed to match the event handler in Chrome.

Qt actually runs the glib event loop these days. You can easily verify this by kill -ABRT'ing a kde app and checking the core dump; this just in from kate:

#8 0xb5df874b in IA__g_poll (fds=0x9c225c8, nfds=6, timeout=25243) at /build/buildd/glib2.0-2.20.1/glib/gpoll.c:127
#9 0xb5deaf82 in g_main_context_iterate (context=0x9778e90, block=1, dispatch=1, self=0x9776f40) at /build/buildd/glib2.0-2.20.1/glib/gmain.c:2761
#10 0xb5deb268 in IA__g_main_context_iteration (context=0x9778e90, may_block=1) at /build/buildd/glib2.0-2.20.1/glib/gmain.c:2511
#11 0xb6a5f438 in QEventDispatcherGlib::processEvents (this=0x9763c68, flags={i = -1074473992}) at kernel/qeventdispatcher_glib.cpp:323

Re:Um....

[PeterBrett]

I mean if I am a hardware manufacturer it takes just three drivers if I want to support Windows past, present, and future with a binary driver. Four if I want to cover the niches. I just have my developers write a Win98/ME, A win2k/XP, and a Vista/Win7. I add a WinXP64/Vista64 and since Win7 can use Vista drivers I have everything from 1998-2014 completely covered with just four binary drivers and no more out of pocket. There just ain't a way to do that in Linux.

There's a much easier way. Send a message to the kernel list saying, "I am a hardware manufacturer. Here are the docs for my hardware under NDA, and here's some samples." Ta-da! You get drivers written for free (or significantly reduced), and every subsequent distro release will support your hardware by default.

Re:It's been time for YEARS

[AlXtreme]

Constantly having to use second rate programs because the the GPL is so restrictive and viral that no software vendor wants to deal with it. As much as people spout 'open source' it isn't. It places as hard or harder restrictions on its use as any proprietary software, they are just different restrictions. But it definitely is not open.

Now you're clearly trolling/FUDing. There are plenty of proprietary apps for Linux, either as drivers (Nvidia) or as userland software (mostly for servers), and if you are merely using FLOSS there are hardly any restrictions at all. When was the last time you saw a EULA when you installed a FLOSS application?

The reason companies don't target desktop Linux is because it's only a tiny fraction of the market. The GPL has nothing to do with it. It's business, plain and simple.

Re:It's been time for YEARS

[PeterBrett]

Yes, when distributing binaries one must target not only a specific distribution, but a specific release and a specific CPU architecture as well.

This is not true. If you make a binary installer with your own link libraries for all of the dependencies you need, you can successfully make a closed-source release which works on just about any kernel since 2.6 with the correct architecture. The Linux userspace ABI is very stable.

If you want to use open-source libraries that would make such a binary blob legally difficult, that's your choice.

Re:It's been time for YEARS

[daver00]

Somebody didn't RTFA (I know who expects you to, really). I will distill it down for you:

Chrome on Windows: Hacked to be funky and unique, non standard libraries for rendering, etc.

Chrome for Mac: Easy to replicate windows experience using standard OSX API's.

Chrome on Linux: Clusterfuck, standard API's are not standard, and not good enough. Hacks will not be cross platform, difficulties everywhere.

Basically the question was posed: Do we even bother to try and replicate the windows chrome experience? Or simply put our fast little engine inside a totally different visual experience?

Re:Steal an idea from elsewhere

[theCoder]

Programming on Windows is easier? Seriously, I just can't let that go.

At work, we have a codebase that compiles on Sun, Linux, and SGI fine, and mostly compiles on that monstrosity known as Windows. I'm sure that most of our issues working with Windows stem from the fact that the system started its life on UNIX and was ported to Windows, but that's no excuse for some of the issues we face:

• It literally takes an order of magnitude longer to compile on Windows. It's a pretty big system, and takes about 2-3 hours to compile on Linux. But that's nothing compared to the 24+ hours it takes on Windows. Now, a lot of that is due to the fact that the higher ups in the company demand that we use ClearCase, which means everything on the compile is done over the network. Some people have done experiments where they copy all the code and 3rd party libraries to the local hard drive, and the compile is much faster. But all that points to the fact that Windows network drivers are bad.
• Debugging is a PITA. No core files. If something crashes, you might get a message box saying an exception occurred, you know, somewhere. I suppose if we re-compiled with debugging symbols, we might be able to use VS to figure out where the fault is, but we can't always compile everything in debug mode (even on Linux that significantly increases binary sizes and run times).
• Pop-ups at the wrong times. We have an extensive suite of unit test programs that we like to run to make sure that the code is correct. On UNIX, if a test fails, we'll get an assertion failure written to the log file and maybe a core file. On Windows, we get a popup saying there is an error. Which would be nice, if we weren't doing the testing over night (see 24+ hour build time), so the popup stops the build! And there are at least 3 different types of popups that could happen. At least the most common can be overcome with the "stapler trick" -- lock the machine and place a stapler on the "enter" key on the right of the keyboard so the popup is immediately dismissed.
• Random brokenness in each new VS release. Whenever we consider changing VS versions, I always wonder what will break in the new version. We generally use VS2003 for compiling because VS2005 had a lot of problems. I don't remember all the details, but ISTR there were a lot of things we couldn't easily work around. I do remember something about calling access(2) with some arguments (not even bad arguments) could cause a crash.
• Missing functionality in the system. Lots of common POSIX features just aren't present on Windows. Things like symlink(2)/readlink(2), fork(2), signals, and even strptime(3) just aren't present. We've mostly worked around these (providing our own implementation, or using other methods), but it's a pain, and some things don't work right.
• Weirdness in the libraries. Did you know that in a Windows C++ library, 'static' data members aren't automatically included across libraries? VS makes a second copy of the static variable in the calling library and leaves it uninitialized, unless you put __declspec(dllimport) in the static declaration. When compiling the calling library, at least -- that can't be there when compiling the code for the called library! Which leads to weird macros for something the compiler should do by default.
• And last, my current build machine has been messed up for some time, and our IT dept doesn't seem to know how to fix it. It suffers from some sort of PID starvation. No PIDs can be reused without rebooting the machine. It gets up to about PID 100000 and then just says it can't run anything else. Since Windows PIDs are always a multiple of 4, this means I get at most 25,000 processes per boot. Seems like a lot until you consider that make tends to run a lot of processes. I can't even get through generating all the Makefiles before I run out of processes and have to reboot. I suspec this is a driver problem of some sort, but don't know what. Fortunately, this means I just don't have