Thu, 25 Sep 2008
Why Python Is More Productive Than C, C++ or Java
Wed, 24 Sep 2008
'Open' Considered Harmful
In the past couple of days, there have been two posts on the programming reddit that have caught my attention:
- OpenGL finally "Open", about OpenGL being licensed as free software, and
- Open Sound System is now open sourced!, about OSS being licensed as free software.
Here we have two codebases that seem obviously free. They are seemingly accepted within the free software ecosystem yet until recently have not been free software. Never having used these from a coder's perspective, I've never had any reason to investigate their licensing thoroughly. However, I've certainly used them as part of my desktop, and still had no idea.
This suggests to me that using the term 'open' to refer to software that is free as in speech is harmful. You will do only one of two things:
- suggest to people who are already sceptical of the term 'open' that your software is not necessarily free, requiring them to investigate more closely, or
- suggest to people who don't know any better that, when used to describe software, 'open' is a synonym for 'free as in speech', which the examples above show to be untrue.
There is no good reason for someone developing free software to want either of these things to happen. The only incentive I can see here is for someone who wants their code to be accepted within the free software community without the supposed disadvantage of licensing their code under a free license.
If you're not convinced, consider Microsoft's latest file format offering, Office Open XML. If that doesn't convince you, you're not even trying.
EDIT: It has been noted in Reddit comments and in #wuglug that these complaints apply to 'free' as well. I should note that:
- I never intended claimed that using the word 'free' in a title was better. I've edited the second bullet to reflect my intended meaning better.
- The use of the term 'free' in a title would, in addition to any implications about 'free as in speech'-ness, also imply 'free as in beer' but this is normally true of 'free' software anyway (whereas 'open' has only one implication, which often should not be implied).
Posted: Wed, 24 Sep 2008 20:05 | | Comments: 0
Tue, 23 Sep 2008
htop
Posted: Tue, 23 Sep 2008 08:42 | | Comments: 0
Sat, 20 Sep 2008
The Updated State of PQM
Patches that have been merged
Patches up for review
These patches are currently in BundleBuggy, waiting for review or merging:- Already approved: Reporting details of successful merges
- Trivial patches: Fixing test stipple, making tests pass, web UI fixes for legacy commands, fix email failures due to a lack of merge base
- Merge directive support: This is largely a reworking of Aaron's previous work on this. It's functional, and reasonably well-tested, but I'm not entirely convinced that it fits the abstraction correctly. I'm not sure that this is the case, but it certainly needs thought.
- Reporting details of successful merges: This is just a cleanup of Tom Haddon's patch on Bug #55717, and is reasonably trivial.
- Reporting of errors caused by unknown branch formats: This is, again, a pretty trivial patch. It fixes Bug #246660, which a couple of people have hit recently.
- Switching the web UI to SimpleTAL: This makes the Web UI code much nicer and easier to modify. It also lays the foundations for further work on the web UI, including RSS feeds. It has received several rounds of review, so should be pretty much there.
- Removed Arch-specific commands: As Robert and I discussed in London, some existing commands shouldn't be needed by any Arch implementation (and certainly aren't required by bzr). This patch removes those commands.
- 'nodebug' command: Adds a nodebug command, so that only specific parts of a given script have to have debug enabled.
- TestCaseWithQueue: Converts the tests to use a TestCaseWithQueue, which abstracts away queue creation. This will allow for testing of several different scenarios, which is especially helpful in testing the UI.
Patches in the wings
These patches are waiting on patches in the above list to be merged:- UI Unicode fixes: Depends on the SimpleTAL changes. Fixes encoding issues with displaying Unicode names in the web UI, fixing Bug #125888.
- New UI tests: New UI tests using the TestCaseWithQueue changes. This improves the test coverage of the UI by a considerable amount.
- RSS feeds: This adds RSS feeds for each PQM project, containing the same information as is given in the Web UI, fixing Bug #133229.
- PatchCommand: This moves the logic for accepting patches from CommandRunner to a separate PatchCommand. This is the first step towards removing CommandRunner entirely.
- XMLRPC: This is a loom containing two threads of work:
- 'xmlrpc': The basic XMLRPC functionality. This includes some email-message-related abstractions, so that both the email and XMLRPC interfaces could use the same functions. This fixes Bug #246845.
- 'xmlrpc-validation': Validation of incoming XMLRPC requests. This takes each command in the incoming script and checks that branches it references are valid and that the submitter has commit access to them. It goes some of the way towards fixing Bug #110433.
Patches in progress
These patches are currently in development:- TagCommand: This branch adds a TagCommand, intended to replace the functionality in CommandRunner. The CommandRunner code is not removed, and there are some issues with 'tag' meaning different things in Arch and bzr.
Posted: Sat, 20 Sep 2008 12:34 | | Comments: 0
