This is my last entry of the year. I have been looking into actually implementing mtree-based packages and it's difficult! :) mtree only checks directories, netbsd's /etc/mtree uses some weird specification to get the files just so, and netbsd sed doesn't have an inline option. It's all very difficult.

I would, however, like to report that postgresql is so far ahead of mysql that it's pathetic. The whole world needs to wake up! It's not that I don't like mysql, I do, but pgsql has that "enterprise" feel, tablespaces, and all kinds of handy stuff. ;)

I started and finished tomb raider legend this week. It was very easy and short, but fun. I suppose I've played enough of those types of games (3rd person action/map puzzle) to be relatively good (unlikely) at them so it went pretty quickly. I could replay through the whole thing in new outfits and time trial my ability to get through levels, but that's kind of silly. :)

Labels: gaming

I just installed NetBSD-current (5.99 right now) on my eee and it was pretty much exactly the same as it always has been. The installer seems the same except that it updates rc.conf with rc_configured=YES, so you can actually get into multi user mode on the first boot. I also wanted to use the in-tree x.org, so I checked out xsrc (cvs checkout xsrc) and then did a build.sh -X ../xsrc to get it to build. I then installed with tar -C / -xzvf x[..].tgz. It went smoothly and twm started without even trying to get a working xorg.conf (which I should have saved from my 4.99 instsall. oh well)

Anyway, this should be about the same as 5.0 except now GENERIC will work with ath and lii. I also don't have to restart my network to get wireless working since wpa_supplicant and dhcpcd seem to interact a little nicer.

It got me thinking a little bit about a project for automated installs of netbsd. I think it should be pretty easy to script the entire process of newfs and tar/pax, so maybe I'll look into it a little more.

Labels: eeepc, NetBSD, project ideas

To expand a little bit on the thread of my mtree-pkg idea I'd like to document more things that have been rattling around in my head for a while-

build.sh to pkgsrc crossover framework. I would like to have a list of pkgsrc packages and a mk.conf variable pointing to where pkgsrc lived. When I do a build.sh makepkgs=YES, build.sh would build NetBSD and create a meta-pkg with my list in it, reach over to $PKGSRCHOME/, build these packages with my build.sh tools (cross-build enabled!), and pop that onto my install media. The installed could then see that I have pkgs/* to install and ask if I wanted to put them in.

build.sh/crunchgen custom userland list. This is another list of programs where I want to build a custom crunchgen bundle with build.sh so that I could create a file with only the programs I wanted, execute build.sh mkcrunch=YES kernel=FOO, and end up with a FOO kernel containing the crunched FOO list of programs I specified.

For reference, I've shared similar suggestions in the past:
adding 'make syspkg' to pkgsrc
pkgsrc to replace build.sh

Labels: NetBSD, project ideas

On irc we were discussing the FSF vs Cisco lawsuit and how, no matter the outcome, BSD will benefit.

Here's the reasoning per potential outcome:

FSF wins, cisco is forced to comply with the license. This proves that the GPL is court-enforceable and removes some ambiguity from using the GPL as a license, which puts it on similar footing as BSD. This is a win for linux, which is a win for free software in general, which is a win for BSD.

Cisco wins and does not have to comply- this sets a precedent that the GPL is useless in court and software seeking freedom will look to BSD, which has had better results in the courts.

Cisco decides compliance is not worth the effort and switches Linksys to NetBSD. Obviously, BSD wins in this situation since it gets more market penetration.

Even if they simply settle out of court and the whole thing goes away it would also make companies considering GPL/Linux wary since they might get sued if they don't fully comply. BSD is much, much easier to satisfy. (Portions of our product use code derived from NetBSD. Compliance complete. See sony psp for an example.)

If Cisco sues the FSF out of existence, that's a huge loss for the free software community, but an even bigger loss for linux than for BSD.

Labels: bsd, cisco, linux

Another project idea I had was to take better advantage of the /etc/mtree/set.* files on NetBSD. These files compose a database of installed files on any given NetBSD system. As far as I can tell, however, they aren't used for anything else. They will be scanned by /etc/security if you copy them to $something.secure (cat set.* >> files_to_scan.secure). The file "secure" is also a part of the security scan.

So the basis of the idea is this- if NetBSD needs to do a security update, it usually only needs to replace a few files and change the minor.minor version number. Instead of having to reinstall all of your sets, or all of net.tgz, you should be able to pkg_add -s security_update_20081208.tgz which will simply update the affected files, make backups, change the set.mtree's, and increase the version number after validation. This could also trigger notes about updating configs, checking for dependencies, etc.

As a side-effect, pkg_add could also install FULL base.tgz or any other set as a system package and that idea could be resurrected because, as we all know, it's the right way to go. I'm also a proponent of keeping system packages in a separate database from pkgsrc packages, which is why I like the mtree idea so much- it's a different format!

Labels: NetBSD, project ideas

Here's a project idea- Create a project on sourceforge/google code to create FUSE filesystems for all of the commonly-known bsd filesystems. For example- netbsd-ffs, freebsd-ffs, openbsd-ffs, netbsd-lfs, dragonflybsd-hammer, etc. I started to look at this and it's a serious undertaking. :)

Would I have to teach FUSE about the ufs/disklabel layer before I could get into ffs/lfs on disk? Or would it be as easy as just pointing the fuse functions to the already-written functions in the filesystem code?

Hopefully, I will get motivated enough to look at this a little more.

Labels: FUSE, project ideas

I've added a gallery of select photos from my recent trip to Paris. Check them out!

Ginny and I spent a week there recently and I'm just getting over the sinus infection I picked up along the way. Although the flights were long and the weather was bad, it was still a good time and being in paris is a huge improvement over being in atlanta. :)

Labels: paris, travel

While writing mc.c (txt) I had to learn that linux didn't support the same socket structures as BSD. This is, in my opinion, annoying and a case of NIH (Not Invented Here syndrome). So, the most portable way to use the various socket calls is to always call sizeof() instead of using a stored-in-the-struct socklen_t value. In fact, don't even attempt to set sockaddr_storage.ss_len or any similar member, because your compile will break on linux.

Of course, as a newbie to socket programming the sage of sockaddr_storage was a little difficult to grok in the first place.

Yes, i also know I don't use KNF.

I also haven't event attempted any c programs on windows, so maybe I'll have to give that a shot and learn about REAL portability issues. :)

Labels: c programming, linux, socket programming

I finally finished the DS game: The World Ends with You. It was pretty good. :) The two-screen gameplay was an interesting challenge to keep going with the more difficult bosses and I know there are some parts that I missed because I didn't clear all of the reapers in all of the stages, couldn't figure out how to work some pins, etc, but I've never been one to go back and replay this stuff. I also got the music from this game stuck in my head all the time so I had to play just to hear it, which I guess is a good sign.

This game left me with a strong desire to live in shibuya, tokyo.

http://www.theworldendswithyou.com/