| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
|---|---|---|---|---|---|---|
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
This section:
Tales from the conference circuit
The syndication links at top left will give you a feed for the blog as a whole.
If you'd like a feed specific to this sub-category, see bottom of page.
blogs > andrew > conferences
Fri, 07 Dec 2007
Talking about getting involved
I’m giving a talk at foss.in tomorrow, Saturday, at 10am:
I realize that this is only of interest to people in Bangalore this week and reading planet.foss.in, but here’s my abstract:
The essence of open source is not USING free software, but CREATING it. The purpose of this talk is to teach you how to contribute to open source projects.
Admittedly, getting involved isn’t as easy as it could be, but that’s often because you haven’t had an opportunity to learn how to go about participating in a project’s development.
This talk is aimed at people who probably already know something about Linux, already know how to program, and already believe how important free software is… but haven’t yet made the jump to being contributors themselves. And that’s LOTS of people. So, it’s time to become and open source hacker.
It’s easy to talk about “interacting with the community” and “filing bugs” and “submitting a patch”, but until you know how to do this, it can all be a bit daunting. So we are going to be do all these things, TOGETHER, on stage, LIVE. We’re going to file real bugs about real problems in real open source projects, and then we’re going to fix ‘em, right there on the screens in front of you.
How do you contribute? You have to check out source code, learn how to build open source software, run it, test it, and debug it… but it doesn’t stop there! Then comes creating and sending patches, receiving feedback from the upstream project, dealing with rejection, but finally when you’re successful exalting your success.
For the beginners in the audience we’ll be demonstrating what you do to submit to upstream, but we’re also going to show what the upstream people do when you make that contribution. So we’ll see the whole open source process, beginning to end.
Take joy in your work, do your work in the open, and open it to the world. Do that, and you ARE an open source contributor.
Actually, it’s not just me — my good friend Shreyas Srinivasan and I will be doing the demos jointly. So the best part will be watching the two of us making fools of ourselves on stage.
I hope you can make it!
AfC
P.S. 10 am means Ten O’Clock in the morning. People who are late don’t get any free chocolate chip cookies.
Tue, 04 Dec 2007
GNOME Mascot?
It’s the GNOME Project Day at foss.in!
Máirín Duffy talking about getting involved in art, marketing and branding in GNOME … question from the audience: we have the GNOME foot logo, but why doesn’t GNOME have a mascot?
I asked quickly in #gnome-hackers and James Henstridge suggested that the mascot was:
“whatever made the footprint”
It’s a giant invisible beast! :)
AfC
Thu, 22 Nov 2007
Do you have what it takes to be a volunteer at a conference?
Speaking of tireless volunteers:
The amazing thing about Open Source is that there are so many ways to be involved. Unlike any other area of human endeavour, you are not limited by race, gender, or the requirements of joining a profession. The only barrier to entry is that you participate.
Like most things, Open Source is about people. And a great way to meet other people is by getting involved at conferences. Technical conferences always need people to help out, and so it’s a great way to be able to spend time with the local community and with the speakers who have come from near and far. And just think of all the free T-Shirts you’ll collect. Geek nirvana, really.
Two really amazing conferences are coming up. If you’re anywhere in Asia, you should be making plans to get down to Bangalore for India’s greatest Linux & Free Software event, foss.in. And whether you’re in Australia, New Zealand, or France you should be booking your flights to get to Melbourne for the eighth linux.conf.au. Both conferences are the wonderful experiences they are in no small part because of the energy and enthusiasm of the volunteers who help with everything from A/V to picking up speakers at the airport to helping get people registered to making sure a conference network is up and running [hackers get grumpy when they can’t get their email :)]. If you’ve got a little time, if you’re looking for a way to get involved, then consider signing up as a volunteer to help out.
The Call for Volunteers for foss.in/2007 is out, and time is running out to sign up, so act fast!
I promised Atul that I wouldn’t subvert his volunteers this year. Last time around, the person who was supposed to to be monitoring the time and telling me to wind up was so enthralled by what I was saying (and now he’s a major contributor to the project that I was talking about; go figure) that they completely forgot to tell me to sit down. See? Me going overtime isn’t always my fault. Honest!
AfC
Tue, 07 Aug 2007
The conference with attitude is back
foss.in 2007 announced
It’s always difficult for a community based conference with a multitude of demands all pulling in different directions. The temptation is always to try and please everyone. There always seems to be people who want the focus to be on converting people to Linux (inevitably because they’re trying to sell something, and figure the conference is there to create new customers for them). These groups seem to object if the conference isn’t all about new users and explaining why Open Source is so great.
But here we are in 2007. There is no need to waste time preaching to the choir; the audience of such a conference already knows that Software Freedom is so important. And on the other hand, there very much is a need to grow the worldwide base of people contributing to Open Source. That doesn’t mean that the cause is won, but we need less people talking, and more people doing.
Thus it is admirable that in the case of India’s premier Linux, Open Source, and Free Software conference, foss.in, this year the team have chosen to refine and refocus their event to focus on encouraging contribution and facilitating development.
I think this is terrific.
Unsurprisingly, there was a bit of resistance from the usual suspects. But in reply to one such message, Atul Chitnis (my favourite Open Source rock star and the lead matador at foss.in) replied with this:
We have to pick our battles, or we lose the war. The focus of this conference is development and contribution, not newbie orientation. And even if were to allow this, the rest of the conference would be a complete loss to them.
If someone comes to FOSS.IN, it is expected that s/he knows what s/he is coming for. There are four months to the event — plenty of time to attend LUG meets, surf the net, and learn the basics.
“Do your homework”.
The guy is a guru.
Longer talks, no tracks, and project days
Considerably at odds with the general trends in most conferences, they have chosen this year to considerably lengthen the talk slots, recognizing full well that there will be less speakers but allowing those presentations to evolve into large scale workshops — the goal being helping people get bootstrapped not with using Free Software, but creating it.
This will all be balanced by “project days”, modelled somewhat on the mini-confs that linux.conf.au originated. The idea is to give individual communities an organized forum to concentrate on the doing. I’ll be at the GNOME one!
Conference Promotion
And once again, this team absolutely leads the pack. So much attitude:
Awesome!
foss.in/2007, Bangalore. If you’re going to be in India this coming December, you need to be there.
AfC
Fri, 13 Apr 2007
Learning Linux?
I was amazed and indeed almost disappointed at the number of people that have approached me this week and asked “how to get started in Linux?”. I’m embarrassed to admit that I didn’t actually have a ready answer. Conference wise I tend to hang around with people who long ago found their way [to Unix and from there] to Linux, and so had not given a lot of thought to answering the baseline question of where to start!
Luckily I had another keynote to give on the next day of the conference, so I had time to get my shit together. I prempted the beginning of my second presentation to try and address the question. I told them this:
- Read a book about Linux
- Install Linux on your computer
- Talk to people, and ask for help
- Not necessarily in that order
Install Linux
I drew up a graphic to give an overview of the lay of the land distro-wise, throwing in a few other flavours of Unix as well:
[The trend line shown there is something that occurred to me a while ago. It seems for a long time there was a clear inverse relationship between how easy something is to install versus how easy it is to maintain and upgrade over time. Ubuntu, of course, breaks the mould by making Debian easy to install, but it still isn’t as easy to maintain (from the standpoint of a power user) as a Gentoo system is. This graphic actually worked quite well as a backdrop to discussing the emergence of distros over time and the evolution of network aware dependency based packaging systems]
Read a book about it
And suggested a book for them to look up. The best one I could think of was Matthias Kalle Dalheimer and Matt Welsh’s Running Linux, now 5th edition, published by O’Reilly [one thing that’s great about Bangalore is that there are like seventeen million bookstores all full to the brim with O’Reilly books].
To the blogoverse I ask: what book would you recommend to someone to a young university student who has caught the fire of enthusiasm and wants to get started in open source?
AfC
Sat, 07 Apr 2007
Convincing students
I have a somewhat unusual challenge ahead of me next week: I have to convince a conference full of students that they should participate in and pursue open source. This will strike many readers as somewhat strange since an enormous number of the people contributing to the global free software phenomenon today are students. But from my many trips to India over the last few years I have come to understand that the university system there does not promote the sort of individual initiative that involvement in open source requires — but there are people trying to do something about it.
One such is the Linux User Group at the MS Ramaiah Institute of Technology in Bangalore, India. They run an annual conference about open source, called “Mukthi”. This is a fascinating group of people. For one thing, they run their own in-house Linux conference! For another, they manage to convince the entire computing faculty to cancel classes that week so that students can attend the conference. This is exceedingly cool.
I’ve been invited to open this year’s conference. This will be great fun; there are few things I like more than standing in front of a crowd encouraging them to go wild about open source.
But that in and of itself is not exactly a topic, of course. One of the things I try to do with speaking engagements is to get a sense from the organization of what sort of impression they want me to leave. “Is there a message you want conveyed to the audience? A tone that you want me to set for the rest of the event?” That sort of thing. (I will, of course, do whatever it is I want anyway, but it’s always nice to at least try to make your hosts happy)
This one will not be easy, though. When I talked back and forth with the organizers about what they wanted to hear, they said that what it really boiled down to was that they were all exasperated about one thing: “We’ve always got people telling is how great open source is. But what good is it, really?” That made us laugh, so, I turned that around and made trying to answer that the title of my talk.
An audience of really talented young computer scientists and engineers, all about to enter the workforce: tough crowd. The conventional proprietary path is well trodden and a safe bet in most local IT industries. But it is a global marketplace and the traditional route is about getting work out of you, not about empowering you to succeed. The key to their professional future will be their ability to succeed as individuals in the global economy. The magic of the open continuum is that it changes the game: the only barrier to entry is contribution, and for those willing to risk it, there is the chance to really make a difference, and in so doing not only do they lift themselves up, but too their companies, their communities and their nation.
AfC
Fri, 02 Feb 2007
Pair Sliding
Davyd Madeley and I gave a tutorial at linux.conf.au this year about the basics of writing GTK and GNOME applications. That’s hardly an original topic, but we set out to do it working in three different programming languages simultaneously, and that made it really rad, of course!
(Click through if you care to see the abstract for the talk)
So the obvious thesis for the tutorial was that it really doesn’t matter that much what language you choose to writing a GTK program in; in other words, pick something that you’re comfortable in and concentrate on getting your app built, but on the other hand once you’ve learned GTK, that knowledge will be pretty portable to other languages should you care to stretch a little and switch.
Of course, we had to figure out how to convey that message. The obvious thing would be to just do the same program three times, once in each language, but we figured that would be pretty boring and repetitive. So instead we decided to do one application, but start it in C, continue it in Java, and then complete it in Python. Whoa!
One thing that was cool (and really, the reason that I’m blogging), was how Davyd and I ended up preparing the slides. We’d been batting around these ideas for a while, but knew we’d need a day together to bang out the slides. So Davyd flew in to Sydney a bit early and we spent an afternoon doing what was, to all intents and purposes, pair programming. Only it was writing slides and doing images. So it was like, pair sliding. I’m a big believer in agile programming practices, but I’m always amazed when I see it work in a not-coding context. It was an awesome experience: we were doing images in Inkscape, one person driving, the other catching things and offering ideas and advice. The flow was unreal. For either one of us to do that one-at-a-time remotely would have taken forever and not come anywhere close to the same quality. Same with the presentation slides. The deck slid back and forth a bunch of times as someone would say, “nah, more like this” while the other person said “ok, sure, but try that”. Amazing.
Anyway, as it turned out, our tutorial ended up being less about language and a lot more about tying the essence of “graphical user interface programming the GTK way” together. We covered the basic concepts in C, and along the way fairly clearly pointed out that that much boiler plate coding by hand in C is kinda a pain in the ass because we were writing code, live, right there in front of people. Conventional wisdom about giving presentations would have it that that’s a pretty risqué thing to do, but it was a lot of fun and, I think, helped keep the pace of new material sane. With the foundation ideas covered, showing how they were implemented in (say) Java was not a big conceptual jump. Once we’d made the switch, we returned to discussing more GTK-isms, further driving home the point that language choice really isn’t the big question. Along the way I got to do some of that magic “java-gnome code madly appearing out of thin air in Eclipse” thing, which is always pretty impressive to see.
People seemed pretty happy with our presentation, and we’ve already have a few requests to give the tutorial again at other events, which definitely makes you feel good about yourself. Oh, for those who were there, slides are now up, as is the source code from the demo.
And to my partner-in-crime on this one: Davyd, thanks for your hard work!
AfC
Sun, 26 Nov 2006
First live demonstration of the new java-gnome bindings
I’m giving my second talk at foss.in this afternoon, Sunday, at 14:00 local. This time it’s a technical one:
(Click through if you care to see the abstract for the talk)
I’ve been working like mad for about 6 months to completely re-engineer the design of the java-gnome language bindings to GTK and GNOME. Memory management, proxying GObjects into Java, figuring out how to handle more generic GValues in property setting. But most importantly, how to create an architecture where we could generate the bulk of the bindings off of .defs metadata so we can share that with the pyGTK guys and make our bindings a comprehensive representation of GTK and GNOME without being the totally borked, hand written, leaky, and completely unmaintainable mess that the present java-gnome 2.x bindings are.
Along the way I’ve been validating the design with code not just code mock ups but a fully working prototype. The most challenging technical piece of late has been designing an new signal handling API. Not only was the API design tough, but the plumbing to make it work is completely voodoo — the GSignal marshaling APIs are not trivial. Couldn’t have got anywhere without the old 2.x code to use for inspiration, but man oh man it’s been a hard slog.
On Wednesday at 01:48, I finished the last piece of engineering to enable signal connection to work! And so, today, as I’m talking about architecture and working across boundaries between projects, I’m going to be unveiling the prototype and giving the new java-gnome 4.0 code its first live demonstration.
This is only the beginning. There’s a lot of work yet to come, and I am hopeful that we’ll get the funding we need to make it a reality. Java Libre!
I was talking about all this yesterday over coffee with one of my good friends Sirtaj Singh Kang, who happens to be one of the original KDE developers. After the whole discussion he said “did you know I wrote the old KDE Java bindings? They’re really rickety, and I want to redo them. Do you think I could use this too?”
Wow! Wouldn’t that be something?
Don’t worry. Cats and dogs are not sleeping together: I gather there is already some new Qt Java code floating around, so presumably whoever did that will be extending it to KDE, but no matter. The architecture I’ve developed seems really promising for the task of proxying any underlying native library which more or less follows OO idioms. So as I’m working, I’m keeping in mind that more than just GLib based systems might someday want to use it. Obviously, though, our new code is going to be optimized for the GNOME + GTK case, which is as it should be.
AfC
Thu, 23 Nov 2006
Keynote Abstract
I’m giving a talk at foss.in tomorrow, Friday, at 6pm:
I realize that this is only of interest to people in Bangalore this week and reading planet.foss.in, but here’s my abstract:
There is a fundamental structural problem in the open source movement. Within a given project, things generally find a way to get done, but when a problem lies between two projects (be they peers, one dependent on the other, whatever) then things often remain unresolved…. This is actually the cutting edge area in the free software movement at the moment - trying to find a common ground for not just projects but constellations of projects and above them distros to collaborate.
Whilst contribution is the barrier to entry (ie, my talk last year), there is a bigger issue: the overall continued viability and success of the open source movement. And that will take us finding ways to cross the bridges between projects.
The question has a number of aspects. Although any problem involving humans interacting is ultimately a social one, we are nevertheless face a situation where our tools are holding us back. But don’t worry: in the grand tradition of free software gurus, I shall not let so-called “reality” get in my way as I describe the future Utopia that awaits us.
Why there are there 80,000 unfinished one man show projects on SourceForge? The “not-invented-here” syndrome means that so many of us keep re-inventing the wheel; and that’s so often because we think its easier for us to start work on something new than to contribute to an existing project. We all know there are lots of reasons for this, but a big part of the truth is that contributing is hard. That’s what we have to change.
So this talk will look at what getting in the way of projects co-operating with each other, and take a wild romp through the amazing and vibrant activity taking place in the area of tools to support us. The present state of affairs is not encouraging: there is a proliferation of incompatible project hosting and bug tracking systems. Inefficient communications mediums that help us to rant at each other but don’t help us to reach decisions. The contentious struggle to develop a next generation source revision control system rages on. Even the hallowed release cycle of GNOME is up for examination: is it developing quality software or preventing people from easily contributing?
The times, they are a changing, however. Of particular interest is the version control debate. Working closely with the proponents of a number of the latest entries in distributed version control land, I’m going to talk about why this has been such a ripe area of activity, but focus on something that one of the
bzrdevelopers just noted to me: “We spend so much time chasing the Distributed Version Control System grail because that’s what everyone thinks we should be doing - but it’s not clear whether that’s actually the problem that needs addressing: when someone approaches me and says ‘but I just want to share my branch’ are we really helping them?”Source code is just part of the equation; another huge factor is getting that code to build. The solution here has long been
automake+configure+Make+libtoolbut the they way they approach the problem has long been primitive. There has been some dramatically new developments lately in this area focused on helping code from different projects work together. It’s going to take all of us to get it to succeed, but if we can cross the divide, then we will have made a major step towards working together.Last year I said the barrier to entry is contribution. This year we are going to talk about the criterion for success: ensuring that the barrier to other people contributing to your project is low. If we can remove the impediments to collaboration then together we can really make free and open source software the road that into the future. Apotheosis rising.
I hope you can make it!
AfC
Tue, 24 Oct 2006
Conference Preparation
Speaker confidence
Probably the most important requirement to be an effective speaker is confidence. Confidence in yourself, confidence in your mastery of your subject, and confidence that you know that what you are saying (together with your slides, assuming you’re using some) are combining together sufficiently to convey the message you are trying to deliver.
One of the things that causes doubt while you are speaking is wondering if you are getting through to your audience. Often when you are trying to explain the intricate detailed technical aspects of something, you can’t help but wonder in the back of your mind whether you have explained enough context for your listeners to understand.
The catch, of course, is that you can’t get around this by explaining every last bit of background. There’s no time for that, and you’d lose the interest of your audience for sure. So you summarize, try to paint a picture, and hope that you have brought people along sufficiently for your main point to drive home.
I’ve started to wonder if we might be able to improve on this a bit.
Organizers’ concerns
Meanwhile, one of the (many) issues that the people running a conference go through in selecting presentations for the programme of their event is pondering the question of whether or not a proposed topic will be of interest to the audience.
Certainly once a speaker and their presentation are accepted, then the concern of the organizers is to ensure (ie, hope for the best) that each presentation will be not only of the highest quality, but of interest and benefit to those who attend. After all, there’s nothing worse than walking into a room and having no idea at all what the person speaking is talking about.
Speakers’ confidence and organizers’ confidence. It occurs to me that these issues are not unrelated.
Preparation?
At technical conferences, our audiences are our peers: highly intelligent, respected contributors in their own right. They might not be an expert in your particular thing (though you never know) — but they wouldn’t be listening to you if they weren’t interested.
So the question is, what can we do to help people who want to be better prepared so they get the most out of a presentation?
I used the term “homework” in as the zeroth step in a series of emails I recently wrote, but it was pointed out to me that for the conference context, homework has far too many connotations of “compulsory” to describe what I am trying to get at for improving one’s experience at a conference. So perhaps “preparation”?
In what form?
So here’s the question: what form should such an endeavour take?
Some have suggested to me that blog posts in advance of an event can seed the waters. That’s true, but even when an event has it’s own planet-type aggregator, there’s not necessarily a very high likelihood that the attendees to your talk will read your post. And in any case, blog posts aren’t generally of the detail and breadth that you probably want to be conveying as background material.
Another idea is handouts at the event. I’ve seen quite a number of business consultants do this, and it can be quite effective when it takes the form of speaking notes. There’s always the minor detail that if you give handouts that people will spend all their time head down reading them and not paying attention to what you’re saying. And there’s the logistical overhead of producing the damn things in the first place.
Traditional conferences (academic symposia, and the more established technical conferences like USENIX + SAGE’s renowned Large Installation System Administration conference and related Australian conferences) have long required full papers (perhaps with peer review, perhaps not) which are published in the conference “proceedings” and most of the time give to attendees when they show up, ie before they listen to the presentation. If they’re really diligent, they can read up ahead of time to figure out what the authors are on about and in so doing get more out of your presentation and ask you intelligent questions.
That’s all well and good for conferences who require written paper and which publish them in official proceedings, but not everyone does that these days, and more to the point, writing a formal paper represents an enormous level of effort. Certainly for more casual gatherings (ie, most open source conferences) it is prohibitive, and even for more featured events it still represents a barrier to participation. I don’t know about you, but in most cases, I’d rather be coding.
So what else? Many conferences have custom software they use to run their web site and and often you can browse by schedule, topic or speaker. That might be a good place to collect and publish background material, though it is ever a challenge to come up with a good web user interface for this sort of thing. If the conference had a Wiki (many do) that could work too, assuming it was organized sufficiently ahead of time — one page per presentation or presenter, perhaps. In either case, the catch is getting audience eyeballs to the material before the presentation.
What do you think?
Hm. Any other ideas?
Bear in mind that regardless of any ideas here, a presentation still has to be as vibrant, informative and interesting as possible for all attendees and that, in the end, no assumption of preparation can be made.
Nevertheless, I definitely plan to help people who want to get more out of the presentations I make in the future. It will help them, but even more importantly, it will improve my confidence, and hopefully that will improve everyone’s experience.
AfC
Tue, 27 Jun 2006
Beach party
Normally parties full of geeks are boring. One of the things that sets LCA (the Australian Linux conference) and the conference I’m at this week, GUADEC (the GNOME conference, this year being held in Vilanova i la Geltrú, near Barcelona, Spain), apart is that the evening social events tend to be outstanding.
Last night, one of the sponsors, a streaming media company called Fluendo, held a party. They said it was “on the beach” which I imagined was figurative and that it would just be at one of the restaurants or bars along the main waterfront road here. Since I only just got in, I was jet lagged out of my mind, wired on caffeine and ice cream, and enormously distraught over what happened to Australia in the match against Italy. I wasn’t exactly expecting much.
No, it was at a bar on the beach. Excellent music pumping, good conversation (when you could actually figure out what people were saying over the aforementioned excellent and loud techno) and a good opportunity to meet people. Ok, the fact that it was an open bar might have helped too.
At one point, some drunken bastard thought it would be a good idea to start swapping people’s conference name badges around. As you’d expect, this rapidly caught on and then promptly got out of hand, which led to the rather humorous result that that at 3 in the morning there were all these very inebriated people hopelessly wandering around like lost puppies looking for their name card. (To be honest, I actually found this mildly annoying: a big part of the reason we come together at these conferences is to get to know the people that otherwise we only have seen online. Changing name tags does NOT help!)
Then, after a whole whopping 3 hours sleep, I discover the morning sun streaming through the window right into my eyes. Time to get up, apparently.
AfC
Tue, 24 Jan 2006
GNOME.conf.au
Blogging live from the GNOME mini-conf at Linux.Conf.Au 2006, Dunedin, New Zealand!
Good start to the day. Jeff Waugh gave the 10x10 talk he gave at GUADEC last year — but also incorporated a lot of the feedback and views he’s heard since then which made it interesting even a second time ‘round. [Not to mention it being new to most of the Aussies and Kiwis in the crowd]. It was quite refreshing to hear Jeff being candid as opposed to blindly enthusiastic (because that’s the current party line or whatever).
A good conversation about release cycles got going. One thing that puzzled me at GUADEC and that continues to puzzle me is the recognition (I’m paraphrasing here) that “while the time-based release cycle has led to quick availability of quality software, it’s meant that visionary innovations (an agenda) have perhaps been left behind” … but after discussing it for a while, the conclusion was again “we will therefore stick with the 6 month release cycle”. Huh? If you don’t change the system, why would you expect a different outcome?
The sys-admins in the crowd were fairly unified in expressing their frustration at releases being too frequent, with the result that by the time they got a chance to test a released version set, qualify it for their environment, work out a migration path, and deploy it on their site, GNOME would have moved on at least one release and the hackers themselves would by then be working on the release after that, meaning that bug fixes and polishing for the version our poor sys admin was trying to roll out on their site run would never really happen. (ie when was the last time any of us did a bug fix to GNOME 2.10 branch code, let alone 2.12?).
Lord knows I spend enough time in my professional life going around the world warning people to beware the seductive dangers of incremental change, so it’s difficult for me to be objective about this issue. It strikes me, though, that the core GNOME hackers who gained so much from switching to the 6 month cycle in the first place are having a hard time figuring out how to recapture the initiative without losing their productivity. My impression is that the religious adherence to the 6 month time-based release cycle is a structural issue which is holding GNOME back from making the visionary leaps it wants to make.
Later in the morning Glynn Foster did a live demo of dtrace on OpenSolaris. I’ve been hearing people go on about .d for ages, so it was great to see it in action [when we were chatting over beers in Bangalore at FOSS.IN, Rasmus mentioned that he maintains a Solaris box just so he can use dtrace to profile PHP. Great endorsement!]
Someone I hadn’t met before came up to me at lunchtime and said “hey, I use your bindings”. Cool! And while I quickly set him straight that the java-gnome project is certainly not mine, it’s great to listen to people describe their experiences using software I contribute to.
AfC
Thu, 01 Dec 2005
Always something to learn
FOSS.IN day 3
Another awesome day here in Bangalore at India’s premier free and open source conference, FOSS.IN/2005.
Gave my “Inside | Outside” keynote this morning. The audience cheered when I slammed the GNU/ travesty. (Yes, cheered. I love this place). Best feedback of all was when Sulamita Garcia from Brazil said “you said what we’ve been trying to say for years, but couldn’t find the words”. I’ve got nothing on her, though — yesterday she gave her first ever presentation in English.
Slides for both my day 1 talk about configuring Java to run on Linux, and for today’s Inside | Outside are now on my website. See operationaldynamics.com/talks
This afternoon went to two really interesting talks in the ballroom. One was a really sensible talk by Sriram Bala entitled “CTO tales: Evangelizing Open Source to the Fortune 500”, full of lessons about how to present FOSS effectively to a business audience. That was followed by Danese Cooper doing lightning talks as a way of teaching people “How to give a FOSS presentation”. Danese is a fantastic speaker and it’s a privilege to have someone of her calibre offering suggestions on how to improve one’s public speaking.
Always something to learn.
Check out planet.foss.in for photos and blog entries from speakers, organizers and participants.
AfC
Mon, 29 Aug 2005
Camping and Hacking
Spent last weekend out in the woods at Peter Miller’s awesome Central Coast Code Con. This is the second year we’ve done it. This time we went to the Basin Camp Ground in the Olney State Forest in the Wattagan Mountains. A beautiful setting.
I actually think the term “CodeCon”, despite is venerable lineage, is a bit unhelpful in terms of explaining to people where you were or what you were doing. After all, what the heck does it mean? I thought a bit about how we could improve it:
Hacking in the Forest — That’s pretty good, and pretty much what we did for the weekend. But last year we went to the beach. Hm.
Camping and Hacking — Not bad, if somewhat less catchy. But last year we were hardly roughing it - we went to a campground up the Central Coast of NSW that had showers and electrical outlets. Oh well. I guess being in a trailer campground is some people’s idea of roughing it. (Electricity, of course, is somewhat important to recharge the laptops and to run the projector at night. This year Peter arranged for a small generator which was astonishingly quiet).
Hackfest by the Campfire — Ok, so long as people don’t get the notion that they are supposed to throw their laptops onto the fire or something…
One of the features of a CodeCon is that people do short informal presentations of something interesting they’re working on. We had a good crowd. Highlights: Erik de Castro Lopo talked about OCaml; Robert Collins showed us a new unit test suite for python he had madly hacked away on over the weekend. Silvia Pfeiffer talked about the future of Annodex which led to an awesome discussion about growing open source communities. Peter Miller showed us the tiny version control system he wrote to be the back end of a wiki he wrote called “quickie” (awesome name, dude). I described the configure-for-Java thing I’ve been working on. Conrad Parker gave us a demo of melting his shoes in the fire.
Katrina came along [and put up with a bunch of geeks!]. On Saturday we went for a hike up a picturesque (if somewhat hilly) section of the Great North Walk which was great exercise.
AfC
Category Specific Feeds.
Use these links for an RSS or ATOM feed limited to this category and its descendants.
Technorati Profile
