Whatever

A small amusement for the weekend:

I recently ran across the Whatever button extension. It’s a wry take on the way users have been conditioned to automatically click through any prompt that interrupts their workflow. Sometimes it’s just ignoring a useless popup, sometimes it’s ignoring something that has security implications.

The Whatever Button extension basically concedes defeat, and relabels these “Ok” / “Accept” / etc. buttons to read what they really mean: “Whatever”. When a web site presents you with lengthy Terms of Service legalese, ignore it (like you did before), roll your eyes, and click Whatever. Whaaaaaat-eeeeeever. You may have just sold your first born, but immediate gratification is what you want, and you want it now dammit!

So, if you’re feeling cynical, try it out.

(Whatever.)

Some related blather:

  • A canister of tasty Monbana chocolates appeared in the office recently. Yay chocolate fairy! I wasn’t familiar with their name, so I Googled it. The first Google result is Monbana’s Legal Terms page — sadly, I was not particularly shocked to see such a page, and assumed it was just another click-through pseudo-legal agreement before entering the site. “By using this site, you have accepted these terms and conditions.” Whatever.
  • Will someone slap Sun’s marketing folks already? There’s been interest in using Solaris tools to help with developing Mozilla, which means downloading Solaris to install it. But to download anything you are forced to first create a “Sun Online Account”. Whatever. The fine engineering folks have assembled a pre-installed VMWare image, which means it now takes more effort to start downloading the damn thing than to actually use it… Grr. Mozilla has been investigating what causes people to abandon Firefox at various points after visiting the download page; I similarly wonder how many people click Sun’s “Free Download” link and then give up before getting to an actual download.

OS X and virtual “bloat”

There’s a lot of work going on these days to improve Mozilla’s memory usage, and it’s a complicated issue with different facets. When discussing this with users, one thing that sometimes comes up is the difference between a process’s working set, and its total virtual memory size. To simplify grossly, the working set is often the more important number, as it’s the amount of physical memory actually being used. A process could have gigabytes of virtual memory assigned to it without any measurable performance impact to the system, as long as the working set stays small. I’m skimming over a lot of details, but the point is that a large virtual memory size may or may not be a practical problem.

I’ve noticed that on OS X, in particular, the amount of virtual memory a process is using seems to be a rather strange value. Here’s a few lines of output from the “top” command on my MacBook. Note the rightmost VSIZE column (total address space allocated) and the RSIZE column (the resident size, or working set) next to it. You can also use the OS X “Activity Monitor” tool, which reports the same numbers as “Real Memory” and “Virtual Memory”.

  PID COMMAND      %CPU   TIME   #TH #PRTS #MREGS RPRVT  RSHRD  RSIZE  VSIZE
  436 bash         0.0%  0:00.00   1    14    16   212K   832K   784K  27.1M
  425 firefox-bin  0.7%  5:32.43  12   151   758  98.9M  59.0M   125M   542M 
  349 Terminal     1.9%  0:48.52   6    94   150  2.39M  17.4M  15.0M+  370M 
  230 Colloquy     0.0%  5:57.88   7   151   952  46.5M  23.6M  53.1M   422M 
  228 iCal         0.0%  0:14.24   5   121   332  19.2M  15.2M  28.4M   383M 
  196 ntpd         0.0%  0:00.07   1     8    19  68.0K   708K   236K  27.1M

Gosh, there’s Firefox with 542MB of virtual memory. I’ve been browsing a while with lots of tabs, so maybe I shouldn’t expect it to be tiny. Then again, starting it with a blank page results in just a 39MB RSIZE, but VSIZE is still over 540MB. Look at iCal and Colloquy (an IRC client), which both weigh in around 400MB… Hmm, that seems like a lot. Quite a few other processes are also in the 350MB ballpark; in fact, top reports a total of over 10GB of virtual memory assigned on my system. And, hmmmmmm, even standard Unix programs like bash and ntpd are grabbing 27MB of VM — what’s going on?

