Tue, 20 Jan 2009
Mono Framework 2.0 on FreeBSD
I've taken the good work done by the BSD# folks and have prepared it for integration into the FreeBSD ports tree. I'm awaiting final approval from them to put it through an -exp run on the cluster. If all goes well with the -exp run I'll be able to commit it into the tree shortly after. I don't know when it will happen yet but it's becoming closer with each passing day.
The effort consists of one huge patch and 3 new ports. The patch is at mono.diff along with webkit-sharp.shar, gnome-desktop-sharp20.shar and gmime2-sharp20.shar. Feel free to send me a mail if you notice anything wrong with them.
posted at: 15:52 | tags: freebsd, ports | path: /entries/freebsd | permanent link to this entry
Wed, 14 Jan 2009
FreeBSD Kernel Internals Posted to Youtube
If you didn't already know there is a BSDConferences channel on youtube. There are a good number of videos posted there and more coming as time permits. I'm currently watching The FreeBSD Kernel Internals by Marshall Kirk McKusick. I use the book written by him and George Neville-Neil fairly regularly, so this video is a good supplement. In fact, the book is sitting on my desk right next to me as I type this. ;)
posted at: 11:49 | tags: freebsd | path: /entries/freebsd | permanent link to this entry
Wed, 03 Dec 2008
So You Want To Be A FreeBSD Developer?
I'm quickly approaching the one year mark since I was asked to be a FreeBSD developer. Looking back at the past year I've had a lot of fun learning new things and settling in to a workflow. I've had some friends ask me what it takes to become a committer, and my response is usually the same. I figured I would lay my thoughts out here so I can simply point at them the next time I'm asked.
This assumes you are interested in actually contributing to the project. Contribution is not limited to purely code. There are lots of ways to contribute to the project, it's just a matter of finding that which suits your skills the best. This is probably one of the biggest things that is misunderstood about the project. Ultimately what the project produces is code but it takes a lot of resources to do that. Time, bandwidth and hardware are the most obvious resources consumed by the project but is not all that goes into the project. There are extensive testing and performance measuring work that goes on. There are things like documentation (arguably code), marketing and the foundation. All of these things are areas where you can contribute whatever you can. Which brings me to the next point: if you have decided you want to contribute how do you do that?
If you are truly interested in contributing to the project you should start by getting an understanding of how the project works. Every successful project has some kind of community around it, usually in the form of mailing lists. Start to read these lists and pay attention to things. You can really learn a lot this way, both technically and socially. You will begin to understand the tone of the project (is it a helpful and open discussion of things or is it hostile), and you'll start to see themes in things. You will see patterns of who is working on what, where the architecture of the project is headed and really get a feel for how to interact with the people who are already a part of the project. Ultimately that is who you are going to be working with, the people who are already doing the work.
First and foremost you need to understand that the project is made up of people who volunteer (for the most part) their time. They don't do it because some pointy-haired boss says they should; they do it because they have a passion for it. You have to always keep in mind that these people have lives, families and personal responsibilities outside of the project. You are not entitled to anything from these people so please don't make demands from people without offering some form of compensation for their time and effort. Also, be aware of your tone as email is often a difficult communication mechanism.
As alluded to earlier each project has a tone. In the greater context the project is like a society of people who are working towards a common goal. Any freshman level sociological class will illustrate that any given society has a set of normal practices and behaviors. As an outsider you should keep an eye out for these things and work within them instead of against them. The project does change, but like any large society it doesn't change quickly. Changes come over long periods of time and slowly. Your options are either adhere to these practices and behaviors or risk being ostracized before you can even begin to have an impact. You can always work to change these practices and behaviors from within.
So you've done your homework. You have started to get a feel for how the project works and where it is going. Along the way you should have spotted opportunities for improvement in things (again, not just code). In a volunteer project you have to be willing to dig in and get your hands dirty. Whatever the opportunity is for improvement you have to either fix it yourself or find a way to get someone else to fix it for you, all while working within the sociological context of the project.
In the process of working you will not be in an isolated environment. You will likely run into problems and need assistance. This is where you can reach out to the community for help. If there is a particular area of code you're interested in start talking to the developers whom you have identified as being likely to help you. It is often easy to forget that the person you are talking to in an email thread is a real human with emotions, and by virtue of being involved in the community has some of the same interests as you. Don't be afraid to talk to people within the community. They are there because they want to better the project also. This is probably one of the most important things to stress: there are real people doing the work, so interact with them as if they were standing right there in front of you. Lots of projects have IRC channels where the developers hang out. Don't be afraid to get to know the people, it's an important step in making a relationship last.
Don't be afraid to ask questions if you are stuck, but don't ask questions without doing some basic research yourself. If the project is lacking in documentation on how to do something that is a good opportunity for improvement. You should take that time to write the documentation so the next person doesn't get stuck like you did. Questions are a good thing and documentation is there to answer those questions. If the documentation doesn't answer your question then by all means ask for help.
Eventually, if you hang around the community long enough and work to improve things you'll begin to pick up bits of information that can be helpful to other people. By this point you should be sharing the information you've learned with others in the community. Answer some questions on mailing lists or IRC, respond to review requests from people. Start to become active outside of just improving things. In other words, start to empower others to get their work done also.
So you've got a great idea for something you can work on but you aren't sure how to do it. Don't ask for a community consensus on the design of something - it never works. By doing your homework up front and getting to know the direction of the project the design should be fairly evident. If it is not fairly evident you should ask for review from people within the community who have shown expertise in what you are working on. Decision by consensus leads to pointless discussions over stupid things. This is commonly called a bikeshed or Parkinson's Law of Triviality. A better approach is to do what you (and anyone you have asked for direction) think is best and be open to new ideas upon a wider review of your work. You will often make mistakes in your design and implementation of things. This is normal. Learn from these mistakes and move on.
The idea of a bikeshed is an interesting one and one that should figure prominently into your interactions with the community. Don't give a bikeshed response to something. As an example I was recently paying attention to some features that were proposed for a project I use heavily in my FreeBSD work. One of the features was to include a favicon.ico in the src tree so that the port did not have to distribute it by hand. The particular icon which was suggested was Beastie instead of the new official FreeBSD logo which I would have recommended. Instead of sending a reply and starting a stupid discussion I merely did not comment. In the grand scheme of things is the favicon used important enough to warrant what would certainly become a pointless thread with no clear conclusion?
In the FreeBSD world, and often in other projects, if you do enough good work you will be offered a commit bit. Usually it comes from someone you've been working with, but not always. If you've gone through all the things listed above and are improving the project in any way you can then you likely won't see a commit bit as anything besides what it is: a formal recognition of your contributions by existing project members. So there it is, you've become an official member of the project after a lot of hard work and dedication. But does being an official member mean anything? In my experience it gets you two things: first, the ability to directly commit your work and second, the ability to vote in the core-team elections. Not being able to do these two things doesn't mean you aren't an accepted member of the community, so don't be discouraged if you think you deserve a commit bit and don't get one. Instead your passion for the work and the project should keep you happy and busy. Your hard work has likely already paid off by this point even if you don't have the commit bit to show for it. People within the community likely respect you and value your contributions. Keep up the good work and the official reward will eventually get there.
posted at: 18:23 | tags: freebsd | path: /entries/freebsd | permanent link to this entry
Mon, 24 Nov 2008
ZFS Update on ack
wxs@ack wxs % mount data on / (zfs, local, noatime) devfs on /dev (devfs, local) /dev/ad4s1a on /mnt/ad4s1a (ufs, local) data/dump on /dump (zfs, local, noatime) data/dump/cvs on /dump/cvs (zfs, local, noatime) data/dump/incoming on /dump/incoming (zfs, local, noatime) data/dump/mp3 on /dump/mp3 (zfs, NFS exported, local, noatime) data/jails on /jails (zfs, local, noatime) data/ncvs on /ncvs (zfs, local, noatime) data/tinderbox on /tinderbox (zfs, NFS exported, local, noatime) data/tmp on /tmp (zfs, local, noatime) data/usr on /usr (zfs, local, noatime) data/usr/home on /usr/home (zfs, local, noatime) data/var on /var (zfs, local, noatime) wxs@ack wxs % sudo zfs get version NAME PROPERTY VALUE SOURCE data version 3 - data/dump version 3 - data/dump/cvs version 3 - data/dump/incoming version 3 - data/dump/mp3 version 3 - data/jails version 3 - data/ncvs version 3 - data/tinderbox version 3 - data/tmp version 3 - data/usr version 3 - data/usr/home version 3 - data/var version 3 - wxs@ack wxs %
I upgraded ack (my personal development machine and fileserver) recently. Along with the upgrade I figured I would try out the new ZFS version and upgraded all the filesystems in this pool. There was only one problem which was resolved by using the old slice I had laying around which I still boot off of and fixing my mistake.
So with this update and ongoing work I should have a much more stable system (it was very stable before the update so this isn't saying much). I'll also be able to test out some of the delegated administration aspects of this update which sounds very nice. Lastly I hope to eventually test out the boot from zfs support which is just recently hit the tree and is still highly experimental.
posted at: 23:33 | tags: freebsd, zfs | path: /entries/freebsd | permanent link to this entry
Mon, 17 Nov 2008
New ZFS Features in FreeBSD
With this commit we have an updated ZFS in -current now. I intend to play with some of these issues as time permits. I'm especially interested in the delegated administration piece of it.
No, I'm not dead again. I've just not wanted to write much about what I've been doing since it's mostly been fairly easy work lately. I've already committed more things to FreeBSD than any other month so far, so it's not like I've been slacking. I've got HoH work starting up this year, and I'll probably be putting a couple posts up over there. If you're one of my few readers who comes by this time of year looking for HoH information you can look at the new site run by Kym. Anyways, if I'm in your RSS reader don't delete me just yet. Maybe I'll pick up a decent project soon and write about it.
posted at: 17:15 | tags: freebsd, zfs | path: /entries/freebsd | permanent link to this entry
Sun, 28 Sep 2008
/ on ZFS.
Prior to moving to NC (oh yeah, I may not have mentioned it here but I moved to the RTP area in North Carolina a few weeks ago) I took a quick stab at doing a migration from a regular setup to everything (except /boot) on ZFS. The first attempt failed miserably but I tried again tonight and got it working.
All the documentation I've found online details how to set it up without a currently populated system. This at least gave me a major hint as to what the final product should look like, even if it did not provide me with a simple step-by-step guide to get there. So after some hacking I had everything set up how I thought it should be and kicked off an rsync to move everything to the zpool. Upon reboot I went back into single user mode and double checked everything before booting into multiuser. The machine is now up and running, though I'm sure I will have some bugs to iron out. I have noticed a repeatable crash during reboot though, so I plugged in a serial cable and will attempt to debug later in the week. The machine is sitting in a closet on the other side of my office so I had to break out the obnoxiously long serial cable and run it behind my desk.
posted at: 20:41 | tags: freebsd, zfs | path: /entries/freebsd | permanent link to this entry
Tue, 02 Sep 2008
Bug Found and Fixed in fastest_sites.
There was a bug in fastest_sites which I just committed a fix for. The idea for the fix came from Ryan Steinmetz, though the patch has a couple smaller additions by me to make it slightly more friendly.
The bug is because there are things like this in Mk/bsd.sites.mk:
.if !defined(IGNORE_MASTER_SITE_DEBIAN_POOL)
MASTER_SITE_DEBIAN_POOL+= \
${MASTER_SITE_DEBIAN:C|(/%SUBDIR%/)|/pool/main/${PORTNAME:C/^(.).*$/\1/}/${PORTNAME}/|}
.endif
...
.if !defined(IGNORE_MASTER_SITE_GOOGLE_CODE)
.if defined(PROJECTHOST)
MASTER_SITE_GOOGLE_CODE+= \
http://${PROJECTHOST}.googlecode.com/files/
.else
MASTER_SITE_GOOGLE_CODE+= \
http://${PORTNAME}.googlecode.com/files/
.endif
.endif
The way fastest_sites works is by doing 'make -V MASTER_SITE_FOO -f $PORTSDIR/Mk/bsd.sites.mk' for every MASTER_SITE definition in the file. It then splits the result and makes the connections to everything (not technically true, it only does the first 10 which respond) in the list in order to get the RTT estimate for a TCP handshake. The problem is that ${PORTNAME} is not defined resulting in:
wxs@ack ~ % make -V MASTER_SITE_GOOGLE_CODE -V MASTER_SITE_DEBIAN_POOL -f /usr/ports/Mk/bsd.sites.mk http://.googlecode.com/files/ http://www.gtlib.cc.gatech.edu/pub/debian/pool/main/// ftp://ftp.us.debian.org/debian/pool/main/// ftp://ftp.au.debian.org/debian/pool/main/// ftp://ftp.bg.debian.org/debian/pool/main/// ftp://ftp.cl.debian.org/debian/pool/main/// ftp://ftp.cz.debian.org/debian/pool/main/// ftp://ftp.de.debian.org/debian/pool/main/// ftp://ftp.ee.debian.org/debian/pool/main/// ftp://ftp.es.debian.org/debian/pool/main/// ftp://ftp.fi.debian.org/debian/pool/main/// ftp://ftp.fr.debian.org/debian/pool/main/// ftp://ftp.hk.debian.org/debian/pool/main/// ftp://ftp.hr.debian.org/debian/pool/main/// ftp://ftp.hu.debian.org/debian/pool/main/// ftp://ftp.ie.debian.org/debian/pool/main/// ftp://ftp.is.debian.org/debian/pool/main/// ftp://ftp.it.debian.org/debian/pool/main/// ftp://ftp.jp.debian.org/debian/pool/main/// http://ring.nict.go.jp/archives/linux/debian/debian/pool/main/// http://ring.sakura.ad.jp/archives/linux/debian/debian/pool/main/// http://ring.riken.jp/archives/linux/debian/debian/pool/main/// ftp://ftp.nl.debian.org/debian/pool/main/// ftp://ftp.no.debian.org/debian/pool/main/// ftp://ftp.pl.debian.org/debian/pool/main/// ftp://ftp.ru.debian.org/debian/pool/main/// ftp://ftp.se.debian.org/debian/pool/main/// ftp://ftp.si.debian.org/debian/pool/main/// ftp://ftp.sk.debian.org/debian/pool/main/// ftp://ftp.uk.debian.org/debian/pool/main/// ftp://ftp.wa.au.debian.org/debian/pool/main/// ftp://ftp2.de.debian.org/debian/pool/main/// wxs@ack ~ %
The results are obviously bad: http://.googlecode.com is not legal, and while the seecond result is a legal URL it is not correct in the context of ports - it's missing the piece about the PORTNAME.
The patch looks for results that contain '//.', '[a-zA-Z]//' or '..' as those are the common cases. Technically the '..' case doesn't exist yet but it's not a far stretch to see a MASTER_SITE_FOO definition that uses http://www.${PORTNAME}.mirror-network.com in the future. We might as well catch that case now.
I committed the patch tonight, thanks again Ryan, and notified Jordan (he's the author of fastest_sites) about some other minor issues with it. I'd fix them myself but my python-fu is very weak and I just don't have the time since I'm moving in a week. Hopefully Jordan will get around to it once he's back from his honeymoon.
posted at: 22:46 | tags: python, ports, freebsd | path: /entries/freebsd | permanent link to this entry
Sun, 29 Jun 2008
Web2.0 Graphs + Core Team Elections
No, I'm not dead. I've been preparing to go all web2.0 with some fancy new graphs for Freshports. The content is working, but they could use a small bit of polish in order to make them really shine. I'm hoping to have something for those out the door next week (would be this weekend but I'm traveling for the 4th).
I also placed my votes for the FreeBSD Core team today. Yay!
posted at: 18:00 | tags: freebsd | path: /entries/freebsd | permanent link to this entry
Fri, 13 Jun 2008
Flying Solo
garga 2008-06-13 17:57:54 UTC
FreeBSD ports repository
Modified files:
. access
Log:
Forced commit to note wxs@ is free from mentorship, hs is ready to fly solo.
Revision Changes Path
1.833 +0 -0 CVSROOT/access
posted at: 18:45 | tags: freebsd, ports | path: /entries/freebsd | permanent link to this entry
Fri, 02 May 2008
Good Video Describing How The FreeBSD Project Works
Here's an interesting video explaining some of the aspects of the FreeBSD community, given by Robert Watson at Google in June 2007. It's a great thing to listen to if you have very little knowledge about FreeBSD and how it's community works. I just noticed that if you look closely you will see Jordan Sissel in the audience. He's wearing the maroon colored backwards hat (he's off on the right).
posted at: 20:52 | tags: freebsd | path: /entries/freebsd | permanent link to this entry
