Monday, November 30, 2009
I just recently realized how easy it is to apply an arbitrary commit on top of another one, without treating it as a patch. Since all high-level Git commands work with patches and diffs, one sometimes forgets that internally Git doesn't use patches, but simply stores the state of the tree as is at any point.
So, to put commit-a on top of commit-b, I simply do:
git-read-tree -u -a commit-b
Again, this doesn't apply commit-b as a patch on top of commit-a; it copies the exact state of the tree in commit-b.
Why is this necessary? Sometimes there can be a very messy path from commit-a to commit-b, while all we want to record in the official history is just the two commits.
After reading the Git user manual, the first idea would probably be to do this using "git-rebase -i" or even a sequence of "git-cherry-pick -n". However that approach takes a lot (!) of effort, and is risky because there can be conflicts which need to be resolved.
Another severe problem lies with the portability of the bug database. For my hobby or consulting projects I like to keep the bugs close to the source - I might happen to work om my desktop, on a laptop, etc. They should be easy to move around and archive. By comparison, moving or backing up a Bugzilla installation involves unspeakable complexities that my mind simply refuses to do. (I do realize that it is not technically complex to move a Bugzilla installation, in fact it is a relatively easy as these things go, but it is not something that one would undertake casually - it takes preparation, time and care).
Yes, one could maintain a running publicly accessible (even only via SSh/OpenVPN) web server, and always use it, but that is a whole lot of work, not to mention the security implications and the real added expense. Plus, one is not always online.
So, until recently my bug tracking for these kinds of projects has been restricted to keeping a couple of text files called BUGS.TXT and TODO.TXT. Not very high-tech, but hey, they do the job.
That is until I found Ditz. It is a command line bug tracking tool, and it keeps all its data, including all configuration files under one neat sub-directory, plus everything is in plain text format! I absolutely love it and highly recommend it.
With Ditz the entire bug database even can be a part of the source tree, which automatically makes it distributed if one uses Git for example. (I am not sure that is such a great idea by the way - polluting the source history with bug reports - but I am still thinking about it). Moving it between computers is just a copy, and so is backup. It literally requires no thinking or effort.
While I am on this subject, todotxt also deserves a honorable mention, although it is not suitable for issue tracking.
Bottom line, Git and Ditz provide a full featured and yet very simple infrastructure for small projects. Now all I have to do is finally start using a good command line email client.
Friday, November 13, 2009
So, one, there isn't a way to auto-update all applications. Two, it feels like developers for Android are constantly pushing out buggy unfinished apps, and then updating them all the time. I mean, I sometimes get two-three updates of the same app within a week. People, test your god-damned apps before publishing them, and Google, please provide a way to update all apps.
In short, my attitude towards Android has definitely changed for the worse since I actually have an Adroid Phone. Initially it was awesome, compared to my previous phone a Motorola Razr. But we bought an iPhone for my wife at approximately the same time that I got my G1, and I have had an ample chance to compare the two since then. Although I would never buy an iPhone for myself on ideological grounds, I grudgingly have to admit that the iPhone is a superior phone! Damn it.
Although I would never admit it (oops, I just did), I catch my self "casually" wanting to use my wife's iPhone for browsing the web, or looking at photos, or what not, because it is simply better than the Android.
Wednesday, November 4, 2009
So, they have three weeks between Beta1 and Beta2 and then only two weeks more before release. What I don't understand is this: how the hell can they guarantee that they will fix all critical beta bugs within a total of five weeks? And since I know for a fact that they can't (nobody can), it follows that they will simply release no matter what.
December 3rd, 2009 – Alpha 1 release
January 7th, 2010 – Alpha 2 release
February 4th, 2010 – Alpha 3 release
March 4th, 2010 – Beta1 release
April 1st, 2010 – Beta2 release
April 15th, 2010 – Release Candidate
April 29th, 2010 – Final release of Ubuntu 10.04 LTS
So, let me repeat that. No matter what remaining bugs there are, the Ubuntu LTS version will be released on time. With the bugs. Why bother with the betas at all then? I have to say this is not what I would expect from a "Long Term Support" version or like to run on my servers. Or my desktops.
Sunday, October 25, 2009
The problem is not that these people exist, but that apparently they are the target audience of popular Linux desktop distributions. This worries me. At least with Windows you know that there is a "design committee" somewhere in Redmond, trying to do the right thing; they don't end up doing it, but they at least try to approach it intelligently. What am I saying - apparently they do succeed, and the proof is in the pudding - 98% of the desktop market share.
Recently there were discussions in Slashdot about PulseAudio. The latest attempt to "fix Linux sound". Apparently OSS was not good enough, so it was replaced with Alsa, which wasn't good enough, so Arts, Esound, etc, were created, and now finally PulseAudio to rule them all. In the meantime Windows 2000 (and perhaps even Windows 95 and Win 3.1??) had better sound than Linux today. But I digress.
What really made an impression on me is the admission by Pulse Audio's creator that its mixer controls can't possibly handle all different sound cards, but that at least it was an improvement over the existing Alsa mixer control. To this I say, if you aim low you land low. Let's think for a second. Why isn't this a problem in Windows? How are all possible sound cards handled there?
BTW, here is a hint: it is not only the sound. Exactly the same limitation exists in Linux printing. While printers might have tons of special functionality (cleaning, adjustments, manual double-sided printing, etc) available in Windows, this is never available from CUPS in Linux.
The answer is, in Windows the manufacturer can ship a custom applet, designed specifically for the capabilities of their hardware, together with the driver. Who knew that instead of trying to handle all possible cases in the OS, it is possible to push the burden to the manufacturers and let them take care of it.
Homework question: why doesn't this obvious solution work in Linux, and why does this mean that Linux is destined forever to fail as a desktop.