22 January 2019

Scott Redding talks about the 2018 Aprilia MotoGP team.

It's been a long while since I've come across something that I felt needed to be preserved but this is it.
And it hits a little close to home.
Not from my experiences with my MotoGP team, obviously, not even is it related to my own motorcycle racing.
But I know that kind of frustration. The frustration of knowing you can pull something off if only circumstances were slightly different. The frustration of having all your achievements flushed away because you're part of a team and that team is fucking things up and people aren't acknowledging that. Shit like this wouldn't be necessary if we would all be willing to put the same effort into being accountable for stupid shit we do as covering our own asses. The world caters to mediocrity.
It takes shitloads of courage to burn bridges like this and I applaud him for it.

Scott Redding is highly critical of Aprilia after a dismal showing in Austria, says, “you cannot make a piece of shit, shine. And that's what I'm trying to do.”
After finishing a lowly 20th in Sunday’s MotoGP outing in Austria, Scott Redding has provided an astonishingly frank take on a dismal showing, describing Sunday’s race as “heartbreaking” and saying the weekend was “hell from the beginning.”
The Englishman was highly critical of Aprilia, listing a number of mechanical issues he encountered throughout free practice, qualifying and on race day. “In a team of this level it should not be happening,” he said on Sunday afternoon. “And it is happening.” 
Having placed a competitive second in a soaking wet FP2 session, Redding said the showing came as a timely reminder of his talents, and only served to highlight the RS-GP’s deficiencies in the dry. “You cannot make a piece of shit, shine,” was the takeaway line from an impassioned debrief. “And that's what I'm trying to do.” 
Redding was not only unable to explain why he finished well outside the points. The reason he took the chequered flag 21 seconds back of team-mate Aleix Espargaro, when he had provided the Catalan with competition in recent outings, was also something of a mystery. 
“The [wet] conditions bring the machines closer,” said Redding. “I can see my potential. I can be fast. And it just reminded me of how good I can actually be. I just accepted it this year, I've never had a wet session. But then this weekend was like, 'yeah, well you can mix with the best guys in the world when the level comes a bit lower with the machinery'. Then it dries again and you're out in the field again. 
“It's been hard. It's been a hard weekend and to be honest to have a race like that is heart-breaking because I try all the time and it doesn't get easier. Why can I go to Assen and battle with my team-mate, in Brno I can battle with my team-mate - yes I crashed - then I come here and I can't even fucking be in the same situation. 
“Every time I go on the bike, every fucking day is different. There's always a problem with something. Every weekend there is a problem. And I've tried to accept it and I've tried to just deal with it, but honestly it's a bit of disaster at the moment. And I'm not happy. This weekend was a reality check for me. Riding around there, it hurts. 
“So now I have to go to Silverstone, the next race. I need to smile in front of everyone and say I'm going to do a good performance and it's all bullshit. Because you can't do anything. You cannot make a piece of shit, shine. And that's what I'm trying to do. 
“I know it sounds harsh and I shouldn't say it, but that's what it is. You're trying to make something average be better. I just hope when we go testing next week at Misano, that we can find something, we have a new engine… what is it going to bring? 
“It's something that I've asked for five races ago, if not more. I hope that it's better. I do hope. But if it continues like this I don’t know what mindset I'm going to be in because this is not what I go racing for. I don't do it.” 
It didn’t end there. Asked whether these repeated mechanical issues had been ongoing for some time, and he went again, describing the current situation as “a bit of a joke."
“The guys are trying but it's just a bit of a joke. There are so many things that I'm just not even allowed to say, not against me, but in a team of this level should not be happening. And it's happening. And I accept it. 
“But I come here. I can be fast here and I've made good results in the past, I like the track, it suits my style. I thought I'd come here and have a good chance of making a good enough result for us. And it was hell from the beginning. 
“And then we find out yesterday night there was a problem with the sensor, this and this and this. The suspension is reading different to what it's doing. Fucking hell. This is MotoGP, a full factory team. Why is this happening? 
“I've had problems with the electronics all the weekend, cannot get it to work. So what hope do I have to make a result here? I can't. And that's the thing that is making it hard at the moment.” 
Not even the possibility of testing at Misano next weekend offered up optimism. Aprilia’s management of the supposed shakedown was also “a fucking joke,” in the 25-year old’s eyes, as the factory had originally intended to spend three days on the Adriatic coast. Now he and Espargaro are only booked in for one. 
”To be honest even that's a fucking joke. We were supposed to do three days. Then it was two days. Then something was not organised enough and now we have one day. Things like that you know. We need that test time, we need those things. But it's a joke. 
“So the important thing, we have the engine, OK. Something big to try. We have one day, we can focus on that and I hope that it brings something. That's all I do. Just hope.”
Does he feel clear-the-air talks with Aprilia management and technicians could be of benefit before the all-important home race at Silverstone in two week’s time? 
“I've tried,” he said. “I've tried already from round one. And I was in a bad place earlier this year and I said to everyone that I'm not happy, I need to move on forget it and let it be. And I was doing that, but then when you realise how good you can be and you can't do it again and it's holding you back and it's holding you back. That's what's so frustrating. 
“I had the same in qualifying yesterday. Go in FP4 with the medium, I go in the qualifying with the soft and I go slower. And I have problems that I haven't had all weekend. I go in the race and I have problems again I haven't had all weekend. Why? Is the bike that bad that it changed from three degrees. I don't know. But you can never find the rhythm. 
“I'm honestly better off doing FP1, warm-up and the race. The rest of it just forget it and I would do the same result. Because it doesn’t matter what you do.
“I had a problem with the suspension so it was too soft. 'Cannot stop the bike, cannot stop the bike', it was all I complained about. Oh yeah, it was the problem. Okay, we change the fork spring. Okay, I can stop, and the lap time is the same. Because you run into another problem. 
“Because all you are doing is covering. You're not fixing something and moving on. I had not a tyre problem, got to Sachsenring and now tyre wear is really high. Where did that come from? OK, at the Sachsenring we can expect it. Brno we struggled, here we struggled. Seven laps… it's frustrating because you want to do it, you work to do it and you can't do it.”
-Neil Morrison, crash.net, 12 Aug 2018 (link to the original article

06 November 2018

Wurmd move from Google code to Github

Just in case anyone besides me would actually be using it: I've moved wurmd from Google Code, which has been deprecated for quite some time, to Github. https://github.com/timdingo/wurmd.

13 April 2016

On ecryptfs and ssh public key authentication.

I'm using an Ubuntu (not by choice, mind you) box to compile stuff on, which I've set up with ecryptfs to encrypt my user's home directory.
It's a headless box so most of the stuff I do on it is over SSH and I've been really annoyed to learn ecryptfs, by default,  auto-unmounts the user's home directly every time the SSH session disconnects.
Why, you ask? Because it breaks public key authentication aka 'passwordless login'.
Turns out ecryptfs, by default, needs the user's login password to decrypt the volume, which it then mounts so all is good as long as one's using a password based login procedure.
Anyways: a reasonable workaround (as there's no fixing this design issue), as long as the box doesn't shutdown too often, that is, is to not allow the volume to unmount every time the working session is closed:

  • Supply the password once over SSH, which auto-mounts the volume
  • Remove the ~/.ecryptfs/auto-umount file
  • Done

07 May 2015

On Debian's init process

Are you tired of badly written, complex, buggy and generally shitty init systems on Debian based systems?
Do you wonder what certain Debian developers have been smoking lately?
Do you think upstart, systemd and the likes need to stay the fuck away from your otherwise pretty stable Debian systems and do you long for the simpler SysV days?
Yeh, me too.

apt-get install sysvinit systemd-
or

apt-get install sysvinit upstart-

takes care of it.
That's all.

20 May 2014

Bancontact mobile application with a Belgian Keytrade account

It took some time to get it working; if the 'activation' step in the mobile application keeps failing, do this:
Log into the Keytrade web site and go to 'Cards' -> 'Card Security' -> 'Activate Card for Online Payments'.
That's it.

Screenshot because it's fancy:


19 March 2014

Unsetting a trap

Quick one: catching a trap in bash is fairly easy with bash' trap command (search for 'trap \[' in bash' man page) but how to clear a set one?
It's in the man page, of course, but who reads those, right? I'm betting the answer is bound to be found on some blog through Google in 0.76 seconds flat ;)
"If arg is absent (and there is a single sigspec) or -, each specified signal is reset to its original disposition (the value it had upon entrance to the shell)."
So it turns out it's fairly simple and this demonstrates it:
root@mgmtsrv:~# cat test.sh
#!/bin/bash
trap 'echo TRAPPED!; break' SIGINT
while [ True ]; do
        sleep 1
done
echo 'end of script'
exit 0
root@mgmtsrv:~# ./test.sh
^CTRAPPED!
end of script
root@mgmtsrv:~#
Now, let's unset the trap:

root@mgmtsrv:~# cat test.sh
#!/bin/bash
trap 'echo TRAPPED!; break' SIGINT
while [ True ]; do
        sleep 1
done
trap - SIGINT
while [ True ]; do
        sleep 1
done
echo 'end of script'
exit 0
root@mgmtsrv:~# ./test.sh
^CTRAPPED!
^C
root@mgmtsrv:~#
So, in short: the 'trap - SIGINT' line clears the set trap :)

