Amending my SoC post

I’m always pleased to be proved wrong on points I thought ere going badly, so I’m happy to say I was wrong in my previous post, about Luis and BaseGUI project.

My mistake was due to not connecting BaseGUI with app-portage/himerge, which I did read quite a bit about; seems like there has been a bit of name changes around (well, you can’t blame him, it seems to happen to almost all the SoC projects). As for CIA stats, the Haskell team uses Darcs repositories, and they are not aggregated on the same username

The project, spawned by BaseGUI’s SoC project is called Gentoo GUIs and is quite active.

Once again, sorry Luis, and I’m glad you’re around to correct me!

Some tips for both students and mentors for SoC (but not limited to)

While I wrote my rant about last year’s SoC I started to think of some advises for both students and mentors of Google Summer of Code.

I have to say first off that I didn’t partecipate actively as a mentor in 2006 (I was backup), and I didn’t partecipate last year at all, so you have to take these suggestions as an outsider’s suggestion, but, I think, a quite experienced outsider, by now.

  • Work in advance. Don’t wait till your application is accepted. Plan ahead, if you intend to partecipate, start working already! Find an interesting idea, and start fleshing out details. How are you going to work on it? Can you already prepare a few use case diagrams? Can you design an interface already? This is an investment, even if you don’t get accepted, the goal of SoC is to put you into a real-world environment, and doing this work is the first step. Think of it like trying to sell an idea to your superior, or a new company you want to work for. Also, it should give you quite an edge, showing you care about the experience more than the money (which in turn should mean you might actually continue working on the thing afterward).
  • Ask around! An important task for any developer, not limited to Free Software developers, is to be able to ask the right questions. If you’re a free software developer, you most likely have to ask one day to people who worked on similar issues than your own, colleagues and similar, so that you don’t have to re-implement the wheel every time. Searching documentation is cool, but it’s not always going to cut it as you might not find any reference to what you want to know. If you need information, you have to ask not only your mentor, but whoever has the information you need. Your mentor is supposed to know more about the project which you’re working on than you, but if that is not the case you has to find someone to give you the information. Trying to work without knowing the conventions and similar is not going to produce good results.
  • If you’re working on a testable project (a library, or a non-interactive tool), write testcases: doing so will make sure that your mentor can tell your work is proceeding correctly. And will give you a way to make sure you don’t end up breaking what you wrote a week before. In addition, I’d suggest you to write one test each time you do find an error in the behaviour, even if that means you end up with hundreds of tests!
  • Profile your code. Profiling is an important task for making sure of the quality of the code; while in most universities you’re done with writing a working solution, or a working not over-complex solutions, in real world you have to write code that doesn’t suck. And that means it has to run in a timely fashion and not abusing memory. Try looking around in my blog about memory usage and cowstats for instance. You need to learn how to use tools like that, smem, valgrind, and so on. This is the best time!

Mentors should look at these points above, and see what they can do to facilitate their students. Be around to answer their questions, point them to the right person to ask if you can’t answer them. Make sure you know how the testsuites work in the language of choice of your student, this way you can judge if he’s doing them right or if he’s just testing the behaviour that is known to work; also, try to figure out patterns that are not yet tested for, and ask the student to test those.

Up to now the suggestions refer to any organisation and project involved in Summer of Code, not just Gentoo. So feel free to link this post (or quote it, please still reference my blog though) to your students.

As it might be that not all the developers writing up as mentors will have time to do all of the above, I’m at least going to help by trying to stay around for the students. This means that if you have any question, especially related to C or Linux programming (ELF files, memory usage, compiled code analysis – both static and dynamic), feel free to contact me. In the worst case I’ll have to answer you “ask me again tomorrow, I’m busy” or “sorry this I don’t know, it’s not my area of expertise”. It’s worth a try :)

(Joshua, Alec, whoever, feel free to link this blog in the SoC page).

Some more about Summer of Code, on the Gentoo side.

First a service information, I’ve taken a day off because yesterday I ended up in the ER after three days of headaches; don’t worry, the (urgent) CAT scan shown everything is okay, and all the blood tests are fine too. I just have to consider this a signal telling me not to stress too much out of me.

