Slashdot Mirror


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."

11 of 20 comments (clear)

  1. So.... by baldass_newbie · · Score: 3, Funny

    Would this be their 'Autumn of Results'?

    --
    The opposite of progress is congress
    1. Re:So.... by nacturation · · Score: 2, Funny

      Would this be their 'Autumn of Results'?

      As long as it's not followed by a Winter of Discontent.

      --
      Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
  2. Userfs by RAMMS+EIN · · Score: 4, Interesting

    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.

    --
    Please correct me if I got my facts wrong.
  3. SysV-type (init.d) subsystem control? by Anonymous Coward · · Score: 2, Interesting

    [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.

    1. Re:SysV-type (init.d) subsystem control? by rsax · · Score: 3, Informative

      The new rc.d system is equally sysadmin-friendly as the SysV equivalent. FreeBSD adopted it as well.

    2. Re:SysV-type (init.d) subsystem control? by Ezdaloth · · Score: 2, Interesting

      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.

    3. Re:SysV-type (init.d) subsystem control? by Arandir · · Score: 2, Insightful

      And frankly, i never use the different runlevels like you're supposed to anyways.

      I don't think anyone else does either. It's far more complex than the "problem" it was trying to solve. Somewhere deep within the bowels of Sun is a sysadmin who truly uses the SysV init system, but everyone else can get by with a far simpler system... like rc.d.

      --
      A Government Is a Body of People, Usually Notably Ungoverned
  4. UserFs Completion by msisden · · Score: 2, Interesting

    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.

    1. Re:UserFs Completion by Flaming+Foobar · · Score: 2, Informative
      That just seems...... off to me.

      That's because you didn't read the goals. They were behind a link, so I'm not sure if they qualify as TFA.

      --
      while true;do echo -e -n "\033[s\n\033[u\134_\033[B";done
  5. I think I speak for the entire open source... by Refrozen · · Score: 2

    ...community when I say "Thanks Google."

  6. tmpfs documentation by Commander+Spock · · Score: 2, Interesting

    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.