Oct 30, 2005

Gmail feature request - intelligent account selection for reply

Gmail feature request.

In Gmail you can define multiple accounts i.e. different “from” e-mail
addresses. One of those addresses is a default address also used for
every ‘reply’ command.

‘Reply’ should observe to which account the e-mail was sent and use the same account for reply i.e. if I have two accounts:

  • foo@bar.com
  • bar@bar.com

If I reply to an e-mail sent to my ‘foo@bar.com’ account, Gmail should
automatically use my ‘foo@bar.com’ account for ‘from’ address, and if
it was sent to ‘bar@bar.com’, it should use ‘bar@bar.com’.

Pretty please?

Category:  — Permalink

Oct 27, 2005

Pre-RTM Visual Studio 2005 uninstall tool

Pre-RTM Visual Studio 2005 uninstall tool is available. Not sure what the benefit is over doing manual unistall but I expect this tool to be useful. I’ve seen cases where betas of VS 2005 often were hosed after the install so I’m hoping that I’ll be able to install final version over my beta 2 without destroying my dev system. Full OS rinstall ain’t as much fun as it used to be.

Category:  — Permalink

A book to read, talks to listen to

“Producing Open Source Software” by Karl Fogel looks like a book I need to read. It’s available for free on-line.

I just finished listening to mp3 recordings of a few talks from Paul Graham’s Startup School. So far I’ve listened to talks by Paul Graham, Olin Shivers and Steve Wozniak. Recommended.

Category:  — Permalink

Storage is expensive

As someone hosting a few web sites I’m always looking for good deals on hosting. Currently I’m using ev1.net (for a cheap, dedicated server) and textdrive.com for a cheap, virtual server (mostly using their hosted svn repositories and mailman mailing list).


A mention of openhosting.com got my attention since they offer virtual hosted servers with unusual pricing: basically you pay for what you use, based on a very complicated formula.


I’ve used their rate calculation and found that the most expensive thing in hosting those days is storage and OpenHosting doesn’t compete at all with ev1.net if you’ll end up using a lot of storage. For example, 10 GB of bandwidth and 10 GB of storage on OpenHosting will cost you $80 a month. The chepest dedicated server on ev1.net is $99 but it gives you 1000 GB of bandwith and 60 GB of storage (on a 1.3 GHz/0.5 GB RAM machine). It’s even worse when you compare with 1and1.com developer package: 20 GB storage, 750 GB bandwidth for $20/month (although it’s not completely fair comparison: it seems that OpenHosting provides more freedom with SSH login and ability to install your own software which might be important for geeking out).

OpenHosting might be attractive if you use little storage (1-2 GB).


The worst part about the storage is that it usually doesn’t drop i.e. once you put something on a hard-drive, it stays there. This is unlike bandwitch which fluctuates depending on the current popularity of your website.


A lot of storage is probably not required for many people. If you host a simple weblog then 100 MB will be enough. But there are plenty of usages for which a lot of storage is required, e.g.:



  • having your own e-mail IMAP server, to be independent of various free e-mail providers
  • hosting your pictures. In those days of megapixel cameras it’s easy to fill up gigabates
  • using it as a backup for files

Makes you wonder how storage-heavy websites (e.g. flickr) can afford that. It seems that co-location is the only affordable option in those cases: you can colocate as much storage as you want and you only pay for it once, when you buy a hard-drive. Then you just pay for bandwidth and co-location costs.

Category:  — Permalink

Oct 26, 2005

Code-name Monad and the value of different perspective

ArsTechnica wrote another excellent review, this time of upcoming Microsoft Windows Shell, code-name Monad.

It’s a really cool shell, it blows every other shell in existence out of the water. But this is not a link-blog, I provide commentary and what Monad made me think about is the value of different perspective.

The first Unix shell has been developed in 1971, 34 years ago. Bash, currently the most widely used shell on Unix was developed in 1987, a slight improvement over 1977 Bourne Shell (thank god for whiskey and Wikipedia).

The most popular Unix shell, default on Linux, Mac OS X and most other Unix versions, isn’t much better than it was 30 years ago.

Open-source evangelists often argue that open-source is better than closed source because openness brings experimentation, experimentation brings improvements. They also argue that openness creates an evolutionary way of writing software, where lots of changes in divergent directions ultimately converge on the best solution, may the best piece of code win. The problem with this view is:

  • I don’t want to wait a million years for a usable piece of software; I need it yesterday
  • evolution created humans so it must be great. But it also created pigs and, when you think about it, compared to humans everything else is a failure; I don’t want software whose quality is comparable to the relative quality of a pig
  • you can only stretch a metaphor that much before it breaks. Software doesn’t have DNA, what might work for nature doesn’t have to work for software.


