Showing posts with label Chrome. Show all posts
Showing posts with label Chrome. Show all posts

Sunday, August 25, 2013

Slightly Interesting Javascript Benchmark

I have an Asus CG5275 desktop, and decided to try out the Mandelbrot JavaScript benchmark at http://alexey.radul.name/ideas/2013/cleverness-of-compilers/ with the three browsers I use most, Chrome 29.0.1547.57, Firefox 23.0, and Opera 12.16. I expected Opera to be the slowest, and was not disappointed.

The mild surprise was that Firefox was almost four times as fast as Chrome. Here are my timings on the Asus with the above-mentioned URL and browsers:

Browser             Size    Time      Relative
Chrome 29.0.1547.57 500x500  9562 ms  3.86
Firefox 23.0        500x500  2478 ms  1
Opera 12.16         500x500 19464 ms  7.85

Opera took just about twice as long as Chrome, and Firefox was almost 4 times as fast as Chrome. This is on an Intel i5 at 3.2 GHz running Linux Mint 15, Mate, kernel 3.8.0-29-generic. It's a 4-core machine, which makes me curious about the almost 4x speedup of Firefox vs.. Chrome.

[ Note added about 15 minutes after original posting: Mate's System Monitor makes it appear that all three versions use just a single core. No real surprise--this is JavaScript, after all. ]


Sunday, May 19, 2013

Amusement in Advertising from Google

Web access seemed sluggish this morning, so I hopped over to http://www.speedtest.net/ to look at the results. They were okay:


However, this was with Firefox, and the ad suggested results would be faster with Chrome. Really? I have Chrome, and use it often. Here are my Chrome results:


Faster? My throughput with Chrome was just a little slower but the ping times suggest a lower RTT with Chrome, which could possibly suggest a faster scripting implementation. However, this was from two different servers, one reportedly in Frederick and the other in DC, and just one shot each. Perhaps a more detailed study is warranted, but not now.

Friday, May 17, 2013

HTTPS Everywhere Rule Set for userpages.umbc.edu

Many of the servers at  UMBC do not support HTTPS, but userpages.umbc.edu, the server(s) for user home pages, does. However, probably few people access it securely. For those using HTTPS Everywhere, I wrote an extension for HTTPS Everywhere:

<ruleset name="userpages-UMBC">
  <target host="userpages.umbc.edu" />

  <rule from="^http://userpages\.umbc\.edu/" to="https://userpages.umbc.edu/"/>
</ruleset>

I haven't figured out how to install this in my Chrome profile, but it works fine with Firefox HTTPS Everywhere. Tips would be appreciated.

First, HTTPS Everywhere must be installed. Most people should install it anyway. The EFF is doing great things for the public, which is why I donate annually.

Second, the file must be installed "in the HTTPSEverywhereUserRules/ subdirectory in your Firefox profile directory" (see the EFF page). Then restart Firefox. On my Xubuntu system, this directory was
~/.mozilla/firefox/xxxxxxxx.default/HTTPSEverywhereUserRules. The penultimate part of that path will vary from system-to-system.

[ Originally omitted; added 2013-06-09 ]:
Third, the file name must match the domain name, userpages.umbc.edu in this case.

Get HTTPS Everywhere from the EFF here.

Saturday, July 14, 2012

Chrome as Nagware

Now whenever I start Chrome, it asks me to sign in to the browser. Why? It's a browser, not an OS. Apparently this will let me sync my bookmarks, history, and settings on all my devices: "With Chrome's sign-in feature, you no longer need to fret about your bookmarks or apps being "stuck" on one computer." Who's enough of a dweeb to fret about this stuff?

Different machines have different characteristics, so maybe I want different settings. Maybe I want different bookmarks, history, and apps at home and at work. Maybe I want to try out a setting or an app, but not spread it across all my systems until I decide I like it. Maybe an app is stealing data. Do I want it spread across all my machines quickly and automatically?

I think this is a feature that some people will want. But the way Google is going about it, nagging us to log in every time we start the browser, apparently with no setting to disable the request, feels coercive. And when a corporation attempts coercion, I worry about ulterior motives.

Saturday, August 13, 2011

Chrome: Blocking HTML Referer [sic]

It's easy to block HTML referrers in  Firefox: visit about:config and set network.http.sendRefererHeader to zero.

It's easy to block referrers in Opera: Make sure "Send Referrer Information" is unchecked at Opera | Settings | Quick Preferences

So how about Chrome? The man page is incomplete, not saying how to do this.

Googling sent me to a a Chrome extension. I have no reason to trust the author of that extension, so I looked a little more.

The answer is, surprise, in the Chrome help forum,  http://www.google.com/support/forum/p/Chrome/thread?tid=63a866565ba8664f&hl=en

The thing is, I don't usually start Chrome from the command line, and I don't recommend doing so. If Chrome (or Firefox, or Evince, etc.) are given a command shell, they dump gobs of junk to, probably, stderr. So it's necessary to change the shortcut from which Chrome starts. Gnome instructions follow; Windows instructions, untested, are here. [ Note added 2012-09-10: I think the following is incorrect and that Firefox does require an extension to block referers. Bad Firefox, bad. Original text: I do not endorse their method of blocking referrers in Firefox, as it is simply not necessary to install an extension to do this. ]

In System | Preferences | Main Menu | Internet (your system may vary) right-click on Google Chrome. Add --no-referrers to the end of the command line. Kill Chrome. Restart Chrome through the updated shortcut.

On referrers: this is from a time when the Internet was a less dangerous place. I have trouble seeing how this was ever a good idea, but now it is simply an invasion of privacy. It isn't likely that any subsequent version of HTML will drop this, but it would be nice if browsers would default to not sending referrer information.

A note on the misspelling 'referer': the word was misspelled in RFC 1945 (!996 Berners-Lee, Fielding, Frystyk), which is a bit odd since they spelled 'referred' correctly. Wikipedia says the misspelling originated in a different document, by a different author. Fielding says that neither 'referer' nor 'referrer' were in the UNIX spell program at the time. I thought by 1990 everyone was using ispell or aspell; okay I never actually thought that. Paper dictionaries weren't available at the time? I'm just happy to not have my name as prominently associated with a dumb little mistake like this. Of course, it is just a dumb little mistake.

Friday, August 5, 2011

Stupid Chrome Tricks

I'm using Chrome 14.0.835.15 dev on Ubuntu 10.04 LTS and I viewed a web page today, the bottom left of which looked like this:


Chrome wasn't rendering the ñ in enseñar correctly. However, I took this screen shot with the mouse pointer hovering over the link to enseñar.jpg, and at the bottom, it was rendering the word correctly. So Chrome halfway knew what encoding was in use. I went to Wrench|Tools|Encoding, and it claimed a UTF-8 encoding. Odd, this word should be rendered correctly with that encoding. I changed the encoding to ISO 8859-15, which was no better. Then I changed it back to UTF-8 since as default encodings go, that seems a good choice. Voila! The page was rendered correctly.

Apparently Chrome only said it was using UTF-8 initially, but after changing away from UTF-8 and then back, it suddenly really was using UTF-8.

Firefox 3.6.18 on the same system worked fine.

Another amusing thing is that Chrome on a Windows 7 system I occasionally use, when rendering the same page, says the original is in Afrikaans, and offers to translate it to English. Does Spanish look that much like Afrikaans?

Wednesday, July 20, 2011

Zombies, Firefox, Chrome, and all That

I've been noticing a lot of defunct or zombie evince processes lately and decided to take a couple minutes figuring out what's going on. In the Linux world, evince is a good PDF reader, certainly better than the one freely-available from Adobe. The problem isn't with evince: zombies cannot be held accountable.

All the zombies I had on my system this morning had one of two parent process IDs, that of Firefox (3.6.18) or that of Chrome (13.0.782.56 beta). When a process forks a child, it is supposed to wait() for the child. This can be done asynchronously, so it's little inconvenience for the parent process, and not much for the programmer of the parent process, if said programmer knows what he is doing. The child process, evince in my case, hangs around the process table as a zombie until the parent issues a wait(). This allows a parent process to keep track of the status of its children. Once the parent checks on the child, the child can go away.

Firefox and Chrome are apparently not checking on their children.

Friday, December 24, 2010

Migrating UMBC E-mail to Gmail

Some months ago UMBC began migrating e-mail to the Google cloud. This migration has been voluntary, but everyone will be moved over in January. I like Gmail, and considered moving some months ago, but decided not to because it was unclear whether there would be a solid wall (psychologically as well as logically) between my personal Gmail account and my UMBC Gmail account. This will not be an issue for a number of reasons:

(1) The accounts are separate, one reached via mail.google.com and the other via gmail.umbc.edu. I can reach both via the traditional mail.google.com URL, but with two different user names. I plan to explicitly go via (and link to) the gmail.umbc.edu address.

(2) I usually use Chrome for Gmail, but use Firefox for UMBC (myUMBC) services. Firefox add-ons allow me to selectively turn off undesired scripting within myUMBC and Chrome does not display PeopleSoft slop properly (I suspect it really does, however, and that PeopleSoft is simply not following web standards, but this is something for future investigation). So I will continue to use Chrome for personal Gmail, and will use Firefox for UMBC mail.

(3) I use different themes for the two Gmail services, and so my work and my personal screens look very different.

(4) The UMBC Gmail has "myUMBC" prominently displayed in the upper left.

(5) If all of that is not enough, I can simply return to an IMAP client for UMBC e-mail and continue to use the browser for personal Gmail.

The one drawback I have seen in my initial look is that Google says it may take several days for my old e-mail to migrate to Google. Since I have switched, I can no longer access UMBC Squirrel mail, and so none of my old e-mail folders are currently available via the web. Since grades are due in a couple weeks, this could become sufficient motivation to temporarily configure an IMAP client on my laptop. However, I do not foresee much inconvenience here except possibly delaying my grading of assignments submitted via e-mail.

I do suspect there is still a way into squirrel mail, but do not plan to spend any time finding the way.

Saturday, June 5, 2010

Different Browsers for Different Purposes, II

I previously commented on how I've started using different browsers for different purposes. I just visited the Weather Underground (wunderground.com) using Chrome, and it wasn't pretty. Right next to the weather map was this obnoxious flash animation. I quickly closed the frame and reopened it in Firefox, where NoScript screens out much of the obnoxious, much of the dangerous, and much of the insipid.

I had a similar experience last week while out of town. I don't have cable TV, and so am usually not subjected to cable news. Cable TV news is terrible, all commercials all the time and almost no news. Give me NPR and BBC any day. I've mostly stopped watching NFL games for the same reason.

Sunday, July 12, 2009

Chrome: Darn the Luck

It looks like my favorite feature of the Linux version of Chrome, the lack of Flash support, is going the way of the dodo: http://h3g3m0n.wordpress.com/2009/07/12/linux-chrome-flash-ext/ It's nice to have a browser that doesn't support Flash simply because so many web sites use it for advertising content. Perhaps advertising is the predominant use of Flash.

Wednesday, June 10, 2009

Chrome on Ubuntu

I've started using Chrome on one of my Ubuntu Linux machines, and kinda like it. It's fast, and pointing it at a PeopleSoft SA page doesn't lobotomize it (Firefox 3 slows to a crawl when SA is visited and remains at a snail's pace until the browser is closed--generally a mercy killing). A few minuses to date:
  1. The formatting on some of the PeopleSoft SA pages is sufficiently messed up as to be unreadable. It's not as though they were all that readable to begin with, though.
  2. It doesn't seem aware of my Flash installation, which may be a simple configuration issue.
  3. I can't right-click on an image and ask it to never load images from that particular server ever again. Thus I see a lot of ads I've trained Firefox to not fetch.