05 February 2014

On loopback device creation

I was having some problems with loop back device creating & almost immediately detaching; it seems sometimes a kernel thread holds on to the device and the detach fails.
I decided to have a look what's going on so I created a script which automates the creation, attaching and detaching of loopback devices:


# ./test.sh

Creating sparse 4TB file: Done
----START----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
----NEXT PASS----
Loopback devices currently in use:
/dev/loop0
Checking for free loopback device: /dev/loop1
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
----NEXT PASS----
Loopback devices currently in use:
/dev/loop0
/dev/loop1
Checking for free loopback device: /dev/loop2
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
----NEXT PASS----
Loopback devices currently in use:
/dev/loop0
/dev/loop1
/dev/loop2
Checking for free loopback device: /dev/loop3
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
----NEXT PASS----
Loopback devices currently in use:
/dev/loop0
/dev/loop1
/dev/loop2
/dev/loop3
Checking for free loopback device: /dev/loop4
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
----NEXT PASS----
Loopback devices currently in use:
/dev/loop0
/dev/loop1
/dev/loop2
/dev/loop3
/dev/loop4
Checking for free loopback device: /dev/loop5
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
----NEXT PASS----
Loopback devices currently in use:
/dev/loop0
/dev/loop1
/dev/loop2
/dev/loop3
/dev/loop4
/dev/loop5
Checking for free loopback device: /dev/loop6
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
----NEXT PASS----
Loopback devices currently in use:
/dev/loop0
/dev/loop1
/dev/loop2
/dev/loop3
/dev/loop4
/dev/loop5
/dev/loop6
Checking for free loopback device: /dev/loop7
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
----NEXT PASS----
Loopback devices currently in use:
/dev/loop0
/dev/loop1
/dev/loop2
/dev/loop3
/dev/loop4
/dev/loop5
/dev/loop6
/dev/loop7
Checking for free loopback device: losetup: could not find any free loop device
Exiting, couldn't find any free device any more.
So if done fast enough the pool quickly gets depleted as giving back (detaching) the device fails. A second or so later it might work, though. But let's test how much time exactly is needed to free the device? I modified the script to keep trying to detach/free the loopback device and see what happens:

Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
Loopback device broken down after 4 tries.
----NEXT PASS----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
Loopback device broken down after 2 tries.
----NEXT PASS----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
Loopback device broken down after 6 tries.
----NEXT PASS----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
loop: can't delete device /dev/loop0: Device or resource busy
Loopback device broken down after 1 tries.
----NEXT PASS----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
Loopback device broken down after 3 tries.
----NEXT PASS----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
Loopback device broken down after 3 tries.
----NEXT PASS----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0 seconds.

Breaking down loopback device:
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
Loopback device broken down after 2 tries.
----NEXT PASS----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
Loopback device broken down after 3 tries.
----NEXT PASS----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
Loopback device broken down after 2 tries.
----NEXT PASS----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
Loopback device broken down after 4 tries.
----NEXT PASS----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
Loopback device broken down after 4 tries.
----NEXT PASS----
Loopback devices currently in use:

Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
loop: can't delete device /dev/loop0: Device or resource busy
Loopback device broken down after 1 tries.
----NEXT PASS----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
Loopback device broken down after 5 tries.
----NEXT PASS----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
Loopback device broken down after 10 tries.
----NEXT PASS----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
Loopback device broken down after 2 tries.
----NEXT PASS----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
Loopback device broken down after 4 tries.
----NEXT PASS----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
Loopback device broken down after 4 tries.
----NEXT PASS----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
Loopback device broken down after 3 tries.
----NEXT PASS----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
Loopback device broken down after 0 tries.
----NEXT PASS----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
Loopback device broken down after 4 tries.
----NEXT PASS----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
Loopback device broken down after 3 tries.
----NEXT PASS----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
Loopback device broken down after 2 tries.
----NEXT PASS----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
Loopback device broken down after 0 tries.
----NEXT PASS----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
loop: can't delete device /dev/loop0: Device or resource busy
Loopback device broken down after 1 tries.
----NEXT PASS----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
Loopback device broken down after 3 tries.
----NEXT PASS----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
Loopback device broken down after 2 tries.
----NEXT PASS----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
loop: can't delete device /dev/loop0: Device or resource busy
Loopback device broken down after 1 tries.
----NEXT PASS----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
loop: can't delete device /dev/loop0: Device or resource busy
loop: can't delete device /dev/loop0: Device or resource busy
Loopback device broken down after 2 tries.
----NEXT PASS----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
loop: can't delete device /dev/loop0: Device or resource busy
Loopback device broken down after 1 tries.
----NEXT PASS----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
loop: can't delete device /dev/loop0: Device or resource busy
Loopback device broken down after 1 tries.
----NEXT PASS----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: ^C
So it varies. The device might get released instantaneously, but that doesn't happen too often, or it might take 10 consecutive tries. Let's see if allowing half a second's worth of pause in between creating and detaching fix the problem,

