Havoc's Blog

I meant to toss out a couple thoughts when Robert
blogged about index funds, reminded by a Wall Street Journal
article yesterday pointing out that the S&P 500 has gone nowhere over
the last 9 years.

Here are said thoughts:

• Lots of sensible advisers will tell you to buy index funds, but
  importantly, the advice is not simply “buy index funds.”
  There are at least two other critical details: 1) asset allocation
  across multiple well-chosen indexes, maintained through regular
  rebalancing, and 2) dollar cost averaging (or,
  much-more-complex-but-probably-slightly-better, value averaging). The
  advice is not to take your single lump sum and buy and hold a
  cap-weighted index forever. The advice is an investment
  discipline which involves action over time, and an initial
  choice among indexes. An index-fund-based
  strategy is not completely passive, it involves some active risk
  control through rebalancing and averaging.
• For example, Warren Buffett in a recent
  interview adds “don’t put all your money in at once,” when he
  gives the index fund advice:

  “I think everybody should read
  Jack Bogle’s book. … what you really want to do is you want to own
  American industry which is going to do fine over time, but you want to make
  sure you don’t put all your money in at once because you might pick just the
  wrong point. But if you buy in over time into a wonderful business, which is
  American industry, and you make sure you don’t go in at just the wrong
  times, when people get excited, and you get to keep your costs low
  … you’re going to beat 90 percent of the people because they’re going
  to run up unnecessary costs.”

• The S&P 500 has been nowhere for about a decade, but investing in a
  balanced portfolio with multiple asset classes, averaging over time
  from 1998-2008, and rebalancing regularly, has worked out just
  fine.
• A great innovation is the “Target Retirement” fund, now the default in
  many retirement plans, which implements the asset allocation and
  rebalancing for you.
• ETFs can be slightly lower in annual expenses than a normal mutual
  fund, but they also have downsides. Remember the discipline involves
  dollar cost averaging and rebalancing. Thus, you will have commissions
  (at most brokerages), and spreads (at all brokerages), and these are
  not one-time costs. Also, a target retirement fund is the
  right choice for many people, and at least until recently these were
  not available in the ETF structure.
• Regular mutual funds have some downsides too, but, for me if you’re a
  long-term investor the ETF vs. regular index fund choice seems like a
  bit of a wash. Vanguard Total Stock Market regular share class is
  0.19% a year, or $19 per $10,000; the ETF share class is 0.07% or $7
  per $10,000. The $12 difference is pretty likely to be lost on
  commissions and spread. Contrast either one with an actively-managed
  fund that might be $100 per $10,000. There are some small tax
  differences as well, but those don’t matter in a retirement
  account. Bottom line, maybe ETFs are overhyped if we’re talking about
  a buy-and-hold investor saving for retirement. If you do use ETFs, be
  sure your commissions are darn low.
• In a bear market, perhaps it helps to think of yourself as investing
  in a discipline, not in a fund. The discipline is to buy an asset
  allocation and to average and rebalance over time. The question is
  whether this discipline is working overall, over a 10-year period, not
  whether each asset class is up or down today. And if you abandon
  the discipline in a bear market, the discipline will not work.

Anyway. I am not religious about index funds, personally I use about a 50/50
mix of indexing and other strategies. Not to “beat the market” – I
have no idea why discussions center around beating the market, since
doing so has nothing to do with anyone’s goals or their
planning. “Beating the market” in this context has a technical
academic meaning anyway (“alpha”) that doesn’t quite match the
common sense meaning.

Nobody’s retirement hinges on beating the market. Most people’s goals
hinge on whether they make some kind of decent return or not. A major
goal in investment planning should be to increase the probability of
adequate returns, in my opinion. (Where “adequate” is defined
by your personal goals and resources, it’s not an absolute thing. And
where the probability includes human behavior – not just what you
should do but what you will do.)

“You can’t generate alpha so buy index funds” makes no sense to me. I
would say, “dollar cost averaging plus appropriate asset allocation
plus low-cost index funds is one simple, proven discipline to give you
a good shot at decent returns.” Whether decent returns are adequate,
of course, depends on your goals and whether you are saving enough
every month…

