trans pacific open source software conference

i'm back in the islands in a little over a week for tposscon. i was there for the inaugural event last year and am interested to see how things will have matured since. it is once again being organized by the hawaii open source foundation's scott belford, so i'm sure it'll go well. i'll be presenting on each of the four days and i'll be trying out all new material. i'm particularly excited about the 2 hands-on sessions.

one of the presentations, "How Open Source Software Improves Society", is not about KDE but about open source and society in general. i don't believe Free software can or will solve all or even a majority of social ills, but i do believe in the monumental importance of informational freedom for building healthy societies and recognize open source's role to play there. i decided to tackle the topic at this particular event for a very personal reason.

i'll be staying with family while i'm there. they live just outside the community i spent my teen years in: nanakuli. nankuli is a hot and often dusty community nestled in a valley on the leeward coast of oahu. when announcing to the mailing list that i'd be coming for tposscon, scott noted that i graduated from a high school that has been officially labeled a failure.

i phoned a teacher of mine at the high school who i'm still good friends with and she confirmed: they have been declared a chronic failure and have been put under restructuring. they've already spent some US$400,000 to get a private company to come in to raise test scores. yes, test scores. as if that was so important. i understand that it's a quantifiable metric, but failing standardized tests are the symptom not the problem.

when i arrived at nanakuli high and intermediate i quickly discovered that life in a gang- and drug-ridden school where ethnicity was a daily definer (and divider) and poverty was the norm rather than the exception was quite different than going to school in rural coastal british columbia. the social state of the school seemed to overshadow and undermine everything else. but the people had (and still have) great hearts and souls.

the years surrounding my graduation saw a visible decrease in violence at the school. more kids went on to university, including prestigious institutions like harvard. there were several students interested in computing, we had a mock trial team, a math team and more. our student government was active and it seemed things were better. it wasn't a perfect hollywood ending type situation, but it was better and that's all one can hope for from one day to the next in my experience.

and it wasn't because of test scores. it was because of the tireless work of the teachers and counselors, the willingness of the students to explore and experience and the support and encouragement of respected community members that combined to create an atmosphere of positive belief and action.

today serious social problems persist in the community (such as 3 generations of meth use). it was hard to go back last year and see people who had been such believers and hard workers giving up in the face of these seemingly immovable objects.

i'm disappointed that the government has declared my alma mater a failure because the people there are not failures. it's an insult to the school staff to call them efforts failures and demean their jobs to ones of rigging tests; it's an insult to the people of nanakuli to call their children and those that went through that school failures by association. but mostly it is a failure to appreciate the human condition on the part of government. it's a serious undermining of spirit and souls.

i have no solutions, though. my personal solution was to leave, as did many of the others who pursued academic or intellectual careers. i'm not sure it was the best answer, but it seemed like the only one i had at the time. scattered across the world as we are, it remains that many of us came from that "failure" of a school, and i bear no shame for that. i'll visit the school in january and leave no question about that.

pizza, lego, weapons; or, the aftermath of xmas

that less-than-a-week between christmas and new years is usually pretty quiet. people often don't go into the office, shops are less busy, some people take the time to invest in recovery after christmas partying and eating.

