Slashdot Mirror

← Back to Stories (view on slashdot.org)

NetBSD Status Report January - March 2005

Posted by Zonk on from the howzitgoin? dept.

jschauma writes "The NetBSD Foundation published its first quarterly status report in 2005, covering the months January through March of 2005. Among many other things, this status report covers the addition of TCP/SACK and PAM support, the opening of the Foundations Online Store, the new stable pkgsrc branch and various port-specific items."

11 of 111 comments (clear)

  1. Wow, that's a bit slow by vadim_t · · Score: 1, Interesting

    PAM has been available on Linux for ages. And it doesn't look as a very complicated thing either.

    Just curious, have there been problems with the adoption of PAM, or it just wasn't a priority?

    1. Re:Wow, that's a bit slow by Anonymous Coward · · Score: 4, Interesting

      PAM has been around for a while, but it's a huge pain in the ass to get working right. It was around when I was building my LFS-4.0 system, and the only thing it served was to confuse me. It's used by some apps, but not by most, although the apps not using it could be blocked by apps using it if you didn't have the settings correct.

      Since this is a BSD PAM, at least we know there'll be good documentation concerning it (ie, more than what it is and what it can do).

    2. Re:Wow, that's a bit slow by sudog · · Score: 5, Interesting

      It wasn't adopted because PAM is a steaming pile, and the people on the NetBSD mailing lists have been arguing ceaselessly about the only benefit that PAM has over other, technologically superior schemes: support for closed-source binary authentication modules.

      Part of the reason for the push for PAM adoption has been the recent commercial slant of the decisions of NetBSD core. I wouldn't call it "selling out" per se, but I would say that it is no longer just about the code.

      It's unfortunate. It's reluctance to incorporate things like PAM, or use Linux-like exploding version numbering, was the primary reason I was such a pro-NetBSD supporter. Now that those attractions are gone and the NetBSD foundation seems to want to play catch-up with Linux, I might as well just go with FreeBSD, or a version of Linux.

      I believe the reason for the recent commercial slant is simple: I think the commercial customers of Wasabi Systems are pushing them to build an OS which is as close to Linux as possible but is not encumbered by the GPL. The commercial advantages of that are obvious, but disheartening.

      NetBSD's old niche of extreme portability and purity is now overshadowed by these commercial interests. Too bad.

    3. Re:Wow, that's a bit slow by Anonymous Coward · · Score: 3, Interesting

      Now that those attractions are gone and the NetBSD foundation seems to want to play catch-up with Linux, I might as well just go with FreeBSD, or a version of Linux.

      Have you considered OpenBSD? I think we can safely say that OpenBSD will never "play catch up" by going against core project ideals. They'd rather implement from scratch if the need arose.

      If only OpenBSD had Unified Buffer Cache I might be using it 100% of the time, as opposed to 90/10 Open/Net.

      At least I can rest assured that OpenBSD moves carefully forward and performance issues will continue to be sorted out with the long term big picture in mind and not use some quick fix hacks.

      I think the commercial customers of Wasabi Systems are pushing them to build an OS which is as close to Linux as possible but is not encumbered by the GPL.

      What can Linux do that NetBSD can't? This is a serious question BTW. NetBSD has been a better fit when I have had to deploy in commercial environments. I've tested latest SuSE and RH Core against NetBSD 2.0 with the custom disk heavy apps I deploy and NetBSD killed them all. What are people who choose NetBSD missing out on?

    4. Re:Wow, that's a bit slow by Morth · · Score: 2, Interesting

      The big problem with PAM is that it wants to stay in control of the thread and only use callbacks when it needs some information from the user. This cause several problems if you're not willing do dedicate a separate thread to authenticating. If you for example have periodic tasks or want to support multiple users at the same time, you have to make various hacks to make PAM return control of the thread to you.

      I think you misunderstood the closed source part. It was about corporations pressuring to be able to use their closed source PAM modules with any PAM application.

      I do not agree much with the GP though, and I think the version number system is a weird thing to choose your OS on. NetBSD still has the cleanest source base out there, and BSD in general have lots of advantages over Linux.

    5. Re:Wow, that's a bit slow by Anonymous Coward · · Score: 1, Interesting

      Interesting troll.

      Care to provide any examples of a "decrease" in quality, or things that "always" break under the most recent version of the Linux kernel? Or are you too much of a juvennile to back yourself up?

    6. Re:Wow, that's a bit slow by Anonymous Coward · · Score: 1, Interesting

      In my experience, NetBSD's UBC does not increase performance vs OpenBSD in any realworld situations.

      I had to write some shell scripts to parse some large log files and expand them via lookup tables. The log file was larger than half the current free memory. The result was that running this under OpenBSD caused the hard drive light to pretty much be permanently hard-on, whereas running this under NetBSD on the same machine showed NetBSD running very many times faster than OpenBSD and the hard drive light only coming on every now and then to write the output. From memory, NetBSD was about 7 times faster than OpenBSD for this. I assume this is due to the fact that OpenBSD was not able to cache all the data, whereas NetBSD could due to its buffer and cache being unified and thus much more efficient.

      OpenBSD would have been buffering and caching data seperately that it would very soon need to flush and then buffer and cache again, in addition to writing the result to disk. This would have caused lots of wasted CPU cycles and disk head thrashing, as the head moved between reading input files and writing the output file.

      NetBSD on the other hand was able to cache it once and then just work on reading the cached data, only ever accessing the disk for writing. Reading out of RAM would have been super fast for sequential reading and random reading would have been hyper fast (comparitively speaking against disk), leaving the disk free for mostly sequential writing.

      For me this was a real World problem that was big enough to have me move over to NetBSD for problems like these. I'm not a NetBSD zealot btw, I continue to love using OpenBSD where it shines, which is why I wish OpenBSD would gain UBC. If I could always just use OpenBSD then I would be very happy. Moving away from such a clean, well documented system for performance reasons is disappointing for me, especially when it is the system I know best.

      PS, this was done with shell scripting of standard unix tools performing multiple passes on the same file (thus the caching issue). I probably could have implemented this with Perl or Python, etc and performed a single pass on the massive file, but I had some unique barriers at the time disallowing me from doing that. So obviously this real World problem is probably far from typical. I'd still love to see UBC in OpenBSD. At least it is on their list of things to do.

  2. Robustness of Xen support by LaughingLinuxMan · · Score: 3, Interesting

    Regarding Xen support, is it robust enough to "jail" applications like web servers or ftp servers? Or, at least, can it be used to provide multiple personal "servers" as we have seen with VMware? -LLM

    --
    Annoy a Conservative...
  3. So... by Anonymous Coward · · Score: 1, Interesting

    ...what are the differences between the various BSDs, out of curiosity?

    1. Re:So... by DarthBart · · Score: 4, Interesting

      FreeBSD - Originally started out as an x86 only port. Screams on x86 hardware. Other ports are kinda lackluster. Its the BSD for people who don't want to run Linux. NetBSD - Runs on everything from a Sun Ultra 60 to a toaster. Has an extremely robust IP stack and a very well designed architecture independant framework for both host machines and device drivers OpenBSD - Supposedly "secure out of the box" via large amounts of code review for security holes. Eh. The biggest thing with OpenBSD is Theo's ego. Yes, I'm kinda partial to NetBSD.

  4. Sorry, I'm trolling... by pp · · Score: 1, Interesting

    TCP SACK was introduced in 1996. Linux introduced it some time between 2.0 and 2.2 (that is, around 1999-2000). It's quite useful if you have a high-bandwidth link with some packet loss, since you can now retransmit only those packets that actually did get lost.

    Good to see that the we-are-the-defacto-internet-standard-tcpip-stack people are finally catching up. NetBSD does get some very impressive single-CPU TCP/IP benchmarks though. Oh. They forgot fine-grained locking in their network stack. I suppose performance with those quad Opterons sucks. Too bad. Well. they do have the long distance record tho, guess how many cpus those boxes had. :)

    And yes. PAM is a pile of dung, even on non-BSD systems. But it does let you easily authenticate off just about anything adding just a few lines to your config files. That means RADIUS logins for local users or those that are just accessing some random web page served by Apache that you want to add some access control to. Or LDAP or Kerberos or NIS or NIS+ or a customized SQL database.