OS X has a nifty little utility called vmmap that lets you see exactly what’s consuming address space in a process. The full output is rather verbose, but it has a summary too:

==== Summary for process 436
ReadOnly portion of Libraries: Total=2960KB resident=2684KB(91%) swapped_out_or_unallocated=276KB(9%)
Writable regions: Total=26816KB written=76KB(0%) resident=220KB(1%) swapped_out=0KB(0%) unallocated=26596KB(99%)

REGION TYPE             [ VIRTUAL]
===========             [ =======]
MALLOC                  [  18536K]
Stack                   [   8192K]
__DATA                  [    188K]
__IMPORT                [     24K]
__LINKEDIT              [    500K]
__PAGEZERO              [      4K]
__TEXT                  [   2460K]

That’s the summary for the “27MB” bash process. It looks like 8MB is reserved for the stack, 18.5MB is reserved for the “DefaultMallocZone”, and about 2.5MB (__TEXT) is code and static data. [The full listing shows that the bash code is only about 500K, the rest of the 2.5MB is all system libraries.] Another nifty OS X utility, heap, confirms that only 85K of that 18.5MB malloc area is actually being used. So, the conclusion here is that most of the alarming 27MB of bash‘s VM size is just unused address space (which is dirt cheap) and default system stuff. The amount of memory usage directly attributable to bash is really quite small. Smaller, in fact, than the 784K working set top reports.

So, now the $542,000,000 question… What’s up with Mozilla’s virtual memory size? (after the jump, to avoid annoying planet.mozilla.org readers!) Continue reading OS X and virtual “bloat”

Solaris, reporting for duty

Solaris has recently gained some attention from Mozilla developers, largely due to the availability of DTrace. Rob Sayre, in particular, has recently been putting it to good use tackling performance and memory problems.

I just reinstalled the latest release, Solaris Express Developer Edition 9/07, and helped update the Solaris Build Prerequisites page on DevMo. I’ve used Solaris for years, and thought I’d share a few other tips for anyone else who might be installing Solaris to play around with this stuff…

  1. Solaris is fairly compatible with x86 hardware these days, but as with Linux configuring video cards can be a pain. My old desktop died, so I got to reinstall again on a new machine. With an ATI video card. It even almost worked (unaccelerated, wrong resolution, etc etc)! Long story short — just get a Nvidia card. The Solaris support is much better.
  2. Change root’s shell (passwd -e root). /sbin/sh sucks, and for a desktop machine the holy wars about if it’s safe to change root’s shell are largely irrelevant.
  3. I use “man -k foo” all the time to look things up when I can’t remember the exact command. This works out-of-the-box on Linux and OS X, but on Solaris you’ll need to run “catman -w” first (as root).
  4. BlastWave.org seems to be the new hotness for prebuilt (binary) packages of open source software. I used sunfreeware.com for years, but it’s a little more effort involved.
  5. Synergy is great for using a single keyboard/mouse across multiple systems. “pkg-get install synergy” on the Solaris side (yay BlastWave), and install QuickSynergy on the OS X side.

Getting a functional environment is kind of important too. I do this:

.bash_profile:

. ~/.bashrc

.bashrc:

# Make prompt prettier the "bash-3.00"
export PS1="[solaris] W \$ "

# Set path to all the useful stuff.
# /opt/csw is the Blastwave stuff
export PATH=~/bin:/opt/csw/bin:/usr/bin:/usr/sbin:/sbin:/opt/SUNWspro/bin:/usr/sfw/bin:/usr/X11/bin:/usr/dt/bin:/usr/openwin/bin:/usr/ucb

export MANPATH=/opt/csw/man:/opt/SUNWspro/man:$MANPATH

# Build environment, else we get gcc...
export CC=/opt/SUNWspro/bin/cc
export CXX=/opt/SUNWspro/bin/CC
export LDFLAGS="-L/usr/sfw/lib -R/usr/sfw/lib"

# Allow vi-like scrolling/searching in "man foo" output.
export PAGER=less

I’ll try to update this blog if I change stuff.