the house here is semi-chaotic. pizza boxes (because i don't feel much like cooking right now), dishes that seem to pile up as quick as i clean them (as there are more people around the house than usual) ... but it's all good. it has led me back to wondering about the economics of pizza; the large is nearly 50% larger in surface area than the medium, but only costs $2 more? methinks the cost isn't in the product but the people and location.

i got t. a katana for christmas. i'm not sure if it's the wisest of things to purchase your significant other a weapon. you're kind of banking on them not going crazy in your general direction, but andy gave t. the thumbs up as "officially not insane" about a month ago so i'm feeling pretty confident with this decision. and the sword is freekin' sweet.

the p-man absolutely cleaned up on the lego front. he got about a dozen boxes of the stuff including an electric lego train from his grandma. aside from gradma's contribution of several boxes of lego ranging from large houses to people and people parts, both zack and t. got him lego too. p spent pretty much the whole day yesterday assembling various lego structures. we spent the last couple of hours before bed together assembling a fairly cool house with "brick tile" walkway, trees and a gabled roof. i love lego =)

plasma is coming along as well. i'm continuing to work on infrastructural bits today. should be moving on from applet management to the start of the theme system. zack has started on some visuals and matt broadstone is working on applet loading and javascript integration. these are the basic bits necessary to get some basic stuff limping along. then it's on to engines and getting the appletdisplay classes working. i really need to update the plasma roadmap on the website, but that can wait for the new year.

lo the year end draws nigh

so the 2005 calendar year is almost over. zack and i spent the afternoon in a coffee shop writing code. i was working on some of the more boring bits of plasma: classes for applets, chains (the replacement for panels) and necessary bits of scaffolding. matt broadstone had done some interesting work (now in kde4 playground) showing how we can use the generic kde service loading framework for applets, which means that much less code in plasma. huzzah.

applets have both a global as well as applet-specific config files available to them, solving the global-vs-specific configuration quandry kicker applets have. the idea of unique applets is gone though (good riddance! =). all of the positioning and other such management code is being put into the chain class so the applet class remains small and single purpose; once we get around to figuring out the replacement for applet handles those will also be finding their way into the applet class directly so that we won't be plagued with the current problems where the applet handle (and therefore the menu) and the applet have little to no idea about each other. i kind of worked around this in kicker, but it wasn't pretty code wise nor optimal usability wise.

a couple of hours into the coffee shop experience a birthday party descended around us. an octegenarian and his wife come to the shop every day at 16:00 for coffee and sit at the corner tables we had made ourselves comfy in. today was his 86th birthday so they were joined by a couple tables of friends. we moved aside and wished happy birthday to the celebrant. his wife gave us some birthday cake and we visited briefly with a few of them, including one couple who was from norway.

selecting applications for kde4

personally i divide the software we release as "kde" (e.g. "kde 3.5") into three groups in my head: development framework, workspace, applications. the workspace is stuff like kdesktop, kicker, kwin, kcontrol, konqueror. applications include kcalc, juk, kooka, kalzium, etc. these are not official definitions, they are just how i personally organize the chaos.

looking back at kde2 and kde3 and how our application set grew, i've been wondering if the process could be improved. right now we require that the application has wide appeal (it can't be niche), must use KDE libs, has to be reasonably feature complete, needs to be maintained and can't have legal or security problems. that's actually a fairly low bar and it doesn't really touch on a number of important issues.

obviously, documentation and HIG compliance need to be added to this. but it's more than just that. whenever we add an app to the official kde application bundle (we so need a name for that), we end up stifling third party projects in that same category. we also allow someone to march in with a 1.0 version of an application and put it into svn without it being proven first.

this didn't matter so much when the majority of people who wrote kde software worked within the main kde project and when there were a limited number of kde software projects out there. but that's not the case anymore. today we have a huge community of developers, we have kde extra gear and we have kde-apps.org.

imagine if we had picked a cd burning app for inclusion in kde back when there were four (or more?) kde cd authoring apps in development. would we have picked k3b? would k3b have become as popular? would we have picked one of the other apps that later became unmaintained?

on the flip side, we have apps that went into kde right away. some of them got me really excited as they brought capabilities to kde. but some of them didn't really take off much and remain problematic to this day. now i wish that we'd let them sit out in kde extra gear for a while and see how it went: were they maintained? did competition arise? what did the users pick?

after a while it becomes obvious which apps to bundle: kopete and superkaramba are two examples of this process. k3b, digikam and amarok are probably ready for this now as well.

perhaps with kde4 instead of saying to people "if you're willing to maintain it, commit it!" we ought to instead start our apps out in kde extra gear and migrate the best of the best into our app bundles.

this may end up changing how our release and development cycles look when it comes to applications, however. our app bundles may become snapshots of the last stable release of many apps, while they continue to be developed on their own (and perhaps faster) development cycle. or perhaps we make it easier for apps to branch for a release and continue development. both kopete and kontact have done this in the past.

it's interesting that most distributions already include apps outside of our app bundles (e.g. k3b) as a standard part of their kde offering. so why have app bundles at all? to help guide and direct users, developers and vendors as to what can and should work well together. it's a service of selection we offer to downstream users, and it helps our documenters, translators and developers know what pieces of software to prioritize their efforts towards.

now, obviously, some apps are "must haves" and we can't wait for a longer trial period (particularly elements of the workspace), but for most applications this should work out well.

