Today I stum­bled again over some HeatMaps from Bren­dan Gregg (of DTrace–fame). This time it was the PDF of his pre­sen­ta­tion at the LISA 2010 con­fer­ence. It shows nicely how he plans to evolve it from a single-machine (like in Ana­lyt­ics for Ora­cle Stor­age prod­ucts) to the cloud. It is a very good overview about what kind of intu­itive per­for­mance visu­al­iza­tion you can do with this.

I would love to see some­thing for FreeBSD (or other per­for­mance data). Maybe some­one could take the DTrac­eTaz­Tool as a base or hint and write some­thing generic which works for a lot of things…

There are just too much nice and inter­est­ing things out there, and not enough time for all of them.

Bren­dan Gregg of Sun Ora­cle fame made a good expla­na­tion how to visu­al­ize latency to get a bet­ter under­stand­ing of what is going on (and as such about how to solve bot­tle­necks). I have seen all this already in var­i­ous posts in his blog and in the Ana­lyt­ics pack­age in an Open­Stor­age pre­sen­ta­tion, but the ACM arti­cle sum­ma­rizes it very good.

Unfor­tu­nately Ana­lyt­ics is AFAIK not avail­able in Open­So­laris, so we can not go out and adapt it for FreeBSD (which would prob­a­bly require to port/implement some addi­tional dtrace stuff/probes). I am sure some­thing like this would be very inter­est­ing to all those com­pa­nies which use FreeBSD in an appli­ance (regard­less if it is a stor­age appli­ance like NetApp, or a net­work appli­ance like a Cisco/Juniper router, or any­thing else which has to per­form good).

Seems that I will actively men­tor again in this Google Sum­mer of Code (as opposed to just review the sub­mis­sions from stu­dents and/or act­ing as a fall-back mentor).

The project I will men­tor is the “Make optional ker­nel sub­sys­tems reg­is­ter them­selves via sysctl”-one from the FreeBSD ideas page.

The stu­dent already got into con­tact with me and it looks like he is moti­vated (he is already sub­scribed to sev­eral FreeBSD mail­inglists, which is not a require­ment we have in our GSoC docs).

I search a way to use one-time–pass­words for jabber/XMPP (ejab­berd) on FreeBSD. I do not want to use PAM (local users on the machine). Cur­rently I use the inter­nal authen­ti­ca­tion, and I expect that not all users of the jab­ber server will use OTP if avail­able, so the prob­lem case is not that easy (migrat­ing exist­ing users to a new solu­tion can be done by chang­ing the pass­word myself and then telling them to change their pass­word, but there needs to be a way to let them change the non-OTP password).

I assume that OTP is not fore­seen in the XMPP pro­to­col, so where could I ask to have some­thing like that con­sid­ered as an exten­sion (if such a place exists at all)?

Oh, yes, send­ing the pass­words over SSL is not an option (that is already the only way to login there). The goals are to have

• an easy to remem­ber pass­word for an OTP app on the mobile to gen­er­ate the real password
• the pass­word expire fast, so that a stolen pass­word does not cause much harm
• not the same login-password for dif­fer­ent ser­vices (mail-pw != jabber-pw != user-pw)

I stum­bled over Google’s new RE engine. Unfor­tu­nately it is not han­dling back­ref­er­ences, so it is not a drop-in replace­ment for the reg­u­lar expres­sions code in FreeBSD. It has a POSIX mode, but this only seems to be enough for the egrep syn­tax. For peo­ple which need back­ref­er­ences, they refer to the Google Chrome’s RE engine irreg­exp which in turn ref­er­ences a paper from 2007 which is titled Reg­u­lar Expres­sion Match­ing Can Be Sim­ple And Fast.

The tech­niques in the paper can not be applied to the irreg­exp engine, but maybe could help to speed up awk, egrep and sim­i­lar programs.

I think it would be inter­est­ing to com­pare those recent devel­op­ments to what we have in FreeBSD, and if they are faster, to see if it is pos­si­ble to improve the FreeBSD imple­men­ta­tion based upon them (either by writ­ing new code, or by import­ing exist­ing code, depend­ing on the cor­re­spond­ing license and the lan­guage the code is writ­ten in).

Maybe a can­di­date for the GSoC?