facepalm.jpg

While browsing dockapps.org site I've found interesting applet. It is very similar to my WMVolMan, but have more functionality, like customizable commands and LUKS partition mounting. And it uses modern UDisks instead of obsolete HAL. Since I was planning to migrate to UDisks, I took a closer look at this applet...

First look at configure.ac scared the shit out of me me:

PKG_CHECK_MODULES(dbus,dbus-glib-1)
PKG_CHECK_MODULES(libnotify,libnotify)
PKG_CHECK_MODULES(gnome_keyring,gnome-keyring-1)
...
AM_PATH_GTK_2_0(2.18.0,,[AC_MSG_ERROR(cannot find libgtk)])

I know, dbus-glib is necessary to access UDIsks service via DBus and easily integrates into glib mainloop, but for fuck's sake, tell me what the hell GTK+2 is doing here? I don't even asking about libnotify (which depends on org.freedesktop.Notifications DBus service, which in turn provided by GNOME Notification Deamon) and GNOME Keyring library (which depends on daemon of the same name).

Next, I looked into dockapp window code. I shouldn't have done it, really. The whole dockapp code was written using ONLY GDK and GTK. With signals, callbacks, widgets, blackjack and hookers.

And finally, take a look at this:

$ ls -logh wmudmount 
-rwxr-xr-x 1 267K Mar 30 23:06 wmudmount
$ ls -logh wmudmount
-rwxr-xr-x 1 102K Mar 30 23:06 wmudmount
$ ldd wmudmount | wc -l
47

I know that ldd shows both, direct and indirect dependencies, but that's the point. And I was using -Wl,--as-needed.

Comparing to my wmwolman:<

$ ls -logh =wmvolman   
-rwxr-xr-x 1 32K Jan  4  2008 /usr/bin/wmvolman
$ ldd =wmvolman | wc -l
19

One may say that WMVolMan have tree times less functionality, but hey! Why would someone use WindowMaker inside GNOME (and it WILL be "inside GNOME" just after libnotify and libgnome-keyring starts all GNOME services like gconf and gvfs) with dockapps enabled? Just stay with gvfs and Nautilus.