Following yesterday’s request about SoC, I started wondering about writing something out of last year’s handling of SoC in Gentoo. The part of me that tries to not be too critic of others told me not to write, but I feel compelled to. I already can tell this is not going to be good PR for Gentoo, but as for once we deserve it, and with “we” I mean myself too, as I didn’t want to mess with Google SoC last year (well, maybe it was better this way as I would have disappeared as a mentor without notice, with what happened).

Up to yesterday, the Gentoo SoC page still shown the information about last year’s SoC. Thanks to Joshua the page is now updated to show the 2008 proposed projects for the students to try applying for, please all the interested parties to look into it. More proposals and more mentors are most likely welcome, and if you’re interested in one of these projects, it might be a good idea to start fleshing out some of the details already, so that when you submit the application you have a valid proposal already.

The old page can be accessed still, even if it’s not linked in the archives (even if the URL is not explicitly referenced, it’s not a secret, anybody can find it in the viewcvs). By the time you read this entry, if you’re not doing so right after I write it, it might be possible that the page was changed, if you can’t understand what I am referring to, check 2007.xml revision 1.1 .

Take a look at the page now. Yes it is correct, there is no information about which students took part in the SoC. There is no list of accepted projects, there is no result information. The page was not updated to reflect the outcomes of the SoC, and not even to reflect the actual projects that formed SoC last year.

I’m sorry, but this has a huge FAIL stamp all over it, in bold red characters. I don’t want this to happen again. The first problem one can see easily is the very limited number of people that the team consisted of last year. The page only refers to Christel and Alec. Luckily this year we have quite more people involved in this task and that hopefully will avoid repeating that huge failure.

But what about the projects themselves? Luckily for us, Google archives the data, so you can find last year’s projects on Gentoo’s SoC 2007 page at Google . Unfortunately, when the time came to review the results of these projects, I was unavailable (remember, I didn’t really come back as a developer till mid to end October 2007, while it wasn’t my fault I still feel sorry for having been unable to help the process). I suppose I would be able to judge whether a project brought good results by having know about its completion after the fact. If I didn’t even heard of it anymore, I would suppose the results were pretty shaky…

  • the Collective Maintenance project, I really don’t see any trace of around; failed I’d say;
  • BaseGUI I also didn’t find any trace about; failed too; sorry Luis, not wanting to pick on you, but you’re the first one in the order of the list to be also a Gentoo Developer, this detracts point to the idea that Gentoo Developers have more chances to complete something for SoC;
  • GNAP cross compile support (and same applies to the other GNAP project, as well as SCIRE); I can’t tell about this, I admit GNAP is way out of my usual league of competence, so I’d like to ask for a status about these three projects to the developers involved; a post on Gentoo Planet would be appreciated;
  • archfs: heard nothing about this either;
  • equizApp, I’m not sure about this either, I haven’t heard it named in quite a while, but as I remember Betelgeuse discussing again of changes in the recruitment process, I don’t suppose this was successful either.
  • Python bindings for Paludis this is probably the only project which I heard of when I came back; the interesting notes are that this is a project that is not, strictly speaking, related to Gentoo (or at least to Gentoo Foundation that is the mentoring organisation) – Paludis is explicitly an external project – and the developer was already a Gentoo developer.

What does this say? Well at a first glance one might actually argue that this plays against my request. The only project that completed successfully was one handled by a Gentoo Developer. But I don’t think the main point to judge by the rate of completed project. As I said, my opinion in SoC is that it is helpful to find new good developers.

I think this was a total failure in that regard. The year before we had even two more applications accepted, and quite a few of those had results that actually can be looked at. In that edition, though, we had a lot more students being developers already (and not even all of them succeeded, anyway). I don’t think the better results are to be referred to the higher dev to newbie ratio, but rather to the higher feasibility of the accepted proposals.

SoC is great, it gives three paid months to a student to work on something they wouldn’t have worked on otherwise. But they are three months. The people has to understand that there will be no more checks after those months, and it comes down to either implement something that can be done and completed, or they have to show intent to continue after those months. That is also an important lesson to learn.

