Очень интересно наблюдать, что происходит с ruby и rails в этом вашем Сизифе. Почему-то последний ruby ВДРУГ срочно понадобился ООО, да ещё так, чтобы в нём работал redmine. Традиционно на эту работу припахали наименее разбирающихся в вопросе сотрудников, которые тем не менее взялись за дело с большим энтузиазмом. В результате чего ruby в ALT Linux пошёл по пизде, простите мой клатчский.
Сначала эти люди пытались откатить ruby с версии 1.9.2 на 1.8.7, но видимо убоялись анметов. Тогда был реализован хитрый план и появился пакет ruby1.8, который первое время мог устанавливаться рядом с ruby, но потом это безобразие было в корне пресечено заботливо расставленными конфликтами (чем это чревато я неоднократно рассказывал много лет назад, но как известно всем похуй). Обе версии скорее всего оказались нерабочими чуть менее чем полностью, ведь мы помним, что новые мантейнеры ruby языка не знают и фейлящиеся тесты "чинятся" удалением этого теста. Сейчас в Сизиф собирается такой же rails...
К чему я это всё? Не знаю. Получается, что всё что Кирилл и я делали на протяжении последних нескольких лет оказалось никому нахер не нужно. В пересборке 75-и пакетов под 1.9.2 со своими пакетами поучаствовали только greycat@ и zerg@. Зато каждый знает как надо собирать ruby в репозитарий. И какой версии.
А трушные рубероиды как ставили rvm, так и продолжают это делать.
Saturday, April 23, 2011
Friday, January 21, 2011
Monday, December 6, 2010
Ruby vs. Python
Once upon a time, there lived a girl named Red Ruby Hood with
But in the forest girl met Evil Gray Python...
Hate!..
Hate!!
Hate!!!
So, the Python ate girl, her mother, her grand-grandmother and all lumbermen...
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...
Wednesday, March 31, 2010
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:
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:
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:<
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.
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.
• . . . . . .. . . . . . . . . . . ,.-‘”. . . . . . . . . .“~.,
. . . . . . . .. . . . . .,.-”. . . . . . . . . . . . . . . . . .“-.,
. . . . .. . . . . . ..,/. . . . . . . . . . . . . . . . . . . . . . . ”:,
. . . . . . . .. .,?. . . . . . . . . . . . . . . . . . . . . . . . . . .\,
. . . . . . . . . /. . . . . . . . . . . . . . . . . . . . . . . . . . . . ,}
. . . . . . . . ./. . . . . . . . . . . . . . . . . . . . . . . . . . ,:`^`.}
. . . . . . . ./. . . . . . . . . . . . . . . . . . . . . . . . . ,:”. . . ./
. . . . . . .?. . . __. . . . . . . . . . . . . . . . . . . . :`. . . ./
. . . . . . . /__.(. . .“~-,_. . . . . . . . . . . . . . ,:`. . . .. ./
. . . . . . /(_. . ”~,_. . . ..“~,_. . . . . . . . . .,:`. . . . _/
. . . .. .{.._$;_. . .”=,_. . . .“-,_. . . ,.-~-,}, .~”; /. .. .}
. . .. . .((. . .*~_. . . .”=-._. . .“;,,./`. . /” . . . ./. .. ../
. . . .. . .\`~,. . ..“~.,. . . . . . . . . ..`. . .}. . . . . . ../
. . . . . .(. ..`=-,,. . . .`. . . . . . . . . . . ..(. . . ;_,,-”
. . . . . ../.`~,. . ..`-.. . . . . . . . . . . . . . ..\. . /\
. . . . . . \`~.*-,. . . . . . . . . . . . . . . . . ..|,./…..\,__
,,_. . . . . }.>-._\. . . . . . . . . . . . . . . . . .|. . . . . . ..`=~-,
. .. `=~-,_\_. . . `\,. . . . . . . . . . . . . . . . .\
. . . . . . . . . .`=~-,,.\,. . . . . . . . . . . . . . . .\
. . . . . . . . . . . . . . . . `:,, . . . . . . . . . . . . . `\. . . . . . ..__
. . . . . . . . . . . . . . . . . . .`=-,. . . . . . . . . .,%`>–
Sunday, March 14, 2010
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...
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...
Thursday, February 18, 2010
Code WTF
While playing with one opensource project we've found this masterpiece of Hindy C. I will not even comment it.
This reminds me forgotten stories about Miklos...
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...
Tuesday, December 29, 2009
-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.
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.
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.
Subscribe to:
Posts (Atom)