softwarebakery.com

Install Hirens Boot CD on DriveDroid

frozencow@gmail.com (FrozenCow) — Mon, 22 Apr 2013 22:30:00 +0200

In this tutorial we will go through the process of installing Hirens Boot CD on a DriveDroid image. This is very similar to the process of installing other systems. The steps are as follows:

Create a blank image in DriveDroid of reasonable size.
Select the image in DriveDroid, so that it becomes available on your PC as an USB drive.
Follow the instructions at Hirens Boot CDs page on how to install Hirens on a USB drive.

This also applies to other systems, but for those systems the instructions on how to install them to a USB drive will, of course, differ. In this article we will focus on install Hirens Boot CD.

Requirements

A phone with DriveDroid installed
An USB cable
A PC with Windows installed
7-Zip
Hirens.BootCD.15.2.zip from hirensbootcd.org
USBFormat.zip from hiren.info
grub4dos.zip from hiren.info

Creating a blank image in DriveDroid

The first step is creating a blank image in DriveDroid where we will install Hirens Boot CD on. You will find the option 'Create blank image...' under the + menu in DriveDroid:

Next choose a filename, set the size to 650MB, uncheck 'Partition Table (MBR)' and set filesystem to 'None'. It should look like:

Next hit create and wait for the creation process to complete. This usally takes at least a minute.

Now we have a blank image. It is time to use it. You should be able to see the image in DriveDroids image list. Tap the newly created image:

A dialog will popup where you can select in what mode to host the image. Your dialog might differ, but the options are from left to right:

Writable USB-disk
Read-only USB-disk
CD-rom disk

On my device I have two host-devices, so I see two rows. For our purposes we want to create a USB-disk and we need the PC to be able to write to it, so we choose the first option:

A USB-disk should now popup on your PC. From here on we can loosely follow the tutorial on how to install Hirens Boot CD to an USB-drive that is found on their site.

Installing Hirens Boot CD

From their tutorial we can see that we first need USBFormat. Download and extract the zip and run USBFormat as an administrator. Next look for the USB-disk in USBFormat. For me it shows up as 'Linux File-CD', but that may differ on your phone/rom/kernel. Once you have the USB-drive selected use the following settings to format the disk:

Once USBFormat has finished, you'll notice that the disk now becomes available on Windows and allows you to put files on it.

For the next step we need to use grub4dos. Download and extract the zip and run grubinst_gui.exe as administrator. Look for the USB-disk by looking for the correct size (around 650MB) and use the following settings to install Grub4Dos onto the USB-disk:

Next, copy grldr and menu.lst from grub4dos.zip to the USB-drive.

Now it's time to put the rest of the files of Hirens Boot CD onto the USB-drive. First download and extract the file Hirens.BootCD.15.2.zip from their download page. You should see an ISO file named Hiren's.BootCD.15.2.iso. We will use 7-zip to extract the files from the ISO to the USB-disk. Click with right mouse on the ISO, choose 7-Zip and 'Extract files...':

