lca: the forgotten stories

as some have already heard, a bunch of people (including jdub and david s. miller) got various bits of their cranial hair removed on the last day of linux.conf.au. in fact, jdub took it all off, full monty style.

the night before at the wrap up dinner, maddog did his usual charity auction. the clock-made-of-a-linux-mag-cd-signed-by-linus-himself fetch $700, but the real show stopper was to be the lions' book. john lions wrote a book called "lions' commentary on unix 6th edition, with source code", on which topic wikipedia says:

Lions' Commentary on UNIX 6th Edition, with Source Code by John Lions (1976) contains the complete source code of the 6th Edition Unix kernel plus a commentary. It is commonly referred to as the Lions book. Despite its age, it is still considered an excellent commentary on simple but high quality code.

For many years, the Lions Book was the only Unix kernel documentation available outside Bell Labs. Although the license of 6th Edition allowed classroom use of the source code, the license of 7th Edition specifically excluded such use, so the book spread by samizdat. It was commonly held to be the most copied book in computer science.

what they didn't mention is that at&t actually reneged on their agreement with lions and the book couldn't be published for many, many years. as lions came down with a terminal illness, his friends rallied and convinced SCO (when they were still a unix company out on the west coast) to give the "ok" to a reprint and they did. now they are setting up a permanent chair at the university of new south wales, where lions taught, in john lions' name. it's going to take 500,000.

usenix is ponying up for a chunk of that (half, IIRC), and the book being auctioned was to go towards that amount. whatever the book fetched, linux australia would match from its own pockets, and in turn usenix would match that sum.

well, the copy maddog brought with him was signed by people you may have heard of such as dennis ritchie, ken thompson, van jacobson, linus and a few other such luminaries. it was also signed (on a separate page, of course ;) by the speakers at linux.conf.au 2006.

rusty russell did the honors of auctioneer and the book reached into the low thousands, then the bidding stalled. so jeff waugh (jdub) got up on stage and announced that if it reached $6,500 he'd shave his hair off. this was met with applause and bidding edged up to (IIRC) $4,444.44. and it sort of stalled again. so i went up and noted that whilst i didn't have the flowing locks of jdub, i sure would like to help things along to where jdub's challenge was met and he lost his hair. so i offered a mention in the about box for kde 4.0's plasma desktop if the bidding reached 5,000, and for each 500 up to jdub's 6,500 i'd fix a (fixable) bug in kde of the winner's choosing. bidding quickly reached 6,500.

but that wasn't the end of it. jdub went back up and offered a mention in planet's release notes; mysql offered a mention in mysql 5.1; rusty russel donated his mustache; david s. miller his beard; and greg "groggy" leheya of bsd fame offered his beard as well.

bidding reached 10,000. much hair was lost.

who spent that much? a bunch of lions' old students got together and raised a mighty pot to ensure the book went back home to the university of new south wales where it will adorn a wall for years to come in his memory.

in accordance with this, the "thank you" in the plasma about box will bear the name of john lions' and a recognition of his contributions as author, teacher and researcher to the world of computing.

and jdub shaved his head. bwuahahaha! ;-)

and they say mondays are bad

it's tuesday. i've discovered that the brazillian consulate in toronto closes rather early each day; that it's a bitch to get flight miles added to an account after the fact; that it's really obvious that ldb has been primarily used by only one major project; that kconfig needs a bunch of work done to it to get ldb (or any other backend) properly integrated into it (though someone had the foresight to pass in the resource type along with the path to the kconfig ctor).

toes the cat is back home as of today. he's got energy again and is eating and drinking small quantities. he's even used the litter box twice today. i have to hook him up via an i.v. needle to a bag of electrolytes twice a day just to ensure that he remains hydrated during his recuperation. i hate needles; as in i usually go light headed / faint when in in the presence of their usage. and now i'm actually shoving them into my cat twice a day.

