Jon Dowland: My new record player unit
![[pic]](http://jmtd.net/log/./expedit/image1.jpg)
On 21st October 2004, Robert Smith of the Cure sat in for John Peel whilst he
was on holiday and presented his show. This was part of a sequence of people
covering for Peel. Off the top of my head Siouxie of the Banshees sat in
on another night, but I forget who else.
Anyway, sadly, John died a few days later on the 25th.
Before John's death, in response to his pre-recorded show being butchered by
the BBC, Smith posted an angry message on the Cure's website, which included
the tracklisting as he had originally prepared. After John's death was
announced, Smith deleted the post from his site, no doubt out of respect for
Peel and to avoid any mis-interpretation.
I recorded the show onto minidisc when it was broadcast and discovered a lot of
music that I loved and hadn't heard of before. I've just stumbled across a
copy of Smith's post, including the tracklist, so for historical interest's
sake, here it is (with only light typographical editing).
If anyone cares enough, I could have a look for that minidisc
Image by Cayusa via Flickr
#!/bin/sh # # Rygel daemon handling RYGEL='/usr/bin/rygel' RYGEL_ARGS='' su -s /bin/sh -c "nohup $RYGEL $RYGEL_ARGS > /var/local/rygel/rygel.log 2>&1 &" rygel EXIT_CODE=$? if [ $EXIT_CODE != 0 ] ; then return $EXIT_CODE fi PGROUP= ps --no-headers -o pgrp $$ PID= pgrep -g $PGROUP -f $RYGEL echo $PID > /var/run/rygel.pid exit 0
I have a laptop used for playing music (and occasionally also videos) which is currently running Windows XP with XBMC. Reinstalling this beast to Linux is on my todo list for ages and now I've finally found time to try that.
Starting Debian installer worked like charm and in few minutes I got Debian system running. I've chosen to run sid, well for reason I run it usually on place where I want latest software. Installing XBMC from Debian multimedia worked also fine and you can easily find some howtos for directly starting XBMC.
And that's where I ran into trouble - XBMC is damn slow. Notebook has oldish nVidia GeForce FX Go5200 card, which seems to be poorly supported by nouveau (and "Do not file bug reports about this driver." suggest that this is what authors do expect). Okay, I can survive having some binary crap so let's try nVidia proprietary drivers. I've quickly realized that the legacy drivers won't work with recent xserver and probably also not with the kernel.
Maybe I should try installing something older, what would run binary drivers, but for now I gave up and system is back on Windows (with all problems I have there...).
Filed under: Debian English Linux 7 comments Flattr this!
I had a bit of an adventure yesterday, which would have taken some
explaining if the police had gotten involved. It went a little something
like this...
My friend and former co-worker Sara was in the US Virgin Islands for the
holidays. Her boyfriend, Karl, flew there separately for the tail end of her
time there.
Yesterday, I received a phone call from Sara, saying that Karl had managed
to fly out to the Virgin Islands without his passport. Apparently you can
get there without one, but to get back into the mainland US, you need one.
She wanted to know if I could get one of my lock-picking co-workers to break
into their apartment and retrieve Karl's passport and mail it them. Karl was
supposed to fly out the next day. Attempts by Sara to contact her landlord
had failed, so they didn't have many other options (apart from mailing me a
key, which would have cost them another day).
I asked one of my co-workers, Jason, who I knew was into lock picking, if he
was up for it, and he offered to put me in touch with another guy who had
dominated the recent lock picking night that he'd run.
So now I'm talking to David, who's on board with the mission, but doesn't
have his lock picking gear on him. No problem, Jason says he'll lend me his,
which was at work with him. So we have a plan.
Our friends Ian and Melinda are currently in Australia. They've lent us
their car because it's leased, and they have some minimum mileage they're
supposed to do and they're under it, so I've been driving to work in their
car some days. As it happens, I drove to work in it yesterday.
So now David and I set out in a car that neither of us own, with a lock
picking set that belongs to another person, to break into an apartment of
someone who's in the Virgin Islands. What could possibly go wrong?
I'm told that it's not illegal to own a lock picking set, but if you're
caught with one on your person and you're not a locksmith, you can get into
all sorts of trouble. On top of that I'd have a hard time explaining the car
I'm driving.
We get to Sara and Karl's condo complex. It has a common gate that visitors
would normal get buzzed through. Turns out it's not that hard to climb over.
It's got some benign-looking spiky things on top, but I could get a leg
over from the left hand side of the gate and jump over without impaling
myself. Then I let David in and we proceeded upstairs to Sara and Karl's
apartment door, where David set to work.
Sara said that just the dead bolt was locked. David started at it with
Jason's tools, trying to be as discreet as possible. It was about 3:30pm and
there was no one around, but we could hear some noises from the neighbouring
apartment (the two front doors were right next to each other).
After what felt like about half an hour without success (the last pin of the
lock was particularly tricky apparently) David was having to resort to more
noisy techniques with the lock, so I decided to take the up-front approach
and just inform the next door neighbour what we were doing in case he/she (I
think it was a she) decided to call the cops on us. I told her through the
door why we were there and what we were doing. She didn't seem to care too
much.
David then proceeded to start "raking" the lock, essentially brute forcing
the pins with a lot of jiggling, and finally managed to pick it and we were
in. I quickly found Karl's passport where it was suspected to be, and then
we pondered how we were going to lock the door again.
We could have just locked the door knob instead of the deadbolt and closed
the door behind us, but we weren't sure if Sara and Karl had a key to the
doorknob (Sara said they always just locked the deadbolt). Sara was fine
with leaving the door unlocked until they got home, but weren't so keen on
leaving our fingerprints all over the place and then leaving the door
unlocked.
David tried to re-pick the deadbolt so that he could lock it via the same
means as opened it, and I scouted around for a key. I managed to find a key
that locked both the deadbolt and the doorknob, so I took that with us and
locked up their apartment. In David's defense, the deadbolt was a bit stiff
to lock even with the key.
I dropped David back at work, collected my stuff (it was now about 4:30pm)
and headed to the UPS Store to ship Karl's passport to him as fast as
humanly possible. I just made the 5pm pick up.
Today I received an SMS from Sara informing me that they had received the
passport. I was very impressed with how fast it got to them.
So that was all a bit of an adventure. I'm not sure how much longer Karl is
going to have to stay in the Virgin Islands as a result. I'm going to
suggest that Sara and Karl leave a spare key with someone in future.
After dist-upgrading my main Hetzner server from Lenny to Squeeze,
Apache failed to come up, barfing the following error message in the
alphabetically last defined and enabled virtual host s error log:
[error] Illegal attempt to re-initialise SSL for server (theoretically shouldn't happen!)Well this is not theory but the real world and it did happen and it took me a while to find out what was wrong with the configuration despite it worked with Lenny s Apache version. To avoid that others have to search as long as I had to, here s the solution: Look at all enabled sites, pick out those which have a VirtualHost on port 443 defined and verify that all these VirtualHost containers do have their own SSLEngine On statement. If at least one is missing, you ll run into the above mentioned error message. And it won t necessarily show up in the error log of those VirtualHosts which are missing the statement but only in the last VirtualHost (or the last VirtualHost on port 443). To find the relevant site files, I used the following one-liner:
grep -lE 'VirtualHost.*443' sites-enabled/*[^~] \ xargs grep -ci "SSLEngine On" \ grep :0Should work for all sites which have defined just one VirtualHost on port 443 per file. I suspect that the raise of SNI made Apache s SSL implementation more picky with regards to VirtualHosts. Oh, and kudos to this comment to an article on Debian-Administration.org because it finally pointed me in the right direction. :-)
Since I am currently working on a Windows machine at work I am looking for ways to make this thing work in a sane way. The latest insane thing is the fact that I wasn't able to log on a CVS server at work from WinCVS (which uses CVSNT) with my regular credentials, while the cached password in Cygwin did work with the Cygwin CVS./1 :pserver:username@our.cvs.server.net:/u S()meh4s'h00
Current status
Back in September,
I wrote
about the machines that I set up to help bootstrap the new armhf
port in Debian. Basing on Konstantinos' huge efforts in bringing up
the new "architecture" in debian-ports, we started importing armhf
into the main Debian archive on the 24th of November. Since then,
those builders have been churning away night and day to build the
huge collection of software that makes up the Debian archive. The
current state can be seen on
the armhf
buildd status page, and there's a nice graph showing how quickly
we've managed to run from 0 to over 90% of the archive here. (Click
on the image for a larger version, or visit
https://buildd.debian.org/stats/
for other versions. We overtook hurd-i386 quickly and are now ahead
of the kfreebsd-* architectures.
We've recently brought 3 more similar build machines online
(hildegard, howells
and hummel), again sponsored by the nice folks
at Linaro but now hosted at
the York NeuroImaging Centre
at the University of York. This gives us both more build
horsepower to keep up with building more different bits of Debian
(experimental, updates etc.) and more redundancy in case of
problems.
We now have the vast majority of the archive built, and now a
number of us are concentrating on fixing the remaining issues:
language bootstraps and bugs. Also, on the 7th of January we were
just added into testing, the next step on our path for inclusion as
a Debian release architecture.
Setting up the machines
A lot of people have been asking me about the physical setup I
showed in my last blog about these machines, so here's more details
for those who are interested.
exec(), you fork() a process in the background that will wait for the current process id to disappear from the process list, and then does whatever you want to do.
A simple proof-of-concept I wrote is composed of two bash programs: wrapper and real.
real is really simple: it just waits a few seconds and then prints its process id to the console:
#!/bin/bash
sleep 5
echo $BASHPID
wrapper is the program that handles the situation we want to exercise: it replaces itself with real, but still has the chance to do something after real finishes. In this case, wrapper notifies the user that real finished.
#!/bin/bash
echo $BASHPID
real_program_pid=$BASHPID
(
while ps -p "$real_program_pid" >/dev/null; do
sleep 0.1s
done
notify-send 'real program finished'
) &
exec ./real
wrapper explores is that when exec() starts real, it really replaces wrapper, and therefore has the same process id (in this case accessible by bash in the $BASHPID variable). Because of this, the background process that wrapper starts just before the exec() call already knows which process it has to watch for.
The actual code for waiting is not optimal, though. I cannot use waitpid() (the wait builtin in bash), since real is not a child process of wrapper. I went with a brute force approach here, and I am pretty sure there is a cheaper way to wait for a random PID without a busy loop (but that wasn t the point here).
1
update: I am aware of the classic fork()/exec() pattern. My Very Good Reasons include the fact that I can t control the flow: I am writing a plugin for a program that calls its plugins in sequence, and after that, calls exec(), but my plugin is interested in doing some work after exec() finishes.
Tonight I'm staying at the free camping area behind the General
Patton Museum at Chiriaco Summit. Not a lot has
changed since the last time I stayed here. There is one other RV here
as well. The picture is taken from the tank garden, with my RV in the
free camping area behind.
Makers is a SF novel set in the fairly near future. It is available
in ebook form free from the author's web
site or if you prefer you can
buy the paper edition from a bookstore. I found the first portion one
of the most believable near-future with a significant change I have
read. (The boogie-woogie Elmo dolls that run Linux and didn't sell
were a cute touch.) While the technology involved might seem the same
as the typical techno-babble seen in mass-market SF to someone not in
the computer industry, it is actually plausible and the details are
correct. The later parts of the novel are less believable, but still
internally consistent. Overall, I found this a good but not great
read.
new year, old hobby: trying to fix an RC bug per day, & reporting about
it. here's the first episode of 2012:
I ve just uploaded new version of sshfs package.
Here goes changelog:
sshfs-fuse (2.3-1) unstable; urgency=low
* New upstream version. (Closes: #636357)
$ aptitude show dpkg Package: dpkg [...] Version: 1.16.1.2 [...] Breaks: apt (< 0.7.7), aptitude (< 0.4.7-1), dpkg-dev (< 1.15.8), libdpkg-perl (< 1.15.8), pinfo (< 0.6.9-3.1), tkinfo (< 2.8-3.1)it occurred to me that most (all?) of these relations were irrelevant to Britney when she migrated dpkg 1.16.1.2 to testing. Right now, at least the APT relations are only relevant if you are doing something like a distribution upgrade from Lenny/Squeeze to Wheezy. Similarly, the version constraints in a lot of dependency relations (e.g. libc6 (>= 2.11) ) are satisfied in testing and unstable at the same time. Removing the version constrains on dependencies is a rather minor thing as it is basically just a minor constant time optimization on each dependency check. However, removing an entire clause slightly reduces the problem size a bit. Particularly, the Conflicts/Breaks relations tends to be expensive for us. The first task was to identify the relations that can (or cannot) be simplified. In a Britney run we at most 4 versions of the same package per architecture, though usually only 1 or 2[1]. I devised a small set of rules to simplify the relations. These rules are applied to each package in the relation (atomic proposition, if you will).
[0] There is perfectly valid reason for doing that.
I might get back to that in a later post.
[1] One in unstable, testing, testing-proposed-updates and proposed-updates. The latter may seem a bit weird, but [0]
[2] This is the rule that prune relations like the one in the dpkg Breaks-field.
Edit: 2011-01/09, clarified that we have at most 4 versions per architecture.
Next.