Next enter the location of the USB-disk (use Browse if you aren't sure). Extraction will take several minutes.

When the extaction process is finished you should have the following files on your USB-disk:

Finally, make sure to safely remove the USB-disk from Windows. This is to ensure all data is being written to the disk (which is usually cached by Windows for a while). After doing so, open up DriveDroid on your phone and tap the image again. Now instead of using the first option, choose the USB-disk in read-only mode (the padlocked USB icon). This will ensure the USB-disk cannot change whenever the image is hosted in this mode. If you ever want to write some files onto the disk, choose writable USB-disk-mode.

Now reboot your PC. It should now be able to boot Hirens Boot CD from your phone. Enjoy!

Shrinking images on Linux

frozencow@gmail.com (FrozenCow) — Thu, 21 Feb 2013 15:53:00 +0100

When creating images from existing ISOs you often need to allocate a number of MB for the image to at least fit the files that are in the ISO. Predicting the exact size of the image is hard, even for a program. In this case you will create an image that is larger than actually needed: the image is much larger than the files on the image are combined.

This post will show how to shrink an existing image to a more optimal size. We will do this on Linux, since all required tools are available there: GParted, fdisk and truncate.

Requirements

A Linux PC
Some knowledge how the terminal works will helps
The unoptimal image (myimage.img in this example)

Creating loopback device

GParted is a great application that can handle partition tables and filesystems quite well. In this tutorial we will use GParted to shrink the filesystem (and its accompaning partition in the partition table).

GParted operates on devices, not simple files like images. This is why we first need to create a device for the image. We do this using the loopback-functionality of Linux.

First we will enable loopback if it wasn't already enabled:

$ sudo modprobe loop

Now we can request a new (free) loopback device:

$ sudo losetup -f

This will return the path to a free loopback device. In this example this is /dev/loop0.

Next we create a device of the image:

$ sudo losetup /dev/loop0 myimage.img

Now we have a device /dev/loop0 that represents myimage.img. We want to access the partitions that are on the image, so we need to ask the kernel to load those too:

$ sudo partprobe /dev/loop0

This should give us the device /dev/loop0p1, which represents the first partition in myimage.img. We do not need this device directly, but GParted requires it.

Resize partition using GParted

Next we can load the device using GParted:

$ sudo gparted /dev/loop0

This should show a window similar to the following:

Now notice a few things:

There is one partition.
The partition allocates the entire disk/device/image.
The partition is filled partly.

We want to resize this partition so that is fits it content, but not more than that.

Select the partition and click Resize/Move. A window similar to the following will popup:

Drag the right bar to the left as much as possible.

Note that sometimes GParted will need a few MB extra to place some filesystem-related data. You can press the up-arrow at the New size-box a few times to do so. For example, I pressed it 10 times (=10MiB) for FAT32 to work. For NTFS you might not need to at all.

Finally press Resize/Move. You will return to the GParted window. This time it will look similar to the following:

Notice that there is a part of the disk unallocated. This part of the disk will not be used by the partition, so we can shave this part off of the image later. GParted is a tool for disks, so it doesn't shrink images, only partitions, we have to do the shrinking of the image ourselves.

Press Apply in GParted. It will now move files and finally shrink the partition, so it can take a minute or two, most of the time it finishes quickly. Afterwards close GParted.

Now we don't need the loopback-device anymore, so unload it:

$ sudo losetup -d /dev/loop0

Shaving the image

Now that we have all the important data at the beginning of the image it is time to shave of that unallocated part. We will first need to know where our partition ends and where the unallocated part begins. We do this using fdisk:

$ fdisk -l myimage.img

Here we will see an output similar to the following:

Disk myimage.img: 6144 MB, 6144000000 bytes, 12000000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000ea37d

      Device Boot      Start         End      Blocks   Id  System
myimage.img1            2048     9181183     4589568    b  W95 FAT32

Note two things in the output:

The partition ends on block 9181183 (shown under End)
The block-size is 512 bytes (shown as sectors of 1 * 512)

We will use these numbers in the rest of the example. The block-size (512) is often the same, but the ending block (9181183) will differ for you. The numbers mean that the parition ends on byte 9181183*512 of the file. After that byte comes the unallocated-part. Only the first 9181183*512 bytes will be useful for our image.

Next we shrink the image-file to a size that can just contain the partition. For this we will use the truncate command (thanks uggla!). With the truncate command need to supply the size of the file in bytes. The last block was 9181183 and block-numbers start at 0. That means we need (9181183+1)*512 bytes. This is important, else the partition will not fit the image. So now we use truncate with the calculations:

$ truncate --size=$[(9181183+1)*512] myimage.img

Now copy the new image over to your phone, where it should act exactly the same as the old/big image.

Windows installation on DriveDroid

frozencow@gmail.com (FrozenCow) — Fri, 25 Jan 2013 12:31:00 +0100

In version v0.7.0 of DriveDroid (Free) and DriveDroid (Paid) a feature has been added to create blank images that look like normal USB disks. This allows you to use tools on your PC to fill the blank USB disk with whatever you want.

In this post I will show how to create a Windows 7 installation disk that can be booted from your phone with DriveDroid. The disk will be made using files of the official Windows 7 ISO.

Requirements

DriveDroid v0.7.0+
4GB free space on your Android phone
A PC with Windows 7 and 7-zip installed
Diskpart utility (installed by default on Windows 7)
A Windows 7 installation disk or ISO

Note that on some systems diskpart is not installed. I installed it seperately using the diskpart setup.

Image creation

First hook up your phone to your PC using a USB cable.

Next we'll have to create a blank image on your phone. On this image we will eventually store the installation disk. In DriveDroid we go to the + button and choose 'Create blank image...'.

Choose a filename like 'windows7.img' and choose 3500MB as the size for the image. You can uncheck 'Partition table (MBR)' and choose 'None' for the filesystem. Now hit the 'Create' button on the top-right.

As a side-note, we choose to not create a partition table and filesystem here because DriveDroid does not support formatting NTFS filesystems. NTFS is required for the Windows 7 installer to work. We will partition and format the image from your PC in Windows, but we'll get to that.

This will create the image file in the background. Open the notification-bar to see when the image creation is finished. Most time will be used by 'Allocating file...', which creates a 3500MB file. This can take half an hour or so on most devices that have a FAT-32 filesystem on their SD-card, other filesystems do not seem to have this problem and will finish almost instantly.

It is recommended not to do anything else on your phone while the image is being created. At the moment the image creation process can be killed by Android when there isn't enough memory available on the device to launch other applications. I still need to figure out how to avoid this.

Once the image is created go to DriveDroid.

Partitioning and formatting

Select the image in DriveDroid and click the option that says '(read-write)'. As soon as we have done that, Windows will find a new USB drive. A window will popup in Windows asking to format the drive.

Choose 'Cancel': this method of formatting is not compatible with a Windows 7 install disk, since it'll not create a partition table and bootsector. Thus it will not boot using this option. We will partition and format the disk properly using diskpart.

Go to start and type cmd.exe. Command prompt will open.

Start diskpart by typing diskpart.

Show the connected drives by typing list drive.

You will see that the image you just created in DriveDroid is listed here as a disk of 3500MB. In this example it is listed as Disk 3.

To work on disk 3, we need to select it by typing select disk 3.

Next we create a partition table and fill the bootsector by typing clean.

Now we can create a partition by typing create partition primary.

The partition hasn't got a filesystem yet. For the Windows 7 install disk we need a NTFS filesystem. We can format a NTFS filesystem on the partition by typing format fs=ntfs quick. This will take a few seconds to a minute or so.

Now we have a bootsector, partition table, partition and filesystem. We only have to mark the partition as 'bootable' to be able to boot from it. We do this by typing active.

Finally we leave diskpart by typing exit. You can close the window after that.

Copying files

Now we have a disk that has a filesystem and can be booted from. We should be able to see the empty disk in 'My Computer'. In this example it is disk G:.

Next we need to copy files from the official Windows 7 installation CD to the USB drive. If you have the CD at hand, you can just copy those files over.

However, since I only have an ISO file I need to extract the ISO to the USB drive. We can do this using 7-zip. Go to the Windows 7 ISO using Windows Explorer. Right click the ISO file, choose 7-Zip and choose Extract files....

Choose G:\ as the destination to extract the files to and hit OK.

Extracting the files will take a while.

Once the files are extracted the contents of your disk should look similar to this.

We are finished. The disk should be usable and is stored in windows7.img on your Android phone. If you want to try it on another PC, first safely remove the disk by left clicking the icon in your system tray.

And choosing your phone from the menu. In my case it is GT-I9000 (Samsung Galaxy S).

Unplug your USB cable and plug it in a PC where you want to install Windows 7. Make sure you still have windows7.img selected in DriveDroid.

Boot the other PC, go to the bios and put your phone as the first boot device.

Save the changes and reboot. The PC should now boot the Windows 7 installer from your phone.

DriveDroid 0.7.0 released

frozencow@gmail.com (FrozenCow) — Sun, 20 Jan 2013 22:01:00 +0100

Version 0.7.0 of DriveDroid (Free) and DriveDroid (Paid) is just released. This version comes with quite a few changes. Here is the changelog:

Added 'Create blank image' to create an empty/FAT32 disk-image
Improved USB Mass Storage option
Improved support emails
Option to check for USB Mass Storage
Changed menu structure for creating/adding/downloading images
Added support for HTC Sensation, Samsung GT-S5360 and HDC i9300
Fixed crash when going to preferences without root

Create blank image

The biggest feature is the ability to create blank images from within DriveDroid. You can specify the size that you want the USB-disk to have and DriveDroid can format a FAT-32 filesystem on it (big thanks to fat32-lib). Once you select the image you'll see an empty USB-disk on your PC where you can store files.

One advantage of this system is not just being able to store files, but to be able to use any tool on your PC to create bootable USB drives. In the past a number of ISOs were not loadable by DriveDroid, because those weren't USB compatible. Now you can use tools like Windows 7 USB/DVD download tool, UNetBootin, Image Writer or just dd to write images or ISOs to a disk you created+hosted using DriveDroid.

Compatiblity

I've also tried to support devices that do not have USB Mass Storage by default. Use the 'USB Mass Storage (UMS)'-option in the preferences of DriveDroid to enable UMS. It will use the normal way of enabling UMS, but will try to detect whether this does not work and use other methods to enable it. Hopefully this will work for some devices.

For anyone who still has trouble, please send me a support email through the preferences of DriveDroid. Support emails now contain more information, so it should have a better chance of solving the problem.

DriveDroid 0.6.2 released

frozencow@gmail.com (FrozenCow) — Sun, 09 Dec 2012 22:13:00 +0100

Since the first release of DriveDroid (version 0.5) much has changed. This post summarizes the changes from 0.5 till 0.6.2.

Distributions

A number of new distributions are now available in the downloadlist:

Arch Linux
Crunchbang
Debian
Fedora
FreeBSD
GeeXboX
Gentoo
Grml
OpenSUSE
SliTaz
Tails
Ubuntu

For a recent list of distributions take a look distscraper, which retrieves the different downloadable image-urls.

The downloadlist now also includes logos of the distributions. The logos are retrieved and slightly altered using a script in distscraper.

Compatiblity

Support for the different devices has been improved greately by adding support for hosting iso/img files for 5 new devices/ROMs. There were also a lot of different little incompatiblities between the different Android versions, which now show appropriate messages when a particular feature is not supported on the device.

Paid version

Last but not least, there is now a paid (no-ads) version available on the Play Store. No extra features are added to the paid version at the moment, though it always helps development.

DriveDroid 0.5 released!

frozencow@gmail.com (FrozenCow) — Mon, 12 Nov 2012 20:13:00 +0100

DriveDroid allows you to boot your PC from ISO/IMG files stored on your phone. This is ideal for trying Linux distributions or always having a rescue-system on the go... without the need to burn CDs or USB pendrives.

DriveDroid also includes a convenient download menu where you can select a popular distibution to download and use.

How do you make this work?

Connect your phone to your PC using an USB cable
Download an image file (.iso or .img) through DriveDroid or download them manually
Select the image file in DriveDroid to let your phone 'host' the file over USB
(Re)start your PC and make sure the correct boot priority is set in the bios
The image should now be booted on your PC

Requirements

Root
USB cable (from phone to PC)
USB Mass Storage-support should be enabled on your ROM (being able to mount SD card)

Notes

Some .iso files do not support being booted over USB, but most popular distibutions are. All images that are downloadable through DriveDroid are supported.
All .img files should work fine.
It is recommended to download distributions over wifi: those files are big!
Do NOT use DriveDroid while your SD card is mounted (being used on your PC). This can cause loss of data.

The downloads that DriveDroid provides are gathered using distscraper. If you want other distributions to be includes in the list, please open up an issue or do a pull request.

Recovering commits with Git

frozencow@gmail.com (FrozenCow) — Fri, 13 Jan 2012 21:42:00 +0100

Git is pretty powerful. With this power it allows you to do amazing things. Recently I've come to realize that you can hurt yourself pretty badly with its powers. Operations like resetting and fast-forwarding are dangarous and should be used with care.

Today I did not handle them with care and commits seemed to be lost. Luckily I found that Git does not delete commits. My lost commits were just not referenced by any branch or tag, but were 'dangling'. The problem is finding these commits back.

I found two possible commands that helped me find my lost commits: git reflog and git fsck --lost-found.

Reflog

This command shows the history of operations you have done on your repository. Each operation is shown with the hash of the commit that it results in. As an example we will create a repository, commit a change, 'lose' the commit and find it back using git reflog.

First we create a test repository:

$ mkdir myrepo
$ cd myrepo
$ git init

Next we'll commit a file with some text:

$ echo some text in a file > file
$ git add file
$ git commit -m "My first change"

Now we'll make a change to the file:

$ echo other text in a file > file
$ git commit file -m "Another change to file"

You can see the current commits in the log:

$ git log --oneline
fd9e098 Another change to file
98b88cc My first change

Now we make our mistake and reset to the first commit:

$ git reset --hard HEAD~1

Our second commit is now 'lost'. We can see that the file does not match the latest change we made and the log does not show our latest commit anymore:

$ cat file
some text in a file
$ git log --oneline
98b88cc My first change

Presume we haven't done the previous logs and don't know the hash of the latest commit that we have done. We can see the operations we did using reflog:

$ git reflog
98b88cc HEAD@{0}: reset: moving to HEAD~1
fd9e098 HEAD@{1}: commit: Another change to file
98b88cc HEAD@{2}: commit (initial): My first change

Two commits and a reset, that seems to fit with what we did. Commit 'fd9e098' seems to be the one we're missing. We can take a look at the history of that commit to get a better understanding whether it really is the right one:

$ git log fd9e098 --oneline
fd9e098 Another change to file
98b88cc My first change

This seems to be in line with what we previously saw, so now we want to get back that last commit. We have the option to just reset our history to that commit by using git reset --hard:.

$ git reset --hard fd9e098

The history is now the same as before:

$ git log
fd9e098 Another change to file
98b88cc My first change

If you weren't sure it was the right commit yet, you can do a checkout of the commit before resetting to look at its files more easily:

$ git checkout fd9e098

Though do remember to checkout to your previous branch when you're done going through its files:

$ git checkout master

Lost and found

Instead of using git reflog to find your lost commits, you can also use Git's fsck to find 'dangling' commits for you. If we go back to our example we can do a reset again to 'lose' our latest commit:

$ git reset --hard 98b88cc

Now if we issue the lost and found command. It'll return the dangling commit(s) that were lost:

$ git fsck --lost-found
dangling commit fd9e0982eaf3d8589aac26f0c6a52be5741ee8f7

We can do the same as before and reset to that commit:

$ git reset --hard fd9e0982eaf3d8589aac26f0c6a52be5741ee8f7

Now the history is restored and the files are of the latest commit.

Garbage collection

Even though the dangling commits exist at this time, they will be removed after a garbage collection. Git automatically does this for files that are 2 weeks old. Garbage collection can also be disabled by using the configuration value gc.auto:

$ git config --global gc.auto 0

To do garbage collections manually you could use:

$ git gc

More information on this can be found on git-gc manual page.

Setting up an infinote server with PAM

maato@softwarebakery.com (Maato) — Tue, 12 Jul 2011 22:42:00 +0200

Gobby is a multi-user text editor. It allows editing text files by multiple persons, while all of them can see and edit in real-time. It is a great tool for online collaboration, like making todos or even coding a program collaboratively.

Gobby connects to an infinote server. The server keeps track of the different users and documents.

On Ubuntu 10.04 infinoted 0.4.1-1 is already in the repository and it is easy to set up. However, such a setup does not include username and password authentication, an automatic startup using a init-script and a separate user under which the process should run. Authentication using PAM, and thus username and password, is only available since 0.5.0.

This post contains all of the steps required to run infinoted 0.5.0 on Ubuntu 10.04. This includes compiling, creating the user, init-script and configuration necessary to run infinoted in a proper way.

Compiling infinoted with PAM support

Since PAM is an optional dependency for infinoted you should make sure that libpam-dev is installed before compiling. The configure script does not provide you with any notification of its absence (this will be fixed in a later version). You should also make sure libdaemon-dev is installed, otherwise the initscript will not work properly. After that, compilation is rather straightforward:

$ apt-get install libxml2-dev gnutls-dev libgsasl7-dev libglib2.0-dev libpam-dev libdaemon-dev
$ wget http://releases.0x539.de/libinfinity/libinfinity-0.5.0.tar.gz
$ tar xfvz libinfinity-0.5.0.tar.gz
$ cd libinfinity-0.5.0
$ ./configure --prefix=/usr
$ make
$ make install

If you are on Ubuntu and want to make a deb package, you can replace the last command (make install) by checkinstall and answer the questions that follow. Make sure you install checkinstall first:

$ apt-get install checkinstall

When you've created the package, you can install it using:

$ dpkg -i infinoted-0.5.0-1.deb

Configuring infinoted

We'll run the server as a seperate (less privileged) user instead of as root, so we start by creating a new user. The user's home directory will be /var/infinote.

$ useradd --home-dir /var/infinote --user-group --shell /bin/false infinote

Before we can start the server we have to create a home directory, a place to store the documents and its configuration. The server looks for the configuration file $HOME/.config/infinoted.conf. We create the directories and set the appropriate permissions on them using the following commands:

$ mkdir /var/infinote/{,root,sync,.config}
$ touch /var/infinote/.config/infinoted.conf
$ chown -R infinote: /var/infinote
$ chmod -R 0700 /var/infinote
$ chmod 0600 /var/infinote/.config/infinoted.conf

Now we can fill infinoted.conf with the following configuration:

/var/infinote/.config/infinoted.conf

[infinoted]
security-policy=require-tls
root-directory=/var/infinote/root/
certificate-file=/var/infinote/cert.pem
key-file=/var/infinote/key.pem
sync-directory=/var/infinote/sync/
sync-interval=60
pam-service=infinote

Generating a certificate

You might have noticed a reference to the cert.pem and key.pem files. These allow the connection to be encrypted. We haven't created them yet, so we'll do that now. The creation of the certificate requires quite a lot of entropy. If your machine runs out of entropy this can make the entire process take a very long time. To solve this you could try to generate more entropy by moving your mouse or typing on the keyboard. On a server which has no such peripherals this will obviously not work, so you might have to create the certificate somewhere else and copy it over to the server. Another thing to look out for is the fact that the certificate (cert.pem) will be bound to a domain name. This is determined by the hostname of the computer generating the certificate, so you might have to change it temporarily.

$ hostname your_temporary_hostname # optional, don't forget to restore afterwards
$ cd /var/infinote
$ sudo -u infinote infinoted-0.5 -k key.pem -c cert.pem --create-key --create-certificate
$ chown 0600 key.pem cert.pem

Authentication using PAM

The documentation of infinoted shows the option to setup PAM but gives no hints on how to do it. There are multiple ways to setup PAM authentication with infinoted. We chose to use the pam_pwdfile authentication module. This allows you to define users and passwords in a flat text file, so that you do not need to create full system users for them. So you need to apt-get install libpam-pwdfile. Since all users that are in this file are solely created for use with infinote we will use the module pam_permit to forgo account management.

We start by creating a new PAM service in the /etc/pam.d/ directory called infinote and use the following as its contents:

/etc/pam.d/infinote

#%PAM-1.0
auth      required    pam_pwdfile.so pwdfile /etc/infinoted.passwd
account   required    pam_permit.so

Now we have to create the file that defines users and their passwords, we have chose to place it at /etc/infinoted.passwd. The file should contain username:password_hash pairs. The password hashes can be generated using any of the following commands:

$ openssl passwd -1 <password>
$ openssl passwd -crypt <password>
$ htpasswd -nbd <username> <password>

Note that both of the available hashing methods are rather weak, so don't count on these hashes to provide you with any security. After having created the hashes for your passwords, your password file should look something like this:

/etc/infinoted.passwd

maato:$1$yII45doY$ZSH/biluHy12zp9KOuEQ9/
frozencow:SiN2d/00c/ubI

Creating an init script

To automatically (and easily) start and stop the infinote daemon, we will need an init-script. We placed the code below in /etc/init.d/infinoted. Make sure to also run chmod +x /etc/init.d/infinoted.

/etc/init.d/infinoted

#! /bin/sh
### BEGIN INIT INFO
# Provides:          infinoted
# Required-Start:    $local_fs $remote_fs $network $syslog
# Required-Stop:     $local_fs $remote_fs $network $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: starts infinoted
# Description:       starts infinoted using start-stop-daemon
### END INIT INFO

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/bin/infinoted-0.5
USER=infinote
NAME=infinoted
PIDFILE=/var/infinote/.infinoted/infinoted-0.5.pid
DESC="Infinote Daemon"

test -x $DAEMON || exit 0

if [ -f /etc/default/infinoted ] ; then
        . /etc/default/infinoted
fi

set -e

. /lib/lsb/init-functions

# Function that starts the daemon
d_start() {
        log_daemon_msg "Starting $DESC" "$NAME"
        start-stop-daemon --quiet -c $USER -p $PIDFILE -x $DAEMON --start -- -d
        log_end_msg $?
}

# Function that stops the daemon
d_stop() {
        log_daemon_msg "Stopping $DESC" "$NAME"
        start-stop-daemon --quiet -c $USER -p $PIDFILE -x $DAEMON --stop -- -D
        log_end_msg $?
}

case "$1" in
  start)
        d_start
        ;;
  stop)
        d_stop
        ;;
  restart)
        log_daemon_msg "Restarting $DESC" "$NAME"
        d_stop || true
        sleep 1
        d_start
        log_daemon_msg "Done"
        ;;
  status)
        status_of_proc -p $PIDFILE "$DAEMON" infinoted && exit 0 || exit $?
        ;;
  *)
        log_daemon_msg "Usage: $NAME {start|stop|restart|status}" >&2
        exit 1
        ;;
