Archives for: 2006
So, someone hanging around here in Villanova (or maybe still sleeping, who knows?) got my keychain card thing. It'd be pretty cool if he/she could give it back, so I can at least have food tomorrow...
wingo, yours is at the Fluendo booth in the main building.
This entry might bore most of you, upset some others, and could be useful for some. Sorry!!!
Last 3 days I've been reading (in my study pauses ;-)) on code optimalisation (both code speed and memory) and DSO pitfalls (pointers and some samples might follow later).
One of the things I read was a paper by Ulrich Drepper (Glibc guy), where one of the samples was about string duplication (strdup) optimalisation.
I looked into the Glib (no, thats not glibc) code to see how it was handled there, and found a simple, straight-forward, (unoptimized) implementation.
So obviously, I wanted to find out if this could be somewhat optimized. So I started my precious gvim, and made a testcase, which does some (well, a lot of) different duplications, both using g_strdup and my own little implementation.
An overview of what the test code does:
- Do one simple strdup using g_strdup, and free the result (so the test is "fair", think of relocation time)
- Copy, print and free a compile-time constant string, a variable string (argv), and an empty string (strlen printed here) to make sure the code works fine
- In a loop of 10000000 iterations, duplicate a constant string, a variable one (again, argv) and an empty one, and free them
Why always a constant string, a variable one and an empty one? Simply because my implementation tries to handle these cases in the most efficient way ;-)
Here's the result:
nicolas@marslander ~/tmp $ gcc -o my_strdup_test -O2 `pkg-config --cflags --libs glib-2.0` g_strdup_test.c g_strdup_test.c:9:10: warning: #warning "Using own implementation" nicolas@marslander ~/tmp $ gcc -o g_strdup_test -O2 `pkg-config --cflags --libs glib-2.0` g_strdup_test.c -DUSE_G_STRDUP g_strdup_test.c:5:10: warning: #warning "Using g_strdup" nicolas@marslander ~/tmp $ ./g_strdup_test > /dev/null && echo -e "g_strdup_test:\n==============" && time ./g_strdup_test && ./my_strdup_test > /dev/null && echo -e "my_strdup_test:\n===============" && time ./my_strdup_test g_strdup_test: ============== foo = foo ./g_strdup_test = ./g_strdup_test 0 = 0 real 0m9.438s user 0m8.968s sys 0m0.064s my_strdup_test: =============== foo = foo ./my_strdup_test = ./my_strdup_test 0 = 0 real 0m5.906s user 0m5.627s sys 0m0.033s
I know 'time' is not a very good benchmark, but I guess the result is fairly obvious.
This result is +- the average, g_strdup version ranging between 9.4 and 9.6 seconds, mine between 5.8 and 6.1 seconds. This is a 30-40% speed gain, not wasting more memory.
Obviously, not all duplications would become faster. Actually, only the ones of strings which are constant at compile-time. In some applications this can be a major amount of g_strdup calls though.
I should note this "enhancement" is only possible when GCC is used as compiler as it uses some GCC-specific extensions. This is not an issue though, as on other compilers the code won't become slower :-)
The code I used can be found here. I added comments to make some things easier to understand (I hope), but the code is not "clean". A check for GCC should be added etc, but hey, this is just a proof of concept.
I really like these rather low-level optimisation things. They allow a lot of applications to become more efficient without changing the actual app, and low-level code is fun.
I'll read some more about this, and try to blog about interesting papers/techniques/... too, got some things in mind, but lack time now (yeah, those exams).
Luckily the end is in sight, and so is GUADEC :-) Booked my plane some days ago, still awaiting one email about lodging stuff. I'm so glad and thankful I'll be able to be there. Great start of holidays ;-)
Enough now, more algebraics and geometry to learn...
As I'm not allowed to code last days (studies >:() I tried to get something working I wanted for a long time: be able to run my favorite media player on my desktop (I must confess that's Amarok), and playback the music using a hifi chain in another room.
As currently I don't have a wifi network at home, I can't do "the real thing" yet, but testing can be done using usbnet (little howto on how to set up that might follow later).
After lots of searching and great help on several IRC channels, I got things working fine now.
Let's start with a little overview of the setup.
- Music player: Amarok using the Xine backend, using alsa
- Streaming server: Icecast2
- Icecast source: gst-launch using the shout2cast sink
- Just the standard audio player
Here's how to set up things correctly:
- Install icecast2 on your system (this is distribution dependant)
- Configure the server. You can run icecast as a system service, or as a normal user. I chose to run it as a normal user:
- Copy /etc/icecast2/icecast.xml to some directory
- Change "logdir" to some directory you got write permissions for
- Start the server: icecast -c icecast.xml (add -b to daemonize)
- Start some media player
Now we got to get the media player's output to our icecast server. As the 770 cannot playback ogg/vorbis, but can handle mp3, we'll use mp3 here. I know that might be non-free etc, but let's be pragmatic.
To get the alsa sound to the server, one might use DarkIce, but I could not get this working, so I used a simple gstreamer pipeline instead:
gst-launch-0.10 alsasrc device=plughw:0,0 ! audioconvert ! lame ! shout2send mount=amarok
You might need to change the "device" parameter, you can change the "mount" parameter of shout2send too (although you'll have to adjust the URI used later too, of course). I'm using the default password ("hackme") in this setup, if you don't, or want to set other options, see
gst-inspect-0.10 shout2sendfor more info.
- When that's running fine, open a browser, and go to http://localhost:8000. If all goes well, the "amarok" mount should be listed there. Do not open the stream, as this'd create a loop!
- Finally, launch the audio player on your 770 device, open the menu, "Playlist -> Add Stream...", and enter here the URI of the stream. In my setup, this is http://192.168.2.1:8000/amarok. Now start playback.
- The 770 should buffer some data, then start playback.
Currently, I stream my Amarok's output to my device using usbnet, and got my normal computer speaker connected to the jack output. Works fine :-)
If you're using Amarok too, take a look at the "Web Control" script. When running this script, you can open the 770's browser, and browse to http://192.168.2.1:4774 (adjust the IP). Now you're able to control Amarok from your device, and look at the current playlist. No need to walk to your desktop. The web interface might need some love though.
That's about it, have fun!
1. I got a SoC assignment, at Gentoo. I'll be (actually I am) working on Gentoo's NetworkManager backend and integration into the distribution, next to more general NetworkManager hacking (although some people seem to dislike that somehow :|).
2. I might be able to come to GUADEC, jay!
3. Experimented with SystemTap today. After seeing the DTrace demos at Fosem06, I was fairly impressed. Systemtap is no DTrace-for-Linux yet, but I the scripts I was able to run were pretty promissing.
Little HOWTO (on Gentoo, but should work on other distributions too):
$ (cd into some project folder, I used ~/Projects/systemtap)
$ mkdir elfutils && cd elfutils
$ wget ftp://sources.redhat.com/pub/systemtap/elfutils/elfutils-0.120.tar.gz ftp://sources.redhat.com/pub/systemtap/elfutils/elfutils-portability.patch
$ tar -zxf elfutils-0.120.tar.gz && cd elfutils-0.120
$ cat ../elfutils-portability.patch | patch -p1
$ cd ..
$ cvs -d :pserver:email@example.com:/cvs/systemtap login
(pass is "anoncvs", no quotes)
$ cvs -d :pserver:firstname.lastname@example.org:/cvs/systemtap co systemtap
$ cd src
$ ./configure --prefix=/path/where/you/want/the/stuff --with-elfutils=/path/to/patched/elfutils
I used ~/Projects/inst as prefix (expanded), and ~/Projects/systemtap/elfutils/elfutils-0.120 as elfutils path
make failed for me (GCC4.1.1) due to usage of -Werror in elfutils. I had to add a -Wno-error in elfutils/elfutils-0.120/src/Makefile.am on the appropriate place (you should be able to do that yourself).
$ make install
Now we need a kernel with debug info, and kprobe support.
$ cd /usr/src/linux
$ make clean
$ make menuconfig
Configure the kernel like you would normally. Make sure you change the "Local version" under "General Setup". I added -dbg to the string I already got there ("-ck1-ikke2-dbg"), so your "normal" kernel modules won't be overwritten.
Then you need these options. This list might not be complete though:
- Instrumentation Support -> Kprobes
- Kernel hacking -> Compile the kernel with debug info
- Kernel hacking -> Compile the kernel with frame pointers (this might not be necessary)
$ make modules_install
The generated kernel will be big:
# du -sh /lib/modules/126.96.36.199-ck1-ikke2-dbg/ /usr/src/linux/vmlinux
and compilation (actually, linking) might take longer than normally. Used diskspace will be much higher too.
$ cp /usr/src/linux/vmlinux /lib/modules/2.6.18-ck1-ikke2-dbg/
Now install the kernel like you normally would. I didn't put it as my default kernel in grub.conf though.
When you're done, reboot inside the new kernel. I booted into single user mode (by appending "1" to the GRUB line), just to be on the safe side.
Log in as your normal user on the console.
$ cd Projects/systemtap/src/examples/small_demos/
$ ~/Projects/inst/bin/stap top.stp -v
stap will show what it's doing. In the end, sudo will be called to insmod the generated module. Enter your password. Make sure the user is allowed to use sudo with the specific program (run with one more -v to see the specific call).
When it says everything's up and running, try switching console, type in some characters,... And see what system calls these actions generate.
As you're in single user mode, you can only use one tty. Run the stap instance in a screen session to get rid of this ;-)
Whe done, press ^C to quit. You can play around with some other sample scripts too, or try to write one yourself. I didnt manage to get some of the scipts working on my system yet though. Didn't think too much about it either :-)
Thats it, have fun!
4. Started reading "Linux Device Drivers, 3th edition", at chapter 6 now. Cool stuff, concurrency and locking (ch5) seems to be a fairly difficult issue. It is in userspace (threading), seems to be even harder in kernel space imho.
5. First exam tomorrow, "Rights of Intellectual Property". Wish me luck ;-)
Been busy lately due to uni work, so not much hacking time. I did enhance that messaging thing a little (not working on other stuff I'd like to work on yet as they're potential SoC projects :-)).
wall, write and other pty based communication support still isn't in there as I didn't manage to get something working (yet). Must be doing something completely wrong somehow.
I did add a "Reply" option to the incoming messages though. Currently the reply dialog is not HIG at all, no I18N support, it's crap PyGTK code, but it does work somewhat.
Here's a little demo (1MB animated GIF screencast, thanks Byzanz (and Company)!)
I made a first "release" for people who's want to play with this. You can find the tarball here, but note it needs work: checking for Python stuff in configure.in, fixing Python code, adding I18N support, get the dialog code inside the C daemon, as using a helper is plain stupid (I use a helper as it's pretty easy to create a GUI using PyGTK quickly).
TODO: incoming message throttling (so one can't flood you using smbclient in a shell for loop), I18N (damn intltool 's been driving me crazy), nicer UI, other messaging "protocol" support, get a Telepathy backend out of this (jdub's idea),...
Davyd talked about integrating good old messaging systems like talk, wall, write and even WinPopup into the GNOME desktop. As it looked like a fun thing to do, I got my hands down on it today.
I still couldn't figure out how to catch wall and other pty-based messages, but I'm sure I will be able to get them working too.
At the moment, WinPopup messages work:
Maybe in-time one should be able to click the message popup and get a simple window allowing the user to reply on the incoming message, but thats to be done later on, first I want to get wall and talk requests working fine.
A little change to smb.conf is needed for this (the "message command" line should be set, I'm using a Python script to send the messages), and one file in the D-BUS system.d to allow the user Samba uses to spawn the message command ("nobody" on my system) to send messages on the system bus.
Obviously pty-based messages shouldn't need a callout anywhere.
Current code isn't ready for release yet (at all), I'll try to get what I got into good shape asap.
As it starts to take over 5 minutes every day to attempt to remove all comment spam I receive on my weblog (like RealNitro), I added a new .htaccess rule to block the spammers if possible. Next to a referer check on post_comment.php, I denied access to everyone using pinappleproxy. I hope this doesnt cause too many issues for people visiting this (sub)domain...
Don't like Perl? Maybe you will now:
#! /usr/local/bin/perl -w use Lingua::Romana::Perligata; maximum inquementum tum biguttam egresso scribe. meo maximo vestibulo perlegamentum da. da duo tum maximum conscribementa meis listis. dum listis decapitamentum damentum nexto fac sic nextum tum novumversum scribe egresso. lista sic hoc recidementum nextum cis vannementa da listis. cis.
Which is translated to:
print STDOUT 'maximum:';
my $maxim = ;
my (@list) = (2..$maxim);
while ($next = shift @list)
print STDOUT $next,
Lots of traffic on GIMPNet today, many different and interesting things were discussed between some GNOME hackers. But I guess others will write about those things (Philip? Jeff?).
Anyway, more related to myself and my own project (yeah, CDIS, you know): I had a great talk with Robert "Robot101" McQueen, who gave some very sensible insights in the D-BUS system, and how I could (ab)use it.
First of all, last night I was thinking about the D-BUS glossary a little, and came to the conclusion that "interfaces" might at a certain level be compared to "namespaces" instead of "interfaces", at least in some point of views. Might be interesting if you try to "get" D-BUS. Questions? Leave a comment ;-)
After this talk and some help from J5, #1 python-dbus guru, I managed to get a new sample setup working. In this new design, there is no central daemon at all any longer, which is great, obviously. Some changes/enhancements to the D-BUS bindings might be necessary though (I hate the fact you can't get the sender service/object path in a signal handler!).
As a picture says more than a thousand words, first open up this screenshot. Code's here.
As you can see, first the user starts his favorite media player, RhythmBox, and spins his favorite song (1). In the background, a screensaver application is running (in the sample I started it after RB, but hey, its a sample) (2). After a while (3 seconds ;-)), the user starts his VoIP softphone, Ekiga (3). As the user is very popular, he almost immediately receives a call, and accepts it (4).
As you can see, Ekiga knows about music players, and asks them to pause playback. RB is CDIS-aware, and stops playing (5). Obviously, the music player should do a generic "Paused" signal here (see later). Next, Ekiga sends out a signal on the org.freedesktop.CDIS.SoftPhone interface, "IncomingCall". This signal can be used by any application listening for it. It is not related to pausing music players: in (4-5), Ekiga tells all music players to pause. It knows about this kind of applications, and knows how to handle them. In (6) Ekiga provides application types it doesn't know about (or, maybe more likely, doesn't want to know about, doesn't care about) to do some action based on the fact there's an incoming call.
As this is a video conference, the screensaver traps that signal, and stops his internal timer (7).
After a while, the call is over, the user disconnects (8). Ekiga sends now tells all music players they can resume playback if they were playing before (9). It also sends out a "CallTerminated" signal on the SoftPhone interface, which is again seen by the screensaver, who restarts his timer.
Then, something happens that will/should not be supported, but I just implemented it as a sample. When the screensaver decides it's time to blank the screen (11), it tells all SoftPhones to go "Idle" (12). This is not the way we should handle this in "real" applications, as a screensaver should not put SoftPhones in idle state, it should send out a signal "ScreenSaverStarted", the softphone should watch for that one, and go idle when the screen blanks. Anyway, I just wanted to give one more example of the "action" paradigm, just like "Pause" and "Resume" on the MediaPlayer interface.
As usual, the prototype code is extremely ugly, but it does show what I got in mind regarding code generation. There should be 3 "objects":
- CdisMusicPlayer: inherited by a "real" music player, or by some internal CdisHandler object. Needs function pointers to all supported CDIS function calls. In the sample, used by RhythBox.
- CdisMusicPlayerController: Used by code that wants to control a class of applications. Used by Ekiga to pause all music players. Only provides "active" functions that, when called, result in a change on remote objects.
- CdisSoftPhoneClient: helper class for "generic" applications that want to be notified about things by a SoftPhone application. Used by ScreenSaver to be able to work with SoftPhone applications on the system, as the SoftPhone doesnt know about screensavers
For all of these objects, I'm sure there's some pattern for them. Philip, help! :-)
This should be fairly clear I guess... If not, ask. Lots of things can/will/should change, eg authorisation, and issue raised by sri yesterday. Don't know yet how this should be tackled thogh.
Duplicate events should be prohibited too (although this can for a big part be done by having well designed interfaces): when app A asks MusicPlayers to pause, then B does the same, and A sends a "Resume" signal, the player(s) should not resume unless B also sends the "Resume" command. This and other issues will need to be fixed!
After all a pretty fun day :-) Although you can't imagine how much I hate Blast by now :> Big thanks to all help on IRC, I should get all of you a beer at GUADEC. Sadly enough due to exams I can't be there though ;-)
First of all: Evolution is sooooo "1337":
Guess what: I've been thinking some more about CDIS. Yesterday I had a little discussion about it on #gnome-hackers with Robot101, who seems to have some good knowledge of D-BUS. Obviously, he rejected the idea of adding one more daemon. Indeed, it shouldn't be there, I hate it myself too, but currently it's the only solution to get things working.
He suggested to specify some well-known service and object names, and call methods on the desired services that way. This is not a possible solution though: think of someone running 2 VoIP softphones (eg Ekiga and Skype), 2 IM clients (Gossip for Jabber, aMSN for MSNP),... A service is unique for one application.
So some other solution should be found.
The best one, IMHO, is to add a method to the org.freedesktop.DBus service/object, something like "GetObjectsByInterface", which accepts a string, and returns an array of (servicename, objectpath) tupples, both strings. Using that one can do a specific call on all objects that need to be called.
Next to that, there's the versioning issue. If I remember correctly, a long long time ago this has been discussed on the D-BUS mailing list, and people decided interface versioning support wouldn't be added to D-BUS. As the CDIS interface specifications won't ever be "final", it should be possible to get around this.
It's not that hard though. We can use the standard x.y versioning system, x.y is backwards compatible with x.(y-1), so in a version bump from x.y to x.(y+1) only methods or signals can be added. Bumping x allows a complete API break.
Like this, if we release version 1.2 of the org.freedesktop.CDIS.FooInterface interface, and application FooApp got an object implementing this interface version, it should register itself to the D-BUS sessionbus, and tell it it implements org.freedesktop.CDIS.FooInterface.1.0, org.freedesktop.CDIS.FooInterface.1.1 and org.freedesktop.CDIS.FooInterface.1.2. Now if some other application wants to call a function added in version 1.1 of our spec, it just checks what service/objectpath pairs implement org.freedesktop.CDIS.1.1, and calls the method(s).
All this can be done behind the scenes by some helper library that makes it easier to make applications CDIS-aware.
As now is the time to come up with some project for Google's Summer of Code, I think it'd be great to work on this (now don't steal the idea). The only issue is: would someone be willing to mentor this?
I'd like to do the initial work somewhere under the hood of the GNOME project, if that'd be possible/allowed/accepted.
Here's a TODO:
- Add the previously described method to the D-BUS service
- Come up with some XML format to define CDIS interfaces, including interface version support
Write code generators that generate helper libraries based on these XML descriptions. Some ideas:
- Plain C: using vtables with function pointers
- GObject: standard GObject things like signals and GObject interfaces
- Python: decorators
- CLI/C#: decorators too
The helpers should use the language-native D-BUS bindings, which makes things easier to debug (IMHO)
- Write up an initial interface for some specific service type, and make some projects ("servers") aware of it
- Change some other applications ("clienst") so they can make use of the servers
Regarding the helper libs: these should abstract the complete D-BUS backend and versioning issues from the actual application. An application should just initialize it, say "Hey, I'm a MusicPlayer, I want to support version x.y of the org.freedesktop.CDIS.MusicPlayer interface, here are my callbacks".
/* Hello world, I want to implement a CDIS interface */ CdisMusicPlayer *cdis_self = cdis_musicplayer_new("1.2", "com.eikke.CoolPlayer", "/com/eikke/CoolPlayer/CDISController"); /* When a client makes a "pause" call to apps implementing org.freedesktop.CDIS.MusicPlayer, please jump to myapp_playback_pause * This uses D-BUS methods */ cdis_musicplayer_set_playback_pause_cb(cdis_self, myapp_playback_pause); /* Hey listeners out there, I started playback * This sends out a D-BUS signal */ cdis_musicplayer_playback_started(cdis_self);
Next to the server object, there are clients:
/* Hey, I'd like to control music players. I support version 1.5 of the org.freedesktop.CDIS.MusicPlayer interface */ CdisMusicPlayerClient *c = cdis_musicplayer_client_new_with_bus("1.5", my_dbus_connection); /* If a player starts, please run this callback */ cdis_mediaplayer_client_set_playback_started_cb(c, playback_started); /* Tell all MusicPlayers to pause */ cdis_mediaplayer_client_pause(c);
Maybe the "object" instance isn't even necessary!
Behind the scenes, when the client calls cdis_musicplayer_client_pause(), the helper will know this method was added in version 1.1 of the specification. It will request a list of all service/object-pairs that implement the org.freedesktop.CDIS.MusicPlayer.1.1 interface from the D-BUS service, and do the Pause() call on all returned objects.
When the server "connects" to the system, telling it implements version 1.2 of the spec, the helper will connect to the session bus and will tell the D-BUS system the object implements org.freedesktop.CDIS.MusicPlayer.1.0, org.freedesktop.CDIS.MusicPlayer.1.1 and org.freedesktop.CDIS.MusicPlayer.1.2.
Like this it should be fairly trivial to make existing and new applications CDIS aware. And that's the way it should be ;-)
Obviously, an application could use "pure" D-BUS calls to handle all this itself too. But why make things so complicated?
Next to that, it should be possible to write "testkits" too, based on the XML specs. Python might be very usefull here. One test then looks up the highest version of the spec, and executes all methods new in this version on all objects claiming to implement the interface. Then it takes the last-but-one version, and does the same thing, all the way down to x.0. This way an application developer can easily check whether his application is CDIS compliant. This needs some more thinking though ;-)
Anyway, lots of things to be done, and obviously, not all of this can be done in only 2 or 3 months. Still, some results/progress can be made, and I'm 99% certain incorporating this in the desktop would be a great thing.
I know one should just apply for SoC without thinking about a mentor. I would like to know someone'd want to be mine though before applying (just to be on the safe side), so if these things interest you and you want to get some experience on the mentor side of things, please let me know!
Writing code on easter day, after spending a day with your family (including the obligatory champagn/wine/beers) isn't such a good idea (#gnome-nl):
23:43 <@ikke> damn, help! 23:43 <@ikke> g_return_if_fail(foo() != TRUE) 23:43 <@ikke> returnt dat nu al foo() TRUE is, of FALSE? 23:43 <@ikke> ik ben helemaal aant flippen :s 23:43 <@kris> het failt als foo() != TRUE niet true is 23:43 <@kris> dus als foo() true returned 23:43 <@ikke> dus returnt als foo true is 23:43 <@kris> oh nee 23:43 <@kris> wacht ff 23:43 <@ikke> kijk, jij ook al :p 23:44 <@kris> all foo() false returnt, is foo() != TRUE true 23:44 <@kris> ja 23:44 <@kris> dus het failt als foo() true returnt 23:44 <@ikke> dus ie returnt als foo true is 23:44 <@kris> want dan is foo() != TRUE false 23:44 <+qball> leuk he :D
For the people who dont know dutch out there:
23:43 <@ikke> damn, help! 23:43 <@ikke> g_return_if_fail(foo() != TRUE) 23:43 <@ikke> does it return if foo() is TRUE, or FALSE? 23:43 <@ikke> I'm going nuts :s 23:43 <@kris> hit fails when foo() != TRUE isn't true 23:43 <@kris> so, when foo() returns true 23:43 <@ikke> so it returns when foo is true 23:43 <@kris> oh no 23:43 <@kris> wait a moment 23:43 <@ikke> look, you got the same issue :P 23:44 <@kris> when foo() returns false, foo() != TRUE is true 23:44 <@kris> yes 23:44 <@kris> so it fails when foo() returns true 23:44 <@ikke> it returns when foo is true 23:44 <@kris> caus then foo() != TRUE is false 23:44 <+qball> fun heh :D
Oh well, it's fixed :-)
I got Gentopia SVN commit access now. Gentopia is a project set up by some Gentoo devs aiming to get the Project Utopia stack properly integrated in the distribution. I committed an updated networkmanager-vpnc version, enjoy ;-)
Cleaned up the NetworkManager Gentoo backend a little too.
Could someone tell me how to mark a bug as a dupe in Bugzilla?
Next to that: jay for new fglrx drivers! Now I *will* be able to run Linux on my laptop when I get it (will not be within next 2 months though I'm afraid :-(), which is some *great* news.
Well, proof of concept, it's not that much actually :-)
Been fighting with DBus today to get something as I described yesterday working. Thanks to the people on the mailing list and IRC (#dbus@freenode) for all help, hints and pointers!
I hacked together a very small sample in Python (yes, I hardly know Python, so the code might be very very bad, I just wanted to test whether what I want to do is possible using DBus).
The setup uses a central daemon (don't shoot! It looks like it's the only usable way to cut the job) which keeps track of all objects that want to implement some CDIS interface. Objects subscribe to the concentrator (thats how I called it anyway), and clients talk to it too.
See this screenshot to get an overview how it works. First the concentrator is started. Then the user starts Gaim and Kopete (this is just a sample, obviously). They both register to the concentrator, which keeps track of them. Now some user app (think "a screensaver") connects to the concentrator, and asks it to set the status of all IM clients to "idle".
The concentrator receives this request, checks his list of connected objects, and runs the "SetState(s)" method on all objects implementing org.freedesktop.CDIS.InstantMessenger.
All of this is completely transparant to the actual application: it doesn't know about DBus, it shouldn't care about subscribing to the concentrator (unsubscribing can be done using NameOwnerChanged etc, not implemented yet) etc. Just provide all functions to implement the inteface.
The best way to tackle this, I think, is to write the specs using some XML format (we might want to look at the dbus-glib-bindings format), then generating code using that (plain C using function pointers, GObjects and their signals, QObjects and their in-process signal mechanism, dunno about the best way to do this in Python and others). It should be fairly painless to get this working.
- Write a *decent* concentrator (this one can be started using DBus activation on the first subscription call, jay!) that's error-savvy, handles killed applications, can scan the bus on startup for existing objects it should handle,...
- Write a spec XML format
- Write specs (this one will be the hardest part I guess)
- Get desktop apps to use this beast!
- Tons of other things
 Per RealNitro's request, code is online. Beware, it's ugly.
I've been thinking: for the Python "bindings", function decorators could be very well suited...
Tomorrow I'll send something about this to XDG, I hope something useful can come out of this.
The recent discussion on desktop-devel on the inclusion of GNOME Power Manager into the 2.16 desktop release (big thanks to the developers for this software, it took a while to get suspension working on my desktop but now it does, I really like GPM even if it's no laptop) ended up in two completely different discussions: the usage of notifications (libnotify) and the notification area versus normal applets, and sharing a base daemon with eg the KDE power manager (somewhat related to what NetworkManager does: a central daemon running as root, and a client applet on top of that, using DBus for IPC, although the power management daemon should not run as root, as all privileged tasks are handled by hald, which runs as root).
The second issue is one which interests me a lot, as more than a year ago (IIRC I was still using Windows as main desktop at that time :oops: as my Linux machine was too slow to run any desktop app) I sent an email to the XDG list about what was to become CDIS, the Common Desktop Interface Specification (the email I link to is just the first of bunch of long threads, from the initial idea almost nothing was kept). Lots of email on the list later, no actual result came out of it (which is mainly due to me).
Shared interfaces are, just like open file formats etc, very important. We got some great desktop specifications that ensure a developer his/her code and application will work on all platforms supporting the specification. Think of the notification area spec, autostart spec, .desktop files,...
Shared IPC interfaces (think DBus) are very important too. In the case of a power management app like GPM or it's K* equivalent, they should both use the same interface for several functions, eg "DontHibernateNext5Minutes" (dumb and useless example, but hey). If I write an application that doesn't need user input, but does a lot of work (think of a CD burning app), I don't want the machine my software runs on hibernates during the burning process, whilst it's perfectly possible the user leaves the machine and his sessions idles out. But I don't want some construct like
if(user_runs_gnome) do_gpm_dont_suspend_call(); if(user_runs_kde) do_kde_power_manager_dont_suspend_call();
or something alike. Maybe this isn't a big issue for some simple program, but think of a large app that should be cross-desktop made by some ISV...
Same thing for a DVD player: I don't want to notify both gnome-screensaver, kde-screensaver and whatever they shouldn't pop up next minute, I just want to notify the org.freedesktop.ScreenSaver service it shouldn't take control of the desktop.
Another sample: I'm a VoIP softphone (think Ekiga), and I get an incoming call. Obviously, I'd like all media players that might run on the current console/desktop to pause. I don't want to send one signal to PlayerA using some custom socket, one to PlayerB using his own DBus interface! I just want to notify all media players they should pause, and send a "Pause" signal to (eg) org.freedesktop.CDIS.MediaPlayer. When the call is ended, I could send a "Resume" signal to the same object path.
I don't know whether all this is possible using DBus, still need to read the docs once again (there's some black magic in there, really!), but I guess you get the idea.
Obviously, an application implementing a CDIS interface can also implement extra functionality, and if multiple applications start implementing the same extra functions, this functionality might be added to the a new version of that interface spec. Like this, we never limit the service developers. There can even be "NotImplemented" errors etc.
The only thing we need is getting some developers together in all fields to write down such a spec in some standard format. Not too many people though, so there's less chance of huge flamewars and more results.
Some application types I think of now that can use a shared interface:
- Power management
- Media players
- Instant Messaging apps ("SetStatus(STATUS_AWAY)",...)
- Email clients ("NewMailArrived")
Maybe it's time to get this on XDG again...
Completely unrelated: dear lazyweb, within a month or so (at least, I hope) I should get a laptop computer (Asus W3J, dualcore 2*1.83Ghz, 1GB, 80GB, pretty cool stuff). Obviously I'd like to run Linux on the machine (oops, GNU/Linux, sorry!) once I can, as it got an ATI X1600 GPU which is completely unsupported today.
I was thinking to run both Gentoo Linux (like I do now on my dekstop) and Ubuntu on it: Gentoo for development things and just playing around, Ubuntu as "serious" desktop and university stuff. Next to that I also need Windows on it (some university soft is Windows-only).
I wrote down a possible partition layout for this setup today, and got some questions about it:
- Will this work? The Gentoo part will, as that's +- what I run now, but will Ubuntu be able to handle a foreign bootloader, and the LVM stuff?
- Won't I get in trouble by sharing my homedir between both distributions? I shouldn't, but there are no more certainties in life these days
During your talk at FOSDEM you showed some of the Tinymail code, eg the Account Store implementation on top of GConf.
Something in there took my attention: in per_account_forget_pass_func you memset the password to 0's, and free it. The day before I was working on a new IMAP server installation based on Dovecot, and while browsing the website I came across the Secure Coding techniques used by the author.
One of the parts I remembered:
When dealing with passwords and such, erase them from memory after you
don't need it anymore. Note that such memset() may be optimized away by
compiler, use safe_memset().
Where safe_memset is basicly a braindead simple re-implementation of memset. Might be interesting ;-)
It's useful to read the whole text anyway for everyone dealing with C code that needs a certain level of secure string handling.
Oh well, back to Dia.
So, last weekend (25-26/02/06) FOSDEM, the Free and OpenSource Developer European Meeting (right?) took place at the ULB campus in Brussels, Belgium (Europe). Just like last edition (I wasn't "into" FOSS before last year, flame me) it was great to be there. Interesting talks and demo's, some great people, productive discussions,... No Social Event with unlimited drinks like at LinuxTag but hey, at least there was no MS booth.
After only 2 hours of sleep (yawn) I took off to Brussels by train with some of the Zeus people. Public transports (bus) in Brussels are expensive!
Once arrived at the campus we headed to the Janson room for RMS' keynote. Once you know RMS'll do a talk, you can be fairly sure about what you'll hear. This year he talked about why software patents are evil (and I won't disagree on most of his ideas there), there was the always-returning GNU/Linux frustration (hey, where's HURD at?), some jokes (if they were intended like that?) on GIF/PNG,...
Anyway, one major comment on the keynote: I hope his "Thank you for removing that source of noise" quote won't be published too much. Not all hackers only love their computer, some of them do like little kids or human beings in general. Of course crying babies can be irritating sometimes, but there are limits. Maybe I'm just old-fashioned though.
After the keynote there was some little talk about how to fight software patents, and GPL3, which me and Ward skipped as we were fairly hungry. After a while we found some little restaurant (with some other visitors in there, with and without laptop) where we had a good meal (spghetti carbonara, yum).
In the afternoon we went to the GNOME devroom for the introduction (oh my, the room was crowded!). Everyone was invited to introduce himself and say what he/she(?) was working on, after which Damien Sandras started his talk on Ekiga (former GnomeMeeting). In fact I didn't intend to go to that talk (sorry!) but to the XDevConf overview in the X devroom, but as the GNOME room was so crowded I couldn't get out of there :-S
Anyway, Damien's overview was pretty interesting. I installed Ekiga on my system this afternoon, but didn't manage to get it working though yet, STUN problems I think. Bloody router. Ekiga (relase date 16/03 IIRC?) seems to be some nice software though (although I must admit I'm not really convinced by Damien's idea on Jabber integration...). Now if only I'd have a mic and/or webcam :-)
At 15:00 I wanted to attend the DTrace talk in Janson's. It was the first time I really saw what DTrace is, how it works, and some samples were showed. Hot stuff! I certainly got a reason to play around with OpenSolaris one day.
I intended to go to Tor's talk on "Writing Win32-friendly GNOME libs/apps" in the GNOME devroom afterwards, but didn't get in as the doors were closed (I guess the room was overcrowded again?). Too bad, as win32 could be a big market for our platform. Don't the KDE guys want to get most of KDE4 apps running on it?
Oh well, after a while there was Philip's interesting talk on Design Patterns combined when using GObjects. Some great information (although most people already know most patterns presented from things like DBUS (Proxy) and any event-driven widget toolkit like our beloved GTK+ (Observer)) and samples. Philip is right, things like this are very important to keep our lib API's both manageable, future-proof and fast.
After the talk some more discussion (with Jeff, Philip and a couple of other guys I didn't know) on several subjects. I wasn't active in it, but heard some interesting things. One of them was the fact we should be fairly proud of all the work we do. Sometimes it looks like we make no progress, or almost none, due to the 6 months release cycles. This might be somewhat true: it's not easy to make really big changes in our existing applications in "only" 6 months. The changes should be fairly obvious though if you'd run a GNOME 2.6 desktop (Sun's Java Desktop?) nowadays. That's "only" 2 years ago, and changes are, well, fairly obvious.
Some more technical discussions took place too, but I must admit I can't remember what it was all about at the moment :-S
After a while I took of with RubenV and some of his friends to Leuven (slept there). Had a meal in the city, walked around a bit, and discussed lots of things 'till 02:00 or something. Pure tech stuff (GIM!), related issues (secret ;-)), whatsoever.
On sunday we had to get up at 07:00 so we could attend the first talk in the X room (blame me!) about automatic configuration of displays. Sometimes very hard to understand what they were talking about, but it was fairly interesting (the parts I did understand). There's still a lot of work to do, most obviously.
At 10:30 we intended to attend jdub's talk on "GNOME advicacy, stuff like that" in the GNOME room again. Sadly enough he was unable to be there. Better luck next time! We just sat back and went to the X talk on "DTracing the Xorg server" as planned. More DTrace hotness, too bad real demo's were lacking a bit. As the shedule was broken a little, I wasn't able to go to the Valgrind talk as I intended to do.
After lunch the GNOME room was the place to be again as Jon talked about Beagle in there. No real talk, just some chatting about lots of things. Why we should use C# instead of C to develop our desktop applications, what he's doing at Google (well, at least what he was allowed to tell us), what Goobuntu is,...
Some great new on the Mono front. Last year in the GNOME room I had a long discussion with Alex Larsson and several others on Mono's memory performance and garbage collector, as Beagle did suffer from these issues (I tried to be a Beagle contributor in those days, but didn't dare to ask Jon a signature... I was that soylent guy, remember?). Now it looks like the Mono people are working on a less conservative garbage collector. Some great news!
After Jon had to leave for his "real" Beagle talk, I waited for Sebastien's talk on GScore and Cairo. As I'm a musician too, wanted to write a GTK+-based score editor too one day and did intend to use Cairo there (where are those "OXO" times?) it was interesting, also to get some insight in the GScore internal workings. Rock on!
Finally there was Kristian's talk on Project Ridley and GTK+2.10. If you read Planet Gnome regularly, most things said over there were "old news", but now seeing everything bundled, I guess everyone in there knows 2.10 will rock. Finally libegg can die die die.
After some more food and drinks I wanted to go to the OpenOffice.org talk in Chavanne, but doors were closed and the entrance is in front. Oh I hate those rooms.
Had a little talk with Jon and some others on Beagle/Project Soylent (RIP) etc. Great to be able to talk to some developers IRL.
After hanging around a little longer the talk on XUL started. It was aminly about XULRunner, which wasn't what I expected. Too bad we didn't see some examples on how to write XUL applications.
Finally there was Jeff's ending talk. Some great things in there. Funny winks, but also some thorough analysis of both problems the FOSS community faces, and some great things already done. Very pragmatic/liberal views too, which isn't a bad thing at all.
I can imagine some non-G* people were a little upset but hey, after all Jeff is a GNOME and Ubuntu advocate, next to FOSS in general.
Train to Ghent, luckily my bike wasn't stolen or damaged at the station. Got home, fairly tired, slept 'till 14:00 today...
Overall it was a great weekend. Superb to meet some people for the first time IRL, or meet some of them again (Hey GNOME-NL, GNOME, X.org and x-tend guys! Hi Genstef!). Sadly enough I didn't meet some of the people I intended to see (sorry [url=http://raphael.slinckx.net/]Rapha
Real Life can have great impact on man's other activities :-/ Oh well.
FOSDEM '06 this weekend. Some interesting talks in both the main track (DTrace, Valgrind, Beagle, Jeff's closing talk,...) and the devrooms (X.org, GNOME,...). And at least as important: meeting some people IRL again or finally!
See you over there?
First of all: hey Planet GNOME! It's an honour to be listed between all those hackers whose work I use every day again.
Like lots of other people (I think) I tried to get XGL + compiz working on my desktop today. XGL was a breeze (worked yesterday too), I did have some issues with compiz (mesa-issues, to be more precise). It doesn't work yet, but I hope I'll be able to sort out all remaining issues tomorrow or this week-end (although I'm no low-level X/OpenGL guru)... The whole problem could be related to some function/constant/enum renaming sutff.
The issue I got is this: I can start XGL/compiz and X apps, but the XWindows are empty black or white rectangles on the screen... The issue is (I think) related to some OpenGL extension call not working inside compiz:
Couldn't bind redirected window 0xdeadbeef to texture pixmap 0x12345 can't be bound to texture
Oh well, even with empty windows, the result is fairly amazing. I tried to make a little amateur video of what I got now ("scrot" refuses to work?). I'm sorry for the bad angle, I only got 2 hands ;) Get it here (18MB).
There's a little problem with the wobbly effect too, which leaves "traces" on the desktop (image).
Anyway, after working on Metacity's compositing some weeks ago, and now seeing this beauty, I think we should prepare for some more great progress regarding our beloved (hmm) graphics subsystems.
As some of you might have noticed, there used to be some severe problems with Blogspot feeds screwing up the layout of Planet UGent.
Some minutes ago, thanks to the great help of Jeff "jdub" Waugh, this has been fixed. All feeds work fine, no b0rked layout,...
The planet is getting more popular every day:
$ cat members.dat | grep -v -e ^# -e ^$ | wc -l
Not that bad, it's only up for a week or so :-)
I'd love to get some more gotchi's though (hint ;-))
Just installed XGL using this howto, and ran it. Doesn't work: windows are rendered well (in FluxBox, not in e17 -> artifacts), but whenever you move a window, the window content isn't updated/re-rendered, don't know how to explain better.
Needs work I guess :-)
- Got around the lack of cron on this server by using some Bash, PHP/shell_exec, wget and an external cron daemon to do the updating
- Top banner thanks to Peter. Using tables, couldn't find a decent way to display the banner
- Fixed encoding issues by moving the index page to a PHP script and use header()
- Make the sidebar fit better. Methinks it's fairly ugly now
- Maybe make the text balloons a little broader
- Add more feeds and add more gotchi's
- Guest Users: 475