In 2006’s edition, the two Gentoo/FreeBSD-related projects were slightly active, and the students seemed to stay around after a while even if the SoC finished. They didn’t make devs, but I impute that also to the not-much-inspiring environment that the Gentoo/BSD project has become again (and that is also my fault, I want to take back the project as soon as I’m a bit more free than I am now).

As for people from 2007 edition, I don’t remember the name of either of the students (with peper’s and araujo’s exception of course).

The projects, judging by the applications, were quite high-shooting. Proposing to reinvent entirely the maintenance process of Gentoo seems like proposing to fix Italian Parliament in a week (people knowing Italian politics, this is your cue to laugh out loud). One slot was allocated to something that I can’t see interesting Gentoo directly (archfs) and one for an external project (Peper’s python bindings for Paludis).

But how should one judge the intent of the students to stay around after SoC ended? Well I admit that is the tricky part. While I referred to “new blood” I didn’t specifically mean “somebody that has never seen, touched or contributed to Gentoo” bur rather “somebody that hasn’t been an active Gentoo Developer”; people who have been active in the community, even by just reporting bugs, would probably stick around longer than people that never used Gentoo. FFmpeg solves the problem in a slightly different way, as you can see on their SoC Wiki page : they give some admission tasks that the student has to complete before its application is considered for acceptance; if somebody is in only for the money, and counts on disappearing, they’ll likely look for something else and abstain from wasting time and slots.

I don’t think is feasible to get the students to pass an ebuild quiz, for instance, but it might be worth to interview them, or at least to ask them “Since when do you use Gentoo?”. Not like it has to be mandatory to use Gentoo, but it certainly would allow to prioritise people who have at least a clue what they are proposing.

I’m sorry Luis for picking again on you, again, it’s just a matter of who is under hand at the moment. You’re not really an active developer; CIA stats for araujo count less than 400 commits. And they are shared with a FreeBSD developer that goes by the same username. It’s not thus a matter of being already a developer to become more active for the SoC timeframe.

I know this post is really a rant, I know it’s not much constructive, and I’m sorry I can’t be more constructive, for SoC, than volunteering to be a mentor this time and to point out the mistakes I think should be avoided. I can’t come back in time, and I couldn’t really help last year to clean up the stuff after the fact.

I do hope that this year there won’t be the same issues again. And having a stricter selection of students is IMHO a very important thing to do. That and being able to judge the feasibility of a project. So as a suggestion to anybody who wants to apply, I can tell this: work beforehand. Even before submitting the application, try to flesh out details, try to understand what is involved. Don’t be afraid to ask, especially questions about the structure of a software or the method used for maintain it.

Read the blogs, read the documentation and check the commit history of the project. Check who proposed a given project, and ask him more details, I know I will be quite happy to give them to you (and to others maybe, through a blog). [Service request for Joshua and the other people working on SoC: if you’re reading this, please add a contact entry in the table, so that possible students can contact who proposed them if there is not a proper project which they can reference to, like for sandbox).

If you start already to at least investigate what you want to do, it is more likely that we’ll see through your intentions to continue working with the project after the SoC months.

In a different tone, I wish that Jakub, some #gentoo operators and some of the forum moderators could volunteer as SoC admins. If you don’t know what an admin is, it is a person that work for the mentoring organisation that is not going to mentor a student directly, but that is involved in the process of selecting the valid applications. I ask this because you are part of the user-facing interface of Gentoo, and you tend to know who is active (in bugzilla, IRC and forums). And the previous commitment to Gentoo is another important information for choosing wisely the applications to accept.

Summer of Code: is it all about the money?

This is the text of a mail I sent earlier today to gentoo-dev mailing list:

I know this is going to stir up quite some discussion, but I do think
it’s worth trying requesting it at least.

In the past two years we had quite a few applications from students that
were already full-fledged Gentoo developers. I sincerely would like that
this year we put as a rule that Gentoo developers cannot partecipate in
Summer of Code as students for Gentoo.

I’m not asking to penalise Gentoo developers are students. But I
sincerely think the main goal of Summer of Code is to allow new people
to enter the scene of Free Software, to understand how Free Software
projects work and so on. Gentoo Developers are already pretty well
“inside” this world.