esac

exit 0

Additional information

pam-pwdfile README

Wii Device Library v1.2 released

frozencow@gmail.com (FrozenCow) — Sat, 02 May 2009 00:00:00 +0200

Here is another release of Wii Device Library. This version fixes even more bugs and adds some more stablity. The major changes:

Balanceboards are now also supported under Windows.
All stacks are more stable (*).
Fixed support for Bluez v3.2.1 on x64 machines.
Fixed some issues for the Windows and Linux GUIs.

(*) You can now (un)plug your bluetooth dongle when running without problems.

You can get the full changelog at Google Code.

The download is available at the project page

Wii Device Library v1.1 released

frozencow@gmail.com (FrozenCow) — Sun, 19 Apr 2009 00:00:00 +0200

We have finally found the time and resources to release a new version of Wii Device Library. This version fixes a lot of the reported bugs and more. Here is a short list of the changes in this version:

Connecting using BlueZ has improved.
Connecting using MsBluetooth has become more stable and faster.
Fixed freeze when connecting to a Wiimote with plugged extension under Windows.
Fixed incorrect behaviour with multiple Wiimotes under Windows.
Fixed a rare bug that occured on some Vista machines.

Several other fixes and changes have been made. You can get the full changelog at Google Code.

The download is available at the project page.

