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
Canberra Linux Users Group Install Fest for May 2009
The Canberra Linux Users Group invites anyone in the Canberra region to
come along and learn more about Linux. We help you install Linux on
your computer, we teach you about how it works and the way to get around
a modern Linux desktop, and we help you fix the problems that have been
nagging you with your Linux system in the past. We can even demonstrate
what it looks like and why it's not as dangerous as it sounds if you're
not ready to install it just yet.
There's more information on my website, so
please feel free to email
me with your questions. If you want to come along and are interested
in having a sausage for lunch, please also drop me an email by Friday!
posted at: 22:45 | path: /tech/clug | permanent link to this entry
Installing and debugging Minimyth for fun and profit
In the ongoing quest to save power, I am moving my MythTV backend
onto my low-power home web server, and building a new low-power
frontend based on a fanless Via EPIA M board and the
Minimyth custom linux distro.
This is a cut-down system designed to boot off TFTP or NFS, but
can be also adapted to boot off a CompactFlash card, which is what
I'm doing (my firewall has a DHCP server but the web interface
doesn't allow me to set a TFTP boot option, and I can't be bothered
to work out PXE boot just this moment).
It's a very neat little package, with everything you could want compiled in, but this also means that setting it up is a rather complicated process. First you write a specialised config file, which has to go in a specific place. Then you unpack the various bits and pieces onto the CF card and run syslinux on it to make it bootable. Then you stick it in the machine and boot it, and if anything goes wrong you telnet (yes, telnet) into it and peruse its /var/log/messages to find out what went wrong. Then you take the CF card out, fiddle with the contents a bit on your own computer, plug it back in and see if that helped.
This is made somewhat frustrating by the lack of examples and somewhat minimalistic approach to explanation that the minimyth documentation takes. It also leans more toward the network boot process (to have no flash drive in the machine at all, and to allow you to run a writable root partition) and covers the flash install side somewhat minimally. The site also doesn't provide a sample / working / minimal minimyth.conf file, so you have to google around and womp up one on your own. Add to that the minimyth machine's habit of only bringing up its telnet connection (yes, telnet) about two minutes after you've booted it,
I started this nearly a week ago, and various delays and frustrations
have prevented me from documenting all the steps. But I'll try to get
more of the process documented soon.
posted at: 22:40 | path: /tech | permanent link to this entry
Canberra Linux Users Group monthly meeting for May 2009
The first of many CLUG Linux Learners Meetings!
This meeting is a 'fixfest' and learner session for people new to Linux or still finding their way around. (That's most of us!) We'll be having short talks about a variety of subjects but the majority of the night will be given over to people helping other people fixing problems and learning their way around Linux.
Lana Brindley will be starting the night with a talk entitled "10 Reasons Why You Do Not Want To Install Linux. Ever." and with a provocative title like that you can tell it's going to be interesting! Paul will then give a short talk on tips he's learnt in using Bash, the current standard command line shell in Linux.
You're welcome to bring your computer along but please email me
(paulway@mabula.net)
beforehand so I can get an idea of the numbers of machines involved.
posted at: 22:39 | path: /tech/clug | permanent link to this entry
CLUG Programmers SIG for May 2009
Last Thursday night we had Paul Fenwick from Perl Training Australia giving
two talks - "The Art of Klingon Programming" and "Awesome Things You've
Missed In Perl". I'd see the first one before at OSDC 2008, but Paul is
still constantly improving this talk so it's still worth seeing again. In
particular it's the examples that often have me saying "of course!" and
"how clever", as Paul introduces some subtle new feature or variation on
what he's said before that gives a new perspective on autodie's
usefulness.
"Awesome Things You've Missed In Perl" is a good way of updating seasoned Perl coders to the new things you can do with recent versions of Perl. It's more about the modules that have come out in recent years that make writing Perl much easier, such as Moose, autobox, and autodie (of course). But there's still much that Paul mentions that exists in Perl 5.10 that makes a coder's life easier; given/when, the smart match operator and named captures just for starters. For us people that still have a Camel book second edition on their desks (somewhat guiltily), it's an excellent refresher and reminder to get with the times. It also makes the transition to Perl 6 much easier.
The meeting was very well attended - 18 people - including three from the class that Paul was teaching. For me it was a wonderful "small world" moment as a friend of mine from Melbourne happened to be at the course - of course, my embarrassingly useless people memory caused me to have to ask her name. But it really was quite wonderful to see Louise again, albeit somewhat briefly. The main programmer for the water resources project that Paul was tutoring was interested to learn about the Canberra Perl Mongers group and will hopefully join and come along as a regular participant.
So, thank you Paul Fenwick for making this a really great night!
posted at: 11:37 | 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.