Hmm, put this
point together with this
suggestion from Luis, anyone?
(I was thinking after my last post: a lot of GNOME’s progress has
always been from companies; whether huge traditional ones like Sun,
the original International
GNOME Support, Eazel and Ximian and the Linux distributions,
Nokia, the many consulting companies staying busy right now, and
more.)
(This post was originally found at http://log.ometer.com/2008-06.html#11)
I agree
with Richard that churning the existing GNOME with “radical”
change does not make sense. “3.0” as a concept sucks.
I also like what
Rodney says; my spin, the problem is not that the GNOME desktop is
not changing much. The problem is that “make a desktop” is a direction
with limited possibilities.
GNOME 2.0 and KDE 4 are bad models for change. They rewrote and broke
the code, but from a user-goals perspective, they are the same thing
as before. We shouldn’t feel bad; Windows Vista made the same
mistake. Nobody cares about Vista, because XP allows users to
accomplish all the same goals. Even if Vista didn’t have a bunch of
regressions, nobody would really care about it.
The fact is that people already have a desktop. They don’t want a new
desktop from GNOME, from Apple, or from Microsoft. Making another
desktop does not add anything to the world. On average, people who
have GNOME want to keep it, and the same for the other desktops.
People using the GNOME desktop want it to keep evolving slowly, get an
improvement here and there, but nothing radical. People not using the
GNOME desktop, for the most part, are not going to. They might want to
use some exciting new open source software one of us could invent, but I
don’t think “a desktop” qualifies.
As I said 3 years
ago when the same angst came up, “GNOME 2 is in an important sense
the same thing as GNOME 1.” To make a different thing you
need to address different
goals and audiences. Different is a mobile device instead of a
desktop, web apps instead of local apps, graphical Excel vs. text-only
Lotus, and so forth. Meet a new need, be a “paradigm shift.” Different
is not “make the graphics better,” “fix bugs,” “clean up the code,”
etc. Different is when you don’t have to ask people to switch, but
instead ask them to do something new or in a new way or new context.
With technology, different is disruptive (see “The Innovator’s
Dilemma”), while same is an uphill battle (see OS X or Firefox
for the best case – despite near-perfect execution by their
respective organizations, they remain nowhere near even 50%
marketshare). Same only wins large marketshare when the
incumbent market leader massively screws up. Different can be
popular despite a top-notch market leader doing everything right.
The idea of “revolutionizing the desktop” is broken on two
sides.
1) It’s broken because it keeps people from making the GNOME desktop as
it is the best product for the people who are using it (the current
Linux userbase). Work on the current product is necessary and
admirable. It’s not useless or to be ashamed of just because it’s not
“revolutionary.”
2) It’s broken because by definition if it’s still “the desktop,” it’s
not a revolution. Everyone has a desktop already. What do they not
have? Providing what they don’t have would be a revolution and could
lead to 80% marketshare.
Should GNOME continue to evolve and enhance the GNOME desktop, or
create new ideas and categories that help people do what they can’t
already do today? Surely GNOME (the community) should aspire to do
both. GNOME (the
desktop codebase), though, is not revolutionary, because it’s a
desktop. A “3.0” won’t change that.
In both cases, the issue is to know the audience for the software
and do what they’d really like to see.
While I’m rehashing old points in response to other people rehashing
old angst, here is a Steve Jobs quote I’ve posted before:
This stuff doesn’t change the world. It really doesn’t
… Technologies can make it easier, can let us touch people we might
not otherwise. But it’s a disservice to constantly put things in a
radical new light – that it’s going to change everything. Things don’t
have to change the world to be important.
Update: Good idea from
Jono. (And for the record, nobody should be looking to us old
GNOME 2.0 era people for vision, I hope they aren’t. It’s time for new
people to do new things. Just do it. GNOME 1.0 was not done by a lot
of people at first. Neither were Firefox, or KDE, or Linux, or
anything else.)
(This post was originally found at http://log.ometer.com/2008-06.html#11.2)
We’ve revised litl.com – now it is
just a little bit more informative. Not too
informative, of course. Have to maintain stealth mode decorum.
Best way to learn more: come talk
to us. We’re doing quite a few job interviews. Worst case, you lose a
couple hours of time and satisfy your curiosity and give us some
advice. Best case, you find a great company to join. We have offices in Boston and London
according to our new web site. See how informative it is?
(This post was originally found at http://log.ometer.com/2008-06.html#9)
Just watched this
David Heinemeier Hansson talk from Startup School.
This is a
great thing to watch if you’re starting a career as a
developer, or ten years along.
His basic point is this. Lots of times developers might see their
range of options as working as an employee, or founding a
venture-funded startup. Those can be great options in the right
situations, I enjoyed working at Red Hat and am enjoying the startup I’m a part of now.
There’s an under-considered third option: create a small,
sustainable business. Sometime since the dot-com boom (back then
everyone was buying huge racks of Sun servers), it became possible to
launch a web app or web site for almost no up-front investment. You
can buy just one server in a colo, or even better, use flexible
utility services such as Google App Engine, Amazon EC2, or Mosso.
There are inexpensive, pay-as-you-go, automated ways to do all the
mechanics of a business, such as collecting payment (PayPal, Google
Checkout, Amazon) and advertising (both buying ads and selling ad
space). None of these have up-front fixed costs.
If you want to be old school you could even create a non-web app and
sell that. I guess there’s nothing 100% new here; developers have been
writing shareware and doing freelance work forever.
Whatever the details, as a software developer all indications are that
you can start a simple small business with just your own skills. The
only investment will be your living expenses. There are many ways to
cover living expenses (consulting/freelance, savings, mooching). It
helps if you live
well within your means.
Disclaimer: I haven’t done this myself. I’ve been fortunate enough to
find other stuff I wanted to do and people I wanted to work with. But
I have seriously considered it. A while back I tried figuring out in
detail how I’d do it. I came up with numbers pretty similar to the
ones David Heinemeier Hansson mentions in his talk.
If you find something you can charge $5/month for, or better
$40/month for, the number of customers you need to match typical
software developer salaries just isn’t that high. Make a spreadsheet
and play with your own numbers to prove it to yourself.
Your product can be niche, or regional, and still be
worth your time.
Coming up with product ideas is hard, but it’s a lot easier if you’re
trying to come up with something small a few people might want,
instead of trying to invent a product worth hundreds of millions.
Why is this huge? Think of the confidence and independence it
should give you to know that by yourself, or with a couple friends,
you can go earn money directly. Employers and investors have
advantages and often make sense to work with, but if the relationship
isn’t mutually beneficial, you don’t need it. That’s a great thing about
software development as a career in 2008.
Even if you never end up starting your own business, you’ll be a much
more valuable employee (and earn what you’re worth) if you have all
the skills you’d need to go out on your own. Learn something about UI
design and financial math and marketing and legal issues. Why stick
only to code? The world is a complicated place.
Surely it’s a worthwhile exercise for all developers to work through
what they could do on their own – what they could contribute to the
world, what they could earn, and what their quality of life could be
like. Identify any missing skills. Develop a concrete plan. Then use
your plan as a baseline when choosing people and companies to work
with. Why settle for less?
(This post was originally found at http://log.ometer.com/2008-05.html#25)
I previously
mentioned Easy GIT,
which greatly improves git, in large part by hiding man pages and
command line options packed with unimportant implementation detail,
while adding examples and options that relate to workflow.
Since then I’ve been using Easy GIT with other people and a central
repository, and moving up the learning curve a bit, and started to
find some stuff that still doesn’t work for me.
(I guess I’ll say eg and git interchangeably, since in many cases
enhancements could go in either project.)
For my workflow, with a central repository and a small team (which is
all my projects ever, whether D-Bus or Metacity or LiTL), any
local-only changes or local-only branches are temporary.
In fact my standard procedure on a branch that will last a few days is
to push to the server pretty much every hour or so, so I have a
backup. Easy GIT (or git) makes this easier in some ways, since it’s
easy to create my own branch on the server.
No way I’m keeping a few days or weeks of work only on my local
drive. I’ve watched a few too many other people do that and regret it.
Here’s what happens, though. As the day goes on I end up with a
half-dozen branches, and some commits on master too, in various stages
of patch review, some approved for merge to master and some not. For
most of these branches I probably intended to push them to the server,
but for some really small quick-fixes, perhaps not.
Now say I want to power down, or go to bed for the night, or switch
from my home computer to my work computer; what I want to do is say
“sync to server” – just back it all up! I don’t want stuff only on my
local drive. If I go from home to work or vice versa, I want
everything available on the server so I have it.
Two ideas:
This morning I set out to push all my patches that had not been
pushed. Problem one: I couldn’t figure out what these patches were.
Remote tracking branches are confusing, and I think could simply be an
implementation detail. I care about remote repositories (“remotes”); I
care about branches that are on remotes; I care about having an
offline cache of branches that are on remotes; but I do not
care that the offline cache happens to be implemented as a branch. And
I do not ever, ever, ever want to write to the
remote tracking branch.
How does one write to a remote tracking branch? I’m not sure to be
honest. But today, for a second time, I discovered I had a remote
tracking branch that was somehow not the same as the branch on the
server it was supposed to be tracking. My only guess is that this
results from typing “push origin/master” instead of “push origin”, or
the like. But I have no idea, really, how this could happen, or why I
would want it to happen. Worse, I haven’t been able to figure out how
to fix it, short of a fresh clone.
This is only a small symptom of the problem, though. I think the big
picture is that for purposes of command line syntax, “origin/master”
should mean “branch master on the origin remote.” If an operation
should be done offline (as everything except writes and fetches should
be), then behind the scenes it would use the remote tracking
branch. If an operation is a write, then it should go to the remote
branch instead of the tracking branch.
I don’t need to know that “origin/master” and “branch master
on origin” are different. I think it’s clear in all contexts which one
I mean, because git already separates network operations from
local-only operations, and because it is never correct to modify the
remote tracking branch (except to pull in new stuff from the remote
branch, of course).
On every pull, the system should verify that the remote tracking
branch (aka the offline cache) is exactly the same as the remote
branch, and make it be the same if it isn’t. And “push –branch master
origin” simply should not be different from “push origin/master” –
that’s crazy.
Getting back to the idea of “eg sync”: at any given time, I’m planning
to either never push a branch, or always push a branch, or not push it
for a while and then only push it when I explicitly decide to; but
whatever the plan, it’s not something that changes every hour. I want
to say “keep this branch in sync with server”; or “don’t send this to
the server ever”; or “don’t sync this for now, I’ll re-enable sync later.”
If branches were tagged with whether to push them or not, and to which
server branch, I could globally “eg sync” the entire repository.
I guess git lets you push a branch to multiple different remote
branches. Seems like an obscure feature that I can’t imagine
using. For me it would be fine if, for each remote branch I want
changes on, I had to create a local branch, attach it to that remote
branch, make the changes on this dedicated local branch, and push.
In the normal case, I would have a local branch for all remote
branches already anyway.
But, if there are people who love pushing to lots of remote branches
from one local branch, they can just set all branches as “never sync”
and then they can push individual branches by hand. The rest of us
should be able to sync all shared branches at once, while
still having local-only branches if we want.
Easy GIT has –all-branches and –matching-branches, but these are IMO
wrong workarounds. –all-branches forces you to push stuff that may be
a throwaway local branch or “on hold” temporarily. –matching-branches
doesn’t push new branches and may also push a branch you wanted to keep
on hold. What’s needed is that branches know where they go; I
shouldn’t have to push with a special “wildcard” option to do the
normal thing, which is to sync all branches marked shared, and do not
sync any branches I intend to be local-only.
Now that Easy GIT fixed the docs, I think the number-one UI deficiency
in git is that it has no feedback; it does not explain what it’s doing
when it’s doing it. Sometimes it’s totally silent;
sometimes it has a bunch of babble about “objects” and “packs” that
means nothing to me; neither of those is good.
This steepens the learning curve, since you can’t watch what commands do.
Maybe worse, it makes the source control system “feel bad.” For me,
the purpose of a source control system is to make it so I can
never lose any history or data; when every command feels like it
did something mysterious I’m not sure I understand, I don’t have a
sense of security.
Commands should output things like: “downloading changes from remote
server ‘origin’ on remote branch ‘master'”; “merging branch
origin/master onto branch master”; “3 new changes applied to
master”. For each command, I should get feedback on any network
transfers; all branches that were involved; and all commits that were
created or merged.
“eg branch” should show more than only branch names to help orient
me. I would like to know if the branch is synced and if so to which
remote branch, for example.
For a detailed ChangeLog, I want to write the ChangeLog entry as I
develop the code, using ‘C-x 4 a’ in Emacs, ideally.
The problem is that when I go to commit, that’s not when I
want to write the log. I prefer to write it either as I go,
or just before commit as part of self-reviewing the patch – I read the
patch while doing ‘C-x 4 a’ to document each part. That’s the value of
having a ChangeLog file that exists always, and isn’t just an open
editor at commit time.
However, if you have a ChangeLog file git barfs all over every
merge. git should be smarter. Merging ChangeLog conflicts is not
exactly a computationally intractable problem. But there’s an even
better solution maybe.
Every time I switch to a branch, git could create an empty file called
ChangeLog; then when I commit, it could pre-fill the editor with the
contents of that file and reset the file to empty. Magic!
The problem is not that ChangeLog disrupts git merges. The problem is
that git does not support the nice format and workflow of ChangeLog.
A minor thing, but if you just start using git, it puts garbage in the
Author field. Every other program uses the EMAIL environment variable
and your UNIX account information. That is a good default. If people
want to override it via config option, then let them, but don’t
require configuration to get started.
If you want to review a branch to see if it should be merged, the
syntax is the magic triple dots: git diff master...mybranch
This is weird, arcane, hard to discover… and something I need to do
all the time.
I’m not sure what the right solution is. Maybe just docs, or maybe it
should be an option to diff instead of the funky triple-dots.
I think to delete a remote branch you have to do eg push
:branchname, another strange and surprising syntax.
eg branch -d remotename/branchname should work,
IMO. (Again, writes to a remote branch should modify the server-side
branch, not the remote tracking branch.)
With subversion, I think it’s basically impossible for someone with
access to the central repo to accidentally make a change that
can’t be reverted. Sure they can log on to the server and delete stuff
from the shell, but with Subversion commands, I can’t do anything that
won’t show up in the history.
I can’t tell whether this is true with git. Throughout the docs there
are options like “–force” and “–hard” and warnings about how using
the command can screw you. I don’t know how many of these warnings
apply to central, remote repositories, but I worry about it. Remember,
I don’t understand the git docs, and hope I never have to try.
An example from man git-push:
–force
Usually, the command refuses to update a remote ref that is not an
ancestor of the local ref used to overwrite it. This flag disables
the check. This can cause the remote repository to lose commits; use
it with care.
Wait – can cause the remote repository to lose
commits???!!! This is not what I’m looking for in a source
control system. It’s the main thing a source control system is
supposed to be preventing!
Accidents worry me a lot more than malicious people or mysterious
cosmic rays. Especially when something as absurdly hard to
use as git is involved!
It also bugs me that I can accidentally do things that while
theoretically recoverable, are still very hard to recover from. For
example, somehow having changes on remote tracking branches that are
not on the server. (To beat that dead horse a bit more.)
If you want to understand the branch structure of a project, your best
bet is gitk, and gitk is not a good bet. I do not understand the gitk
display at all.
There’s probably some simple info the command line could report that
would be very helpful, such as which branches have changes that are
not on master, which branches were ever merged into a given
branch, or which branch a branch was originally branched from. Perhaps
some of this should be in the “git branch” output by default.
So much work to do.
(This post was originally found at http://log.ometer.com/2008-04.html#29)
The LiTL UI team has arrived! Welcome to
Johan, Lucas,
Tommi,
and Xan.
Still looking for more
people, of course.
(This post was originally found at http://log.ometer.com/2008-04.html#14)
Jason, I
think you’re missing a really basic point here. The point of a GUI is
(usually) not to expose or wrap a command line app. It’s to provide a
nice way for some
specific audience to do some specific thing.
The whole reason PackageKit is new and different is: it’s not a
“frontend for RPM” or a “frontend for dpkg.” There are already a ton
of those, for the kinds of audience who want those.
To design something, first-order, what should the UI be like for the
specific audience and the specific things they want to do?
Second-order, how can that UI be implemented?
If you and Richard don’t agree on the audience and purpose of
PackageKit then of course you won’t agree on the UI. That’s why
multiple UIs and multiple programs very frequently should and do
exist.
Whatever the merits of PackageKit, there’s a great general lesson
to be found here. Thinking of any software as a “frontend for XYZ” is
flat-out wrong…. unless your intended users are used to XYZ
and what they want is a frontend for XYZ!
But, there is no rule that Richard has to write a package manager
frontend for whoever it is that wants that. In fact, I hope he
doesn’t. I hope he writes a UI for keeping a completely terminal-free
desktop up-to-date with security patches, and finding and installing
new apps for said desktop. PackageKit seems to be pretty good for
that.
Something like 10 years ago now, I wrote a god-awful frontend to
Apt called gnome-apt; and it opened a terminal
(Zvt, back then, not VTE). It was hilariously, embarassingly bad
UI even 10 years ago to open a terminal, and people made fun of me.
My memory from back then: there was a future plan for all Debian
packages to have default answers to all questions, specifically to
avoid the UI wart of opening a terminal. Of course, who knows what’s
happened since. But I don’t think opening a terminal became a better
decision, that’s for sure.
It would be wonderful discipline for any software dev team serious
about Linux “on the desktop” (whatever that means)
to ban their own use of terminals. Of course, none of us have ever
done this, and that explains a lot about the resulting products.
btw, on this “Red Hat bias” topic: if I were writing PackageKit and
wanted to screw over Debian, I would put in the
show-a-terminal feature, because it’s so comically bad I could then
mock it. Just saying. I think Richard is doing a solid for Debian and
Ubuntu to insist on having PackageKit be just as good on those
distributions.
(This post was originally found at http://log.ometer.com/2008-04.html#13)
We’ve made good progress hiring UI developers and designers for
LiTL. We may hire more on the UI side in a while (please do let us
know if you’d be interested), but we have an initial team.
In the meantime we are turning our focus to a couple other
positions. See the official
job descriptions and if you’re interested, please email jobs at
litl com.
LiTL is a startup in downtown Boston working on a new consumer product
that involves hardware, software, and online services. We have the
right financial, business, and design support in place. Our success
hinges in large part on the development team. That’s where you might
come in.
To give a bit more color so you know what we’re looking for…
First, the job shown as Release and Quality Engineer probably
ends up as multiple jobs. We want a few different skills and maybe you
focus on one area. One role: what I would call “OS Wrangler” – do you
make custom Linux distribution spins? Hack on init scripts? Maintain
packages? Fix problems in the HAL/dbus/udev/kernel/etc. stack? We need
someone to put an OS together with our new code into a coherent spin,
and tune the OS for our product. Depending on your background this job
could involve significant new software development or could be more
focused on integration and coordination.
Another skillset or two we’re interested in: release and quality
engineering – nightly builds, automated testing, test plans, generally
ensuring our users have a great experience. We’ll need to test both
our UI and our web site, and manage new releases and updates.
Second, the job of Lead Server Developer. Here we want a
hard-core server application developer who can create a great, modern
web site with supporting APIs and services. If you’re into web
technology, we have quite a few interesting projects to get done that
you’d probably enjoy. We haven’t picked a platform – we’d rather pick
a great team and see what their platform of choice is – so this is a
chance to use Ruby or Java or whatever you love. We need someone who
can be a technical lead and make the major technical decisions, and we
want someone hands on who’s going to write a lot of code
themselves. We don’t want a manager, and we don’t want a pure
architect who doesn’t write code.
If you have some of these skills, we’d love to tell you more about
what we’re doing, and learn more about your background. Don’t be shy
with the emails.
(This post was originally found at http://log.ometer.com/2008-03.html#31)
I can’t seem to write a Python function that will spit out the same
numbers for average cost basis that Vanguard puts on their statement.
My many Google attempts are not turning up any description of the average
tax basis algorithm (single or double category) that is precise enough
to implement. All of them parrot what publication 564 says,
but that publication only describes the simplest cases. If you sell
multiple times, sometimes with mixed short and long term basis, it is
very unclear to me what is supposed to happen. I’ve tried various
things that seem logical but none of them match Vanguard’s
computation.
Surely there’s at least an open source program that implements this
algorithm, but I’m not finding that either.
How can there be nobody on the whole Internet giving more info than
the few sentences in the IRS publication?
Update: the secret is wash sales, which Vanguard mixes in to
the average basis calculation. The actual average basis calculation is
the simple thing described by the IRS. A side effect of this is
that the total allowable gain or loss shown on the Vanguard statement
is the right thing to put on your return, but the average basis shown
on the Vanguard statement is NOT correct to put on your return. To
fill in the basis column on schedule D you have to adjust the basis
Vanguard shows by the disallowed loss they show.
(This post was originally found at http://log.ometer.com/2008-03.html#30)
Amy and I broke down and sent our CD collection to Get Digital. I had manually
ripped about half of it a long time ago, but the metadata (from
MusicBrainz in 2005 or so, I guess) was a disaster, and I didn’t have
a good system in place so never finished ripping the rest.
Get Digital was far from free, but they did a nice job with fast
turnaround. They managed to get the right information for every one of
our CDs, including some imports, CDs that came with magazines, small
local artists, and other challenges. They did not have album art for
some of the more obscure things. Their metadata is completely
consistent; they always spell the same artist in the same way. They do
“Various Artists” correctly, so the artist for the album is “Various
Artists” but the artist for each track is the actual performer of that
track. They’re consistent about always using “Various Artists” too, so
we don’t have some albums under other spellings like “Various” or
“Multiple Artists” or whatever.
Anyway, I recommend Get Digital overall. I plan to use them again
after building up a batch of 50 new CDs. (They have a minimum of 50.)
From now on I’m just going to assume all CDs cost an extra couple
bucks to get the ripping done, since we won’t listen to them enough
otherwise.
The bonus – we had to stack all our CDs on spindles to mail them in,
in the process we pulled all the paper inserts out of the jewel cases
and put those in another box. So now we have two small boxes – one of
paper inserts, one of CD spindles – instead of several huge, heavy
boxes of jewel cases. The spindles can go in the basement as
backups. The empty jewel cases will finally be out of the house.
(This post was originally found at http://log.ometer.com/2008-03.html#29)