# ./test.sh
Creating sparse 4TB file: Done
----START----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0.5 seconds.
Breaking down loopback device:
Loopback device broken down after 0 tries.
----NEXT PASS----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0.5 seconds.
Breaking down loopback device:
Loopback device broken down after 0 tries.
----NEXT PASS----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0.5 seconds.
Breaking down loopback device:
Loopback device broken down after 0 tries.
----NEXT PASS----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0.5 seconds.
Breaking down loopback device:
Loopback device broken down after 0 tries.
----NEXT PASS----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0.5 seconds.

^C
It does, but what's holding on to the device exactly? I modified the script again to look up the did in the process table. This takes time of course, so the detaching phase took less tries to complete:

# ./test.sh
Creating sparse 4TB file: Done
----START----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
loop: can't delete device /dev/loop0: Device or resource busy
root     25417  0.0  0.0      0     0 ?        S<   13:25   0:00 [loop0]
Loopback device broken down after 1 tries.
----NEXT PASS----
Loopback devices currently in use:
Checking for free loopback device: /dev/loop0
Setting up loopback device: Done
Sleeping for 0 seconds.
Breaking down loopback device:
loop: can't delete device /dev/loop0: Device or resource busy
root     25437  0.0  0.0      0     0 ?        S<   13:25   0:00 [loop0]
Loopback device broken down after 1 tries.
----NEXT PASS----
Loopback devices currently in use:
^C
Right, so it's Linux that's holding on to it and I'm not sure if I like this behavior. I realize losetup can only request Linux to free up the device and it does cleanly report a 'Device or resource busy' but I don't understand why it just doesn't wait a bit until the resource is cleared from the kernel, or at least provides the option to the user to do so. I thought about pathing losetup but now I can't be bothered anymore, so I'm just putting it out there :)

18 December 2013

On bypassing mdadm's interactive mode

So I wanted mdadm to not go interactive, ever, but instead just bail out whenever something happens it doesn't understand; you'd think the developers would have thought of that, right? Turns out they haven't.
The 'fix' is easy enough though: pipe /bin/false through mdadm by default so it'll get a 'false' every time it would be looking for user input; effectively making it bail out whenever something's off:

alias mdadm="/bin/false | /sbin/mdadm"

04 December 2013

On quickly creating sparse and large files

I've been using dd(1) for as long as I can remember to create sparse files but for some reason I keep forgetting how to use dd's argument options so I set out to find something better... and found it: truncate(1):

From the man page: "Shrink or extend the size of each FILE to the specified size. A FILE argument that does not exist is created." -looking good:

root@debian64:~# time truncate -s 10T testfile

real0m0.003s
user0m0.000s
sys 0m0.004s

root@debian64:~# ls -l testfile
-rw-r--r-- 1 root root 10995116277760 Dec4 10:27 testfile

root@debian64:~# du -hs testfile
0 testfile

Awesome!
So then I set out to find me something to quickly allocate 'real' files:

fallocate(1):
"fallocate  is used to preallocate blocks to a file.  For filesystems which support the fallocate system call, this is done quickly by allocating blocks and marking them as uninitialized, requiring no IO to the data blocks.  This is much faster than creating a file by filling it with zeros."

And it truly is fast:


root@debian64:~# time fallocate -l 1G testfile

real    0m0.004s
user    0m0.000s
sys     0m0.000s

root@debian64:~# du -hs testfile
1.1G    testfile

root@debian64:~# ls -l testfile
-rw-r--r-- 1 root root 1073741824 Dec  4 10:34 testfile


01 October 2013

On OverlayFS and distilling patches (or: how to get OverlayFS)

So, I was looking at unionfs alternatives and I wanted to try overlayfs.
You'd think a project almost begging to be merged into mainline Linux would be interested in getting some traction amongst the "regular" Linux crowd and actually provide some patches making it relatively easy to try out the code until the time finally comes they're part of mainline, right?
Well, apparently you'd be wrong assuming that: getting a clean OverlayFS patch requires distilling a diff from a patched Linux source tree on git and that is left as an exercise to the user... or simply use Ubuntu's or SuSE's kernels (no...fucking...way) as those are already patched it seems.
Anyways, this is how to do it:

