Short Tip: replace characters in txt files with sed

When working with txt files or with the shell in general it is sometimes necessary to replace certain chars in existing files. In that cases sed can come in handy:

sed -i 's/foo/bar/g' FILENAME

The -i option makes sure that the changes are saved in the new file – in case you are not sure that sed will work as you expect it you should use it without the option but provide an output filename. The s is for search, the foo is the pattern you are searching the file for, bar is the replacement string and the g flag makes sure that all hits on each line are replaced, not just the first one.
If you have to replace special characters like a dot or a comma, they have to be entered with a backslash to make clear that you mean the chars, not some control command:

sed -i 's/./,/g' *txt

Sed should be available on every standard installation of any distribution. At lesat on Fedora it is even required by core system parts like udev.

Short Tip: Mount directories via SSH

Other computers are often accessed via ssh. That is very easy and comes along with a lot of possibilities. However, working on files which are saved on the server is not that simple all the time. KDE offers the fish:// KIO for these cases, but this just works for KDE apps, and has to be called for each app individually.

In such cases it makes more sense to actually mount the server directories locally: sshfs let you mount any given server directory locally. And since it works on top of FUSE it does not require root interaction at all (given that the local user is a member of the fuse group).

All you have to do is:

sshfs -o idmap=user 192.168.0.1:/data ~/sshDir

The idmap=user option translates the server side uid to the client side uid and is therefore an often used and also needed option to avoid permission problems.

Of course the given directories have to exist on the used machines. Also, as already mentioned, make sure that the user who tries to use sshfs is a member of the fuse group! Last but not least the server must have a running ssh server, and the program sshfs has to be installed on the client machine. On Fedora, the package is called fuse-sshfs and is part of the main repositories. I guess it is similar on the other, bigger distributions as well.

Since every sshfs directory is a regular fuse directory, the umount is done via:

fusermount -u ~/sshDir

This can even be embedded into /etc/fstab and also understands typical ssh configuration options like other ports or the very handy key authorization.

Ktorrent 3.0 – hello, KDE 4 [Update]

Ktorrent released the new version, Ktorrent 3.0. The biggest change is that it is now based on KDE 4, and with a bit of luck, Fedora 9 will be shipped with that KDE 4 version.

With Ktorrent one of the largest external KDE projects now released a first stable KDE 4 version of their product. This also shows that KDE 4 is also accepted by external developers.

Besides the obvious port to KDE 4 and the integration with KDE 4 services Ktorrent now builds with the help of cmake. Featurewise the main news are that Ktorrent is now ipv6 ready, supports SOCKS v4 and v5 and can even be bound to a specific network interface. Smaller changes and features include:

• Added time estimation algorithm selection
• Added option to disable data checking during uploading
• Added possibility to open multiple torrents in one go (they will be opened silently)
• Added option to do a data check when a torrent is finished
• Added new missing files dialog with quit button
• Added support for hostnames in PeerManager::addPotentialPeer
• Use a toolbar in the search plugin instead of a widget
• Show files which a chunk belongs to in chunks tab
• Add alternative fileview mode (flat list)
• Added feature to move inidividual files of a torrent

Since Fedora 9 will ship KDE 4 I will try to come up with a Ktorrent 3 package for that release. At the moment there are still some problems with Fedora’s build system but I’m confident that it will be sorted out in the end.
I could also submit a Fedora 8 update to ktorrent 3.0 since Fedora 8 comes along with the necessary kde4 base packages. And it indeed works! However, that is not really necessary and I think people who want to run KDE 4 apps should go with Fedora 9 anyway.

Update:
The Ktorrent packages are built now, everything worked out fine. They should appear in rawhide soon.If you can’t wait that long, grab them from koji.

KDE development now based on Qt 4.4

The Qt snapshot in the KDE development tree was update to Qt 4.4 pre-Beta some hours ago. Qt 4.4 dependent features can now be included into KDE’s main tree.

The update of qt-copy was long expected: Qt 4.4 comes along with a rich set of new features: Widgets in QGraphicsView, WebKit integration, Phonon integration, etc. Several KDE projects waited for this inclusion for quite some time now.

The project with the largest needs of Qt 4.4 is probably Plasma: with Widgets on QGraphicsView the Plasma team will finally be able to integrate QWidgets into Plasma applets, so future Plasma applets will be able to contain QWidgets like QComboBoxes or like the new QWebKit. This will enable to put party of “real” programs into Plasma applets. Or, to say it with Aaron Seigo’s words:

it allows us to more or less freely mix qwidgets and pure canvas content

This will enable an entire range of new possiblities for Plasma applets because suddenly several new widgets are available. And since these widgets are well known to the KDE developers it is likely that they will quickly take advantage of these, blurring the border between traditional applications and Plasma applets even more.
Also, applications using Plasma will take advantage of this as well. Amarok already showed a first screenshot of how it uses the new possibilities.

Besides this new widget possibilities and the mentioned Phonon and WebKit integration Qt 4.4 will also fix performance problems during resize and also fix a bug which crashed Krita – at least I was told so

liquidat_afk: there is an other cool stuff with Qt4.4, it fixes an annoying crash in Krita

VirtualBox for OpenSolaris hosts available – FreeBSD soon? [Update]

Innotek today announced the first Beta version of their well known virtual machine VirtualBox for OpenSolaris. It is also possible that a FreeBSD version will be available soon.

The announcement can be found in the news section, however there are no further details available than the simple announcement itself:

Feb 11, 2008. innotek today released the first beta of VirtualBox for OpenSolaris.

Neither the Press section nor the Forum have any additional information, and there is also no screenshot provided this time. Heck, there isn’t even anything mentioned at the e-mail lists or at the changelog. But of course a prebuild package (tagged beta 1) is available, and there are also build instructions for the more experienced users.

Sigh, as much as I love the product, as much do I wonder about their news politics. They should definitely put a little more effort into their public relations – or at least provide some press material for the interested users and bloggers to create some PR for them. And they shoudl rework the wiki in a way that the interesting information are presented to the reader, and don’t have to be searched.
Anyway, searching around around the project web page for more information also brought me to a chart comparing VirtualBox to both VMware and Parallels Workstation/Desktop in regards to the features. The list is pretty interesting and shows very well that VirtualBox supports more host systems than the other solutions. Several other features are also unique to VirtualBox or at least are only shared by one of the other solutions (also it is questionable if these features are needed by others). Other features which are not supported by VirtualBox like “3D-acceleration” are also listed.

Last but not least the list mentions a development version of VirtualBox for FreeBSD hosts. Since VirtualBox is now supported on Mac OS X, Solaris and Linux the porting effort should be manageable. It is likely that there will be soon a new VirtualBox release (1.6 or something) for all major platforms (Linux, Mac OS X and Windows) while the Solaris version and a then released FreeBSD version are available as Beta until their reach the feature level of the main versions.
Now the only thing missing is that the VirtualBox kernel module gets into the Linux mainline kernel, that would give VirtualBox another boost, I think.

Update:
Sun just bought Innotek. The announcement says Sun will continue to publish VirtualBox as an Open Source product. That might even mean that future versions of VirtualBox are fully Open Source, including the atm still closed parts as some USB enhancements and RDP features. Anyway, looks like all big companies are on a shopping spree these days.