Slashdot Mirror
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?"
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.
From scarped cliff or quarried stone she cries "A thousand types are gone, I care for nothing, no not one."
I will squirt it up for you: here. Alternatively, you could have binged it.
Ezekiel 23:20
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.
Well, then, make a standard that doesn't suck. That is what I was saying.
What they are talking about (HIG) is only a "guideline" for programmers to follow. You know, for programmers who would otherwise get it wrong (using dropdowns when radio buttons would be more appropriate, using editable textboxes just for displaying information, etc.). It is not supposed to be a concrete "thou shalt do it this way or else" document.
Otherwise, you are not leaving the "user experience up to the users" anyway... you are leaving the user experience to programmers who don't know how to do interfaces.
I guess the guy that used to be the lead developer of Firefox may know better than you and me.
Perhaps the problem is that the lead developer of Firefox ignored that HIG in making Firefox. From Wikipedia: "Mozilla Firefox's user interface, for example, goes against the GNOME project's HIG, which is one of the main arguments for including Epiphany instead of Firefox in the GNOME distribution." No doubt there were reasons for the choice taken in Firefox development, but the consequences include a lot of bloat and reinvented square wheels.
Those who can make you believe absurdities can make you commit atrocities. - Voltaire
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.
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.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
There simply is no benefit because PCs without Windows on them won't sell very well. Most people who buy computers barely know where to click and are totally confused by new operating systems. All they know is Windows, so that is what they will buy. It's very hard to get past that.
-- Cheers!
> Chrome should have been built on top of Qt from day 1.
RTFA.
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.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
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.
How many people can read hex if only you and dead people can read hex?
... 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.
wxWidgets is mainly just a wrapper around GTK.
You use Wx when you specifically want your program to "look native" (without having to emulate it) across all three Win32/GTK/Mac platforms.
Yes, that means it has the idiosyncrasies of all three platform. And if your open source application doesn't have a development team large enough to deal with three separate applications sharing backend components, then it's a fairly cheap way to achieve both platform support and native look and feel.
I've used it a couple of times for exactly that purpose.
But if you're Google, and you can afford the programmers to support three forks with common components, then you don't pick Wx. You go straight to lower layer source and use GTK.
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.
Here is the great thing about having dozens of GUI toolkits, multiple libc, and several audio APIs. You only have to choose 1! Every time somebody complains about the "mess" of GUI toolkits, it just comes off as senseless whining. Where are the downsides? There are only 2 major ones, and if you don't have experience in either, just pick one.
I don't know if it's just me that keeps running into these wtfs, but if all of them worked from the user POV then I'd agree with you. Reality is that sometimes pulseaudio works, sometimes it works if I redirect it to ALSA, sometimes for no good reason I have to pick OSS output - that on modern Linuxes maps to ALSA, but for some reason that works and ALSA doesn't. Sometimes if I'm running multiple sound-using apps I get complaints that it can't open the audio device and so I have to close something else, even though everything should support mixers since many years ago.
It usually runs decent if you run say only KDE apps, probably the same for Gnome - but if you start mixing kde and gnome apps, virtualbox, wine and closed source then my experience is really bad. Still, it looks like a decent toolchain is emerging:
Phonon - high-level cross-platform API - "Play me this MP3 file"
GStreamer - plugin layer for all the good/bad/ugly formats, not the one true decoder - "I took the MP3 and decoded it, here's the sound"
PulseAudio - sound (re)direction to speakers, headphones, network+++ - "Preferences say this sound should go on the headphones"
ALSA - actually deal with the hardware and reveal playback/recording capability - "Headphones - play this"
It's not like all these pieces of the audio system does the same thing, when they're trying to show that it's so very confusing they overcomplicate a bit. There's a fairly one-directional workflow from the application towards the hardware, and if you displayed them as a layer diagram (with some blocks possibly covering several layers) then it wouldn't look nearly as bad.
Live today, because you never know what tomorrow brings
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 /build/buildd/glib2.0-2.20.1/glib/gmain.c:2761 /build/buildd/glib2.0-2.20.1/glib/gmain.c:2511
#9 0xb5deaf82 in g_main_context_iterate (context=0x9778e90, block=1, dispatch=1, self=0x9776f40) at
#10 0xb5deb268 in IA__g_main_context_iteration (context=0x9778e90, may_block=1) at
#11 0xb6a5f438 in QEventDispatcherGlib::processEvents (this=0x9763c68, flags={i = -1074473992}) at kernel/qeventdispatcher_glib.cpp:323
Save your wrists today - switch to Dvorak
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.
Pirate Party UK
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.
This sig is intentionally left blank
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.
Pirate Party UK
Won't happen, because either some free software believer will "leak" the docs to some place like wikileaks, or you will see half the software developers scream in true RMS style "NDAs are the devil! Information wants to be free!" or some such rot. Most companies are NOT going to give their specs and docs to anyone outside the company-period-full stop. If that is what it takes to have a driver for Linux? Then you simply won't have drivers. Kinda like now.
What they WILL do is be quite happy to write you a binary driver if they know they can "write once use forever" like they can with Windows. The last all in one I picked up had a Win98 driver, as well as 2K,XP, and Vista. looking at the dates on the Win98 driver they are from 2001. Hell the XP drivers are from 2003. Can anybody here even imagine a device driver circa 2003 working without ANY need for tweaks, hacks, updating, or recompile in Linux?
And THAT right there is the problem in a nutshell. It isn't the big bad MSFT, who boned themselves real good with fucking up backwards compatibility in Vista, it isn't the OEMs like Asus who are dropping Linux, it ain't the mom & pop shops like me that would be happy to carry Linux boxes if it wasn't a support nightmare from hell. it is the fact that the margins on all those little devices that everybody seems to have sucks, and spending money constantly having to have developers tweak or recompile them for Linux isn't money well spent. If they only support Windows they can have developers only write four drivers and then put them on other projects while selling that device for years. With Linux everything from the kernel up is in a constant state of flux and things are getting broken pretty much constantly. Just go to the Ubuntu forums after a release and see how many "The update totally broke device Foo" posts there are.
So to me it seems pretty simple. The Linux users and developers need to get together and ask themselves a single question: do you WANT to have decent marketshare? If the answer is yes then you HAVE to support all those doodads being sold out of Best Buy, Walmart, Staples, etc. You can't write all those yourselves, it would be too costly. you NEED the hardware manufacturers to support your OS. And they will never do so until they can have a "write once, use forever" driver model like they enjoy on Windows. So get together and decide on a stable, backwards compatible undercarriage that anybody can write a binary to and be done with it. Do that and you'll have OEMs and mom & pop shops like mine selling Ubuntu boxes right next to the Windows ones. But without those manufacturers on your side you will never get any marketshare, and right now writing drivers for Linux is like trying to hit a dartboard with a live bumblebee. Is it any wonder why guys like Asus have stopped trying to sell Linux to home users?
ACs don't waste your time replying, your posts are never seen by me.
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?
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:
"Save the whales, feed the hungry, free the mallocs" -- author unknown