Branch overlayfs.v18 is intended to work with Linux 3.10.x:
https://git.kernel.org/cgit/linux/kernel/git/mszeredi/vfs.git/tree/Makefile?h=overlayfs.v18
Git clone the overlayfs.v18 branch:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git -b overlayfs.v18 overlayfs.v18
From the git log I got they merged Linux 3.10-rc7 so that's the branch we're going to diff to. Adding a new remote repo to the overlayfs.v18 local repo and fetching the v3.10-rc7 branch from it (git fetching won't actually change the local code!):
cd overlayfs.v18
git remote add v3.10-rc7 git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux
git fetch v3.10-rc7
Now all we have to do is the actual git diff:
git diff v3.10-rc7/master...HEAD > ../overlayfs-v18.patch
So let's try to patch our Linux 3.10.12 tree :
root@bob:/usr/src/linux# patch -p1 --dry-run < ../overlayfs-v18.patch 
patching file Documentation/filesystems/Locking
patching file Documentation/filesystems/overlayfs.txt
patching file Documentation/filesystems/vfs.txt
patching file MAINTAINERS
patching file fs/Kconfig
patching file fs/Makefile
patching file fs/ecryptfs/main.c
patching file fs/internal.h
patching file fs/namei.c
patching file fs/namespace.c
patching file fs/open.c
patching file fs/overlayfs/Kconfig
patching file fs/overlayfs/Makefile
patching file fs/overlayfs/copy_up.c
patching file fs/overlayfs/dir.c
patching file fs/overlayfs/inode.c
patching file fs/overlayfs/overlayfs.h
patching file fs/overlayfs/readdir.c
patching file fs/overlayfs/super.c
patching file fs/splice.c
Hunk #1 succeeded at 1313 (offset 1 line).
patching file include/linux/fs.h
patching file include/linux/mount.h
root@bob:/usr/src/linux#

Lookin' good, w00t!

31 July 2013

On Linux patches and diffs

So you're running your own customized Linux, and want to stay up-to-date a bit, right?

root@box:/usr/src/linux# patch -p1 --dry-run < ../patch-3.10.4
patching file Documentation/i2c/busses/i2c-piix4
Reversed (or previously applied) patch detected!  Assume -R? [n] ^C

So what's happening here is that 'patch-3.10.4' from kernel.org actually is a diff from 3.10 to 3.10.4, not from 3.10.3 to 3.10.4.
This'd be fine except that you've already applied patch-3.10.3 the day before yesterday and you don't want to keep track of which patches are already applied and stuff, you just want to see whether or not the new 3.10.4 patches apply without problems.
Plus you've got other patches applied as well so you really just want to have a patch with the changes form one minor release to the other, right?
So that's where interdiff comes into play:

interdiff patch-3.10.3 patch-3.10.4 > patch-3.10.3-to-3.10.4

Now we have a patch that only includes the changes from 3.10.3 to 3.10.4 and that can be applied directly and cleanly to our already patched-with-the-previous-version-and-other-stuff-as-well Linux tree.

On apache's mod_proxy

Another short one, a warning; a 'heads up' if you will.
Took me some time to figure out that Apache's mod_proxy actually requires the proxied service to be accessible when Apache itself starts.
It seems logical enough writing it down now, but when I was configuring mod_proxy to work with apt-cacher it sure wasn't clear looking at the log files.
So when you're playing around with mod_proxy and a random to-be-proxied service, make sure to reload/restart the service first (and verify everything working alright) and only then reload Apache to take the new mod_proxy settings into effect.

07 March 2013

Debugging a slow KDE session.

KDE (from the Kubuntu repo) and all QT applications were slow as hell after an update so I set out to investigate:

The most obvious one to start with was kopete (sloooooooooooooow), so I straced (strace -s 500 -f kopete) and it hung on this:


11574 recvmsg(6, 0x7fffb90ddde0, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable)
11574 sendmsg(6, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1\0\0\0\0\t\0\0\0o\0\0\0\1\1o\0\26\0\0\0/modules/networkstatus\0\0\6\1s\0\f\0\0\0org.kde.kded\0\0\0\0\2\1s\0\37\0\0\0org.kde.Solid.Networking.Client\0\3\1s\0\6\0\0\0status\0\0", 128}, {"", 0}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 128
11574 poll([{fd=6, events=POLLIN}], 1, 25000

It's hanging on handler 6, going up in the output I found what 6 is:

11368 socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC, 0) = 6
11368 connect(6, {sa_family=AF_FILE, path=@"/tmp/dbus-TNffZVatPK"}, 23) = 0
11368 fcntl(6, F_GETFL)                 = 0x2 (flags O_RDWR)
11368 fcntl(6, F_SETFL, O_RDWR|O_NONBLOCK) = 0
11368 geteuid()                         = 1000
11368 getsockname(6, {sa_family=AF_FILE, NULL}, [2]) = 0

Right, so kopete is slow because it's waiting to receive something sent through dbus to kded.
Let's try to use dbus to contact kopete manually:


timothy@xps:~$ time qdbus org.kde.kopete                                         Error: org.freedesktop.DBus.Error.NoReply
Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
real    0m25.018s
user    0m0.004s
sys     0m0.008s


It timed out, let's try it again:


timothy@xps:~$ time qdbus org.kde.kopete
/
/KDebug
/KIO
/KIO/Scheduler
/Kopete
/MainApplication
/ManagerIface_contact
/Statistics
/kopete
/kopete/MainWindow_1
/kopete/MainWindow_1/actions
/kopete/MainWindow_1/actions/settings_prefs
/kopete/MainWindow_1/actions/file_quit
/kopete/MainWindow_1/actions/settings_showmenubar
/kopete/MainWindow_1/actions/settings_showstatusbar
/kopete/MainWindow_1/actions/settings_keys
/kopete/MainWindow_1/actions/options_configure_toolbars
/kopete/MainWindow_1/actions/settings_notifications
/kopete/MainWindow_1/actions/AddGroup
/kopete/MainWindow_1/actions/contactSendMessage
/kopete/MainWindow_1/actions/contactStartChat
/kopete/MainWindow_1/actions/contactMove
/kopete/MainWindow_1/actions/contactCopy
/kopete/MainWindow_1/actions/makeMetaContact
/kopete/MainWindow_1/actions/contactRemove
/kopete/MainWindow_1/actions/contactSendEmail
/kopete/MainWindow_1/actions/contactSendFile
/kopete/MainWindow_1/actions/contactAddContact
/kopete/MainWindow_1/actions/contactAddTemporaryContact
/kopete/MainWindow_1/actions/contactProperties

real    0m3.720s
user    0m0.028s
sys     0m0.004s


So now it works. Consistent with what I'm experiencing in the KDE session right now.
Everything works, more or less, but it's all extremely slow.
Let's have a look at kded:


timothy@xps:~$ qdbus org.kde.kded
Error: org.freedesktop.DBus.Error.NoReply                                        Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.                         


I want to see what's kded's problem, let's look at it's status:


timothy@xps:~$ ps aux | grep kded
timothy  10298  0.0  0.3 793672 29280 ?        Sl   10:06   0:00 kdeinit4: kded4 [kdeinit]                     
timothy  10455  0.0  0.1 414756 11236 ?        Sl   10:06   0:00 kdeinit4: kio_trash [kdeinit] trash local:/tmp/ksocket-timothy/klauncherT10296.slave-socket local:/tmp/ksocket-timothy/kdeda10298.slave-socket
Sleeping eh, could be worse. Let's see what's it actually is doing/hanging on:
timothy@xps:~$ gdb kdeinit `pidof kded4`
[... lots of stuff...]
(gdb) bt
#0  0x00007f6aa1952023 in select () at ../sysdeps/unix/syscall-template.S:82
#1  0x00007f6aa2d99366 in qt_safe_select(int, fd_set*, fd_set*, fd_set*, timeval const*) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#2  0x00007f6aa2d466da in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#3  0x00007f6aa2d47fab in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#4  0x00007f6aa2d0248e in QProcess::waitForFinished(int) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#5  0x00007f6aa31def32 in KProcess::execute(int) () from /usr/lib/libkdecore.so.5
#6  0x00007f6a80f3f1a5 in ?? () from /usr/lib/kde4/kded_notificationhelper.so
#7  0x00007f6a80f3bca5 in ?? () from /usr/lib/kde4/kded_notificationhelper.so
#8  0x00007f6a80f39ad4 in ?? () from /usr/lib/kde4/kded_notificationhelper.so
#9  0x00007f6a80f39d24 in ?? () from /usr/lib/kde4/kded_notificationhelper.so
#10 0x00007f6aa2d86446 in QObject::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#11 0x00007f6aa20ef894 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#12 0x00007f6aa20f4713 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#13 0x00007f6aa3b063f6 in KApplication::notify(QObject*, QEvent*) () from /usr/lib/libkdeui.so.5
#14 0x00007f6aa2d6ce9c in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#15 0x00007f6aa2d70c6a in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#16 0x00007f6aa2d9bf93 in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#17 0x00007f6a9ea5fd53 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#18 0x00007f6a9ea600a0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#19 0x00007f6a9ea60164 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#20 0x00007f6aa2d9c3bf in QEventDispatcherGlib::processEvents(QFlags) ()
   from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#21 0x00007f6aa2197d5e in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#22 0x00007f6aa2d6bc82 in QEventLoop::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#23 0x00007f6aa2d6bed7 in QEventLoop::exec(QFlags) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#24 0x00007f6aa2d70f67 in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#25 0x00007f6a8f4fde55 in kdemain () from /usr/lib/kde4/libkdeinit/libkdeinit4_kded4.so
#26 0x00000000004086a4 in _start ()
So we're in the kded_notificationhelper.so module. Let's see what I've got on my system mathing that name:

timothy@xps:~$ dpkg -l | grep "notification-helper"
ii  kubuntu-notification-helper            11.10ubuntu1                            Kubuntu system notification helper

Seems fishy.

timothy@xps:~$ apt-cache show kubuntu-notification-helper
Package: kubuntu-notification-helper
Priority: optional
Section: kde
Installed-Size: 212
Maintainer: Kubuntu Developers
Original-Maintainer: Jonathan Thomas
Architecture: amd64
Version: 11.10ubuntu1
Depends: libc6 (>= 2.4), libkdecore5 (>= 4:4.4.95), libkdeui5 (>= 4:4.4.0), libqt4-dbus (>= 4:4.5.3), libqtcore4 (>= 4:4.7.0~beta1), libqtgui4 (>= 4:4.5.3), libstdc++6 (>= 4.1.1), konsole | x-terminal-emulator, qapt-batch
Recommends: apport-kde | apport-gtk
Filename: pool/main/k/kubuntu-notification-helper/kubuntu-notification-helper_11.10ubuntu1_amd64.deb
Size: 38114
MD5sum: 0c6b775a0f78cbdb138149ea0e32b60b
SHA1: 2f2c37f9d16a094ac6f215c22c6cb558f6e5eada
SHA256: 8a96a2b822e825d3d56d7dcba732061576b690077bd73ff5ddcfd896192399bf
Description-en: Kubuntu system notification helper
 Kubuntu Notification Helper is a daemon that presents various notifications
 to the user. It uses the KDE Daemon system as a base and presents the
 notifications using the KDE Notification system. It also includes a
 System Settings module for configuring the daemon. Kubuntu Notification
 Helper is lightweight and fully integrated with KDE.
 .
 Current features include:
  - Notifications for Apport crashes.
  - Notifications for upgrade information, when available.
- Notifications for the availability restrictively-licensed packages.
  - Notifications for when upgrades require a reboot to complete.
  - All notifications can be hidden temporarily or permanently.
Homepage: https://launchpad.net/kubuntu-notification-helper
Description-md5: cfe41fe07651879c49f8ca54be0c1170
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu
Supported: 5y
Task: kubuntu-desktop, kubuntu-full, kubuntu-active-desktop, kubuntu-active-full, kubuntu-active, edubuntu-desktop-kde

Ubuntu bloatware I can perfectly do without, check.

timothy@xps:~$ sudo apt-get remove --purge kubuntu-notification-helper
Reading package lists... Done
Building dependency tree     
Reading state information... Done
The following packages will be REMOVED:
  kubuntu-notification-helper*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 217 kB disk space will be freed.
Do you want to continue [Y/n]?
(Reading database ... 296995 files and directories currently installed.)
Removing kubuntu-notification-helper ...

After a KDM restart everything is back to normal AND that annoying pop up 'there's are X software updates' thing is gone...

23 January 2013

Fine Tuning an Original Floyd Rose

I'll start off by stating this is a guide for fine tuning a  Original Floyd Rose (OFR) bridge, not a generic double locking floating bridge (DLFB) tuning guide, although the ideas and concepts are alike for many Floyd Rose licensed DLFB's.
Floyd Rose is a brand name and an Original Floyd Rose is a type of bridge.
Your Ibanez branded DLFB isn't a Floyd Rose.
Ibanez' are called Edge and were once Licensed Floyd Rose, but not any more.
The original Edge DLFB was very similar to a OFR though.

This isn't a Floyd Rose set-up guide either, that's a bit out of scope at this time.

This is a guide to fine tune your OFR and by that I don't mean on how to use the bridge's fine tuners, I mean tuning it so it stays perfectly in tune no matter the abuse.
Not even Floyd Rose's guide on their website correctly lists a method of making sure the bridge stays in perfect tune at all times for some reason.
Most guides generally have 3 major steps:
1) Tune using the tuners
2) Lock the nut
3) Tune using the fine tuners
They don't speak about what the tuning should be when pulling up or down on the bridge which is, I think, the very essence of an OFR, right?
Should be bridge be in perfect tune after pulling up and letting it return to zero?
Should be bridge be in perfect tune after diving and letting it return to zero?
Well, yes, yes it should be.
The thing is, following most guides it can't be, you'll see why and what's your definition of 'perfect'?
Pefect tuning on an OFR equipped guitar is nearly impossible, I'll explain why later on.

