Passport is Microsoft's bid to operate the master
password database for every Web site and service. They've
got a shot at grabbing a large number of subscribing sites
because the current Web authentication solution involves
thousands of different password databases to administer and
support, and thousands of passwords for a user to remember.

I don't think they can do it right.

Those Terms of Service are an abomination

Insufficient paranoia is endemic within MS product groups

The protocols are closed, resulting in vendor lock-in

The protocols are closed, resulting in insufficient peer
review of what is potentially the most used crypto since DES.

AOL are their only credible current threat. They have a
slightly better security record, but the other problems are
much the same.

I don't want to trust either of them. We cannot allow
Microsoft or AOL to dominate Web-wide authentication.

In accordance with the Principle of Least WTF?ing, a desktop
environment's user interface should name applications in a
way
that makes some kind of sense. For example, the gnome menu
should have something called 'Image file viewer'
(appropriately
localized), rather than things called EOG and ee. Sure,
_you_ know what they are...

Too many bits of paper, filesystems, web sites. Time to
write a program that I can type at and then tell what to do
with it, so all my textual output is Logged in One Place.

I suppose some would call this Emacs.

Occasionally when people start to think about alternative
information paradigms, the 'lifetime stream of data' one
pops up. Implementation would require the sort of
all-encompassing throw-out-good-working-code event that free
software usually tries to avoid. There's a part of me that
thinks setting fire to the code base occasionally wouldn't
hurt, but I try to appease it by
embarking on occasional hard drive cleanups, for That Way
Lies Madness.

I've been thinking about user-space code vs. kernel-space
code, and it occurs to me that if you abstracted away the
differences between them you could write code that could be
compiled for or run in either. And it would be at least as
slow as user-space code and would hang the machine in no
time flat.

Now, if I only had some decent library access and a clue,
I could check this theory against the literature.

I've been wondering why Linux distributions all end up
being Unix-like, but I suppose it's obvious. Compatibility,
and that fortune that goes 'Those who do not understand
Unix are compelled to reinvent it... poorly.' And who
really understands Unix?

I'm occasionally tempted to implement a distribution
which keeps its packages in packages (much like the
nextstep/macosx 'bundles') and has a shell that can find
stuff in them. It should be easier to deal with upgrades
and version skew this way. The problem is that I don't know
what bits will be harder this way.

init is another candidate for reworking. It won't start
daemons for ordinary users, it spawns some things from
inittab and some from the init.d scripts... It's all
terribly ad hoc, I feel.

I've been trying to get used to click-to-focus recently,
seeing as
focus-follows-mouse is relatively unpopular across GUIs and
I've
not seen any evidence that either is better.

The most annoying thing about it is that new windows
(Netscape, for example, which takes a while to start) steal
focus from the terminal I'm typing in. One can turn off
focus for new
windows, but that's not quite right when you're not doing
something in another window. The best solution would give
the window focus if
typing wasn't currently occuring in another, I would think.
Opinions?