Slashdot Mirror

There are a shitload of applications out there that do not exist in either, and if you want them they suck monkey testicles to install.

That's the fault of the application, not of the distro.

For example, try installing Chrome on Ubuntu -- you click either the 32-bit link or the 64-bit link, and it Just Works. It also sets up a Google repository so that it will continue to auto-update, through the package manager.

Your complaint would be somewhat like complaining because some Windows app demanded that you download and install Visual Studio Express first, then downloaded and compiled the source for it and several libraries it needs. It's certainly possible to make installation easier, but it's up to the app to do so.

Ouch, sorry. Bad link. Here's. the correct one.

Wrong. While still 'un-official', a developer preview of Google Chrome for Linux has been out for a long time, freely available. Link.

Isn't it pretty much useless to run a 64bit browser anyway? I quote the 64-bit support (chromium developer) page

In general, the benefits and costs of a 64-bit build are non-trivial and should be analyzed and measured thoroughly.

• Our multi-process model negates the benefit of a 64-bit address space. A 32-bit address space should always be sufficient.
• Some performance gain may be possible with the 64-bit instruction set, but this can come with a cost of increased code size, cache usage, etc.
• There will be a significant increase in memory usage, as all object pointers (DOM nodes, V8 objects, etc) would double in size.

Citation here: http://news.cnet.com/8301-17939_109-10110247-2.html Technical details here (I think): http://dev.chromium.org/developers/design-documents/extensions/gleam-api

Here's the Linux version: http://dev.chromium.org/getting-involved/dev-channel#TOC-Linux

The source for the disassembler is pretty simple.

http://src.chromium.org/viewvc/chrome/trunk/src/courgette/disassembler.cc

Porting that to parse x86 out of ELF or another executable container wouldn't be too difficult. Porting it to parse x64 or PPC would be tougher.

I'm posting right now from Chromium running on Linux/X/GNU/Fluxbox
http://build.chromium.org/buildbot/snapshots/chromium-rel-linux/

You might wanna recheck your preconceptions - a lot has changed in the past few releases for Firefox: http://dotnetperls.com/chrome-memory

That benchmark is worthless. Especially for Chrome. Quote: "When a process with the same name such as 'chrome.exe' is encountered more than once, its total size is accumulated, yielding a total of all the 'chrome.exe' figures together." Apparently the author has never heard of shared memory! See Google Chrome Memory Usage - Good and Bad on the Chromium blog for some discussion on this.

The other browsers might not be using multiple processes, but the same flaws apply to a lesser degree. Every library they load will count against them, even if another app is using the library and so it would be in memory anyway. The only reliable way to tell how much memory a process is really using is to check memory usage, use program, check memory usage, kill program, check memory usage. If the first and third figures are equal, then you can get a correct figure by subtracting the second figure from their common value. (If they aren't equal, either the app hasn't actually exited fully, or some other program has eaten up more memory in the meantime and the results are no good.)

Granted, I doubt Firefox is such a comparative memory hog as people paint it to be, but the benchmark proves nothing either way.

Just use Chrome.
http://build.chromium.org/buildbot/snapshots/chromium-rel-mac/

The Chromium Blog says:

If you're measuring memory in a multi-process application like Google Chrome, don't forget to take into account shared memory. If you add the size of each process via the Windows XP task manager, you'll be double counting the shared memory for each process. If there are a large number of processes, double-counting can account for 30-40% extra memory size.

To make it easy to summarize multi-process memory usage, Google Chrome provides the "about:memory" page which includes a detailed breakdown of Google Chrome's memory usage and also provides basic comparisons to other browsers that are running.

2. Location of FFmpeg source code

The source code for FFmpeg is easily locatable in the same place as
the rest of the Chromium source:

http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/ /quote)

The first email linked to in the summary pointed to chromium, which is why I linked to the terms page. I don't really know the difference between Chrome and Chromium, I just figured that Chrome was built on top of Chromium, or that Chromium is the site that holds the Chrome source repository. Anyway, I've been fighting back cold symptoms all day, so my ability to concentrate isn't what it usually is.

You can use chromium if you don't want to use the google branded Chrome. Chromium will not send any data to anyone.

Also the linux version doesn't have sandboxing

Unlike the Mac version. I'm sure they'd appreciate hints on how to use SELinux/AppArmor.

from http://dev.chromium.org/getting-involved/dev-channel :

Installing Google Chrome will add the Google repository so your system will automatically keep Chrome up to date. (If you don't want Google's repository, do "sudo touch /etc/defaults/google-chrome" before installing the package.)

