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.