Older blog entries for richdawe (starting at number 139)

Thanks to Linux desktop developers

I've just caught up with 2 years' worth of Linux desktop developments (NetworkManager works, user switching, built-in volume controls working on my laptop). I like. Thanks for all the hard work, Linux desktop developers!

PS: Turning on "subpixel aliasing" has made text much more readable.

Syndicated 2009-01-31 18:06:01 from richdawe

Occasional lock-ups due to Parallels & FileVault?

I've been running a Windows VM under Parallels on my work Mac. I have my home directory encrypted using FileVault. I've had ~5 lock-ups in the past 6 months where my Mac has just locked hard. It always seems to happen when I'm using a Windows VM. I've allocated 768 MB of RAM to the Windows VM. The Mac has 2 GB of physical RAM. The disk image is pre-allocated, to avoid performance problems with it being resized on the encrypted volume.

I've wondered if the box has locked up because FileVault cannot allocate memory for some reason. This doesn't seem to happen in normal usage. Maybe the Windows VM is pushing memory usage over the edge.

Today I've switched to hosting the Windows VM disk outside the encrypted partition, and using NTFS encryption for the data I need to protect. Hopefully that will work better.

Syndicated 2009-01-09 19:42:20 from richdawe

Interesting essay on "Misunderstandings of Privacy"

I found the article "'I've Got Nothing to Hide' and Other Misunderstandings of Privacy " by Daniel J. Solove interesting. Specifically how he tried to categorise privacy into different categories based on the kinds of problems encountered, and his discussions on privacy and the relationships between individuals and society.

Syndicated 2008-12-31 14:13:46 from richdawe

3 mobile broadband on Mac

I got some mobile broadband from 3 to cope with a two-week gap in my wired broadband provision. I had some pain getting it to work on my work Macbook Pro (which is a US one) running Mac OS X Tiger (10.4.x).

