Oh, and a nice seat, and you get another HID to use for moving around. This is using the upcoming 0.1.0 release of libsixdof which has wiimote support. Note that you can also use the spacenavigator true 6dof device. If you are using the later then you'll need evdev 2.1.0 or later, and if you're using 2.1.0 see this bug for a patch to get more than X and Y axis working.
More information to follow, including a video and details on the space navigator and GE.
libsixdof and a wiimote to control Google Earth under Linux from Ben Martin on Vimeo.
Tuesday, January 13, 2009
Saturday, January 10, 2009
Chinook vs Diablo
While most folks have upgraded to Diablo long, long ago, I fell into the trap of actually using the n810 early on. So I had a nice chinook setup and didn't really want to do the Wintel mantra of reinstalling just to get diablo. But now I've been playing with both, with two n810 devices, because its always more fun with two ;)
So one is running the Chinook from about Feb 2008 and the other RX-44_DIABLO_5.2008.43-7. I thought that wifi felt faster on Diablo, so I did a little measuring. Its quite slap happy but does show some considerable difference, using the same DLink DIR-855 AP for both devices.
On the server:
dd if=/dev/zero of=10mb bs=1024 count=10240
On the tablet:
time wget -Y off http://x/10mb
The results:
chinook:
real 0m29.301s
user 0m1.047s
sys 0m1.828s
350k/s
diablo:
real 0m24.815s
user 0m0.656s
sys 0m1.188s
546k/s
The chinook k/s is quite stable at around 350. On diablo things move around quite a bit in terms of speed. Perhaps this bursty nature works well for browsing making things 'feel' faster too.
So one is running the Chinook from about Feb 2008 and the other RX-44_DIABLO_5.2008.43-7. I thought that wifi felt faster on Diablo, so I did a little measuring. Its quite slap happy but does show some considerable difference, using the same DLink DIR-855 AP for both devices.
On the server:
dd if=/dev/zero of=10mb bs=1024 count=10240
On the tablet:
time wget -Y off http://x/10mb
The results:
chinook:
real 0m29.301s
user 0m1.047s
sys 0m1.828s
350k/s
diablo:
real 0m24.815s
user 0m0.656s
sys 0m1.188s
546k/s
The chinook k/s is quite stable at around 350. On diablo things move around quite a bit in terms of speed. Perhaps this bursty nature works well for browsing making things 'feel' faster too.
Monday, December 15, 2008
Welcome to the libferris screencast on copy append.
1) I start a copy from the command line.
2) I decide I want to copy another file to the same place.
For example to the same USB stick.
3) In the old days, I would have to start a parallel copy
or wait for the first copy to finish before copying
the second file.
4) Now, with libferris, I can just append it to the existing copy task for this destination.
1) I start a copy from the command line.
2) I decide I want to copy another file to the same place.
For example to the same USB stick.
3) In the old days, I would have to start a parallel copy
or wait for the first copy to finish before copying
the second file.
4) Now, with libferris, I can just append it to the existing copy task for this destination.
Unfortunately the video quality is not so good in the final web version. Still some fun and games to be had getting things up to scratch.
Untitled from Ben Martin on Vimeo.
Wednesday, December 10, 2008
Automounting for the People
Now that the bad pun in the title has been read, you can't unread it!
So, now libferris has some closer HAL integration. Of course, some might say right away that ferris has been able to mount dbus for ages, so why have an explicit hal:// filesystem. The reason is that the fdo methods in the raw dbus interface for HAL are very coarse, and by explicitly having a hal:// and a volume manager daemon you get some interesting possibilities.
When the daemon can't work out what to do, it runs a nice little wizard:
One you choose how to identify the volume, you can tell libferris what to do:
More actions will arrive in time. I particularly like the auto copy mode, if a usb stick is readable at 20mb/s, a local scratch RAID-10 at 200Mb/s it makes sense to start moving the data to the scratch RAID right away and then pick it apart from there rather than from the USB stick directly.
So, now libferris has some closer HAL integration. Of course, some might say right away that ferris has been able to mount dbus for ages, so why have an explicit hal:// filesystem. The reason is that the fdo methods in the raw dbus interface for HAL are very coarse, and by explicitly having a hal:// and a volume manager daemon you get some interesting possibilities.
When the daemon can't work out what to do, it runs a nice little wizard:
One you choose how to identify the volume, you can tell libferris what to do:
More actions will arrive in time. I particularly like the auto copy mode, if a usb stick is readable at 20mb/s, a local scratch RAID-10 at 200Mb/s it makes sense to start moving the data to the scratch RAID right away and then pick it apart from there rather than from the USB stick directly.
Tuesday, November 18, 2008
Libferris summer hackfest
OK, so I now officially have one participant in the libferris summer hackfest! If you've been looking to help out a crazy filesystem project but hesitant as to who to approach, look no further... ;)
But seriously, if you have been using libferris and always wanted it to do X as well then now is a great time to help make it happen. Of course you could send patches, but you might be better off just buying some time and now is a great time to do the latter. And so ends the plugfest.
But seriously, if you have been using libferris and always wanted it to do X as well then now is a great time to help make it happen. Of course you could send patches, but you might be better off just buying some time and now is a great time to do the latter. And so ends the plugfest.
Saturday, October 25, 2008
Unfsck your redland RDF.
Again, for those who are using the unpatched db4 redland backend, if you get issues where libferris apps just eat CPU and seem to hang, if your backtrace includes Ferris::RDF::RedlandIterator::__advance() calling librdf_iterator_next() then there is a fair chance your RDF db4 files are screwed. You can try to recover them with the below.... sorry about the long standing issue folks.
#!/bin/bash
cd ~/.ferris/rdfdb
for if in myrdf-po2s.db myrdf-so2p.db myrdf-sp2o.db
do
echo "Fixing: $if"
db_dump -r $if >| dump
rm -f $if
db_load -f dump $if
rm -f dump
done
#!/bin/bash
cd ~/.ferris/rdfdb
for if in myrdf-po2s.db myrdf-so2p.db myrdf-sp2o.db
do
echo "Fixing: $if"
db_dump -r $if >| dump
rm -f $if
db_load -f dump $if
rm -f dump
done
Sunday, September 14, 2008
No n810 is an island
Ch, Ch, Ch, Ch, Changes.
Yes, maemo has had rsync for ages. Yes, rsync makes dumping stuff to the device really easy. Trouble is, when you are travelling around for a while, and when you have a little keyboard you tend to update some of those files.
Assuming the OOM (Only One Me) rule, Unison is a great tool to make the n810 much less of a data island and more of an extension of the desktop.
Check out my repository for the debs. You'll need to install gcc and binutils, complements of the way ocaml is currently built. So thats another 15mb of downloads or 40mb of card space you'll loose. The gcc thing should be able to be worked around to make a leaner install, but I wanted unison for use before the maemo summit. Kind of handy to sync stuff over and know you can edit it with the device. Of course you could always rsync from the device when you get home again, but unison is just a nicer bidirectional solution.
Yes, maemo has had rsync for ages. Yes, rsync makes dumping stuff to the device really easy. Trouble is, when you are travelling around for a while, and when you have a little keyboard you tend to update some of those files.
Assuming the OOM (Only One Me) rule, Unison is a great tool to make the n810 much less of a data island and more of an extension of the desktop.
Check out my repository for the debs. You'll need to install gcc and binutils, complements of the way ocaml is currently built. So thats another 15mb of downloads or 40mb of card space you'll loose. The gcc thing should be able to be worked around to make a leaner install, but I wanted unison for use before the maemo summit. Kind of handy to sync stuff over and know you can edit it with the device. Of course you could always rsync from the device when you get home again, but unison is just a nicer bidirectional solution.
Subscribe to:
Posts (Atom)