Back from Bordeaux where I was attending and talking at XDC 2014, the Xorg developpers conference.
First of all, it was a nice conference, foreign people seemed to have appreciated the French mood.
As a tourist, Bordeaux by night is really a nice town. Really weird to speak english
for 3 days while being in France !
That's a long time I haven't post something here. Summer was quiet with content that
would have their place here.
This year I will attend to XDC 2014, the X Developper Conference. It will take place in Bordeaux this year, that's not so far !
These days, I have been working on having writes being non-blocking in FreeRdp. That makes me walk through most of the low level component of FreeRdp, so let me share things I have collected during this code walk.
The actual code is non-blocking for read: it handles a EAGAIN or EWOULDBLOCK for a read() call. But for write calls, it will actively wait until all data have been sent. For the FreeRDP client you almost never hit the case where write calls gets blocked, because most of the traffic is from the server to the client (sending screen updates). You can hit it anyway when using the channels: Disk Redirection (pushing a file to the server) or audio in (microphone exported to the server).
But when you're in FreeRDS acting as a RDP server, blocking writes is very common. Just try to see a fullscreen video through a slow WIFI connection.
OpenSSL has the "good" idea to use the stack as a source of entropy. This is the cause of the 2008 debian bug: the debian maintainer for OpenSSL was annoyed by valgrind warnings. So he did a fix that removed the error but introduced a main security issue: after the fix, the number of possible keys was so weak that it was possible to list them. The consequence is that all the cryptographic materials generated by this version had to be regenerated, and it probably remains plenty of servers running with vulnerable keys.
So ok, the maintainer has been blamed, he did his mea culpa. But what can you do when you're annoyed by all these warnings ?
I have been told that the RDP compositor have been proposed for integration in Tizen
by default.
It's quite a long time that wordpress is annoying me: all the daily updates (as soon as
you're using plugins). There's even one of these update that was supposed to be painless
that have corrupted all my posts. I had to set back the language informations on all my posts. That's really my
favorite activity to fix wordpress plugins bugs (I love so much PHP).
I have recently worked on the remoteFx encoder of FreeRdp. So here's a post to discover remoteFX.
RemoteFx is a codec for bitmap in RDP. At the beginning of the RDP protocol, many vector operations have been added: draw a rectangle with a solid color, move a region from one place to another, do some complicated bitmap operations... It looks like Microsoft was trying to put in the protocol the operation that were supported by the GDI. That gives very complicated operations, for example I imagine very few people understand the ninegrid operations.
At the end the result was not that good:
So some researches have been done to optimize the required bandwidth for transmitting bitmaps. Doing so:
I won't cover the details of the remoteFX compression, as I'm far from being an expert on this subject. A very high level overview
The year has just began, but there have been linux.conf.au, a conference with interesting talks. I like that one because a talk gave there make me have some interest for wayland a year ago.
I have found that nice article about activating stack canaries with
GCC to help debugging.
This option is obviously here to enhance security.