Anyways, I recommend getting a polygraphic tuner.
We'll need to check the entire range of tuning for all strings once we'll get to the fine tuning bit, so getting a graphic representation of the current tuning is extremely handy.
I've got a Hardwire HT-6 polygraphic tuner and fwiw: I recommend it wholeheartedly.
A word of advice when using your polygraphic tuner when tuning though: don't press down on the strings to much when you're sweeping them all at once.
Pressing down too hard makes the other strings go out of tune obviously, so you won't get a correct overview of the tuning. Gently sweep them instead.

First things first:

New strings should be stretched before tuning!
This is so important it's not funny any more.
Neglect to do it and it won't stay in tune, I can guarantee you that much!
Put the new strings on and stretch the hell out of them by pulling up on the whammy bar as much as you can and then take the string with your fingers and stretch it even more.
The better you stretch, the more stable the end tuning result will be.

I see a lot of guides recommending unscrewing the fine tuners completely as a first step, this is wrong.
We'll need to be able to both fine tune up and down, so position them in the middle.
Here's how:

Screw the 6th string's fine tuner all the way in
Screw the 4th string's fine tuner all the way out
Screw the 5th string's fine tuner right in the middle
Screw all fine tuner's on the same level as the 5th string's fine tuner, using your finger as gauge.

