News for hackers. Stuff that matters.
Re:Chrome Binary Size by scott_s on Monday September 20, 2010 @09:19PM (#1711115)
This is an amazing visualization, but I don't like using the term "bloat." What would you take away? Keep in mind that Chrome's architecture is purposefully approaching that of an operating system.
Re:Chrome Binary Size by WalterGR on Monday September 20, 2010 @10:08PM (#1711209)
I don't like using the term "bloat."

It's an extremely non-specific term that people use to describe software they don't care for, much as people cast arguments they don't like as "FUD".

I was in a conversation with someone who said he felt IE 9 was bloated. I asked him why. "The right-click context menu is too big."

"Uses too much RAM", "requires too much disk space", and "has too many dependencies" can all be valid complaints. But it seems that in most uses, "bloat" = "has one or more features I don't use."

Re:Chrome Binary Size by othermaciej on Monday September 20, 2010 @10:37PM (#1711263)
Having too many features is valid usability complaint. In fact, it probably harms the user quite a bit more than "requires too much disk space".
Re:Chrome Binary Size by palish on Monday September 20, 2010 @11:07PM (#1711326)
In practice, not really. People just ignore what they don't use.
Re:Chrome Binary Size by othermaciej on Tuesday September 21, 2010 @02:20AM (#1711681)
In practice, yes really. Simplicity is one of the basic principles of good Human Interface design. User testing bears out that users find it hard to do even basic tasks with a more complicated program.

Now, sometimes it is possible to add features in a way that is unobtrusive enough that it doesn't affect usability for basic tasks. But it's a tough design challenge to do this, not a given.

By the way, I think Chrome overall does a pretty good job of design simplicity. But the "just ignore the features you don't want" argument is not a good basis for HI design.

Re:Chrome Binary Size by sgift on Tuesday September 21, 2010 @03:13AM (#1711796)
> But the "just ignore the features you don't want" argument is not a good basis for HI design.

It is a good basis if you can find out (as the HI designer) which features most people don't want: Then you can put them into places for advanced users, where they wait for the moment people need them. IMO the "simplicity" of many programs is just a crutch for HI designers unable to design a usable interface with more features.

Re:Chrome Binary Size by ugh on Tuesday September 21, 2010 @07:20AM (#1712158)
Do you really believe that it is possible to create arbitrarily simple interfaces for programs with arbitrarily many features? That seems unlikely to me. It seems much more reasonable to me that there is a correlation between the number of features and the complexity of a program.
Re:Chrome Binary Size by Lerc on Monday September 20, 2010 @11:51PM (#1711397)
They also don't use what they can't fathom. A plethora of options can make it difficult for a new user to find the features they want.

Yes they do ignore the unwanted features, but they also ignore features they would use if they knew about them. In that respect the notion of bloatedness is even amplified because a larger portion of the software is provided but idle.

Re:Chrome Binary Size by jmtulloss on Tuesday September 21, 2010 @02:17AM (#1711675)
Why do you believe this?
Re:Chrome Binary Size by billiob on Monday September 20, 2010 @10:36PM (#1711260)
It's useless to have N versions of the same library on your system. I prefer that my favorite distro takes care of updating one particular library if there is a security bug than having to wait for google to take care about it. It's what is done in gentoo: http://phajdan-jr.blogspot.com/2010/08/www-clientchromium-no... Currently, it uses the system libraries for:

• bzip2,

• codesighs,

• cros,

• icu,

• jemalloc,

• lcov,

• libevent,

• libjpeg,

• libpng,

• libxml,

• libxslt,

• lzma_sdk,

• molokocacao,

• ocmock,

• pyftpdlib,

• simplejson,

• tlslite.

As TODO, there is still zlib due to an issue during compilation.

It would also be great to have V8 as a different project so that it could be used outside of chrome with much less pain.

Re:Chrome Binary Size by bnoordhuis on Tuesday September 21, 2010 @06:48AM (#1712091)
> It would also be great to have V8 as a different project so that it could be used outside of chrome with much less pain.

http://code.google.com/p/v8/source/browse/trunk/ ?

Re:Chrome Binary Size by est on Tuesday September 21, 2010 @03:11AM (#1711794)
or type about:credits in your chromium address bar
Re:Chrome Binary Size by mcbain on Monday September 20, 2010 @10:00PM (#1711193)
That chunk of "third_party" stuff is a pretty tempting target.

Instead of using shared libs - like those that you've probably got on your system already - Google appear to like slurping everything into the one blob to solve dependency/versioning issues.

Re:Chrome Binary Size by cperciva on Tuesday September 21, 2010 @04:41AM (#1711910)
That chunk of "third_party" stuff is a pretty tempting target.

Not all of it. Part of the third_party code is a modified version of bsdiff, and as the bsdiff author I specifically endorse the shipping of modified versions of bsdiff with the software which required the modifications.

Re:Chrome Binary Size by _delirium on Tuesday September 21, 2010 @01:43AM (#1711607)
It's probably not a terrible default, given their cross-platform development. Slurping everything into your app bundle is the official way of doing it on OS X anyway, and more or less the only sane way of doing it on Windows, whose DLL-versioning is notoriously bad. So if they were doing any factoring out of shared libraries, it'd be solely for the Linux version, which I could see them not considering worth the hassle.
Re:Chrome Binary Size by blasdel on Monday September 20, 2010 @09:43PM (#1711158)
Please stop repeating that canard, it got old years ago: http://news.ycombinator.com/item?id=297297
Re:Chrome Binary Size by scott_s on Monday September 20, 2010 @11:20PM (#1711343)
I thought that analysis was ridiculous the first time I read it. I read Chrome's design docs when they were released. Chrome's design is approaching that of an operating system. Considering that it has to manage processes, there is no alternative.
Re:Chrome Binary Size by blasdel on Tuesday September 21, 2010 @01:26AM (#1711572)
But that's the thing, it's only managing processes, not scheduling them nor managing the minutia of their stacks — it devolves that responsibility to the real kernel by using 'dumb' native processes instead of inventing its own fucked coroutines with a browser-wide GIL for all the logically-independent javascript environments.

It is less OS-like than any other major browser!

Re:Chrome Binary Size by scott_s on Tuesday September 21, 2010 @09:45AM (#1712538)
Correct, it is not an operating system. Just as the Java Virtual Machine is not an operating system. But when you start using principles and common designs from operating systems, you are approaching the design of an operating system.
Re:Chrome Binary Size by argsv on Monday September 20, 2010 @10:17PM (#1711229)
Re:Chrome Binary Size by blasdel on Monday September 20, 2010 @10:23PM (#1711237)
I'm actually waiting to buy a Netbook until it comes out, in the vain hope that someone will ship a decent ARM-based system using it.

But it is just slightly-extended Chrome running directly in X unparented without the standard Gnome Desktop BS on otherwise stock Ubuntu.

Re:Chrome Binary Size by aaronblohowiak on Monday September 20, 2010 @10:35PM (#1711257)
tmux+vim+chrome is all i really need. (and a full posix system down below, of course)
Re:Chrome Binary Size by blasdel on Monday September 20, 2010 @10:39PM (#1711268)
What I want is NaCL implementations of urxvt+SSH and VNC/RDP.

I don't need yet another local posix system to maintain, I want remote access to my real server where my main screen session lives, and I want that access to live in a tab.

Re:Chrome Binary Size by aaronblohowiak on Monday September 20, 2010 @11:34PM (#1711364)
you can get vnc over html5, thought it may not be as fast as you'd like.
Re:Chrome Binary Size by asmosoinio on Tuesday September 21, 2010 @05:33AM (#1711983)
The term "bloat" is not used anywhere else than in the URL.
Re:Chrome Binary Size by gjm11 on Tuesday September 21, 2010 @06:10AM (#1712039)
And it looks to me as if the only reason it's even in the URL is that that's the name of the tool he wrote to extract and display the information.