• . . . . . .. . . . . . . . . . . ,.-‘”. . . . . . . . . .“~., 
. . . . . . . .. . . . . .,.-”. . . . . . . . . . . . . . . . . .“-., 
. . . . .. . . . . . ..,/. . . . . . . . . . . . . . . . . . . . . . . ”:, 
. . . . . . . .. .,?. . . . . . . . . . . . . . . . . . . . . . . . . . .\, 
. . . . . . . . . /. . . . . . . . . . . . . . . . . . . . . . . . . . . . ,} 
. . . . . . . . ./. . . . . . . . . . . . . . . . . . . . . . . . . . ,:`^`.} 
. . . . . . . ./. . . . . . . . . . . . . . . . . . . . . . . . . ,:”. . . ./ 
. . . . . . .?. . . __. . . . . . . . . . . . . . . . . . . . :`. . . ./ 
. . . . . . . /__.(. . .“~-,_. . . . . . . . . . . . . . ,:`. . . .. ./ 
. . . . . . /(_. . ”~,_. . . ..“~,_. . . . . . . . . .,:`. . . . _/ 
. . . .. .{.._$;_. . .”=,_. . . .“-,_. . . ,.-~-,}, .~”; /. .. .} 
. . .. . .((. . .*~_. . . .”=-._. . .“;,,./`. . /” . . . ./. .. ../ 
. . . .. . .\`~,. . ..“~.,. . . . . . . . . ..`. . .}. . . . . . ../ 
. . . . . .(. ..`=-,,. . . .`. . . . . . . . . . . ..(. . . ;_,,-” 
. . . . . ../.`~,. . ..`-.. . . . . . . . . . . . . . ..\. . /\ 
. . . . . . \`~.*-,. . . . . . . . . . . . . . . . . ..|,./…..\,__ 
,,_. . . . . }.>-._\. . . . . . . . . . . . . . . . . .|. . . . . . ..`=~-, 
. .. `=~-,_\_. . . `\,. . . . . . . . . . . . . . . . .\ 
. . . . . . . . . .`=~-,,.\,. . . . . . . . . . . . . . . .\ 
. . . . . . . . . . . . . . . . `:,, . . . . . . . . . . . . . `\. . . . . . ..__ 
. . . . . . . . . . . . . . . . . . .`=-,. . . . . . . . . .,%`>–

GNU is Not Usable

If you want to make something completely unusable - give it to GNU crowd. These guys seem to have ability to turn anything they touch into shiny and whistling piece of bad-smelling shit. No need to go far - take a look at GNU info. And the progress never stops, every new release of their info browser is getting worse and worse, they are making impossible things possible.

Recently I was playing with WindowMaker project, trying to clean it's autocrapped buildsystem. Inside WindowMaker there are WINGs library and WPrefs application that both contains gettext-driven translations, having three textdomains in total.

Here comes the question for one million points: how all these textdomains can be handled with one configure script? And by "handled" I mean "single autoreconf invocation should update Makefile.in.in and shit for all po subdirs". Answer is: you can't, shut up and suffer.

GNU is so GNU...

Code WTF

While playing with one opensource project we've found this masterpiece of Hindy C. I will not even comment it.

int pid, status, ret;
int filedes[2];
rc = pipe(filedes);
pid = fork();
if (pid == 0) {
  ret=0;
  close(filedes[0]);


  rc = functionThatMatters(/* some args */);



  if (!rc) {
    ret = 0;
  } else {
    ret = 1;
  }


  close(filedes[1]);      
  exit(ret);
} else {
  close(filedes[1]);
  close(filedes[0]);
  
  rc = timewait(pid, &status, /* timeout values */);
  rc = WEXITSTATUS(status);
}


if (!rc) {
  (*outStatus)[i] = 1;
  /* LOG WARNING THAT WE HAVE FAILED */
} else {
  (*outStatus)[i] = 0;
}

This reminds me forgotten stories about Miklos...

-D_PLZ_UNFORTIFY_MAH_SOURCE_KTHXBYE

More than five years ago Jakub Jelinek implemented object size checking in GCC. This feature (combined with GLIBC runtime checks) helps to detect many buffer overflows, both compile-time and run-time.  Of course, this brings some limitations to code.

Since then many distibutions (ALT Linux, Gentoo, OpenSUSE, Owl/*/Linux) turned this feature on by default. But there were those who resisted...

In February, 2007 patch from OpenSUSE was offered to Vim developers. Almost immediately it was rejected with resolution "The problem is in the compiler, so fix the compiler".

Now to the funny part.

Patch 7.2.044
Problem:    Crash because of STRCPY() being over protective of the destination
            size. (Dominique Pelle)
Solution:   Add -D_FORTIFY_SOURCE=1 to CFLAGS.  Use an intermediate variable
            for the pointer to avoid a warning.

Patch 7.2.251 (after 7.2.044)
Problem:    Compiler adds invalid memory bounds check.
Solution:   Remove _FORTIFY_SOURCE=2 from CFLAGS. (Dominique Pelle)

Patch 7.2.316
Problem:    May get multiple _FORTIFY_SOURCE arguments. (Tony Mechelynck)
Solution:   First remove all these arguments and then add the one we want.
            (Dominique Pelle)

I have a great citation for that case - this "won't solve the problem, only create the illusion that it works".

Heavy New Year, everyone, and double-check code that you intend to use in your usual life.

How's your stable?

Ruby is a nice language, but its community makes me sick.

On December 7, 2009, CVE-2009-4124 was fixed by SVN revision 26038. However, this fix was a bit buggy: #2463. This issue was fixed in trunk by SVN revision 26052 on December 9, 2009.

Now the funny thing. http://www.ruby-lang.org/en/downloads/ says "The current stable version is 1.9.1" and "Ruby 1.9.1-p376 (md5: ebb20550a11e7f1a2fbd6fdec2a3e0a3) Stable Version (recommended)".

For those who still don't get it: neither 1.9.1-p376 nor ruby_1_9_1 branch at all contains fix for #2463. I tried to add another issue, which was immediately closed as "duplicate of #2463".

19 days have passed so far and current recommended stable version still contains bug that nobody cares about. By the way, this bug affects Rails.

Have a nice day.

Unit tests? We don't need no stinkin' unit tests!

While packaging ruby-coderay for ALT Linux I ran into problem that tests just fail. Well, this is not really a problem, because we have Ruby 1.9.1 and there may be some obsolete language constructions or encoding issues. In fact, there was two issues that happen only on Ruby 1.9.x - Marshall::dump adds encoding information and output differs from expected. Other seven errors were really funny.

Seven tests fail in CSS section of HTML output. Browsing through revision history brought me to [r332] and [r329], both commited by Upstream Developer around 22 Apr 2009. Patch was obvious and commited in my repo on 29 Jul 2009.

After several months I've decided to update ruby-coderay package. There was another amazing [r372] commited on 18 Oct 2009. And fixed with another obvious patch on 09 Nov 2009.

Since Aplil 2009 only one test was fixed by [r361] on 10 Oct 2009.

Bottom line: test suite for CodeRay project has been broken for almost eight months and nobody gives a fuck. Gosh, I LOVE Free Software!

I told ya!

More than three years ago I've reported an issue about filetype detection in Vim.

Vim tries to detect filetype by file name and contents. If there were no match in builtin rules and file contains #-comment in first several lines, it's filetype is set to "conf". But then it sources additional user-provided filetype detection scripts.

There is :setfiletype command, that sets "the 'filetype' option to {filetype}, but only if not done yet in a sequence of (nested) autocommands", which can not be used for files, those filetype already set to "conf" by this fallback code.

I suggested to move loading of user-provided filetype detection scripts above this fallback code and immediately received replies that I "should never create, delete or modify any file in the $VIMRUNTIME directory tree" and "current method is correct"

Finally, new patch appears. After THREE FUCKING YEARS!

I hate them...