The software gave me an obscure error -- "internal error 5370" or similar -- when running the 3 Connection Manager software. According to a techie in the 3 store I went to, I needed to download the latest drivers from the 3 website. That was pretty hard to find. It turned out to be on the support page for the Huawei E160G on Mac OS X 10.4. (I don't recall how I found that page.)

I uninstalled the old software, deleted the "3Connect" folder from applications, installed the new software and fired up the "MobileConnect" application. That detected the 3 network, but crashed when I tried to connect. This thread on the Huawei forum suggested that I could create a profile in the Network panel of the computer settings:

Firstly, run the “Mobile Connect” Make sure under “settings” there is a profile: I called mine “3 USB Modem”, with Access Point name of 3internet and Telephone number of *99#. You only need to do this once.

Secondly, go into System Preferences. In the Network pane, select the HUAWEI mobile device in the left pane. Now, in the right pane, under Configuration, select “Add Configuration”. I caled mine “Three”. Add *99# as the telephone number, make sure “Show modem status in menu bar” is ticked (for convenience) and you’re all set.

I had to enable a profile called "HuaweiMOBILE" first. Once I edited that as instructed above, I found that the MobileConnect application could connect.

Actually, it failed to connect the first time due to some authentication error. But it's worked every time since. Perhaps the auth error was a signal strength issue.

Syndicated 2008-11-10 20:14:26 from richdawe

Knowing what rpms you've just built

One idiom I've found myself repeating in various projects is a build-all script that builds multiple rpm packages in a certain order. This isn't very sophisticated -- each time I've ordered the packages being built manually.

But how do you know what rpms you will get, when you run rpmbuild? You need to know this, so you can install the rpms. Here is a solution:

specfile=project.spec

RPMDIR=$(rpm --eval '%{_rpmdir}')

# What format does rpm use for built binary rpms?
# %{ARCH}/%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}.rpm
BUILD_NAME_FMT=`rpm --eval '%{_build_name_fmt}'`

rpms=$(rpm -q --specfile $specfile --queryformat "$BUILD_NAME_FMT ")

pushd $RPMDIR
rpm -ivh $rpms
popd

This works as follows: get the rpm root directory into $RPMDIR; find the format rpmbuild uses for built binary rpms; query the rpm specfile for packages and format the results using the build rpm filename format; finally, go into the rpm root and install all the binary rpms.

Syndicated 2008-10-03 08:45:23 from richdawe

File::ExtAttr 1.08, (Open)Solaris and 2 xattr schemes

I released File::ExtAttr 1.08, which has some changes to make it report errors more consistently ($! should always contain the value of errno now). It also has some build changes, which will hopefully avoid all the CPAN Testers FAIL reports on platforms that don't have the development packages installed for using xattrs (libattr-devel rpm on Linux).

I development this release on various platforms, but the most exciting one was OpenSolaris 2008.05 (AKA Project Indiana). This is so much easier to install and use than Solaris 10. It's much more like using a Linux distro. The OpenSolaris LiveCD is very easy to install, and things just seem to work. It took about 6 steps to get a fully functional development environment for File::ExtAttr.

While developing 1.08 on OpenSolaris, I discovered that it has two separate ways of storing extended metadata: extended file attributes, and extensible system attributes. The extensible system attributes were added as part of supporting CIFS on ZFS. It's still unclear to me why the existing metadata scheme wasn't good enough -- maybe the semantics of the original xattr interface weren't compatible with the use cases?

(The original xattr scheme is that you open the file as though it were a directory, and then the xattrs can be accessed through directory entries. This is clever, but different to the way Linux, *BSD and Mac OS X implement xattrs.)

I'm now not sure which xattr API I should be exposing through File::ExtAttr. I guess it comes down to which one will be more portable across platforms. I think that will be determined by which xattrs are preserved by tar, etc.

Anyow, here's the change log for File::ExtAttr 1.08:

1.08 2008-08-19

     - (richdawe) Add a typemap for usage of "const char *" in the XS.
                  This may help fix the build with Perl 5.6.x or earlier.

     - (richdawe) Remove NetBSD 3.x from list of supported OSes,
                  since File::ExtAttr's test suite will never pass on it.

     - (richdawe) Update Makefile.PL to fail more gracefully when the build
                  pre-requisites are not present. On Linux use
                  Devel::CheckLib to check for libattr. Also exit
                  more gracefully if libattr's headers are not present.

     - (richdawe) OpenBSD isn't supported, so bail gracefully
                  in Makefile.PL on that platform.

     - (richdawe) Make sure that the errno value from any failed
                  system calls is propagated into $! (#32679, #32680).

     - (richdawe) File::ExtAttr no longer generate noisy warnings
                  when an xattr system call fails. All error reporting
                  is now via the function return values and $!.

     - (richdawe) Operations with non-default or non-"user" namespaces
                  will now fail with EOPNOTSUPP instead of ENOATTR
                  on Mac OS X, *BSD and Solaris. This behaviour
                  matches the behaviour on Linux.

     - (richdawe) Added a note to the documentation about Solaris
                  extensible system attributes, which are different
                  to extended file attributes.

Syndicated 2008-07-19 11:29:32 from richdawe

19 Mar 2008 (updated 7 Jun 2008 at 10:28 UTC) »

rpm: Filtering dependencies differently for different subpackages

Recently I was trying to work out how to filter rpm Requires/Provides dependencies differently for different subpackages. I was trying to produce a subpackage that was the same as another subpackage, but stripping out some library dependencies. Call the one subpackage foo and the other foo-nodeps. (Don't ask why I was trying to do this.)

rpm has a way of hooking the dependency generation, as described in FilteringAutomaticDependencies at the Fedora wiki. This is pretty magical. You disable rpm's internal dependency generation. You can then override the default external dependency generation scripts (if you want). Normally rpm uses find-requires and find-provides in /usr/lib/rpm, or /usr/lib/rpm/redhat on some Red Hat or Red Hat-derived systems. If you do override the scripts, it's likely you'll want to call them and filter their output.

When you define your own dependency generation scripts, they are applied to all subpackages. There is no information passed to the script to indicate which package/subpackage it is being call for. You can pass arbitrary parameters to your custom find-requires/find-provides scripts. But there are no macros that you can use to pass that in as a parameter (%name is always the main package's name -- there's no %subpackage macro AFACIS).

A solution was to pass that information in via the filesystem. In the %install script I'd create a file per package. Something like this:

mkdir -p %{buildroot}/NOTINSTALLED
touch %{buildroot}/NOTINSTALLED/foo.ghost
touch %{buildroot}/NOTINSTALLED/foo-nodeps.ghost

Then in each package's file list I'd put the appropriate file:

%files
...
%ghost /NOTINSTALLED/foo.ghost

%files nodeps
...
%ghost /NOTINSTALLED/foo-nodeps.ghost

The %ghost ensures that the file isn't installed, but is still passed to the find-requires/find-provides scripts. A custom find-requires script can then find out which subpackage it's being called for. Something like this:

cat > .files
if (grep -q -E '^/NOTINSTALLED/foo-nodeps.ghost$' 2>/dev/null); then
  # Filter out dependencies on libfoo
  /usr/lib/rpm/find-requires | grep -v -E '^libfoo.so'
else
  /usr/lib/rpm/find-requires
fi

Syndicated 2008-03-19 22:38:52 (Updated 2008-06-07 09:50:56) from richdawe

FileVault

I enabled FileVault home directory encryption on my work Macbook Pro the other day, which is running Mac OS X Tiger (10.4). I was a little bit hesitant about doing this, because of various horror stories about it not working, or performance being terrible. I made sure I had a proper backup, before starting the process.

The 160 GB hard disk was about 40% full before I started. It took 1.5 hours to encrypt my 41 GB home directory, followed by 3.5 hours to securely erase the old unencrypted version.

The performance afterwards seems to be generally the same before. The only exception I've hit so far is with Parallels resizing an expanding disk in a virtual machine, and there the performance is terrible. This makes some kind of sense: There are two disk images being expanded, the Parallels VM disk inside the encrypted home directory, and then the encrypted disk image containing the home directory. Pre-allocating the disk image for the VM helps, because it means no resizing is required at run-time.

Some of my preferences seem to have been lost. I had to make Firefox my default browser again. And I had a hot corner to turn on the sceensaver, which mysteriously stopped working -- I fixed that by setting a different corner to do "show desktop", after which the screensaver hot corner worked again (strange).

Syndicated 2008-01-12 08:50:47 (Updated 2008-01-12 08:53:13) from richdawe

Recycling Compact Flourescent Lightbulbs (CFLs)

I read in Scientific American that Compact Flourescent Lightbulbs (CFLs) contain mercury, and some US stores/states have recylcing programmes at stores or kiosks. I didn't realise they contained mercury, and probably would have just thrown them in the bin with my other rubbish. Links:

Compact Fluorescent Light Bulbs at energystar.gov
Compact fluorescent lamp at Wikipedia
Toxic Mercury In CFL Bulbs
lamprecycle.org (not much use here in the UK)

I had a look to see what's on offer in the UK. The "Recycle Now" website doesn't seem to contain any information about how to recycle CFLs. Greenpeace has an article about CFLs, which suggests I should be able to take them back to the retailer. Do I have to prove that I bought the bulb from the retailer in the first place?

Syndicated 2007-11-11 21:56:35 from richdawe

4 Nov 2007 (updated 19 Jul 2008 at 12:07 UTC) »

File::ExtAttr 1.06, mab2ldif

I released File::ExtAttr 1.06 to fix building on Mac OS X. File::ExtAttr provides an interface to extended file attributes (meta-data) that's consistent across Linux, Mac OS X, *BSD, Solaris.

I also released mab2ldif, which takes a Mork-format address book (e.g.: as used by Thunderbird) and converts it into an LDIF file. You can import the LDIF file into Thunderbird. I wrote this to recover my old Thunderbird address book from an old computer that died. You can actually export the address book from Thunderbird into LDIF, but if Thunderbird won't run, you'll need this tool to get your data back.

Syndicated 2007-11-04 10:45:11 (Updated 2008-07-19 11:18:24) from richdawe

130 older entries...

New Advogato Features

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!