Added abbreviation feature of Kramdown.

css/custom.css

@@ -1,3 +1,8 @@
+abbr, acronym {
+    border-bottom: 1px dotted #888;
+    cursor: help;
+}
+
 #headerleft, #headerright {
   display: inline-block;
 }

know-how/hacking/_posts/2009-12-19-avm-fritzbox-7270.md

@@ -128,3 +128,7 @@ To use custom DNS entries instead of those given by your ISP, use the
 
 Now just insert your desired DNS servers, upload the changed config and you should be set.
 (Info found on [ip-phone-forum.de](http://www.ip-phone-forum.de/showthread.php?t=86191&page=2).)
+
+*[FB]: Fritz!Box
+*[DNS]: Domain Name System
+*[ISP]: Internet Service Provider

know-how/hardware/_posts/2009-02-02-asus-wl300g.md

@@ -26,16 +26,25 @@ The router ID was found quick: In the `dd-wrt.v23_asus.trx` at `0x356fc4`, there
 
     57 4c 35 30 30 67 78
 
-which is `WL500gx`. After changing it to `WL300g ` (with a space after the "g" to fill up the digit), the router didn't reject the firmware directly, but initiated the update, then rebooted quickly after that and showed the old firmware again.
+which is `WL500gx`. After changing it to `WL300g ` (with a space after the "g" to fill up the digit), the router didn't reject the
+firmware directly, but initiated the update, then rebooted quickly after that and showed the old firmware again.
 
-According to the [DD-WRT manual for the WL-500g](http://www.dd-wrt.com/wiki/index.php/Installation#Asus_WL500G</u>.28Original.29), the router should have a recovery mode which you can enable by holding the Reset button while powering on the device. But seems this mode wasn't there in my router.
+According to the [DD-WRT manual for the WL-500g](http://www.dd-wrt.com/wiki/index.php/Installation#Asus_WL500G</u>.28Original.29),
+the router should have a recovery mode which you can enable by holding the Reset button while powering on the device. But seems this mode wasn't there in my router.
 
-So there has to be some sort of checksum which tells the router whether the firmware file is corrupt or not. In the DD-WRT forums I read somewhere, that there are only some informational bytes different between a normal DD-WRT binary firmware and the ASUS TRX format - maybe the ID-string at the end.
+So there has to be some sort of checksum which tells the router whether the firmware file is corrupt or not. In the DD-WRT forums
+I read somewhere, that there are only some informational bytes different between a normal DD-WRT binary firmware and the ASUS TRX format - maybe the ID-string at the end.
 
-Therefore I compared the two files `dd-wrt.v23_asus.trx` and `dd-wrt.v23_generic.bin` and voilà: Besides the few bytes at the end of the file, there were 4 additional bytes different at position `0x08`. This HAD to be the checksum. The remaining question was, from which bytes it was calculated. Since the seemingly compressed data began at `0x28`, I tried from there to the end and used [Hex-Workshop](http://www.hexworkshop.com/) to calculate different checksums, but nothing matched what was in these 4 bytes. The next try was from `0x10` but also no match. Then I tried starting directly after the checksum in the header, from `0x0c` and bang: The CRC32 checksum matched that in the header.
+Therefore I compared the two files `dd-wrt.v23_asus.trx` and `dd-wrt.v23_generic.bin` and voilà: Besides the few bytes at the end of
+the file, there were 4 additional bytes different at position `0x08`. This HAD to be the checksum. The remaining question was, from
+which bytes it was calculated. Since the seemingly compressed data began at `0x28`, I tried from there to the end and used
+[Hex-Workshop](http://www.hexworkshop.com/) to calculate different checksums, but nothing matched what was in these 4 bytes. The next
+try was from `0x10` but also no match. Then I tried starting directly after the checksum in the header, from `0x0c` and bang:
+The CRC32 checksum matched that in the header.
 
 ![Hex Workshop Screenshot]({{ site.url }}/assets/hexworks.png)
 
-So I calculated the CRC32 of my modified file and changed the header - and now I could upload the DD-WRT file using the normal firmware upgrade of the original firmware. After installing v23, you can easily update to v24 using the DD-WRT web interface.
+So I calculated the CRC32 of my modified file and changed the header - and now I could upload the DD-WRT file using the normal firmware
+upgrade of the original firmware. After installing v23, you can easily update to v24 using the DD-WRT web interface.
 
 ![DD-WRT Version Info]({{ site.url }}/assets/ddwrt.png)

know-how/hardware/_posts/2009-02-02-medion-bios-settings.md

@@ -17,3 +17,5 @@ According to a MEDION employee, there are only 2 employees who know this passwor
 Well, IMHO everyone should decide for his own whether he wants to risk damaging his PC or not. But I guess the newer BIOSes ask for another password.
 
 More info: [PC Welt forums](http://www.pcwelt.de/forum/showthread.php?t=196865), [Wim's BIOS](http://www.wimsbios.com/phpBB2/viewtopic.php?t=7557)
+
+*[IMHO]: In My Humble Opinion

know-how/hardware/_posts/2009-12-13-tomtom-pnas.md

@@ -80,3 +80,7 @@ After passing the roundabout, the map displays fine but as soon as you reach the
 After it started up again and you're above the "hide map"-speed, it crashes and reboots again. The crossing which should show up is the one at `N 52° 31.744', E 13° 06.607'`.
 
 Tested with NavCore 9.014 and 9.024, maps 830 and 840. All combinations show the same behavior.
+
+*[PNAs]: Personal Navigation Assistants
+*[TTS]: Text to Speech
+*[POIs]: Points of Interest

know-how/hardware/_posts/2009-12-22-memup-pop-key.md

@@ -24,3 +24,5 @@ With the [SMI UFD Utility](http://ftp.usboffice.kr/files/SMI_UFD_Utility.zip), y
 
 This way, you can make it e.g. a Windows XP or Windows 7 installation device, use it for the [System Rescue CD](http://www.sysresccd.org/Main_Page) or - if you can trick the *U3 LaunchPad* into
 accepting the stick - burn the U3 software to it to make it U3 compatible.
+
+*[SMI]: Semiconductor Manufacturing International

know-how/hardware/sandisk-sansa-fuze/_posts/2008-12-31-mtp-mode.md

@@ -23,3 +23,6 @@ and maybe [mtp-tools](apt://mtp-tools). Now connect your player in MTP mode and
 (make sure, the directory `/mnt/sansa` exists before trying the mount command.)
 
 Now you should have access to the MTP area of your Sansa where you can delete the demo songs or put new files in.
+
+*[MTP]: Media Transfer Protocol
+*[MSC]: Mass Storage device Class

know-how/hardware/sandisk-sansa-fuze/_posts/2008-12-31-rhythmbox.md

@@ -41,3 +41,7 @@ The `playlist_path` and `playlist_format` describe the location for playlists an
 
 
 The file `/usr/share/hal/fdi/information/10freedesktop/10-usb-music-players.fdi` lists the options usually set for FUZE players. Just search for the string "Fuze". But I guess the PnP-ID of the newer models isn't in that XML file.
+
+*[MTP]: Media Transfer Protocol
+*[MSC]: Mass Storage device Class
+*[FUSE]: Filesystem in Userspace