Thu, 28 Aug 2008

Making Intrepid Solid

Making Intrepid Solid

With feature freeze now in effect the bulk of the big changes in Intrepid should now be done. There will still be new features entering the archive with the appropriate exceptions, but the rate will slow as we move forward.

Now we really need to focus on making Intrepid solid. We want to squash as many bugs as possible, so that when we deliver the final release it is something we can be proud of.

This is something that everyone can help with. There are plenty of ways to help out, so there should be something for everyone.

Testing

Simply running Intrepid and reporting bugs is a great start. It's still not recommended to run it if you aren't able to fix a system that doesn't boot, or where X doesn't start, but if you are then upgrading now will be a great help.

You can do more than just using the system though, pick an application and start testing all of the functionality, and report the bugs that you find. Some bugs only show up in certain locales, with certain hardware, or with certain combinations of packages, so try different things and look for serious problems.

Upgrade testing is an area that is under-tested until the last minute when floods of users upgrade. Also the easiest testing to do lots of is upgrading pretty standard installations, but this doesn't catch a lot of problems. So, when you are comfortable with running Intrepid upgrade and let apport file any upgrade problems that you find. You should also be on the lookout for unnecessary prompts that happen while upgrading, or packages that are left broken by the upgrade.

Even if you are not happy running Intrepid yet you can still potentially help upgrade testing, thanks to the unstoppable Michael Vogt. He has written a tool that will clone your system in to a kvm virtual machine, and then upgrade that. This means you can test a real world upgrade without risk to your system. If you do this a few times during the remaining time for Intrepid and file bugs, then you will have a much better chance of a hassle free upgrade to the final release. You can find more details on Michael's work here. (Not everyone has kvm capable hardware though unfortunately.)

Looking at bugs

As well as trying to find your own bugs you can look at the ones that other people have already found. There are several important things here.

The first is bug triage, trying to make sure that a bug report has all the information that it needs, and trying to set an appropriate priority. This is really important work, and we always need more help doing it, so consider joining the bugsquad and helping out.

At this time important bugs should also be milestoned so that they can be concentrated on for the release if possible. Deciding the different classes of bugs here is really tricky, and there can often be disagreements. It is important work though. If you see a bug that should probably become release critical then work with the bugsquad to triage it, and make sure to suggest that it is considered for release-critical status.

Developers can help by actually trying to fix these bugs. Some can be easy, for instance if they are known to be fixed elsewhere. Some can be really complex, and take a lot of effort. Fixing things from the release-critical bug list, and lists of other important bugs is always valuable.

Doing the easy things

There are some ways to improve the quality that are actually fairly easy. Though there is a freeze in effect in Ubuntu there is still loads of work going on elsewhere, and many, many bugs being fixed elsewhere. Pulling these fixes in to Ubuntu will improve the quality, while in theory being easier than coming up with a fix for a bug.

We should keep an eye on upstream projects and pick up bug fix point releases to the versions that we have. If the project doesn't do this then look out for important fixes going in to trunk and back-port them. If you are doing that then it can be worthwhile looking at the versions in other distributions that plan to release soon, and if they carry the same version suggesting that you share the workload of creating these point release, or at least collaborate on fixes and share them.

Adding external bug watches in launchpad is also a great way to help. Jorge explained this recently. This helps easily spot when there is a bug fix that we could pull in. When there is they will appear on harvest

Harvest (now with a new look) is another easy way to do things. It lists opportunities to fix things that should be fairly easy, such as bugs fixed elsewhere, or bugs with patches attached.

Making Intrepid+1 rock

In parallel with all the above now is the time to start thinking about what you want to achieve in the next cycle. If any of that requires changes to an upstream then speaking to them early can be a good idea, as you can get their feedback and see how it fits in to their plan. I'm sure everyone has loads of ideas, and a bit of preparation now can help you hit the ground running in the next cycle.

Posted at: 12:51 | category: /ubuntu | Comments (0)

Tue, 26 Aug 2008

I love a bad book

