Older blog entries for riscgrl (starting at number 12)

patch 42 commented. simple kernel Makefile fragment.

I went to A-Kon over the weekend. i got nabeshin to sign two of my books of yamato nadeshiko shichi henge! </fangirl>

seriously, I had a blast, other than having a mizerable cold that started the moment I stepped into the car to go. got lots of pics, and some neat cosplay ideas for next year. i'm still not over the cold. *sigh*

I heard back from a job i really wanted. they had a volunteer crop up to do the work they were going to hire me for, but they were impressed enough to offer to fly me up for an interview when they have another opening. so i got a "get out of the phone interview free" card. yay! :)

I've still got help with linuxpmi. maybe I'm actually doing my job as "cheif necromancer". :)

got through hunk #41 today. aparently, the new mail account i set up is broken. makes it hard to extend an olive branch to the old simple openmosix team.

technically, about a year ago, we butted heads. they wanted to drag the dev work to a more modern kernel, before geting core openmosix components stabilized. i went my way, they went theirs.. and seem to have been inactive all of 2008.

I've asked a friend to contact them, while i'm fighting my mail. I hope he's a bit more political than I am, I think I have spent too much time on irc with kernel hackers. :)

i was always of the opinion we should be documenting and fixing the current 2.6.17 tree, rather than trying to keep up with the kernel itsself. while i know the kernels dveloped some new APIs, and merged some code that we're still "maintaining" (in-kernel sockets, kgdb), I'm of the opinion that until we can prove 2.6.17 isn't going to work, we should be trying to fix our code, not introduce new bugs during repeated porting efforts.

Hunk 41 was interesting. It contains the logic for moving from kernelspace to userspace for an openmosix process, as well as several other kernel<->openmosix APIs. It seems most of the code we've added to kernel .c files calls something in this patch.

Google has indexed the new site URL. this time I disabled two trac modules that were confusing google, and that we were not using (the milestones, and the timelines). we're going a bit too slow to use them.

I'm still disapointed we couldnt come up with a zombie themed name for the project. after all, we're slowly moving forward, and looking for BRAAAINS...

oh! and we got git set up. we don't have anonymous git set up, but the usage problem isn't getting docs out (thats what trac is for), but for syncing my two laptops. and best of all, it wasn't done by me. i actually have help for a change. now, its too bad my help is so well spoken and highly educated in physics/maths. holding a conversation has a tendancy to make me feel two feet tall. :)

Today, I drank from a firehose.

We've been planning on re-naming the codebase we're working on from "OpenMosix", a dead project to... something. After a week and a half of getting names and options, intending on having a slow voting process, I heard a name I liked well enough to have a kind volunteer register, since no-one who'd come up with any names agreed with each other.

Aparently, that was a shot that echoed in the halls. As soon as I set it up(actually during that process), my phone started ringing, with local individuals, who prefered one of the other names. then more people on irc started popping in, agreeing. In the end, it looks like my first unilateral decision got vetoed by the community(and they say OpenMosix is dead!).

I also seem to have picked up a few more developers along the way, we'll see how long they stay. I hope my documentation comes in handy, as this was the moment it was meant for. I'd be more than glad to be relegated to the task of documenting only, instead of having all this on my shoulders.

patch 40 commentaried. you'd think commenting on a patch that contains just config options would be easy, but it isnt. found a dead entry, probably inherited from the old 2.4 "weee! wooo!" code. other than that, nothing eventful. one more down.

well, my friends have been bugging me about using a blog, instead of yammering on on IRC, so here goes!

I've stopped hacking Gnu Gift at the moment. decided i needed OpenMosix to accomplish any real Big Jobs. just in time to watch moshe bar kill OpenMosix. without even consulting the dev team, on IRC, who was working hard at the time! needless to say, this disheartening development stopped us cold. nothing like the luminary of your project giving speeches and interviews about why your product is useless, and saying some opinion based / factually incorrect reasons. (there, wasn't that politically correct?). I'm continuing on, first writing a commentary of each patch from the last 2.6 based tree. you can see my work at my "homepage", which is really just a trac wiki. i've concentrated on documentation, due to the wise saying "if you cannot explain it, you do not understand it.". i want to understand what i'm doing, before i run around trying to fix the last grevious bugs. the source tree really isn't in that bad of a shape, its just that moshe wasn't performing linus' job of "project managment" during the 2.6 cycle, and the patches show it.

there are a couple of developers other than myself associated with the project, but after moshe's actions, we're looking to rename it. take our "luminary"'s name from the project. not that we have any good ideas, as "transparent process migration" conflicts with the trusted computing module, and "In Kernel Process Migration Infrastructure" conflicts with some power managment thingie. all the good acronyms are taken.

We're still alive, on irc, waiting for more developers, or someone with a good name! :)

This month's round of patches took a while longer. basically, AMD64 porting issues, making gift build where $(builddir) != $(top_srcdir), and a few insignificant bug fixes.

Nothing too exciting, for 29(!) patches.

Not yet comitting, due to a bit of a slowdown in both the 32bit and 64bit versions. i'm thinking the sizes of my datatypes changing is killing it...

More catching up on gift's patches.

I've now sped gift up from 1.9 seconds per image, to .8. (on a P4 2.2Ghz)

The next steps of optimization have more to do with multi-tasking the extraction process, and re-using the extraction program for more than one image at a time. I'm thinking of converting the program into a tool that accepts absolute file paths of all the files to be converted on stdin, and writing to stdout the name of the file dropped to. wolfram's idea, basically. between that, and running multiple feature extraction processes at once, i should speed things up quite a bit more.

Things have been very quiet on the mailing list, I suppose it has to do with the darpa urban challenge having closed last week, and everyone being way too busy to audit my patches. Not that it matters much anyways, as I have commit access, but a second set of eyes is always a good thing.

I really wish there was more than me programming on this, especially because gift is written in C, Perl, and C++, and I normally don't touch C++ or Perl with a ten foot pole.

But, what needs done needs done. *reads O'reilly perl books/Bjarne's C++ book*

Yaay! caught up in patches to gnu gift, and in work.

I've sped gift up from 1.9 seconds per image to 1.3 seconds per image, and i still have major changes in my tree to filter upstream.

I've had to do some ugly stuff, like reverse the image in memory, and my next set will be to swap X and Y while storing back into the array, which is still in reverse order.

Optimization is ugly.

My personal tree runs in .85. Concidering i'm not the only person who runs this stuff 160,000 times in an import, i'm proud to be saving people days of their computational time. :)

falling behind in patches, falling behind at work..

it could be worse.

at least no-ones bugging me about it yet.

gosh it's been ages since my last advogato-diary-post. ;)

working for a bank, and a wal-mart contractor. both at once, wheee.

been pushing patches to gnu gift recently, as well as tintin++, and FAI (the fully automatic installer for debian).

linux4tv never shipped any hardware. so, no contest, no nothing. other than that? dead busy.

i hope advogato dosent go away.