I think it should be a self-made decision to abstain from applying as a
student for what you already partecipate in, but as such concerns don’t
seem to be widespread (at least as the last two years shown), I’m asking
for a formal decision to all the developers. If that is requested, I’m
even willing to bring this in front of the council.

Gentoo’s ranks are quite reduced nowadays, and a few persons have shown
conerns about our current recruiting methods being able to judge clearly
technical and social skills, as well as the time one is ready to pour
into the project. I think SoC could be used as a pretty good recruiting
method: as you are going to work quite a bit with the student, you can
easily judge availability and technical and social skills. Leaving SoC
applications open to developers means wasting this opportunity.

There are many other organisations partecipating, I think it would be
quite feasible for Gentoo developers wanting to be a student SoC to
choose another one, in which they are not involved already. Yes it’s
easier for them to do something for Gentoo as they are already
contributing, but that is not the point of Summer of Code, the point is
to introduce new people into projects, not giving money to people to do
what they already do.

And just to take a stance, even if this request is to be rejected, I’m
not going to mentor a student that is already a Gentoo developer, for
sure.

So to be clear, I’m not trying to look down to anybody, I don’t even
want to stop people from being paid for their work. I just wish that we
can focus this opportunity to improve the Gentoo project as a whole.

I knew it wasn’t going to be accepted unanimously, but I sincerely thought it was more based on personal views rather than focusing on the “who get the money” idea.

And this makes me wonder, is it all about the money?

When I heard about Summer of Code the first time, I was still a student myself, but I didn’t even consider it, because I was already a free software developer. Not successful (I don’t consider myself successful even now), but a free software developer nonetheless.

I think Summer of Code is of great value for students with no real-world development experience. During the summer, when they have no classes to study for, they can find a job, not much for the money, but more to get some real world experience. Rather than going in a software company that is half empty because of summer, needing someone to keep track of the simple bugs that come during the time, they can enter the Free Software scene, mentored by already active Free Software developers.

I think the choice should be already appealing on its own, the money would just be an extra incentive so that, for instance, the parents can’t say they are not doing anything to bring back at least some money.

I sincerely can’t see how does it make any sense to rely on this money for who needs it, and would otherwise need to move some time from Gentoo to a day job. Don’t get me wrong, I do feel very much empathy for those who has to use spend more time on the day job rather than Gentoo, I am one of them, but we’re talking about students here.

If one can afford to be a student nine months an year without having a job, it’s not for the three months during the summer that he has to focus more on the day job than on Gentoo. Either one can afford to study and work (not paid) on Gentoo all year long, or has to be doing a dayjob the rest of the year too, thus is more free during summer. I can’t understand how it can be possible that “magically” by giving someone €3000 (which is not much a big sum for most people, I’d say), they can stop needing a dayjob for three months, focus more on Gentoo, and then resume the school.

It might work as “extra” money, and it might be quite appealing. But then, can one just make a little more effort, take a pause from Gentoo if he needs to, and choose a different project to be a student of during Summer of Code? Learning to work in a different environment, which is one of the goals of SoC after all.

Or is it just a matter of getting money easily, doing something you would have done already?

Ideas for Google Summer of Code

I know it’s not even spring yet, and we can’t even be sure if Gentoo is gonna be on Google Summer of Code this year, but maybe if we start early, if/when Gentoo is accepted into Summer of Code we’ll have already some ideas to throw to our users.

To begin with, I think we should decide, this year, to limit ourselves to projects that affect Gentoo as a whole project, and avoid using up slots for external projects. Although as Grant said we have external projects affecting the core of Gentoo, I think they should be left independent as they are, and we should focus on stuff that is still done in-house, and need to be improved. It doesn’t matter if the project is pkgcore, paludis or even OpenRC: if they are external, they remain external, Gentoo has enough internal projects to complete.

