NetBSD Summer of Code Summary

UltimaGuy writes "The NetBSD Project is pleased to announce the results of its participation in Google's "Summer of Code". After Google announced this program to introduce students to the world of open source software development at the beginning of June, the NetBSD Project was happy to join the approximately 40 other open source groups as a mentoring organization and compiled a list of suggested projects. I personally think the Project tmpfs: Efficient memory file-system as the most successful one."

Userfs

[RAMMS+EIN]

Seeing that userfs is still in early development, perhaps an effort could be made to unify the API with FUSE. Then we could develop filesystems in a way that is portable between Linux and NetBSD, and possibly others once they follow suit.

SysV-type (init.d) subsystem control?

[Anonymous Coward]

[I'm probably behind the times and it already exists ... if so, then sorry, gimme a URL to it pls. :-)]

Being a big-Unix person, I find the SysV approach to subsystem control through "init.d/blahblah {stop/start}" very sysadmin-friendly, so Linux has always got a big pat on the back from me for that. In contrast, the old *BSD approach has always seemed less helpful when you need to bring subsystems up and down regularly. One manages, but it's a pain.

I guess I was hoping to see SysV-type subsystem control among the Summer of Code projects. It sure would be handy for sysadmins.

UserFs Completion

[msisden]

Let's do a run down:

# still bare-bones
# simple filesystem with some hardcoded files (which are modifiable) written
# "The framework coughs but manages to avoid complete and utter defeat."
# code not yet imported
However, in the end: all SoC goals met ?

That just seems...... off to me.

Re:SysV-type (init.d) subsystem control?

[Ezdaloth]

Indeed. I actually find the rc.d system much easier to use then the sysv-init thing. I tend to get confused by 6 directories with symlinks which have to be kept up to date instead of 1 configuration file.

And frankly, i never use the different runlevels like you're supposed to anyways. I only ever start or stop single services, and reboot the system. I don't start different sets of services.

tmpfs documentation

[Commander Spock]

The tmpfs is a good project for many reasons, and one big one is because of the documentation. Documenting the "hows" of making a filesystem is something that I find fascinating.

I once wrote a ramdisk driver from scratch on MacOS 7; it would have been nice to have enough documentation to actually write a new filesystem to use on it instead of HFS.