Chatonka

My original reason for working on a replacement for TimeVault was due to me feeling that its core method of taking snapshots using directories and hard linking files was not scalable because of the lack of hard linking directories on ext3 and other file systems. If you have large amounts of directories (for example in source trees or in my own documents hierarchy) each backup takes a non-trivial amount of space just to recreate the directories.

The beauty of starting from scratch means that I can make any of the design decisions without carrying extra baggage from before. This lead to the rewrite existing in KDE4/Qt4/C++ using some of the KDE frameworks such as solid.

I’m still subscribed to some bugs from the old TimeVault and after I had responded to one person asking for a status on TimeVault I thought I should share it with others as well.

If you feel comfortable working with a non-released branch my timevault-external branch has basic support for external devices. I haven’t messed with any of the actual backup code so it shouldn’t mess with your data at all, but I can’t guarantee that. There is more information at the branch https://code.launchpad.net/~astromme/timevault/timevault-external .

Secondly, I have been working on a different backup program that originally had some of the same goals as timevault but has now deviated quite a bit. I have some preliminary work up at https://launchpad.net/timevaultng but nothing close to usable by what I would consider the ‘target’ audience.

With luck, I’ll have more time to work on my next gen concept of timevault more in the coming weeks.

At the moment, I would suggest one of two things.
A: Use the released version of TimeVault if you like the concept of ‘always backing up’. As long as you stop the timevault daemon while your drive is unplugged you should be fine.

B: Learn rdiff-backup and put it in a simple script. That is what I am doing for the time being as it is really flexible. It is also what I am building timevaultng around so you will have a head start on the concepts that will be useful.

Hopefully that clarifies the situation somewhat.

Of all of the areas of computing, I’m most interested in user interaction and user interfaces. Although I can program, I care less about the code (Maybe that’s why so few of my projects make it to fruition!) and more about the design and interface. I’ve been working on a personal backup utility in some of my spare time and while this is generally an area that has very little interface to it I found that the design process of even this little app was extremely interesting.

I needed a small preferences interface to let the user choose things such as the destination drive for storing backups, the frequncy of backups, and how long backups were kept. The following image was my first iteration of the preferences window.

If you use KDE4 you might have noticed that the drives view in the window is taken from the “recent devices” plasmoid. I decided that it was a familiar (to KDE4 users) and good way to show devices. When hovered over, the subtext is not “Open with Dolphin” but rather “Use as backup device”.

As cool as the widget is, there were still some flaws with this preferences window. First of all, I needed a separate check box to say whether or not backups were to be taken at all. Additionally, the user only had a choice of Daily, Monthly, Weekly, etc… and not intermediate specifications such as “Every Monday” or “On the 4th day of the month”. And to top it off, there was no way to specify how long to keep backups for. From these problems the second iteration was developed.

This revision keeps the device selection widget (I really like it), but removes the unnecessary text on the left. Additionally, it adds two sliders at the bottom to specify how long to save backups for and how frequently to take them. But this has its flaws, as there is no feedback to the user for how long backups are actually saved for nor how often they are taken. It’s just an abstract “somewhere on this slider”. So, with feedback in mind, the third iteration was created.

I am mostly happy with this last window. There are tick marks on each slider differentiating between major points (I.E. less than a day, less than a week, less than a year, and less than a decade). Additionally, if you move the slider all the way to the right you get “Forever” which is great way to not have to add an additional checkbox that disables truncating backups. The same logic is applied to the Backup Frequency, which allows specification for sometime within each hour, each day, each week, each month, each year or never. Again, we are spared the expense of an extra check box by having the maximum value on the right be “Never”.

The work needed to create this (relatively simple) preferences dialog is fairly significant and definitely not to be forgotten. It can make the difference between having an app that is simple and clean or an app that is cluttered and unusable.

If you feel like following the progress of TimeVault, it is hosted on launchpad at https://code.launchpad.net/~astromme/timevault/timevault-kde4

Success! The backend has changed quite a bit in 2.7 but there shouldn’t be too many differences in the blog (or feed) appearance. Now it’s time to work on KDE 4.2 beta1. There are packages in intrepid-backports that I’m itching to try.

I’m working on a fairly complex lab for an engineering class. My writeup for this lab includes diagrams, figure captions, equations, references, headers, and some crazy tables. All of this has been created in Word 2007 on the XP machines in the engineering computer labs. However, I needed to make some calculations dependent on the data in my writeup and the only machine I had access to was my laptop, which runs Kubuntu 8.10 with OO.o 3.0. So, I figured I should give it a try.

Boy am I impressed. Not only did open office open the docx correctly, along with all of the special formatting, it also did so directly from the samba share that holds the files.

Chalk one up for open source =).

