QComicBook hosted on GitHub

QComicBook repository is now available on GitHub, meaning you can now access all historical releases and follow the development (master) branch if you wish to do so.  QComicBook source tarball can be found in the Downloads section of the repository.

Remark: commit messages are in Polish as I've never intended to publish my local repo... I apologize for inconvenience. I'm going to change this with next commits.

My home web site is not available yet - I'm still looking for a web hosting (see my previous blog entry).

Urgent: My website is down. Looking for new web hosting.

My web hosting provider had suddenly stopped the service and wiped the server out yesterday, meaning my web site is temporarily unavailable. Unfortunately, this includes QComicbook, KleanSweep and my other projects as they have no mirrors.

Here is a plea: if you're a system administrator of a web hosting server and you ever wanted to support free software projects, then this is your chance. I need a free web hosting to host my home site and open source projects as soon as possible. My expectations are:

• it's free.
  
• this must be a stable and secure server, running 24/7.
• you're a professional web hosting provider and have already been providing web hosting for other web sites.
  
• web pages can use Ruby on Rails or PHP (for now my web page is all static, but I'd like to change it).
• disk quota can be increased if needed (I should be fine with around 50Mb for now, but may need more in the future).
• you have some nice domains available (e.g. gnu.org is a nice domain, whereas microsoft.com is not) and you can provide me with nice hostnames like qcomicbook.<yourdomain> or stolowski.<yourdomain> (I'd like to split my website into personal web site and qcomicbook, kleansweep hosting sites, so a few hostnames would be required).
• ssh and shell are not required, but would be a nice addition.
  

I can't give you much in return except for satisfaction and my appreciation. And of course you'll be listed in THANKS file of QComicBook ;).
So, if you can provide me with web hosting service and meet these requirements, then please email me immediately. Thank you.

I'm also interested in suggestions about free and reliable web hosting services, so if you know and can recommend any, then please let me know.

Regarding the availability of QComicBook source tarball... I'm looking for a temporary web site to host it until a new hosting is available and my web site is back. I'll keep you informed, check this blog for updates.

QComicBook 0.5.0 unleashed!

I'm happy to announce that the new version of QComicBook has finally been released and is available for download. The middle version number has been increased from "4" to "5", meaning this release brings substantial new features, not just bugfixes. Here is the ChangeLog:

• implemented true continuous viewing mode. 'Continuous scrolling' option moved to 'View' menu.
• cmake-based build system (replaces autoconf/automake).
• all windows/dialogs implemented via QtDesigner's .ui files and handled by uic.
• icons and splash screen are now handled by Qt resources system and compiled-in in the resulting      qcomicbook executable.
• new, improved 'System Information' dialog.
• new splash screen.
• removed 'Forward two pages in two pages mode' option.
  
• fixed splash screen showing.
• lots of internal and architectural changes.
  

The most important new feature is of course true continuous scrolling mode, which displays all pages on a single continuous "sheet of paper" that you can freely scroll up & down. I don't have to say that reading comic books this way is much more enjoyable, do I? Of course, the implementation is smart enough to preserve memory and load/release pages as needed, so no worries. This feature took me tens of hours and a lot of blood, sweat and tears to implement, so keep that in mind and consider a small donation (e.g. a beer worth) if you like QComicBook (PayPal link is available at my home site) ;).

To celebrate this new 0.5.0 release, QComicBook got a new splash screen (see picture above) - thanks again to Adam Mateja for this wonderful piece of work!

Now as 0.5.0 has been released and a few months of work has been concluded, I'm about to start planning for upcoming months.  As of now the following two features are on the top of my TODO list:

• zoom lens and/or other ways of zooming.
• on-the-fly image enhancements (brightness, contrast, color adjustements etc.)
  

Of course, before these (and/or possibly other) features are implemented, expect 0.5.1 bugfix release.

As usual, QComicBook can be downloaded from http://linux.bydg.org/~yogin/

Enjoy!
     

When half of your memory is gone

When you're compiling a custom kernel, don't forget to turn 'HIGHMEM' option ON, otherwise you may be wondering why only a part of your memory if available for use :}.... And don't let this option fool you, 4GB actually means systems with 1-4GBs... Fortunately, kernel messages are very accurate and pinpoint the problem:

Warning only 895MB will be used.
Use a HIGHMEM enabled kernel.

I'm killzoned

I've just recently collected almost all of the singleplayer campaign trophies in Killzone 2, except for Heroic Survivor, Iconoclast and Field Agent. I'm now going to beat the game for the 3rd time, this time with "Elite" difficulty level to earn the remaining trophies. This will be tough time... Killzone 2 is the first game I've ever played which gets even more fun and enjoyable the next time you beat it. IMHO it is also the best first-person-shooter ever. Period.

Web page updates: dead projects, new QComicBook packages

Time has come to conclude the state of some of my projects and update my website... Thereby I declare the following projects as no longer developed or maintained:

• Moorie -- taken by volunteers some time ago, so chances are it still has future.
• VyQChat -- forked as TriX project a long time ago. Not sure whether it's still actively developed (last update: June 2008).
  

This shouldn't be surprising for those who where following these projects. I haven't updated them for a long time and already declared their death when asked via emails.

