Tue, 06 Jan 2009
To get amarok to use the SPDIF output, first use alsamixer and unmute the IEC958 output.
Then in the Configure Engine section of amarok, use the xine engine, the alsa output plugin, and change the alsa device configuration from:
Mono: default 4 Channels: plug:surround40:0 Stereo: default 6 Channels: plug:surround51:0
to
Mono: plug:spdif 4 Channels: plug:spdif Stereo: plug:spdif 6 Channels: plug:spdif
[/software/amarok] permanent link
Sun, 23 Nov 2008
I use Gallery to display my photos. I'm mostly happy with it and have developed the following work-flow to help me add pictures with the minimum of fuss.
- Copy the pictures onto my server. I generally do this via scp or an NFS mount.
$ cp -a /media/CAMERA/DCIM /mnt/server/pics/new
- Run my autorotate program to name the files based the date and time the pictures were taken, split them into directories based on the date, and rotate the pictures based on the EXIF orientation information.
$ autorotate /pics/new/**/*(.) # this is zsh syntax
- Then I run nautilus on the created directories (in /pics/new) to look at the pictures and delete the ones I don't want. Using the icon view and setting the icon size to 400% makes it quite usable for this. I can also run my rot script here to rotate any photos that were incorrectly rotated or which came from a camera without orientation information. Finally, I make sure all the photos are in the folders I want them to be in.
- Then I log into gallery and go into my pending directory. Here I upload the directories using Add Items / From Local Server.
- Then I can move the directories to where I want them to live and choose the highlight pictures. Nautilus is also good for this.
- I like the majority of my albums to be arranged chronologically, and for the album to have the date and time of the first photo in it. To easily do this I then run my set_gallery_album_dates program.
$ set_gallery_album_dates
- When I am happy, I check the albums and then set the permissions so that they are viewable. Since this is a right pain I will generally go to the top level album and remove the permissions then add them again making sure the apply changes to sub-items box is ticked. I check this has worked by temporarily setting the display mode (in the bottom right hand corner) to guest.
- Finally, I clean up the old files. I've spent too much time double checking old directories full of pictures against what's in the gallery.
$ rm -r /pics/new/* /pics/sorted/*
- And the very last step, unmount the memory card, put it back in the camera and format it.
[/software/gallery] permanent link
Sat, 22 Nov 2008
Sometimes EXIF date information on pictures can be incorrect, usually because the clock on the camera is set incorrectly. To adjust a set of pictures with incorrect EXIF date information I run a command similar to:
$ exiftime -v+1y -fw *
This will add one year to all the EXIF date tags in all the pictures in the current directory. The modifiers are y, m, w, d, H, M, and S and they can be adjusted forwards with + or backwards with -.
For complete details, see the man page.
[/software/gallery] permanent link
Fri, 21 Nov 2008
To watermark a picture I run a command similar to:
$ composite -gravity Center -quality 90 -dissolve 50 watermark.png pic.jpg pic-w.jpg
[/software/gallery] permanent link
Mon, 14 May 2007
ORA-00257: archiver error. Connect internal only, until freed.
I run Oracle-XE on Ubuntu and got the error message:
ORA-00257: archiver error. Connect internal only, until freed.
I had previously enabled the archive mode and it seems that the logs had filled up my disk. Now, this is almost certainly the wrong thing to do, but I just deleted the log directories in /usr/lib/oracle/xe/app/oracle/flash_recovery_area/XE/archivelog.
The directory can be determined by running
select member from v$logfile;
Well, the first part of it can, anyway.
Then I restarted the database and the world was put in order. Or at least a small part of it was.
Anyway, archive mode can be enabled with:
shutdown immediate; startup mount; alter database archivelog; alter database open; select log_mode from v$database; alter system archive log start;
and disabled with:
shutdown immediate; startup mount; alter database noarchivelog; alter database open; select log_mode from v$database;
You can see interesting information about the archives with:
archive log list
[/software/oracle] permanent link
Wed, 14 Mar 2007
I suspect that the most popular of the software I have written is Devel::Cover. Devel::Cover is the Perl code coverage module. The first release was 0.01, and it escaped into the wild (aka CPAN) on 9th April, 2001, so the software is now almost six years old.
The current release is 0.61 and that does actually represent 61 releases. Since the very first release, the README file (and the pod for the main module, from which it is generated) has included the sentence:
If you can't guess by the version number this is an alpha release.
When I wrote that sentence it was very obvious to me what it meant and it never occurred to me that it might have a different meaning for other people. I have also never considered removing the line from the documentation, and I'll explain why later.
However, in the subsequent six years, I have noticed many people asking whether this meant that the module wasn't in a state where it could be used, or some similar question. Others have normally answered this question stating that the software has been working quite well for them, and I have been happy to leave things at that.
But today, as the question was asked again, I did something I should have done five years or so ago - I actually thought about the reasons behind the question.
And here we come to the crux of the matter. What does an alpha release actually mean?
To me, alpha releases, beta releases, release candidates and full blown releases come with a specific set of expectations, and the version numbers of the releases serve to confirm those expectations. I thought these expectations were common when I first started writing software, but it now appears that I might be clinging on to a minority view.
The key word in these expectations is interface. In an alpha release you can expect the interface to be unstable. That means that the interface may well change between alpha releases without warning.
In a beta release the interface should be stable. Wider usage and more thorough testing of beta releases may show problems, the resolution of which might involve an interface change, but that should be the exception rather than the rule and would probably involve returning back to alpha status until the new interface was considered stable again.
A release candidate should be just what it says, and if no problems are found it should become the actual release. And a release itself should be stable software, properly tested and with all the advertised features required to make it useful.
There are almost as many versioning systems as there are developers, and I'm not overly concerned about their details, provided they are consistent. But one aspect of the versioning system should hold - an increase in the major version number should indicate a backwards incompatible change to the interface. Otherwise interfaces should be backwards compatible across the same major version.
[ Note: Some version systems, such as that used by perl, for example, may choose slightly different semantics. In the case of perl, the system is Revision.Version.Subversion and the promise is made that compatibility is maintained across Revision.Version. But since Perl 5 is over 12 years old, the effect is much the same. ]
Notice that these definitions only talk about interfaces. Specifically they do not talk about features, quality or bugs, with the exception that a full release would be expected to have a reasonable quality.
But it seems that nowadays, in general, that is all that these terms are expected to mean. Wikipedia, for example, (the fount of all knowledge) states:
The software release life cycle is composed of different stages that describe the stability of a piece of software and the amount of development it requires before final release. Each major version of a product usually goes through a stage when new features are added, or the alpha stage; a stage when it is being actively debugged, or the beta stage; and finally a stage when all important bugs have been removed, or the stable stage. http://en.wikipedia.org/wiki/Software_release_life_cycle - 2007-03-14
Whilst it is true that the stability of the software will generally bear a relationship to its status, I think that this description completely misses the point. But it gets worse:
The alpha version of a product still awaits full debugging or full implementation of all its functionality but satisfies a majority of the software requirements. It often lacks features promised in the final release but demonstrates the feasibility and basic structure of the software. Ibid.
No wonder people wonder whether it is safe to use my software!
Nowhere in the Wikipedia article is the word interface even mentioned, except to say that Microsoft included user interface changes during their public beta testing phase for Windows Vista. One could argue that stability includes the idea that the interface should be fixed, but the article seems to equate stability with a lack of bugs.
Now I'm not really picking on Wikipedia here. The article just seems to be reflecting the predominant perception of these terms. What really surprised me was how hard I had to search to find anyone holding the same opinion as me. To be honest, I didn't really search all that hard, but then I hadn't expected to have to search at all hard, and I did only find one reference, which was to the Python version number scheme:
Alphas are early releases in which interfaces aren't yet finalized; it's not unexpected to see an interface change between two alpha releases. Betas are more stable, preserving existing interfaces but possibly adding new modules, and release candidates are frozen, making no changes except as needed to fix critical bugs. http://www.python.org/infogami-faq/general/how-does-the-python-version-numbering-scheme-work/ - 2007-03-14
So it seems that most people consider alpha software to be incomplete and full of bugs, and beta software to be what is given to the public to do the testing. I suppose that's not too surprising given the state of much released software, even software which costs a large amount of money, but it really isn't what I mean when I use these terms.
When I say that Devel::Cover is alpha software, what I mean is that I may still change the interface to it. Over the last six years and 60 releases I've been pretty good at not changing the various interfaces, but there are some that I don't particularly like, and as soon as I come up with something better (or if I'm lucky someone else will do this) then I want to be able to change the interface without having to bump the major version number.
I also mean that there are some features missing that I would like to add at some time, and that there will be bugs so don't get upset if you find one, but mostly I mean that the interface might change.
It's really not a big deal, but since I don't have a marketing department telling me that I have to have a new major release in time for a certain trade show and that it must include the following check-box features because the brochures have already been printed and the press release has been sent out, then I'm happy staying at an alpha version until I really am happy with the interface.
And anyway, if being in perpetual beta is a mark of being Web 2.0, surely being in perpetual alpha is a mark of being Web 3.0, which puts me well ahead of the game, even six years ago.
That's why Devel::Cover is still alpha software, and that's what being alpha software means for Devel::Cover. Since I now realise that this is probably not what most people understand when they read my documentation, I'll just have to explain things in more detail. I suppose I should really be glad that not too many people read the docs.
Tue, 30 Jan 2007
On Windows XP the hosts file has the same format as /etc/hosts (it can be directly copied from there) and lives in C:\WINDOWS\system32\drivers\etc\hosts. Or, at least, it does on the machines I had to deal with.
[/software/windows] permanent link
Tue, 14 Nov 2006
A while back I wanted to know how to start apache without having to go through the pass-phrase dialogue required for the SSL on the https server. Turns out it is a faq, and the next time I need to know I'll look here.
[/software/apache] permanent link
Tue, 03 Oct 2006
I still use Gallery to display my photos and have recently upgraded to version 2. The upgrade was generally smooth and I'm fairly happy with Gallery2. But for a while I've been unhappy with the software I use to take the photos from my camera and organise them prior to uploading them to gallery.
My requirements are fairly simple. I want to be able to take a bunch of photographs from somewhere, organise them into directories named after the date on which they were taken, and the photographs themselves to be named after the date and time they were taken. I also want the photographs to be automatically rotated as required, losslessly. Finally, I don't want any duplicates. In this form, I can easily upload the directories to gallery.
I was sure I would be able to find something to do that, but I couldn't. So I finally got fed up and wrote something myself. It's only a hundred lines or so, so I probably should have done it myself a long time ago.
Anyway, here it is. I'll use it for a while, iron out the kinks, and then, if it seems worthwhile, I'll package it up somehow.
Note that the error checking is minimal, so don't delete your originals until you are happy with the results. Oh, and you'll need certain programs to be installed. So it will probably only work on *nix. I have somewhat unimaginatively named the program autorotate.
#!/usr/bin/perl
use strict;
use warnings;
my $Rotated = <~/g/pics/sorted>;
mkdir $Rotated or die "Can't create $Rotated: $!"
unless -d $Rotated;
my %Rot =
(
2 => "-flip horizontal",
3 => "-rotate 180",
4 => "-flip vertical",
5 => "-transpose",
6 => "-rotate 90",
7 => "-transverse",
8 => "-rotate 270",
);
sub date_name
{
my ($year, $month, $day, $hour, $min, $sec) = @_;
my $datef = "%04d-%02d-%02d";
my $namef = "%s %02d:%02d:%02d.jpg";
my $date = sprintf $datef, $year, $month, $day;
my $name = sprintf $namef, $date, $hour, $min, $sec;
($date, $name)
}
FILE:
for my $pic (@ARGV)
{
unless ($pic =~ /\.jpe?g$/i)
{
print "ignoring $pic\n";
next;
}
my $exif = `exiftags -a '$pic'`;
my ($date, $name, $tmp);
for my $type (qw( Created Generated Digitized mtime ))
{
next if $date;
if ($type eq "mtime")
{
my $mtime = (stat $pic)[9];
my ($sec, $min, $hour, $day, $month, $year) = localtime $mtime;
($date, $name) =
date_name $year + 1900, $month +1, $day, $hour, $min, $sec;
}
else
{
next unless
$exif =~ /Image $type: (\d{4}):(\d\d):(\d\d) (\d\d):(\d\d):(\d\d)/;
($date, $name) = date_name $1, $2, $3, $4, $5, $6;
}
$date = "" if $name eq "2005-01-01 00:00:00.jpg" ||
$name eq "0000-00-00 00:00:00.jpg";
}
my $newdir = "$Rotated/$date";
mkdir $newdir or die "Can't create $newdir: $!"
unless -d $newdir;
my $rot = `jpegexiforient -n '$pic'`;
my $trans = $Rot{$rot} || "";
print(($trans ? "rotating" : " copying"), " $pic to $name",
($trans ? " [$trans]" : ""), " ");
$tmp = "$newdir/tmp_$name";
$name = "$newdir/$name";
if ($trans)
{
my $command = "jpegtran -copy all $trans '$pic' > '$tmp'";
system $command and die "Can't run: $command: $?";
$command = "jpegexiforient -1 '$tmp' > /dev/null";
system $command and die "Can't run: $command: $?";
}
else
{
my $command = "cp -a '$pic' '$tmp'";
system $command and die "Can't run: $command: $?";
}
while (-e $name)
{
system "cmp -s '$tmp' '$name'";
if (!$?)
{
print "- exists!\n";
unlink $tmp;
next FILE;
}
no warnings "uninitialized";
$name =~ s/(-\d+)?\.jpg$/$1 - 1 . ".jpg"/e;
print "- trying version ", -($1 -1), " ";
}
# print "- renaming => $name" if $name =~ /-\d+\.jpg$/;
print "\n";
rename $tmp => $name or die "Can't rename $tmp => $name: $!";
chmod 0644, $name;
}
[/software/gallery] permanent link
Mon, 07 Aug 2006
I use ion as my window manager and on a new Ubuntu installation I decided to use ion3 instead of ion2 as on all my other installations. I don't like the standard ion configuration which hijacks all my function keys, but that was easily fixed by changing /etc/default/ion3 to
META="Mod1+" ALTMETA="Mod4+"
This uses the otherwise useless "Windows" key for options which previously had no modifier.
Then, to set the terminal emulator I want,
# update-alternatives --config x-terminal-emulator
and select uxterm, an xterm that knows about UTF8.
Then, I like to use Control-Left and Control-Right to move between objects within frames. This is done by adding the following as ~/.ion3/default-session--0/cfg_user.lua
defbindings("WFrame", {
bdoc("Switch to next/previous object within the frame."),
kpress("Control+Right", "WFrame.switch_next(_)"),
kpress("Control+Left", "WFrame.switch_prev(_)"),
})