As part of my quest for a quieter desktop, I replaced my old NVidia 6600GT with a shiny new fanless AMD 3450HD card. I had heard good things about AMD graphics working well in KDE4, even with desktop effects and I was interested in having a card that (in the far future it seems) will eventually work with the opensource radeonhd drivers.

In the meantime, it seems that I’m still stuck using the binary-only fglrx driver. And up until a few minutes ago, I was having all sorts of trouble with it. Once I was into a desktop session things were fine, but getting from a computer that was powered off to a working X session was absolutely horrendous. A normal boot would never work, and some magic combination (which I have yet to narrow down precisely) of using the “xfix” option in the recovery menu, copying over old xorg.conf files and restarting the xserver in all manners of ways would sometimes let me see the login screen at the correct resolution.

Finally, I was completely frustrated with fglrx and decided to drop down to 2d only with the current radeonhd drivers (that supposedly work for my 3450HD). Upon trying to install xserver-xorg-video-radeonhd, I discovered that it was already installed. I’m not sure if this is a part of the default Intrepid install or if I installed it and forgot about it, but I decided to just change my driver line in xorg.conf from “fglrx” to “radeonhd” to see what happens. Much to my surprise I got the same black screen as I normally did. Out of curiosity, I decided to remove the radeonhd driver, in case it was conflicting with the fglrx driver, causing my headaches.

I removed the driver, reset the xorg.conf and rebooted. Lo and behold, X11 started up cleanly. I guess all of my problems were related to some sort of conflict with the radeonhd driver and the fglrx driver, even though the latter was the only one listed in the configuration file.

Update: A few days later, everything is still working perfectly.

I’ve always wanted to add a handwriting component to some of the more interesting note-keeping apps in KDE, such as BasKet. I wonder if having a KPart (like marble does) that let you (as a developer) easily add annotation support would be useful. Not that I know much about creating a KPart yet, but I think that it would fit very nicely with the concept of KDE4

I haven’t had much luck with hard drives in the past few weeks. After having a 500gb drive die on me while I was in Norway, I now have a computer that loves to spontaneously reboot whenever I write to 30% of an IDE drive.

I first noticed the latter problem when I was investigating a software based RAID1 (mirrored) solution. Originally the raid was successfully created and I was able to transfer 80GB (These are 120GB drives, so well over 50% of the drive) of data over. Then I wanted to simulate device failure and raid1 rebuilding.

mdadm --fail /dev/sdb1
mdadm --remove /dev/sdb1

Then, /proc/mdstat showed a degraded RAID1 array (as it should),

md0 : active raid1 sdc1[0]
117242240 blocks [2/1] [U_]

Then I tried to re-add the device,

mdadm /dev/md0 --add /dev/sdb1

Checking /proc/mdstat again showed linux happily rebuilding the raid. I come back after 20 minutes to check /proc/mdstat only to find that the computer has restarted itself in the mean time and the raid didn’t get rebuilt.

So, I try again, wondering what could be the matter, this time watching /proc/mdstat. At 30-some% suddenly I get a beep, some sort of ata error (it flashes by for less than a second) and the computer promptly restarts itself.

Great, I think, do I have a bad drive? Better to find out now rather than after storing crucial data on it (and spending the time to get it all set up). Out of curiosity, I reformat the drive as ext3 and write to the blocks (from the filesystem rather than on a device level):

dd if=/dev/zero of=/mnt/sdb1

When I return in an hour, this has completed successfully. Quite odd. I forget about the raid array and am busy with other work for a few days.

Yesterday, I returned to the test computer to investigate rdiff-backup as a backup solution. (Note: I really like the idea of rdiff-backup, and I’m inclined to write a kio-slave for it to be used for recovery easily from kde) I start the rdiff-backup of the 80GB of data and let it run overnight. This morning I find out that it rebooted itself less than 30 minutes after I started the backup, at least according to uptime. I then realize that I’m using the flaky drive/ide chipset/whatever is the matter that I had RAID problems with earlier.

My next line of work is to remove the drive (IDE), put in a 250GB (SATA) and try the same thing. I have a worrying feeling that it’s the chipset. The source drive for this backup is on SATA and the destination was on IDE. This caused reboots for both a raid setup and a rdiff-backup setup. However, using the same drive with dd and /dev/zero did NOT cause a reboot. Also, I can read the data from the SATA drive just fine. (Or can I? I should try a cp /data /dev/null).

(Friday, May 15 17:17) Resting, Hungry

I’m back home now after visiting Trolltech. Wow, what a day. First was the sculpture garden. There was a marching band there and many Norwegian families - when I asked Kristin later she said that it was a trial run for tomorrow’s parade! It seemed to go quite well when I was there, and I did get some good video of it, so hopefully I will be able to show that when I get home. The batteries I bought yesterday didn’t work. Now, they weren’t the most powerful, so shame on me for not being careful of what I buy. But anyways, I still have hope for the rechargeables. After reading online that sometimes the Nickel-Cadmium ones take a few cycles to get to their full capacity, I discharged the batteries completely last night to see if that helps. They’re currently charging again. Trolltech, wow, I think that deserves its own paragraph.