Last night I finished reading "Exit A" by Anthony Swofford. I had decided a while ago that I didn't like it, but it wasn't so bad that I had to put it down, so I stuck with it to the end. It wasn't a bad book, it was just poor in places, and disappointing overall.

I did prefer the act of reading the book to the book itself though. I have just read 10 or 20 draw-droppingly good books in a row. The previous book was "Disgrace" by J. M. Coetzee, which is stunning. Read it. I was beginning to think that I just possibly enjoyed most books a lot. Reading a book I didn't enjoy showed me that I just read a lot of good books.

I saw this one as a new release in a bookshop, and it had a piece of card with it, written by one of the members of staff in the shop. The card said something like "Swofford could have been forgiven for writing a poor second book, but he doesn't need to be, he can really write." I agree for the most part, he certainly could have been forgiven, and this book isn't bad enough that he really needs to be. It however not a great book, unlike "Jarhead", which I haven't changed my opinion on.

It wasn't just the act of reading a mediocre book that buoyed my spirits though. I wanted to like the book, so it wasn't just that it's not a famous classic like "Disgrace", so I'm not that much of a book snob. Also, it was really the card that caused me to buy it, even though I was drawn by the author's name, so it shows that my instincts are good, which gives me confidence when choosing books in the future.

The final aspect is the one that makes me happiest though. I know why it's not a great book. I can point to places in the book and tell you why they are bad. At school I was terrible in English classes, I didn't understand the first thing. Reading this book gave me confidence that I am learning while reading. Not only learning about life and the world, which I was already concious of, but also learning about language and writing. Even though I'd never be able to write like I would like to, I can at least comfort myself with the knowledge that I am at least able to partly understand the mechanics of good writing.

Posted at: 01:46 | category: /life | Comments (0)

Sun, 17 Aug 2008

Help needed

The server team asked me to write a blog post to ask for help removing the use of "multiuser" as an argument to update-rc.d. This used to be the way that we sped up the shutdown time a little, but we've changed the approach now.

This is great, as it means that we can get rid of some of our diff to Debian, as well as helping Debian to get the improvements (the original approach was never accepted by Debian, the new one has been).

However, I no longer need to write the post. Thanks to a few people most of the work has now been done. In particular I would like to thank Didier Roche, Nicolas Valcarcel, and Cesare Tirabassi, as well as the sponsors that uploaded their work when needed.

However, I thought I'd write the post anyway, as there is still loads of work to do, so if you are interested in helping out with development then come and get stuck in. I'll try and post about some specific tasks in the future, hopefully before somebody does all of the work next time.

-- This belongs to Lionel Richie

Posted at: 00:47 | category: /ubuntu | Comments (0)

Sat, 16 Aug 2008

Does it just work?

I recently attended Lugradio Live in Wolverhampton. During the live recording of the show they were discussing how things have changed since the started the show. Aq was saying that things are less interesting nowadays, as everything just works. I disagree that it's less interesting, not spending time compiling drivers for my video card means I can spend time on other things.

I bought another laptop this week, and so I can personally attest that the developers involved should be proud, all of the hardware was supported out of the box, with just a few minutes following instructions on a wiki page to get everything working properly. Also, all of those little tweaks won't be needed in a few months time, as the developers have fixed the problems.

However, I also disagree that everything just works. Even though it took me only a couple of hours to install and get all of the hardware working, I'm still setting up the laptop. Why do I have to spend ages configuring all of the applications, even though 90% of the settings will be the same as on my other laptop? I could copy across my dotfiles, but there could be more done to help me move just those that make sense to be on another machine. (I don't think I would want to copy the whole of .mozilla/)

There's more though. Though I have two laptops running linux next to each other, it's not that easy to move a file between them. Why do I have to enter details of my contacts more than once? Why isn't it trivial for me to send off an email to someone I am chatting to on IRC? I could go on.

The work on the kernel, drivers and installers that meant that it only took me a couple of hours to get up and running is a fantastic achievement; it's what allows us to ask questions like these. There is more that needs to be done in these areas, but we need to expand our ideas of what should just work.

