Xfce

Subdomains

Today I was at work from 8:45am until 7pm. While that may not be particularly impressive in the long run, it's quite a bit for me. While I didn't particularly appreciate spending the majority of my waking hours there, it's nice that the work is starting to interest me again. I'm getting to do a bit of software work. Even if I'm not really writing new code yet, digging into the Linux kernel for debugging purposes is pretty fun.

Anyway, I want to get to bed. I've been getting up early so far this week, and I'd like to keep it up.

I don't know what's going on, but the second of our three cats had to be put to sleep last night. She was diagnosed with kidney disease a few days ago, and wasn't given a lot of time. She did ok for the first couple days (albeit being tired and sluggish), but started getting sick yesterday. She seemed to be in a lot of pain, so Dad had her put down; really, the only merciful thing to do.

What to say about Gwynna... She was the youngest one, about 7 or 8 years old, I think. I didn't know her as well as the others, as she was taken in around when I left for college. She was a beautiful cat, mottled brown/orange and grey. She was very personable, and meowed all the time, sometimes seemingly for no reason. She always wanted attention, sometimes at the expense of the other two cats.

I'm not sure what else to say... I'm still a bit stunned that two of our cats have died in the past 2 months.

I was bored last night, and decided to try to fix a few xfmedia bugs. It was looking fairly decent, so I figured I'd put together a new release, since it's been over a year since the last one, and several fixes have accumulated since then. Anyway, feel free to go download it from the page above, and/or check out the summary of changes.

I have written a quick script to update the list of the images for the background in Xfdesktop.

#!/bin/sh# Update the background.list so the new downloaded wallpapers are available# to show up in Xfdesktop.LIST=$HOME/.config/xfce4/desktop/background.listecho "# xfce backdrop list" > $LISTfind $HOME/images/background/ -type f >> $LIST

Note: change in the last line the folder to the backgrounds.

This script can be either putted in an .zshrc file. Or better, if you use Xfce, save the script, under the name update-desktop-list.sh for example, to your personal bin folder (in my case $HOME/.local/bin) which is correctly set in the PATH, and run xfce4-autostart-editor. You can add the command update-desktop-list.sh.

Finally you have to set up Xfdesktop to use the list (located at $LIST) of backgrounds. Go to Settings > Desktop manager, and select the list as the file. If it doesn't exist run the script a first time.

For the hell of it, I installed Drivel. I'm not sure if I prefer blogging from a "normal" web client, or from a local client, outside the web browser.

One deficiency is that Drivel (2.0.3) seems to be unable to set more than one category for new posts. Unfortunate.

This might be out of scope for the app, but a more robust post manager might be nice. Currently you can see recent posts in a dropdown menu, but to do anything with them, you have to load the post. I'd like to have a window with a list of posts, sorted by date, category, whatever, and be able to do various things with that.

Maybe I'll play with it again some other time; it looks like a neat piece of software.

Back in March, I bought a used 12" PowerBook G4 from James. I absolutely love it, but I've had one annoying problem. I have both Mac OS X and Linux on it, and I have three partitions on the 60GB drive: one for Mac, one for Linux, and one for my home directory, which is shared between both OSes. Of course, I needed something that both of them could read and write to, so I chose the Mac HFS+ format. At the time I installed it, the ext2/3 driver for OS X didn't have write support for 10.4. It does now, but it doesn't have ext3 journaling support.

Unfortunately, the Linux HFS+ driver lacks journaling support as well, so I was forced to use a non-journaled volume, as Linux refuses to mount a journaled HFS+ volume read/write.