Next, unlock the nut and remove the nut blocks and bolts for now, remembering which is which and in what position they were on.

If the OFR was at level, it probably won't be any more now, that's fine.
This happens as, after locking the nut, fine tuning increases string tension right up to the nut; the string's part behind the nut has a different tension.
Removing the nut changes the tension again so the bridge moves a bit.

Now, make sure the Floyd Rose's fine tuners are reset to their middle position.
Then, follow these steps:

A1) Pull the Floyd Rose up and carefully let it come back to it's zero position
A2) Tune to the desired tuning using the regular tuners on the headstock
A3) Pull the Floyd Rose up carefully let it come back to it's zero position
A4) Repeat step A2
(Procedure 'A')

Pulling up ensures there isn't any slack anywhere on the length of the string and it's a very important step on some set ups; don't skip it.
This of course means you can't push down on the bridge at this time!

Now it's time to check the OFR's tilt.
It should be completely at level with the body of the guitar and I don't mean give or take.
Ensure it's completely at level or you won't get it completely in tune in all situations later on.

Most probably it won't be level, so this is how you level it:
Note: you'll need to tune again (steps A1 through A4) after every single spring adjustment at this stage.
Remove the backplate leading to the OFR's springs in the back cavity of the guitar.
You'll see a claw plate holding 2 to 5 springs connected to a big block holding the bridge and the plate is connected to the guitar's body by 2 screws.
First ensure the claw plate should be at level with the body of the guitar!
(So, remember: if you've turned the screws at all, run procedure 'A' again!)
Now the claw is level and we're tuned again, good.
Have a look at the OFR's baseplate:
if it's tilted forward (towards the headstock), you'll need to tighten the crews in the back cavity.
if it's tilted backwards (away from the headstock), you'll need to loosen the crews in the back cavity.

B1) Check the baseplate's level
B2) Determine which way the screws need to be turned (if at all)
B3) Adjust the screws
B4) Tune (procedure 'A')
B5) Repeat from step B1
(Procedure 'B')

The screws should be evenly turned (as the claw needs to be parallel to the cavity) and they're pretty sensitive: a 1/32th turn on both of them can very well cause a 10 degree change in baseplate angle after steps B1 through B5 are performed.

Right, now the baseplate is level for the desired tuning, good.

Next step: locking the nut.
Maybe you've noticed locking the nut messes up the tuning, maybe you haven't, but it does.
So have a look, if locking makes the lower strings go flat and the upper ones go sharp, you'll need to compensate for that a bit by tuning the lower ones a bit flat and the upper ones a bit sharp before locking as we'll want to minimize using the fine tuners afterwards.
Remember: tune by following steps A1 through A4!

Now that the nut's locked, the fun part starts: fine tuning the bridge.

An OFR is a balancing act and not all the strings are pulling equalling hard on the bridge, right?
That's why we're going to adjust the strings in a certain way: from the "hardest pulling" string to the "softest pulling" one (I'm not really sure, in fact, that this is correct to be honest, but it works for fine tuning).
This boils down to this sequence: E/G/A/B/D/e.

So, it's quite easy as long as you follow a couple simple rules:
* Follow the string adjustment sequence
* After adjusting 1 fine tuner, check tuning again (all strings!)
* Only tune up
* If you need to tune a string down, downtune it flat so you can tune up
* Remember the string sequence, adjusting the E string will have a shit load more impact on the other strings than adjusting the e string

So, firstly: we're going to make sure it's fine tuned for the current bridge position:

C1) Check tuning (all strings!) & determine which string need to be adjusted
C2) Fine tune for that string
C3) Repeat C1-C2 as much as needed until all strings are in tune.
(Procedure 'C')

So far, so good.

D1) Pull up on the whammy bar as far as possible
D2) Fine tune (Procedure 'C')
D3) Press down on the whammy bar as much as possible
D4) Fine tune (Procedure 'C')
D5) Repeat D1->D4 as long as tuning isn't perfect when returning the bridge to zero after pulling up/pressing down
(Procedure 'D')

Procedure D can take very, very long and to be honest, you'll come to a point where the difference between what the tuning is when using the whammy bar and perfect tuning isn't perceivable by human ear any more and you'll only know it's off by looking at the tuner.

There's one thing I forgot to mention though: gravity.
It's the law, so we've got to obey it at all times and tuning our OFR isn't an exception.
The position of the guitar and even the whammy bar influences the tuning of the bridge.
Try it: check tuning the the guitar's flat on an even surface, when on a strap, on your lap, whammy loose or locked in different positions... tuning always will be 'a bit' off.
That's why you never should tune the guitar when it's laying flat, there's just too much difference with how you'd normally hold your guitar.

As a small reference: it's pretty easy to get the OFR to, after returning to zero from pulling up or down on the whammy bar, line up perfectly on the HT6 overview display.
The overview is slightly less accurate than the individual string tuning mode, and I can visually confirm it's a wee bit off in individual string tune mode, but I can't hear the difference any more.
At that point I could run procedure 'D' for some time extra, but I usually don't bother.

10 January 2013

On waking up computers

Introducing something I've been working on: http://code.google.com/p/wurmd/

"Wurmd tries to solve the common problem when using Wake-On-Lan on your server/desktop/fridge/... that once it's asleep it has to be woken up again, which usually is a manual operation the user has to perform. Having the device go to sleep isn't the problem but having to fire up an additional program to wake the device back up can become a PITA after some time.
The logical next step would be to incorporate WoL functionality into programs itself, but that's hardly feasible. Sure, you may get the XBMC crew to write code so if a file share isn't online it'll automagically sends a WoL packet, but that's limited to XBMC, right? What if you want to access your file server at home from your favorite file explorer but it's asleep again?
Wurmd is a standalone program that listens on an interface in the background for initial connections to your configured devices. If it detects such a connection it'll send a WoL packet to the device to wake it up. What this means, practically, is that as long as wurmd is running on the host you can use any program to make a connection with a sleeping device and wurmd will wake it up. Your program probably won't even know what happened.
Binaries are available for both x86_64 and Raspberry Pi's architecture, ARMv6. Packages for various Linux distributions are forthcoming and I might even build an OSX binary."

I guess it's not ready for prime-time yet and there's hardly any error-handling, but it's functional.
I've been running it on my laptop and on my OpenELEC Raspberry Pi for some time now and I quite like it; YMMV.

31 December 2012

Ran guitar - Follow-up review 2

Seeing as there still aren't a lot of Ran guitar reviews floating around and my Ran NGD post gets hit on the regular, I'll continue to review mine.