I don't wish to discredit those that are working on this sort of problem, there should be more people helping them. We need other developers to appreciate the issues, and support those trying to tackle them.

If you agree with me then don't complain about it, fix it. Find a project working on a problem that you care about and support them however you can. I realise the irony inherent in telling everyone this at the end of a post like this, I hope you will forgive me.

-- This belongs to Lionel Richie

Posted at: 23:37 | category: /tech | Comments (3)

Thu, 14 Aug 2008

MOTU School sessions for Ubuntu Developer Week wanted

Next month we have another Ubuntu Developer Week. It's still in the planning stage, and there will be a proper announcement later, so if you are interested in attending wait for that.

This post is for those who are in a position to give sessions. I want to get several MOTU School sessions included in the schedule, but for that I need presenters willing to give them.

There's a list of some ideas for sessions at

https://wiki.ubuntu.com/MOTU/School/Requests

as always. If there is a session there that you would like to give then get in touch with me. It doesn't have to be one from that list, I'm interested in any session that you are willing and able to present.

In particular I'm really keen to see the sessions on Java this time. I'll speak to the Soyuz team to see if they are willing to present a session, as that one has several votes. I'll also probably present a bzr session with David, and a packaging with bzr session.

If you want to have a session during the week on something then stick your name and the title on

https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep

or grab dholbach or me to discuss it.

Speaking of dholbach, let's make this developer week ROCK!

I'll leave you with Eugene O'Neill:

There is no present or future,
only the past happening over and over again,
now.

Posted at: 01:37 | category: /ubuntu | Comments (0)

Thu, 07 Aug 2008

Tempted by a stage dive

Hello Planet Ubuntu.

This feels like I've just made it on stage with my favourite band.

Today I was accepted as an Ubuntu member through the Universe Contributors group. Thanks to all those that helped me achieve this. There's been a load of other people join this group recently. Hopefully this is a sign of things to come, and we're going to have some great releases coming up.

It's an interesting time to be joining planet, with yesterday's CC meeting discussing what role the planet should play in our community. I think that Emma had a good post touching on how we should conduct ourselves. (Hey Emma, when are you going to become a member so that more people see your insightful posts? And the animal ones too, I like those)

Emma refers to a poem by Robert Frost in her post, I had heard of it before, but I had never read it, so I hunted it out. I recommend reading it.

Mending Wall
Robert Frost (1874-1963)

SOMETHING there is that doesn't love a wall,
That sends the frozen-ground-swell under it,
And spills the upper boulders in the sun;
And makes gaps even two can pass abreast.
The work of hunters is another thing:
I have come after them and made repair
Where they have left not one stone on a stone,
But they would have the rabbit out of hiding,
To please the yelping dogs. The gaps I mean,
No one has seen them made or heard them made,
But at spring mending-time we find them there.
I let my neighbour know beyond the hill;
And on a day we meet to walk the line
And set the wall between us once again.
We keep the wall between us as we go.
To each the boulders that have fallen to each.
And some are loaves and some so nearly balls
We have to use a spell to make them balance:
"Stay where you are until our backs are turned!"
We wear our fingers rough with handling them.
Oh, just another kind of out-door game,
One on a side. It comes to little more:
There where it is we do not need the wall:
He is all pine and I am apple orchard.
My apple trees will never get across
And eat the cones under his pines, I tell him.
He only says, "Good fences make good neighbours."
Spring is the mischief in me, and I wonder
If I could put a notion in his head:
"Why do they make good neighbours? Isn't it
Where there are cows? But here there are no cows.
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offence.
Something there is that doesn't love a wall,
That wants it down." I could say "Elves" to him,
But it's not elves exactly, and I'd rather
He said it for himself. I see him there
Bringing a stone grasped firmly by the top
In each hand, like an old-stone savage armed.
He moves in darkness as it seems to me,
Not of woods only and the shade of trees.
He will not go behind his father's saying
And he likes having thought of it so well
He says again, "Good fences make good neighbours."

From http://www.bartleby.com/118/2.html

Posted at: 02:28 | category: /tech | Comments (0)

