http://www.linux.org.au/fta/testimony/
Rusty presented to the Senate Select committee (with slides!) and did a really good job. This is compulsory reading – it explains the issues using easy-to-understand language.
http://www.linux.org.au/fta/testimony/
Rusty presented to the Senate Select committee (with slides!) and did a really good job. This is compulsory reading – it explains the issues using easy-to-understand language.
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.
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.. :)
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.
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.
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.
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.
We’ve got our position paper (at least a draft, going final soon), information on how to fight the nasty IP stuff and a petition.
http://www.linux.org.au/fta/
Lots of work, and community support will validate that effort!
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.
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.
Stick the internel server error in your pipe and smoke it! hahahaha – die spammers, die.
I really want all spammers to die a really slow, painful and final death. I hate them. I really hate them. Especially blog spammers – you should become new armour for battle tanks.
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 :)
New junkcode addition – jpeg_recover.c
http://www.flamingspork.com/junkcode/
Borne out of weirdness going wrong with a friend’s compact flash card while we were on holiday – suddenly a bunch of photos went missing. It didn’t seem to be easy to recover them using conventional manipulations of the FAT filesystem, so instead (without an internet connection, but with lots of beer) hacked up a program that searches through a file (given as the command line parameter) extracts things that look like jpeg files and dumps them in the current directory. It can produce a number of false-positives, which is probably due to the fact that I didn’t have access to any jpeg specs, so this is all from looking at some jpeg files and working out something simple, quickly. But hey, we got a fair few of the photos back.

You’re an Espresso
What Kind of Coffee are You?
brought to you by Quizilla
I think I now understand them, at least for american football. The game is so bloody slow and mostly boring that you’ve got to have *something* to look at that actually *does* something while at the game.
Hell, I’d wish they’d televise them now.
well, after a 13 hour length american national anthem, much like one i saw on some show where it was so long you’d start falling asleep – they’re actually playing “football”.
What a pack of wimps. Stacking on 40 pounds of padding and a helmet to play a game with less contact than Rugby.
really, they should get a proper sport.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/2003110
top browser accessing flamingspork.com atm – w00t! MSIE6 had edged it out of the top position for a little while – but all these people checking out LCA2004 photos seem to like using a decent browser.
rock on.
Okay, finally got around to posting these photos up, so here they are for your enjoyment.
The night was good, and the pub after great too.
Check out my Photos from the other day! (16 Jan)
yeas, i’m about to finish those last four things in packing and leave the room.
ahh… been fine place to come back to and crash. oh, and the network port was nice :)
oh, i just convinced myself to pull my mail :)
all is good fun, great conf, and sad it’s over really. It’s a *big* and *long* week – but ALL in a GOOD way! :)
but will be nice to get home, where i seem to spend a lot less money on beer.