c133.org/blog
all clee, all the time
Fri, 24 Jun 2005
.: ikaruga ::

Somehow, I just spent four hours playing Ikaruga.

They weren't kidding. This game is hard. Holy shit, this game is hard. I don't think I've ever played a game where it took me four hours to get to the THIRD STAGE before. This game rules.

I don't think I'll be sleeping this weekend.

(oh, and props to mpyne, who kicks *major* ass for dropping Ikaruga to me in the mail. The note he placed in the case reads "Let me know how Level 3 is. I only ever made it to the boss of Level 2." Holy shit this game is hard.)

[21:19] | [tech] | # | G
Wed, 22 Jun 2005
.: wireless future ::

(responding to ChipX86)
Dude. One word.

Batteries.

Ok, to be slightly less cryptic: Wireless devices won't ever really replace their wired counterparts until they no longer require battery replacement to run. Batteries that recharge by gyroscopic motion? Ok, cool. Batteries that recharge by quantum phase induction? Hey, even if I just made it up, it sounds cool, and as long as it means that I don't have to put new batteries in when the current ones die, I'm all over it.

The main reason I don't have any wireless peripherals right now is the battery issue. I've almost talked myself into getting one of the Logitech mice that recharges on the base station - that's pretty close to my ideal scenario. It takes the whole "there's a battery inside" detail and makes it completely irrelevant.

[03:08] | [tech] | # | G
Sun, 12 Jun 2005
.: build system notes ::

We had a discussion in #kde-devel earlier about what KDE's requirements for a build system are. What are the current problems we have with autoconf/automake/libtool? What features do they provide that we really care about? How hard would it be to replace any/all of them with things that suck less?

I took notes of the discussion. They're below; I'd like to get more feedback on this.

(One of the first points that I'm sure someone will make is "auto* is cross-platform! We need to support KDE on platforms that aren't Linux!" etc. Look, we realize this. However, auto* provides lots of problems for us on platforms we do care about, including MacOS X and Windows. (Ask RangerRick or js about them on IRC, or email them.)

Just because we're using auto* and friends doesn't mean that our code works; as a matter of fact, RangerRick noted that so far, all of his issues with the Mac port of the work-in-progress KDE4 have been build issues, and none of them have been code-related yet.

This is clearly a problem and since KDE4 is an aggressive new major release, we should solve it in the KDE4 timeframe. We don't want to have to wait until KDE5 for a build system that doesn't suck, do we?

Without further ado, the notes from the discussion.

Must support:


  • generating binaries (duh)

  • generating shared libs (on all ELF platforms + MacOS X; Windows?)

  • icon installation

  • uic, moc, KConfigXT, etc

  • GCC visibility

  • automatic dependency resolution

  • manual hints for dependency resolution

  • flex/bison

  • non-recursive (flat) builds

  • --enable-final

  • builddir != srcdir

  • simple to the point of being learnable within 5 minutes

  • kdeinit support (?)

  • multiple build targets (libfoo, libbar, libbaz) in one file

  • --compile-slots, like in unsermake

  • pkg-config support

  • support rpath sanely

  • ability to link & run uninstalled binaries

  • easily integrated into KDevelop

  • 'admin' needs to be shipped in KDE instead of in src of each app (if we keep the 'admin' dir, that is)

Would be nice, but not necessary:


  • having a standard and distributed build system and test suite

  • ability to build from svn:/trunk/KDE

Thoughts?

[22:34] | [tech/KDE] | # | G
Wed, 08 Jun 2005
.: cool interview ::

Matt Harrison sent me a link to a cool interview with Ivor Hewitt, one of the guys working on KHTML lately.

Looks like the interview has been taken down. Maybe it'll come back up soon.

Ivor, do you have a blog? Because you should. Planet KDE could use some KHTML blogging love...

[15:46] | [tech/KDE] | # | G