OK, so I spent some fun time playing around with my 5g video iPod — time for more serious action now.
I have created two patches today which add support for the video iPod to gtkpod, a GTK+ based, platform independent GUI for Apple's iPod.
These initial patches allow you to sync m4v video files to your iPod and watch them there. I will add support for all other video formats which work on the iPod, soon. The patches will be sent to the gtkpod maintainers, of course, in the hope that they can be included in the next release.
Note: This is pre-alpha, barely-tested code! Use at your own risk!
mount -t vfat /dev/sda2 /mnt/ipod
/mnt/ipodis the default).
umount /mnt/ipod), disconnect the USB cable.
I get a "Destroying mmap buffer" error every time I sync the iPod, but that's probably a gtkpod bug, and it's non-fatal anyways.
If you happen to own a video iPod, please test the patches and report whether they work! Thanks!
Update 2005-11-19: The libgpod patch is in CVS now (plus a bug which caused MP3s to appear in the "Movies" list is fixed now, too). So you don't need the libgpod patch anymore! I have updated the gtkpod patch (Update: patch no longer needed.), you should now be able to sync almost any video format (m4v, mp4, mpg, mpeg, avi, mov) to your video iPod.
Update 2005-11-24: The current libgpod/gtkpod CVS now contains all the features of my patches, so they are obsolete from now on.
For those who don't yet know what I'm talking about:
Gobby is a free collaborative editor based on libobby, a library which provides synced document buffers. It supports multiple documents in one session and a multi-user chat. It runs on Microsoft Windows, Mac OS X, Linux and other Unix-like platforms.
apt-get install gobby later, I was astounded as to how mature it already feels. I think Gobby will be of great benefit when taking notes during conferences, talks and so on. It could also prove invaluable as a pair programming tool.
Anyways, I already hear you crying "but SubEthaEdit has been doing this for ages", which is true. But:
There you have it.
(via Daniel Stone)
It's late at night, so what else could I do than watch the stars? Of course, as I am such a
moron geek, I don't just look out of the window — I use GPL'd software to watch the stars.
apt-get install stellarium
Just to prove the world I'm doing Debian work sometimes: I have recently updated the flobopuyo package (needed rebuild because of the C++ transition), the bfbtester package (hey, it took me only three attempts until I f*cking figured out why I couldn't change the section), and cccd (cosmetic stuff).
Nothing to see here, move on.
A while ago I wanted to enlarge my
/home partition (hda6), as it was getting full. After that partition I had another (unused) one, which I intended to merge with hda6 and thereby increase the amount of free disk space on
Here's parts of the disk layout:
hda6 Logical Linux ext3 30848.00
hda7 Logical Linux ext3 8848.00
So, merging hda7 into hda6 should be as simple as removing hda7, and then resizing hda6 to swallow up the 8 gig from the former hda7. Basically, that's how it worked, but I had a few problems. First, at that time is seemed impossible to simply resize ext3 partitions. Neither ext2resize, nor QtParted, nor parted worked for me for some reasons (maybe that has changed recently).
After some googling I finally found a way to do it (which I'll document here, maybe it'll be helpful for others):
fsckon both, hda6 and hda7 (optional?)
# tune2fs -O^has_journal /dev/hda6
parted. The xxxx is the original start of hda6 (you may not change that) and yyyy is the end of the disk:
(parted) resize 6 xxxxx yyyyy
tune2fs -j /dev/hda6
But this didn't work from the beginning either — for some strage reason parted didn't believe me that the space after hda6 was free. It did display it as free space, but the "resize" operation complained.
So what I did was this (instead af the above step 3):
parted, and remove hda7 again from within parted(!):
(parted) rm 7
parted didn't like the way
cfdisk removed the hda7 partition... very strange...