Tue, 24 Jun 2008

bzr-upload

On Friday bzr-upload was officialy announced. In the blog announcement Martin tells the story of how this plugin was born. I'm proud to say "I was there!". I was sat at the table with them that evening as they discussed what was wanted, and what was possible. This was just one of the great things about the last sprint for me, and I was only there for two days.

Very often on the #bzr IRC channel we have users asking why bzr doesn't update the working tree on a remote machine, and what they can do about this. Very often it turns out that they are web developers who are looking to deploy a website, rather than just host the branch, and so the normal behaviour is kind of the opposite of what they want.

John wrote the push-and-update plugin to help with this, but it didn't fulfil all the needs, and requires ssh access, where web developers sometimes only have ftp access.

While bzr-upload does have some corner cases to be wary of, it's a great thing to have available. If you are web developer who is looking for a version control system for your code then consider bzr, it will hopefully suit your workflow very well.

Now, watch out for Martin's improvements to loggerhead, and Vincent's improvements to his kitchen.

Posted at: 20:38 | category: /bzr | Comments (0)

Tue, 13 May 2008

Gutenberg's Revolution

I love Stephen Fry, everything he does is great, but also seems to come with a touch of quality as well. His documentaries are probably a lesser known part of his work, but they are equally fantastic; the two-part documentary on manic depression was particularly notable.

Last night a watched a new documentary presented by him, and while it was neither as moving or as personal as the others I have seen it was still interesting and enlightening. This particular documentary was about Johannes Gutenberg, the printing press that he invented, and the impact which this had upon the world.

He explained that the printing press, and the increased access to knowledge that it allowed, was a major factor in the Renaissance, which radically changed the world, and can be seen in the world in which we live today.

In Gutenberg's time the Church was the most powerful organisation. He worked with the church, and tried to show them the benefits of his idea to them. It was suggested that he would never have succeeded if he had not courted the Church. If the printing press was indeed the catalyst for the Renaissance, and the Renaissance was the start of the decline in the power of the Church that we see today, then the Church's embrace of the printing press could be said to have precipitated their loss of power and influence.

Are there any ideas at the current time that are as powerful as the idea of the printed word? During the programme their were a couple of references to the growth of the printing press being similar to that of the growth of the Internet in recent years.

The Internet, like the printing press before it, allows a new group of people to have direct access to information. Will that access cause a fundamental shift in our world and our lives?

Is there a dominant force in the world which will be diminished by the Internet? Are they currently embracing it as a tool which they can use to entrench their position? Are we thinking too small; is there something we haven't thought of yet that is going to have an even more radical impact?

Posted at: 11:54 | category: /tech | Comments (0)

Fri, 25 Apr 2008

A long anticipated release

Now that one important release is out the way it's time to look forward to another one. This has been long anticipated, and will probably decide whether they go on to great new heights, or are just remembered for their previous contributions, but aren't considered relevant any more.

No, I'm not talking about the Fedora release, that is definitely relevant, and is sure to be great. I'm talking about the release of "Third", the new album from Portishead. Fingers crossed it's going to live up to the legacy.

Oh, and if you don't know, get to know.

Posted at: 15:17 | category: /life | Comments (0)

Jerk Pork Burger with Green Apple Slaw

Thanks to richb I found this recipe for "Jerk Pork Burgers with Green Apple Slaw", and they are fantastic. The Slaw is particularly good, I'd really recommend you try it, even if it does sound a little weird.

Unfortunately, it appears as though "The Bell", a pub just round the corner, no longer serves food. No matter how good a burger is, I'm sure there's no way it could be as good as a Bell Burger. It seems I'm stuck spending the rest of my days trying in vain to recreate that marvellous piece of meat technology.

Posted at: 14:59 | category: /food | Comments (0)

Thu, 13 Mar 2008

Revision numbers

Revision numbers vs. revision ids