My website was also updated with links to new QComicBook packages provided  by volunteers; binary package is now also available for Slackware Linux and PKGBUILD is availabe in AUR repository for Arch Linux. Thanks for those involved in preparing binary packages for QComicBook!

Fun with Cheese :)

Fun with GNOME Cheese (using Noir filter in Cheese; put together with Gimp)  - my daughter and me.

iwl4965 driver bug & a workaround

I've been experiencing random wifi disconnections for a couple of months from now, but assumed these were problems with my AP or with Network Manager. Until now. I've just recently spotted messages indicating firmware/driver problems in dmesg output (I'm running kernel 2.6.30):

Oct  1 16:25:11 pc kernel: wlan0: associated
Oct  1 16:27:21 pc kernel: iwlagn 0000:03:00.0: Microcode SW error detected.  Restarting 0x82000000.
Oct  1 16:27:21 pc kernel: Registered led device: iwl-phy0::radio
Oct  1 16:27:21 pc kernel: Registered led device: iwl-phy0::assoc
Oct  1 16:27:21 pc kernel: Registered led device: iwl-phy0::RX
Oct  1 16:27:21 pc kernel: Registered led device: iwl-phy0::TX
Oct  1 16:28:54 pc kernel: wlan0: disassociating by local choice (reason=3)


Google reveals several bug reports for this error for many popular Linux distributions: Ubuntu, Fedora, Gentoo, Arch...; it was also reported on Intel's bugzilla. The bug has been known for months but it looks like it's not apparent what's its root cause. The problem occurs under high traffic volume or after long inactivity. The connection doesn't work anymore, but it is not reported as such by NetworkManager or iwconfig. To get it working again,you have to reconnect with NetworkManager or reload iwlagn module.

 It seems there are two workarounds, I've tested both of them and both worked for me:

• set "swcrypto=1" option for iwlagn module using modprobe.conf
• use ndiswrapper driver, that is, the wrapper for MS Windows driver.

Of course 1st option is recommended if it works for you. Ndiswrapper works well, except for its ntos process may take as much as 80% CPU under high load (e.g. 200K/s transfer) and around 9% with no traffic (running on 2GHz Core2Duo)... It's not noticable on Core2Duo though.

Judging from the changelong for RC of kernel-2.6.32, there is a buch of fixes related to Intel wireless drivers (and iwl4965 in particular), let's hope the problem will be gone when 2.6.32 is finally released.

PSP Go is a no-go

The new incarnation of PSP - called PSP Go - has hit the shelves. Reviews are showing up and are generally not favourable for the new SONY's baby. It's not hard to see why and it's hard not to agree with most complaints. I'd recommended the review published by Arstechnica.

To me, PSP Go is a big disappointement. I was initially very excited when it was first announced and planned to buy one by end of this year but given all the drawbacks and pricing, I'm no longer considering buying it; I'd rather consider a PSP 3004 + a big memory card...

One more thing... As a happy PS3 owner I'm getting frightened and unhappy about all the downloadable content (DLC) fuss. It's becoming obvious, that downloadable games are by no means cheaper than traditional games (in fact, they are often more expensive), you can't buy used games and they often sell you unfinished and crippled games to make you buy additional content for them. Let's hope that tradional boxed games will never disappear and digitial distribution will be limited to mini-games only.

Arch Linux with TOMOYO Linux MAC

I had mentioned in my mini review of Arch Linux about no official support for Mandatory Access Control solution such as SELinux or AppArmor and also outlined the importance of MAC when writing
about AppArmor a few months ago.  I'm very happy with my Arch Linux installation, but one thing that bothered me was no ability to protect crucial applications and system against unknown vulnerabilites. So I decided to put some effort and install a MAC implementation on my system. This blog entry is about how it went.

The problem with software bugs is you cannot avoid them. Developers make bugs and even if you keep your system updated, you are still endangered by zero-day bugs and hidden, undisclosed bugs.  If you think you're on the sunny side because your're not a server administrator, just a workstation user, then you're mistaken. You may get hacked by just visiting a malicious web site that exploits a yet-unknown vulnerability in your web browser or by opening a crafted PDF file that exploits a bug in your PDF viewer software.

With Mandatory Access Control you can "enclose" selected applications in secured domains with precisely defined resources and privileges for that application. If bug in secured application is exploited, an attacker cannot perform any operations not defined in that application's policy rules.

OK, now onto choosing the right MAC implementation. This depends on your needs, determination, time, knowledge and willingness to learn. When looking for a solution for Arch Linux I initially considered two implementations: AppArmor and SELinux.
• AppArmor is something I'd preferr over SELinux for my needs, but the status of AppArmor development is not clear to me. The latest kernel patch available on the official web site is for kernel 2.6.26, so it's a bit outdated.  On the other hand AppArmor will be shipped with new Ubuntu 9.10 (kernel 2.6.31), so obviously there are people who maintain it, but I could not find any new patches.... Strange.
• SELinux would be an overkill for a workstation. I'm just not willing to tackle with file labelling and complex policies just to protect a few applications. Besides that, it's seems to be hard to protect Mozilla Firefox with SELinux labelling. The nice thing about installing SELinux is it can be easily installed using Community packages.

I kept looking and found two other solutions that recently emerged in Linux world:
• SMACK - Simplified Mandatory Access Control - available in stock kernels starting from kernel 2.6.24.
• TOMOYO Linux - available with limited functionality in stock kernels starting from kernel 2.6.30 (but not enabled in Arch Linux kernel). Also available as a separate kernel patch with full functionality.

SMACK is a "SELinux for dummies"; it uses lables and extended attributes, but is much more easy to use than SELinux. Tomoyo is similiar in concept to AppArmor - it uses path names as security labels. It can be easily installed on Arch using PKGBUILD from AUR. Keeping all the above in mind (complexity of administration, availability) I decided to give Tomoyo a try.

 
Installation is easy. Just build and install kernel26 and ccs-tools from AUR (note: this is TOMOYO 1.6.8 with full MAC functionality) , update grub config file, reboot the system, initialize policy files and it's ready to use (basic setup is well described in TOMOYO's HOWTO). The majority of work is with creating application policies. Fortunately, TOMOYO has a really powerful learning mode. Here is how to use it:

1. Start application just once so that TOMOYO knows about it, then quit it.
2. Run ccs-editpolicy and find that application on the domains list (see screenshot) and highlight it.
3. Press 'S' and then '1' to enable learning mode for it.
4. Excercise your application a bit - perform as many actions as possible. Policy rules for this application will be generated automatically and kept in kernel memory.
5. When you're done, press 'S' again and then '3' to enable enforcing mode for your application. Alternatively, you can use '2' for permissive mode (all actions are permitted but potential denials will be written to log file - useful for testing purposes).
6. Save the policy with 'ccs-savepolicy'. This stores current policy from kernel memory to /etc/ccs/* files.
7. Adjust the /etc/ccs/domain_policy.conf and /etc/ccs/exception_policy.conf with a text editor. You'll most likely need to change any specific file paths occuring in the policy (like /home/john/.mozilla/firefox/6y78dadq.default/Cache/yiaud) with file patterns (e.g. /home/\*/.mozilla/firefox/\*/Cache/\*).
8. Reload the policy with 'ccs-loadpolicy de'; this loads current policy from files to kernel memory.
   

You can repeat above steps as many times as needed.

There is hovewer one catch to be aware of.  Policy rules are defined per execution domain. In TOMOYO domains are defined by process invocation history (PIH), that is, a concatenated list of executables that lead to the execution of specific application. This means that "/sbin/init /usr/bin/gdm /usr/sbin/gdm-binary /etc/gdm/Xsession /usr/bin/ssh-agent /usr/bin/gnome-session /usr/bin/gnome-panel /usr/bin/transmission /usr/lib/firefox-3.5/firefox" domain is different from " /sbin/init /usr/bin/gdm /usr/sbin/gdm-binary /etc/gdm/Xsession /usr/bin/ssh-agent /usr/bin/gnome-session /usr/bin/gnome-panel /usr/lib/firefox-3.5/firefox", even though in both cases Mozilla Firefox was executed. In the first case Firefox was started by Transmission, in the second case it was started by Firefox shortcut on the panel. The number of domains Firefox could be started in is potentially infinite, because you can start it via ALT+F2 in GNOME, xterm, gnome-terminal etc. You may think you'll end up with duplicating policy rules for all possible domains Firefox can be started in (not a good idea...), but fortunately Tomoyo has solution for this:  you've to add 'initialize_domain /usr/lib/firefox-3.5/firefox' definition to /etc/ccs/exception_policy.conf and define policy rules for " /usr/lib/firefox-3.5/firefox" domain.  It's so simple.  From now on, whichever way you choose to start Firefox, Tomoyo will use just one domain definition and same rule set. Don't underestimate PIH though, as PIH is a a powerful tool to define various polices for same application, depending on its invocation history (well... that was obvious, hmm...). You can, for example, define different rules for /bin/cat executable, depending on whether it was used in /usr/bin/foo.sh script or /usr/bin/bar.sh script.

Ok, this is enough. It's time to summarize best features of TOMOYO Linux:
• Easy to set up. No existing userland tools need to be modified.
• Easy policy language.
• Great learning mode.
• Ability to modify policies on-the-fly.
• No impact on performance (according to Tomoyo Linux authors, performace hit is within measurements error).

If you need a MAC solution which is easy to setup and use and you understand the differences between path-based (TOMOYO, AppArmor) and label-based (SELinux, SMACK) solutions, then you should definately give Tomoyo Linux a try. I think it's superiror to AppArmor and now as it made it's way into Linux Kernel, it seems it has a bright future. Congratulations, TOMOYO team!

UPDATE: I've been contacted by Tetsuo Handa (one of the Tomoyo developers) with a rectification about performance: there is some impact on performance, and performance impact of TOMOYO is larger than SELinux (as it entails string comparison with pattern patching), but users
 won't notice unless CPU is too slow. Some people tried to measure the performance hit, but they got bizzare results.

Arch Linux

I admit that, I'm a distro junkie and Linux addict and just can't resist trying different distros... I've been using Linux on regular basis for over 12 years and tried several distros, but haven't found the perfect one so far. This time I was tempted to try out Arch Linux - a versatile distro designed with accordance to KISS principle and targeted at advanced users. After around one week of playing with it I can say it's close to meet all my requirements for a perfect distro. Ok, it's not 100% perfect, but really close. Main advantages of Arch Linux in my humble opinion are:

• It's blazing fast. I mean it. It boots really quickly and GNOME + Firefox feels much snappier then in other distros.
• It's customizable. Ok, you can say it about most distros, but with Arch you're not forced to choose any path. You start with a bare minimum (just core system packages) and install whatever you want on top of it. Do you want pulseaudio? Here you are. Do you hate pulseaudio? That's fine too.
  
• It's brain dead simple to customize & recompile packages with custom options and features, thanks to tools such as pbget, customizepkg and makepkg. It's equally easy to create your own packages from scratch, as all you need is a simple PKGBUILD file.
  
• It's a rolling-release system, meaning most packages are up-to-date all the time and you may be on the bleeding edge to your liking.
• It'sa binary distro after all, optimized for i686 (x86_64 is also available). No need to waste time & CPU time to compile all the stuff.
• Basic aspects of system configuration (deamons, modules, network etc.) are easily configurable via a single /etc/rc.conf file. Daemons may be started in background (i.e. in parallel) making the system boot faster.
  
• Pacman (Arch Linux package manager) is damn fast.
• It has a good and helpful Wiki pages as well as supportive community.
  

Ok, I mentioned Arch was not perfect, so now onto downsides:

• Setting it up takes time. It took me around 5 hours to install and tune the system to my needs. This included installation of Xorg, GNOME, multimedia stuff as well as some tools and libraries I use for developing my projects (Qt Designer, boost, cmake, git, emacs etc.). The main issue I had was with GDM - it turned out I had to use a specific GDM option (GdmXserverTimeout=60) to get it working correctly. On the orher hand, you do it once and forget about it.
  
• Things may occasionally break if you upgrade your system blindly without paying attention to what's going to be updated.
• The official repositiories lack some less known or less popular packages.
  
• AUR repository (the repository of user-provided PKGBUILD scripts for additional packages that are not included in offical repos) is not something you can count on. It contains user content of varying quality. Some PKGBUILDs may be outdated or broken. On the other hand however I had to use AUR for 5 packages only: Opera web browser, grandr-applet, pbget, ttf-droid fonts and xephem.
• There is no official support for security enhancements like AppArmor or SELinux. SELinux is available in the community repository only. I consider a MAC enhancements a must in today's systems; at least selected applications should be executed in confined environments.
  

I'd definately recommended Arch to everyone with some prior Linux experience. It should be particularly valued by advanced users, developers and open-source enthusiasts who like to use the newest and hottest software.

QComicBook: 0.4.2 & 0.5.0

QComicBook 0.4.2 has just been released; this is mainly a bugfix release which fixes compilation problems. As already mentioned before, I've also been working on some changes that will debut in the near future with  QComicBook 0.5.0. Some changes have already been revealed, but here are more news to give you the taste of what's coming:

• true continuous mode (see screenshot)
• improved multi-threading affecting background image loading
• cmake-based compilation
• ui-based windows and dialogs.

I'm particularly happy to give you the long-awaited, true continuous reading mode. Imagine reading comic books with no jumping to next page, but having all pages displayed on a continuous sheet of paper, which can be freely scrolled upwards/downwards! This is already implemented, but I've to hammer out some bugs and implement some missing bits to support all the functionality QComicBook had before introducing this feature.

The new 0.5.0 release should be ready within a few weeks. Stay tuned!

D.Jordan, A. Wiest - Atlas II Wojny Światowej

Po wielu latach niezrozumiałej posuchy w temacie, doczekaliśmy się w końcu wydania na rodzimym rynku atlasu historycznego w całości poświęconego II wojnie światowej. Dotychczas takiej pozycji w języku polskim po prostu nie było, co jest dość dziwne zważywszy na fakt, że podobnych publikacji ukazało na Zachodzie co najmniej kilka; sam posiłkowałem się dotąd anglojęzycznym atlasem "Atlas of World War II" R. Natkiel'a (który nota bene - podobnie jak kilka innych atlasów - można sprowadzić za bardzo rozsądne pieniądze za pośrednictwem internetowego sklepu Empik).

Atlas autorstwa Davida Jordan'a i Andrew Wiest'a wydało w naszym kraju mało chyba znane Wydawnictwo Dragon (ja, przyznam się, usłyszałem o nim po raz pierwszy) - i chwała im za to! Atlas już na pierwszy rzut oka sprawia bardzo dobre wrażenie, a pobieżne nawet jego przejrzenie wywoła zapewne szeroki uśmiech u każdego miłośnika historii II wojny światowej. Książka ma format nieco większy niż A4, twardą obwolutę, liczy 256 stron i wydrukowana została na porządnym, kredowym papierze. Jeśli chodzi o zawartość, to atlas zawiera 160 kolorowych map i obejmuje okres od wybuchu wojny (gwoli ścisłości: kilka stron poświęcono też na omówienie uwarunkowań, które do wojny doprowadziły), zapoczątkowanego napaścią na Polskę, do upadku Japonii. Całość podzielona jest na kilka części, wedle teatrów działań wojennych. Mapy ilustrują przebieg poszczególnych kampanii, rozmieszczenie i ruchy wojsk, linie frontu itp. - czyli to wszystko, czego po takiej publikacji należało by się spodziewać. Są do tego bardzo przejrzyste. W większości zostały wykonane w dużej skali (1 cm = 50km lub 1 cm = 100 km), ale znalazło się kilka wyjątków (m.in. bitwa o Stalingrad, atak na Pearl Harbor, powstanie warszawskie, operacja Market-Garden), gdzie są dużo bardziej szczegółowe.

