A few days ago I dreamed about flying a space ship. Now I've found it's actually possible thanks to the Vega Strike game. Although Vega Strike doesn't run on my computer very well and I don't have time to actually play it, it's nice to see another high quality Free Software project.
It's amazing how difficult it is to find a good web server other than Apache. I tried to find any web server which is regularly maintained, provides basic functionality (serving static pages, CGI scripts with arguments in the form of path, providing index files and virtual servers), actually works, is sufficiently documented, performs reasonable logging and is not too complex. thttpd, bozohttpd, Boa, Cherokee, Yaws, Twisted, Roxen, AOL, Portable AllegroServe all failed this criteria.
Finding working weblogging software which doesn't use an SQL engine for storing its data and is well configurable may not be easy too. If you use Debian and try Pyblosxom, don't use its sarge version suffering from a bug preventing it to run with some web servers, use the version from unstable.
So this site runs on Portable AllegroServe now. The main problem with AllegroServe was it couldn't run CGI scripts on SBCL, but I succeeded in porting the corresponding code. It's not ready for submitting a patch, but if you're interested in it, tell me.
I've chosen Portable AllegroServe because it's highly and easily configurable and written in Common Lisp (with no UFFI involved) so it's easy to hack it when needed.
There's an interesting project for us running their weblogs on Lisp servers. Too bad I've got absolutely no time to contribute now. :-(
I write a small application which works with Festival speech synthesis system. As Festival modules I use are written in Scheme, I started to write the application in Common Lisp and McCLIM. But I had to step back from this decision soon. McCLIM is an excellent GUI toolkit, but it lacks support for Czech, which is absolutely required by my application. As there is no real maintainer of McCLIM and the team of occasional contributors is generally not responsive even when you try to make patches, I didn't want to risk blockers in the later stages of my project.
I moved to Guile and guile-gnome. That seemed to be a natural choice, GTK+ is a proven and stable platform and despite I missed McCLIM high-level functions I hoped to benefit from the implementation of the whole project in Scheme. But it occurred again that using foreign bindings is painful. guile-gnome platform is basically undocumented and based on a foreign bindings generator which is hard to understand and without proper documentation too. After several battles with guile-gnome I had to give up and rewrite the UI part to C (the rest remains written in Guile).
The plain C GTK+ UI works now. Well, the basic UI concepts of GTK+ look like ten years behind CLIM 2.0 (i.e. somewhere around 1980), programming in GTK+ is no way comfortable and the thousands of low-level functions are far from elegance. But what is more important is that GTK+ works and is properly documented. You spend predictable amount of time on low-level coding instead of completely unpredictable amount of time on reading and fixing toolkit source code.
Several latest versions of Konqueror use to crash, usually about once or twice a week. This is not something I'm able to fix easily and as I got sufficiently annoyed (including some missing features such as inability to block popups or to show page source in a sane way) I decided to move to another browser.
There is hardly any real alternative other than Firefox. So I switched to Firefox 1.5. The result? Firefox has crashed three times during the first day of its use…
I've been using Ekiga (formerly Gnomemeeting) for several years. Among free software phones it was exceptionally stable and well usable since about its 1.0 version. But it supported only the H.323 protocol which became a big problem during the time. H.323 is usually not supported by VoIP providers, it is poorly supported by the Asterisk PBX and generally it has no future. That forced me to use the development branch of Ekiga which contains SIP support.
A development version is naturally not a stable version. Ekiga snapshots suffered from occasional freezes, automatic deregistrations and other problems. I'm tired from all the problems related to Internet telephony, so I looked for a well working free software phone with SIP or IAX support. That was not easy, most of the phones are not well usable.
I've recently switched to Twinkle. It is stable and provides additional nice features not present in Ekiga, such as two phone lines, better user interface, user script invocation on incoming calls or logging SIP messages. A very important advantage of Twinkle over Ekiga is that calls are much less jitter-prone when something runs on the computer. The only Twinkle drawback I've met so far is that it is a Qt application which means it doesn't work very well with a systray when using Sawfish.
My long term observation about GNOME and KDE is that GNOME is stronger in desktop, while KDE is stronger in applications. One of the excellent KDE applications is digiKam.
The most popular free image processing tool, GIMP, hasn't succeeded to become a tool for serious work. Its lack of important features (such as 16-bit color support) and poor user interface make it suitable just for occasional use and perhaps for web designers. Lack of free usable photo processing and management tools has motivated me to develop my own photo processing program as a part of my Springtail Lisp tools. But due to lack of time and zero support from McCLIM developers Springtail didn't provide completely satisfying results.
About a year ago I discovered digiKam. After trying it I've abandoned the Springtail photo application development immediately. Not that digiKam offered all the features present in Springtail and everything I needed, but it provided interesting features, good user interface and was well maintained. It was clear to me that this may be the right tool and it made no sense to invest my effort into development of my own tool instead of helping a promising project.
I can say that digiKam fulfills my expectations and I recommend it to photo enthusiasts who look for a good photo editing and management tool. It can't do everything and there are many features that could be improved, but this is up to us – we can file bug reports, vote for bugs and make patches. I believe this project is well maintained and it's worth to help it.
With the increasing complexity of modern user interfaces the number of annoying bugs grows. What is worse, number of long standing unfixed annoying bugs grows. The overall number of bugs grows and I'm able to do something only with a small part of them. Complex user interfaces have been being released without coming through a serious testing process (a typical example is GNOME).
One way how to handle this situation is to move from the complex user interfaces that don't work to simpler ones that do. I've recently switched from Sawfish and GNOME panel to Ratpoison and XFCE panel and I've been happy with the change so far. Ratpoison is, together with Stumpwm and Ion, a very simple window manager – no window buttons, no borders, no workspaces, no systray, no customization dialogs, no mouse support. Instead you receive a window manager that works, can be easily and completely operated from a keyboard, utilizes maximum of your screen space and is well customizable. I was surprised how little of the complex functionality of other window managers I actually need. Ratpoison seems to offer all I need and to be more comfortable for me than classic window managers.
At the same time I switched from Firefox to Conkeror. The primary reason was that I got annoyed by being unable to reasonably operate Firefox from keyboard. Conkeror is similar to the window managers mentioned above (no wonder – Ratpoison, Stumpwm and Conkeror were written by the same author). There are no toolbars, menus and other decorations, it can be operated from keyboard and it uses Emacs concepts (interactive commands invoked by M-x, buffers, mode line, minibuffer, echo area). Unlike Ratpoison, Conkeror has not been feature complete yet but it's possible to invoke the standard Firefox interface from it in case you need it. Additionally Conkeror is just another user interface to the web browser and as such it can't fix Firefox fatal bugs (such as crashes or freezes on certain pages). Anyway, I like it and I don't miss the standard Firefox interface often.
Well, here is a screenshot of my current desktop, do you like it? :-)
Scanning software should deliver maximum information in the best possible form. It's not necessary to avoid further processing, but it's important to keep it possible and to perform processing steps that can be made automatically without losing important information. Choosing right scanning tools is important as mistakes in this process may result in the necessity of repeated scanning and processing. How is it with scanning negative films on Epson Perfection 2480 Photo?
The original Epson scanning software on Windows usually produces good results, but one must be careful to actually receive them. Obvious selections are setting colors to 48-bit (or 16-bit in case of bw negatives) and resolution to
that in my experience actually doesn't remove any dust but removes many details instead (this is a pure software algorithm, the hardware doesn't support any dust removal features). Note that unsharp masking has to be disabled for each scanned film field individually. When you forget it, you receive bad results when you try to apply unsharp masking later yourself. Usually the software produces good colors (better than I'm able to get from the negative by other means now) although manual corrections are often necessary during post-processing, as is common with color negatives. It happened to me once with a few strongly overexposed film fields that the software has chosen very aggressive color clipping and I had to adjust histogram settings and rescan the given fields again. The Epson software requires a lot of mouse clicks (on average more than 2 for each scanned field) and suffers from memory leaks, requiring occasional restarts.
On Linux the scanning process is more challenging. The SANE driver supports all the crucial hardware features and scanning half a film strip requires just a single scanner button press (when you use scanbuttond) and no mouse clicks. But here is a small 1:1 sample of what you receive (contrast is much increased in all the examples to demonstrate the problems more clearly):
Note two things:
As for the special ugly stripe, it helps turning quality settings off (i.e. removing the '–high-quality=yes –quality-cal=yes' scanimage command line options). I guess their meaning is reversed in the driver by mistake. So here is new result:
The extra stripe is gone, but the regular stripe pattern is still there. I've no idea why it's there but I've seen something similar in the samples from other scanners on the net so it's likely to be some common hardware feature. FWIW, scanning direction is vertical here. No such apparent stripes are present when the same image is scanned with the Epson software on Windows:
So I tried to get rid of the stripes by averaging each two neighboring stripes into a new "neutral" stripe. This operation shouldn't lower resolution of the image, it may just soften it (and the actual scanner resolution doesn't correspond to the scanned image size anyway). So it should be safe. Here is what I received after applying the following imagemagick commands:
convert -crop 199x158+0+0 image.png crop1.png convert -crop 199x158+1+0 image.png crop2.png composite -blend 50% crop1.png crop2.png result.png
I think the result is pretty close (except for contrast adjustments) to what Epson software produces, so it's probably the way to go.
All the things presented here may look clear and simple. But it took me long time coming from the first naive scanning attempts to discovering why the scanned images don't look well and finally finding out all what's described above. Now I know supporting a piece of hardware doesn't mean just providing raw low-level drivers to the hardware. The hardware specific post-processing part is also very important and the user may receive poor results if this part is missing.
Well, I switch the revision control system I use for the third time during last years.
When I decided to try something else than CVS, I started with GNU arch. This was a good choice as GNU arch made a good basis of modern free software revision control systems. Unfortunately problems in GNU arch development and its split into unconvincing forks and replacements forced me to look elsewhere.
There were several reasonable choices among distributed revision control systems: darcs, Mercurial and git. I switched to darcs as it looked simple, user friendly and was popular among Lisp programmers. Indeed, as long as darcs is used for a single line development (as is typical with Lisp projects because they usually don't require much development power) it works very well. I was very satisfied with it until I have been hit by the infamous darcs performance problem. This is a fatal drawback preventing use of the revision control system at all in certain situations. So I had to switch to another system once again.
The remaining choices were Mercurial and git. I decided to go git as it looked more reliable to me (something used for Linux kernel development is unlikely to be seriously buggy or suffering from performance problems, isn't it) and provided "native" tools for cooperation with CVS (this is important to me as I usually work on projects with upstream CVS repositories).
I've been using git for several months now and I'm satisfied with it. From the user's point of view it's somewhat ugly and unfriendly, but one can live with it using a few external tools such as Emacs and qgit. More important is that the underlying concepts look right. Also the git CVS cooperation tools work better than tailor that the other systems use. I think git future is promising, git seems to be well founded, with stable development and growing user base (I know I'm not the only one migrating through the systems as described above and being now a git user). Perhaps git is the future leading free revision control system and I won't have to migrate again in the next years.
We have moved from qmail to Exim recently on our company mail server. It is a big relief. The mail server can handle the high amount of incoming junk mail now, it is reasonably manageable and provides readable logs.
It was late transfer. It is not easy to move a mail server to a completely different software and it happened only after more significant qmail problems than just a weird licensing conditions arose. But the important question is: What are the lessons?
Many years ago I was enthusiastic about qmail myself. In comparison to its common alternatives of the time, Sendmail and Smail, qmail was innovative and elegant. I only became a bit reserved about it when Debian Free Software Guidelines explicitly excluded qmail from Debian (there is a special item in the document inspired directly by qmail licensing problems) and djb (the qmail author) became well known for his poor communication style. The time has proved these issues were important and I stopped using qmail on my machines. Now, many years later when qmail is semi-dead and we can look backwards, I can identify three major lessons from the qmail rise and fall.
The first lesson: Beware of non-free software of any kind. Although qmail original license didn't prevent modifications and their distribution, it was restrictive enough to prevent unlimited spread of the software and it put obstacles to contributors and users. In the final result qmail was unable to adapt to new conditions appropriately, namely it is incapable to handle junk mail. Although djb put qmail to public domain recently, it was too late, as with many other pieces of dying non-free software (but it may be still better than to let the software die completely).
The second lesson: Software can't be completely separated from its author. If he is blinded by his pride, numerous problems can appear. For instance the semi-restrictive qmail licensing conditions served no good, they were designed just to satisfy author's ego. Completely ignoring compatibility with other similar software makes adoption of new ideas more difficult. Telling other people they are idiots (either explicitly or implicitly) discourages contributors, doesn't educate the users and builds a wall around the author preventing him from considering other opinions and correcting his wrong decisions. In the final result the software can't utilize its full possibilities and it degrades.
The third lesson: Security is a more complex concept than just avoiding privilege escalation and buffer overflows. Empty security advisory track may look nice but what is it good for when the mail server gets permanently irresponsive under junk mail floods, distributes junk mail itself through bounces and one has to apply third party patches not covered by the security warranty? In such a case the security statement is mostly just a blurb without connection to reality.
Why did I select Exim as the new MTA on our company server? Two mainstream good MTAs today are Exim and Postfix, they are mostly comparable and both the Exim and Postfix communities talk with respect about each other. So as a matter of personal preference I selected Exim which was already known to me.
I've recently experienced root file system loss. This happened after my keyboard had stopped functioning due to a hardware problem and I had turned off the computer by the power button. Apparently some random process had happened on the disk and while most data survived the file system as a whole was seriously damaged and the system was unusable after fsck fixes. Well, I should probably use the reset button next time and turn the power off only in the bootloader menu.
I had to reinstall the whole computer. As Debian 5.0 was released recently, it was a good opportunity to test its installation.
The most interesting experience was discovering how software is unstable today. I often use development versions of the operating system so I use to be tolerant to various small problems. But when I install a released system from scratch, I expect a completely smooth process. It wasn't so and Debian 5.0 is disappointing to me. I don't think other distributions work better but Debian used to have higher standards (and I would expect them after 7 months of freeze). While the installation process itself was completely fine, not all of the installed systems were ready to work well without fixes.
There are two kinds of problems: Debian problems and upstream problems. I experienced one Debian problem. It was that apt-proxy didn't work in the default setup. This seems to be a known bug (!), making a small change in one of the source files was needed. Apparently there was some lack of coordination between archive maintainers, installer maintainers, and apt-proxy maintainers. Considering the complexity of the current distributions one can understand it's difficult to make them completely flawless. But there seem to be problems in testing and paying appropriate attention to reported bugs.
Upstream problems are more frequent and more difficult to deal with. The current trend seems to be to fix bugs by releasing new upstream versions without proper attention to regressions. Similarly, it's much easier for a distribution package maintainer to package a new upstream version than to backport the bug fixes. The result is that old bugs get fixed, but new ones are introduced. Combined with the facts that it's often uneasy to reproduce and diagnose the reported bugs and that we are all busy, busy, busy today, there is no obvious way to handle the general software instability problem. Even when some bugs are known, there's not enough power to fix them and they tend to get ignored.
So should we simply learn to live with the fact that software features get more and more complex while their stability gets more and more reduced? Or is there a feasible way to get the growing software complexity managed?
I think there are things worth to try. More and better interaction between software developers and users is needed. We need to build better ways to prevent regressions, to reduce amount of hidden bugs, and to offer easy means to users to determine causes of problems. Instead of hurrying for new features we should focus more on making existing functionality actually work. This is what I demand from the software as a user.
Unfortunately the real world doesn't allow me to step into this area anytime soon. But if I ever have opportunity to work more on Debian, I'll probably start with joining the Debian QA efforts.
Thanks to GNUBridge I could play a few games of contract bridge last weekend, for the first time since my student years!
Do you know which PC chess playing engine became the second strongest one in the world after Rybka this year? It's Stockfish, a free chess engine distributed under the GNU General Public License.
It may look surprising that a hobby program with publicly available source code can beat all the proprietary engines with their secrets and hard working full-time developers. But it just proves that cooperation, open development, sharing (Stockfish developers make just the playing engine and don't have to care about user interfaces already provided by other programs) and making things for fun may lead to excellent results.
The Web is a common platform for many everyday activities today. But working with it is still often annoying, one reason being lack of a good end user client. We've got Emacs for text editing, organizing, communication, programming, file management, calculations, etc. But what do we have for browsing the Web? There is no usable web browser for Emacs and it's hard to find any usable web browser at all.
I've been using Conkeror web browser for several years. But Conkeror is limited by XULRunner and Gecko problems and although it was better than anything else I could find several years ago, it hasn't been comfortable enough for my needs recently. So I've looked for a possible alternative and discovered Uzbl.
I started to like Uzbl almost instantly. I switched to it completely within a few days. Uzbl is not perfect but it's still a great tool. What's so attractive about it?
The first thing is that Uzbl is based on WebKit, so the Gecko problems are gone (maybe just to become substituted by WebKit problems, but I enjoy the relief in the meantime). But the more important and more difficult to understand reason is the Uzbl philosophy. Uzbl doesn't offer much more than a rendering engine with some basic facilities and a simple and easy to use interface to the browser. When I need to make a minor customization of the browser user interface behavior I don't have to study JavaScript code and bindings while looking through tons of documentation and then to integrate my JavaScript code somewhere. I can simply add a single configuration line and write a shell script (or another kind of program) to implement the feature. All I need is using the simple text protocol and reading the mostly complete documentation consisting of only a few pages of plain text, complemented by looking at some examples. And I can change and debug my scripts separately, without touching or even restarting the browser.
This may not look that important at the first glance and it's, ehm, unusable for a common end user. But it is absolutely great for a programmer. I've already implemented some features for Uzbl that I haven't implemented for Conkeror for several years and that's convincing.
There is also an idea to embed Uzbl into Emacs. It's not currently possible without patching Emacs but once Emacs supports embedding other X applications into it, it should be possible to integrate web browsing facilities into Emacs by the means of Uzbl and thus making a really powerful web user interface.
I've never been successful in keeping really useful and up-to-date diaries and todo lists. Well, one can think: "If it's really important I won't forget about it and the other things don't matter much." But if nothing else then family life can cause semi-chaos making really difficult to get anything done. Nevertheless an important change has happened to me last year.
I used to use KDE PIM suite as my software organizer (indeed, there are some important things one can forget of). Last summer I had to upgrade my desktop and got exposed to the infamous KDE 4. I hadn't been very comfortable with KDE PIM before the upgrade and it got only worse afterwards. I think I needn't explain much, KDE PIM simply wasn't among the few excellent and already completely working KDE 4 applications (believe or not there are some).
By chance I met Emacs Org-mode at that time. This wasn't for the first time I've seen it. But previously either Org-mode wasn't mature or I didn't really understand its concepts (perhaps both). This time I found a mature product with interesting concepts and features. After some exploration I decided to move from KDE PIM to Org-mode.
What's so good about Org-mode? The basic idea of simplicity and flexibility. You can just write down anything that comes to your mind and put it into plain text files using simple markup. And then you can use available tools to manage all the information. Easy, isn't it? Actually it may not be that easy, it requires some mental change when abandoning GUI tools designed to drive you and moving to a plain text organizer designed to be driven by you. But once you get it you'll start to like it a lot.
You can simply start writing anything you want in your editor without having to use menu commands and to navigate through fields and buttons of predefined dialogs – you define how information is organized. You can keep related information in a single place – no need to split a journal entry containing a calendar item, a short todo list, a contact and some note into five different locations in five different applications. You can structure and organize your information as you like, it can be anything from a single big file to a directory tree containing many different files. In any case you can use the presentation tools to retrieve and combine required information. And you can customize it as you like, it's Emacs after all.
In the result KDE PIM wasn't the only set of applications I abandoned in favor of Org-mode. Think, you can put a lot of things into plain text files: notes, tasks, events, anniversaries, journal, bookmarks, passwords, contacts, vocabularies, clocking, documents, source code, commands, ideas, this blog entry, etc. There are many contributions to Org-mode, putting some kinds of specialized applications into obsolescense due to their limitations, low flexibility and lack of integration.
A very important part of Org-mode is its excellent documentation. When you've got a flexible software, good documentation is essential because the software is much about general concepts and personal preferences. It's interesting to see that e.g. KDE PIM pages present just feature lists and completely omit the important areas. Org-mode is equipped with a complete user manual, tutorials, presentations, FAQ and other documentation that help you learn how to manage things. It's software with intelligent community around it.
I can confirm the Org-mode way works. I was able to reasonably organize my things soon after I had begun to start using Org-mode and this is for the first time I'm able to keep my agenda in order. Org-mode has impressed me a lot. Not because it's perfect (it's not) or because of its feature set (it offers much more than I need while some things are missing), but because of its excellent concepts that solve the right problem, in a right way and for a useful purpose.
Well, this is not an introduction to Org-mode nor a feature overview. If you'd like to know what Org-mode actually is, look at Org-mode home page where you can find explanation of its concepts and everything else about it.
Until recently I was a relatively satisfied Linux VServer user. But when I upgraded to Debian 6 about half a year ago, OpenAFS aklog stopped to work inside the guests. There were always problems with running OpenAFS clients inside VServer guests but this time I couldn't find any workaround. I had to solve the problem and I had to act quickly.
As VServer didn't look useable anymore I decided to move to Linux Containers. It's a similar virtualization approach, implemented in a different way. I can't provide any expert comparison of the two solutions as I'm just a home user. Here are my simple observations.
Linux VServer is generally more mature product (no wonder, it has been around
for some years). It provides better management tools, including things like
vserver-stat (summary information about running guests and resources consumed
by them), vserver stop (safe stopping of a guest), vserver enter (a way to
enter a guest directly from the host) or vapt-get (batch invocation of
apt-get over all running guests). It defines a finer set of capabilities,
e.g. you don't have to set the big CAP_SYS_ADMIN permission just to be able
to use FUSE. And it contains hashify with the copy-on-write feature to save
main memory, memory cache and disk space.
Linux Containers allow me to run some things in the containers that I've never
managed to get running inside VServer guests (new OpenAFS aklog, OpenVPN).
They provide more sophisticated device isolation (mknod /dev/null possible
without permitting too much) and network isolation (each container can have its
own routing and filtering rules). Configuration is easier. And they are
included in the official kernel source. On the other hand they lack some
important features provided by Linux VServer and I experienced several less or
more annoying problems (but none of them preventing me from using Linux
Containers completely). The implementation may improve rapidly, so it can be
better now.
Both the projects lack good documentation.
There is some lesson with Linux VServer and Linux Containers. AFAIK, Linux developers have originally rejected the Linux VServer idea as unnecessary for several years. Apparently during the time they changed their mind and Linux Containers are here. The result of the lost years is that we haven't got a complete and well working solution yet. Well, we know that progress is sometimes constrained by our mental barriers.
Entries tagged "software": 
Created by Chronicle v4.6