and they say mondays are bad =(

ldb take 2

in my last blog entry i mentioned working with ldb for kde configuration. there was, as expected, a good amount of feedback most of which was negative. i thought i'd take a moment to address a few of the issues raised.

first the good news: kconfig was designed to have multiple back-ends available. i'm adding ldb/tdb as a possible backend; an env var controls which to use for now (makes it easy for testing things =). i see no reason to get rid of INI style configs altogether: applications still just see KConfig objects (so it matters not to them), and for other subsystems such as the services resources and application menu entry objects it continues to make sense to distribute those as INI style files. add to that the issues of migration from kde3->kde4 and the braindamage of NFS file locking and it just becomes pretty obvious that keeping INI-style config files as a backend is a no-brainer. that much was obvious to me from the start.

so there is no need to hyperventilate over INI files going away .....

some were concerned about storing the data in a binary format. people often go running and screaming from binary formats, and for some good reasons: binary formats have been home to some of the worst implementations of these things ever (e.g. the windows registry), and binary formats are usually impervious to text editors.

personally, i've worked with unix(-y) systems for years and really like a lot of things in them; being able to edit things with a text editor is among those things. if ldb didn't provide facilities for that, i wouldn't be interested in it.

but i do i believe it's important to separate failure from design; just because a particular airplane design tends to crash a lot, it doesn't mean that fixed wing aircraft are a bad idea when it comes to flight. so pointing to the windows registry (or gconf, if that's your axe to grind) and howling is not the most adroit means of evaluation here IMHO.

if you wish to edit your data via a text editor, you can certainly do just that with ldb using ldbedit (which launches $EDITOR).

and unlike the windows registry with its alice-in-wonderland-like maze of obscure entries with mysterious values, i'm keeping the same naming conventions so we can see "kickerrc -> general -> AutoHideDelay: 0" and with the beauty of kconfigxt even be able to see what the zero value means, what the range of allowed values is, etc...

and of course you can also export the db to plain text. that's how ldbedit works, actually.

but what about stability? well, ldb/tdb is being used by samba4 which in turn is being (or will be) used in some pretty heavy duty installations. when it comes to single sign on, printer access and file server stability failure isn't exactly an option nor is slowness. i'd also note that INI-style files aren't impervious to corruption either (as i noted, i just had a bug report on kicker about this exact problem last week), though they can keep it compartmentalized due to separate files.

so, how about the speed? that's the issue i'm working on right now. after years of using the same $KDEHOME, i have 181289 entries in 14066 groups spread across 386 files. cp'ing the rc files takes ~0.045s. migrating those settings over takes ~105s on my machine of which all but ~6s is spent in lbd_add, which amounts ~142 groups/second. kconfig's INI backend does it ~18s, or ~781 groups/s.

i need to do some more testing with realistic usage patterns and ensure i'm not using the API wrong and therefore tripping it up ... i also need to test read with appropriate indexes more before i can comment on those things.

ldb & kde

while at linux.conf.au i spent a bit of time with tridge who was keen to showcase ldb which is the new "ldapy" storage backend that was written for samba4.

i've begun working on ldb support for kde and while i'm a few days away from having something worth committing so far it's looking pretty good. ian geiser had done some work on this already, i believe, as well. personally i've become convinced it's the way to go for kde4 and am putting in the effort to get it there. why?

ldb is an embedded database that mimics ldap. because it's embedded it's fast and memory lean. it had to be as samba has some pretty insane performance requirements. from what i understand, these performance requirements is what caused them (the samba project) to write their own thing rather than reuse something that was already out there. but it's features go far beyond performance:

firstly, it's transactional and multi-reader/writer safe. this means that if an app is writing to its config and crashes (or, as in a recent kicker bug report, the user purposefully kills it during such a write process) the configuration file doesn't end up in a non-usable state. it also means that even though everything is one file, it's perfectly suited to having dozens of different processes hammering away at it and all without having a separate daemon process.

it offers an ldap-y API and storage format but without the requirement of schemas (hallelujah!) and provides network access for free (just provide an ldap:// URI instead of a local ldb file path). they are now working on replication, so all users of ldb will get that for free eventually as well. indexes keeps access fast, and mmap'ing the file intelligently keeps page-ins and memory usage minimal. even the "two-phase commit" transaction system for writing is kept light-weight enough to not become onerous.

it's also scripting and human friendly. with command line tools and a "vipw"-like tool for the database, one can either use scripting or a text editor to edit the contents of the database (or any specific branch of it). this was one of my bigger worries (alongside safety) of using a monolithic binary file.

the obvious implications of all this are that kde could get a centralizable, replicatable, scalable, fast and safe config storage system that can move us beyond ini-style configs without much work on our part. being able to store data in binary formats also means that we may find we get some performance boosts from not having to ascii-ize everything on the way out to the config file and repeat the process in reverse when reading it in.

this translates into various perks such as making kde even more attractive for large roll-outs where centralization of config data may be desirable, making it easier for users to know what to back up ("just back up the kde.ldb file!") and bringing us a bit closer to integration with samba.

by providing a nice KDE-style front end to LDB we may also finally provide a nice way for app developers to store hierarchical data without resorting to abusing the INI file format (think mail filters or accounts in kmail, panel layouts in kicker) or deciding they need to use something else such as their own hand-rolled XML concoctions.

the latter is The Big Dream here. imagine a "firewall to phone" type solution based on the combined value of linux/bsd (firewall & operating system), kolab (groupware), samba (file/print), astrisk (voip) and kde (desktop productivity, document management, phone GUI and voice mail access) all with their configurations being held in a common LDAP(-y) database. so when the sysadmin adds a user they can get email, calendaring, file server access, network printer access, PBX access and desktop configuration provision all at the same time and essentially for free.

this obviously requires letting these individual pieces tie into the same configuration infrastructure, and it seems samba4 has the most sane option in our world right now from a desktop perspective. i talked with an asterisk guy at linux.conf.au about some of these things and will be discussing it with kolab people as well. and getting kde4 on ldb would be us doing our part to make this happen.

hopefully others will agree with me and we'll have ldb files as an option for configuration files in kde4 =)

lca wrap up

i'm feeling a wee bit jet lagged right now. my body is urging me to sleep, but i need to get some food into me first and i figured i may as well do email and blog a bit.

linux.conf.au was amazing. i met several people for the first time and got to attend some really terrific talks (vanJacobson's presentation on speeding up networking was really impressive, for instance). i didn't get to much the first two days as i was speaking for the length of each of those, but the the next two days i only did half days and friday was all mine to attend at will.

the osdw miniconf went very well, with those attending being pretty impressed with what kde has to offer. kde's dev framework shows really well, so props to everyone who has been involved with that: you've done a world class job! we covered everything from build systems to database programming, from kparts to ioslaves... very fun.

the kiosk talks were well attended and there were the usual number of "jaw drop" moments as people discovered just how powerful and flexible kiosk is. when showing kiosktool a few people expressed interest in helping improve it, and i even received a patch the day after the conclusion of the kiosk talks implementing one of the suggested improvements. open source in action! =)

the kde4 talk got the most attention, filling one of the 2 larger auditoriums. phonon, solid, oxygen and plasma all impressed, as did the amazingly cool "appfs" demo based on george staiko's code ....

the dinners and evening events were very enjoyable and provided a great way to speak at length in comfortable surroundings with various people. in the picture we were about to play some pool post-dinner while talking about various user interface metaphores (i believe we were discussing "leaves on water" when this one was taken, actually)

during the days and some evenings it was work as usual. i got to spend some hacking time with newly met friends. a highlight was tridge (of samba fame) demoing ldb for me; we discussed usage of it in kde over the next couple days (more on that in another blog entry). of course there was the usual networking, intra-project bridge building, user relationship building, etc .... thankfully, linux.conf.au is very technical so there were no "suits" and an extremely high godlikepersons quotient in attendance.

the kde thong accompanied me, as it does to most of these events, and was an instant hit with me being asked to recount the sordid details of its existence a few times and once even being cajoled into modeling it for a bunch of shutterbugs in the main causeway:

ill cat

i returned home last night to learn that my cat is ill. he's in the animal hospital overnight getting some tests done. hopefully he'll be alright.

i think t. was a bit upset with me over the whole issue as i was going to wait until monday and was a bit shocked at the cost of the treatment. she's someone for whom the health and wellbeing of an animal is worth just about any effort and expense and, with tears in her eyes, probably found my reactions a bit callous.

relationships are amazingly complex, doubly so when jet lagged, trebly when a loved member of the family (the cat, in this case) is having medical issues ...

oh really, now!

Boudewijn: what does Krita need Qt4 for right now? is there nothing that couldn't be improved right now that doesn't need Qt4? imho, krita would survive just fine on linux/unix for another release or two and i don't see how image embedding or text printing affects krita.

the problem here seems to be the monolithic nature of koffice. sharing code between all those apps makes tons of sense; having an integrated office sweet makes just as much sense; but not allowing individual releases of apps where it makes sense seems pretty dense to me.

krita can't devel against koffice 1.x libs for another release or two while koffice2 libs come into being? i dunno, perhaps not. maybe krita is a good example of what ought to move to kde4/qt4 ASAFP.

i don't think it holds for for vast majority of apps, however.

enthusiasm and evening karaoke

the best things about presenting on technical KDE topics to people who are just now learning how to write KDE software are meeting new people and feeding off their enthusiasm. it reminds me of how i first felt those years ago when i discovered kde 1.9x: amazed, enthused, wanting to get going, like, yesterday and in awe of those who wrote this stuff.

if you want to recapture a bit of your own initial energy, try holding a little workshop somewhere sometime on kde devel. it's truly fun, and osdw.org has a growing number of presentations for them. i'll be uploading the presentations from lca at the end of the week.

last night after speaking for nearly 7 hours during the day i went out for dinner at a nice indian place that was all vegetarian and vegan that was beyond tasty. from there we went to this little pub where everyone was heading to listen to a d.j. show done on linux. the music was less than intriguing for me so i took off down the street with a fellow i met here. as we said "hello, good evening" to every person we passed to engage in a social study of the locals, we found a karaoke place on our way and we decided to send a rescue party back to the pub in the form of a cab.

10 or so people crammed into the cab and came back and we essentially owned the karaoke stage from there on forward. some of the attendees are truly great singers. we finished off the night with a choral rendition of "we all live in a yellow submarine". the entire evening was captured on video. fun.

on the way back to the university res, we passed a pair of young women walking the other way. given that they were dressed in bar clothes and were carrying highball tumblers with the dregs of their last coke-n-something-alcoholic drinks i figured they might know where the dance clubs are. they obliged and told me a very complex story about where the various places are. i'm directionally challenged so i asked if they could draw me a little map or something. one of them obliged and took my pen saying she'd write down how to get to the better places. as she's writing i asked which place it was she was jotting directions for and she says, "oh, this is my house. here's my name too. and my cell." i guess that's sort of like knowing how to get to the dance clubs.

there are also some cool pictures of the kde logo done in sugar i did over lunch yesterday (yes, i get bored easily) that i have to track down and upload.

new kde tag lines: "kde is sweet" and "kde: not bad ... for a beginner!" (the latter is apparently some sort of kiwi in-joke)

LCA Day 1

day one of linuxconf australia (in new zealand; oddness) has been great so far. dunedin is a wonderful university city with a very friendly populace. there's tons of veg fare for me to eat within a few blocks of the university and the uni's residences where i'm staying are quite nice. i have a room to myself, and that helps =)

there's an excellent group of people here at the show so far; very technical and not much manager-n-suit types. i've chatted with maddog and met linus when he arrived yesterday, so there are some of the "superstars" here as well. but it's all very relaxed and fun.

the main conf doesn't start until wendesday, however. right now it's just the miniconfs. the morning osdw session has just finished and i'm heading for lunch now. it's progressing well, so perhaps we'll have some more open source desktop devs in a few days ;) paul campbell, author of the laptop support in kde, is the room proctor, so we're getting to hang out and chat a bit. i think i've even convinced him to do the kdevelop presentation tomorrow.

kde3 or kde4?

with kde4 development underway, the question of when to target kde applications
for kde4 versus kde3 is being asked by more developers. should new applications
begin developing against KDE3, KDE4 or Qt4 only? should existing applications
port to KDE4, become Qt4 apps for the time being or continue using KDE3?

the open source community tends to have a(n overly) pressing emphasis on the
bleeding edge. this is often good as it keeps things moving forward. but it's
not always necessary; sometimes "old" (as in: it was released last month) is the
best option.

kde 3.5 was just released, and the first update to it, kde 3.5.1, is set to be
released in the coming weeks. with kde4 a year or so away, 3.5 will likely
continue to be the default kde desktop shipped on supported operating systems
for at least the next 12-18 months. remember that many linux distributions haven't even made an official release that contains 3.5 (though many offer it as a post-installation upgrade).

moreover, when kde4 does ship, it is highly unlikely that kde3 libs will cease to be distributed instantly. this is because there will bre many kde3 apps that haven't yet been ported to kde4 when 4.0 is released that users will still want to use.

one of the mantras in open source is "release early, release often". for
applications, waiting 12-18 months can be a killer. the obvious answer is to
continue to target KDE3 for upcoming releases so that releases can continue to
roll.

also remember that kde4 libs are still a sea of shifting sands. developing against them can be a bit frustrating at times. we are porting
most of the apps that ship with the KDE desktop in micro-steps every time a new
libs snapshot is made, so we do have apps to stress and test out the libs. but
this probably isn't what most application developers (or their users) want or
need. it'll likely be some months yet before kde4 libs settle into something
resembling their final forms.

what about moving to qt4, then later to kde4? well if you're a typical kde3 app, you'll end up having to provide a large amount of code to replace common kde functionality only to remove it and rework the app to use kde facilities again. in some cases, it's not a big deal. in others, it is. my concern would be that apps that go from kde3->qt4 would remain qt4 apps and not get kde4 integration for a long time hence. and targetting qt4 won't get you a huge audience yet anyways, at it's not yet a staple in most operating systems which are predominantly shipping qt3 right now due to the relative recency of qt4's release.

so it would seem that sticking with kde3 libs for application development may be
the best bet at the moment. but what about the innevitable port to kde4 in a
year?

(this may seem like an especially crucial question for new applications but just
as with existing apps, new applications should release early and often and get
users on board to prime the feedback cycle. so i don't see a big difference in
importance for new versus existing apps here)

my personal experience in porting apps from KDE3 to the current KDE4 libs has
been promising. it is far from a rewrite, and in many cases some judicious
scripting can really help with the effort. personally, i wouldn't be afraid of
spending the next year developing a kde3 application (releasing 1-3 times in the
meantime) followed by a "kde4 port" release. we're also providing a kde3 class compat library along with 4.0 (though that will likely be phased out in 4.1 or 4.2)

in 9 months this will probably be a different scenario, but for now i would
personally recommend kde3 for application development. this also helps the kde
project in general. how?

as we work towards kde4, we won't have a new kde release for a while. not an overly long while, but longer than our user base is generally used to. during this time, new application releases will give people something to new to try out and give them something to talk about beyond the "yet to be released super amazing kde4". =) in a way, we're relying on application developers to provide a kde buzz that will be skipped due to no 3.6 release since we're working now on 4.0.

obviously the more kde4 apps we have when 4.0 hits the floor the better. but 4.0 is a ways off yet. if you are an application developer, think about what timing is best for your schedule and for your users.

happy hacking.

firsts

this week i crossed the dateline for the first time, entered the southern hemisphere for the first time and found my first white hair in my bear.

not bad for the 31st year of my life.

more qt4 treeview; OSDW, LCA and SCALE

i've written a few times in my blog about qt4's treeviews. i promise i'm not obsessed with them, but here i go again. ;) marius, the troll (as in trolltech) who looks after that particular bit of code (though i hear ben meyer is helping out there as well these days?), wrote me to let me know that inserting items one by one into a view triggers worst-case scenarios in painting/updating/etc.

indeed ... the way one should do bulk inserts is by putting them into a list and using insertTopLevelItems() or insertChildren(). then things go a lot faster, even in 4.1.0 =)

marius also mentioned that they are working on some serious optimizations in the header views for qt 4.2. given another release or two with these sorts of optimizations and qt4 is going to be seriously fast compared to what we have now. and it's not too shabby already ... so buckle up =)

however, other than a kicker bug i'm going to squash today (knock on wood) it's not going to be a big coding day for me.

i did upload a couple of the presentations i did at tposscon last week after someone asked for the slides. now you can click through them as you listen to the audio. yes, they are in kpresenter format. i haven't gotten around to doing an html export. pradeepto, of kde india fame, converted all the OSDW presentations into html. i need to get around to uploading those.

i'm busy today getting my presentations in order for linux conf australia (aka lca) 2005 which, tricksylike, is not held in australia this year at all but new zealand. i'll be speaking for the first 3 days with breaks for coffee and lunch; the first two days will be an OSDW affair (no, it's not on the website *sigh*), the third day is a set of presentations on using kiosk to deploy KDE. the fourth day i only have one small presentation to do on KDE4 and then i get to see what other people are up to. i was hoping not to do all this alone, but the various people who had bravely volunteered ended up having to take care of other commitments. some managed to support me in other ways, including bard hards who pitched in for some of my flight costs along with lca and the aukland linux users group. thanks to all involved there.

there'll be another OSDW event in north america in may in philadelphia. the boys and girls at sourceextreme will be helping out there.

i'll also be at the southern california linux expo where i'll be presenting the same kde4 presentation i'm doing next week at lca. there'll be a kde booth there as well and i have one helper lined up already, but we have room for 2 more. so if you are a kde fan and would like to hang out and chat with the event visitors, please email me (aseigo at kde dot org) and i'll hook you up with a free pass.

the day before the cali event i'll be stopping in mexico to keynote at the Sistemas Computacionales y Tecnologías de Información at moneterey university.

and then i stay away from people until mid-april.

hawaii wrap up

i'm back home from the trans-pacific open source conference and am using the weekend to get down to the business of catching up with my housework. when i arrived home a small wooden pail of bath goodies awaited me with a note from t., which is just what i needed.

the event started off difficult: attendance was low, i was witness to vendors taking advantage of local efforts without supporting them in kind, local government is sadly myopic and i managed to argue twice with my mother (whom i was staying with while there) over our moral differences in the first two days i was there. i was questioning the wisdom of me having gone, and instead of coming home at the end of the day and breaking open the code editor i generally just went to sleep after prepping for my talk the next day.

but then things picked up. i went to a meeting of local technology entrepreneurs and talked about open source and KDE with a number of people there. the box of kubuntu CDs i brought emptied quicker at the tposscon conference than i expected. family life (esp seeing my niece again for the first time in years) improved, finishing off with a gourmet vegan meal prepared by yours truly. i was interviewed at my high school for their video magazine about culture and community. the last set of presentations were really well done and though provoking, such as john terpstra's "linux: the business opportunity".

but most uplifting was on the last day of the conference, following a lot of discussion on how to improve the event for next year, was the creation of the hawaii linux project. i presented the end note entitled "10 ways to get involved in open source" and jim thompson closed the event with the hawaii linux proposal: a localized version of linux done through the local hawaiian charter schools. this includes translating everything into hawaiian, providing hawaiian calendars and artworks ... the whole bit. they'll most likely be using kubuntu as the base for that as well. it was very encouraging to see not only support but action being taken in support of open source and the local people.

and as if that wasn't enough, i learned that the western samoan delegates had decided to go ahead with switching all 9000 of their educational desktops to linux. apparently they will be using the kde-based linspire distribution for this. perhaps we'll get a samoan translation of kde sometime in the future =)

audio recordings of the presentations are available online, with video to follow.

kubuntu by the crateload

i received 2,160 kubuntu cd's yesterday. looks like i'm the new north american kubuntu warehouse. and given that kubuntu releases every 6 months, these CDs have a limited shelf life. looks we'll be swimming in CD's at north american events this year! =) big thanks to riddell, canonical and the (k)ubuntu project.

qtreewidget speedups; urbanlizard.com

model/view (aka "interview") in Qt4 is very cool. but since it does raise the complexity bar, one of the early concerns was that interview would make development painful for simple listbox/treeview usage. trolltech listened and added widget implementations of the various views that are meant for simple use. in fact, they look a lot like the qt3 APIs. best of both worlds, right?

well, i noticed that adding items QTreeWidget in Qt4.1 was disasterously slow. the first 100 items would take ~200m which already way too slow, but it would get worse (like 0(n^2) worse) the more items one added. by the time one got to 30,000 items, it would spend over three seconds adding the next 100 items on my 1.7Ghz laptop. ouch.

some pointed out that QTreeWidget is really meant for small collections of items and anything very large probably called for a model anyways. well, i could think of a few use cases that isn't particularly true, but even then 500 items taking 1s to be added? zoinks!

ben meyer took a look at it this week, however, and things are going to be much, much better in 4.1.1. after applying his patches and re-testing, adding 100 items takes just a few ms. but even better (and more importantly), adding another 100 items even after adding 100,000 other items still only take a few ms. it's still a bit slower for this kind of worst case scenario adding insanity than the qlistview it replaces from qt3, but nothing significant. huzzah for ben and qt 4.1.1.

i'll bet there's even more such "low hanging fruit" in qt4. as matthias mentioned in a blog entry last week, the upcoming releases of qt are just going to push the bar even higher as they add not only features but performance.

in completely unrelated news, i licensed off local calgary rights to a website i wrote between 2001/2002 for finding local restaurants, clubs, bars and entertainment for a cut of revenue. the backend is designed for multiple cities, it has an integrated sales tool and a client participants site as well. but it was essentially abandoned after the guy doing sales (and my biz partner at the time) developed a nasty drug habit which threw his life down into the sewer. i was so busy with other things i couldn't devote time to getting the business side of it back up and running and, to be honest, it was a bit depressing all around.

a friend of a friend came around last fall, however, and asked if he could give it a crack. i figured, "what the hell..." who knows, maybe i'll see something for the effort i put into it one day ;)

writing, hacking, appeal transparency, electricity

this week is going to be filled by tons of prep and writing for tposscon and some mag articles i have upcoming. today was no escape from this.

i did manage to get some bits of hacking done on kde4, such as ensuring kurl turns ~s into home dirs more reliably. you know, exciting stuff. ;-P i did manage to discuss some plasma art related items with some of the artists. but yeah, pretty low key day in terms of coding.

it seems that some people have issue with the appeal project contending that it is "closed". appeal is a virtual or umbrella project; it isn't producing anything itself, but projects within it are. this includes plasma, oxygen and more. the mailing lists are open, the svn repositories are too. the wiki isn't, but the reason for that ought to be pretty obvious if one thinks about it for a couple of moments ;)

