Proposals submitted...
The Linux Conference Australia
call for papers is now out, and I've submitted two papers - one for a
talk and one for a tutorial. Now the waiting begins...
In 2009 I got accepted to give a talk on writing good user documentation. I'd submitted several papers before then but never got accepted; the chief reason was that I had submitted papers about stuff I was interesed in but was not actually a key contributor to. LCA is crazy hard to get to speak at, but is totally worth it because they really treat speakers well. And to me it's addictive - I loved it so much in 2009 I wanted to do awesome things just to get a place in 2010.
That didn't work out for me; mainly because I'm a neophile. I tend to be interested in a whole bunch of things but only shallowly - occasionally (such as when I decided to write the doco for LMMS) I dip in but I rarely seem to be able to sustain that involvement before the next thing comes along and lures me away. But I'm more hopeful I can get a speakership at 2011 because I'm putting forward two proposals for things that I'm actually really involved in and know about.
Ah well. Now for three months of anticipation. Better keep on working on
my electric motorbike then...
posted at: 09:45 | path: /tech/lca | permanent link to this entry
Weird boot problems fixed by mkinitrd
My brother had a weird problem where his MythTV machine stopped booting.
From a screenshot of the boot (as in JPEG sent by email) it appeared that
the boot process was missing some part of the LVM volume group. I got
him to boot the System Rescue CD and let me remotely SSH into it, and to
my surprise I found the LVM working fine.
I mounted the logical volumes, used mount's -B option to bind the /dev, /proc and /sys into the same file system, and chrooted into the directory structure. All worked fine. Suspecting the boot process had an old record of the LVM layout, I rebuild the initrd with mkinitrd. Copying it into place and rebooting brought the whole thing up again, much to his and his partners' delight.
Another successful bit of Linux troubleshooting achieved.
posted at: 21:34 | path: /tech/fedora | permanent link to this entry
Gabarn-yowtj-ja
Wikis in general have revolutionised information on the internet. Not
only is data and information more accessible but it can be improved as
time goes on with the same amount of effort. They apply the 'many
eyes' principle of fault-finding and make it easy for someone who can
improve something to do so. Before wikis, web pages were arcane things
guarded by religious orders of designers and programmers, charged with
the sacred task of protecting these pages from just anyone editing them.
Now content has been opened up to the masses.
We don't, however, have the same kind of tool for data. I'm talking both about tables of information - phone number lists, customer data, etc. - and the relationships between them. There's masses of data like this around, and most of it is in CSV files, HTML tables and occasionally in some database or other. There are interchange formats around and systems like ODBC for communicating between one database engine and another, but this still involves the database administrators to come forth from their temples and bless the queries and connections.
We need tools that can allow a web site to:
And while I'm finding Django to be a great framework to work with, I still seem to end up doing all the work of manually importing CSV files, KML lists, HTML tables and former SQL databases. This should be a simple process of no more than half a dozen steps. Every table in Wikipedia should be a data reference that can be sorted, keyed against, and used in someone else's pages. Google has put a lot of effort into understanding everything from movie times to stock prices, but for the rest of us it's a matter of asking a programmer. There's all sorts of interesting data mash-ups going on but they still seem to require APIs, server software and lots of code.
It's hard to stand on the shoulders if giants if you can't climb up...
The title of this page comes from the Wagiman
language from the Northern Territory. It roughly means fast-find - given
that I know of the language only what the dictionary gave me I don't know if
I've formed the words correctly. But it's that key property that I think
makes this such a compelling idea. The ability to throw a CSV table into a
website and it become searchable, sortable and accessible to others instantly
is compelling. While I think hand-crafted data relationships will always be
faster or more accurate than automatic imports, the latter is still better
than locking the data away for want of a system to access it.
posted at: 14:57 | path: /tech | permanent link to this entry
When awesome is no longer enough
Kate and I went to collect the mail on Sunday from our post office box, and
discovered I had a parcel waiting to be collected. "What is it," she asked.
I replied that I honestly didn't know. Either it was a T-shirt and book
from Penny Arcade, or it was two
books from Weregeek, and since both
of them were coming from north america it was hard to say which had won the
race. Besides, I love getting parcels (who doesn't?) and the delicious
suspense was increased by finding out on Monday that the parcel was too
large to fit in my small satchel and I would have to collect it on
Tuesday.
It was from Penny Arcade, and contained their book The Splendid Magic of Penny Arcade and the Automata T-shirt. The latter was awesome enough, but from my brief foray into the former I have to say that it's everything I had hoped for and more. I'm only really a casual gamer so a fair number of the in-jokes about the industry go over my head, but even without that fine detail the humour still bites in. And it's not all gamer jokes, some bits (Cardboard Tube Samurai, for example) are just awesome, some bits are thought-provoking, and some I just love for how they hit home and make me say "Yeah, I can relate to that."
And I think Penny Arcade shows that two ordinary gamers - two ordinary people - can make something fantastic that goes from strength to strength and keeps coming up with new ways to be awesome. You don't need million dollar executives and lots of marketing. You need good things that reach out to people. Jerry and Mike love what they do, and they do what they love, and in the process they give millions of dollars of toys and money to charity, they run massive events like PAX that are insanely popular, they make a webcomic that is smart, funny, crude, bizarre, beautiful and even touching, and they prove that gamers can also be successfull without sacrificing their origins or being chewed up and spat out by the industry. That's an awesome example to show to people.
This is why I love reading the background and history and detail behind Penny Arcade. I love seeing Gerry's comments on cartoons, I love seeing the toys and stuff that people have made for them, or the cartoons that others have drawn with Tycho and Gabe. I love it for the same reason I love watching the episodes of Penny Arcade TV - because I learn more about them as people by listening to them talk about how they make up a comic, and this gives their output more depth to me. To see a guy at PAX take the microphone and thank the guys for keeping him cheered up during his tour of duty in Iraq, and watching Gerry go and give him a hug, says much about how much those guys really care than all of the millions of dollars that Bill Gates donates to his own charity each year.
My charity philosophy this year is to support webcomic artists. I read in the order of sixteen webcomics - some daily, some every couple of days and some intermittent. (The great thing about being in the east coast of Australia is that 4PM is midnight in the USA, more or less, and that's when new comics are traditionally dropped into their waiting servers). I don't pay for reading them normally, and this year I have decided that I will. I've paid $25 to Cheyenne Wright, the Hugo-winning colourist for Girl Genius when he had an accident. I've now bought stuff from Weregeek and Penny Arcade. When the mood takes me I will buy more stuff from the web comics I like. Because this basically goes directly to them, modulo some postage and handling - there's no publisher or media outlet standing in the doorway taking my cash and saying "we'll 'pay' the guys, yeah, sure".
It's not tax-deductible. I don't get a picture of the child in Uganda that
I saved from starvation. But someone out there gets to do what they love
- write webcomics - and entertain me in the process, and overall I think
that's a win for both of us. And I get some nice books and neat T-shirts
too, which I can use much more readily than a photo or a ribbon.
posted at: 17:03 | path: /tech | permanent link to this entry
Energised communities
Last week I went along to a group at once new and very familiar. They all
were passionately keen about a new technology, and yet they'd all had to
explain the benefits over and over again to disbelievers. Most of them were
working on their own projects but came together as a larger community.
While they all knew it was the inevitable way of the future, powerful
commercial interests were working against them and governments and the
general public seemed indifferent to their cause.
This was, of course, electric vehicle hobbyists.
For my part, I'm keen on constructing an electric motorbike. I'm also interested in adding open source components and microprocessor controllers to various parts of the project, partly to keep the cost down (some of the proprietary parts are really expensive) and partly for the fun of tinkering.
There were three main topics of discussion during the night:
Firstly, there's a lot of interest in the local group in starting a EV racing standard and, within one to two years, getting actual races happening. Initial ideas revolved around a standard car chassis that is fully CAMS approved (which is necessary for official racing), but then someone mentioned go-karts as a lower-cost entry level category which also got a lot of nods. There's already moves in this direction (CAMS has had an Alternative Energy division since August 2008) but getting the community groups - schools, Scouts, youth groups, etc - involved is a great idea.
Secondly, the group is trying to collect information about building EVs into an online resorce. I put in my oar and proposed using a wiki (which they sort of have already) and keeping it public (opposing the person who said it could be monetised in the future), both of which met with general agreement. The current process they're using is for one person to be a 'subject matter expert' that collates all the ideas from the group into an article, and that then gets put on the Wiki and people can edit it from there. This combines the best of both practices of document writing, and I think it's an excellent way to go.
Thirdly, there was a lot of interest in the hardware hacking theme that is all the rage at the moment. Everything from makerbots and repraps to arduinos and programmable fridges was met with interest and requests for more detail. I'm trying to find their email list to make a general announcement and I'm hoping that I'll get a few people coming along to the next CLUG meeting. There's a number of projects out there, from David Rowe's work on controllers to the Tumanako project that are applicable to EVs. I really need to point the Canberra EV group in the direction of the Electric Saker sports car - a New Zealand project!
My main quest for this month is to make the plans for my new electric motorbike,
and to understand what a battery management system does and find one that
doesn't suck.
posted at: 17:35 | path: /tech | permanent link to this entry
Power seller
I had known for some months that my laptop battery was gradually waning
in power. When, at OSDC, the battery
light started flashing three short orange and one long green, I didn't
need to Google it (though I did, of course) to find out that this was the
laptop's electronics saying "you really need to think about changing that
battery soon".
The problem was, however, that in my previous examination of the situation I discovered that most of the people selling laptop batteries under website names that look like they should be Australian are, in fact, pretty much one or two companies in Hong Kong operating a plethora of different web fronts. Using 'whois' on their domain names mostly tells you the truth, as these people don't bother to get an address in Australia to use as their administrative contact. Do not be fooled by use of '.au' in their domain names or Australian flag icons appearing in their banners.
These are made more dodgy still by then having spammed the Canberra Linux Users Group list shortly after I posted to it asking "where do I buy laptop batteries at a decent price from an Australian company?". The behaviour makes me think of the stereotypical chinese market hawkers, yelling at you to try their products, very cheap, for you special price, broken English permeating the whole transaction with the feeling that somewhere, somehow, you're going to be ripped off. I resolved, after OSDC, to find an Australian company that would sell me a battery for my still perfectly serviceable Dell Inspiron 6400.
Lo and behold I found one - Laptop Plus, which advertises itself as "Proudly Australian Owned & Operated". I also found a few eBay sellers advertising batteries, but since eBay cares as much about verifying the location of their sellers as they do about checking whether the postage is reasonable, I decided against shopping there. There are a reasonable number of sellers of Inspiron laptop batteries claiming to be in Australia, some even selling the 7200mAH batteries. But I decided to go with Laptop Plus, even though they were more expensive.
My decision was rewarded with prompt service, prompt answering of my
questions, and speedy delivery. The battery came in a nice foam-padded
box and checks out by the laptop hardware. It just worked, and I'm
very happy with their service. I can only hope they will be around in
another three years so I can buy another battery from them.
posted at: 23:08 | path: /tech | permanent link to this entry
The new age of programming
I gave a lightning talk at OSDC
this year and thought I'd write my thoughts up into my blog. It was
the confluence of a number of ideas, technologies and thoughts
gradually merging, and I think it's going to be an increasingly
important issue in the future.
Most laptops now have at least two cores in them. It's hard to get a desktop machine without at least two. The same chips for ordinary x86-architecture machines will soon have six, eight and twelve cores. The Niagara architecture has at least this many and quite possibly more. The Cell architeture allows for up to sixty-four cores on-chip, with a different architecture and instruction set between the FPE and SPE cores. The TileGX architecture includes one variant with a hundred 64-bit cores, connected to three internal DDR-3 memory interfaces and four internal 10-gigabit ethernet interfaces.
The future, it can therefore be said, is in parallel processing. No matter what new technologies are introduced to decrease the size of the smallest on-die feature, it's now easier to include more cores than it is to make the old one faster. Furthermore, other parts of our computers are now hefting considerable computation power of their own - graphics cards, network cards, PhysX engines, video encoder cards and other peripherals are building in processors of no mean power themselves.
To harness these requires a shift in the way we program. The people who have grown up with programming in the last thirty years have, by and large, been working on small, single-processor systems. The languages we've used have been designed to work on these architectures - parallel processing is either supported using third-party libraries or just plain impossible in the language. There have been parallel and concurrent programming languages, but for the most part they haven't had anywhere near the popularity of languages like Basic, C, Pascal, Perl, Python, Java, and so forth.
So my point is that we all need to change our way of thinking and programming. We need to learn to program in small units that can be pipelined, streamed, scattered and distributed as necessary. We need larger toolkits that implement the various semantics of distributed operation in the best way, so that we don't have people reinventing thread processing badly all the time. We need to make languages, toolkits, and operating systems that can easily share processing power across multiple processors, distributed across cores, chips, and computers. We need to help eachother understand how things interact better, rather than controlling your own little environment and trying to optimise that in isolation.
I think it's going to be great.
posted at: 11:48 | path: /tech/ideas | permanent link to this entry
The journey is the destination
I attended CodeCon
2009 this year, along with two friends from Canberra. This is an event
where you go camping in a nice out-of-the-way location with no internet
connection, take along your laptop, and hack away on code. There's lots
of talk, lots of coding, enough seeing and walking and doing to keep the
various personalities interested, and lots of sharing of ideas and thoughts.
Peter Miller organises it, including hiring a generator and bringing along
a bunch of tarps, poles, cables, and other stuff to make it all work - he
does a splendid job and gives a lot of his time to making sure it all runs
smoothly.
My feelings, coming back from the event, are overwhelmingly positive. This is the sort of affirming event that LCA is to me - talking to people who share the same jokes and ideas and worries, being able to help as well as ask for it, and realising that there are people of all ages who enjoy both geeking out and camping out. It's not for everyone - you have to be prepared to bring everything you'll need, cook your own meals, set up your tent and not have running water or a light at the reach of your hands. But obviously some people do enjoy it, and that's just fine by us.
Highlights for me were those belly laughs from brilliantly timed witticisms by other people; seeing a Lyrebird about 20 metres away (thanks, Kate, for lending me your small binoculars); getting a whole bunch of coding done; those quiet times discussing how life works; and how, sometimes, you just have to be a bit patient to wait for the annoyances to move off.
This isn't really a hour-by-hour account, as I'm not sure that kind of write-up would do it justice. But it was really great, and if you're at all interested in camping and hacking on code then it's well worth making the effort to go to. You don't really need access to the internet to get things done!
(I should investigate the possibility of running something similar at the
Yarrangobilly
Caves - thermal springs ahoy!)
posted at: 23:10 | path: /tech | permanent link to this entry
The wonders of modern technology
On Sunday I had some friends around to play computer games. Actually, due
to one of those typical glitches in communication which happen when trying
to arrange things a fortnight in advance with people on a Sunday night, only
one friend turned up. The game we were most familiar with was StarCraft,
which I still think has the best idea for getting people interested in
playing - a 'spawn' version that allows you to run up to eight people on
one registered copy of the program. Considering the problems I'm having
trying to convince these friends to spend even $10 (for Supreme Commander
through Impulse), a spawn
version of some of these games makes perfect sense to get people interested
without them having to shell out up front.
Of course, we first had to go through that dance of getting the networking set up and the machines talking to eachother. My machine would appear on his display when I first set up the game but would immediately disappear. Wireshark from another computer on the same switch showed traffic from both, but short of being on a dumb hub (and who has them these days) I couldn't tell where the problem was. Probably a firewall problem somewhere. Rather than spend a lot more time faffing around with networking settings in Windows, something I'm not entirely familiar with these days, I went with plan B.
Plan B worked perfectly, first time. Instantly we could see eachother, and our games went perfectly smoothly with no lag or hitches. What was this wonderous technology?
Serial cable.
By some miracle both computers had nine pin RS-232 serial ports; by another miracle I had a null modem cable with nine (and twenty-five) pin connectors. I deduced that it was a null modem cable because it had two female plugs. StarCraft did the rest. Hours of enjoyment.
The next day I found how to get the two machines talking to eachother - more
precisely, how to convince the Windows Firewall that StarCraft was one of
those programs it could deliver outside packets to. So next time we won't
have to get the serial cable out. But I'm pretty happy that the option was
there...
posted at: 16:35 | path: /tech | permanent link to this entry
Understanding the chinese room
The Chinese Room
argument against strong AI has always bothered me. It's taken me a while
to realise what I dislike about the argument and to put it into words,
though. For those of you who haven't read up on this, it's worth perusing
the article above and others elsewhere to familiarise yourself with it, as
there's a great deal of subtlety in Searle's arguing position.
Firstly, he's established that the computer program as is comfortably passes the Turing Test, so we know it's at least an artifical intelligence by that standard. Then he posits that he can perform the same program by following the same instructions (thus still passing the Turing Test), even though he himself "doesn't understand a word of Chinese". Then he proposes that he can memorise that set of instructions to pass the Turing Test in Chinese in his head, and still doesn't understand Chinese. If he can do that while not understanding Chinese, then the machine passing the Turing Test doesn't "understand" Chinese either.
So. Firstly, let's skip over the obvious problem: that the human trying to perform the computer program will do it millions of times slower. This speed is fairly important to the Turing Test, as we're judging the computer based on its ability to interact with us in real time - overly fast or slow responses can be used to identify the computer. A human that's learnt all the instructions by rote and follows them as a computer would still, I'd argue, be identifiably slow. We're assuming here that the person doesn't understand Chinese, so they have to follow the instructions rather than respond for themselves.
And let's skip over the big problem of what you can talk about in a Turing Test. Any system that can pass that has to be able to carry on a dialogue with quite a bit of stored state, has to be able to answer fairly esoteric questions about their history or their current state that a human has and a computer doesn't (e.g. what did you eat last, what sex are you, etc). I'm skipping that question because it's an even call as to whether this is in or out for current Turing Test practice: if an AI was programmed with an invented personality it might be able to pass this in ways a pure 'artificial intelligence' would not. It's a problem for the Chinese Room, because that too has to hold a detailed state in memory and have a life outside the questioning, and the example Searle gives is of a person simply answering questions and not actually carrying on some external 'life'. ("Can I tell you a secret later?" is the kind of thing that a human will remember to ask about later but the Chinese Room doesn't say anything about).
It's easy to criticise the Chinese Room at this point as being fairly stupid. You're not talking to the person inside the room, you're talking to a person inside the simulation. And the person executing all those instructions, even if they're in a high-level language, would have to be superhumanly ... something in order to merely execute those instructions rather than try to understand them. It's like expecting a person to take the numbers from one to a million in random order and sort them via bubble sort in their head, whilst forbidding them from just saying "one, two, three..." because they can see what the sequence is going to be.
To me the first flaw in Searle's argument is that his person in the room could somehow execute all those instructions without ever trying to understand what they mean. If nothing else, trying to learn Chinese is going to make the person's job considerably easier - she can skip the whole process of decoding meaning and go straight to the 'interact with the meaning' rules. Any attempt by Searle to interfere here and say that, no, you're not allowed to do that really has interfered with any attempt to disprove that the person doesn't understand Chinese - if he makes her too simple to even understand a language, then how does she read the books; if he makes her incapable of learning then how did she learn to do this process in the first place, etc. So the basis on which Searle's judgement that the AI doesn't really "understand" because the person in the room doesn't "understand" is based on the sophistry that you can have such a person in the first place.
But, more than this, the fundamental problem I have is that any process of trying to take statements / questions in a language and give responses to them in the same (or any other) language is bound to deal with the actual meaning and intelligence in the original question or statement. It's fairly counterintuitive to make an AI capable of interacting in a meaningful way in Chinese without understanding what makes a noun and a verb, understanding its rules of tense and plurality, or understanding its rules of grammar and structure and formality. If Searle would have us assume that we've somehow managed to create an AI that can pass the Turing Test without the programmers building these understandings of the actual meaning behind the symbols into the program, then I think he's constructed somewhat of an artificial (if you'll forgive the pun) situation.
To try and put this in context, imagine the instructions for the person in the room have been written in English (rather than in Python, for example). The obvious way to write this Chinese Room program, therefore, is by having big Chinese-English and English-Chinese dictionaries and a book of rules by which the person pretends that there's another person (the AI) answering the questions based on the English meaning of the words. I argue here that any attempt to obfuscate the process and remove the use of the dictionaries is not only basically impossible but would stop the Chinese Room being able to pass the Turing Test. It's impossible to remove the dictionaries because you're going to need some kind of mapping between each Chinese symbol and the English word that the instructions deal with, if for no other reason that Chinese has plenty of homographs - symbols which have two different meanings depending on context or inflection - and you need a dictionary to distinguish between them. No matter how you try to disguise that verb as something else, you'll need to put it in context so that the person can answer questions about it, which is therefore to make it meaningful.
So once you have a person capable of learning a language, in a room where symbols are given meaning in that language, you have a person that understands (at some level) the meaning of the symbols, and therefore understands Chinese.
Even if you introduce the Python at this point, you've only added an extra level of indirection to the equation. A person reading a piece of Python code will eventually learn what the variables mean no matter how obscurely the code is written - if we're already positing a person capable of executing an entire program literally then they are already better than the best maintenance programmer. If you take away this ability to understand what the variables mean, then you also (in my view) take away the ability for the person to learn how to interpret that program in the first place.
Searle's argument, therefore, is based on two fallacies. Firstly, that it's possible to have a human that can successfully execute a computer program without trying to learn the process. Secondly, that the program will not at some point deal with the meaning of the Chinese in a way that a person would make sense of. So on both counts Searle's "Chinese Room" is no argument against a machine intelligence "understanding" in the same way we understand things.
What really irritates me about Searle's argument here - and it does not change anything in my disproof above - is that it's such an arrogant position. "Only a real *human* mind can understand Chinese, because all those computer thingies are really just playing around with symbols! I'm so clever that I can never possibly learn Chinese - oh, wait, what was that?" He's already talking about an entity that can pass the Turing Test - and the first thing I would argue about that test is that people look for understanding in their interlocutors - and then says that "understanding" isn't there because it's an impelementation detail? Give me a break!
And then it all comes down to what "understand" means, and any time you
get into semiotics it means that you've already lost.
posted at: 17:17 | path: /tech/ideas | permanent link to this entry
Look Mum, no bugs!
I recently encountered
a
bug in RhythmBox where, if you rename a directory, it thinks that all
the files in the old directory have disappeared and there's a whole bunch of
new files. You lose all the metadata - and for me that was hours of ratings
as I worked my way through my time-shiftings of the chillout stream of
Digitally Imported. Worse, if RhythmBox was
running during the rename, when you try to play one of those files that has
'gone missing' it will just say "output error"; when you restart it because
(naturally) you think it's borked its codecs or something, it then removes
all those previous entries (giving you no chance to fix the problem if you'd
just renamed the directory in error).
I decided to try to be good, so I found the GNOME bugzilla and tried to search for "directory", or "rhythmbox", or anything. Every time it would spend a lot of time waiting and then just finish with a blank page. Deciding that their Bugzilla was hosed, I went and got a Launchpad account and logged it there. Then, in a fit of "but I might have just got something wrong", I went back to the Bugzilla and tried to drill down instead of typing in a keyword.
Lo and behold, when I looked for bugs relating to "Rhythmbox", it turned up in the search bar as product:rhythmbox. Sure enough, if I typed in product:rhythmbox summary:directory then it came up with bugs that mentioned 'directory' in their summary line. If you don't get one of those keywords right, it just returns the blank screen as a mute way of saying "I don't know how to deal with your search terms".
So it would seem that the GNOME bugzilla has hit that classic problem: developer blindness. The developers all know how to use it, and therefore they don't believe anyone could possibly use it any differently. This extends to asserting that anyone using it wrong is "obviously" not worth listening to, and therefore the blank page serves as a neat way of excluding anyone who doesn't know the 'right' way to log a bug. And then they wonder why they get called iconoclastic, exclusive and annoying...
Sadly, the fix is easy. If you can't find any search terms you recognise,
at least warn the user. Better still, assume that all terms that aren't
tagged appropriately search the summary line. But maybe they're all waiting
for a patch or something...
posted at: 22:44 | path: /tech/web | permanent link to this entry
SELinux for SLUGs
Last Friday I gave two talks at the
Sydney Linux Users Group, at the
new Google offices. It was a pretty full-on day, as I'll explain in
another post, and I was keen to get to the meeting pretty quickly.
Fortunately the light rail in Sydney is pretty good, and finding ones way
from the Star City stop to the offices was pretty easy. I happened to
meet two people who were also going to the meeting, a lady escorting her
young nephew (if I recall correctly) - she came and asked me if I knew
where the linux group meeting was. I talked with them for a bit on the
tram, but I'm sorry to them if I was a little distracted - my thoughts
were on getting to the meeting, getting set up correctly and giving the
talk.
We arrived in the twilight zone between the day, when the lifts allow you to get to any floor without a pass, and the night, when the SLUG Google employees were shuttling people up to the fifth floor. So we climbed the ten flights of stairs - I was in the need of a bit of a stretch. I then picked up my name badge - they were using Anyvite, so they could print out named labels easily for those that had bothered to RSVP on the site so beforehand. I had a brief bit of hesitation when my laptop shut down because it thought it was out of power, a curious interaction between the failing battery and Fedora 11, but all came good. Then it was time to work out how to get connected to the projector.
This was the source of two startling discoveries. Firstly, Fedora 11's screen detection now works pretty much seamlessly - if you plug in a new screen and click the 'Detect Monitors' button, it just finds the new output on the VGA port and sets it up appropriately. Secondly, Open Office 3.0 has a 'presenter' mode that can take advantage of two screens and display your 'now and next' screen on your laptop screen while the projector just displays the current slide in all its streamlined beauty. This was one of those "Wow, It Just Works™" moments where you see how fast the pace of Linux development really is - I was all ready with arcane xrandr voodoo but this just worked perfectly.
Sadly, due to slight cabling problems my laptop was sitting on a server cabinet six meters away, but when I muttered to the nearest person that what I needed right now was a wireless presenter device, the same guy just pulled one from his bag and handed it to me. Whoever you are, you really made my day - thanks! Still, I would be deprived of the handy 'now and next' view and would occasionally have to look over my shoulder to make sure I was talking about the right thing. I'd practiced both talks beforehand, so I was able to move on fairly smoothly. If you're going to do presentations, you have to do this - reading off your slides or looking at the screen to see where you are is really embarrassing.
The two talks went well, though I didn't receive anywhere near the amount of heckling that the CLUG people gave me when I gave the same talks. The questions asked were generally quite insightful, and I had to think hard about my answers. I remembered to restate the question for the microphone, and got to give two T-shirts to people who asked good questions. So overall I was pretty pleased about how it went.
I was talking with Andrew Cowie after the talk, and he gave me some very useful advice for approaching talks in the future. After you've done your initial bit of research working out who you're talking to and what level your should pitch your talk at, you really just have to go for it. I'd been worried that it might be too technical for some and not technical for others - and it was, of course; the point is that that's not really my problem. There always will be that spectrum of knowledge in the people attending a talk at a volunteer organisation, and it's not the presenter's problem to try and cater for everyone. You simply have to do the best you can and reach the most people you can, and not worry about whether you've got everyone interested.
After the talk I got to spend a bit of time with Andrew talking about trades and professions, what makes good meetings and presentations, and many other things that are now lost in the blur that that Friday became. He's an excellent speaker and, like me, wants to see people doing the right thing - being moral and ethical in all their dealings. I also have a small envy of his globetrotting ways, and admire his ability to write Java as fast as think about it in Eclipse, so it was good to get a chance to talk to him for an extended time rather than the usual 'nod in the corridor' meetings we've had in the past.
Overall, a good night. I've put both the
SELinux
for Beginners and
SELinux
for Sysadmins talks up on SlideShare for people to read.
posted at: 23:59 | path: /tech | permanent link to this entry
What we owe Microsoft
Strangely, over the last month or two I've had a couple of people pose the
idea to me that the computer industry should be thankful to Microsoft for
producing Windows. One person stated that they keep us computer support
people in a job; the other said that Microsoft's development of Windows was
such an outstanding achievement that we should allow them to dictate how
we use our computers and how other software companies interface with
Windows. I've tried to debate rationally about these issues, given that
us people who use Free Open Source Software see them as akin to chocolate
on a fishing hook with a shotgun aimed at it - they're bait, and when you
take it you're going to end up hurt, but all the same... it's chocolate...
Let's start by saying that these arguments, to me, make no sense. Microsoft is a convicted criminal, an abusive monopoly that has lied, cheated, bankrupted, threatened, bullied and undermined its way to the top by killing off competition wherever it could. It's done all this not because they want to improve things for the users - although they've said this, that's why they're liars - but simply to maximise profits. It's obvious from everything they do that they see themselves as the 400-kilo alpha male silverback gorilla in the software industry, and that they should be able to do whatever they like with no justification. You can and they do, of course, attach justification to everything but it's merely the covering on a deeply abusive relationship. Saying that we owe them anything is like saying people deserve to be raped - it's literally unthinkable to me.
On the other hand, the people that have espoused this "thank you Microsoft" point of view have valid points, so it always seems like it's worth trying to examine them rationally. For example: yes, Microsoft is not the only company to do naughty things to competitors and even the alleged friend of us FOSS zealots - Google - is at base a company for making money. Yes, we all hold the dream of having an invention that changes the world and being recognised for it. Yes, standards are a good thing and having a unified desktop has helped developers create software in a way that having many competing operating systems would make difficult. Yes, Ford doesn't 'need' to consult its competitors or manufacturers of after-market accessories for their products if they want to change some detail of how their car is designed.
There are two problems with all of these things. Firstly, they're superficial - the comparison breaks down if you follow the analogy through. Ford doesn't need to consult its competitors explicitly because it already does implicitly - Ford knows that it has to offer competitive features or be left behind. Just because Google puts prices on ads and puts them in our faces and does deals with companies for where their listing is going to sit in various searches doesn't justify Microsoft's behaviour. Ideas are not monopolies and should not imply a monopoly on their execution.
But, more fundamentally, the problems with all of these things is that they miss a fundamental point that Free Open Source Software people realised early on: collaboration works much much better than competition. We live in a community of people; we live in societies with shared goals and ideals, ethics and past-times. Many things in life are not zero-sum games, and to portray everything as a win-or-lose, black-or-white scenario is not just incorrect, sometimes it's actually a form of cheating.
This point was driven home to me this afternoon when, just after having come out of an hour-and-a-half debate with one such Microsoft apologist, I read this exchange and it made sense. You simply cannot compare software to the real world, and you simply cannot compare the entire FOSS suite - the work of tens of millions of people all over the world in every profession and every category - with any other physical entity. Trying to stick to the car analogy is pointless because we're using a car, given to us for free, built by a whole range of people, which contains every possible combination of driving performance, style, comfort and efficiency - simultaneously! For free! And I can give you exactly the same car with minimal effort, absolutely legally. There's literally no analogy to it.
My observation here is that the car analogy, and many of the other analogies that get used to describe software and how it works, suits people who still belive in the politics and economics of scarceity. From the perspective of these analogies, Free Open Source Software makes no sense because it doesn't fit in the analogy. Strangely the people espousing these points of view don't see this as a sign that their analogy is broken, they see it as a flaw in the reasoning for Free Open Source Software.
Let's make it clear: Free Open Source Software works on the four principles of freedom espoused by the Free Software Foundation. They allow you to get software, use it, fix it if it breaks and improve it if you can, and share those improvements with other people. The key point unstated there which I think the Microsoft apologists are missing is that all this works on a community of sharing. The four freedoms make sense for you as an individual, but they are absolutely no-brainer logical when you are part of a large community of people that can help eachother. Proprietary software's principles only make sense when you are an individual, without any connection to anyone else using the software but with only the connection to the software vendor. Even before the internet that was untrue; the internet merely made the processes of being in a community - communication, contribution, sharing and co-operation - available to an audience many orders of magnitude larger.
In the heat of the moment, though, I did think of one fundamental flaw in
the car analogy that caused my interlocutor to reconsider his position. It
would be a completely different thing for Ford to change the specifications
of how after-market gadgets fit on their cars if Ford made 80% of the cars
on the market and (most importantly) if the size of the after-market
parts industry was ten to a hundred times the size of Ford's business. In
that light it doesn't look like fair play to change their specs so that they
can sell more brake-pads or steering wheel covers and everyone else has to
go back to the drawing board for six months. But, since that breaks the
analogy, it might not have made sense...
posted at: 17:21 | path: /tech | permanent link to this entry
Canberra Linux Users Group monthly meeting for May 2009
The first of many CLUG Linux Learners Meetings!
The meeting was, in general and in my opinion, a success. Lana Brindley gave the first talk, entitled "10 Reasons Why You Do Not Want To Install Linux. Ever.", which was (no surprises) really a "10 old myths about not using Linux and why you should ignore them" talk. It was clever, well presented and covered all the things Linux users get tired of explaining. Several times Lana would pose a myth about Linux and people would automatically call out objections or corrections - which I take to be a good sign that her talk dispelled the myths that us enthusiasts want cleared away.
My talk, unfortunately, I feel was doomed from the start. It was "Paul's Ten Tips About Bash", and the content was definitely useful to some people - and I think it says a lot about Linux users that even the most learned people in the room still learnt a few tricks and mentioned some that I didn't know. However, it wasn't a talk for everybody, and importantly it contrasted with Lana's number one point: that Linux is perfectly possible to use without ever coming near the command line. My disappointment is that I didn't think of this earlier - I got carried away by my own geekiness. It should have been "Paul's ten tips on avoiding the command line", which would have been something that many more people learned from. Heck, I could have learnt a lot putting that talk together.
I'll do it at the next Linux Learners meeting, which will be in August (I
think we'll set a schedule of doing them every three months and see how
that goes).
posted at: 18:48 | path: /tech/clug | permanent link to this entry
All posts licensed under the CC-BY-NC license. Author Paul Wayper.
You can also read this blog as a syndicated RSS feed.