the goal should be to have high quality, well maintained applications shipped with kde and those are metrics that take a couple of releases to assess, IMHO.

a bit more on xgl

when i write in my blog, it's coloured by my personal knowledge and sometimes i forget to include things that to me are obvious given my day-in-day-out involvement with these things but which aren't so obvious to others. when it comes to the recent xgl issue, i realized that i had not included enough detail after reading this response.

the writer of that "editorial" bit is wrong on several points. first off, XGL is not a new project started by Novell. it was an existing project that Novell hijacked by hiring some (but only some) of the developers and then taking all their work in house, where it is both duplicating and blocking the efforts of those still working in the open. therefore the "getting something working before opening it" argument is not accurate at all.

next, he (i assume it was a he; it could be a she though) compares XGL to luminosity. they aren't the same thing at all. luminosity is not an xserver, it's a layer that runs on top of a given xserver and intercepts the various calls xfake style.

he also says that KDE has not done anything towards this work. he ought to read up on zack rusin a bit. he's a kde developer who has contributed to X and has worked on XGL. more over, we would like to work with this technology as well as consumers of it.

he also tries to frame it as a kde and gnome issue. it's not. red hat, a gnome shop, is as out in the cold as kde is on xgl. we are all losing out on this one.

finally, i find the dismissal of the utility of open development to be vastly concerning. here's a hint: successful open source projects are developed in the open. many otherwise good projects have (and are) failing specifically because they aren't.

as for what KDE is doing about these things .. well, we would like to be involved but we aren't going to be idiots and try and fork off in yet another direction. just because some people feel that's an acceptable response doesn't make it a good one. more productively, we're working with technologies that will benefit from hardware accelerated x servers that will hit end user desktops with kde4. kde will not fall behind in visual presentation. that's not my concern. i just want the open source desktop not to be slowed down (or worse) by the self-centered actions of a few.

so .. what am i hoping for out of all this? best would be if xgl development opened up. second best is if our partners and user base understand what is going on so expectations are reasonable and so they can vote with their feet should they decide to.

a final note: if you're going to "editorialize" on something by writing an aritcle for publication, have the decency to post non-anonymously. identity is the basis of trust, and if you don't feel confident putting your reputation on the line for what you have to say in an article then maybe you should think twice about saying it. =)

iterating in qt4

qt4 has given us more ways than ever to iterate over collections such as QList: traditional "stl style", java style iterators and foreach. which is best to use? i suggest that foreach is great to use when you need to iterate over the whole collection; java style iterators are often clearer to read and code for, especially when removing elements (or otherwise doing things that would invalidate stl style iterators); stl style is good when performance is an absolute requirement, when you feel like being verbose or you are using stl algorithms (obviously =).

i wrote a small test app the other day to answer the performance quandry. turns out that for collections of POD types, stl and foreach are essentially equivalent (no surprise, since foreach is syntactic sugar for an stl style iteration) while java style is slightly slower. for more complex types (i tested with QList<QString>) foreach is within 10% and java style is within 20% of stl style.

but you have to be careful. for instance:

List::const_iterator itEnd = list.constEnd();

for (List::const_iterator it = list.constBegin();
     it != itEnd;
     ++it)
{
    // do something
}

if you don't (e.g. because you can't) use const_iterators, it's measurably slower. if you don't cache the constEnd you also take a large time penalty. and if you invalidate the iterator while iterating (e.g. you remove an element) you need extra code to ensure your loop doesn't end up resulting in poor results (e.g. crashing)

another example:

foreach (const ListType& i, list)
{
    // do something
}

note the use of "const ListType& i"; with just "ListType i" where ListType is a QString you'll incur a good 40% performance penalty due to the code that foreach expands out to. (thanks to matthias ettrich for pointing this one out to me on irc)

so what are the actual differences in times? iterating over a 1,000,000 element collection of QStrings using each of the three methods results in data that tends to look like this:

list has 1000000 items in it
start for loop: "28 118"
elapsed: 362
start java iterator: "28 481"
elapsed: 422
start foreach: "28 904"
elapsed: 393

the numbers came from running the test app on a 1.7GHz laptop and are in milliseconds, so you can see that we're not talking significant (e.g. user-visible) differences even with a set of a million strings.

new server