so why oxygen isn't releasing more of it's art right now? well, what they have released has already made its way on to people's desktops. yes, i've seen actual screenshots of actual desktops using the oxygen folders, for instance. there's nothing wrong with that, but it is if we wish this new look to be associated with kde4 and be fresh with kde4 comes out ... well, that's not going to happen if it's publicly released now for kde3. art is rather different from code in this way.

that said, oxygen isn't done yet and won't be for many months. it's a big effort. those putting in the efforts are working on it together; i see the collaboration on the public freenode irc network all the time. were i an artist with a keen desire to aid the oxygen project and were able to match the quality and concepts i'd probably just email those involved and see about getting involved. but i'm just a consumer of the artwork, and while i've had input on concepts (e.g. the "icons of different types need to be visually distinct, even if subtly/subliminally" idea) i have no pressing need to see their day-to-day pixel improvements. and i don't =)

anyways, the highlight of the day had to be peyton and a plasma ball type device i have. it's a gift from my previous neighbour (the smarter, cooler one less scream-at-your-girlfriend one) and peyton really likes it because .. well .. it's damn cool. =) today he figured out that if you put a bit of metal near the glass, then put your finger near the metal object you can cause purple bolts of electricity to arc through the air. he noted that it stings a little, but that it's really cool looking.