One thing that Bazaar does a little different to the other distributed systems is to give every revision a revision number. Some people don't like this as the revision numbers are global, that means that the revision number of a revision in my branch does not necessarily match the number that it was given in your branch. Some people say that this makes bzr somehow "less distributed." This is not the case at all, you just need to be careful to be clear what branch you are referring to, i.e. say "revision 315 on branch http://...", rather than just "revision 315".

This is a little dangerous in that the branch may have it's revision history changed, for instance by uncommitting and then committing again. If that may happen then you should use revision ids, which you can find from "bzr log --show-ids".

Why do number the revisions at all then? One reason is simply that some people find revision ids ugly, and may be scared off by them.

Another reason is that they are shorter to type. git folks will tell you can use the first few characters of the revision id, and git will work out what revision you mean. However these shortened ids are not necessarily stable over a long period of time, and so again, if you are worried you should use the whole thing.

The third reason is that the numbers can give some sense of the order of the revisions in your branch. If I say talk about revisions "3445abe" and "b27ac9" then you don't know which is earlier in history. If I refer to revisions 345 and 532 then it is immediately obvious (providing that I am only referring to a single branch).

The advantages I have outlined are small, but they could be valuable at times, and you always have the revision ids to fall back on if you require them.

Numbering merged revisions

Along with numbering the mainline bzr also numbers merged revisions using a dotted numbering scheme. This means that your mainline revisions are "1", "2", "3", as you would expect, but any merged revisions are given three digit numbers, e.g. "2.1.3".

The numbering scheme has a couple of nice properties, the most notable of which is that it is "stable", this means that once I have numbered a merged revision with respect to a certain mainline it cannot be effected by any addition I make to the revision history. This means that any commits, pulls or merges that I do will not change any of the existing revision numbers, but they will add numbers to any new merged revisions such that they will not be the same as any number already used.

The current algorithm used for this involves looking at the whole history of the branch to number the revisions, which is obviously undesirable.

On the last evening of the sprint last week myself and John were discussing the numbering scheme, and thinking about possible algorithms to do the numbering that would be more efficient.

We had the following inputs:

  1. The revsision id you are trying to give a dotted number for.
  2. The tip of the mainline that you are numbering against.
  3. The revision number of that mainline revision.
  4. A map of revision_id -> parents.

And you are asked to provide the revision number for the specified revision. Any other numbering that you may be able to do along the way would be a bonus.

The fact that all we are given to get the information we need is a map telling us the parents of a revision id means that we cannot ask the question "what are all the children of this revision?"

I don't really want to explain the numbering scheme here, as it is a little long-winded to do so. The outline is that for the first digit you find the intersection of the target revision's left hand ancestry with the mainline, and use its revision number. For the second digit you find all of the branches that originated at the revision found in the first part, and then number them by the order that they merged back in to mainline. The third digit is then just the place of the revision in its own part of one of these branches.

Notice the second step there. Remember that we are not able to retrieve the children of any revision? That means that we must work backwards from our mainline to do this. This is where the real complexity comes in, and it appears as though it is necessary to search a reasonable amount of history to calculate this part.

After the discussion with John I had a reasonable idea of how such an algorithm would work, and yesterday I posted a first draft of that to the mailing list. We have found some problems with it, and haven't benchmarked it yet to see if it is actually an improvement, but hopefully it will evolve and prove to be faster.

Displaying logs, and history emphasis

The revision numbering code has a very close relationship, and also interacts with it in an awkward way from a performance standpoint. This lead to John explaining to me how the logs are generated in more depth.

When bzr produces logs by default it emphasises the left hand parent to produce your mainline. It then indents any revisions that you merged:

>       -----------------------------------------------------------
>       revno: 3270
>       committer: Canonical.com Patch Queue Manager <pqm@pqm.ubuntu.com>
>       branch nick: +trunk
>       timestamp: Thu 2008-03-13 00:40:30 +0000
>       message:
>         (Adeodato Simo) Add a space after "revision-id:" in log output.
>          -----------------------------------------------------------
>          revno: 3257.2.1
>          committer: Adeodato Simó <dato@net.com.org.es>
>          branch nick: foo
>          timestamp: Sun 2008-03-09 23:06:47 +0100
>          message:
>            Add a space after "revision-id:" in log output.
>       -----------------------------------------------------------
>       revno: 3269
>       committer: Canonical.com Patch Queue Manager <pqm@pqm.ubuntu.com>
>       branch nick: +trunk
>       timestamp: Wed 2008-03-12 23:08:34 +0000
>       message:
>         (Daniel Watkins) Add a --revision option to 'bzr push'
>           -----------------------------------------------------------
>           revno: 3256.1.5
>           committer: Daniel Watkins <D.M.Watkins@warwick.ac.uk>
>           branch nick: push-r
>           timestamp: Sun 2008-03-09 18:41:31 +0000
>           message:
>             Added NEWS entry.

To do this it must decide which revisions are present in the history of one revision, but not in the history of its left hand parent. To do this it starts off two history walkers in parallel, one walking the history of the first revision, the second walking the history of the parent. The first walker then stops walking down a particular line of history when the second "claims" it, once the first walker has no more lines of history to walk it returns its group of revisions, and the log formatter code then displays them indented as necessary to match the history.

This is a much more complex process than that you get with "git log", in which the revisions are produced in just date order. There is a "--topo-order" option to git log, but that just ensures that all parents are output before their children. It doesn't ensure that all parents not in the ancestry of the left-hand parent are shown before the left-hand parent. The work to ensure that is significantly more than that done to provide "--topo-order".

This display makes it easy to see what work was done on a branch, and when those changes entered your branch. This is one reason why bzr's merge doesn't fast-forward by default ("bzr merge --pull" will do this for you if you like). This means that you can always instantly identify which work came from another branch and have them tied together.

Always having merge commits means that "bzr log --short" and "bzr log --line" can give you a good summary of what happened on your branch, the commits you did, and the things that you merged. It preserves a mainline for you in the left hand ancestry, which means that you can always see what happened in that particular branch. "bzr pull" then gives you a mirror of another branch, and the left hand ancestry tells you what happened in that branch.

The indentation of the merged commits (and the fact they disappear with "--short" and "--line") means that mentally they become of lesser importance. You see "merged performance work from Emma's branch", rather than all of the commits that you got from her. They are still there to look at if you want, but they can be ignored at most times.

This means that you don't have to spend time rewriting history to be clean if you don't want to. You don't have the history right in your face either way, though there can still be value in having a clean history. However rewriting history is not what some people want to do, and causes problems for those who base their work on yours.

Posted at: 16:49 | category: /bzr | Comments (0)

Wed, 12 Mar 2008

Version control systems and text editors

So apparently "learning git is like learning vim". Putting aside the incremental learning aspects of this, and stretching the point a little, will you allow me to say "git is like vim"?

We all understand there is no way in which you would mandate that all contributors use vim. You wouldn't want to lose all of those valuable contributions from emacs users of course. However, you still wouldn't dream of mandating the use of one of these two editors. Why should your choice as project maintainer constrain the way in which others want to work?

Obviously it is quite difficult to enforce this editor rule. For a start there is nothing in a plain text file that tells you what editor was used to create it. More importantly though, the contributor's choice of editor doesn't matter to you. If they send you a plain text file then your editor will handle it just as well as theirs.

This is where version control differs from editors. When using the version control system to move code around it tends to dictate the client you use to access it, so one person's decision tends to impact on others.

Is the solution therefore to work towards a situation we have that is similar to that we have with text editors, where the interchange format is understood equally well by all of the tools? Do we spend time developing wrappers for each use that allow us to ignore the fact that we are using different systems?

Recently there has been work done to make bzr support the git-fast-import format. This would then be the start of an interchange format that all tools could use to communicate. However, the problem is that the representations used in one system start to bleed. For instance, bzr supports ghosts, and we are currently discussing the adding support to the format to represent them. However git doesn't support them, and as such there will be know way to complete a round trip of bzr->git->bzr when there are ghosts involved.