Obok map, pokaźną część atlasu zajmują teksty opisujące przebieg poszczególnych operacji. Tu także należy się plus dla autorów, bo w przeciwieństwie do innych publikacji starających się przedstawić II wojnę światową "w pigułce", tutaj faktycznie udało się dość zwięźle i rzeczowo przedstawić kwintesencję opisywanych działań. Całości dopełniają fotografie, które na szczęście nie zabierają zbyt wiele cennego miejsca. Piszę "na szczęście", gdyż nie fotografie i nie treść stanowią o wartości tej pozycji (od tego mamy już całą masę książek), ale wspomniane mapy.

Gdybym miał wskazać jakieś minusy i do czegoś się doczepić, to nie będzie tego wiele: pozbyłbym się całkowicie fotografii i skrócił opisy kampanii a w zamian dołożył więcej map. I to w zasadzie tyle. Nie podejmuję się oceniać merytorycznej strony tej publikacji i tego, czy są w niej jakieś błędy rzeczowe lub inne uchybienia z dwóch powodów: po pierwsze - ponieważ atlas nabyłem niedawno i było zbyt mało czasu, by coś takiego wychwycić, po drugie - moja wiedza jest ciągle zbyt skromna, bym mógł doszukiwać się nieścisłości... Podsumowując - pozycja godna polecenia i na razie nie mająca na naszym rynku konkurencji, do tego dostępna za rozsądną cenę (ok. 69 zł). Zdecydowanie brać.

Upcoming QComicBook changes

A new bugfix release of QComicBook (0.4.2) is on the way and should be available soon. In the meantime I'm working hard on some under-the-hood changes that will debut later around version 0.4.3. These are mainly internal changes that affect building process and maintability, so do not expect any "big" features yet. Two main improvements are:

• Introducing .ui (QtDesigner) form files for dialogs and windows - it just became too cumbersome to maintain and extend the existing hard-coded dialogs. Working with QtDesigner 4.x is a real joy and it is actually very easy to refactor existing classes to use uic-generated forms: just design them with QtDesigner reusing existing object names, inherit from generated classes, call setupUI() and you're done :).
  
• Switching from autotools hell to cmake - CMake is so much easier, cleaner and nicer tool... It took me around 3 hours to switch QComicBook to CMake with no prior knowledge of this tool - just having a sample CMakeLists.txt from other project and cmake man pages... This speaks for itself...

Some other internal changes that have high priority on my TODO list:

• refactor archive handling subsystem with strategies (policies) for handling various archive types.
• refactor image and thumbnail loading/caching for better cooperation; I'm not happy with it's current design.
  

QComicBook 0.4.1

After almost two years of silence I've finally released a new version of QComicBook. There isn't much to be proud of this time, just bugfixes. Changelog for this release:

• fixed freezing when unpacking some archives (in particular zip)
• fixed crash when opening archives via 'Recently opened' menu
• thumbnails are now saved with sha1-hashed file names
• updated autoconf bnv_have_qt macro
• Qt>=4.3.0 is required from now
• internal cleanups

Ubuntu security?

I've recently noticed a security update for git-core in Debian stable/testing/unstable, which fixes a denial of service bug in the git-daemon. Debian got the fix on Jul 25th.
Fedora 11 folks were even more responsive by releasing an update on Jun 23rd (!). How about Ubuntu I hear you asking. Guess what... no update so far. I bet the bug applies to Ubuntu as well: Jaunty uses git-core 1.6.0.4; for Debian sid it was fixed with version 1.6.3.3-1. Fedora users got git-1.6.2.5. Wake up, Ubuntu Security team!

Qt4: don't mix waitForFinished() with processEvents()

I had received a few claims about QComicBook hanging when unpacking some cbr archives in the past, but could not confirm the problem till now. I've just received a nice bug report for this issue - with a sample .zip archive that reproduces the bug. It looks like it's not a good idea to mix QProcess::waitForFinished(-1) with QApplication::processEvents(). The problem manifests itself if you do the following:

• start a process (an external command)
• wait for exit with waitForFinished(-1)(which blocks until process exits)
• capture the output with a QProcess::readyReadStandardOutput() signal handler
• the signal handler calls QApplication::processEvents()
  

waitForFinished(-1) may then block forever.

The problem has already been reported on Ubuntu's Launchpad as well as in QtSoftware bugtracker. Unfortunately, it seems there is no solution, it won't be fixed in Qt library and should be avoided... The workaround I implemented for QComicBook-0.4.1 (to be released soon) is a busy-loop around waitForFinished(1000) (i.e. 1 second) and processState() calls. Not the nicest solution, but it seems to work fine and I can still use processEvents() to provide progress bar updates when unpacking archives.

Joined Twitter

I've just joined Twitter microblog community. You can follow my status at http://twitter.com/pstolowski.

Vim's CTRL+Y in Emacs

One of the nice features of Vim I couldn't find in GNU Emacs is copying characters from the line above the cursor with CTRL+Y; it's very useful when dealing with repetitive lines of text. So, why not implement it with elisp? Ok, here you are. I'm not sure if this is the best approach, but it works:

(defun get-above-char()

 "Get character from a line above"
 (let ( (o) )
  (setq o (- (point) (line-beginning-position)))
  (save-excursion
   (if (> (line-number-at-pos) 1)
    (progn
     (forward-line -1)
     (forward-char o)
     (char-after)
    )
    )
  ) ) )

(defun copy-above-char()
 "Copy character from a line above"
 (interactive)
 (insert (get-above-char)))

Copy this elisp code to your .emacs and bind copy-above-char to a key, e.g.
(global-set-key [(control \;)] 'copy-above-char)

Of course it is possible to record a keyboard macro instead if you don't like/know elisp, but elisp implementation is more elegant and allows for additional checks to be performed (e.g. if current line > 1).

Playing with laptop-mode

The other day I decided to squeeze most out of my laptop's battery. After a few minutes of tweaking I had discovered (to my surprise) that laptop-mode is disabled by default in Ubuntu 9.04. The comment in /etc/default/acpi-support provides an explanation:

# Switch to laptop-mode on battery power - off by default as it causes odd
# hangs on some machines. (Note: This is reported to cause breakage in
# Debian - see deb bug #425800. Leaving enabled for Ubuntu for now
# since presumably it's still valid here.)

But apparently it's disabled in Ubuntu... W00t? This means that if you're running on battery power, the system doesn't perform any optimizations to reduce power consumption except for CPU frequency scaling performed by ondemand governor (please correct me if I'm wrong...).

So the first step is enabling laptop-mode (set ENABLE_LAPTOP_MODE=true in acpi-support config file) and restarting /etc/init.d/laptop-mode. A quick look at /etc/laptop/conf.d directory reveals plethora of options for tweaking laptop-mode. Many of them depend on and require specific hardware and are disabled by default; some are generic. The ones I found interesting for my laptop are:

• cpufreq.conf - configures frequency scaling rules, e.g. makes it possible to force slowest CPU frequency when running on battery power, no matter what system load is.
• start-stop-programs.conf - allows for setting programs or services which should be started or stopped when on battery power.
  
• ethernet.conf - configures power saving settings for Ethernet cards, e.g. limits connection speed from 1Gbit to 100Mbit.
• wireless-iwl-power.conf - configures powersave mode of Intel 3945/4965 wireless adapters.
• intel-hda-powersave.conf - configures power saving settings of Intel HDA audio chipsets.
  

Enabling the above settings didn't impact the stability of my system. I haven't tested battery lifetime with these changes yet. Conclusion will follow this post. To be continued.

Securing applications with AppArmor

The main problem with standard Unix security model (DAC - Discretionary access control) is passing user privilleges to applications he/she executes. The problem is, whenever you launch e.g. a web browser, it has access to all files/resources you would normally have to. While under normal conditions it's not a big deal, think of what happens if it has a bug that can be exploited by an attacker... Such danger can be minimized by employing MAC - Mandatory access control.

Having some prior experience with SELinux MAC implementation (the master thesis I wrote one year ago), I've decided to try out Novell's AppArmor . While SELinux is very powerful and may seem to be an ultimate MAC solution for Linux, it's far too complex for average joe user. Sure, the default 'targeted' policy implemented e.g. in Fedora Linux works fine out of the box, but debugging problems may still be too intimidating for most users. AppArmor is a MAC implementation for the masses: it's much easier to comprehend, use and administer.

I'm not going to describe AppArmor's history, command line tools etc. as they are explained in detail in the official documentation as well as in man pages. Instead, here is a short walk-through of creating a policy for Adobe Acrobat Reader 9. Acrobat Reader has a long track of security issues - most problems were related to application crashes when opening malformed (crafted) PDF files. The goal is to limit the resources/files that acroread can access by forcing read-only access to the filesystem, write access for specific paths only and 'execute' permission to specific commands only.

1. Run AppArmor's 'learning' mode (profile generation) and point it to /usr/bin/acroread.
   $ sudo aa-genprof
2. Run Acrobat Reader and excercise it a bit, that is, perform all the usual operations, e.g. open file, print it etc.
3. When you're done, press "S" key in the aa-genprof window. You'll now have to answer a series of questions about granting or denying access to specific resources based on the actions you've just performed in Acrobat Reader. Use your best judgment to allow/deny access to given resources; keep in mind that some rules may need to be adjusted and made more generic by specifying glob patterns, e.g. allow acroread to read/write files in /tmp/** rather than a specific file in /tmp/ detected by aa-genprof.
4. Once you're done with aa-genprof a new AppArmor profile will appear in /etc/apparmor.d/opt.Adobe.Reader9.bin.acroread. Open it in an editor and perform further adjustements.
5. When done, reload AppArmor with sudo /etc/init.d/apparmor reload. Run Adobe Acrobat and verify if it works. Check /var/log/messages (or /var/log/audit/audit.log if you have auditd running) for any APPARMOR_DENIED messages which may be related to acroread actions. Repeat steps 4-5 if needed.

You'll need around 10 minutes to complete steps 1-3. You may stop there if you're happy with the rules created automatically by aa-genprof, but it's a good idea to tweak them manually. This will take you around 30 minutes, depending on your skills, needs and application complexity.

When creating my own profile for Acrobat Reader I've decided to simplify rules that govern /opt/Adobe/Reader9 subdirectories like this:

/opt/Adobe/Reader9/** r,
/opt/Adobe/Reader9/Reader/intellinux/bin/acroread rix,
/opt/Adobe/Reader9/Reader/intellinux/lib/* mr,
/opt/Adobe/Reader9/Reader/intellinux/plug_ins/* rixm,
/opt/Adobe/Reader9/Reader/intellinux/SPPlugins/* rixm,

I've also decided to restrict read-access to specific files and directories only; I came to the conclusion that PDF files usually reside in/home directories, /media/ directories (mounted devices like cdrom or flash drives) and/usr/share/doc subdirectories. So I ended up with the following rules:

deny /home/*/.ssh/** r,
deny /home/*/.gnupg/** r,
owner /home/** r,
/media/ r,
/media/** r,
/ r,
/usr/ r,
/usr/share/ r,
/usr/share/doc/ r,
/usr/share/doc/** r,

First two "deny" rules protect some vital user's files. Remaining rules grant read-only access for the paths mentioned above. Please note, that read-access for /, /usr, /usr/share and /usr/share/doc (no globs here!) is needed to allow standard "Open file" dialog to read contents of these directories (just the list of files) and browse to /usr/share/doc/. Try to navigate to e.g. /usr/share/perl to see it's not allowed. Cool!

There are of course more rules - in fact the profile file contains around 60 rules in total. Among them are rules that:

• grant read/write access to configuration files in /home/*/.adobe/Acrobat/**
• grant read access to standard GNOME/GTK configuration files in home subdirectories.
• grant read/execute access to some standard commands like cat, pwd, mkdir and printing-related commands (lpq, lpr).
• grant read access to icons, fonts and pixmaps.
• grant execute access to /usr/lib directory.
  

That's it. Happy hacking.

Favourite movie scenes #1

There are movies you'll never forget. Most often this is because of their stories, but sometimes there are scenes and takes which make some movies brilliant in your eyes. Here are some of my favorite movie scenes (part #1), in no particular order...
Planet Terror. Opening titles - Cherry's Go-Go dance. One of the best and most hot movie openings... Cherry is performing a seductive Go-Go dance, supported by great music by Robert Rodriguez himself. The scene is very dynamic, thanks to frequent changes of camera distance and angle.


Lost Highway. Pete and Renee making love on the desert in the night. Surreal setting with warm, bright car lights illuminating them.
When Renee whispers 'You'll never have me', you can almost fell a chill on your back...


Natural Born Killers. Opening titles - Cafe on the desert, in the middle of nowhere. Mickey is eating a pie while Mallory is turning a jukebox on and starting her defiant dance. Two men enter the cafe, one is mashing her... A scorpion gets smashed on the road,a deer is dying on the desert. The air is incredibly hot. You know something is going to happen soon. Soon they will unleash hell... Great music by Leonard Cohen, by the way.

Spy Game. Scene on the roof of a building. Muir and Bishop argue about a man used as a bait on their mission in East Germany. Muir explains what espionage is all about. You think Bishop is right, but there's no denying Muir is a professional and knows the score... The scene is nicely set on the roof of a building and the camera is circling around from time to time giving the wrangle a boost.

To be continued...

Managing wine bottles

Wine has a nice feature that lets you keep your virtual Windows installations in separate directories, commonly known as wine prefixes. If you install a lot of software or even just a few games, you'll soon discover that some wine settings or tweaks may work for one program but break the other. While some settings may be set on per-executable basis (via winecfg), there are more which have global impact (e.g. virtual desktop resolution settings, registry tweaks etc.). Wine prefixes provide a comfortable way for keeping software installed in isolated environments which are easy to backup or remove. A common use scenario looks like this:

$ WINEPREFIX=/my/windows/software/foo wine setup.exe
$ WINEPREFIX=/my/windows/software/foo regedit

But this is not very convenient. There are some helper utilities that let you create and maintain wine bottles and provide some additonal functionality for better wine experience - examples are: PlayOnLinux, Wine-Doors and q4wine. You may also create your own wrapper scripts for this purpose - or use the ones I've created for myself. The script is loosely based on a script published by linux-tipps.blogspot.com, but adds some more features. It creates wine bottles in ~/Wine directory by default. Sample usage:

Installing game in a new bottle (MyGame):
$ wine-bottle MyGame /media/cdrom/setup.exe

Running winecfg, regedit and wineboot for specific bottle:
$ winecfg-bottle MyGame
$ regedit-bottle MyGame
$ wineboot-bottle MyGame

Running the game in the bottle:
$ cd ~/Wine/MyGame/drive_c/mygame
$ wine-bottle MyGame game.exe

Creating a shell script for quick startup:
$ cd ~/Wine/MyGame/drive_c/mygame
$ bottle-makescript ~/run_mygame.sh MyGame game.exe

bottle-makescript will create a shell script that runs the specific executable in given bottle with no need to resort to command-line anymore.

Any ideas for improvements are welcome. Enjoy.

Linux Everywhere / The website is down

These guys rock! Just watch this... (Disclaimer: 2nd movie contains harsh language).

I want A***** back...

Some retrospective analysis... It is destined to selected people only (aka Circle Of Trust). Hint: 31tor.

Fubeg ergebfcrpgvir nanylfvf. Vs lbh'er zh pheerag rzcyblre, cyrnfr fgbc ernqvat vzzrqvngryl!

V ernyyl zvff N****b. Vg jnf bar lrne jvgu terng crbcyr naq fhcreo cebqhpgf (NPP, NFT). Guvf jnf gur vefg gvzr V ernyyl ybirq zl wbo (V zrna vg - yvgrenyyl), rawblrq vg naq sryg pbaarpgrq jvgu gur cebqhpg. Guvf jnf n wbo V pbhyq qrfpevor nf nyjnlf punyyratvat, fnglfslvat, sha naq abg oheavat lbh bhg naq znxvat lbh jnag gb guebj lbhe CP njnl. Bgure guna gung: ntvyr qrirybczrag, yvahk, p++, obbfg ehyr!!! (V pna rira fgnaq crey ;)).

Gbb onq vg'f nyy tbar. Qnza, qnza pelfvf! V jnag N***** onpx!!! [pel]

Operation Flashpoint & Wine

The great Operation Flashpoint game - probably one of the best war simulations ever - is finally playable with wine on Linux! Although appdb reports state it has been playable starting from wine-0.9.46, I didn't have much success with OFP (mainly with sound) until recent wine releases. With wine-1.1.20 the game runs just fine, except for occasional textures flickering. Screenshots of OFP with ECP mod.

BTW. Too bad Blitzkrieg is still not really playable with wine.

Qt4 and QTreeView performance

When I started working on complete overhaul of KleanSweep GUI (moving from KDE 3 to Qt4) I soon faced problem with slow QTreeView performance when using my own item model. To make the long story short, with around 1.6 mln records the QTreeView was completly unusable taking tens of seconds to redraw when scrolling its contents. I googled a lot only to discover other people had similar performance problems with Qt Model/View architecture.
I almost gave up, until my recent discovery: the uniformRowHeights property of QTreeView. It indicates (if true) that all items in the view have the same height - and allows the view to perform some optimizations. This solved the performance problem I was facing! So now my SQLite-based model works fine and the new KleanSweep (still W.I.P) will be capable of displaying millions of files with little memory footprint!

Fell in love with Debian Lenny

Debian 5.0 (Lenny) has been released. I've been running it for about one month (installed from a release candidate iso) and I must admit I'm absolutely delighted by it. Being an Ubuntu user before I already got used to apt-get, synaptic and other goodies. Where Lenny really shines (compared to Ubuntu) is:

• it's rock stable; I haven't had a single stability issue so far
• it's well tested and you can really feel it. I haven't experienced any stupid / trivial / obvious bugs that  should have been detected and fixed (as it was often a case for Ubuntu or openSuse). It just feels the release was not rushed as it often happens to commercial distros.
• it's not bloated (number of services is reduced to the minimum, no desktop indexing like Beagle or Tracker is installed by default etc.)
  
• no experimental or unfinished features (e.g. no PulseAudio...)

All in all, Lenny seems to be a really good and solid release. Long live, Debian project!

A bit of self-promotion & job status update

I've just received a nice declaration from my university. It states that I've graduated Computer Science within 5% of best students (in 2008) :). This is very refreshing given my recent job changes (to remind you: Astaro closed its R&D office in Poland) and it was also a nice and unexpected surprise!

When it comes to job changes, starting from March 2nd I'll be working for my former company (Alcatel-Lucent) again.

Telescope case

I've finally made myself a case to carry my MAK127 telescope and another one to carry accessories (eyepieces, finder etc.). It took me around three hours to accommodate each case for its duty - main job was to cut sponge so that telescope and accessories all fit and are protected against shock (BTW, as you can see on the photos, the telescope case is made of a casual toolbox). My next target is a case / bag for EQ3-2 mount, but this seems to be more problematic... Any ideas?

Poszukuję pracy...

Początek roku okazał się dla mnie mało szczęśliwy... Okazało się , że Astaro - firma, w której pracowałem przez ostatni rok - zmuszona została do zamknięcia oddziału R&D w Bydgoszczy. Powód: kryzys, szczególnie dotkliwy w Niemczech, gdzie znajduje się główna siedziba Astaro.

Tak więc, jeśli Twoja firma poszukuje doświadczonego programisty (C++, Java, Python, Perl, Linux) do pracy na terenie Bydgoszczy lub okolic, to proszę o kontakt.

Więcej informacji o moich kwalifikacjach tutaj:

• profil goldenline.pl
  
• profil linkedin.com

Vice 2.1

A new version of Vice - popular C64 emulator - has been released on Dec 19th 2008. This version brings some small improvements - most notably fullscreen mode finally works and uses xrandr! This means much more fun & immersion when watching old C64 demos :).

This brings me to a bunch of new demos released in 2008. It turns out there are still guys out there who can amaze the world by squeezing last bits out of C64... If you had C64 and you've ever felt a bit nostalgic about it, I suggest you install vice and watch these demos:

• "Edge of Disgrace" by Booze Design, 1st place at C64 Demo Competition at X'2008.
• "Natural Wonders 2" by Oxyron, 2nd place at X'2008.
• "Pearls for Pigs" by Xenon, 3rd place at X'2008.

Going back to 2007... Check out "Desert Dream" demo by Chorus & Resource - these guys made an excellent remake of the popular Kefrens' demo from Amiga. Simply amazing.

BTW... A nice video about C64 internals and capabilities has been recently made available - see here.