Now, I don't know if it's a deficiency in the Linux HFS+ driver, but 90% of the time after a hard lock (which unfortunately happens somewhat often, as the OSS Broadcom wireless drivers aren't always so stable), the filesystem gets trashed, and even OS X's Disk Utility can't fix it; I have to bust out the big guns: Disk Warrior. And even sometimes that has trouble. So, needless to say, I don't put anything irreplaceable on that partition.

So, I've decided to add journaling support to the Linux HFS+ driver. I don't expect this to be remotely easy. The first step, which I have somewhat completed, is just to allow the driver to replay the journal if there's data in it on mount (i.e., if a crash under OS X left the filesystem in an inconsistent state). I've been running into a bunch of annoyances, many of which just stem from the fact that I've never done any kernel hacking before. It took forever just to figure out how to write to the disk. Figuring out how to read wasn't easy either. I thought that after I'd found the sb_bread() function, that would be it. But, of course, it's all a matter of units. sb_bread() seems to read in blocks of 4096 bytes (which might be device-dependent; it just happens to be 4096 for me). In the HFS+ volume header, the journal location is specified in filesystem blocks (512 bytes), which took me forever to realise. Then most other offsets are in bytes. To make matters worse, some of Apple's documentation doesn't quite make sense.

Writing was another matter. sb_bread() returns a "buffer head" structure, which contains all the data in that block from the disk. (That's another thing: you can't read a certain amount of bytes from the disk, from what I can tell. Each time you read, you get a block, no more, no less.) For writing, you have to read out the correct block, copy the new data to the correct point in that block's buffer, then call mark_buffer_dirty() on it. If you want to write it immediately (I think/hope), you then call sync_dirty_buffer() on it as well.

Anyway, I think I have most of that sorted out; I just need to figure out some things I'm doing wrong regarding interpreting the spec and where portions of the journal are, and it should be ok.

Then comes the hard part, which as far as I can tell isn't documented anywhere: actually implement the journaling support in the driver so as you write to the disk during normal daily activities, metadata gets journaled, then data is written, and then the metadata is flushed to disk (or whatever). I really have no idea how this even works, let alone the details of implementing it. If anyone has any info on this, please feel free to drop me a note...

Auke was ruminating on how the GPL relates to a source distro (specifically, the one he runs, Lunar Linux). It raises some interesting questions. Is Lunar, as an entity, distributing binaries? Not in the literal sense: they just distribute sources, and some amount of patches, as well as a generic automated build system. All binaries are built on the user's target machine (well, with the exception of the install CD, which I'll get to in a minute). But does that "count" as anything more than source distribution? I would say no, but then, consider this (contrived) scenario (applicable to most source distros, not just Lunar):

Lunar user uses the Lunar package manager to install a piece of software named Foo. Say that when he does this, it's version 1.0. Due to some quirks, the Lunar package manager has to patch the sources to get it to build properly (or perhaps to fix some icky bug, or whatever). So Lunar user happily uses Foo for a while, and decides he wants to give it to some friends. However, when he tries to find the sources to his binary (note that he's required by the GPL to offer source in addition to the binary), he finds that Lunar has upgraded their version of Foo to 1.5, which is (for some reason) very different from 1.0.

So, where does he get the sources? And the patches applied by Lunar? What if the sources were modified by 'sed' scripts inlined into the build instructions, which are no longer available. Now, I suppose he could dig through Lunar's Subversion repository, but is that kosher with the GPL?

I suppose it's all moot, though: the GPL says that if you distribute binaries, you must make an offer to have the source available for three years. But what if you only distribute source? Does that change if you distribute source, plus patches? Do you have any future obligations at all?

Anyway, Auke also mentions this:

We only distribute binaries in lunar-linux through the ISO images (the installer cd). All the binaries on that image are created using the unmodified sources from the original websites. For the few packages that have patches, we use the patches from our own patch website URL. That's according to the letter of the GPL and actually the only thing we're required to provide.

I suggest you take a look at this FAQ entry. As an extension to that, regarding distributing only diffs from the original version with the binaries, see this one. So in other words, if you distribute binaries, you must also make available the full source used to create those binaries. The fact that it's (currently) on the original author's website is not enough.

And we wonder why most software development companies are so afraid of the GPL that they refuse to touch software "tainted" with it. Most of the people in our own community (including myself, on occasion) don't even understand the license fully.

I have looked around the patch for gnome-terminal from Kristian HÃ¸gsberg and also the one for Terminal from Benny, and I managed to do the same for Terminal again since the vte libs have been modified, and support for real-transparency has been added. It was really simple, just init the rgba colormap, and call vte_terminal_set_opacity :) It requires version 0.13.3 or higher of vte.

Now someone could come with a good solution to integrate this nicely in Terminal. I think about a hidden option in ~/.config/Terminal/terminalrc, or even a slider.

Here is a first patch. It sets a hard-coded color for the alpha channel (0xDDDD).

Edit: And here comes a second patch which adds a hidden option for the opacity (ColorOpacity). It has to be in decimal, where 0xCCCC is 52428. Don't apply it over the first patch.

Edit 2: Benny commited changes to the trunk with support for real transparency, and a check for the version of libvte.