So, I took the local transportation, specifically the subway and bus, around today. It was only about 4 stops from Myuerstrauen (Ok, I botched that spelling, I’ll get my little packet later), the stop for the sculpture garden. The building was this gigantic complex called BI, which housed the Norwegian School of Management. Trolltech was located on the 6th floor of just one of the 4 quadrants of this building. At first the secretary wasn’t aware of my visit, in hindsight I should have brought the most recent email with my contact’s name instead of the one two messages back (the older one had the address and directions on it). Anyways, I brought up gmail on her computer and it all went smoothly from there. Trenton, also from Minnesota, was my ‘guide’. We started out by eating lunch, and I was lucky, this was the one day of the week where they had a cooked ‘hot’ lunch instead of the traditional sandwiches from home meal. I met 5 or 6 other devs at lunch. Two were from Norway, 2 from the US and 2 from other places in Europe (Finland and Germany?). All spoke English. I actually think that almost all of the interactions that I saw took place in English. I guess that makes sense, because in the global market that is almost always what companies need to use. Anyways, Trenton showed me around after lunch. It turns out that he works on the Mac side of things. I had read that Trolltech was porting Qt to Cocoa (from Carbon), and he confirmed that he was one of the main ones working on that. There were two people to an office in the programming side. I thought this was interesting (more on that later if I have time). We visited some guys working on embedded devices (very cool) and a whole bunch of themed (and named with company core values) office/conference rooms. The office was actually two floors, one above and one below. Although below is a bit of a misstatement, as it was still on floor 5. Trenton showed me their bug tracking system (wow, great for collaboration) and discussed a few of the internal ideas about revision control. (Turns out that Git and Mercurial are dueling it out). At the end of my visit, we went and met the main apparel lady. Oh wow. I now have not only a T-Shirt but also a laptop bag, lanyard, and even a Trolltech branded combo USB Hub/Coffee cup warmer! Crazy stuff.

As many from Planet KDE have done, here is my bash history, sorted:

astromme@Loki:~$ history|awk ‘{a[$2]++ } END{for(i in a){print a[i] ” ” i}}’|sort -rn|head
79 ls
76 cd
53 sudo
40 exit
27 ssh
19 make
17 git
12 ping
11 scp
11 mv

Very interesting. The sudos are mostly for aptitutde I think, either that or editing files. ls/cd because I like navigating directory by directory. I ssh to servers quite often (Dagr, iServer, BlueServer, wServer, Thor). Exit is an interesting one. I guess that my history doesn’t get saved like it should be, mainly because I use a lot of tabs in konsole. I was testing out git recently, I actually don’t use it. I’ve been having troubles with my mediacom internet, hence the ping. Scp and move… well I guess I like to move things around. And make, of course =).

I first started using kdesvn-build to get a trunk build of kde4 back in mid-November. Just to give you an idea of how far we’ve come, back then we still had no artwork for the panel (It was that ugly gradient), konqueror didn’t work with cookies, things crashed hourly and I had to regularly remove my ~/.kde4 because of kwin and other configuration issues. However, I never removed the installed /opt/qt4 and /opt/kde4 directories, instead having kdesvn-build overwrite newly updated files upon each build. While this worked, I noticed that my system had been getting progressively slower and slower. After it broke completely, I reinstalled with Kubuntu Hardy (I think it was about alpha 2 then, more on that in another post) and tried the newly released kde 4.0.0 packages.

That was a mistake.

Many things were broken, such as my icons, and I was already missing the improvements to trunk since the tagging of kde 4.0.0 over a week before. So, back to kdesvn-build. However, I STILL kept my /opt/ directory and hence, I was re-introduced to the slowness. Today I decided to do something about it. I completely removed my build directories and my /opt/, and for a few hours I recompiled everything from scratch. All I can say is that the speed difference is unbelievable! Starting with a fresh everything, kde4 loaded (after a reboot, so nothing was cached) in roughly 2 seconds. Windows open instantly instead of with a noticeable delay, and konqueror is lightning fast. I highly suggest that anyone else who has let cruft build up in their /opt/kde4 directory do the same. If you plan to, make sure you’re either logged out of kde4 and in a text console or logged into the “failsafe” option with kdm/gdm. Then, remove your /opt/kde4 and build away!

- Hmm, it looks like my spellchecking isn’t working. Sorry for any blatant misspellings.

Edit: Ok, I wonder why aspell got uninstalled. Crazy hardy breakage? Possibly. Spelling should be better now! And, ouch, I’m a terrible speller.