[AsiaBSDCon 2010]: March 11-14, 2010, Tokyo, Japan - Summary
from the more-sushi-anyone dept.
[AsiaBSDCon 2010]: March 11-14, 2010, Tokyo, Japan - Summary
As in years past, the AsiaBSDCon conference was amazing. The quality of papers, presentations and speakers just gets better every year. I want to give some colour to the videos and slides that have already been posted by J.C. Roberts. The presentations and papers on-line are nice but they could use some commentary.
Read on to find out what was so special about this year's conference:
The first OpenBSD speaker to talk was Alexandre. I had heard and read of all the fabulous things that can be done with the audio(4) framework in OpenBSD but there is nothing like a demonstration to open your eyes and ears. That's exactly what happened as I was listening to Alexandre speak. It is impressive what can be done with music. Sometimes it takes a simple demo to see the light. Afterwards, I asked Alexandre where I can buy the music that he was using for his demo. He then told me it was his own. Not only that but it is his wife that is doing the vocals. In fact, everything that he played and demonstrated was done using only OpenBSD.
Claudio was next to follow Alexandre. I thought that Claudio was a routing daemon man who just loves to take pictures. Just to show you the diversity of some of the OpenBSD developers, Claudio pulls iSCSI out of his Swiss hat after a few hundred lines of code. He then goes on to finish it and get this, he readily admits that he really doesn't know much about how SCSI works! We use quite a lot of iSCSI internally so I was happy to see someone working on this, I just never thought that it would be Claudio. It takes someone who's smart, capable and willing to do the work. Claudio has done his fair share. We need more people like Claudio who can step up to the plate and get things done.
I was looking forward to Simon's presentation as I have been on the IPv6 bandwagon for a few years now. However, my jaw dropped when Simon listed some of the limitations, namely that this transition mechanism depends on DNS! What was the IETF thinking? I don't use MSN or Skype but these are the kinds of applications that will break if you rely on this transition mechanism. I just shook my head wondering why the IETF spends its energy on RFC's that are fundamentally broken hoping that application developers will change their apps to adapt.
Afterwards, over a few beers, a few of us were scratching our heads about this. A few days later, I then asked Ryan about it and he did say that there are some some practical applications that just can't be handled with relayd(8) or as efficiently because of the userland <--> kernel interaction. At any rate, IPv6 is a quagmire of conflicts. It's a bunch of RFCs written before implementations. It's their biggest mistake; they didn't prove that it would work first. Now we are stuck with broken or crippled transition mechanisms that are in some way an attempt to overcome bad IPv6 design decisions made from the very beginning.
This was perhaps the most technical talk of the conference. Takuya came out of nowhere late last year to work on SGI MIPS architecture and helped to bring SMP support for it to boot, literally. A group of OpenBSD developers went out to drink later that night and it was there that I realized that Takuya is a Japanese Internet rockstar with his own twitter following. He's not your typical Japanese person. In fact, you would never guess that he was a kernel hacker as he comes across as a laid back Japanese Pop star or Idol. Anyhow, he's cool and we're very happy to have him involved in the project.
I've seen Ryan give talks on many occasions and I can't help but say to myself, "man, I'm glad he's working with me". He was able to put together this talk in such short notice and I was a little concerned that he wasn't given enough time to prepare. There were a few speaker cancellations and we needed to fill some spots. Thankfully, he came through with an insightful talk on the evolution of PF. In the end, you couldn't help but think that nothing is wrong with PF, unless you were one of the FreeBSD users sitting in the crowd wondering why they were stuck with a version of PF from two years ago. To add insult to injury, they have even linked their Handbook to the OpenBSD's FAQ PF section which is current! Anyhow, it was this talk and a conversation with Claudio on the changes in OpenBSD's routing daemons that I realized that it is becoming ever more difficult to port our routing daemons and PF to the other Projects.
I was especially excited to have Marco come to Japan. He is one of the developers that has given us so much over the years. In fact, it's been said that he has been reinventing the Internet since 2000. Whenever he's not happy with something or a particular program doesn't work the way he thinks it should or could, he just writes his own. Maybe it's a little "Not Invented Here" syndrome but I'm sure happy he's got that :-). Look at all the work he's done with bioctl(8) and softraid(4), acpi(4), adsuck and a tiling window manager called scrotwm that I fell in love with. His first talk at the conference on epitome2 is another example of how much this person just keeps giving back to the Open Source community with alternatives that are desperately needed and/or better.
After softraid(4) crypto support was added a couple of years ago, I've stopped using svnd for my encrypted partitions and I've never looked back. As you know by now, Joel Sing (jsing@) was holding back a diff until after the tree unlocked post 4.7 for work to begin on making it possible to boot off of a softraid discipline such as a crypto disk. I know this isn't trivial to do but for some of us that have corporate policies that require whole disk encryption, it's such good news.
I think the highlight of the Work-In-Progress was when Theo gave an interesting talk about vether(4). This is new for 4.7 and essentially eliminates the need for an extra physical interface to get a full 1500 MTU on a gif(4), vether or ethernet interfaces to overcome Internet links with lower than 1500 MTU. You'll need a link on the other end with a full 1500 MTU and essentially you send twice as many packets on the wire which your ISP won't be happy with but you just want a better link. Now you can have a full 1500 MTU irrespective of the link quality that you get from your ISP. There should be many other applications of vether and hopefully this will get you thinking.
Finally, I have to thank our most gracious host and chair of the conference, Dr. Hiroki Sato from the Tokyo University of Science. He contributes a lot to the project directly and indirectly through organising this conference every year for the benefit of others. He certainly deserves much credit. It's a great conference to attend and a good excuse to come to Japan, especially at this time of the year when the cherry blossoms are out. I hope that many of you try to make it for next year either as attendees or as speakers. It's worth the trip!