Older blog entries for tausq (starting at number 13)

Haven't posted anything for a few days... um... let's see....

I uploaded a i386 build of boot-floppies last night/this morning. Looks like there's going to be another build tomorrow. Things are moving nicely along. According to aph, all the reported rc bugs are now fixed. There remains some other rc problems, but I trust we'll have those worked out. I am a bit concerned about m68k and arm which are supposed to release with potato. Unlike the other archs (alpha, sparc, powerpc and i386) we don't get active participation of m68k and arm developers on irc so I personally don't have a good feel for where they stand... I've heard they do have somewhat working boot-floppies though.

Looks like I'll be in California for a week in June doing a bit of travelling. Should be fun...

My curry is getting better... :)

I spent some time tonight discussing with several people how to convince companies to sponsor Debian. The fact is, because not many OEMs sell systems bundled with Debian, the project has rather low visibility outside of the technically-savvy clique. IMHO it is definitely in Debian's best interest to more aggregively publicize and promote the project. This will open many more doors both technically and socially for us to make a difference.

<sigh>now i feel like a politician

I have a bunch of other stuff i was going to say, but they are probably best left unsaid ....

As joey says, 6 espies for dhd! He apparently wrote a hello world program for GTK in assembly!

I've been looking at SOAP for a while now. Seems like a neat idea.... there is a mod_soap project in its beginning stages, and I'm working with Chris, who registered the project at SourceForge, to get things going...

One of my dogs, a 14-year old dalmation, had to be put to sleep today :-(. I have two other dogs at home that are about that age. <sob>

<rant>

One of my biggest complaints about the Debian project is that we lack good project management people. Of course, it is to be expected that with 400-odd developers and many to-be-developers, coordination and communication are key. Sadly, no one seems to put a lot of emphasis on this. Our slow release cycle is (IMHO only, of course) a direct consequence of poor communications and coordination. Sure there is tons of work involved, but it can be done much better and more coherently if we had a plan in place rather than everyone going about doing their own thing. Many of the flamewars that erupt regularly on the lists also stem from people not communicating well and arguing before thinking. I'm sure this is nothing new, and many of these assertions have been made before, again and again. Sometimes I wish some of the Debian folks would just take a more draconian approach to the issues that are brought up and deal with them quickly and decisively.

</rant>

Later, when I'm more calm....

Since I didn't feel like doing any work, I decided to go package something :P xerces (XML library from Apache) looks pretty interesting. XML seems to be in the news so much lately, I wonder if it's all hype.... been looking at SOAP a bit. The idea is good, I think, but there seems to be fairly severe performance tradeoffs. Hrm...

well, we got lully back, but without the disks :/ We're supposed to get 2 18G in there, but I wonder how long that will take.

Let's all participate in jgg's find-Culus'-photo contest! (not!)

lully didn't get turned on today (why am I not too surprised?), because TLS says they are busy with COMDEX. I really don't understand why it takes so much effort, hrm... it's now supposed to be turned on tomorrow.

One idea I had today while working on db.d.o -- I'm thinking of creating a "karma" measurement of Debian developers. (yes, I like the Advogato trust metric too much :P) It'll be something like:

sum({C_i | i = {packages maintained}})/n - sum({B_i | i = {outstanding bugs in packages}})/n

where n is the number of packages the person maintains, C_i is a "coefficient of importance" (ie an essential = 1.5, important = 1.4, standard = 1.2 or optional = 1 package), and B_i is a "coefficient of severity" (critical = 1.5, grave = 1.5, important = 1.2, normal = 1)...

Sounds a bit crazy... hm..

Happy Birthday, Joey!

Heard from TLS today; lully is supposed to be back online Wednesday. As always, I'll believe it when I see it... the good news is that they seem to be hiring a Linux/Alpha person; hopefully things will work out better then.

Did some prototyping work with the new db.d.o replacement. Might need to talk to gorgo about packaging the php4-dev files. It'll be interesting to write some new modules for the encryption stuff. I'm a bit worried about the load php places on the server though. I guess it shouldn't be worse than forking perl.

It really bothers me that USWest seems to have a monopoly for DSL ISP services in my area. I called a few ISPs and they say they don't have access to my location, even though I already have DSL wiring and stuff. Hrm...

potato boot-floppies:

I wonder how many ways modconf can break.... sigh... well, I released another version, hopefully it'll work. drow got powerpc boot-floppies to work, so it looks like we're pretty much ready to release 2.2.11. Mostly just waiting for the word from aph now. There seems to be some problems with the kernel/pcmcia modules dependencies still; I wonder what's going on there.... my vmware license expired, and I don't really feel like paying $299 for one. There are still lots of minor glitches with boot-floppies. In some ways I'm continually amazed that it actually works. It'll be interesting to see what we can do in woody. I expect some fairly substantial, if not a total, rewrite.

Morning

Compiled some ia64 stuff at work. Basically I'm just trying to get a few simple tools going. dpkg compiles (mostly), except it depends on perl, which I don't yet have. perl in turns depend on gdbm.... then i decided I wanted to get wget to make it easier to download sources. Turns out you have to force a -D_GNU_SOURCE for wget to compile correctly (took me about 30 minutes to figure that out ): ). Well, wget depends on gettext, which uses libtool, which is just utterly stupid and refuses to work with ia64 without lots of tinkering...

Anyway, I was in the middle of compiling gettext when my connection died... <sigh> Fun stuff, eh?

oh, and apt also mostly compiles, except that there seems to be a g++ parsing bug upstream. Hopefully that'll get fixed soon.

Evening

Am looking into php more to see if we should do db.d.o-NG in perl or php. php makes things a bit simplier in some cases, but lacks strong encyption support (it seems). For perl, with the new IPC::SharedCache stuff we can probably make a more secured system, but I'm a bit worried about how to properly garbage collect stale entries (similar problems with doing this in php). I'd also like to figure out a way to do LDAP (and possibly some SQL backend) connection pooling either with PHP or mod_perl.... hm.... is it even possible?

Today's fun C++ saga starts with some progress on the event mechanism I was thinking about yesterday. I am now able to trigger events like this:

void SomeWidget::RandomlyFireEvents()
{
  KeyEvent e;
  /* fill in e */
  FireEvent(&KeyEventListener::KeyPressed, e);
}

This has the advantage of being strongly typed, with most of the work done at compile-time. FireEvent is a funky method that is defined like this:


typedef void (Listener::* pmf_t)(EventObj); template<class Listener, class EventObj> inline void Event<Listener, EventObj>::FireEvent(pmf_t pmf, const EventObj &e) { listeners_t::iterator i; for (i = listeners.begin(); i != listeners.end(); i++) { ((*i)->*pmf)(e); } }

I guess all you C++ gurus out there will think this is obvious, but I thought it was pretty neat :-)

I still need to do some tests to determine the space/time efficiency of this system though. Oh well.

(Some time later...) Culus has sort of convinced me that this won't work if a widget wants to have multiple events of the same type, but in different queues. He plugged the deity system as being more flexible. It is better in some ways, but I really do not like the void * event parameter that is used in so many widget libraries.... <sigh>. Is there really no perfect solution?

I've been putting it off, but I think I need to rethink the db.d.o code and redo a lot of it.... hm...

4 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!