So here are a few suggestions that might be worth discussing:

  • sandbox: since Martin (azarah) has been busy and then was retired, there was nobody working full-time on sandbox, yet it’s one of the core utilities that Gentoo uses; Martin left an experimental branch of sandbox, with the code used for Gentoo/FreeBSD support in it, stale there, at the moment that sandbox fails badly with Linux modules, as the forward port of the fix for the issue with recent kernels from the old version is non-trivial; having someone to cleanup sandbox code and finish the 1.2.20 release would be quite good;

  • autoepatch: this is something I left dangling myself; autoepatch was supposed to be a way to replace gnuconfig.eclass and elibtoolize, by being able to apply common patches and fixes to source code after unpack and before compile phase; this way it would be possible to fix common mistakes in source code, like broken autotools and similar, without having to handle everything ebuild-per-ebuild; a few posts about autoepatch are available here ;

  • eselect gcc: we all shudder to think about the brokenness caused by eselect compiler; it was certainly not the way to go; but eselect is being used more and more in Gentoo lately, so it would make sense to reimplement gcc-config and binutils-config as eselect modules in a 100% compatible way, not like eselect compiler (whih changed the format of the data files and so on).

  • more eselect modules: whois, tar, cpio, sendmail, there are many packages that have implementations compatible enough to be runtime-swappable; it would be nice to have an easy way of selecting between them, without having to write one extra module for everyone of them; something like Debian’s alternatives would be nice, I think; yes I do know that for sendmail there should be mailwrapper, but it’s at least two years it’s in package.mask if I recall correctly; it’s either time to unleash it or to reimplement it;

  • multilib implementation okay this is asking too much, but it would be nice to see someone starting to work on that, in my opinion;

  • support for user-defined extraction tools this way the user might just decide to use libarchive’s bsdtar command for extracting zip files, and the get rid of unzip; I doubt it’s an easy thing to do, but, well, it might be doable.

These are just a few ideas I gathered thinking about the next Summer of Code. Probably other developers working in other areas might find more of these, which don’t relate to external projects, and are just Gentoo’s.

At any rate, people, if you have proposals for SoC, start talking already, it’s better to start too soon rather than too late!

A little Summer of Code analysis

So today the allocated projects for the various organisations accepted in Google Summer of Code were released, and I decided to skim through them to see if there was something interesting; especially with xine-lib in mind.

First, FFmpeg projects, as FFmpeg is for good or bad xine’s heart, and improvement in it is certainly going to do good to xine project too. There are four decoders proposed and accepted: RV40 (Real Video), E-AC3 (used in some kind of HD media if I remember correctly), Dirac and QCELP. I sincerely never heard of the last one, and of Dirac I heard only as an experiment from BBC; I prepared the ebuild for the Dirac library when I was trying to support it in VLC, but as there was not a simple way to test it I left it masked in the tree for a while; the package is still there, masked, but someone else probably took it over; with further experience, I should have put it in an overlay.

While really interesting, RV40 and E-AC3 doesn’t sound that appealing for the target of xine users; first the Real demuxer needs an overdue overhaul, second E-AC3 only makes sense if we also start supporting HD media, which I don’t think we’d be doing soon enough. I was hoping for a Monkey’s Audio decoder, but that was not the case neither this year.

Users interested in having Monkey’s audio support in Amarok and other xine-based players might consider the idea to start a Chinese wall reverse engineering for it from the macport library, also if some description is present already, and might be enough to start working on it; I’m not keen on going to do it myself though; beside having other things to do, I don’t really know where to start at the moment.. bribes might make me reconsider but remember that almost anything I do goes to help in some way…

Now instead FreeBSD has interesting ideas, I’m quite interested in support for the Apple’s MacBooks (hoping that they will also consider MacBookPro), as I’m an user for it; the TCP/IP regressions testing might also help, as there has been a few TCP/IP problems in the past that might get solved once and forever with this, but what is really interesting is the bintools project to replace parts of binutils with BSD-licensed variants.. interesting not much for its usefulness, but just to see the mess when you add bintools’s commands to binutils’s and elfutils’s … reinventing the wheel, year after year.

