Nicolás Brailovsky

I hate ubuntu, but I hate windows the most. I hate firefox, but internet explorer makes me want to vomit. I don’t like gnome, but kde is uglier. But I love Opera. Well, loved it, I guess version 10.60 will be my last version.

It’s been a loyal application which I’ve been using since its 6.x version. Always fast, with all the functionality I needed (some more too) and none of the bloated BS needed to make FF be a usable (though ugly) browser. It had it’s ussual screw-ups, everyone does, but after I updated to version 10.60 it has become unusable.

Its new features include random crashe, making gmail work really slow (or not at all: the fucking scrollbar won’t work anymore, and keyboard shortcuts in google reader (j & k, next & prev) are foobar’d. Scrolling on a large webpage eats 100% cpu, the upgrade fucked up my nice dark theme (and changed it back to a hellish abomination which seems to be a time-traveller from 1998), and it has random stupid bugs. And I mean STUPID, like, double click a word and the popup menu won’t go away.

I tried to insert this image through WP image uploader, but it doesn’t work anymore in Opera
Fuck. I always liked you Opera, but it seems it may be time to give chrome a chance.

Seen @ http://wiki.wireshark.org/SNMP:

After years thinking and reading RFCs and various other documents, today, I finally understood. “Simple” refers to “Network” not to “Management Protocol”! So it is a Management Protocol for Simple Networks not a Simple Protocol for Management of Networks… That explains why it’s called “Simple”. It was that Simple but it took me years to understand it! — LuisOntanon

Thank you Luis. That explains a lot.

Ubuntu sucks, but less than windows. Gmail sucks, but less than hotmail. Opera rocks, but it tends to fuck up gmail every once in a while. After a lot of research and having found no help on the interweb I traced the problem to having a lot of tabs open for a lot of time (weeks, not hours).

In Firefox this shouldn’t be a problem as having a FF browser open for a week should hog all the memory on its host computer, forcing you to reboot. In Opera, being a little bit better behaved browser, this may actually be a problem.

Luckly the fix is simple: open a Vim editor or take out pencil and paper, make a list of all your open tabs, close opera and using your favourite console type “rm -rf ~/.opera/sessions” (i.e. delete the sessions folder in your .opera dir). Restart Opera and restore your tabs from your backup list. Problem should be gone.

(gvim:13664): Gdk-CRITICAL **: gdk_window_get_user_data: assertion `GDK_IS_WINDOW (window)’ failed
Vim: capté una señal de muerte SEGV
Vim: finalizado.

* Post from the wayback machine. I wrote this a long time ago but it got way down the posts queue, don’t know why *

I liked my vacations very much, thank you. Some people enjoyed vacations from me too. At work they even decided to keep until my return. Upon my arrival a nice coredump was waiting at my desk, so to speak. Check it out, isn’t it beautiful?

Yeah, that’s getting killed inside zlib. Nice way to start the year, a bug in zlib. What led me to that conclusion? Easy, the same compressed file worked in Ubuntu. Must be a bug in zlib then!

The next step was getting zlib’s code and adding enough printf’s to know the problem was in the middle of the file, not at the beginning nor the end; indeed, most of the file could be correctly decoded, but then it just died. This looked more and more like a bug in zlib.

I began to scramble things around, trying to isolate the problem. Things just got weirder, the same code worked fine if instead of being inside a thread I was on the main thread. If you have psychic powers you now have enough information to know what the problem was. Although I should have known too (these wasn’t even the first time I saw a problem like this one!) I was mind set on finding a bug in zlib, which now, it seems, only appears while interacting with ACE (in my defense, I did see these kind of bugs too).

Fiddling around with the code some more, even stranger backtraces began to appear. First this one:

And then this other one, which led me into the right direction:

That last stack trace got me to think how could it be possible for an otherwise working program to coredump while creating an stdlib object. I mean, stdlib is quite well tested, isn’t it? Then it struck me: the keyword isn’t stdlib but creating. It was allocating memory from the stack, upon entering the function.

Some more research later I found out that Solaris default thread size is about 1 mb, while in Ubuntu this thread is of about 8 mb. And I also noticed the buffer I was allocating for zlib was taking up space in… the stack.

If there’s something to learn from this story is that you should always know what goes in the stack: only small objects should live there, and you should always know the max stack depth a function could reach. Otherwise it may come back and bite you in the ass when you’re back from your vacations.

Seen @ bash.org:

< adamkuj> are there any good open source tools for working with Access DB’s (mdb files)?
<@Dopey> rm
Comment: #evilgeeks

True, so true… It’s been said a thousand times, but I kinda like ranting… like it or not Office files are a majority out there. If you work with Linux, using it in a real enterprise environment, sooner or later you’ll run into someone using a propietary Office format. You’ll also run into someone who doesn’t know that you need OOO to open those weird odf files. You may need to produce an adecuately formated document sometime, and LaTeX may not be an option.

Deal with it. Install a VM, or Wine, and a copy of MS Office. Resistance is futile.

Random WTF 1

Note: Use dapper instead of edgy to use Ubuntu Dapper

Thank you captian obvious.

Random WTF 2

I’ve been working with a big-co supplied ACS server, but it’s IE only. WTF!? Aren’t ACS all XMLy so they can work everywhere? I hate you all.

Remember my problems with dual screen support in Ubuntu? Well, I still love bashing Ubuntu, and the sound system in Linux is certainly a topic to rant a lot. Making the sound work fine in Ubuntu is an odyssey in pain and frustration, unless it works fine out of the box. And even if it does, it may still have it’s kirks. Lots of them. In my case the sound starts in mute. I know it’s a problem with pulse (which is a WTF in itself) and alsa, I don’t really care what’s the problem though, I just want to play my mp3s collection without having to carefully turn the knobs up to eleven in alsamixer.

After trying a lot of the “solutions” found on the internets I’ve decided the best thing to do, short of switching back to windows me, is adding the following to my “fix_ubuntu_fuckups.sh” start script, which already contains my dual-screen pseudofix:

This sets alsamixer to normal volume levels. As for the real fix, I’ll wait till the next Ubuntu version. I wonder which sound subsystem will they chose next time.

Thank you very much, Oracle Berkeley, for having a type named Db and another one named DB, and for never using namespaces. It makes my work a much more interesting challenge (*).

(*) Yeah, I know, Db is for the C++ wrapper and DB is for the plain C API (**). So what, I hate you all anyway.
(**) I’m working on a project with Berekley DB and it has enough WTF moments for a complete blog… I may post some of them, as a catharsis method. (***)
(***) Or because it has some interesting stuff too… who knows. Recursive note FTW (**). I think I have already done that, haven’t I?

Last time I told you about an evil snipet I found on Oracle Berkeley DB’s manual:

And we concluded it’s trying to… well, dereference a number. And yet it compiles. What the hell is going on there? The answer here is in the subtleties of the sizeof operator. That’s right, operator, not function. Plus is an operator. Less is an operator. * is a (unary) operator. sizeof is a unary operator too. The relevance of this is that operators can behave in more bizzare ways than functions do. In this case there’s a difference between this two lines:  MyClass x;   int a = sizeof(MyClass);   int b = sizeof(x);

A very subtle difference. Can you spot it? a and b will have the exact same value, rest assured. The difference is in the operator itself: sizeof MUST have parenthesis when applied to a type name, yet parenthesis are optional when applied to an instance of a datatype, so this code is legal:

Oh, wait, the fun doesn’t stop there: sizeof also has bizarre precedence order, meaning it won’t get applied as you expect it. So, this is valid too:

Can you see where we are going? Knowing that sizeof will be applied last lets you write something like this too:

Which means nothing else than “store in b the size of member y in struct X. It should be easy to see why BDB’s example does compile, and why did I spend half an hour trying to understand the reason it compiled fine.

By using some more casts and a clever arangement of parenthesis you can come up with a great job security device.