"that's mah boy!"

glx updates; end of zack's visit

so zack is leaving tonight. it was really enjoyable to have him around for a couple of weeks. yesterday we drove out to banff, which is a small alpine town nestled in the center of a national park reserve. it was a bit chilly (though i'm sure zack would label it as simply "too cold" ;) but enjoyable. we ate in the nearby town of canmore at a vegetarian restaurant. it was the first time he'd been in the rocky mountains, so that was a nice way to cap off the visit.

i wrote in a recent blog entry about novell taking glx development internally. there have been a few updates since then.

dan kegel brought it up on the desktop architect's list and nat replied that they are planning to release the code in february at xdevconf. when asked if this was going to be simply a code dump, nat said, "Total merge, long term useful. One tree to rule them all, etc." we'll see when february rolls around, but i'm hopeful. i think most of nat's rationalizations for the situation were weak and i still believe it was a non-optimal move on their part. let's hope things can come back together because we're all (novell included) best served by that.

but meanwhile the non-novell developers have not been able or willing to sit still waiting for a future event. as zack noted in a recent blog entry a bunch of xgl code has been committed to the official x.org tree by these people.

this means we officially have a fork between the code bases. i was hoping this would be avoided, but given the circumstances it was highly probable. how this pans out will have to wait for february and beyond. hopefully the two trees will eventually become one, be developed openly in the x.org repository and bring our scarce graphics development resources back together again.

happy new year everyone!