But it didn't (and I didn't touch /etc/defaults/google-chrome)

Those are just build numbers. Pick the biggest number for the latest version. As of right now, this is the latest version:
http://build.chromium.org/buildbot/snapshots/sub-rel-mac/17420/

You can download Chromium here: http://build.chromium.org/buildbot/snapshots/sub-rel-mac/

Since no one so far cared to provide a link to the actual Chromium Linux builds, here it is:
http://build.chromium.org/buildbot/snapshots/chromium-rel-linux/

Chrome's getting extensions: http://blog.chromium.org/2009/05/extensions-at-google-io.html

The guy forgot just one important thing: Most people don't use Firefox.

Jetpack is just a weekend knock off of the much better done Chrome Extensions, true story. Compare their couple month old API v. Jetpack's API and its blatantly obvious where Jetpack came from.

I'm hoping Safari and Opera adopt the Chrome Extensions model.

See also LastTab. I used the ctrl-tab functionality with preview until I adopted a Chrome-style workflow. LastTab with only the "Focus last tab selected when current tab is closed" option + Tabs Open Relative.

I'm not a fan of extensions that do a million different things.

There are the first Chromium snapshots available.

Webkit as we love it. Rough but usable. No Plugins so far, that also means no Flash (I'll count that as a feature 90% of the time). Speed - don't know, sites are just there. But here comes the boomer: it's the first (modern) browser that doesn't eat my frakking RAM like there's no tomorrow and makes the whole machine feel sluggish after two hours of extensive web browsing.

There dare daily builds available for all platforms here http://build.chromium.org/buildbot/snapshots/ For the mac build, to get an idea about what status it is in and what works and what doesn't you can see my post on it http://www.manu-j.com/blog/download-updated-native-google-chrome-for-mac-os-x/230/

BTW, it's available under dev channel for now. http://dev.chromium.org/developers/design-documents/extensions/samples

This is the mac daily build page

http://build.chromium.org/buildbot/snapshots/sub-rel-mac/

I do NOT want 30 different processes, all firefox tabs, using up all my cores just to run spam animations.

No one would implement multiple processes it that way. Google chrome for example uses "Process-per-site-instance" model Chromium process models

http://build.chromium.org/buildbot/snapshots/chromium-rel-xp/ Choose your revision, and run mini_installer.exe Or, extract chrome-win32.zip for a portable version. (it still leaves behind its settings in your AppData directories, though)

take the code compile it yourself

From the Windows build instructions: "Prerequisite software: [...] Microsoft Visual Studio 2005 Pro (8.0) or later. Visual Studio Express won't work. Visual Studio 2005/2008 Pro Trial will work." But I don't see who would want to spend $637.49 just to unbrand Chrome once the 90-day trial runs out. One could buy a Mac Mini and use the Mac build instructions for less than that.

Everything on my Ubuntu installation is 64 bit. Every single application. Since I'm using Chromium, I guess that I have V8 in 64 bit. Just add the Chromium repository to Apt, then apt-get the source. You don't even have to know how to compile. (I do know how to, sort of, but I'm certainly not proficient - just let your installer do the work!)

I suspect it's using ia32-libs and not actually 64 bit. I have two reasons for suspecting this.

1) Chrome does not support 64 bit builds

2) The Ubuntu Chrome Daily PPA page says "no native 64bit debs planed for now. The amd64 package is using ia32-libs."

Yep, like i said, it's a shame, The idea is that we would use it in our project which is a telephony server that runs much better on 64bit, that's really the only show stopper from our being able to try it instead of the spidermonkey library we use now.

Everything on my Ubuntu installation is 64 bit. Every single application. Since I'm using Chromium, I guess that I have V8 in 64 bit. Just add the Chromium repository to Apt, then apt-get the source. You don't even have to know how to compile. (I do know how to, sort of, but I'm certainly not proficient - just let your installer do the work!)

I suspect it's using ia32-libs and not actually 64 bit. I have two reasons for suspecting this.

1) Chrome does not support 64 bit builds

2) The Ubuntu Chrome Daily PPA page says "no native 64bit debs planed for now. The amd64 package is using ia32-libs."

Just use either portable chrome or portable chromium then, replacing the app folder with nearly-hourly builds from http://build.chromium.org/buildbot/snapshots/chromium-rel-xp/LATEST (delete rlz.dll). But no auto-updates this way.

The fastest way to get info from a disk is sequentially.

I disagree (for typical desktop usage)

