Inkscape

Just did my first illustration using Inkscape (www.inkscape.org). It’s pretty cool. Open Source Vector illustrator (produces SVG graphics and has good bitmap export).

i.e. select what you want, File->Export Bitmap (and it’s already gone to the “export selection” thing, choose the res of the image, where it is, and click export.

Funky!

exciting new world of comments

comments are back! well, until the spam is unmanagable, and then i’ll have to go and moderate everything. At least it’s better than MT though, where it just accepts everything and you have to go hunting for bad things.

I like WordPress!

I’ve started to use Straw again, a cool News aggregator for GNOME (written in Python from memory). Basically to try and keep up with various blogs/dev blogs around the place.

Spatial Nautilus

Okay, so debian finally caught up to the rest of the world and unstable has GNOME 2.6 packages. So, everything has settled down, and i’ve dist-upgraded my laptop.

After a logout/login cycle (unfortunately, everything doesn’t "just happen" when you upgrade, I’m now onto GNOME 2.6 and spatial nautilus.

Yes, this whole idea where "the window IS the folder" idea that has made computers usable since the first Mac is back. And, Guess what? That’s right, it’s GOOD! There’s the browser interface also, so you can go and do things how you used to.

my mother has been using this for a bit (since we put Fedora Core 2 on here machine, well, actually, one of the test releases).

i’m also gathering up the strength to go and install FC2 on my desktop…. as long as I can get DVD stuff going, i’ll be okay :)

and then there’s the whole bootloader thing… gah. i fucking hate the way partitioning and bootloading works. generally, not just the extremely bad way that PCs do it.

reminds me… gotta test my yaboot patches for sparse files on XFS.

and move away from movable type.

new headphones

Today (well, *technically* yesterday, ’cause it’s 2:30am on sat now) my new headphones arrived in at work. From Grado Labs, Alessandro Music Series One.

Pretty good so far.

Having to go through my iMic on my desktop PC as the built in sound has too much noise (you hear this high pitched tone with the headphones).

knew that imic would be useful.. :)

book.

The instructions are: Grab the nearest book, open it to page 23, find the 5th sentence, post the text of the sentence in your journal along with these instructions.

This optimization prevents the wasted copying of large amounts of data (the address space, easily tens of megabytes); in the common case a process executes a new executable image immediately after forking.

memberdb work

been doing a fair bit of mods to memberdb recently – getting features in.

– new css based look (which is almost correct)
– more solid code around the place
– better error reporting (that needs debugging… hahaha)
– a start on the positions tracking UI
– change password UI
– sorting of the memberlist
– moving look and messages into site customisable directories (so nobody has to get scared by memberdb code itself)

so, been busy :)

some of these have made it to the stable branch… i guess i’ll put more of them in there as things actually stabilise. Especially since linux.org.au is actually running the stable 0.2 branch now (which is nowhere near final).

Have no real schedule or ideas on when to release 0.2, maybe when i’ve done the positions stuff, fixed the CSS and made a “edit member info” (accessible to admin and each member) UI. That’d be a real big leap from 0.1 :)

I’d like to put GPG stuff on the cards for 0.3…. but it’ll be tricky finding a nice way to integrate everything. I’m thinking along the lines of a UI where a person enters their key ID, fingerprint and keyserver (then we pull the key using gpg). To help verify, we could then send all email gpg signed/encrypted :)

we’d then have to have a not-well-trusted GPG key for memberdb installations – which could be… interesting….

but hey – it’s the one big feature request from an outside group.

They want to have GPG signed applications – but maybe they’ll settle for sending GPG encrypted mail to the applicant (saying “confirm membership like this”). The validity of the key can always be checked before approving the membership – it’s going to have to be semi manual anyway.

onode unique id versus packing id

along the lines of how reiser chooses to pack things on disk (heuristic that makes numbers of where and how to pack things).

onodes get a unique id.
– to be used in indexing (onode_index primarily, but also higher level indicies)

onodes get a packing id
– onodes with similar packing ids get put on disk together (theoretically). Numbers can overlap. i.e. non-unique. if two onodes share the same packing id, we REALLY want them to be packed together.

Tightly packing onodes

The current problem is that an onode, however much we can pack forks into a block, still takes up a minimum of one disk block. A disk block typically being 4kb, and a tendancy to want to be bigger (think large media files), and also being the unit of atomicity with disk writes.

So, how do we allow multiple onodes per block?
We could take the inode table way of doing things, and just have “an onode is X bytes, and X/block size = Y many onodes per block”, but that does have a lot to be desired – we may want variable sized forks to be stored along side onodes (e.g. what would typically go in an inode).

One way is to split each block into N “sub blocks” or “chunks” (or “insert-cool-name-here”). Basically have a block bitmap with N bits per block, and a chunk size of block size / N. This would allow us to have N onodes per block. Simple to implement (we wouldn’t even have to change the onode_index, as we could do a simple linear search for the onode, even storing them in onode_num order, enabling a binary search). But, if we had a 256kb block size, this means 32k per onode, no matter what. Annoying if the volume has both large media files (where the 256k block size helps), and small files (a unix like operating system or even a Maildir). Volumes are now big, and users like having one big file system on them – so we must be more flexible.

Do we want to (can we?) provide onodes which span blocks? My feeling is no to the latter – as in within the onode struct itself. Having an onode which has forks in other blocks seems like a quite reasonable (and indeed, needed) thing to do. So, we could have lots of onodes tightly packed into a disk block, with the forks being in other blocks. Typically though, you probably want at least one fork packed with the onode, as there aren’t many operations on the onode itself.

So, if onodes (along with some forks) can be a variable size, and we want to pack these into (quite possibly) large blocks, how are we going to do it?

I reckon we can pack them all into one block, with padding where needed (to have it so that no onode crosses atomicity borders) and rely on packing things in a block in a cache friendly manner.

talking at luv tomorrow

talking at LUV (Linux Users of Victoria) tomorrow night.

on:
– netfilter/iptables (a howto use it, well, some of it)
– Linux Australia update

and in the update I’ll be talking a lot about the AU-US Trade Agreement – after looking into it, i refuse to use the word free in relation to it.

the whole IP and patents things are really nasty.

no doubt i’ll try and rant about them here soon. i think i need a rant.

trade agreement

doing more work on documents related to the trade agreement, and the IP stuff within. it’s actually tricky to write something that’s good – but I think I’ve always known that.

my way of writing something seems to be to just edit and re-edit until happy. Granted, it usually works – but jeez it can be slow sometimes.

but it was good being able to talk to Rusty after the meeting today and nut through improvements to the doc.

memberdb 0.1!

Oh yes, time for me to abuse my position and spam a bunch of lists! :)

memberdb is the membership database software i’ve been hacking off and
on for a while now, and is being used by Linux Australia.

In it’s current form, it’s visually not very pretty – but the backend
database has had a huge amount of design (and redesign) work put into
it. This release is to encourage feedback, patches and volunteers.

It’s also out there so that other groups can look at it as a possible
solution to their membership database needs. Okay, realistically,
they’ll need a lot of work on it before it suits them and not us. It’s
called contributing dudes!

Yes, there are bugs. Yes, probably a security issue or something that’s
slipped me by – open source, peer review – all good.

Anyway, go have a look:
http://www.flamingspork.com/projects/memberdb/

or grab the 0.1 tarball from:
http://www.flamingspork.com/projects/memberdb/release/0.1/memberdb-0.1.tar.=
gz

even better, grab the latest sources and start hacking! esp if you’re a
XHTML and CSS guru – i need them :)