Wii Device Library released

frozencow@gmail.com (FrozenCow) — Mon, 22 Dec 2008 23:00:00 +0100

After working on Wii Device Library on and off for several months we have decided to release our work to the public. This is not the first project we have worked on together, but it is the first project we have actually decided to release. Because of this we wanted to do it right, so we came up with a couple of requirements for the release of the library. In this post we will describe what decisions we made to share this knowledge with others and for ourselfs to look back upon.

Project hosting

As it’s likely we want to release more of our projects in the future, it will be helpful to have a centralized place where we can publish all these projects. That’s why we first started looking into project hosting websites such as SourceForge, Google Code and others. We felt that the projects we would be hosting there would be unrelated to each other and we wanted more control over our content. So, we wanted our own website. But since we were taking as long as we did to publish one project, we also wanted to start as soon as possible with the content. Developing our own website would take too much time. That’s why we chose a CMS, which in our case is WordPress. We chose WordPress because we could test it out on WordPress.com. There we found that it was possible to not only blog, but also create pages. And since we didn’t want to spend a lot of time making a theme, we could easily choose our theme from different theme-galleries. From here, things finally started to get rolling. We quickly found a good webhost and registered our domainname. Here we set up our own WordPress site, added a few plugins and we were ready for the next step.

Version control

