pjcj's notes

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

Sat, 28 Apr 2007

Setting up the N800

Here's the steps I have taken to flash my wife's N800 and make it useful.

Flashing

From maemo.org,

Get the linux flasher-3.0 and firmware image. Put them in the same directory on your linux box.
Update: get the latest image.
Switch off the N800, unplug the charger and connect the N800 to your linux machine with the USB cable.
As root, or a user with permissions to access USB, run

./flasher-3.0 -F RX-34_2007SE_3.2007.10-7_PR_COMBINED_MR0_ARM.bin -f -R

Update: run

./flasher-3.0 -F RX-34_2007SE_4.2007.26-8_PR_COMBINED_MR0_ARM.bin -f -R

Wait for the message

Suitable USB device not found, waiting

Switch on the N800 by either
- Plugging in the charger or
- Switching it on using the power button whist pressing the Home button
The image should now flash and the N800 will reboot

Get root

In order to do anything interesting, you'll need root access. This involves adding a repository and installing a couple of applications. The N800 uses the debian packaging system, so this will be familiar to anyone who is used to debian or ubuntu.

Add the repository

Catalog name Maemo Repository

Web address http://repository.maemo.org/

Distribution bora

Components free non-free

See http://maemo.org/maemowiki/MaemoReleasesRepositoriesDistros for more information.

Install osso-xterm.

Update: Also available here.

Install becomeroot by clicking on http://eko.one.pl/maemo/dists/mistral/user/binary-armel/becomeroot_0.1-2_armel.deb in the browser on your N800.

Start xterm. It's in the extras menu.

run sudo gainroot

set the root password

Red pill mode

Red pill mode is an (ex) easter egg providing access to some advanced features. Activate it by going to add a new application catalogue, setting the "Web Address" to "matrix" and pressing "Cancel".

See http://hildon-app-mgr.garage.maemo.org/redpill.html for more information.

Ssh

Install the ssh package.

Update: Also available here.

Configure

Perform whatever configuration you would like. For example:

Set the hostname - echo myn800 > /etc/hostname
Set up hosts - scp myserver:/etc/hosts /etc

Add packages

Other useful packages can be found at http://maemo.org/downloads/, for example:

wget

Install by clicking on http://mg.pov.lt/770/wget.install

Start the server by running x11vnc.sh&

vnc

Download http://mike.saunby.googlepages.com/x11vnc_0.8-3_armel.deb from http://mike.saunby.googlepages.com/x11vncfornokia7702 and install it using dpkg -i x11vnc_0.8-3_armel.deb.

In order to get mouse clicks working properly, you will need to add the string " -extension XInputExtension" to the ARGS string in the file /etc/init.d/x-server. For me, that leaves line 5 as

ARGS="-mouse tslib -nozap -dpi $DISPLAY_DPI -wr -nolisten tcp -extension XInputExtension"

Then reboot.

Gizmo

Install http://download.gizmoproject.com/GizmoDownload/gizmo-project_2.0.0.56_N800_armel.deb from http://www.gizmoproject.com/download.php.

rsync

Install from http://maemo.org/downloads/product/grsync/. (Doesn't seem happy to install. Perhaps it's only for the 770 after all?)

Claws-mail

Install from http://maemo.org/downloads/product/claws-mail.

Canola

Install from http://openbossa.indt.org/canola/help.html. Reboot after the installation. To enable clicking on items, run

gconftool-2 -s -t bool /apps/canola/plugins/uicontainer/free_click true
gconftool-2 -s -t bool /apps/canola/plugins/uifolder/free_click true

Boot off SD

Why might you want to do that? Well, you get your root filesystem somewhere where it's not going away, you can make it as large as you need and, as a bonus, not being a jffs2 filesystem it will probably seem about twice as fast.

Partition the SD card

I've seen instructions for doing this on the N800. It seems easier to me to just plug a card reader into your linux box and partition it that way.

Make the first partition FAT16(6) and the second linux(83).

fdisk /dev/sdb

Format the partitions

mkdosfs /dev/sdb1
mke2fs /dev/sdb2

On Ubuntu, removing and reinserting the card should be enough to create the required devices to run these commands.

Get GNU tar onto your N800

The busybox tar just won't cut it, so you'll need to get the GNU version onto your N800. However you do that, you'll need somewhere to put it, so first

mkdir /root/bin

You can get tar onto the N800 using the N800 by downloading the tar .deb file and extracting the tar binary:

apt-get -d install tar  (you'll need to answer Y to the questions)
mkdir /t
dpkg -x /var/cache/apt/archives/tar*.deb /t
mv /t/bin/tar /root/bin
rm -r /t
apt-get clean

Or you could do a similar thing on your linux box, getting the .deb from http://repository.maemo.org/pool/bora/free/binary/tar_1.14-2.1osso_armel.deb (or whatever the current version is) and scp it across. That particular tar_1.14-2.1osso_armel.deb is also available from my site.

Or just download the thing from my site.

Mount the rootfs

mkdir /mnt/rootfs
mount -t jffs2 /dev/mtdblock4 /mnt/rootfs

Copy the rootfs

The rootfs needs to be copied to newly created partition. Again, this can be done directly on the N800, but it seems easier just to do it whilst the SD card is connected to the linux box. On the N800:

/root/bin/tar cf - -C /mnt/rootfs/ . | ssh -l user myserver tar xvf - -C /media/usbdisk-1

Enable dual booting

This part is possible due to the work of Frantisek Dufka.

Download the initfs_flasher and unzip it.

tar xvzf initfs_flasher.tgz
cd initfs_flasher

Make sure the N800 has sufficient power, close all applications, disconnect from the network and open an xterm. Run the flasher

./initfs_flash

After the reboot, run

chroot /mnt/initfs cal-tool --set-root-device ask:mmc2

and reboot

shutdown -r now

Links

[/unix/n800] permanent link

Fri, 27 Apr 2007

Adding disks to VMWare

create the disk using the VMWare UI
fdisk /dev/sdc (or sdb or whatever you have created)
mkfs -t ext3 /dev/sdc1 (or sdc2 or whatever you have created)
create the mount point(s)
edit /etc/fstab
mount -a
df -h

[/unix] permanent link

Wed, 14 Mar 2007

When alpha releases aren't

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.

[/software] permanent link

Fri, 09 Feb 2007

Removing duplicate PATH entries

I was creating a little setup shell script to be sourced to set up an environment. It's the standard thing; set a few environment variables, play with the filesystem, start some things. Part of it adds directories to PATH and LD_LIBRARY_PATH.

Then I wondered about it being run more than once. I don't imagine great problems, but multiple entries in the PATH look ugly.

So I wrote this little function to clean up the PATH, or any other similar variable:

tidy () { echo -n $1 | perl -naF: -e 'print join ":", grep !$s{$_}++, @F' }

It can be called as:

export PATH=$(tidy $sw/bin:$PATH)
export LD_LIBRARY_PATH=$(tidy $LD_LIBRARY_PATH:$sw/lib:$ORACLE_HOME/lib)

which seems to work well enough.

[/unix] permanent link

Tue, 30 Jan 2007

hosts file

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