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

40 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 idiotnot · · Score: 1

      AFAIK, Slackware doesn't use PAM.

      I've setup linux pam on NetBSD, and it works okay (for LDAP auth).

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

    4. Re:Wow, that's a bit slow by vadim_t · · Score: 1, Insightful

      huh?

      Now, I'm perfectly willing to believe that PAM is crap, provided good evidence (which you didn't). I've written a PAM module myself, and didn't see anything majorly wrong with it. So, please tell me what exactly is wrong with PAM and why, as I'm very interested.

      However, I strongly disagree with the closed source part. Why exactly should the authentication system a closed thing, and what's the good in it? Unix has a well designed mechanism - it's perfectly well known, the password database can be left readable, and still (provided passwords are good) it's safe. That's good design.

      What exactly are those closed source modules, and what's that great about them?

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

      correct Slackware doesnt use PAM, and GNOME has been dropped from Slackware, and that was one of the reasons, because so many things need none-PAM GNOME and soem need PAM GNOME, so its been dropped so people can choose to install which ever they want after completion

      --
      ¦^)= The Vengance Will Come =(^¦
    6. Re:Wow, that's a bit slow by vadim_t · · Score: 1

      Yup, actually I have, I wrote a little module for it. Nothing very impressive though.

      Now, the architecture is certainly debatable. PAM is essentially a library that replaces the code that would have inside the program itself instead. In that sense it's a massive improvement.

      Now, a replacement in the form of a daemon would be interesting. I wonder if there is anything like that out there. Especially something PAM compatible, if possible.

    7. Re:Wow, that's a bit slow by SA+Stevens · · Score: 1

      Huh? FreeBSD has a single source tree that I can download once and build, from scratch, on my PPC, Mac68K, i386, Sparc, MIPS, VAX, and ARM hardware?

      No, FreeBSD is partway along the way to this, but since portability hasn't historically been a primary consideration (in fact, not caring about portability, just the x86 platform, was a primary reason for the FreeBSD fork in the first place) Why reinvent the 'portability' wheel by trying to port something all over to different archs, when a working codebase specific to that goal already exists?

    8. Re:Wow, that's a bit slow by Brandybuck · · Score: 1

      PAM has been around for a while... It was around when I was building my LFS-4.0 system

      So which is it? LFS-4.0 is current events.

      --
      Don't blame me, I didn't vote for either of them!
    9. Re:Wow, that's a bit slow by setagllib · · Score: 1

      Is that really what bothers you? I have to report that in spite of the PAM inclusion, NetBSD 3.0-beta is still a world of performance and efficiency, and EVERYTHING works properly. Things that always broke on Linux 2.6.11, for instance.

      It's good that it's moving to be able to replace Linux, that means it can gain market share while still retaining its quality. What the hell is wrong with you? If implementing features of questionable design (even though the implementation, Open PAM, is about as good as you can get) kills an OS for you, you are going to have to ignore FreeBSD (why? because it has made nothing but bad design decisions lately, AND IT HAS THE SAME PAM IMPLEMENTATION) and Linux (one big bad design flaw, and it's the corporate monster you're afraid NetBSD will be).

      NetBSD is probably the only system that is moving to corporate-worthy and Linux-replacing changes, while not actually losing any quality in the process. Yes the source tree is a bit bigger now. But yes it is also now more appealing to a large number of users who were previously stuck with Linux or FreeBSD so as to have a base-system PAM. If it increases market share without decreasing quality, it's a Good Thing. Linux does it almost every day, and Linux often does decrease quality.

      --
      Sam ty sig.
    10. Re:Wow, that's a bit slow by setagllib · · Score: 1, Informative

      The problem is that even the loopback interface can be sniffed on (usually only by root, admittedly, but still) so any authentication happening with sockets is going to be a bit on the dangerous side. Libraries are still in the protected address space of their host process, so there's no problem. I like daemons, don't get me wrong, but I wouldn't trust one to handle authentication - especially since there's no real advantage to it.

      Now, if we were talking about network authentication with decent SSL or other encryption between daemon and client, that I could agree with. But I believe that's already been done in other ways...

      --
      Sam ty sig.
    11. 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?

    12. Re:Wow, that's a bit slow by Guy+Harris · · Score: 2, Informative
      The problem is that even the loopback interface can be sniffed on (usually only by root, admittedly, but still) so any authentication happening with sockets is going to be a bit on the dangerous side.

      Socket traffic between processes on the same machine doesn't have to go over the loopback interface.

      (Hint: "UNIX-domain sockets".)

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

    14. 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?

    15. Re:Wow, that's a bit slow by setagllib · · Score: 1

      I don't think you know what I mean at all. I didn't deny any of that. I am refuting that its (accused) move to replace Linux is not hampering its quality (where 'quality' is 'does what it's supposed to properly', not 'does what Linux does', which is a stupid argument).

      Do you know why I dropped Linux on my gateway? It couldn't handle IPSec properly. On certain protocols (yes, it actually had protocol-specific bugs, even though IPSec is meant to be protocol agnostic) it would just drop packets without any clue as to what was happening. The exact same configurations on DragonFly and NetBSD worked exactly as expected. THAT is what I am talking about when I say quality. If a BSD says something will work in a stable branch, it will work. This is not the case in Linux. 2.6 is meant to be a stable branch, yet a lot of things either don't work or have huge debilitating bugs like this IPSec misfeature. I don't care if Linux' performance runs loops around NetBSD, if it doesn't do what it's supposed to and has no practical workarounds, THIS FAR INTO A STABLE BRANCH, it is not even worth considering.

      And since NetBSD is gaining ground (albeit slowly) to be able to replace Linux installs for more and more applications, all the better. Others, too, will be able to replace Linux with a system that Works Properly All The Time, not just Works Properly in 2.6.8-rc3-mm2-bbq5.

      --
      Sam ty sig.
    16. 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.

    17. Re:Wow, that's a bit slow by overbom · · Score: 1

      On Darwin, that would be netinfod and lookupd, though they encompass much more than just authentication. I know they're open sourced, but I don't know if they've been ported or not.

      hth

    18. Re:Wow, that's a bit slow by setagllib · · Score: 1

      Actually, smartass, I DID test it thoroughly, and (in 2.6.11, and continuing to 2.6.12-rc2 - no other kernels tried) it consistently fails to connect the MSN protocol (any client) and POP3, and some HTTP seems to behave badly but mostly okay. It IS a bug in Linux because none of the BSDs exhibit this, and it is also a bug that isn't fixed in 2.6.12-rc2 despite numerous changes to IPSec (and related) components.

      When you show me a BSD exposing a significant security hole (like the Linux signal exploit) or breaking long-standing network functionality (IPSec, packet filtering, etc.), then I might consider them somewhere close to buggy, but flawed hardware support is nothing compared to the breakages Linux experiences.

      A Linux advocate I know said, and I quote directly, "I've had some corker problems on GNU/Linux-based systems that can only be attributed to poor development and testing, and implementing the same thing on OpenBSD had no issues at all. First thing that comes to mind as indicative of the difference in quality between the GNU/Linux and BSD's, is PAM vs BSDAuth.."

      Honestly, it's no mystery and nothing new at all. Linux does not get tested. Shit, are you even listening to kernel devs? They've decided NOT to do any quality assurance, leaving vendors up to the task of testing and bug fixing (hint: they don't do a good job either). Find THAT kind of philosophy in any BSD...

      --
      Sam ty sig.
    19. Re:Wow, that's a bit slow by setagllib · · Score: 1

      You know what? You're absolutely right. To be honest, this IPSec thing (which I insist I am not doing wrong, since even with years of iptables experience I could not identify anything wrong with my script that could have affected this) is the only real bug I've had with Linux, which is much better than anything I can say about ANY BSD I've used. I'm a whingy bastard who just tries to level the playing field and give BSD a chance.

      Although it would still be nice to have this worked out. In the meantime I've worked around HTTP and POP3 by tunneling them through SSH (so now they work great), and running AMSN on the gateway itself and only tunneling the X component. Good enough for now.

      Truth is I run Linux on my gateway (largely for performance and software availabliliy) and the laptop I spend my whole life on, but sometimes little nagging issues in design are a bit too uncomfortable. I'll post some shit on some forums or Slashdot that will make me feel better and run a BSD for a few days then go back. Pathetic but what can you do? At least I'm not a sex crime offender. Trolling is a relatively harmless hobby.

      Meh, it ends here. Thanks for the coercion.

      --
      Sam ty sig.
    20. Re:Wow, that's a bit slow by setagllib · · Score: 1

      Yeah, Linux happens to be a flagship of open source these days, fair enough. If that keeps it in open testing then it's a Good Thing.

      Out of curiosity, what was the really awesome security framework Linux has OpenBSD can't touch? Or is it one of the out-of-tree jobs? I'm disappointed in Linus for not wanting to merge in grsecurity patches - the instability they cause is minimal (but I have had some..) and could be removed with some decent testing, but they bring Linux up to no less a level of proactive security than any given BSD. A code audit would finish the final few meters of distance. And since a LOT of people go to BSD just for security, that means they can stay with Linux and a sufficiently well-tested distribution.

      Well I'm sure it will happen eventually. Before that I'd still want to see a new packet filter. While iptables is pretty functional and not at all difficult to use, it could benefit from some syntax flexibility. You might be able to get away with writing just a new frontend, or a wrapper for the existing one. But sometimes you can write a one-line rule in *pf* that takes a dozen lines in iptables, especially where groups of addresses and interfaces and so on exist. If it wasn't for the multiport match it would be a real nightmare.

      --
      Sam ty sig.
    21. Re:Wow, that's a bit slow by setagllib · · Score: 1

      Well, pf's syntax is much more flexible, it has advanced features like packet normalisation ('scrubbing'), implicit antispoofing, packet filtering by OS fingerprint (which appears to be completely unique to pf), and is the first packet filter I know to log in pcap format which means you can watch with tcpdump and see the whole packet and analyse it. All of these are things that iptables could learn from and bring to a bigger audience. But it'd be better, at this stage, to just write a new filter entirely. Maybe I should look at that and make it my contribution to Linux.

      --
      Sam ty sig.
  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...
    1. Re:Robustness of Xen support by Lemming+Mark · · Score: 1

      [disclaimer: I'm a Xen developer]
      Xen 2.0 itself is pretty robust by now, plenty of people running it in production environment. The tools could do with some work but they are quite nice to use.

      I can't say I've played with the NetBSD port yet but NetBSD will have vested interest in making it work well, since they use Xen internally.

      You should also be able to boot virtual machines running Linux 2.4 / 2.6.

    2. Re:Robustness of Xen support by Anonymous Coward · · Score: 2, Informative

      That's exactly the point of Xen. As it says on the Xen page, each domain is a completely separate virtual machine. So no only are you "jailing" the web server application, your jailing the entire OS image that it is runnning on. In this way it's just like VMware. The difference is that by requiring some small changes to the guess OSes, Xen can avoid needing to trap and emulate any protected instructions which results in much better performance.

  3. So... by Anonymous Coward · · Score: 1, Interesting

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

    1. Re:So... by Stween · · Score: 4, Informative

      http://www.daemonnews.org/200104/bsd_family.html

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

    3. Re:So... by Qwerpafw · · Score: 3, Informative

      there's also Darwin, which is the BSD-core of Apple's Mac OS X. Darwin is Open Source, though Apple is pretty finnicky about who they let contribute for obvious reasons (it's the core of a commercial Operating System). There's also OpenDarwin which is basically a community controlled branch of Darwin that occasionally serves as a testbed for standard Darwin features. Darwin is based on a Mach 3.0 microkernel, though it's more of a hybrid than that simplistic description would suggest.

    4. Re:So... by aliquis · · Score: 2, Informative

      BSD/OS is commercial.

      FreeBSD _was_ performing very good on x86 hardware (only), FreeBSD 5.x is often slower on single-cpu machines because they try to improve SMP performance and functionality. 5.x supports quite a few architectures aswell.

      DragonFly is a fork of FreeBSD 4.x, better performance than FreeBSD 5.x but not for production (if you ask them), if I've understood everything correct their goal is among others fast IPC and beeing able to run the OS on a cluster. Right now they are going x86 only I think.

      NetBSD is about portability, clean code and correctness, earlier it was slower than FreeBSD but it has catched up a lot with 2.x.

      OpenBSD is a fork of NetBSD which centers about security, althought many people are sceptical.

      Personally I've got more and more tired of OpenBSD, really like NetBSD and are very intrested in what will become of DragonFly. If you just want something which works as a desktop FreeBSD might still be your best bet thought.

    5. Re:So... by SA+Stevens · · Score: 1

      The 2.0 release of NetBSD runs faster than NetBSD ever has in the past.

      In fact, it SCREAMS on my Quad-CPU intel machine. I still need to roll it out and evaluate it on my Quad-Sparc box.

    6. Re:So... by setagllib · · Score: 1

      FreeBSD 5.x is free but not very fast, and while this will improve over time, the bugginess and complexity in the meantime isn't worth it for most.

      NetBSD got much faster in 2.0. It can now compete with FreeBSD 4 in UP, and can run a not-bad SMP (if you know what you're doing, that is).

      OpenBSD is useful, because it doesn't stop you from running a text editor - in this case vi. That's a lot better than the 'default install' of a lot of Linux distributions I know.

      --
      Sam ty sig.
    7. Re:So... by Anonymous Coward · · Score: 1, Insightful

      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.

      Funny. I've been using OpenBSD since 2.5 and just recently started using NetBSD 2.0 quite heavily. NetBSD is fast. However it's documentation (user guide and man pages) are nowhere near as clean and complete as OpenBSD's.

      I have found myself checking OpenBSD man pages for hints that I just don't get from NetBSD man pages.

      If you sum OpenBSD's merits up to "Theo's ego", them you are a liar. It is a fantastic system. I also very much like NetBSD and think it is also a fantastic system, but please, don't piss on a great project just because you don't like the leader. Love him or hate him, he has done some great stuff for OSS.

    8. Re:So... by aliquis · · Score: 1

      Define "many". A comment like this could be made about ANYTHING. It is completely pointless. People will always have opinions and most will continue to be wrong.
      I have no idea, I just see the comments from people and webpages sometimes, I personally have to little knowledge to know if something is wrong/stupid or not. Part of it is probably because they brag so much about security and then it becomes more fun for some people when they fail.

      Maybe you became bored of OpenBSD because you couldn't figure out how to use it. I've been very happily using OpenBSD for desktops for years and I know many others have too.
      I've used OpenBSD as a desktop a long time ago aswell (and freebsd and netbsd), and used it for a server since 2.4 or 2.5. However back then I could remove i386-i586 support in the kernel and compile with -march=i686 -O2 without breaking anything, something which didn't worked with the latest versions. (That might be gccs fault and not OpenBSDs) Also at one time the machine crashed on me each time I tried to grep something from a lot of data (maybe it always does? Seems weird enough thought). The second issue might be fixed, the first issue isn't there if you compile for i386, however I also got a third issue with irssi since new versions requires some locale functionality which isn't there in OpenBSD.

      PS, it's although and though. Put a bit of thought into it will you.
      English isn't my native language so I don't care.

      Was there anything weird with the rest? I like all of the BSDs due to the amount of documentation easily available, why I like NetBSD a little more than the rest is because I find pkgsrc better than ports (but that's only my personal opinion and might be because I haven't looked into the deep of any of them). Benchmark tests HAVE found FreeBSD 5.2 to be slower than 4.x, and 5.3 even slower. SMP performance is probably improved thought, and they say the schedulers have been reworked to give better performance for the interface and things like playing movies/sound without any chopping(?). And DragonFly is intresting because whatever with new ideas are.

    9. Re:So... by DarthBart · · Score: 2, Informative

      You can use pkg_add on any supported NetBSD platform, assuming someone built a package. Otherwise, you'll have to download pkgsrc.tar.gz, untar it, and use "make && make install"

    10. Re:So... by aliquis · · Score: 1

      I know it's not recommended, however the comment section in the kernel config says "atleast one is needed", it doesn't say "remove old cpu support and it will break". I also know optimization doesn't do much different at all but often being able to is reason enough to do it.

      And also optimization can bring forward errors in bad hardware, so it's might not break on another machine.

      And anyway the locale part isn't there. So far NetBSD seem to run fine with march=athlon-tbird -O 2 -pipe.

  4. MOD PARENT UP! by Anonymous Coward · · Score: 1, Funny

    OMG! OMG! OMG! OMG! OMG! OMG! OMG! OMG!
    It's so FUNNY! So hillarious! Haha! Get it? Netcraft! Haha! They confirmed BSD being dead and it wasn't. Haha! It's so funny!

  5. BSD??? by PhotoGuy · · Score: 1, Funny

    But I thought....????

    -d

    --
    Love many, trust a few, do harm to none.
  6. 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.

  7. PAM support? by _pruegel_ · · Score: 1

    This Pam? What took the BSD guys so long?