Signatures were once used to express something personal about the sender or convey a useful notice. Today, abuse seems to be the norm. It’s just an observation. If you actually like these messages, just go right on sending them…

1. Prepare a fresh NTFS partition on the USB disk /dev/sdX and mount it at /mntX1, then copy all files from the Windows installer disc or image into /mntX1
2. Install Grub2:
   cd /mntX1; sudo grub-install --no-floppy --root-directory=/mntX1 /dev/sdX; sync
3. Download the latest Grub4Dos, and unpack grub.exe into /mntX1
4. Create /mntX1/boot/grub/grub.cfg:
   set timeout=0
   set default=0
   menuentry “Install Windows” {
        linux16 /grub.exe --config-file=”root (hd0,0); chainloader (hd0,0)/bootmgr”
   }

I was surprised that such a complicated setup actually worked. Be sure to substitute your own values for /mntX1 and /dev/sdX. In the Grub4Dos config, (hd0,0) refers to the first partition on the boot disk; you’d need to change that if you want to boot the installer from a different partition.

Be warned that the following procedure would overwrite the target disk’s MBR, effectively wiping all data on said disk. Make sure that you do not target the wrong disk. Naturally, what you do with this information is your responsibility

1. Install hfsprogs (available in the Ubuntu repositories, if you use Ubuntu).
2. Get the Chameleon binary package from <http://chameleon.osx86.hu/> and untar it, then navigate to the i386 directory in your terminal.
3. Type `sudo dd if=boot0 of=/dev/sdX`, where /dev/sdX is the target disk; this is the step that cleans up the disk and loads a fresh MBR containing the stage-0 boot code.
4. Make a new HFS+ partition (type AF) using fdisk. Let me know if you need help with this.
5. Format the partition by doing `sudo mkfs.hfsplus /dev/sdX1`.
6. Type `sudo dd if=boot1h of=/dev/sdX1` to install the stage-1 boot code to the bootsector of the new HFS+ partition.
7. Now, type `sudo mount /dev/sdX1 /mnt` to mount the partition, where /mnt is your mount point of choice.
8. Type `sudo cp boot /mnt/` to copy the final piece of Chameleon over.
9. Unmount the partition using `sudo umount /dev/sdX1`.

Now you should have a shiny new Chameleon boot disk. I hope this helps.

Dude: Well in True Blood there’s this girl who has to cut up a body and get rid of it.
Companion: Okay.
Dude: Last night I dreamed that I had a backpack full of body parts.
Companion: It happens. Last night I dreamed that I killed someone.
Dude: I was all like, “ugh, all these legs and stuff, what do I do with them before someone catches me?”

While we were eying them in silence, somebody said, “Last night I made a baby.” “Why, congratulations!” was the consensus. He clarified, “No, I mean I got someone pregnant and then two hours later I had a baby. I thought, ‘whoa, what an improvement!’”

I hope it was just a case of pre-thesis-defense jitters.

To remove it, I simply issued

sudo apt-get autoremove ubuntuone* python-ubuntuone* --purge

… and it stopped bothering me after I logged out and logged back in. Launchpad has a page on this as well.

My folks say that I’m a simple guy — too much so for my own good. I like to see the best in everyone. And if, God forbid, I had a reason to be upset, I didn’t see the need to actually be upset and compound the problem.

With experience, it would be increasingly difficult to maintain this attitude. I would hate to have to live with anger.

I’d like to mention that it is partly because of 110mb that I had gained so much experience with Web development, and that I now know so many worthy individuals. Thanks.

Why, I simply installed the usbNetwork hack before upgrading to 2.5.2. The usbNetwork hack installs a Telnet daemon and a SSH server on the Kindle, while allowing the Kindle to be controlled over USB. It is a simple way to gain a root terminal, and it still works after the new firmware is installed. Hopefully, this paves the way for further hackery.

It should be noted that users who already have the new firmware cannot apply the usbNetwork hack (the process terminates with error code U004). If you’re interested in using it, install it while you still have the 2.3.* firmware.

So how exactly do you get a root console on the Kindle, with the usbNetwork hack? First, you put the Kindle into debug mode (in general, to issue any command, just follow these five steps and change what you type during the fourth step):

1. press [Home] to go to the home screen
2. type any key on the keyboard to enter search mode
3. press [←] to blank the line
4. type ;debugOn (the ; character, and many others, is available in the [SYM] menu)
5. press [↵] to issue the command

Next, issue the `usbNetwork command on the Kindle, and plug it in. It should appear as a “RNDIS/Ethernet Gadget” rather than the usual mass storage device. By default, the interface should be configured with IP address 192.168.2.1, and the Kindle could be accessed at 192.168.2.2. How you go about setting up the interface depends on the operating system on your desktop. Telnet and SSH should be running at this point, either of which would give you a root shell.

Users have reported the interface dying after a couple of minutes. Through the console, it is possible to disable the daemon that periodically resets network connections as the Kindle goes to sleep:

/etc/init.d/netwatchd stop

Most extant clinics still rely on paper charts, and it is a daunting task to convert all existing charts to computer files. A common approach to work around this problem is to maintain a hybrid system that keeps track of all new patients electronically while referencing paper charts when necessary. This way, the paper archive would not continue to expand. Old charts would be retrieved only when necessary, since it is a relatively expensive operation compared to a database search. While this method cleverly sidesteps the need to perform any conversion, it does not make the mountain of paper any smaller; a small modification solves this problem nicely. When a paper chart is ready to be archived again after being retrieved, it is scanned into a computer file instead. Only the actively-used charts are converted, greatly optimizing future lookups while saving resources.

Another problem with electronic medical records is authentication and authorization. Digital files are very easily modified and copied, so they need to be properly protected. In addition, many common methods of exchanging such files, such as email, are inherently insecure. Public-key cryptography provides two ways to protect data integrity and authenticity. Firstly, digital signatures using the public-key infrastructure can only be applied by the signer (who holds the private key), but could be verified by anyone (using the public key). Secondly, the public-key infrastructure may be used to set up encrypted communication channels that are resistant to eavesdropping.

Finally, there is a problem with how electronic health records are handled. Most clinics that use such systems currently outsource record-keeping to other companies. To protect their commercial interests, these companies do not document how to access stored data. This is fine if a clinic keeps using the same company, but there is no way to make backups, for example, in preparation of switching to a different company. By entrusting business records to third-parties that have purely commercial interests in mind, clinics allow these parties to hold their business hostage. Some companies do provide backups in exchange for payment, but this is hardly flexible.

Thus, there is a pressing need for an open source record keeping and practice management system that is flexible, secure, and transparent. Some people assume that transparency of protocol means insecurity. On the contrary, there are many secure systems whose programming is fully open for auditing. One question remains: how is such a system commercially viable? By closing down the interface and creating vendor lock-in situations, current medical record-keeping vendors are able to ensure a constant revenue stream in the short run. However, there is much business to be done providing hosting and support for these systems. Most physicians would not want to maintain their own systems, and would rather rely on service providers. Those who are more knowledgeable in software development may even be able to contribute to the project. Canonical, for example, offers a totally free and open operating system, while continuing to grow because of their successful support business.