i share a box with my friend andy where we host our own cvs, mail, database, web, dns, etc... just nice to have your own box for those things sometimes.

emphasis on sometimes.

after getting back from grabbing some xmas loot, i arrived back home to discover no mail. no web. in fact, no server. andy calls me a few minutes later and delivers the bad news: the box is dead, he's bringing it and a new machine over and we're going to set up a new system.

the hardware in the old box was 7 years old and had done its duties well. but finally something on the mobo just went *plonk* and that was that. fortunately, as we were to find out, the disks were fine. whew!

we installed the latest kubuntu on it and set to work migrating things over. i removed the disk pack from the old machine and plugged it into the new kubuntu box. on boot it recognized and set up all the software raid volumes and all we had to do was mount it and start copying data over to the new larger, faster storage. it's nice when things "just work" like that.

unfortunately it wasn't quite as easy as "copy 'n go" because the old box was fedora core 2. yes.. 2. we don't upgrade very often; primarily when hardware fails. i love linux =) so i migrated a number of old-style configs over (e.g. the monolithic httpd.conf to the new slice 'n diced style); chroot'd to the old disks, started postgres, dumped the db's and loaded them into the newer pgsql 8; had to set up more than i should've had to to get postfix+sasl running; etc, etc... 2 pizzas and half a dozen hours later everything is back up and running.

what a way to spend an afternoon.

it was also my first chance to really use adept. it is pretty cool, btw ... there are things that could be nicer (e.g. the sources editor is a bit lo-tek), but for a first stable release it's quite nice and very fast. great job, mornfall! can't wait to see v2.

want my junk mail?

so i just watched my neighbour from two doors down (a rather cute young woman, but who gives me the "danger danger will robinson"s) come over to my place and grab the junk mail out of my post box on my deck and walk back, cigarette in hand, to her place. all calm like she does it all the time.

wtf?

wouldn't be it be nice ...

Wouldn't it be nice if we were older
Then we wouldn't have to wait so long
And wouldn't it be nice to live together
In the kind of world where we belong - the beach boys

it would be very nice if we our X server could use OpenGL directly for its display and composition. because then we could have hardware accelerated effects that are not only cool looking, but also very useful. well, there is just such a project underway, called XGL

but don't hold your breath. the development of XGL has been largely removed from the community and is being done behind closed doors. when i first heard about this state of things i figured there must be more to it but ... nope. it's pretty much the situation.

so instead of getting as many people working on it as possible, instead of allowing other projects to test their software and play with its capabilities, instead of going through the peer-review process that keeps things healthy ... one company has decided that it would be a better idea to hire a few of the developers and put the development into a source repository that only they have access to.

this is worse than your garden variety fork since unlike your usual fork the forked codebase isn't available for others to poke, prod and work on. who gets hurt? everyone who would benefit from this technology, which are, in no particular order: users, users, desktop projects and their users.

this is resulting in other vendors to go off and do their own things. as you probably know, we're already fairly short on graphics programming talent, so this balkanization is not really what we need. it also smacks distinctly of non-Free practices.

i've waited for some time now for this to come to a happy resolution but i see only the current status quo being kept. it seems nobody is willing to openly talk about it, and i understand why: people don't want to rock boats and have uncomfortable conversations in public. but at some point i have to wonder that if nobody is held publicly accountable, if no feet are put to the fire of public awareness and scrutiny, will anything change? i don't think so, because this is a "business decision". this isn't a decision being made within the open source world, but within the board room. and i'm really not happy about seeing a large opportunity go sailing past because of board room politics.

so ... who is this company, you ask, that would take the development of something as potentially important as this out of the community and put it behind closed doors? novell.

You know it seems the more we talk about it
It only makes it worse to live without it
But lets talk about it
Wouldn't it be nice - the beach boys

sunday; kde on solaris

didn't go out shopping like i thought i might today. i realized that it's the sunday before christmas and therefore every place would be nuts. so i decided to do the bits of shopping i need to tomorrow and perhaps some on tuesday when it should be a little less crazy.

picked up zack from the airport with my friend andy, then hooked up with t. and we went for dinner at a japanese place that stays open to a reasonable hour (e.g. 23:00). back at the house now catching up on email and other such stuff.