For what concerns KDE I think we’ll see the results only in a few months, but I’m happy to see that there are projects to improve Kopete’s MSN and Jabber protocols. I just hope that in KDE4 Kopete is going to get more maintenance and won’t be allowed to fall behind every year to an obsolete state (Jingle support was nice… but it was left incomplete and never update up to now!. And I don’t intend to forget Mike’s project on Kontact’s blogging support.. that will be neat for a blog-addicted like me.

For X.org, the server-side XCB support is something that I’ve read about for a few months now in the xcb mailing list and seems like it’s going to be quite useful to reduce the possibility of a mistake in the X server code, which is something we all rely upon nowadays (by the way, since X.Org was founded, using X started to be less a pain that it was before, the no-configuration startup is nice, too bad xorg.conf still uses that obscure format :( ).

When it comes to GCC instead, the projects are more technicalities, but there is at least a speedup project that all Gentoo users should welcome easily, and the SEH support (that by the way comes from a friend of mine, hey Hyp if you’re reading! :) ), that will be one less reason not to use MinGW32 rather than VC++.

And not directly related to xine, but coming from one of xine’s contributors in the last months, there’s a project for Wine to support Solaris.. I wish him good luck, as that might make wine’s code even better, as usually portability helps cleaning up after yourself.

Okay now let’s hope these projects will all be completed during Summer of Code and maintained for a long time afterward! :)

Internationalisation is important

I wrote before about internationalisation. Albeit I’m a good English reader (I don’t speak or write it too well, but I can read it pretty well), I do think about the people who are not this lucky, and I can ensure you, I know a lot of those people, because in Italy it’s not as in a lot of other countries where knowing English is a common thing.

One of the nice things I can tell about Fedora is that they are quite concerned with this kind of problems, and they deprecated GTK+ 1.2 because its Unicode/UTF-8 and i18n supports are pretty much missing, while GTK+ 2 has a very good support for both. This was quite a good thing to do, in my opinion, because it focuses the attention of people to the need for modern toolkits and reasonable translation support.

Ubuntu also is concerned with the availability of free software for people who don’t speak English, and this is shown by their tries to improve the availability of translated software through the Rosetta application in Canonical’s Launchpad framework — that if I have to be honest I don’t trust, as I don’t understand the reason why they don’t try to free Launchpad, if they have the success of Free Software at heart, but that’s another story entirely.

I also read quite a bit of entries in Planet Debian about their efforts to improve localisation support in their packages, and that is quite good.

Something I instead never seen in Gentoo are people concerned with improving the internationalisation support in Gentoo, either packages, tools or ebuilds themselves. I used to fix some ebuilds so that they answered correctly to LINGUAS instead of abusing the cjk flag, I used to work on CJK packages to improve them, so that they actually worked, and I started adding proper support for the LINGUAS variable to a few KDE packages, but these are really little things, they don’t really change the user experience so much, as the bases still require you to know English to an higher degree than is required for other distributions.

Maybe asking for every bit and string of Gentoo being translated is too much of an overkill, but it would be nice to see at least some tests on getting Portage, baselayout, or whatever else to actually be translated.

Why am I writing all of this? Well if there is one thing that I suppose everybody would agree on about last year’s Summer of Code, most of the ideas proposed weren’t thought about for too long, and the results were badly affected by this. So as now we start talking about Summer of Code 2007, I want to write my proposal here.

It would be nice to have a project for Google Summer of Code 2007 that actually has an impact on users. Someone could try to add good i18n support for Gentoolkit, or for Portage-Utils, maybe even for Portage itself. Although these seems to be easy tasks, there is at least one that is non trivial and might be worth pointing for: finding a good way to allow internationalised messages in init.d files and ebuilds. For init.d files it might be easier than you think: gettext can be used to translate strings directly, you just need to have a tarball with the init.d file, the .po files, compile the .mo files, and get baselayout to have a “echonls” function so that the strings you echo there are passed through gettext (if you installed baselayout with nls useflag of course). Ebuilds can be harder, but I have a couple of ideas myself, the problem is to find a way that is good enough not to hinder the general ebuild maintenance, and not to bloat the tree too much.

I know most likely my suggestions won’t be considered at all, or might just be considered ramblings of a fool former dev, but, well, I have still hope that someone will work on that sooner or later.

FedEx had a package for me

So it arrived after all, even if my task on SoC was just to be a backup mentor :) Unfortunately it’s not the weather to wear this right now…

Oh the triangle you see on the wall behind me is a Blind Guardian banner ;)

And yes, I didn’t shave today.

Profiling ruby?

Today on #amarok, dangle suggested me to find something I enjoy to do, so that I can cool off a bit after the waste of time with FFmpeg and the quantity of bugs to fix and correct.