(This post was originally found at http://log.ometer.com/2008-03.html#27)

Elijah posted a humble
note about Easy
GIT, but don’t be deceived. Easy GIT is completely usable for
daily work, and it’s a one-file perl script you can just add to your
path. It hides git almost completely and is pretty much exactly what
I’ve been looking for.

Elijah rocks, which I already knew, but now I have even more evidence.

git clone http://www.gnome.org/~newren/eg/eg.git, stick
the checkout directory in your path, type eg help, and enjoy.

(This post was originally found at http://log.ometer.com/2008-03.html#14)

Samurai-Sword
Maker’s Reactor Monopoly May Cool Nuclear Revival

Japan Steel Works apparently melts 600 tons of steel at once into a
giant one-piece nuclear reactor component that costs $350
million. They also make $10,000 samurai swords.

(This post was originally found at http://log.ometer.com/2008-03.html#14.2)

For the GTK+
hackfest I wanted to start a discussion about why people are doing
custom “canvas” things (HippoCanvas, Clutter, GooCanvas, Pigment,
etc.) and how GTK+ could evolve to address the same problems.

The proposal in a nutshell is that widgets should be one kind of
object in a more flexible scene graph. But there are many details.

Here
is the thread, Google
document, and the document is embedded right here:

The two GTK+ enhancements I’m most excited about are gobject-introspection
and this scene graph (“canvas”) problem.

(This post was originally found at http://log.ometer.com/2008-03.html#7)

Browsing from an old
interview with Elijah I found a post
I wrote a couple years ago.

Here is an idea I still like, but had forgotten to keep using:

The old usability cliche “users are busy not stupid” is exactly right,
because the issue is that they are busy doing something and
they will always only care about things they need to care about to do
that thing. So the relevant question is not whether they find
something confusing, but whether a specific person would care
about it at a particular point in using the software. Much better to
talk about “interestingness” than “confusingness” when deciding what
to strip down (not least because interestingness is more obviously
relative to the audience).

As you design something, ask “is this relevant to what people are
trying to do?” rather than “is this confusing?” – I like it. Maybe
I’ll remember it this time 😉

It doesn’t matter whether people could figure something
out. It matters whether they’re interested in figuring it out – is it
part of what they’re trying to do, or an annoying sidetrack?

(This post was originally found at http://log.ometer.com/2008-03.html#5)

Spent part of today torturing the
Clutter guys with disruptive, untested patches … woo hoo! (I do
plan to clean up and debug the patch, if the idea goes over well.)

Clutter is a pretty fun
change from the usual 2D toolkit stuff, and nicely done in general.

The other day I also wrote up some
quick
notes on making Clutter work better as a canvas inside another
toolkit such as GTK+; incidentally, these same changes would make
Clutter a great foundation for a compositing manager in Metacity…
someone should look into that 😉

Also missing is the other direction – seamless, easy embedding of
GtkWidget into a Clutter canvas – but I haven’t had a chance to dig
into this one yet. Ideally ClutterEntry
is just not necessary – at least if you’re already linking to a
regular toolkit. More importantly, the truly difficult widgets such as
TreeView, TextView, WebKit, and Gecko are handy to reuse.

Easy blending of GTK+ and Clutter would open a lot of doors for
jazzing up GNOME.

(This post was originally found at http://log.ometer.com/2008-02.html#23)

My new company is called LiTL, and we have some job listings up. We’re looking for
desktop developers, web developers, QA engineers, and Linux
distribution wranglers, among others.

Send us a note (to jobs @ litl) to introduce yourself. We’d love to
meet you and tell you more about the company.

(This post was originally found at http://log.ometer.com/2008-02.html#18)

I thought this
was a good post on how to recognize and hire good software
developers if you aren’t a software developer yourself. Or even if you
are a software developer yourself.

(This post was originally found at http://log.ometer.com/2008-02.html#4)

Jeff started a blog thread about handling out-of-memory.

For anyone who’s interested in this, check out D-Bus (or rather, the
libdbus C implementation of D-Bus) for an example of nontrivial code that
attempts to handle out-of-memory.

I would wildly guess that the OOM handling adds 30-40% or so to the
number of lines of code, and thus the size of the library on disk.

There’s also a historical note; I wrote a lot of the code thinking OOM
was handled, then later I added testing of most OOM codepaths (with a
hack to fail each malloc, running the code over and over). I would
guess that when I first added the tests, at least 5% of mallocs were
handled in a buggy way – the handling code crashed, locked up, or
something.

(At one point I applied the same testing strategy to libxml2, and it
was also a crash-fest. Conclusion: if you haven’t tested all OOM
codepaths, they do NOT work, they’re just sitting there causing bloat.)

When adding the tests, I had to change the API in several
cases in order to fix the bugs. For example adding
dbus_connection_send_preallocated() or DBUS_DISPATCH_NEED_MEMORY.

To make OOM handling work, you have to make pretty much every part of
the code transactional – you have to be able to atomically roll back what you
were doing. In the dbus-daemon case, generally this means we roll back
the handling of the current message, then return an error to the
sender of the message.

In a GUI program, I couldn’t even guess what you’d do after the
rollback; you have no memory so can’t open a dialog, not that an
out-of-memory dialog is helpful in the first place. Best I can think
of would be to block for a while then retry the malloc, but that can
be done inside of g_malloc(), so does not require OOM handling.

dbus-daemon was the motivation for OOM handling, since dbus-daemon
can’t crash. As a side effect, though, libdbus allows apps to check
for and handle OOM. This gives us empirical evidence for how many apps
will check for OOM if a library allows it. I’m pretty sure the answer
is zero or close to it, in the libdbus case.

(This post was originally found at http://log.ometer.com/2008-02.html#4.2)

If you want to play with compositing on Fedora 8 using the Intel
drivers, here’s how I got it working.

• For testing, you can run a second X server on the
  hardware. However, you first need to disable DRI on the main X server
  (and not use a compositing WM on the main X server). This is done by
  adding Option "NoDRI" to xorg.conf. If you don’t have a
  xorg.conf (I didn’t), run system-config-display and let it write out a
  minimal one. Add the NoDRI option to the Device section. Next, copy
  xorg.conf to something like xorg-dri.conf, and re-enable DRI in the
  copied file. Then you can run a second X server as something like
  “X -config xorg-dri.conf -audit 0 -br -ac :8 -nolisten tcp
  vt8“. Careful: if your main X server has DRI running, you won’t
  get DRI on the new X server even though it’s in the config file. So be
  sure the main server lacks DRI (use “glxinfo” to check).
• If you run Compiz on a server without DRI, the error is
  "No GLXFBConfig for default depth, this isn't going to work."
  You must have direct rendering enabled (check glxinfo).
• Once you enable DRI, however, Compiz will say the
  GLX_EXT_texture_from_pixmap extension is missing. To fix
  this, you have to set LIBGL_ALWAYS_INDIRECT=1 in the environment.
  The desktop-effects control panel that comes with Fedora sets
  this env variable when it runs compiz. Yes, you should have direct
  rendering enabled, and then you have to set LIBGL_ALWAYS_INDIRECT=1.

(This post was originally found at http://log.ometer.com/2008-01.html#28)