meanwhile, stefan "kde on solaris" teleman posted a bunch of screenshots of kde on running on solaris. if you've ever wondered what that might look like, take a gander. surprise, surprise! it looks just like it does on linux, bsd or any of our other supported platforms. great work by the solaris kde team to get kde packages together for their favourite os!

faith restored

tonight i found a place in town that plays real blues. hallelujah.

zack arrives later today. what will hit svn between now and next year?

merry christmas one and all. =)

xinerama feedback success

i awoke to 4 emails containing debug output using the patch for the pager problem i mentioned in my last blog entry, and a few more emails with various ideas/suggestions/remarks of support.

thanks to everyone who provided feedback (in just a few hours time, no less!). seems the math in the pager is all correct, so i'm off looking into kwin as the possible culprit now...

running kde 3.5 from source on xinerma?

if you are running kde 3.5 built from source on xinerama, here's your chance to be an open source hero! i no longer have a xinerama system at my disposal to test things and so a few regressions have slipped in. i'd like to tidy those up for 3.5.1 and i need your help in doing so =)

your mission, should you accept it, is to go into kdebase/kicker/applets/minipager and apply this patch then do the usual make and make install. from a konsole stop kicker (`dcopquit kicker` works nicely) then start it again.

once it is up and running, maximize a window and then try and use the pager's drag and drop to move the window from one screen to another. when the window is dropped, it won't move (that's the bug!), but you should now see output looking something along these lines in the konsole window:

kicker:       desktop is 1024 x 768
kicker:       we are: 32x 24
kicker:       delta is 256 x 0
kicker:       moving to: 369 x 146

then send that to me by email (aseigo at kde dot org). i'll note your name in the commit log when i fix it.

ok, that's the end of the productive part of this blog entry. the rest is best classified as half bitchfest, half brainstorm. ok maybe three quarters bitchfest. ;)

i happened to ask for help on irc as well, but the only people with xinerama i could find were running kde from packages. meh. this is more than a little frustrating for me, to say the least.

in a dream world i'd have a bunch of low-profile machines (i don't have a huge work area here) with different KDE branches, hardware configs and OSes on them. then i could just switch on the "kubuntu with 3.4 branch build" on, reproduce the bug, fix the problem and then switch that machine back off. of course best would be if such a testing lab was physically available to more than just one kde developer, but that wouldn't help me (unless i actually follow through on my long time threat and found a kde hacker kommune)

vmware, NX, etc. probably wouldn't address the problem completely as i need to test things like xinerama. and i'd still need a bunch more disk space to store all the images anyways. i know that OS vendors tend to have tons of test systems laying about, but it seems they don't really test the things i end up having to fix (obviously since these problems persist). as for users doing the testing, well ... they tend to be better at finding problems than they are at fixing them ;) and doing remote testing (like this blog for example) is just so bloody slow. i do appreciate the patience of those who do engage in remote debugging with me, but it feels so inefficient.

in any case, this problem should've been solved in the time it took me to write this. and it would have had i the necessary hardware kicking around. *sigh*

what to say: lug radio, community flamewars, xinerama

just got off the phone with the lug radio gang. they had me on for a quick update of the goings on in KDE land. they also took the opportunity to grill me with a few of the usual questions about interoperability and linus. you can hear it on next week's show if you're interested.

and speaking of such things ... i've been sitting on my blog-hands the last few days thinking about what to say as the brush fire ignited from a spark of linus' torvalds pen swept across the community.

i really have nothing to say about the topic itself; there's simply nothing there for me to comment on. but the community reaction has been amazingly frustrating for me to experience.

but how to express that frustration in a way that makes any sort of sense is not easy. the question that keeps circling around my head is: if people are as passionate about this open source stuff, why do they engage in destructive behaviour that works directly against the efforts of those who are trying to make it better? this is not a soap opera for your benefit, this is a real effort being made by a relatively small number of people that, goddess forbid, ought to actually be enjoyable. and someone writing one impassioned email, even if that someone is the pope of linux himself, does not qualify as a reason to ignore that.

it is high time we agreed that we can be individuals when it comes to our project identity and purposes, but that we are generally working in the same space for similar ends: an open source desktop experience that kicks ass. there can be more than one result, but there is really only one directive..

i think it is also high time that we got to the business of making taboo out of the sort of actions that sew seeds of division within our culture.