It's been 7,5 months since I received it and I don't think there was a single day I haven't picked it up to play for at least a bit.
One of the things I was looking forward the most was experiencing stainless steel frets and now I absolutely love them; 7,5 months of bending and they're still as shiny new as on the first day.
Bending is smooth as silk and, depending on the brand of course, other guitars with 'regular' frets now feel a little weird to bend on.
According to some sources ss frets make the guitar sound too bright, but I haven't noticed that tbh.
Another thing I read is that ss frets supposedly make strings wear out faster... haven't noticed that either.
I think they actually make strings last longer as there's way less friction but that's just a hunch.

I was watching some videos of Paul Reed Smith the other day where he was talking about the PRS wood drying process, hinting they dry their wood more then other vendors to get maximum tone and stability out of it. Makes sense to me.
Apart from the initial set up I did when she first arrived and that one time not too long ago where I decided I wanted the action just a fraction of a mm lower, I didn't have to do a single set up adjustment.
Lowering the action was only a matter of lowering the Floyd Rose a tiny bit (obviously), but since I was already doing that I figured I could check other stuff as well and I couldn't have been happier: everything was still perfect.
Neck relief: right where I left it, intonation at the 24th fret: perfect, Floyd Rose: level with the body.
Did I mention she stays in tune, all time time, with whammy abuse and all, for weeks on end?
To put all that a bit in perspective: my Gibson V is always cased when I'm not playing her but still there are small noticeable variations in neck relief during the year as I don't usually heat the house when I'm not around.
Now, my Gibson is by no means bad, but still: the Ran is better.
So that's it: after the initial "OMGZ, dat geetar iz teh awesome!" phase is over and a couple of seasons have passed I can safely review it as being awesome.

Update: click here for the previous Ran articles.

31 October 2012

On Tritanopia / tritanomaly

This is going to be a lengthy one; it's not really about colourblindness, rather on how it affects me.
For the TL;DR crowd: skip this one, it's boring.

A bit of history first.
I was diagnosed with colourblindness at the age of 7 (iirc that is).
I remember one time when I was around 6 where I was asked to fetch my 'green' trousers from the wardrobe but I kept returning with the wrong ones. In the end I started crying in front of the wardrobe because I had no idea which ones to try next, as far as I could see I didn't have any green ones.
I don't quite remember how it came to be my mother took me to the hospital to do the tests, but by the time it was all over I was told I was 'green/blue' colourblind.
Green/blue refers to the colours I have problems with perceiving/telling apart but actually it's called tritanopia tritanomalyor blue/yellow colour blindness, referring to the difficulty of seeing hues of blue and yellow resulting in seeing blue hues as greens (does that make sense? -yes it does, cool).
Now, I remember being presented with the Farnsworth arrangement test (my mother told me years later I fucked that one up pretty badly) and Ishihara plates at the hospital, supposedly there were more tests but I can't remember those.
Anyways, once we exited the hospital building she pointed to a tree and asked what color it had; 23+ years later most people still do that when first being told about my colour  deficiency :') Not that I blame them, far from it, but I think it's pretty damn funny.
Does anyone really think after having lived for over 30 years I don't know a tree is green?
Why is it no one is surprised a completely blind person knows the color of grass, but most blank stare me when I correctly state every single colour of stuff they're pointing at?
The day after I was at school telling my classmates about it all when one asked the one question I've never been able to answer: so what do you see?
It seems to be a pretty important question as almost every online article has these 'this is what normal people see, this is what a colourblind person sees' images but I'll go into detail about what exactly I do (and don't) see later on.
Years later (I was in high school) my biology teacher was talking about bacteria and meanwhile showing some black/white slides of different bacteria samples when I asked which color those organisms have got.
He said it was irrelevant as it completely depends on the type of light one uses to look at them.
I still suspect he just didn't know the answer but still, he was quite right.

About online tests and stuff
20+ years after being diagnosed I'm able to pass a lot of online colourblind tests. Pass as in: 'Estimate of color vision deficiency's probability:3%', that kind of passing... am I getting 'better'?
Not at all it turns out, but it took me some time to figure out what was going on :)
See, a couple of years ago I started to check which tests were on the interwebz.
Turns out there's not too much out there which interactively tests colour deficiency, but I did the few that were out there with spectacular results.
That's because, unlike in real life, I'm able to fiddle with the source 'lighting'.
Let's say you're looking at a square and you know there's supposed to be another colored square inside it but you can't see it... just adjust your monitor's colour settings until you do... that's it.
That's why my monitors' colours appears off (I think) as seen by 'normal' people.
That is when there's actually colour on there of course, most of the time I'm working on a grey on black terminal ;)
Now, in theory this practice isn't too different from adjusting the lighting conditions in some colourblind tests.
As colour is just a byproduct of light interacting with surfaces; changing the lighting changes the color, right?
Happy cheating on online colourblind tests ;)

About sun glasses, video games and black ops
I've got these blue glass sunglasses for about 15 years now, I feel it enhances my vision although I can't quite explain what exactly it's like.
In video games I very much like the night vision option, I feel it levels the playing field by taking away colour so I can totally focus on shapes and movement.
I used to play this military simulation game where I got called a cheat on the regular.
The game had vast maps (~200 km²) so playing a marksman role and long range sniping (1000+ m) was very much possible, provided you could actually pull it off of course: ballistics were incredibly realistic; SEAL used the game engine to train their men, go figure.
Anyways, although sniping on those ranges was technically possible it was very hard to do, especially when the target was camouflaged and hiding in a bush more than a 1000m away.
Of course, on that distance a camouflaged person hiding in a bush would be reduced to a set of pixels through the scope, what I saw though was 2 sets of pixels... one being the bush, one being the person.
When I play airsoft it's the same thing. Camouflage just doesn't work that good on me, I tend to look at shapes, patterns and movement instead of colour.
The 'new' binary camouflage is a bit better, but still pretty easy to spot.
I usually get laughed at by people wearing the 'proper' camouflage when I wear ACU in a woodland setting but I feel it's only fair: their camouflage stands out for me just as much as my ACU does for them :')
In WWII, some colourblind people were sent on special missions because of their decreased ability to see green led to an increase in ability to see through camouflage or detect it.
I've even heard people like me were sent on night missions because our vision is supposed to be better in very low-light conditions.
I've always been more comfortable in these low-light conditions, when I was little I used to tell my mother I could actually see in the dark.
She didn't buy it back then thinking it was a child's imagination but there's some truth in it.
I don't know if could scientifically prove I'm actually able to see better in 'the dark' than your average Joe but what I do know is I see better in those conditions than everyone I know.
I understand it's nothing special though, Special OPS soldiers train to be able to do stuff like that.
What's a fact though is that I'm very sensitive to light, aiming a lit flashlight at me physically hurts.
During the day I usually wear shades just because the daylight intensity is a wee bit too much for me to handle; and it hit me a couple weeks ago it worsens over time.
Dusk is awful... too dark to wear shades yet too bright to go without them, I don't usually drive a car at that time if I can help it, fortunately it only lasts a couple of minutes.
When the sun goes down though I can my eyes relax for the first time since I woke up so that may explain why it seems I have better night vision.
But I don't know for sure either way, if you're running a science department somewhere reasonably close to me and want to test my eyesight: let me know.