We wanted our code to be easily accessable to everyone. For this we wanted a svn repository and an one-click download system. Choosing which svn repository to use was hard at first. There were tons of providers for this, all with different features. We thought about what features we really needed, in the end we just wanted an easily accessable code repository. We have also considered different version control systems. Subversion was more widely used than some of the others (Cvs, SourceSafe and Bazaar), so that was in line with our requirement of keeping everything easily accessable to everyone. Google Code gave us a Subversion repository, was fast and it also allowed people to browse the code online, which was just what we needed.

Download package

The repository was finished, but we still needed a download package, which included the binaries, sourcecode and examples, that had to be a breeze to find, download and extract. For this we have put a large download-button on the project page where a zip file can be downloaded. Other archive formats aren’t that well supported accros platforms, so zip was the only right format for this. We chose to not use external download systems, because this required more searching for mirrors that would like to host our files. Handling our own downloads would result in a fast and reliable user-experience. We only need to be aware of our monthly usage.

Examples

We wanted to make it easy to get started with the library. We found in other libraries and frameworks that the examples are a major factor in choosing the library or not. So we thought about what examples we needed to include. We divided the library in different ascpects. For each aspect we created an example that could be used as a program on its own. This makes it very easy to look into one aspect of the library without getting confused by the previous or next examples.

Go check out the Wii Device Library, and let us know what you think.