that way when linus' says, "i like Foo and Bar sucks in this particular way" we can all just step back and say, "interesting. i always wondered what he did and didn't like. i wonder how bar could be made not to suck in that way?" and maybe the answer to that question is "nothing" or "bar is meant to suck like that, huzzah!". but it shouldn't result in tears and gnashing and arguments and fights and stories on the top geek web sites.

this isn't to say we always have to agree, we just have to stop ripping the clothes off each other when we find points of difference. it makes us look like foolish, and there are a lot of people watching. most of those people want to believe in what we're doing, but we keep giving them reasons to doubt.

so how do we move the people in our community in a positive direction? the obvious answer is leadership, but i think we need more than just small numbers of leaders that are self-selected from amongst the developers. not only are we only human (meaning we need to eat and sleep and do slip up as well), and there are very few of us relative to the numbers of people who aren't developers.

i believe it is time community leadership from amongst the user base stepped up and started doing the Right Thing(tm) in these situations. it's time those who write about the open source desktop stopped fanning the flames and instead wrote about strengthening the community (those can be controversial, click-makers too!).

when i see people like frank from kde-look.org and kde-apps.org sites i see the possibilities of such leadership (not to put any pressure on you frank =). those websites show the positive change (and not just for kde!) a committed user can create. he wrote those sites, maintains them and sets a really positive mood and a cool groove.

the community needs more franks.

in other news, i finally made a decision on how to address the transparency painting issues in kicker and simply removed the problematic shadow-around-the-text-labels code from the minipager for 3.5.1.

i also really need to get myself a dual screen system again so i can ensure things work properly there. there have been 3 regressions since 3.4: one in the new DnD pager code, one related to panel autohide occasionally doing odd things and one in the taskbar settings. all fairly minor, but all things that likely would've been caught if i were using xinerama on a daily basis. it's also easier to debug those situations with the right hardware ;)

which is a concern with plasma development since there will be so much from scratch code that will need to be tested thoroughly on both single and multiscreen setups.

wake me up when december ends

good goddess it's been forever since i last blogged. but i'm pretty well caught up on things now and don't feel overly bad about spending some time blogging.

fixed a couple of bugs in kicker for 3.5.1 which is set to emerge in january sometime. got through the minutes for the e.V. board meeting; the other three had already done this and i was the anchor leg as i'm the native english speaker and they are in english. they'll be published to the e.V. any time now and a more public summary will emerge from that.

i also managed to finish up a first draft (not for publication yet) of the outcome of the cross-project coordination track at the osdl meeting in portland week before last. and today i presented on "the present and future of kde" at the online umeet conference. also found out i might be tripping down to mexico the two days before scale in l.a. to present at monterey tech.

the p-man was ill when i got back from germany so we spent the weekend hanging out inside mostly doing things like playing video games on his PS/2 together. he's feeling better now though =)

and while i've been running about in my own little circles so much good has gone on elsewhere ... a solution for automation of application HIG compliance for KDE4 emerging from the recent usability mini-meeting; kde india being founded; a small hill of fixes for 3.5.x and lots of work on kde4; etc ... unfortunately the kde-look.org/kde-app.org server suffered a hardware failure during this time; still down as i write this but hopefully soonish it'll be back on its legs.

and for the record (excuse the pun): american idiot is an amazing album. listening to it on amarok right now as i type this. yum yum yummy.

and on that note, zack is coming out to my place for a couple of weeks of winter fun and hacking ecstatics.

and if you're interested in post-traditional mechanisms for business, economy and generally working together, this is an excellent overview paper. it's now on my "must pass on to others" list. it's amazing to see these memes spread further and further; how long before we see the benefits?

living green; rm work

