Debian – Page 89

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…”.

Steering committee or board?

September 4, 2006 by Raphaël Hertzog

There’s a new idea floating around: creating a steering committee for Debian. I like the principle but I think we should aim for a broader change in the constitution.

I don’t think creating a new separate structure is a good idea, because in my opinion the DPL should be the steering committee. Of course a single individual can’t play that role. And in fact, this is true for almost any task that the DPL currently has to handle.

So we need to get rid of the DPL and to replace it with a board. And that board would be the steering committee and would also have the responsibilities that come currently with the DPL hat. Why?

First of all, the role of DPL is to provide a vision but most recent leaders have not been able to do that as they tend to get overwhelmed by simple administrative work. If you remove the hope to effectively lead Debian by giving that power to a committee, then you scare everybody that wanted to be DPL because it effectively become an administrative position with no interest.

Then, in recent years, the DPL position tended to become a multi-person thingie, first with the DPL team idea and this year with the 2IC (sort of a “DPL assistant”). So it looks like we’re ready to switch to a fully multi-personal leadership: one of an elected board.

And last point, since the DPL tends to be active only on internal organizational issues, for most persons he’s only working on “political” stuff and he’s not valued as contributor leading the distribution where it needs to be lead: to the next release.

That’s why I suggest that the board should be elected for an entire release with a maximum of 21 months. After each release we elect a new board and it should be in place for 18 months ideally.

Tying the term to a release seems like the right approach to me: at the beginning the board is effectively doing most of its work as steering committee (setting/approving release goals) and at the end, during the period where we’re freezing it has more time to concentrate on organizational issues.

The questions is now: how is that going to work with the release managers? Will that position become only an administrative work of low-level coordination without any influence on the whole distribution?

Tags

Recent Posts