It seems like the Eazel name has moved on.
The last couple of weeks I have been working on Sabayon, an application that some other Red Hat people started on earlier this year. Its an editor for user profiles, where you can set up settings and add files for a class of users and easily push them out to users. Today I released version 2.12.1, which has a bunch of fixes and new features.
The interesting thing about Sabayon is the way you edit the profile. Instead of using a completely new interface it uses the standard interface you normally use. This is accomplished by launching an actual desktop inside a window, letting you make your changes in that desktop and then save it. You can also look at the changes that has happened in the session and ignore some of them, or make some of them mandatory.
Just describing Sabayon isn’t doing it justice though. To really see how this is different from other similar things you have to see it in action. So, I prepared a screencast
Once you’ve finished editing your profile it will be stored as a zip file with xml metadata that can easily be applied to a user by running the sabayon-apply tool. There is also support for deploying the profiles from a central http server.
I think this is a really cool app, but I’m a programmer, not really an administrator. I wonder what system administrators think of this? Is it an interesting approach? Is it better than what you’re using currently? Would you use this?
If you want to test Sabayon I recommend you use version 2.12.1. Its currently building in Fedora extras, so it should be available soon.
Recently I’ve been researching a bit into requirements and usecases for a new canvas for Gnome/Gtk+. One of the important features of a canvas is the ability to embedd normal Gtk+ widgets into the canvas and have them integrate nicely. This means the embedded widgets should properly stack with other canvas items, and (less importantly) they should support arbitrary transformations.
The problem with this is that widgets in Gtk+ use child X windows, for clipping/scrolling and to get events. These windows are managed by X and won’t correctly mix with the drawing of the other items in the canvas. This can be seen in the widget item in gnome-canvas, which just doesn’t work very well.
An obvious solution to this is to render the whole widget to an offscreen pixmap and then just copy that translated to the canvas when rendering the canvas item. However, currently there isn’t a way to render Gtk+ widgets to a pixmap. There are some hacks you can use, but they don’t work at all for widgets that have child windows.
This week I’ve been working on a change to Gdk that will allow it to take any GdkWindow and make it (and its children) into an offscreen pixmap, much like the Composite Extension but client-side. Once we have this you can do all sorts of effects with widgets, just like Composite allows effects on a larger scale.
Yesterday I managed to get it to render an actual widget tree for the first time, so I hacked up a simple demo to show off the sort of things you can do with this:
When seen live the water effect actually moves, as can be seen here.
This work is not nearly finished, I haven’t even started to think about how do handle input events, but it does look promising.
Yesterday our new household member arrived:
The kittens mother is the cat of my wifes sister, and she (the cat that is) is also staying at our place for the weekend:
We haven’t decided on a name for the kitten yet. We need to get to know her a bit first.
Kittens are like little packages of energy. You get tired just looking at her for 5 minutes. Climbing the plants, running around, eating the furniture, fighting with her mother…
I’ve been debugging some Nautilus crashers today. It involved decoding
backtraces, and since this is a useful thing to be able to do I
decided to do a writeup about it:
Many bugs that get reported contain backtraces, mostly thanks to
bug-buddy. However, many of these reports where made on a system where
the programs and libraries involved didn’t have debug
information. Having the reporter retry with a build that has debug
info (manually built or with debuginfo packages) help tremendously
with debugging the problem.
However, its often hard to get this, as bug-buddy reports are rarely
followed by the reporter, and the bug might be hard to
reproduce. Thus, its important to learn to read backtraces without
debug info. Such backtraces have several issues:
- They contain no line number information, so you don’t know where in
a function something happened
- You cannot see the values of arguments and local variables
- You cannot trust the function names given in the backtrace, since
the debugger doesn’t know about static functions.
The first two issues you just have to accept, as there is no way to
extract such information. However the third issue can often be worked
around. This means you can get a mostly accurate trace of what
happened before the crash, which can help you figure out the
To decode such a backtrace you have to know how the debugger generates
the backtrace. The debugger locates the active stack frame on the top
of the stack by looking at a register. Each such frame contains a
pointer to the invoking frame, plus the address where execution should
continue when that frame returns. Using these addresses, plus the current
instruction pointer, the debugger can figure out which function was
executing. There are two problems though:
- If the last thing function foo() does is call function bar() and
return its return value (or bar() returns void) the compiler can do an
optimization so that the return from bar() immediately returns to the
function that called foo(). This means such functions will not be
visible in the backtrace.
- The way gdb figures out what function is executing is by looking at
the program/library symbol tables, combined with knowledge about where
in memory the code was loaded. The last function symbol before the
executing address is selected. However, in our case the static
functions are not in the symbol table, so the result is the nearest
non-static function before the actual function.
Armed with this knowledge and the code for the application you can often
figure out what functions were actually called. Its important that the
code you look at is about the same version as the reporter, since
changes to the code affect the result you get.
As an example, let me take bug
302096, a nautilus crasher bug that was recently reported. There
are multiple duplicates, all without debug info, and with very vague
reports of how this actually happened.
Here is the backtrace from the bug:
#0 0xffffe410 in __kernel_vsyscall () #1 0xb7c0148b in __waitpid_nocancel () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb7dddd97 in libgnomeui_module_info_get () from /usr/lib/libgnomeui-2.so.0 #3 #4 0xb77a2a8f in g_type_check_instance_is_a () from /usr/lib/libgobject-2.0.so.0 #5 0x08088666 in nautilus_window_open_location_full () #6 0xb7fb9785 in nautilus_window_info_open_location () from /usr/lib/libnautilus-private.so.2 #7 0x08092423 in fm_directory_view_confirm_multiple_windows () #8 0x0809db34 in fm_directory_view_notify_selection_changed () #9 0xb7f6fcbb in nautilus_directory_add_file_monitors () from /usr/lib/libnautilus-private.so.2 #10 0xb7f70c27 in nautilus_async_destroying_file () from /usr/lib/libnautilus-private.so.2 #11 0xb7f7347f in nautilus_directory_async_state_changed () from /usr/lib/libnautilus-private.so.2 #12 0xb7f7243a in nautilus_directory_force_reload_internal () from /usr/lib/libnautilus-private.so.2 #13 0xb774fb67 in _gnome_vfs_job_complete () from /usr/lib/libgnomevfs-2.so.0 #14 0xb77500a2 in _gnome_vfs_job_complete () from /usr/lib/libgnomevfs-2.so.0 #15 0xb75d1a03 in g_child_watch_add () from /usr/lib/libglib-2.0.so.0 #16 0xb75ced0f in g_main_depth () from /usr/lib/libglib-2.0.so.0 #17 0xb75cfcb5 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #18 0xb75cffd7 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #19 0xb75d051e in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #20 0xb79bd10f in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #21 0x0807878a in main ()
Frame 0-3 is just the crash and bug-buddy handling it, so we ignore
those. Frame 4 tells us the crash was likely a NULL pointer or an
invalid pointer passed to some gobject type check. The interesting
parts start at Frame 5.
Looking at the code we see that both
nautilus_window_info_open_location() are followed immediately by
non-static functions. Also, nautilus_window_info_open_location() calls
nautilus_window_open_location_full(), so these are probably right.
However, fm_directory_view_confirm_multiple_windows() is followed by
multiple static functions, and it doesn’t call
nautilus_window_info_open_location(). We then search for a
nautilus_window_info_open_location() call below but before the next
non-static function. Fortunately we only get one hit, open_location().
Doing the same with #8, fm_directory_view_notify_selection_changed() shows
that this must be activate_callback().
#9 is a bit trickier since activate_callback() is a callback
function and won’t be called immediately. However, its only used in
one place where its passed as callback to
nautilus_file_call_when_ready(). So, we start from
nautilus_directory_add_file_monitors() and look for a callback that
would result from such a call. There are not many functions to choose
from, and obviously the call must be from ready_callback_call().
#10 is found out to be call_ready_callbacks() by a simple search. #11
has no non-statics, so it must be right.
#12 is harder, it could be
right, since nautilus_directory_force_reload_internal() does call
nautilus_directory_async_state_changed(), but there are no less than
11 other such calls before the next non-static function. Here we have
to use our knowledge of the code, and the other information that the
bug reporters gave about what they were doing at the time of the
crash. One way forward is to just guess which call was right and work
from that. If you then get a backtrace that makes no sense you know
you picked wrong.
In the bug you can see that I initially guessed that #12 was
nautilus_directory_force_reload_internal() (although I now believe
this to be wrong). #13 is in gnome-vfs, which doesn’t call
nautilus_directory_force_reload_internal(), but there could be one or
more hidden stack frames here, so I greped the code for calls and
found nautilus-vfs-directory.c::vfs_force_reload() as the only
caller. This function ends with a call to the other function and
returns void, so its a likely candidate for the return optimization
meaning it makes sense that its not visible in the backtrace. I
continued a bit after that, but wasn’t able to follow the trace very
long, since there was too many possibilities.
When you’ve finally decoded the backtrace, or at least parts of it you
need to figure out how this set of calls could have resulted in a
crash. For that, you’re on your own. But at least now you have a bit
more information that can help you.
Today I got a call from UPS saying they were gonna deliver a package to me later today. I immediately realized that this must be the G5 I won in the Linux on POWER contest.
A couple of hours later the UPS guy arrived. I signed my name on the electronic signing thingie (unreadable as always, does that thing have a 10×10 resolution or what?) and I got this box:
I’ve now installed Fedora Core 4 on it, which seems to work perfectly. I’m also playing around with OS X which was preinstalled. Unfortunately it was only 10.3, so I can’t play with the new Tiger features.
Now, all I got to do is figure out where the heck to put it. I already got a bunch of other machines at this desk:
I’m having problems explaining to my girlfriend (soon to be wife!) why I really need this extra computer in addition to all the old ones. She thinks I should just throw away one of the old machines. I think I need to polish my arguments a bit…
I’m not sure how the “is Gnome fun” discussion turned into a language
discussion. I would personally perfer using either C# or Java over C
to code a new app these days. However, using C is not what makes
hacking Gnome less fun than it used to be for me.
What makes Gnome less fun for me is the fact that Gnome is a stable
high-quality codebase that I’m spending all my time maintaining. Each
little change has to be very careful about not breaking backwards
compatibility or introducing bugs and each new features must be very
well understood and known to be right (because its very hard to get
rid of it later). Most time I spend on gnome is reading bugzilla,
fixing bugs in old code, discussing each little change forever,
reviewing patches and saying no to feature requests. In essence, I
have become a maintainance programmer, not a software developer. Of
course, at times I do new development, but it is far more seldom than
it used to be, and I almost never have time to do experimental stuff.
One reason using C# or Java would make things fun for me is because it
would basically force me to work on a new application from scratch,
which means I wouldn’t have to care about all these things and just go
wild experimenting and hacking. Of course, there isn’t much chance for
me to do that because even if I did start working on a new app I’d
still have all the old code I’d have to maintain.