The CBC recently posted an article titled Queen's University investigates 'shockingly racist' student costume party wherein the university's Alma Mater Society described party-goers costumes as "inappropriate" and were decried by Toronto comedian Celeste Yim as "shockingly racist." This article brings to mind another decade-old costume related news bite prompted by Prince Harry's choice to wear a swastika armband to a friend's fancy dress party. It's generally accepted that the prince's costume was actually offensive and inappropriate but are the costumes worn, presumably by Queen's students, truly "shockingly racist?"
This was recorded sometime after December 2015 using nothing more than my cell phone and a less crappy audio recording app that isn't as prone to cutting out. I have many fond memories of listening to this song being played while having one too many beers in the Irish pubs found in Kingston, Ontario.
With apologies to Great Big Sea.
My wife and I use a couple of desktops at home for most of our computing needs. Most of our user files (e.g.,
/usr/home) are stored on a separate server, shared over NFS and amounted via autofs. Said server also provides an NFS export that we use for our shared documents - stuff that we both need read-write access to. For the sake of simplicity I take advantage of the
-mapall parameter in the exports file on the server. This nifty little option ensures that whomever has access to mount the NFS export read-write will read, write and delete files as a single user on the server. This effectively solves the problem of setting up more complicated permissions for file sharing between a small group of people. The
/etc/exports file looks like this:
/usr/home -alldirs client1 client2 /srv/fileshare -mapall=fileshare client1 client2
The problem with this setup rears its ugly head when you're interacting with the NFS mounts on the client through Thunar, the default file manager for XFCE (I've come to appreciate a lot of what XFCE brings to the table over the past 6 or 7 years since we escaped the insanity that is Gnome3). Thunar uses some glib magic for interacting with the file system, and when a user hits the "Delete" key or picks to "Move to Trash" from the context menu, a poorly-documented gvfs binary named
gvfs-trash is invoked and in both cases it is supposed to move the offending file to the user's waste bin. On the NFS mount this function failed with the following unhelpful message:
Error trashing file: Unable to find or create trash directory.
After digging around with truss to figure out what the heck
gvfs-trash was actually doing and scouring the FreeDesktop.org Trash specification, I discovered that
gvfs-trash is supposed to look for a directory named
.Trash in the root of the NFS mount and that this directory must have the sticky bit set.
Okay. Makes sense. I guess.
# mkdir /srv/fileshare/.Trash # chmod 1777 /srv/fileshare/.Trash
At first glance this seems to work fine. Running
gvfs-trash FILE-TO-TRASH now executes without error and gvfs (and in turn glib) goes ahead and creates
/srv/fileshare/.Trash/1001, puts a couple of sub-directories under the one named after my effective UID, moves the offending file and Bob's your uncle. Because we're using the
-mapall option, everything is created using the user we specified on the server in the exports file (in this case the user name is
Unfortunately the problem also occurs the second time
gvfs-trash is run to trash a file. It fails again with the same damned error message. Okay, thanks gvfs.
It turns out that not only must
.Trash exist with the sticky bit, but the UID directory immediately below must be owned by the user who is trashing the file, never mind that this didn't matter when we were trashing the first file. To "fix" this problem I ran the following commands:
# chown matt:matt /srv/fileshare/.Trash/1001 # chmod 1777 /srv/fileshare/.Trash/1001
Since I have a limited number of user accounts this ungainly fix appears to work, at least for the short-term.
I think the moral of the story here is that when you are implementing anything that tries to be halfway "smart" about what it is doing (in this case,
gvfs-trash and the ungodly mess of glib below it), you need to be VERY careful that your process a) provides a more helpful error message when it fails, and b) doesn't work in weird and unexpected ways (in this case, working the first time but failing the second time). Generally speaking, your users shouldn't have to run system-level debugging tools and refer to the spec when easily returned and friendly error messages would otherwise save them a lot of time.
This is one of the first songs that I recorded that I felt comfortable with sharing. It was recorded sometime in 2001 or 2002 in my off-time at the offices of Scouts Canada where I was working. I used a very simple WAV editor that came with the computers we had in the office and may have included 3 or 4 tracks with each one layered on top of the previous recording. One of my friends says it reminds him of Danger Bay but I couldn't begin to tell you where the inspiration came from.
It is admittedly a little "busy" in places but for some reason it still appeals to me.
Watching Occupy Wall Street unfold in 2011 and before that, Arab Spring I began empathize with movements that involved active protest and the risks that participants take both in regards to physical harm or in other less tangible costs. "Firing Line" was somehow the result of my ruminations.
The rudimentary recording apparatus I was using left me sounding a little stuffy (I did not have a cold) but I kept it due to the fact that it is one of my few complete songs.