The fact that Monad is so much better than bash is a slap in the collaborative, evolutionary theory of software development.

If evolutionary way of writing software really is superior, then bash should be a shining example. It’s not an obscure utility no-one cares about - it’s an essential part of Unix.

It’s not like no-one tried to improve the shell - we have Korn Shell, C Shell, zsh, scsh (Scheme-based shell), Rsh, PWB Shell, Es shell, Almquist shell, tcsh. Instead of advancing the default they mostly succeeded in creating head-aches for system administrators.

During all this time all Microsoft had was cmd.exe, a sorry excuse for a shell, a glorified DOS box.

So how come a few Microsoft programmers, in just few years, leap-frogged 34 years of vigorous mutation and cross-breeding of Unix shells?

I have a theory:

  • the power of different perspective
  • the power of vision backed up by focused effort


It’s genuinely hard to come up with something better if there’s a strong history of good enough. It’s hard to develop a different perspective.

Unix shells are good enough and Unix heads for years derided Windows for its clearly inadequate cmd.exe and claiming the superiority of Unix’ “lots of little tools, connected” philosophy. Coming from a position of superiority, it’s easy to become complacent and dismiss many flaws in shell approach:

  • number of shells in popular use causes more problems that it solves
  • shell is a really weak programming language
  • forking a processes to get a list of files is inefficient
  • programs can only communicate via arbitrary, irregular text streams
  • which is why we have hacks like awk. Please mommy, don’t make me decipher awk scripts again, I’ll be good, I promise
  • some simple and frequently done things like grepping through files matching a given pattern in all sub directories of a given directory often require syntax so complex that I don’t even bother to remember what it is


Apparently all Unix programmers prefer to adapt to those problems than fix them once and for all. Microsoft, on the other hand, re-thought the problem and fixed all those messy problems.

I might write about the power of vision backed up by focused effort later.

And just in case you like to draw your own conclusions: please don’t. This is not “close source is better than open source” article. The world is not black and white. There is some good open source and some good closed software. There is shitty open source software and there is shitty closed source software. If there’s one grand conclusion to be drawn here about open source is that it works, but for reasons different than what the popular meme on the subject is.

Category:  — Permalink

Oct 25, 2005

Petzold on Visual Studio and mind corruption

Interesting article by Charles Petzold (the author of THE Windows programming book) where he ruminates on Visual Studio.

Good article; I like his observation about IntelliSense forcing a bottom-up programming.

Category:  — Permalink

Oct 24, 2005

Bloglines vs. Google Reader - the verdict

I’ve been a Bloglines user for ages now. I gave Google Reader a fair
chance by using it exclusively for a few days but I’ve made my
decision: I’m going to remain a Bloglines user.

Google Reader is fine and if Bloglines didn’t exist I would probably be
using it. I really like how easy it is to star documents - it’s one
advantage it still has over Bloglines.

Where Bloglines wins big time is efficiency of reading a large number
of posts. Their layout where one frame has a list of unread feeds and
the other frame a list of all posts from this feed heavily beats
Google’s “one post at a time” way, even when using keyboard navigation.
Google should add an option to read posts the Bloglines way.

I subscribe to a few high-frequency-scan-only feeds (like freshmeat’s
announcement feed) and marching through them one by one kills me.

Also, Bloglines seems faster (something that Google can fix, given enough time, but it’s not fixed yet).

What I would like to see in Bloglines is a better way to preserve
specific posts i.e. a copy of the “star this post” feature. Currently I
use the “clip this” but it requires too many steps. All I need is a
“star this” link that works like “clip this” but without asking any
questions and showing me new windows with confirmation. Just do the job
and don’t bother me.

So far the upside for me from Google Reader is that Bloglines added keyboard navigation. Ain’t competition grand.

Category:  — Permalink

Unsolved source control problems

Recently there was an explosion of new source control programs:
subversion, arch (and its many children), darcs, monotone, git,
codeville, mercurial (and more).

One of the reasons for creating them was the fact that CVS, the king of
the hill so far, lacks some basic features. Or, as a less cultured
person might say, sucks.

Almost all those new programs also
try to make open-source, distributed collaboration easier. Ironically,
I don’t see any of them solving the problems that I’ve come across trying to
make small contribution to various open-source projects so I don’t
think that they are solving the right problems.

In open-source projects there are often 2 sides:

  • project leader (or leaders) - those are the people who can commit changes to the repository
  • contributors - a casual contributor didn’t earn enough street cred to get full write access

First problem I saw is that submitting patches, reviewing and accepting
them is time consuming for both leaders and contributors which causes
projects to suffer because contributions are ignored which discourages
contributors from contributing more.

Ideally, the flow would be:

  • contributor does some code modifications
  • contributor notifies the leader
  • leader looks at modifications
  • leader applies modification to the main tree or marks them as rejected, providing explanation why they were rejected