So, how do I see stuff and how do I feel about it
I've been asked numerous times if I feel bad not seeing stuff as it is but that question is quite irrelevant to me: color isn't just that big a part of my life if I'm honest.
I prefer either very dark colours (black or almost black), white or red; I usually wear black/dark clothes, my car's black (I wanted red, my girlfriend insisted on black), my guitar's black, most of the house's interior is either black or light etc. I do think I couldn't handle being surrounded by color, the thought alone frightens me.
But how do I see colours then? That's the main question isn't it... the answer is I don't know how to explain it as everything's perfectly natural for me. I've never seen what 'normal' people would call blue, or green or any other colour for that matter so we might as well be living in another universe.
In the past I tried to make the 'I know a shitload shades of grey' analogy, but that doesn't work out too well and you know... there's those porn books ;)
People actually think I see blue as grey and the thing is, maybe they're right.
How the fuck would I know what grey looks like to them?
Names of colours are just that: names; given any colour I could call it X, you could call it Y but we'd both mean the same, we'd only see it differently.
I wrote about my biology teacher stating colour is irrelevant as it all depends on the lighting being used earlier, right? That's how I see it, it's irrelevant for the most part.

Without being overly philosophical on the subject I'll try to explain:
  • Blue looks like blue to me (it probably looks different from what it actually is).
  • Green looks like green to me (it probably looks different from what it actually is).
  • I can see yellow just fine unless it's light yellow in which case I can't differentiate it too well with white.
  • Mixed blue/greens I usually can tell the right main colour (blue or green).
  • Cyan (equal amount of green and blue) I honestly don't know what to call it, so I usually call it grey but I don't like it one bit.
  • I know the word 'purple' but I've never actually seen it, what people call purple is just a variation of blue or a variation of red to me.
  • I define a shitload shades of red, from what usually would be called brown to what would be called purple... it's mostly variations of "very dark red" to "very dark pink" to me.
  • Yes, pink is a variation of red to me. I think it's supposed to be a variation of purple, right?
  • When 2 'problem' colours are next to each other a kind of optical illusion can occur where they blend to a single colour I can't easily define. Usually I'd call the resulting colour 'grey' because I'm not really sure how to define it but usually I get a really bad headache if I look long enough at it. The upside of that was I got to skip pesky topographic map questions on geography exams based on medical grounds :) The downside is I can get stuck in MMORPG's simply because I can't see anything anymore (think dark blue/greenish caves or jungle settings), often my friends had to come back for me and guide me out :)
  • When text is in a 'problem' colour, depending on the background, it all becomes one big blur. Some of my colleagues deploy this technique in order to effectively block me from reading off their terminal emulator's window (yes, I'm looking at you guys: Nende,K and Stijn). A fine example of this would be the 'Matrix' Konsole theme, the bash colour scheme on Ubuntu or the colour schemes in Vim.
That's about it, I omitted posting links to relevant articles but it can all be easily found on Google.

30 October 2012

imapsync revisited

Reading around the interwebs I've gained a little insight in what's happened to imapsync: the author wanted to make some money on the project and decided to change the license.
Next the Debian maintainer wasn't comfortable anymore packaging it and asked the author whether he still wanted Debian to ship imapsync... guess what the answer was[1]
Now, the gitsource repo I wrote about earlier is from a guy who's bought a license from the author, so as far as I can see he's got the right to put up the source[2].
Which, in turn, gives me the right to clone the repo, package the script and put it up here.

The package only depends on perl and libmail-imapclient-perl so it shouldn't matter which distribution you install it on, as long as it's a Debian derivative.
So, there ya go [3], install with sudo dpkg -i.


[1] http://lists.debian.org/debian-legal/2011/01/msg00044.html
[2] http://www.linux-france.org/prj/imapsync_list/msg01371.html
[3] http://bin.syphzero.net/imapsync-1.508_all.deb

13 October 2012

Disable UPnP on Scarlet's Sagem F@st3464 DSL bridge

Quickie:

telnet 192.168.1.1
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.
login: admin
Password: ******** (OLOVDSL2)
[admin @ home]$ rg_conf_print upnp/enabled
(enabled(1))

Returned 0
[admin @ home]$ rg_conf_set upnp/enabled 0

Returned 0
[admin @ home]$ rg_conf_print upnp/enabled
(enabled(0))

Returned 0
[admin @ home]$ Connection closed by foreign host.

That's it.

24 September 2012

Preferring IPv4 over IPv6.

As more and more hosts are moving over to IPv6, you might encounter DNS A records with IPv6 entries.
That's all fine and dandy and I do realize the need for an extended IP address pool, but if it's starting to affect performance I say fuck IPv6.
Sadly, modern GNU/Linux systems prefer IPv6 addresses over IPv4 when being presented with a choice. I honestly don't see why the fuck IPv6 should be preferred right now as it's bound to be a lot slower on a lot of networks, for the time being at least.
Case in point: Debian's apt-get update over IPv4 and IPv6:

root@box:~# host security.debian.org
security.debian.org has address 195.20.242.89
security.debian.org has address 212.211.132.32
security.debian.org has address 212.211.132.250
security.debian.org has IPv6 address 2001:a78:5:1:216:35ff:fe7f:6ceb
security.debian.org has IPv6 address 2001:8d8:580:400:6564:a62:0:2
security.debian.org has IPv6 address 2001:a78:5:0:216:35ff:fe7f:be4f
security.debian.org mail is handled by 10 chopin.debian.org.

IPv6:
root@box:~# time apt-get update
[...]
real    1m18.222s
user    0m7.472s
sys     0m6.948s
IPv4:
root@box:~# time apt-get update
[...]
real    0m13.481s
user    0m7.728s
sys     0m5.332s
We could just add static ipv4 lines in /etc/hosts, but that's kinda defeating the purpose as we don't want to disable IPv6 altogether.
So, how do we tell the system to prefer IPv4 addresses over IPv6?
It's rather simple, actually: we need to have a look at getaddrinfo(3)'s configuration file; /etc/gai.conf.
Locate this line and uncomment it:
#precedence ::ffff:0:0/96  100
There ya go, IPv4 is preferred now.
This works as that's the special address range to help in the transition from 4 to 6; every IPv4 address can be written as an IPv6 one using that form.
Anyways, the format is ::ffff:0:0/96 which means that the ipv4 ip address 192.168.18.234/32 will be written as 0:0:ffff:192.168.18.234/128 and will match that line in gai.conf.