apt-get install debian-wizard

Results of the election

April 8, 2007 by Raphaël Hertzog

Sam is our new DPL. The margin with the second (Steve McIntyre again!) is very slim, 8 votes. And Steve only has 25 votes more than me. That’s not much either.

What we can learn from this election:

the principle of a DPL board makes its way, I have been ranked well above NOTA and I have been mainly advocating this proposal (and this despite some votes anti-dunc-tank that I probably suffered from)
my selection of board members was pretty good, the 4 candidates that I selected for the board are the top-4 of the election
Debian developers are fed up by the various problems in some core teams (overwhelmed, not recruiting new members, not communicating enough, etc.). I’ll try to help Sam fix those issues, but it’s going to be a big challenge for us.

In the end, I really hope that sam is going to find a way to cooperate closely with the various candidates that are still highly motivated to work on improving Debian. I doubt that he will choose a board structure (although I would be glad to be proven wrong!), but I really hope that he will expand the 2IC principle (or something similar).

I once told sam that he would have my full support if he got elected, and I intend to stand up to this promise. I said that because I share many of his ideas. The few fears that I have are mainly on how he is going to try to address these issues. But I have no reason to believe that he’s not going to listen to what we (and I) have to say. That’s why he got ranked just after me on my ballot.

Good luck Sam, do not disappoint us!

Alioth and OpenID

March 6, 2007 by Raphaël Hertzog

Stratus seeks for comments from Alioth admins.

Yes I’d like to see OpenID integration with Gforge. The upstream situation is a bit difficult, so I don’t think that you’ll have official opinion from them.

In my case, I want OpenID integration because it would be cool to offer a standard wiki and be able to define ACL on some pages which refer to the Alioth accounts that people are used to use. In the longer term, we have other web services which are going to need authentication (DWTT, new version of the PTS, …) in order to provide customized content and it would be great to rely on OpenID for that part.

I’m waiting your patches! 😉

And next time you want an opinion from the Alioth admins, please mail us instead of hoping that we won’t miss your blog entry in planet.debian.org.

More fun with Linux and serial ports on slow hardware

January 23, 2007 by Raphaël Hertzog

This is a never ending story for me. The first time I’ve had problems with Linux’s handling of serial UART dates back to 2005 (see my previous blog post on buffer overruns). At that time I could improve the situation by applying two patches (kernel-preempt and low latency).

One year later, I have a situation where the buffer overruns are again easily reproducible at slower baudrate (54 kbauds), arguably there’s more than a serial application running this time, and it looks like the load generated by other processes (mainly watching digital I/O) renders the system less reliable with respect to its handling of serial ports.

This time I follow the advice to try out the 2.6 kernel because many “real-time improvements” (coming from the -rt branch, check its wiki) and “embedded improvements” (coming from linux-tiny) have been merged.

So I tried the stock kernel with very bad result. Results are better than the stock 2.4 but they are worse than the patched 2.4.
So I decide to try the -rt patch on 2.6, but this patch doesn’t work on my CPU card and my bugreport didn’t lead to any fix (nobody responded even though I tried hard to include the necessary information and I was ready to do whatever I would have been asked to try).

At the same time I explain my problem on the linux-kernel mailing list.
The discussion doesn’t answer my questions but still brings two ideas to try out. In the end, with two simple tweaks to the stock 2.6 kernel (mainly configuring the UART to send the interrupt as soon as the first character arrives, instead of waiting for 8 chars to accumulate in the FIFO) I have been able to get something better than the patched 2.4. And it turns out my first choices for the 2.6 kernel configuration have not been very wise so the comparison between stock 2.4 and stock 2.6 above doesn’t mean much.

Unfortunately, even if better than the patched Linux 2.4, it still doesn’t give good results in some conditions. So my primary question remains: is there a way to patch my kernel so that it will handle the serial related tasks (servicing interrupts from the UART mainly) as its primary job ? I don’t mind if such a change impact negatively the speed of the system if I can make sure that my serial exchanges are reliable.

And by reliable I mean of course no buffer overruns, but there’s a second similar problem that has been discovered: when using software handshake, the system can send out between 10 and 25 characters after the partner has sent its XOFF. Sending up to 6 characters after the XOFF is ok, more is asking for troubles because the UART on the other side will probably encounter a buffer overrun…

If you have any idea on how to resolve my problems, by any means, let me know.

Some words about dunc-tank

September 22, 2006 by Raphaël Hertzog

Madcoder decided to quote some bits of an IRC conversation held on #debian-devel-fr and (of course, given his current frustration) he munges the meaning of my quote.

I was explaining that for me dunc-tank was definitely not perfect but that it was a first step in a global direction that I’d like to explore. I explained my long term project with dunc-tank in a french blog entry and I also explained it to Bruce Byfield who interviewed me as a member of dunc-tank.

My long term project always involved that decision-making of what to fund would be shared between the donors and all Debian developers. I sincerly hope to avoid many of the current criticism with this infrastructure but I can’t be sure. In the mean time, the current experiment is not run because it’s perfect and ready for generalization but because we want to see if it’s possible to get enough funding, and if it’s actually worth to invest more time in developing something more acceptable to everybody. (And also because we would really love to have etch release in december)

This is my opinion: I’m not speaking for dunc-tank although I have the feeling that others members of the board are there for similar reasons.

Update: following sam’s bad interpretation I fixed my wording to say “…decision-making of what to fund would be shared…”.

Tags

Recent Posts