With CVS it’s all very painful. Contributor has to generate patches. He
has to send them via e-mail or attach to a bug tracking system. Leader
has to apply the patch to his tree (which might be out-of-sync wrt. to
the tree against the patch was generated), preview the patch, respond
via e-mail or by making a note in the bug tracker.

I went through this a couple of times and for small changes it’s just
not worth the effort, especially if patches rot in the bug tracker for
weeks. But if a small change is not accepted quickly, I’m not going to
bother spending more time developing more extensive enhancements,
therefore the project looses me as a potential contributor.

Now, it might be just a social problem (it’s hard to imagine a tool
that would force project leaders to respond to submitted patches
faster) but I believe that a better tool would help a lot.

One option would be to give repository write access to anyone who asks, but the cure could be worse than a disease.

Some systems (e.g. darcs, arch) say that they’ll solve this problem by
making things more decentralized i.e. by making it easier to create
your own repositories based on the main tree and making it easier to
merge changes between different repositories. But this does have a few
problems of its own:

  • not everyone can make their repositories available to other people (you need at least a web server)
  • I think that having one repository is better; another repository
    is a mini-fork and there’s no easy way to tell other people about it 

I think that all a source control system needs to make things better is:

  • anonymous users should be able to create a branch
  • branch management should be easy (list all branches, preview
    changes in a given branch, merge a change from one branch to another)
  • ability to comment on changes

That way the work flow could be:

  • contributor creates a branch for his changes
  • contributor notifies the leader e.g. by e-mail “hey, I’ve made some changes in a branch foo”
  • leader can issue one command that would show him the changes made on branch foo, as a diff or in some gui
  • if leader likes the changes, he can merge them back to main tree
    with one command; if he doesn’t he can add a comment explaining why
    changes are not good
  • if contributor sees the comment, he can modify the code according to comments and redo the process

It’s almost like the full decentralized model but separate repositories
would be replaced by branches in the main repository. Anyone could
create a branch and make his changes on his own branch. Having everything
in one place would make it easier for other contributors to discover
interesting changes.

Currently the biggest problem with open-source development I see is
that whoever leads the project has a strong-hold on what goes in and
what’s not. Having a system that supports branches for everyone but
maintains a restricted access to the mainline would hopefully encourage
more experimentation, more people contributing to projects.

Which reminds me that I’m very disappointed by SourceForge. Did you notice
that it hasn’t changed in ages? No new cool Web 2.0 AJAX-y interfaces.
It still only offers CVS. They don’t offer built-in wiki for projects. Their implementation of a mailing list and a
bug tracker is terrible. And, ironically, the source code to the
biggest open-source code repository in the world is closed.

SourceForge could be so much more…

Category:  — Permalink

Rich client is here

I was always of the opinion that web-based access is great but in many
cases a rich client that uses the full power of your local resources is
even better.

Stanford on iTunes
is an example of that. They could just offer their talks available as
downloads but offering them as an iTunes store is even better since you
can stream or download and play from within one program (especially
useful if you’re a heavy iTunes user).

Not that iTunes doesn’t have it problems. It doesn’t seem to do any
caching or pre-fetching so that navigating the store is slower than I
would have liked, especially given that all they download in Stanford
case is a smallish list. This should be instantaneous (they should
remember the last state of a given page and update the list in the
background).

BTW: they do have some interesting talks. It one-ups MIT OpenCourseWare by going audio. Who’s gonna be the first to offer video recordings and notes for all lectures they do?

Category:  — Permalink

Oct 17, 2005

TextDrive.com could use some improvements.

For my low-end web hosting needs and hosting svn repositories I use TextDrive.com.
They do have a good rep on the internet, mostly due to their
involvement with various open-source, mostly Ruby-based, projects.

There’s one area of their hosting service that could use a lot of
improvements: webmin interface for managing the server. To be more
specific.

1. It’s agonizingly slow. It always has been.

2. The UI is awful, and I mean the interaction, not being pretty. This
is the third time I’ve added a new subversion repository and tried to
setup anonymous access to it. You would think that this would be
possible from the same page that lists the repositories but that’s not
how the mind of the brilliant designer of webmin works. It took me
(again) 15 minutes of clicking on every possible link to figure out
that in order to assign a given user access right to a svn repository,
you have to:

  • go the the virtual server configuration page
  • click on “Edit Mail Users”. Mail! How could I miss the fact that
    setting up subversion repository access is done through editing mail
    users.
  • click on the user
  • setup subversion access

So if you have multiple users, you have to do it over and over again
(as opposed to have all users listed next to repository name and being
able to do it in one step for all users).

And every new page takes forever to render.

The end result being that setup changes are very frustrating.

Category:  — Permalink