So, what about the other solution? Creating wrappers that allow the user to not care what VCS they are using and just get the job done? I think this is useful to a point. It will be great for some people who just want to do really simple things on lots of projects (for instance in Debian). However the tools are necessarily catering to the lowest common denominator, they won't support any of the unique things that make each system great.

Bazaar has foreign branch support (most notably bzr-svn) which allow you to access another system as if if were bzr. This is almost completely transparent ("bzr branch svn://" makes it clear what the project is hosted in), in contrast to git-svn. The latter adds a new command that allows you to do the svn specific parts (setting up the repository, committing back to svn). In contrast bzr-svn uses the normal bzr commands for (almost[1]) everything, meaning you only need to learn the one tool. git-svn is still a great tool, but it certainly makes you realise that you are not dealing with pure git.

The competition between the systems has been great for every one of them. However, it seems like we will be stuck with different systems for the forseeable future, so we should work hard on making them work well together to ease the pain on the users. I think that many of the supporters of distributed version control would say that it is better for you to be using any of them than none of them, but the fractured and unstable landscape we have now is causing a resistance in people to make the switch.

[1]It currently adds svn-push for doing a push that creates a new branch in svn, but this is only a temporary thing, "bzr push" will be able to do this at some point. The other commands that are added are for extra things that the core bzr is not meant to deal with.

Posted at: 01:25 | category: /bzr | Comments (0)

Mon, 22 Oct 2007

Evolutionary Computing and Creationism

The lecturer who taught me evolutionary computing was also a devout Christian, who believed that the world is the way that it is because God created it, rather than it evolving via natural selection.

This was quite surprising to us when he revealed this, but he did not see a problem with holding this view. He recognised that there was a fundamental conflict between Darwinism and Creationism, but not one between his work and his religious beliefs. He could see that the theory of natural selection could be an effective optimisation algorithm where the form that the solution would take was not entirely clear, but it was not his belief that this was the mechanism by which humans arrived on this earth.

It's an interesting feature of science that he was able to hold this position and still research in the field. At one point in the year he did give a lecture on creationism itself. This was not one of the lectures that made up our course, it was an optional lecture at luchtime, open to the whole engineering faculty and other members of the University. I did not attend, but many people got very excited beforehand, seeing it as a chance to go and argue with a holder of this belief and try to discredit the idea. Perhaps they were also spurred on by the fact that he was a man of science, and so potentially more likely to listen to an argument of logical reasoning.

I don't think anyone convinced him, and I doubt anyone ever will, he has obviously confronted this issue many times in the course of his work and still holds the two potentially conflicting ideas in his head.

Posted at: 21:15 | category: /tech | Comments (0)

Thu, 18 Oct 2007

Rosemary Lamb with Roast Potatoes and Caramelised Carrots and Onions

I came up with this the other day. It's pretty rich and indulgent, but not too hard to make. The lamb could perhaps do with something else, but I can't think of anything at the moment.

  • 4 Lamb steaks
  • New Potatoes if in season, otherwise any small potato.
  • 4 Carrots
  • 2 Red onions
  • Bunch of rosemary
  • Garlic cloves
  • 2 glassed of red wine (a small bottle is fine). A good hearty one if possible
  • Gravy powder
  • Thyme (dried works fine)
  • A knob of butter
  • 3 Tablespoons Brown Sugar

