ALT Linux

From wRAR with HATE...

Ruby vs. Python

Once upon a time, there lived a girl named Red Ruby Hood with Hash h={:foo => "foo_val", :bar => "bar_val"}. Her mother gave her "quux" variable with value "quux_val" and told to print all this shit to he gand-grandmother, who lived far beyond the forest. Long story short, girl uses String.%:

$ irb
irb(main):001:0> h={:foo => "foo_val", :bar => "bar_val"}
=> {:foo=>"foo_val", :bar=>"bar_val"}
irb(main):002:0> puts "Teh %{foo}, teh %{bar} and teh %{quux}" % h.merge({:quux => "quux_val"})
Teh foo_val, teh bar_val and teh quux_val
=> nil
irb(main):003:0> h
=> {:foo=>"foo_val", :bar=>"bar_val"}
irb(main):004:0>

But in the forest girl met Evil Gray Python...

$ python
Python 2.6.6 (r266:84292, Oct  1 2010, 13:15:00)
[GCC 4.4.4 20100726 (ALT Linux 4.4.4-alt3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> h={"foo": "foo_val", "bar": "bar_val"}
>>> print "Teh %(foo)s, teh %(bar)s and teh %(quux)s" % h.update({"quux": "quux_val"})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: format requires a mapping

Hate!..

>>> tmp = h.copy().update({"quux": "quux_val"})
>>> tmp

Hate!!

>>> tmp = h.copy()
>>> tmp.update({"quux": "quux_val"})
>>> tmp
{'quux': 'quux_val', 'foo': 'foo_val', 'bar': 'bar_val'}
>>> print "Teh %(foo)s, teh %(bar)s and teh %(quux)s" % h
Teh foo_val, teh bar_val and teh quux_val

Hate!!!

So, the Python ate girl, her mother, her grand-grandmother and all lumbermen...

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.