Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Google Software Businesses The Internet Linux

Harsh Words From Google On Linux Development 948

Posted by timothy from the constructive-criticism dept.
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?"
This discussion has been archived. No new comments can be posted.

Harsh Words From Google On Linux Development More

Harsh Words From Google On Linux Development

Comments Filter:

  • Right (Score:5, Insightful)

    by Mikkeles ( 698461 ) on Saturday May 30, 2009 @01:53PM (#28151065)

    '...is it time to concentrate on consolidation and standardisation in GNU/Linux in general, and the desktop in particular?'

    Good luck.

    • It's been time for YEARS (Score:5, Insightful)

      by bonch ( 38532 ) on Saturday May 30, 2009 @02:47PM (#28151611)

      That part in the summary amused me:

      [I]s it time to concentrate on consolidation and standardisation in GNU/Linux in general, and the desktop in particular?"

      It was time ten years ago when Linux was first gaining real momentum in that area. I remember posting Slashdot comments about it and getting told Linux was about "choice" and that if I didn't like it, I should contribute code. Ten years later, even Google is bashing Linux for it. I bet nothing will change even now.

      Linux is a server OS, only used on the desktop by enthusiasts. Accept it, because the kind of standardized APIs that are needed are not going to happen with the attitudes that this community has.

      • Re:It's been time for YEARS (Score:5, Insightful)

        by Elektroschock ( 659467 ) on Saturday May 30, 2009 @03:07PM (#28151807)

        Accept it, because the kind of standardized APIs that are needed are not going to happen with the attitudes that this community has.

        1986

        BYTE: Given that manufacturers haven't wanted to fund the project, who do you think will use the GNU system when it is done?

        Stallman: I have no idea, but it is not an important question.

        • Steal an idea from elsewhere (Score:5, Interesting)

          by Actually, I do RTFA ( 1058596 ) on Saturday May 30, 2009 @11:27PM (#28155539)

          Maybe Ballmer was right? It's all about developers, developers, developers, developers.

          Every time a conversation about programming on Linux comes up, I try to follow it. But honestly, it's just easier programming on Windows machines. There are maybe 4 versions to worry about ME/2000/XP/Vista. And you can probably forget about ME/2000. Even if you don't, it's a few lines of difference (between them and XP, they're prerrt to identical to program for). And you can leave them in when you program for XP/Vista.

          Meanwhile, if you use the best practices that MS recommended for XP back when they released it, there's no difference between XP/Vista programming (unless you're trying to extend windows explorer.)

          It just works, and it's easy.

          • Re:Steal an idea from elsewhere (Score:5, Informative)

            by theCoder ( 23772 ) on Sunday May 31, 2009 @06:03AM (#28157125) Homepage Journal

            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

      • Re:It's been time for YEARS (Score:5, Interesting)

        by osu-neko ( 2604 ) on Saturday May 30, 2009 @03:13PM (#28151855)

        Linux is a server OS, only used on the desktop by enthusiasts.

        I would hope that all desktop OS's are used by enthusiasts. People who run Ubuntu should do so because that's what they like. People who run Mac OS X should do so because that's what they like. People who run Windows should do so because that's what they like. If people are running an OS for some other reason, then we have problems...

        Accept it, because the kind of standardized APIs that are needed are not going to happen with the attitudes that this community has.

        Indeed. If we were to reject that attitude and simply standardize around a single way because it's best if everyone runs the same, we'd all run Windows. There's no logical argument that can be made for rejecting running Windows but advocating a standardized API for all Linux platforms. The argument for a standardized API is an argument against having multiple operating systems to begin with. Someone who thinks every Linux-based OS should have the same look, feel, toolkit, API (beyond the Linux kernel), etc. but accepts the notion that we shouldn't all just standardize around Windows is in a state of cognitive dissonance, holding logically imcompatible ideas to be simultaneously true. That's not so amazing as the fact that they've managed to maintain it for ten years...

        Setting aside the logical contradictions of your point of view for the moment, and just out of curiosity, when you say "that are needed" -- needed for what? I'm unaware of any objective that an OS should have (keep my computer running, my multiple programs sharing resources effectively, my data safe, etc.) that would require other operating systems to run the same API as me. Why would it matter if my Debian desktop and your Fedora desktop are different? And why would it be more important and somehow more tragic that our two computers are different when it's not likewise tragic that my Debian desktop and my friend's Windows desktop are different? Why is one case of difference bad but the answer is not for all three of us to adopt the more popular standard, rather that for some reason two of us should and one should not?

        • Re:It's been time for YEARS (Score:5, Informative)

          by jacksonj04 ( 800021 ) <nick@nickjackson.me> on Saturday May 30, 2009 @03:27PM (#28151995) Homepage

          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 been time for YEARS (Score:5, Insightful)

          by Bodrius ( 191265 ) on Saturday May 30, 2009 @05:37PM (#28153237) Homepage

          I would hope that all desktop OS's are used by enthusiasts.... If people are running an OS for some other reason, then we have problems...

          Er... Why is that a problem again?

          Why can't billions of people use computers and technology to improve their lives *without* making their OS choice a matter of philosophy or identity? If they choose for more pragmatic reasons (requirements, price/value, simplicity), why is that a 'problem'?

          Most people have only a few things in their life that really matter to them to the point you can call them 'enthusiasts'.

          Most people use stamps without collecting them, drive cars without obsessing over engine models, drink wine without knowing merlot from cabernet, enjoy music without playing any instruments, use electricity without having the least idea about their house wiring... There are enthusiasts for everything, but as a matter of practicality (and probably mental health) humans have to pick the few things on which they invest their time and energy.

          Fortunately, most enthusiast communities are not so arrogant that they assume everyone must share their interests and obsessions - as some kind of political or religious choice. They're the better for it.

          Those who demand their pet interests to be *important* to everyone else demonstrate not just arrogance, but a selfishness that is most likely self-defeating.

          Technology has continuously improved the standards of living of billions of people - but the greatest values of each advancement are only reached when they are so omnipresent and require so little training they're taken for granted. Billions of lives are saved/extended when electricity is in every building, when every child is vaccinated, etc. Computers are not different.

          As a geek, I would like more people to become tech enthusiasts and share the same interests. But I'd also hope we recognize, considering the richness of the human experience, most people will (and should) care a lot less about the OS on their laptop than about most things in their daily life.

  • Choice (Score:5, Insightful)

    by edivad ( 1186799 ) on Saturday May 30, 2009 @01:54PM (#28151079)
    Choice, many times becomes really fast synonym of fragmentation and lack of standard. And this is just a bright example. The situation described is 100% conforming to reality, as far as UI kits and sound infrastructure.

    • Re:Choice (Score:5, Insightful)

      by Midnight Thunder ( 17205 ) on Saturday May 30, 2009 @02:11PM (#28151231) Homepage Journal

      Choice, many times becomes really fast synonym of fragmentation and lack of standard. And this is just a bright example. The situation described is 100% conforming to reality, as far as UI kits and sound infrastructure.

      Sounds like the strength is also its weakness.

      The criticism made is a fair one, and it is only when there are vocal and influential enough developers do people actually stop to pay attention. I am sure there will be many Linux developers who will go on the defensive, but until you are the number one choice for the desktop it is worth listening to what the critics say. Even when you are number on the desktop you should still listen to the critics if you want to stay there. Just look at Windows as an example.

    • Re: (Score:3, Insightful)

      by Santana ( 103744 )

      PC vendors are missing a gold opportunity here. They could adopt a GNU/Linux distribution and make it attractive to the masses, just like Apple did with Nextstep. That would really challenge Microsoft and Apple, but require a dedicated software development department, something that many of them don't know how to do or don't want to take the risk at.

      Even though it's disappointing, It's not unexpected. They only know how to brand a PC and sell it.

      • Re:Choice (Score:4, Insightful)

        by Blakey Rat ( 99501 ) on Saturday May 30, 2009 @02:27PM (#28151411)

        PC vendors are missing a gold opportunity here. They could adopt a GNU/Linux distribution and make it attractive to the masses,

        And that benefits them... how?

        Yes, you're correct, they *could* do that. (If you're just looking for confirmation.) But why would they? What's the business case for it?

    • 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.

      The only downside I can think of is that end-users need several GUI toolkits installed, for their multiple programs that use different toolkits, but a) Linux still has a

      • Re:Are there any downsides to choice in this case? (Score:5, Insightful)

        by Anonymous Coward on Saturday May 30, 2009 @03:03PM (#28151751)
        Does apt-get count as a relatively easy to use package manager? I've used it on both OS X and Windows machines.

        The problem with having several GUI toolkits is that then you fragment the user experience. I use GIMP on OS X, and having X11 running makes it a very awkward, sometimes annoying experience - not only do I have to make sure I'm properly in GIMP rather than X11, but all the keys change command button to control button depending on which one you're in. It's really pretty awful, and I expect non-techy users to find it more confusing than I do.

        Consistency is important to a user experience. Learning how to complete tasks in an OS is very much like a language skill. When you force people to learn different sets of hot keys, different ways of achieving the same task, then you're burdening them with another language. The only good reason to break away from having a single HIG standard, as far as from the user's perspective, is if you're writing a really novel application where you're trying to provoke a different mindset; writing yet another average GUI toolkit doesn't come close to qualifying.

      • Re:Are there any downsides to choice in this case? (Score:4, Informative)

        by Kjella ( 173770 ) on Saturday May 30, 2009 @04:09PM (#28152387) Homepage

        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.

      • As an addendum to this good point:

        The reason we have so many choices is because....the users and developers want choices. OSS choices exist almost by definition because people are choosing them. To say, "your choice sucks, choose a better one" is ridiculous. Google is showing off the corporate mentality here. If you're not paying the thousands of developers of the toolchains for the major (and minor!) distributions, you don't get to complain about what they're producing. If you want standardization, you don't bitch about it - you make your platform of choice far superior to the other options.

        There are choices because they all have something to offer to someone.

  • Yes (Score:3, Insightful)

    by Idiomatick ( 976696 ) on Saturday May 30, 2009 @01:54PM (#28151081)
    Well it was a few years ago. Hope ubuntu has enough weight it can set standards.

    • Re: (Score:3, Insightful)

      by monoqlith ( 610041 )

      I think Ubuntu implicitly has set the standard. Ubuntu comes standard with GNOME, GNOME uses GTK, GTK is therefore the de facto standard.

      The more relevant complaint seems to be that GTK isn't good enough. I agree that Ubuntu and GNOME could do a lot to improve it.

      • Re:Yes (Score:5, Interesting)

        by Enderandrew ( 866215 ) <enderandrew@gmSTRAWail.com minus berry> on Saturday May 30, 2009 @02:42PM (#28151551) Homepage Journal

        Except GTK is so poor that you have Gnome devs calling for a major restructuring, and Mark Shuttleworth of Cannonical/Ubuntu fame calling for Gnome to be built on top of KDE. Ubuntu hitched their wagon to Gnome very early on, and ships broken KDE packages to this day, but I have to wonder if Shuttleworth regrets that decision today.

  • Use Qt.... (Score:4, Insightful)

    by Rainefan ( 969597 ) on Saturday May 30, 2009 @01:56PM (#28151101)

    Why not just use Qt instead? It's LGPL....why people still using GTK?

    • Re:Use Qt.... (Score:5, Interesting)

      by moonbender ( 547943 ) <moonbender@gUUUm ... inus threevowels> on Saturday May 30, 2009 @02:21PM (#28151323)

      True! And since it now comes with QGtkStyle, which uses GTK+ engines and widgets to render stuff, you can use it and have a nice looking app at the same time.

      • Re:Use Qt.... (Score:4, Interesting)

        by slack_justyb ( 862874 ) on Saturday May 30, 2009 @03:41PM (#28152137)
        I have no idea why GTK+ is still around since Qt went LGPL.

        Qt has better documentation [qtsoftware.com] than GTK+. [gtk.org]

        As an example, you'd be hard pressed to find a widget in the QT documentation that is not documented. GTK+ has rough around the edges documentation for it's Canvas.

        I know that RedHat is putting a lot of weight behind Java technology as one of the first and foremost distros for the OpenJDK. I can attest that the QT Java bindings [trolltech.com] are way better than the GNOME bindings. [sourceforge.net] It would make sense for RedHat to toss weight behind QT. Google already uses QT for Google Earth. [google.com] And KHTML is, sorta, WebKit which is Chrome. It all makes more sense to put our weight in QT.

        I've got nothing but love for the GTK+ people. Also, don't kill QT just because of the KDE 4.0 issue. They've made good on their latest desktop, but don't knock a good Toolkit because of the DE.

        My two cents.

    • Re:Use Qt.... (Score:5, Insightful)

      by sricetx ( 806767 ) on Saturday May 30, 2009 @02:44PM (#28151579)
      QT is probably the best GUI toolkit in history, in my opinion. Since it's now available under the LGPL license, I have to assume that the development project the whiner from Google is talking about was done before the LGPL QT 4.5 version was released or is not written in C++. Standardization is fine and all, but please, please don't standardize on GTK. Take a look at the hideously ugly GTK file picker for an example of why the usability of GTK UIs leaves something to be desired.

      • Re:Use Qt.... (Score:4, Informative)

        by jbolden ( 176878 ) on Saturday May 30, 2009 @03:37PM (#28152109) Homepage

        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.

        • Re:Use Qt.... (Score:5, Informative)

          by ultrabot ( 200914 ) on Saturday May 30, 2009 @04:44PM (#28152755)

          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

  • I don't see anything wrong (Score:5, Insightful)

    by Jane Q. Public ( 1010737 ) on Saturday May 30, 2009 @01:59PM (#28151127)
    with a standardized HIG. After all, graphical interfaces are not exactly the new kid on the block. There are common standards (use radio buttons for this, checkboxes for that, put your menu HERE). And while Linux does not necessarily have to conform to OS X or Windows standards, it could certainly have a standard of its own. This would help developers a lot. In my experience, many developers, while good coders, are not good interface designers. Without a comprehensive guide, they just plain get it wrong.

    I don't much give a damn about Adobe being skittish, though. Are they paying Linux core developers?

    • Re:I don't see anything wrong (Score:4, Interesting)

      by XDirtypunkX ( 1290358 ) on Saturday May 30, 2009 @02:53PM (#28151651)

      Chrome is really about as simplistic as UIs get (apart from the web pages themselves). There aren't checkboxes or radio buttons on the main interface; you get tabs, a toolbar/address bar and that's it. To go further, the rendering in Chrome happens in a separate process (not even tied to the GUI) which is RPC'd back to the main process, which indicates that it's not really tied to the GUI toolkit either.

      Is a standardized set of human interface guidelines really going to help them? Or are they just making an excuse for not servicing a small but vocal market? The truth is, if the Chrome developers wanted to worry about standardized interfaces, they would do the work to reproduce what they have on Windows. They didn't care about the standards on Windows (tabs on the title bar), so why would they care about them on Linux?

      While I'm all for creating a common interface "language" for users to understand, I don't think a "linux" specific one is going to be helpful. Making it easy to move from using Chrome on Windows to using Chrome on Linux is much more helpful than saying "hey, look, you can use Chrome on Linux if you know how we do things around here". Making it so someone that uses Windows can understand the linux visual "language" is important, in the same way that we want people to understand what we say when we travel. Otherwise moving to Linux with it's own HIG is going to be like moving from England to China.

  • Yes (Score:3, Interesting)

    by TheLink ( 130905 ) on Saturday May 30, 2009 @02:02PM (#28151153) Journal
    Yes, but I doubt it's going to happen.

    Without some sort of standards how would a helpdesk worker even know where the "start button" is on a caller's "Linux Desktop"? Or what it even looks like, or if it's even there?

    Remember the helpdesk worker might not be working for the same company as the user. For example: if Mr XYZ goes to a hotel and has problems with "hotel internet", they might be calling the "hotel internet helpdesk". Same for other stuff e.g. bank and financial sites.

    BTW Microsoft has created a similar problem for themselves by changing things immensely with Vista (and Office 2007). Lucky for them, they're in a different market position but even they are having problems with market adoption, so go figure.

  • apple (Score:3, Funny)

    by rubah ( 1197475 ) on Saturday May 30, 2009 @02:09PM (#28151217) Homepage

    Should've started on the osx version instead!

    *impatient*

  • There's nothing wrong (Score:4, Interesting)

    by mikesd81 ( 518581 ) <.mikesd1. .at. .verizon.net.> on Saturday May 30, 2009 @02:11PM (#28151229) Homepage
    with having a standard in Linux at all. It doesn't have to be a just about GTK and QT either. They're both widget kits. Great. The standard has to start in the file system. Red Hat, for instance, worries about being backwards compatible with each update, as it should, but that means it broke the FSH to begin with. So migrating from RH to another Linux distro that may follow the FSH is difficult. Also, it makes installing things a pain sometimes. A few times I've had to edit a config file because it points to a web server in /srv/www but in reality my system may use /var/www/ or what have you. Just because open source is about choice, doesn't mean there shouldn't be a standard set.

  • Linux's greatest strength = greatest weakness (Score:5, Insightful)

    by CyberK ( 1191465 ) on Saturday May 30, 2009 @02:16PM (#28151269)
    Let's face it, one of the things all Linux evangelists like to emphasise is the opportunity to use whatever you want and even build it yourself if you want to. But it's maddening for developers to create something that will work on every kind of linux desktop in existence. From political choices of free vs. non-free, to preferred distribution, version numbers, favourite window manager and a host of other choices, no two desktops will be the same. Linux isn't an operating system, it's an operating eco-system. Taking Google as an example, today I tried to install Google Earth on my Ubuntu 9.04 laptop to no avail, despite it having installed without a hitch on my Xubuntu 7.04 Pentium III plaything in my room back in my parent's house. The exact same version of the program with dramatic differences depending on where you try it, that quickly becomes a support nightmare.

    Now for the dedicated GNOME/KDE/xfce/whatever volunteer this does not pose much of a problem because your target audience has broadly the same machine makeup as you do, but for a commercial developer looking for a good ROI it quickly becomes untenable. Windows and Mac OS provide a devoloper with a guaranteed stable platform development-wise, and as such are much safer bets.

    I agree that the only way Linux can make itself more attractive to commercial desktop program developers is with a mighty amount of consolidation, but the problem is that I don't think it will happen. The great OS wars that went before the dominance of Windows had winners and losers because they were systems of a closed nature, and so if you held with a losing team they closed down because it wasn't economically viable and you had to move to something more mainstream, thus consolidating the market. With Linux a project will never close down as long as someone like it more than something else.

  • Article by Slashdot completely distorts reality (Score:5, Informative)

    by Anonymous Coward on Saturday May 30, 2009 @02:17PM (#28151279)

    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.

  • It's open source, google. Fork it. (Score:3, Insightful)

    by Junior J. Junior III ( 192702 ) on Saturday May 30, 2009 @02:22PM (#28151341) Homepage

    I'd like to see a Goo/Linux distro. In my experience as a user of several of their products, google really does a good job with user interfaces. I bet if they put some effort into a google desktop environment, it'd be pretty darn good.

    It could be related to Android, or not, whatever makes sense.

  • Qt (Score:5, Interesting)

    by Enderandrew ( 866215 ) <enderandrew@gmSTRAWail.com minus berry> on Saturday May 30, 2009 @02:26PM (#28151391) Homepage Journal

    Chrome should have been built on top of Qt from day 1. You'd have tight integration with Webkit, a great toolkit, and cross-platform from day 1 on Windows, Mac, Linux and Solaris.

    Google opted for VERY Windows-centric design which made porting hard, and then the man tasked with porting to Linux choose a poor toolkit and then blamed the Linux platform for two bad decisions in a row made by Google.

    I have zero sympathy.

    • Re:Qt (Score:4, Informative)

      by cygnusx ( 193092 ) on Saturday May 30, 2009 @03:10PM (#28151829)

      > 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:Qt (Score:4, Insightful)

        by Enderandrew ( 866215 ) <enderandrew@gmSTRAWail.com minus berry> on Saturday May 30, 2009 @03:24PM (#28151969) Homepage Journal

        I've read the BS answer, and it is BS.

        First off, Qt apps look and operate just fine on Mac and Windows. They don't jump out as looking "foreign" to the platform, where as Chrome on Windows does look extremely foreign in its UI design. This isn't an issue here.

        Secondly, Qt provides VASTLY more functionality than GTK, and wouldn't limit what Chrome could do on Windows or Linux. Chrome didn't choose seperate platform codebases to better enable those platforms. The Chrome devs admitted they wrote a very Windows-centric app because they didn't know anything about Linux and coded how they knew how to with what they were familiar with. Again, this reasoning is completely BS.

        Lastly, the advantages of cross-platform development not only means no initial time to fork, but it means fewer bugs, less complexity, and the entire life of the project with have a much smaller codebase to manage. Ignoring that major advantage is foolish at best.

        Then when you consider how well Qt and Webkit are natively bound, and how well Qt deals with multiple processes and multithreading, it was just plain dumb to not build Chrome on Qt from day 1.

        • Re:Qt (Score:4, Insightful)

          by Blakey Rat ( 99501 ) on Saturday May 30, 2009 @04:19PM (#28152517)

          First off, Qt apps look and operate just fine on Mac and Windows.

          No.

          Better than GTK+, definitely. Not "just fine." Not even good. Especially on Mac, where they're extremely weird in many fundamental ways.

          Typically, people saying things like this about cross-platform frameworks really have little or no experience designing GUI apps-- they don't have the eye for detail that that job requires, and they literally don't see anything wrong with the QT apps. But find an advanced Mac user, show them two UIs and tell them to pick-out the QT one, they'll get it 100% of the time.

          • Re:Qt (Score:5, Insightful)

            by Enderandrew ( 866215 ) <enderandrew@gmSTRAWail.com minus berry> on Saturday May 30, 2009 @04:40PM (#28152707) Homepage Journal

            A Qt browser on Windows looks just as native as Firefox, or Opera, or Chrome. Note, every one of those browsers uses a non-standard UI. Qt provides styles to mimic native widgets and can look perfectly native. Chrome wasn't even designed to look native. They are blowing smoke to obfuscate the reality of the situation.

            Chrome wouldn't have looked one ounce more "foreign" because of Qt. It looks foreign because they designed it foreign.

        • Re:Qt (Score:5, Insightful)

          by Anonymous Coward on Saturday May 30, 2009 @04:59PM (#28152873)

          I am a Chromium developer, and if you don't think Qt apps "speak with a foreign accent", especially on Mac, you don't pay close enough attention. It's not an immediate appearance difference, it's the way that subtle details are wrong. By contrast, Chromium appears _very_ different on Windows on the surface, but we go to great lengths to get small details right. Big differences can be accommodated. Small differences drive you crazy.

          Also, most of us were Linux developers, not Windows developers, before writing Chromium, so again you are asserting things that are completely wrong.

  • and this is different from other platforms... how? (Score:5, Insightful)

    by speedtux ( 1307149 ) on Saturday May 30, 2009 @02:27PM (#28151405)

    My Mac currently has several apps in three different toolkits open; several apps written by Apple itself don't follow standard UI conventions. The Windows situation is even worse: there are several native toolkits there (Win32, MFC, .NET, ...), plus dozens of third party ones. And UI conventions are violated constantly.

    The real problem Windows programmers have with Linux is... that it isn't Windows. They start writing some big, ugly, messy Windows application (hello, Firefox), and then they moan and groan when porting it to Linux and usually do a piss-poor job at it too.

  • RTFA (Score:5, Informative)

    by jipn4 ( 1367823 ) on Saturday May 30, 2009 @02:36PM (#28151479)

    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.

  • GUI standard is a myth. (Score:5, Insightful)

    by McDutchie ( 151611 ) on Saturday May 30, 2009 @03:08PM (#28151815) Homepage

    There is no universal standard GUI toolkit on Windows either. Firefox and Opera use their own. OpenOffice.org uses its own. Even Microsoft Office uses its own. On the Mac, there is even more GUI dissonance. Current Macs make the typical Linux environment look downright uniform.

    Why is this always considered a problem on Linux but not on Windows or on the Mac?

    If the Chrome developers feel too constrained by GTK, they should have chosen a better toolkit, such as Qt (which, incidentally, is also popular on Windows). They can't blame their own bad choices on Linux. Their gripe sounds like the standard "how dare Linux be different from Windows and make us have to learn something new" whining.

  • I am sick to death of hearing developers bitch about "native look and feel". Grow up! Get a fucking life! I couldn't care less how the goddamn app looks COMPARED TO OTHER APPS as long as the look enables the FUNCTIONALITY to be performed correctly.

    What matters is that the program does it's job - not that the widgets look the same as some other app on the system.

    Christ, what a fucking waste of millions of man hours farting around with bullshit cosmetic issues! Fucking programmers think they're goddamn "artistes" when they can't even get their shit to RUN PROPERLY, NOT CRASH, BE FUCKING USABLE, and BE SECURE!

    Shut the fuck up about look and feel and concentrate on making the thing fucking usable, reliable, and secure.

    You want to be Picasso, get a fucking paintbrush!

  • hey Google (Score:4, Interesting)

    by Lazy Jones ( 8403 ) on Saturday May 30, 2009 @07:41PM (#28154247) Homepage Journal
    If you want a better UI toolkit, write one yourself. Otherwise use wx or Qt. But it's OK, everyone knows you're just making lame excuses for not supporting Linux properly despite having enough resources for it easily (even the Mozilla Project can do it and it doesn't earn billions every year).

  • Corporate freeloaders (Score:4, Insightful)

    by bug1 ( 96678 ) on Saturday May 30, 2009 @09:08PM (#28154751)

    So corporations are complaining that the software that they get for free and use to make truck loads of money isnt exactly what they want.

    Ive got an idea, WRITE YOUR OWN DAMNED SOFTWARE, or maybe participate constructively in the community. Dont just complain, do some work yourself on the same terms as the work you received.

    "Did you ever expect a corporation to have a conscience, when it has no body to be kicked and no soul to be damned?" - Edward Thurlow

Slashdot Top Deals

Your good nature will bring you unbounded happiness.

Close