If you see any topics that grab your interest, remember sign up online to get the early bird rate.
Hope to see you there!
Registration is open! It has been open for a few weeks now, and I've just gotten around to announcing it in my blog here now. Apologies.
This year's event is being held on Saturday, October 24. Just 3 weeks away! If you register in advance at the website the cost is only $40. If you show up at the door, it is $60. Earlier is better.
If you would like your name in lights, and would like to help sponsor the event, you can become an individual sponsor as well. More details on the registration page.
As usual, there's a welcome party on Friday night, and an after party Saturday night. Let us know if you can join us by checking the party options during your registration.
You can see a partial list of speakers here. The final list and schedule is still in progress, and if you want to submit a presentation topic proposal, there's still time to get it in under the wire.
The official Twitter feed for the Ontario Linux Fest is @OntarioLinux. We're using the group tag #oglf09. The 'g' is for GNU.
You can also follow me personally on Identi.ca as @cdfrey. I may post there from time to time as I work on the show guide.
Hope to see you at the Fest! I'll update this blog more regularly as more news becomes available.
But with that flexibility comes complexity. Have you ever wondered what the difference was between "commit1..commit2" and "commit1...commit2"?
If so, then this mini howto is for you.
(If you want to follow along, use the sample setup commands at the end of this document)
1. What is a branch?
It is helpful to remember that git thinks of a branch as any name or tag that refers to a SHA1 commit ID. The branch represented by that commit includes that commit itself along with all the ancestors that make it up.
For example:
git log master
will show you the master commit, with all the parent commits that belong to it. If you say:
git log master desktop
it will list all the ancestor commits of both master and desktop.
2. Commit walking
The command git-rev-list takes a list of commits and prints the SHA1 commit IDs of all the ancestors for those commits. This is a low level git command and is the basis for specifying commit ranges.
For example, on a repository I have on my hard disk, I have the following branch structure:
/---o---o master
/
o----o (base)
\
\---o---o desktop
The following command:
git rev-list master | wc -l
shows 3 commits. If I include the desktop branch, which has 2 unrelated commits in it, and does not have the 2 commits from master:
git rev-list master desktop | wc -l
it shows 5 commits.
This shows that specifying multiple branch names is inclusive. All commits from all branches are included in the resulting list of ancestors.
3. Limiting the list
If I want to see all commits that are in master but not in desktop, I can invert one of the branches:
git rev-list master ^desktop | wc -l
This shows 2. The two commits on the master branch. I can verify this with:
git log master ^desktop
which shows only the patches on the master branch.
I can reverse this as well, showing only the 2 commits on the desktop branch:
git log ^master desktop
The shorthand for this is the 2 dot ellipsis. The following are identical:
git log ^master desktop
git log master..desktop
Again, reversing, the following are identical:
git log master ^desktop
git log desktop..master
4. Finding the branch point
Git does not store branch divergence points. This can be calculated on the fly by looking at the heads of two branches and finding the first common commit in the list of ancestors.
This job is done by git-merge-base. If we used it on the above branch structure, we would get a SHA1 commit ID of the point marked (base) above.
git merge-base master desktop
This returns c79f6f286e720b39976531b7a5b713b87308b576 in my repo. It will be different in yours, since you have different author information.
5. Listing all changes
Using what we know, we can now list all the changes on both branches that are not in the main repo:
git log master desktop ^c79f6f
This shows 4 commits, from both branches.
The shortcut to this, is the triple ellipsis:
git log master...desktop
Basically, this means show all the commits from both branches that happened since they diverged.
6. Diff: turn the world upside down
This is all fine and good, but wait! The git-diff command turns this inside out.
Git-diff takes two branches and shows a unified diff patch between the _endpoints_ that they represent. The usual format of the command is as follows:
git diff master desktop
This will create a patch which, if applied to master, will turn it into desktop. i.e. it removes the 2 changes done on master and adds the 2 changes done on desktop.
The reverse will do as expected:
git diff desktop master
This is the same as having two trees checked out, and running a manual diff -ru on them from the command line.
The double ellipsis is used in git-diff as well, but has no special meaning. It is an alias for the above usage. The following are identical:
git diff master desktop
git diff master..desktop
The difference in git-diff is that the triple ellipsis uses the same logic as git-log does when finding the merge-base, but the result is the difference between the base and _one_ of the branches.
For example:
git diff master...desktop
This will find the branch point of master and desktop, and then generate a diff between that base commit and the commit of desktop.
In other words, the diff will contain only the 2 changes on the desktop branch, and is effectively the same as:
git diff c79f6f desktop
or
git diff $(git merge-base master desktop) desktop
Reversing the options will do the same for master. The following commands are identical:
git diff desktop...master
git diff c79f6f master
Now, the diff will contain only the 2 changes on the master branch.
The parsing logic of the triple ellipsis range is the same, but the result is the opposite. With git-log, all 4 commits are shown, with git-diff, only 2 commits from one side of the branch are shown.
7. Play
Pasting the following commands into a shell will create a sample branch with which you can experiment with these range specifiers.
mkdir play cd play git init echo data > file.txt git add file.txt git commit -m "Initial commit" echo data > README git add README git commit -m "Added README" echo data > license git add license git commit -m "Added license file" git checkout -b desktop master^^ echo data > main.c git add main.c git commit -m "New source code" echo data >> main.c git commit -a -m "Bug fix" git checkout master
Enjoy.
Thanks to Ilari on #git irc.freenode.net for the discussion that lead to enlightenment.
For example:
git checkout -b staging master
[make changes]
git checkout -b base_url staging
[make changes]
git rebase --onto master staging
This does: finds all the commits between the current branch (base_url) and staging, switches base_url's HEAD to master, and then reapplies the above found commits. You end up with a base_url branch that looks like it was only branched from master originally.
Excuse me? A foreign company wants to buy taxpayer-funded Canadian technology and they want the Canadian government to foot the bill.
Are we Canadians stupid or what?
Paul Graham on the Manager Schedule vs. the Maker Schedule.
We are looking for speakers to present on the following general topics, but of course, it is not limited to these:
If you have a presentation you would like to present at the Ontario Linux Fest, please add your proposal using the web form.
Our sponsor page is also open for proposals. If you or your company would like to help sponsor the event and get some publicity as well, please check it out. There are sponsorship levels for every kind of organization.
I'm currently working on finishing the registration pages. I'll blog again when it goes live.
If you have any questions, or if you run into problems on the website, please email me. Stick "onlinux" in the subject line to make sure I see it.
A little while ago, I wrote a summary on Linux sound. Since then, the Insane Coding blog posted a new summary of its own, which I'm linking for completeness.
Michael Geist has some historical background on the bills, but it is still early. Looks like these bills are mostly copies of what the Liberals tried to pass in 2005.
I'm sure there will be more news to come. Get ready to start writing letters to your member of parliament...
I'm partly willing to give PulseAudio the benefit of the doubt though, if only for the power saving potential. I find it disappointing that an entire daemon and library system has to be built on top of ALSA and OSS to achieve this, but since Linux has decided that mixing belongs in userspace, and that no floating point is allowed in the kernel (understandable), then mixing has to be done somewhere, and PulseAudio looks like a good attempt by a sane developer, who is saddled with working with the pre-existing sound mess that is Linux.
The library situation looks interesting... if you want to just program with a library and forget the low level, use libao or libao2 (libao2 comes from the mplayer guys). Libao is crossplatform.
Another library called libsydney is also intended to be crossplatform (Linux, Windows DirectSound, Mac, etc). I haven't looked closely into that, but it is probably worth a look.
See http://blogs.adobe.com/penguin.swf/linuxaudio.png for a graphic of other sound APIs and systems. As a programmer, I would aim for either programming directly to OSS, which is portable crossplatform, or use libao2. Maybe libsydney if it doesn't have too many dependencies. My needs as a sound programmer would not be anywhere near the heavy-duty, so these options would work for me.
As for PulseAudio's state of readiness, I think there is a definite reason why it ain't at version 1.0 yet! :-) But that's not a bad thing. For stable-loving users like myself, it is probably worth waiting for a few distro release cycles before the bugs are worked out to a satisfactory degree. Newer PulseAudio releases will even stress ALSA drivers in new and interesting ways, so I expect there will be a strain on the sound system for a good while yet, from the applications right on down to the kernel.
If you don't need sound mixing, don't use PulseAudio yet. If you don't need power savings, don't use PulseAudio yet. If you use a laptop on battery then PulseAudio may be very useful, but you may need a good chunk of memory to support it, and it will pay to stay as up to date as possible, with kernel, distro, and PulseAudio.
From a power standpoint, there are reports of PulseAudio not even showing up on powertop, even while playing music, which is a good thing. I don't know how mpg123 + ALSA or OSS would compare.
There's a lot of flameage out there regarding ALSA and OSS3 and OSS4. It is easy to get caught up in it, and yes, I was caught up in it too... but my style of getting caught up in something usually involves me wasting many hours on research and reading to get the facts, and at the end of all this, I'm feeling less harsh with everyone, even though my mpg123 + ALSA configuration sometimes uses 40% CPU on a P4. (grrr!) :-) I can see the history and the reasons why Linux sound has evolved the way it has, and while some things still look unfortunate, they are understandable, and people continue to work on improving the situation.
I must say, though, that a piece of software going from "open" to closed, such as OSS3 did, can cause much disruption in the Free Software community. Even KDE and Gnome were arguably split due to licensing issues, even though they evolved in quite different technical directions as well. I think it would behoove the Free Software community to be more watchful of such situations, and guard against such collateral damage. The side effects can last for decades.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!