If you can prepare the lamb the day before it will be better, but a couple of hours is fine. Place the lamb steaks in a small container. Take a third of the rosemary, and snap it a couple of times and place it in with the lamb. Next bash open the garlic cloves (there's no need to peel them first) and add them. Get your hands in there and rub both in to the meat, mixing it up. Next add a glass of wine, cover and leave to marinate.

About an hour put some oil in a baking tray and place it in the oven to heat up. Brush the potatoes clean then drop them in the hot oil, add some salt and pepper and snap the remainder of the rosemary and drop that in. Put them back in the oven.

Next brush the carrots clean (you can peel if you like), and chop them in to batons. Then quarter the two onions. Melt the butter in the frying pan over a hot heat. Add the carrots and onion, and stir fry for a few minutes. Then add the sugar and keep stirring. After a while you can turn the heat down to a medium heat. Keep stirring regularly, as they will like to stick.

After about 15 minutes place the lamb under the grill on a medium heat. Make up a serving of gravy in a saucepan, adding one more teaspoon of mixture than suggested. Add the second glass of wine, and put on a low heat on the hob.

When the lamb is cooked to your satisfaction then remove the potatoes from the oven and plate up. Next add the carrots and onions, and finally the meat. (I like to stack the ingredients here). Finally tip the juice from the meat in to the gravy and turn the heat right up and stir for one minute. Finally pour a little gravy on each plate and serve.

Enjoy!

Posted at: 18:52 | category: /food | Comments (0)

Wed, 07 Mar 2007

Facebook and copyright

A lot of my friends are on the Facebook site, and they upload pictures there, so I joined to see those. One of the things the sute has is a profile picture, and I wanted to upload one for me. I chose one and entered the filename in the box. The other part of the form was a checkbox to accept the terms of use for the site. Presumably every user accepts these as they sign up, but having it there as a reminder about the parts on content is admirable perhaps. Anyway I clicked on the link to read those parts out of interest.

After reading them I clicked the upload button, but had neglected to check the box, and up popped a message:

You must certify that that image is not
copyrighted before you upload.

Please click the checkbox to certify.

After learning about copyright and license issues throught libre software this sort of thing jars with me now, so I sent a message off to the admins (after searching for ages for some sort of contact form).

My problem with the above message is that it is incorrect and misleading. It is incorrect as that is not what the box is for, the box is to agree to the terms of use. The terms of use include some statements on copyright, but not that the material uploaded must be free of copyright. Perhaps a short detour in to the law of copyright (as I understand it) is warranted.

Copyright is associated with a creative work, and usually is automatically assigned to the author upon its creation. This requires no special action on the part of the author, though if they are sensible they will add a copyright statement to the work to let people know when it was copyrighted and by whom. Having the copyright on a work allows you special priviledges with respect to that work.

Now just because I have the copyright on a work doesn't mean that you can't use it, but for you to do that I must have granted you a license. A license is nothing more than a statement of what you are allowed to do with the work. They can be very simple, or very complex.

Very often in the media they refer to people distributing copyrighted work when they are discussing music or film piracy. While this is true, it is not exactly the problem, the problem is that the copyright holders (the music and film companies) have distributed the work under a license that does not allow redistribution. This means that even though they have sold you the film, you can't pass it on to other people.

On the cases of CDs and films you can find the copyright statement with the familiar (C) symbol. Next time you see it read past that and look at the next bit. Usually it will say something along the lines of:

Unauthorised copying, hiring, lending,
public performance and broadcasting
of the record are prohibited.

Which is a license stating that you can't do much with the CD you have bought.

However it is not the most restrictive license you can have. If a work has no license attached it then it should be assumed that you shouldn't even be looking at it. This can obviously be slightly problematic.

So this means that the facebook notice above is incorrect, as what they want is not non-copyrighted material, as the copyright of most (all?) of the photos on there will be held by someone (it doesn't expire for quite some time). What they want to know is that the person uploading has permission to distribute the file on their site.

You may think that I am just being picky over terminology, but I believe that this misuse of language is actually keeping people in the dark. Whenever the media, or a website, or someone I meet talks about whether a work has copyright or not as being the deciding factor in whether it can be distributed it continues the misunderstanding. If everyone were to understand that when they create a work they have the copyright of it, and must grant a license so that it can be used by others then they may be more inclined to do so. In fact I believe that many people would grant very free licenses, massively increasing the amount of free content available.

Take Flickr for instance they provide the user with an easy way of providing their pictures under one of several good licenses. Most of the pictures I have seen on that site are provided under the more free choices.

The other problem with facebook's approach is that their terms of use ensure that they have a license to host the picures, but they don't ensure anything about what the users can do with them. This means there is a mass of content, but it is all unusable by others due to the unclear situation. This is a very common problem, and could be mitigated by more people understanding the issues.

Posted at: 22:25 | category: /life | Comments (0)