I read an interesting article about disk IO in the Google Chrome browser. When the browser starts, it "needs" to load the bookmarks, cache metadata, etc from disk. That would take time, slowing browser startup. So what Chrome does is it starts with no bookmarks and without initialising the cache system, and it loads the data in background threads. By the time you've typed a few characters in the address bar (which is when the data is actually needed), it's been loaded.

This gives the appearance of the disk I/O taking zero time.

Incidentally, for desktop usage if you're going to read lots of small files, the thing which takes the time is the seeks. So you really want to submit a large number of parallel requests and allow the OS disk scheduler and/or the disk (assuming NCQ) to optimise by doing elevator seeks - where the heads only move in one direction and don't keep jumping back and forth. Sequential reads are only quicker if you're reading a single large file on a defragmented disk.

As stated on the warning page.

There are daily builds you could try. They're pre-alpha, though, so don't expect too much yet. Or you could build it from source, it's not too hard. See http://chromium.org/

Mod parent -1 uninformed

http://dev.chromium.org/developers/design-documents/extensions

There is Chromium for Windows, and it doesn't come with all of Google's tack-ons.
Latest build here.

See the "this browser is not ready" start page:

Chromium is an open source browser project. Google Chrome is a browser from Google, based on the Chromium project. This is a build of Chromium. No versions of Google Chrome for Linux will exist until Google makes an official release.

Not a wrapper.

Check out the Chromium Wiki for more info:
http://dev.chromium.org/Home

I apologize. The best way to go about this is the following:

1) Go here and download and run the Google Chrome Channel Changer:
http://dev.chromium.org/getting-involved/dev-channel

2) Change to the DEVELOPER channel. Releases happen more often, a later version can be found here, but the versions can be less stable, depending on whether the developers were having a good week or not. ;)

3) Go to the ABOUT dialog box in Google Chrome and it will now say there is a new version. Install it.

4) Once this is complete, change the shortcut for Google Chrome and add --enable-user-scripts after the chrome.exe path and name.

5) Google Chrome will now support user scripts. These are just greasemonkey scripts for those who are unfamiliar with the term.

6) Place your scripts here:

C:\Documents and Settings\your-windows-user-name\Local Settings\Application Data\Google\Chrome\User Data\Default\User Scripts

"Default" is the default profile... if you use a different profile for Chrome, you'd want to go into that path instead.

7) Most user scripts are supported. The ones which are not supported are the ones which use certain GM_ commands. Simple ones like basic ad blockers, ones which force an HTTPS connection for certain services, once which change URLs for links, etc... all tend to work. I've had to tweak some user scripts to avoid certain issues, but some work right out of the box.

Again, it's not "simple"... it's not "clean"... but for now, it works... and is clear that Google is taking the right direction to supporting this stuff. I imagine that, eventually, Google Chrome supported user scripts will become more abundant, will be easily installed via a basic wizard within Chrome, and will likely be found in a "gallery" hosted by Google some day.

Google Chrome leverages this Vista feature. http://dev.chromium.org/developers/design-documents/sandbox/Sandbox-FAQ The sandboxing feature in Vista is implemented with process integrity levels. A process with "low integrity" is severely restricted in what it can do on the system. Adobe could use this feature for Acrobat. They actually do use it (they have to) for Flash, as the Flash plugin in IE runs inside the sandbox. The crux is that a sandbox is often so severely restricted that you need a helper (called "broker") process to do the privileged stuff such as downloading/uploading files etc. Flash actually made their own broker process for Flash and left a stupid bug in there. That was the flaw which allowed Vista to be compromised in last years' pwn2own contest.

If you'd like to get a preview of the Mac release, there are up-to-date builds available here so you don't have to compile it yourself.

Via an older article on Cnet I found the Chrome extensions document, spotlighted on November 29th by Google programmer Aaron Boodman. From the document:

Use Cases
The following lists some types of extensions that we'd like to eventually support:

• Bookmarking/navigation tools: Delicious Toolbar, Stumbleupon, web-based history, new tab page clipboard accelerators
• Content enhancements: Skype extension (clickable phone numbers), RealPlayer extension (save video), Autolink (generic microformat data - addresses, phone numbers, etc.)
• Content filtering: Adblock, Flashblock, Privacy control, Parental control
• Download helpers: video helpers, download accelerators, DownThemAll, FlashGot
• Features: ForecastFox, FoxyTunes, Web Of Trust, GooglePreview, BugMeNot

This list is non-exhaustive, and we expect it to grow as the community expresses interest in further extension types.

Emphasis mine.

Chromium Developer Documentation quote:

"The following lists some types of extensions that we'd like to eventually support: ...
* Content filtering: Adblock, Flashblock"

Notice that it says, "we'd like" to "eventually" support. Ask yourself, who is "we"? What is the corporate power of the "like" of that person?

I read that as the initial ideas of a very idealistic programmer or program manager who, of course, uses AdBlock Plus and Firefox. I'm guessing it is not Google corporate policy. It was not reviewed by the Google public relations department; the people who work in that department probably have no technical knowledge. It remains to be seen what Google corporate policy will do to the initial design ideas.

The fact that Chrome is open source is not as important as some of those who comment seem to think. Firefox is getting $50,000,000 per year from Google, and look at slow pace of development. For example, the Firefox CPU-hogging bug has improved recently, but now with version 3.05 it has gotten worse.

It costs a lot in time to fork a huge project. A group of very skilled people would have to donate their time. That doesn't always happen.

idlemachine, I have a question for you. Your link to Chromium.org does not have "[chromium.org]" after it. My link to exactly the same web page does. How did you do that?

I'm guessing that Chrome will never have AdBlock Plus and NoScript.

That's a common but incorrect belief, at least according to this official design doc (emphasis mine):

The following lists some types of extensions that we'd like to eventually support:

* Bookmarking/navigation tools
* Content enhancements
* Content filtering: Adblock, Flashblock, Privacy control, Parental control
* [...]

If you want to see evidence they're working on delivering a Mac version, you might start at the Mac build instructions or the revision history.

Chrome isn't even open source, Chromium is.

Also, my understanding is that Chromium is Chrome with the logo / branding stripped out for trademark reasons, similar to Netscape / Mozilla in the early days. To say that they're separate at the moment is like arguing Linux vs Gnu/Linux. One's technically righter than the other, but they still both work.

Google portraying Chrome as open source is a Big Lie. If it was truly open source, I would be able to download the source and build the exact same binary. Instead, what they do is distribute a binary that you don't get all of the source to. That means it's based on open source, but the product itself is not open source. A proprietary binary based on 99% open source code is still a proprietary binary.

And it's not just trademarks. It also includes functionality that reports back to Google. From a blog post by a Google product manager (bits bolded by me):

"Chromium is the name we have given to the open source project and the browser source code that we released and maintain at www.chromium.org. One can compile this source code to get a fully working browser. Google takes this source code, and adds on the Google name and logo, an auto-updater system called GoogleUpdate, and RLZ (described later in this post), and calls this Google Chrome. [...] RLZ: When you do a Google search from the Google Chrome address bar, an "RLZ parameter" is included in the URL. It is also sent separately on days when Google Chrome has been used or when certain significant events occur such as a successful installation of Google Chrome. RLZ contains some encoded information, such as where you downloaded Google Chrome and where you got it from. This parameter does not uniquely identify you, nor is it used to target advertising. This information is used to understand the effectiveness of different distribution mechanisms, such as downloads directly from Google vs. other distribution channels. More information is available in the Google Chrome help center. This cannot be disabled so long as your search provider is Google. If your default search provider is not Google, then searches performed using the address bar will go to your default search provider, and will not include this RLZ parameter."

Yeah yeah, Google says they don't invade your privacy, but privacy policies aren't a replacement for open source. Wouldn't you like the source code to auto-update and phone home behavior? Wouldn't you have the source code if Chrome was actually open source? It isn't. Chromium is open source. Chrome isn't.

Probably will actually be Chromium, the non-branded, open-source distro of Chrome.

They are going to support extensions. The list includes content-filtering extensions like ad-block.

You can run ARM Debian without any porting work - that will give you all non-GUI apps working straight away. The G1/HTC Dream does not run Xorg, so GUI apps will not work. The Android desktop is based on the Skia graphics library. So for GUI apps you have two choices: 1) Port to Skia or 2) Get Xorg running on the G1. (Actually, you could use embedded QT or GTK directly on the framebuffer, but base Xorg would be more useful..) The G1 kernel does expose a standard framebuffer device to user space, so getting xorg running should be easy enough. The difficulty comes if you want to run the Google Skia apps on top of that - Skia has a Cairo backend, which in turn uses X, so in theory it would be perfectly possible to link those libraries and run Skia apps. Over time I expect we will see the emergence of some standard distro that unifies all this stuff in a reasonable way. Nokia's Maemo has already shown that it is possible to run a cut down desktop with standard Linux apps on this kind of device.

I'd rather talk about Chromium's nascent plans for extensions, which will hopefully bring AdBlock and NoScript (or at least similar functionality) to Chrome.