i'm sitting in basyscom's (eva's business) offices in darmstadt today and i've noticed that there is a slightly "greener" approach to things in at least this building: the number of lighting fixtures is lower than what i'm used to in north america, and most of the lights are actually left off. even in the cafeteria only about half the lights were on during lunch. the stairwells are left unlighted. ample windows help a lot, but it is impressive to see how many lights are simply left off. and people use the stairs to go between floors instead of elevators. and they recycle. wonderful. simple little things like that all contribute to lowering our footprint (massive as it is) on the environment of our planet.

on the down side, i went to update and build my kde4 installation and ran into a problem with kdelibs and decided the easiest approach would be to wipe out the build and just recheck out the sources since it's been a while since i've done that and a similar problem i'd had previously had been most easily addressed in this manner.

only i forgot i had unchecked-in work in kdelibs, including the qt4 designer plugin builder. *sigh*. oh well, nothing like doing things twice. =(

i'm just a travelling fool

i'm currently in mainz, germany which is a charming little city near frankfurt. the e.V. board is having an in-person meeting, and the progress we're making is very good. it's not the most fun work (to say the least) but critical. we currently have 7 pages line items for meeting minutes. we'll be cleaning them up and publishing them to communicate our progress.

most fearsome, perhaps, is the todo matrix we've generated. the working groups are just gonna love us. but i'm very pleased with how the board is working out: first a quarterly report (mad props to Allen Winter for that) which we've released to the e.V. membership and which we will be shortly also publishing more publicly, and now this meeting.

it hasn't been all work and no play, though. we went for some wine last night at a local restaurant, and then a pint afterwards at a pub that eva used to go to when she lived here previously. walking through the town in the evening revealed several historical roman structures and the general calm of the place. the people are also quite nice.

i flew here directly from the osdl desktop architect's meeting in portland. i nearly missed my flight, actually, due to having been kept company by some of the industry people the night before for a tour around portland's night time scene. this included flaming spanish coffees, a kareoke bar and an after hours eatery. upon arriving back home, i packed and then accidently fell asleep (instead of heading to the airport). i woke up 2 hours later with less than hour before my flight.

fortunately i had made friends with the night desk person the day before and she did a great job of getting me checked out and in a cab in short order. she even said she'd thought about phoning up to the room to ensure that i came down in time since i hadn't registered a wake up call. people who pay attention to their work like that deserve extra credit.

in any case, i got to the airport but realized i didn't have enough american cash on me to pay for the ride (and my bank card didn't work with their system =/ ) so i payed the last few dollars in euros. the cabby had never seen euros before and had to be convinced that: a) "euro" is a real currency, b) they were worth something and c) that they are actually work a bit more than the US currency. he took them in the end mostly because i didn't give him much choice to do otherwise.

i fly back home the day after tomorrow and i'm looking forward too it. portland and mainz have seen some very progressive days for me, but it's time to rest up and get back to coding again.

as for the results of the desktop architects meeting, we're prepping some combined communications which should see the light of day this week. some of the announcements ought to rock a few worlds out there =)

star crossed .. hackers?

while waiting for my flight to portland in the san francisco airport, i sat down in the waiting area and started listening to the conversations around me (yeah, i'm nosy like that; bad habit i know). the guy right next to me was talking to a portland local about how to get to a particular hotel from the airport via the max train that runs through the city. something about him just spoke "hacker" to me. and no, he wasn't overweight, bearded, etc ... he just had that aura.

so i struck up conversation ... asked if he was going to portland on vacation or whatnot and he said it was mostly business (though he was meeting up with his g/f later in the weekend). i asked what he did for work and he said he was a software developer. i asked what he was doing in portland (told you i'm nosy; but i just had this feeling about him) and he said he was attending a conference. i asked which one. he said an osdl conference. bingo!

i introduced myself and he did likewise. turns out it was alex graveley, who you may know as a vmware developer or as the guy who wrote tomboy or who worked on evolution's exchange connector back in the day. we were both impressed by the serendipity of being on the same flight, but really it wasn't that big of a random chance given the hub that s.f. is and that the conference started the next day. so i said, "wouldn't it be wierd if we were sitting next to each other on the plane?" so we whipped out our boarding cards and .... he was 27A i was 27C. woah.

we ended up sharing a row (he by the window, me on the aisle) with nobody sitting in the seat between us. this allowed us to put notebooks there and discuss development ideas.... turned out we have a fair amount in common technology vision wise and may end up working together on some pretty interesting stuff in the near future. we'll see.

upon arrival we took the train together and continued the conversations all the way until our stops. in any case it made the 3 hour expedition from s.f. to the hotel a very enjoyable one and i must say that alex is a very enjoyable and intelligent person.

i hope we do get to work together on some software in the future ...


as for the actual desktop architects meeting ... so far so good. presentations are ongoing and most of them have highlighted really how much we have in common and helped to expose more openly our common needs and goals. will be interesting to see where we end up at the end of the day and at the end of the conf.