find . -depth -print0 | cpio --null --sparse -pvd /new/directoryThat's it. A 1:1 copy of your filesystem hierarchy is deposited in the new directory. It saved my day.
reviews, tips and tricks, opinions about open and less open technology
find . -depth -print0 | cpio --null --sparse -pvd /new/directoryThat's it. A 1:1 copy of your filesystem hierarchy is deposited in the new directory. It saved my day.
Posted by m. s. at 12:25 0 comments
Labels: copy, filesystem, linux, partitions, shell, unix
Posted by m. s. at 18:06 0 comments
Labels: multimedia, open source, standards, web
Posted by m. s. at 13:08 7 comments
Posted by m. s. at 12:24 4 comments
Sorry for the long delay, but this little script is not dead. chm2pdf
0.0.3 is out: now with image support! (Intra-pdf links still dead, anyway. But I had suggestions on how to solve them.)
Download it here.
The script logic changed quite a lot, and it is still very rough
around the edges (0.1 is still -relatively- far). I'd like everyone of
you to test it as much as possible, since it is very likely that bugs
and quirks will occur. My knowledge of the CHM file format is
tentative at best.
Posted by m. s. at 18:33 4 comments
Posted by m. s. at 11:00 1 comments
Labels: chm2pdf, open source, pdf
Posted by m. s. at 00:07 0 comments
Labels: chm, chm2pdf, open source, pdf
Posted by m. s. at 15:58 0 comments
Ok, this is not my work. But it deserves to be shared. Here is an OSNews comment about GPL vs BSD :
If you want to give your software away for free, use BSD. If you want to share your software, use the GPL.
Software under the GPL is not free. Microsoft office is not free, you have to pay Microsoft money. The Borland developer tools are not free, you have to pay Borland (or whatever they're called these days).
Lastly, software released under the GPL is not free: if you choose to copy and paste GPL code into your own program you have to share it. This is how you pay for GPL code. This is a very egalitarian idea: I share my code, and if you use it in your own program, you pay me back by sharing your code or else you ask me to relicense the code under a different license to suit your needs (which was always possible).
To make sure no-one can escape sharing (after all, this is how they're paying to use the software), GPL v3 requires the following
(a) You make the source code available
(b) You don't use patents to prevent people from using your code, which would effectively block code-sharing despite (a)
(c) You don't use DRM to prevent people from using your code, which would effectively block code-sharing, like (a)
The GPL is no more viral than any commercial license, the only difference is in how you pay to use the software. And it's always worth remembering that you don't have to share until you distribute the source-code (and as corporations are legal entities, you can give a copy to all your 1000-odd co-workers without legally distributing it). It's further worth remembering that if this is a problem, you can always ask the original author to re-license their work under a commercial license if you would rather not share.
This GPL is viral/evil/not-as-cool-as-BSD thing is rubbish. It does what it sets out to do: encourage people to share code. There's no excuse for "accidentally" using GPL code in your own software, just as there's no excuse for "accidentally" installing a pirated copy of MS Office on your friends PC. Both place value on software, and if you choose to use it in a certain way, then you have to pay for them: the only difference is in how you pay.
From Bryan Freeney.
Just an additional opinion: A lot of people bash GNU GPL because they feel it's too much restrictive. Disliking the actual concept of copyright, I feel sympathetic about them. However, what they often fail to grasp is that GPL is a licence made to mimick, in the copyright world, what would be a copyleft world. It is surely paradoxical the fact that the GPLv3 restrictions mean more freedom, but it's true, if you count the other's freedom as much as your one.
I prefer Kubuntu over Ubuntu, because I just love KDE, while I can't stand the "dumb-it-down-at-all-costs" philosophy of Gnome. Nonetheless, I use a lot of GTK/Gnome apps in my desktop, and two I can't live without are the Mozilla's Firefox and Thunderbird.
However, Kubuntu sets Konqueror as the default browser. Not a wise choice IMHO (Konqueror is good but not as good as Firefox for a browser; it kicks ass as a file manager, by the way) but that's it. This means that when you click an URL in Thunderbird, it will open Konqueror. And there is no obvious setting to change it.
You have two strategies to let Mozilla Thunderbird play nice with Firefox under Kubuntu/KDE. The first -and more drastic, since it changes global settings- is to change your default browser to Firefox. To do that (straight from the Mozilla Zine:
* Open kcontrol (KDE configuration center).
* Go to "Components -> Components chooser -> Web browser".
* Check "The following browser", and type in "firefox" ("mozilla" for Mozilla).
If you don't notice the "Web browser" component:
* Go to "Components -> File association -> text -> html".
* Select "Add..." under "Application Preference Order".
* Write the command firefox %U (mozilla %U for Mozilla) and select OK. You need "%U" so you can load URLs that are non-local files.
Alternatively, you can change the setting only for Thunderbird. This is a bit more obscure, but even faster to do:
* Close Thunderbird.
* Find your Thunderbird prefs.js file -from the Linux shell, try using locate prefs.js | grep thunderbird
.
* Edit the prefs.js, adding the following line at the bottom:user_pref("network.protocol-handler.app.http", "/usr/bin/firefox");
* Reopen Thunderbird, et voilà it should work.
Posted by m. s. at 17:23 2 comments
Labels: firefox, thunderbird
Posted by m. s. at 17:00 9 comments
I've never been a lot into gaming, so the relative lack of good Linux games never bothered me much. The only game I really loved was Civilization, and Freeciv is, for me, a perfect replacement for it. Sport games were usually the ones I disliked more. Nevertheless I remember myself playing a game called "Soccer Manager" on a DOS box when I was 10-12 years old. I enjoyed it, since it was a purely micromanagement thing. In that game you played the character of a football manager that decides the team formation, sells and buys players looking at their age and skills, maintains the stadium etc. You don't actively play football, like in "Sensible Soccer": you manage the football team.
It came to me as a nice surprise when I only recently discovered Bygfoot, a free soccer management game, was available on Linux. I decided to give it a spin and come back to my childhood memories.
Bygfoot is actively maintained and has recently hit release 2.1, with new features added at each release. It is based on the GTK toolkit. You can find precompiled packages for Bygfoot for Windows as well for most Linux distributions and there are official FreeBSD ports. The game has one playing as a manager of a football team, training the players, buying and selling them, contracting loans, maintaining the stadium, and so on. Teams can be promoted or relegated, and a player can be fired if their skills are not up to scratch.
I played some days with Bygfoot and my reactions are mixed. There is a lot of positive to say. The GUI is overall very well thought, elegant and simple; anyone that already played a soccer manager should master most basic game's controls in less than half an hour. I've tested versions from 1.8 to 2.1 on different machines and I'm pleased with the visible fast progress of development, both in terms of functionality and user interface. The number of teams available is enormous, thanks to many contributors, albeit the names are not 100% real due to "copyright problems" (I don't really understand that one, since it baffles my mind on how someone can have copyright on the names of players in a soccer team, but so says Wikipedia). The latest versions of the game are quite stable (the 1.9.2 version available on Ubuntu Dapper had a horrible memory leak, however) and at a casual look seem quite bug-free and fast.
On the other hand, the gaming experience is nice but not impressive. It must be said that Bygfoot is eerily addictive, at least at the beginning, and the game is well thought up to be both playable and challenging at first. However the game itself becomes repetitive too rapidly. There are not that much options to gain money apart from improving the stadium and waiting for people to come in or selling your players. Exchanging players with other teams, as far as I've seen, is not possible (if I'm wrong, tell me please!). The idea of the "Youth academy" is nice, but players coming from there take an excruciatingly long time to improve their skills as to be significant players. The recent addition of betting is nice but doesn't really spice up the game. More often than not the game is a repetitive "play match-play match-play match-substitute injured player-play match" with little or no user interaction.
Overall, Bygfoot is a good free soccer manager makes for a fun and well done casual game to play here and there, let's say, in breaks at work. However it is still not at the point to be a real challenge to spend your night with.
You probably already know that to navigate forward and backward in time your command line history, you use arrows. Arrow up: previous command. Arrow down: next command. What if you have to navigate more?
For example, suppose you yesterday looked at a text file. You don't remember its name, but you know you used "cat" to see it. And now you want to see it again. Normally you should have to (a)use the up arrow a lot until you meet the command you wanted or (b)use some trick like cat ~/.bash_history | grep cat
and then copy-and-paste the right command.
Good, but it could be better. The science package Matlab for example has a nifty feature that allows you to search in your Matlab command line intelligently, autocompleting the first characters you have typed with matching lines of your command line history. This means that you type "cat" on your command line, by using the up and down arrows you navigate only the history of commands beginning with "cat". A kind of interactive grep on the go. Nice, isn't it?
For some reason this really useful feature is not enabled by default on most Unix distributions I am aware of, but it is really easy to activate it on Bash. Look for a file called .inputrc
in your home directory. If you haven't it, look for /etc/inputrc
instead (you of course have to be root to edit this one). Open it with your favourite text editor and look for these lines:
"\e[5~": beginning-of-history
"\e[6~": end-of-history
Comment them with a "#" character in front of them:
#"\e[5~": beginning-of-history
#"\e[6~": end-of-history
Insert these lines below the ones you just commented:
"\e[5~": history-search-backward
"\e[6~": history-search-forward
Save and exit. To make the changes have effect you probably have to login again. Now pressing Page-Up and Page-Down should autocomplete the first characters you type with the corresponding commands in the history. Once you get accustomed to this feature, you'll never want to come back.
Posted by m. s. at 22:59 4 comments
Labels: autocomplete, bash, history, matlab
Browsing the Gentoo forums I stumbled on an odd problem with one of these "easy-but-who-the-hell-would-have-thought-of-this" nasty solutions.
Symptoms: You connect a USB hardware (e.g. an USB scanner) and nothing happens. It seems it is not recognized. But you know that your scanner/printer/whatever works and it should work with Linux! (This often happens with SiS motherboards)
Solution: Check you have OHCI/UHCI support enabled. If not, enable it. Try modprobe ohci-hcd
and/or modprobe uhci-hcd
as root. If even this doesn't work, chances are you compiled your kernel by yourself (most distros should include OHCI): check in your kernel config you have OHCI enabled.
Rationale: The problem is that a USB 2.0 controller card is often coupled to OHCI (or sometimes UHCI) controllers, to deal with low or full speed devices, while the EHCI controller keeps the high speed devices for himself. The hardware switches controllers depending on the attached device. So if you only have EHCI drivers and your scanner switches to the OHCI/UHCI controller, there won't be a driver for that controller -and therefore, your PC cannot communicate with what's attached there. You can read the full explanation here, look for "USB 1.1. "Companion Controllers"".
Twitter is among the last fads of social networking. For whose of you that don't know, Twitter is something in between a blog and an IM. It leaves you post a brief, SMS-like message (maximum 150 characters) that your Twitter friends can almost instantaneously read. Twitter is the place for every small idea, activity, thought you would like somehow to share, but that is not worth a blog post and you don't want to engage in a direct conversation about. It can be labeled among the best ways Internet has to distract you and make you absolutely non productive, but it is admittedly fun and somehow addictive.
Twitter has a relatively nice web interface, but it is often best used with a dedicated client. This is usually a small application, more like a desklet or widget, that periodically reads new "tweets" from your friends and allows you to instantaneously post a new one when you urge to. The most popular Twitter client is the Mac OS X Twitterrific, and there are analogous clients for Windows.
GNU/Linux and other free systems until a few days ago had little choice. This was even stranger and sadder given how simple the Twitter API are. I was just pondering about writing a Twitter client when I see that the 0.1 version of gTwitter, the first free, Linux-friendly Twitter client I am aware of.
I immediately downloaded the source code tarball .tar.gz and tried it. gTwitter is written in C# with Mono, and needs a few dependencies (The latest GNOME development packages (gtk+-2.8), A full Mono Development stack (mono 1.1.x, gtk-sharp-2.0, etc.) and the Cairo graphics library (cairo 1.0.x) ). On my stable Gentoo Linux box it compiled extremly quickly and without a hitch with the usual source tarball procedure:
tar -xzvf gtwitter-0.1.tar.gz
cd gtwitter-0.1
./configure
make
make install
exit
and just type:gtwitter
I played with gTwitter on my Linux box a bit and, despite its alpha status (just version 0.1, folks!) it seems to be perfectly usable for the main basic tasks of Twitter: reading and posting "tweets". The application is very small and fast and starts fantastically quickly. The GUI is very clean, and borrows a bit from Twitterrific: despite being GTK/Gnome based, integrates quite well in my KDE desktop. If you wanna see it in action , you can see a gTwitter screencast here.
Of course, being a 0.1 release, it is still a bit rough around the edges. A notification area icon is, in my opinion, the first feature to implement, so that one can keep an eye on new tweets without having to open/activate gTwitter. A composite-enabled UI would be really cool, and the gTwitter author (Nil Gradisnik) tells on his blog that it is already in the works. Making the whole GUI smaller would also be nice, so to have gTwitter working effectively as a small, unobtrusive widget.
Anyhow, gTwitter is a little but well implemented and promising application for Linux and other free software users that engage in this social network. I would advice twitters to give it a try without hesitation, and keep a look on its developments.
Posted by m. s. at 19:44 4 comments
Do geeks keep fit? Well, if you are a self-trainer, or you simply like to keep fit, you may find a heart rate monitor useful. Personal heart rate monitors often are thought to output their data on a Windows machine. Can you keep fit on Linux?
The answer is: yes, but it's not that easy (but hey, mind exercise is still exercise!). In general, it seems the best supported heart rate monitors are the ones from Polar, so I will focus on that ones.
Polar Viewer is a Polar (and Ciclosport, actually) heart rate monitor application that has been now integrated into Sports Tracker from the version 2.0. It seems the best choice for heart rate monitoring on Linux: it supports a quite wide range of Polar models, is integrated in a self-training application, it's currently updated and looks polished. As the Sports Tracker page says, "you can easily create diagrams and statistics for specific time ranges and sport types." and, if you feel coding, "all the application data is stored in XML files. So it should be easy to access it with other tools or to write importers and exporters for other applications.". Note: it depends on Mono. Another GTK application similar to Polar Viewer is Polar Scope.
On the KDE side of things, I found a small application, KPersonalTrainer, that can help you sync with your Polar monitor. According to the description:
. Unfortunately, the last update is of more than a year ago, but I guess you can poke the developer if you need an update.
KPersonalTrainer was developed to keep track of data collected by a heart rate monitor like the Polar Watches, or just any other watch.
When you have added an exercise information is saved in a file and presented in a table. A calender is shown to give you an overview of the finished exercises.
KPersonalTrainer also has an option, Weekly Reports, where you can keep track of your progress.
This first version of the program has all the basic functions, and more advanced functions are planned for future releases, for example show diagrams of different data.
I found other attempts at using Polar heart rate monitors under Linux. They seem to be decidedly more hackish, but may be nonetheless interesting. A program to decode the sound data recorded by Polar S410 has been written: however keep in mind that it is a .tar.gz that needs to be compiled by hand and comes from the 2004. A Linux software for the Polar s710 that works via the serial IR interface exists and is updated. The author of this program also owns the (admittedly not so crowded) polar-linux forum.
Last but not least: if you are really into the geeky thing, why don't you build a Linux-based heart rate monitor yourself? You only need a Linux PC, a soundcard and some circuit bending skills. Circuit schematics are ready for you to download, software is provided. Happy hacking.
Posted by m. s. at 23:09 4 comments
Labels: heart rate monitor, linux, polar
If you have plenty of RAM memory, it may be useful to create a temporary RAM disk to use for fast file read-write of an application. Often guides tell you how to create an initial ram disk for the Linux boot, but what about building a ramdisk for everyday use?
It's matter of just four commands. First, create the device:mknod -m 660 /dev/ram b 1 1
Then, give the dimension you want to the new ramdisk, let's say, 4k. You do it by filling it with the right amount of zeroes:dd if=/dev/zero of=/dev/ram bs=1k count=4k
Then it's just matter of creating your mountpoint:mkdir /mnt/ramdisk
and mounting it as an ext2:mount -t ext2 /dev/ram /mnt/ramdisk
That's it.
Posted by m. s. at 17:37 1 comments
Sometimes it just happens. You do something bad with, let's say, the glibc, and suddenly you discover your command line is unusable. Even simple commands like "ls" die with a segmentation fault or similar errors. Nothing works. More often than not, chrooting won't help. Everyone would panic, unless you know you have a lifesaver: a statically linked BusyBox.
This little free software miracle contains stripped down but fully usable versions of many common UNIX utilities into a single small executable. A command line in a box. Its supported commands (actual support depends on compile configuration) include:
[, [[, addgroup, adduser, adjtimex, ar, arping, ash, awk,
basename, bbconfig, bunzip2, busybox, bzcat, cal, cat, catv,
chattr, chgrp, chmod, chown, chroot, chvt, cksum, clear, cmp,
comm, cp, cpio, crond, crontab, cut, date, dc, dd, deallocvt,
delgroup, deluser, devfsd, df, diff, dirname, dmesg, dnsd,
dos2unix, dpkg, dpkg_deb, du, dumpkmap, dumpleases, e2fsck, echo,
ed, eject, env, ether_wake, expr, fakeidentd, false, fbset,
fdflush, fdformat, fdisk, find, fold, free, freeramdisk, fsck,
fsck_minix, ftpget, ftpput, fuser, getopt, getty, grep, gunzip,
gzip, halt, hdparm, head, hexdump, hostid, hostname, httpd,
hwclock, id, ifconfig, ifdown, ifup, inetd, init, insmod,
install, ip, ipaddr, ipcalc, ipcrm, ipcs, iplink, iproute,
iptunnel, kill, killall, klogd, lash, last, length, less, ln,
loadfont, loadkmap, logger, login, logname, logread, losetup, ls,
lsattr, lsmod, lzmacat, makedevs, md5sum, mdev, mesg, mkdir,
mke2fs, mkfifo, mkfs_minix, mknod, mkswap, mktemp, modprobe,
more, mount, mountpoint, mt, mv, nameif, nc, netstat, nice,
nohup, nslookup, od, openvt, passwd, patch, pidof, ping, ping6,
pivot_root, poweroff, printenv, printf, ps, pwd, rdate, readlink,
readprofile, realpath, reboot, renice, reset, rm, rmdir, rmmod,
route, rpm, rpm2cpio, run_parts, runlevel, rx, sed, seq, setarch,
setconsole, setkeycodes, setlogcons, setsid, sha1sum, sleep,
sort, start_stop_daemon, stat, strings, stty, su, sulogin, sum,
swapoff, swapon, switch_root, sync, sysctl, syslogd, tail, tar,
tee, telnet, telnetd, test, tftp, time, top, touch, tr,
traceroute, true, tty, tune2fs, udhcpc, udhcpd, umount, uname,
uncompress, uniq, unix2dos, unlzma, unzip, uptime, usleep,
uudecode, uuencode, vconfig, vi, vlock, watch, watchdog, wc,
wget, which, who, whoami, xargs, yes, zcat, zcip
Quite impressive, isn't it? You can call busybox in various ways. The simplest is calling busybox directly with the wanted command as an argument:
busybox ls /
for example. But you can also enter a busybox shell by typing:
busybox sh
This starts a barebones shell that gives you access to all busybox commands, and allows you to have a working command line (On Gentoo Linux, you can have the same by calling /bin/bb, that is called the "rescue shell" in the docs). Another possibility is to symlink commands to the busybox binary. So, if /bin/ls is a symlink pointing to busybox, busybox will know the symlink called and execute ls. This of course has little sense when rescuing a system, but it is often used when busybox is the actual shell of an embedded or very lightweight Linux system.
Having a static busybox (static is important: you want it to be resilient to borked libraries) installed could make the difference between crying in front of a dead Linux that needs to be reinstalled and being able to grin while telling again the geeky story about how you happily rescued your system. Install it now, before it's too late.
Posted by m. s. at 23:57 0 comments
Sometimes you need to merge PDF files made by someone else in a single file together. Your Windows or Mac user fellows will do probably by using Adobe Acrobat or the like. On Linux you don't need the Adobe software (although you can have it if you like). You can do it by the command line -it's Linux after all, isn't it?
The first method is by using convert , directly from the ImageMagick toolkit. You probably already have this one installed on your favourite Linux distribution; if not, almost every known Linux distribution has a package for it. Even if you don't need to edit PDF files you should have it, it is a wonderful swiss army knife for command line image processing. The syntax for merging PDF files is simple:
convert file1.pdf file2.pdf file3.pdf out.pdf
(that is, the last file name is the output file name). This usually works quite correctly, but 1)it is slow 2)I found sometimes has issues with image resolution. So I looked for another solution, and I found pdftk. The name stands for "PDF ToolKit", and really it is. It is a free (open source under the GNU GPL), wonderful command line utility that with a bit of magic allows you to manage PDF files from the command line. It works on Linux, Windows and Mac. pdftk can merge PDF documents, split PDF pages into a new document, rotate PDF Pages or Documents, decrypt and encrypt, fill PDF forms, apply a background watermark or a foreground stamp, burst a PDF Document into single pages... whatever.
The syntax for merging with pdftk is almost as simple:
pdftk file1.pdf file2.pdf file3.pdf cat output out.pdf
You just need to add the magic "cat output" between the input pdfs and the output file name. In comparison with convert, it is truly fast and in my experience gives better results. And it may come handy for when I have to work with PDF files in other ways. Also, KDE users may find nice PDF Concat, a Kommander script that acts as a simple pdftk frontend to merge PDFs.
Posted by m. s. at 15:10 16 comments
Labels: imagemagick, linux, pdf, pdftk