But I admit I lately stopped enjoying most of the stuff I do. For sure FFmpeg was a harsh hit to my morale, but it wasn’t alone, as in xine every time I tried to implement something I ended up with regressions or something that is not even near to the attribute ‘usable’.

Ruby, that is something I still somehow enjoy, maybe because it’s a language I don’t know enough yet, and I like learning new languages, and such an OOP language is something that entice me easily :)

So, I’m starting to think about something I might implement in Ruby that might come helpful to someone; an easy thought I have is to write a replacement for app-portage/herdstat (that currently doesn’t work on stable systems, at least on amd64, because it does not build with GCC4.1.1), splitting it out in a ruby extension and an user script (so that I can hook it up on ServoFlame without requiring an actual popen, as I used to do in the previous incarnation of it.

But after writing the tool to parse LD_DEBUG=bindings output, I’m starting to think I actually need to have a way to check if the code performs decently, to avoid obvious errors or performance wastes. Lately I’ve been hooked up with valgrind, and in particular with massif and callgrind; while the first is unlikely to be workable with Ruby itself, the latter could be somehow managed, as PHP, Perl and Python profilers have their converters to callgrind format.

Unfortunately Ruby’s internal profiler outputs an already parsed output, that is okay to read but impossible to use for KCacheGrind for instance.

I looked around a bit, and ruby-prof seems promising, as it does actually write a call tree out.

I haven’t played with it yet, but I might in the next days, at least to relax a bit.

The interesting thing about writing a replacement for herdstat in Ruby is that I remember Aaron spending a lot of time fighting with a decent XML parser, with UTF-8 conversions and with URL fetching.. all things I don’t really have to care in Ruby, as there are almost all embedded in the standard library :)

On a totally unrelated note, I wonder when the irony will become reality (because there is almost always a moment when that happens) and Debian users will really have to pay if they want anything done… This is probably why I’d rather not see Gentoo going commercial again, at least officially or semi-officially, as that will likely bring similar, but most likely increased, problems to us.

For who will say that Google’s Summer of Code is something similar to that, I’d just like to say that, for what I’ve read in the admins mailing list, the idea is to use SoC to find new developers, rather than pay people that develops already… and on this, it is indeed useful, as Alex and Victor for instance are going to be very important additions to our Gentoo/*BSD team :)

Planning the FreeBSD 6.2 update strategy

I’m currently thinking about the strategy to update Gentoo/FreeBSD to FreeBSD 6.2, that will be out soon.

The first important change that will have to happen is the new baselayout, 1.13_alpha, that Roy is working on, the first unified version of baselayout between Linux and FreeBSD (yai!) with parallel startup and all the cool features but the PAM support in start-stop-daemon (for FreeBSD, that is). Thank you Roy for all the work :)

Also, GNOME will probably be part of the keyworded packages, thanks to steev:

GNOME on Gentoo/FreeBSD screenshot

Other important change will likely be the merge of the work done by Victor during Summer of Code for Gentoo/FreeBSD on AMD64 (which will mean ~amd64-fbsd keyword in tree soon).

I also read that Matteo Riondato is working on the new FreeSBIE that will probably make our work simpler till I can force Timothy to create a proper Gentoo/FreeBSD LiveCD (based on FreeSBIE of course) ;)

I think I can be pretty satisfied of how Gentoo/FreeBSD is evolving lately, and I wish to thank all the people who allowed this dream come true: Daniel Robbins and Seemant, Otavio R. Piske, Aaron Walker, Stephen Bennet, Javier, Victor and Alex (my personal Spanish conspiracy ;)), Martin Schlemmer, Benigno B. Junior, Roy Marples, Timothy Redaelli, Steev Klimaszewski, and for Gentoo/*BSD project Andrea Barisani, Karol Pasternak, Damian Florczyk and Robert Sebastian Gerus (the BSD-Polish conspiracy), and all the contributors in Bugzilla that I forgot to mention, but I’m still grateful to :)

I hope nobody will misunderstand me now, I’m not going away from Gentoo anytime soon :) I wished to thank all the above because we’re approaching a new release and it’s promising many improvements thanks to the contribution of all the people. This is not a goodbye, but a “stay tuned” message :)