NetBSD Status Report January - March 2005

← Back to Stories (view on slashdot.org)

NetBSD Status Report January - March 2005

Posted by Zonk on Saturday April 9, 2005 @09:53AM 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."

111 comments

Min score:

Reason:

Sort:

Re:BSD by gardyloo · 2005-04-09 10:02 · Score: 0, Offtopic

Easy.

"Nigel!"
"Yessir!"
"Give us the state of NetBSD."
"Same as last year, sir. We're re-re-re-reconfirming it."
Wow, that's a bit slow by vadim_t · 2005-04-09 10:07 · 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 · 2005-04-09 10:16 · 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 · 2005-04-09 10:31 · 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 · 2005-04-09 11:03 · 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 · 2005-04-09 11:08 · 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 · 2005-04-09 11:09 · 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 Anonymous Coward · 2005-04-09 12:35 · Score: 0
  
  Complicated ? Have you looked at the damn thing. UGH. Not to mention running the authentication IN THE SAME ADDRESS SPACE as the application. UGH again. Leads to silly things like making servers need access to e.g. /etc/shadow etc.
7. Re:Wow, that's a bit slow by vadim_t · 2005-04-09 12:51 · 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.
8. Re:Wow, that's a bit slow by Anonymous Coward · 2005-04-09 13:14 · Score: 0
  
  FreeBSD would welcome you.
9. Re:Wow, that's a bit slow by Anonymous Coward · 2005-04-09 13:24 · Score: 0
  
  PAM PAM
  PAM PAM
  PAMela PAMela
  Fuck Fuck You!
10. Re:Wow, that's a bit slow by SA+Stevens · 2005-04-09 14:11 · 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?
11. Re:Wow, that's a bit slow by Brandybuck · 2005-04-09 14:38 · 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!
12. Re:Wow, that's a bit slow by setagllib · 2005-04-09 15:14 · 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.
13. Re:Wow, that's a bit slow by setagllib · 2005-04-09 15:24 · 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.
14. Re:Wow, that's a bit slow by Anonymous Coward · 2005-04-09 15:28 · Score: 0
  
  NetBSD isn't steered by Wasabi. They maintain their own tree, and while some NetBSD developers happen to work for them, there is a clear separation.
  
  Wasabi is more than capable of doing their own work. They need not, do not, and cannot control the open NetBSD project.
15. Re:Wow, that's a bit slow by Anonymous Coward · 2005-04-09 16:31 · Score: 0
  
  Computers age in dog years. LFS-4.0 is from a year or two ago, so that'd be the equivalent of seven to 14 years if we were talking cars (if you accept the premise of computers aging in dog years (and if you accept the dog-to-real years conversion (Lisp rules!))).
  
  At any rate, LFS-4.0 is old news. LFS-5 is already out of date (uses early 2.6 kernels), and LFS-6 has been recently released. PAM has been around since before LFS-4, and its uptake has been quite slow among anyone without a big team or lots of money to get it in.
16. Re:Wow, that's a bit slow by Anonymous Coward · 2005-04-09 17:37 · 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?
17. Re:Wow, that's a bit slow by Anonymous Coward · 2005-04-09 18:31 · Score: 0
  
  FreeBSD fork? The only FreeBSD fork is DragonFlyBSD. What are you talking about? Yes, portability hasn't been FreeBSD's primary goal. Everyone knows that though.
  
  I'm just trying to figure out your point. I think I got it though, but I'm not sure. Maybe you want to be more clear?
18. Re:Wow, that's a bit slow by Anonymous Coward · 2005-04-09 19:24 · Score: 0
  
  No, we are not talking cars. At least I'm not, are you?
  
  What do talking cars have anything to do with it anyway? Are you a talking car that's running LFS? Cool.
19. Re:Wow, that's a bit slow by Guy+Harris · 2005-04-09 19:28 · 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".)
20. Re:Wow, that's a bit slow by Anonymous Coward · 2005-04-09 20:58 · Score: 0
  
  What We Can Learn From BSD
  By Chinese Karma Whore, Version 1.0
  
  Everyone knows about BSD's failure and imminent demise. As we pore over the history of BSD, we'll uncover a story of fatal mistakes, poor priorities, and personal rivalry, and we'll learn what mistakes to avoid so as to save Linux from a similarly grisly fate.
  
  Let's not be overly morbid and give BSD credit for its early successes. In the 1970s, Ken Thompson and Bill Joy both made significant contributions to the computing world on the BSD platform. In the 80s, DARPA saw BSD as the premiere open platform, and, after initial successes with the 4.1BSD product, gave the BSD company a 2 year contract.
  
  These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents on his website. Mr. de Raadt's stubborn arrogance was later seen in his clash with Darren Reed, which resulted in the expulsion of IPF from the OpenBSD distribution.
  
  As personal rivalries took precedence over a quality product, BSD's codebase became worse and worse. As we all know, incompatibilities between each BSD distribution make code sharing an arduous task. Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.
  
  Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the goodwill of open-source. Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.
  
  The failure of BSD culminated in the resignation of Jordan Hubbard and Michael Smith from the FreeBSD core team. They both believed that FreeBSD had long lost its earlier vitality. Like an empire in decline, BSD had become bureaucratic and stagnant. As Linux gains more and more market share, and as BSD sinks deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.
21. Re:Wow, that's a bit slow by Anonymous Coward · 2005-04-09 21:14 · Score: 0
  
  NetBSD loses out to Oracle, SAP, ERP, and DB2 in commercial settings. Additionally NetBSD lacks 24/7 support backed by Fortune 500 companies. NetBSD is hampered by poor scalability and its limited rudimentary SMP. NetBSD also lacks a production ready journaling file system. NetBSD lacks the latest and greatest Java environment. In fact there is no official Java support for NetBSD. NetBSD lacks professional developement tools and compilers supported by industry leaders. In short, NetBSD looks like yesterday's fish wrap when you compare it to enterprise ready systems.
22. Re:Wow, that's a bit slow by Anonymous Coward · 2005-04-09 21:22 · Score: 0
  
  When we think about FreeBSD, we are immediately
  reminded of DeForest Kelley's prescient observation:
  It's dead, Jim.
23. Re:Wow, that's a bit slow by Anonymous Coward · 2005-04-09 23:49 · Score: 0
  
  In my experience, NetBSD's UBC does not increase performance vs OpenBSD in any realworld situations.
24. Re:Wow, that's a bit slow by Anonymous Coward · 2005-04-09 23:53 · Score: 0
  
  There are two "problems" with the adoption. One is the usual Not Invented Here syndrome which has been partly fixed by re-implementing everything with new and exciting bugs to avoid the known and boring bugs in LinuxPAM.
  
  The other is that PAM is a complex system, and rule 101 in security is to keep things simple. Unfortunately that should read "simple _enough_ but no simpler", the previous NetBSD authentication scheme was not powerful enough, and NetBSD's core team knew it. People who could get Linux integrated into their corporate network with a minimum of fuss were discovering that NetBSD expected them to apply unofficial 3rd party patches to key security software to get the same effect. Not going to happen.
  
  I think PAM is a big improvement over other schemes I've seen, and hopefully NetBSD's developers can feed further improvements back to other PAM developers so that everyone benefits.
25. Re:Wow, that's a bit slow by Anonymous Coward · 2005-04-10 00:00 · Score: 0
  
  PAM is the only way I can configure my servers to authenticate to an ADS DC and allow authentication for local users. I could add NIS authentication as well if I needed it. I can do this on an application by application basis, so my Subversion users can't log in via. Telnet but the Unix developers who are using CVS can log in with SSH and run the various CVS maintainance scripts they need.
  
  I'd like to see authentication like that done without PAM. I'd expect the term "steaming pile" to apply somewhere, and I don't think it would be for PAM somehow.
26. Re:Wow, that's a bit slow by Morth · 2005-04-10 00:42 · 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.
27. Re:Wow, that's a bit slow by Anonymous Coward · 2005-04-10 01:34 · 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?
28. Re:Wow, that's a bit slow by Anonymous Coward · 2005-04-10 11:51 · Score: 0
  
  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.
  
  Sorry, no NetBSD has fundamental problems on anything more than a toy system. Even this so called "big-memory" system is too much for NetBSD's immature memory manager to handle.
  
  But what's the deal with calling that "big-memory"? Maybe for your desktop machine (but in a couple of years it won't be). But for a server? It's amusingly puny. Linux runs fine on machines with 4 - 8 TB of memory.
  
  Oh, and what's this? It doesn't even have basic
  realtime scheduling! This is an OS that claims it is good for embedded systems!
  
  It has terrible database performance, even after a multitude of hacks from this kernel developer.
  
  It can't even handle basic SMP CPU topologies like hyperthreading properly. But that's not surprising considering the kernel is completely serialised under a single lock, so why bother making the scheduler any better on multiprocessor systems?
  
  Thanks, but no thanks. If Linux is broken, then NetBSD is a steaming pile.
29. Re:Wow, that's a bit slow by setagllib · 2005-04-10 17:18 · 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.
30. Re:Wow, that's a bit slow by Anonymous Coward · 2005-04-10 19:00 · Score: 0
  
  It sounds like you either did not set something up right - maybe something wrong with your firewall settings (you retarded BSD zealots are always whining about how the syntax is too much for your small brains), or you are just lying because you are a troll.
  
  There are a *lot* of people using IPSec on Linux, including me. "On certain protocols it would just drop packets" just sounds like a vague copout for "I haven't actually tested it and I don't know whether there are any bugs, but this sounds like it's plausible".
  
  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.
  
  Sorry, if you think *any* general purpose UNIX operating system is without bugs, then you are seriously mistaken. You obvously have no idea about software development and release engineering process.
  
  No bugs, eh? What about this,
  this,
  this,
  this,
  
  etc. for example, one can easily go to the NetBSD bug database, and find over 700 open bugs marked as high severity and high importance filed against the kernel alone. Many of those are for 1.4, 1.5, 1.6, as well as current.
  
  And, oh dear!! Lo and behold, there are a handful of IPSec bugs in there.
  
  I hope that shuts you up, you stupid driveling idiot.
31. Re:Wow, that's a bit slow by Anonymous Coward · 2005-04-10 22:06 · 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.
32. Re:Wow, that's a bit slow by Anonymous Coward · 2005-04-10 23:11 · Score: 0
  
  NetBSD is hampered by poor scalability and its limited rudimentary SMP.
  
  SMP, yes at the moment. But Uni proc scalability? I don't think so. This looks interesting too.
  
  NetBSD also lacks a production ready journaling file system.
  
  With Soft Updates, it doesn't need it.
33. Re:Wow, that's a bit slow by Anonymous Coward · 2005-04-11 00:08 · Score: 0
  
  SMP, yes at the moment.
  
  That's what we're talking about. That's by far the harder of the two to get right.
  
  But Uni proc scalability? I don't think so. This looks interesting too.
  
  Well that's not too bad. You couldn't expect much worse from a modern general purpose UNIX operating system, though. Still has a few disappointing O(n) results. Ooh, thread creation in the second link has a non-linear component too, looks like around O(n^2). That's not so good.
  
  With Soft Updates, it doesn't need it.
  
  Actually, it kind of does. Ever wonder why no enterprise ready UNIX (or NT, if that impresses you) uses a similar sort of scheme? Wonder why Wasabi systems created their own proprietary journalling fs? Why DragonflyBSD wants to implement a journalling FS? Why other various BSD people are looking at porting XFS or Reiserfs? It is because softupdates aren't actually a really good substitute.
  
  Yes, despite the propaganda.
  
  They enforce write ordering constraints similar to a journalling fs, however unlike a journalling filesystem SU cannot write the constrained data to a nice linear journal (which is the reason journalling filesystems can actually *outperform* non journalling, non SU, asynch filesystems in some metadata intensive workloads).
  
  SU cannot do anything more advanced like data journalling, could never be extended to support atomic syscall semantics, let alone a full acquire/release transaction model (see Reiser4).
  
  Journalling filesystems can do data+metadata journalling to fast non-volatile storage (eg. battery backed DRAM) while the volume runs on large, slower storage (ie. magnetic disks), with no loss of integrity semantics. SU cannot do that.
  
  SU background fsck is not considered to be a very good solution to the recovery problem. At least not the FreeBSD implementation that I have used, and seen others use (not sure about netbsd).
34. Re:Wow, that's a bit slow by overbom · 2005-04-12 10:22 · 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
35. Re:Wow, that's a bit slow by setagllib · 2005-04-17 17:39 · 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.
36. Re:Wow, that's a bit slow by Anonymous Coward · 2005-04-17 23:35 · Score: 0
  
  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.
  
  Well I use POP3 and HTTP over ipsec and it is fine. So it is likely that you are doing something wrong.
  
  Where is your bug report?
  
  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.
  
  You really have no idea about software development, do you? You honestly think BSDs have no bugs? You are a sad, stupid idiot.
  
  I've looked up your posting history and you are a stupid trolling idiot who wouldn't know a kernel if it kicked him up the anus. You consistently say stupid and incorrect things and try to pass them off as fact. I'm having nothing more to do with the likes of you.
  
  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.."
  
  A BSD advocate I know recently said (quote) "First thing that comes to mind for me is that Linux happens to beat all the BSDs at their own game. It is faster and far more scalable than FreeBSD, it is more portable than NetBSD, and it has advanced security infrastructure that OpenBSD can't match."
  
  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...
  
  Err, actually if you had any idea you would know that they do plenty of quality assurance and follow a good release process. Just because it doesn't exactly match what you small minded BSD zealots are used to, doesn't mean it is wrong. The various BSDs are far more comparable to Linux distributions than the Linux kernel itself.
37. Re:Wow, that's a bit slow by setagllib · 2005-04-18 01:04 · 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.
38. Re:Wow, that's a bit slow by Anonymous Coward · 2005-04-18 20:41 · Score: 0
  
  OK, well yes I admit I have been too harsh. I could believe you hitting an IPSec bug - or a bug _anywhere_ in Linux, it is not perfect.
  
  I am actually a Linux guy (who would have guessed), and I simply don't like some of the unfair comparisons made against it. So I usually try to correct such posts if I know they've made factual errors, or at least query for more information if it is an open ended bashing.
  
  Now I don't think that Linux is ahead of any BSD in all aspects. I think it is ahead of all of them in many (note, I didn't say most). And that is not surprising given its developer base and commitment (the latter of which is owing a great deal to corporate interest in Linux, of course).
  
  But I like the BSDs. They keep Linux honest, they come up with good and different ideas which Linux can use (and vice versa). They are better in some areas, they appeal to different people and have difference licenses.
  
  A BSD quitting now would be like Linux quitting a few years ago when it was looked down upon by NT and UNIXes (well to some extent it still is ;)).
  
  What's more, Linux development *helps* BSD too. Most Linux apps can run on BSD through the linux layer, and open source apps can usually be trivially ported. Linux expertise is more easily translated to a BSD than NT expertise is. Linux acceptance by companies can only help BSD acceptance, etc etc.
39. Re:Wow, that's a bit slow by setagllib · 2005-04-18 21:46 · 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.
40. Re:Wow, that's a bit slow by Anonymous Coward · 2005-04-19 17:39 · Score: 0
  
  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?
  
  The SELinux patches provide a pretty comprehensive and flexible security framework. Linux filesystems also support extended attributes and acls (although OpenBSD probably does too by now?).
  
  So it is not something that makes Linux untouchable, but it is something that enables it to operate in some deployments that it otherwise couldn't.
  
  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 Linux (at least the kernel, which is what I'm familiar with) does have code audits. I know at least IBM and RedHat do security audits on the kernel. There are things like the stanford checker (now called something else) which regularly get run on the kernel source. Probably others as well, eg. SUSE, OSDL, NSA.
  
  Application wise I imagine it is probably not as thorough generally - although in some cases it is is probably very high (apache, other http, mail, DNS, etc servers).
  
  Well I'm sure it will happen eventually. Before that I'd still want to see a new packet filter.
  
  Well I haven't used either to do much serious work, so I can't comment.
  
  You hear a lot about how much better pf is than iptables - mostly from BSD people of course. I guess there is probably at least a grain of truth in it.
41. Re:Wow, that's a bit slow by setagllib · 2005-04-19 18:03 · 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.
The next person who says "Netcraft" is dead meat-- by Anonymous Coward · 2005-04-09 10:10 · Score: 0, Insightful

arrgh, it's flamebait no matter what I say.
Re:easy come, easy goo, all for just a 1$? WTF? by killawatt5k · 2005-04-09 10:10 · Score: 0, Offtopic

WTF is wrong w/ the parent? nice sig! HA
Re:FP by Anonymous Coward · 2005-04-09 10:14 · Score: 0

TCP/SACK

Ti-hi-hi
Re:The next person who says "Netcraft" is dead mea by Anonymous Coward · 2005-04-09 10:16 · Score: 0

NETCRAFT!

I like my [i]dead[/i] meat, medium rare.
End of the report by The+Amazing+Fish+Boy · 2005-04-09 10:16 · Score: 0

... and so, as you can see, BSD is on it's way to being legendary -- AUUUUUUUUUUUUGGGGGGGHHHHHHH!
Re:An observation... by malraid · 2005-04-09 10:26 · Score: 0, Offtopic

3. The previous 2 points are COMPLETLY hypotetical due to lack of ANY real evidence of such events

--
please excuse my apathy
Re:An observation... by Anonymous Coward · 2005-04-09 10:28 · Score: 0

Nonsense. He has firsthand experience.
BSD Status Report... by Anonymous Coward · 2005-04-09 10:30 · Score: 0

I refuse to believe any BSD status report without a Netcraft link confirming its accuracy.
1. Re:BSD Status Report... by Anonymous Coward · 2005-04-09 20:54 · Score: 0
  
  It is official. Netcraft now confirms: *BSD is dying
  One more crippling bombshell hit the already beleaguered *BSD community when IDC confirmed that *BSD market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.
  
  You don't need to be the Amazing Kreskin to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood.
  
  FreeBSD is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: FreeBSD is dying.
  
  Let's keep to the facts and look at the numbers.
  
  OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.
  
  Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.
  
  All major surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a miracle could save *BSD at this point in time. For all practical purposes, *BSD is dead.
  
  Fact: *BSD is dying
Robustness of Xen support by LaughingLinuxMan · 2005-04-09 10:40 · 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 · 2005-04-09 11:22 · 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 · 2005-04-09 11:26 · 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. Re:Robustness of Xen support by Anonymous Coward · 2005-04-09 12:20 · Score: 0
  
  Another conservative successfully annoyed! Five points for Gryffindor!
Re:The next person who says "Netcraft" is dead mea by Anonymous Coward · 2005-04-09 10:47 · Score: 0

you mean:
I like my [i]dead[/i] meat, medium rare.
So... by Anonymous Coward · 2005-04-09 10:54 · Score: 1, Interesting

...what are the differences between the various BSDs, out of curiosity?
1. Re:So... by Anonymous Coward · 2005-04-09 11:02 · Score: 0
  
  In short..
  
  FreeBSD is free and very fast.
  
  NetBSD is free too, but doesn't run that fast. However it runs pretty much anything with a CPU and enough memory. Yes, your toaster will run NetBSD.
  
  OpenBSD? Well known for its security. A default install is not vulnerable, but on the other hand, a default install is rather useless..
2. Re:So... by Stween · 2005-04-09 11:05 · Score: 4, Informative
  
  http://www.daemonnews.org/200104/bsd_family.html
3. Re:So... by DarthBart · 2005-04-09 11:05 · 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. Re:So... by DarthBart · 2005-04-09 11:08 · Score: 0, Offtopic
  
  Sigh. I must learn to use preview.
5. Re:So... by Anonymous Coward · 2005-04-09 11:20 · Score: 0
  
  I'm in the market for a new toaster, could you recommend a NetBSD or FreeBSD compatible toaster? Prescotts aside.
6. Re:So... by Qwerpafw · 2005-04-09 11:29 · 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.
7. Re:So... by aliquis · 2005-04-09 12:00 · 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.
8. Re:So... by SA+Stevens · 2005-04-09 14:20 · 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.
9. Re:So... by setagllib · 2005-04-09 15:29 · 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.
10. Re:So... by Anonymous Coward · 2005-04-09 15:58 · Score: 0
  
  I'm with you on OpenBSD. OpenBSD tries so hard to be secure, which is an excellent goal, but they forget that to be useful a machine has to do something other than just sit there. And the doing something usually entails another application whose developers are not as interested in security. Extreme levels of security and code review look great on paper, but in real life people will sacrifice a little security for things like SMP support. :-)
11. Re:So... by Anonymous Coward · 2005-04-09 16:01 · Score: 0
  
  I'm a Linux user, what is this 'vi' you speak of?
  
  PICO FOREVER!
12. Re:So... by Anonymous Coward · 2005-04-09 17:48 · 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.
13. Re:So... by Anonymous Coward · 2005-04-09 17:59 · Score: 0
  
  althought many people are sceptical.
  
  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.
  
  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.
  
  More mindless drivel from the great minds on slashdot.
  
  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.
  
  PS, it's although and though. Put a bit of thought into it will you.
14. Re:So... by Anonymous Coward · 2005-04-09 18:09 · Score: 0
  
  OpenBSD tries so hard to be secure, which is an excellent goal, but they forget that to be useful a machine has to do something other than just sit there. And the doing something usually entails another application whose developers are not as interested in security.
  
  OpenBSD has active security mechanisms which assist even applications which are not compiled for those mechanisms. Most vulnerabilities which expose root on other systems, merely cause a DoS on OpenBSD. That's a pretty big deal if you ask me.
  
  OpenBSD does come installed with hardened http, ftp, smtp, pop3, ssh, etc daemons ready to be enabled. It's hardly useless and certainly a very secure platform to serve from.
15. Re:So... by aliquis · 2005-04-09 20:33 · 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.
16. Re:So... by dotslashdot · 2005-04-09 20:36 · Score: 0
  
  Can you use pkg_add under NetBSD or do you have to compile everything from scratch for the x86 platform?
17. Re:So... by Anonymous Coward · 2005-04-09 21:01 · Score: 0
  What I know about FreeBSD,
  
  You can not play games on it.
  
  It cannot be used by my grandma.
  
  It lacks a GUI of any note.
  
  There is no support available for it.
  
  It is an assortment of fragmented OSes.
  
  It cannot be run on the x86 platform.
  
  You have to compile everything and know C.
  
  Support for the latest hardware is always poor.
  
  It is incompatiable with GNU/Linux.
  
  FreeBSD is dying.
18. Re:So... by Anonymous Coward · 2005-04-09 21:24 · Score: 0
  
  When we think about BSD, we are immediately
  reminded of DeForest Kelley's prescient observation:
  It's dead, Jim.
19. Re:So... by Anonymous Coward · 2005-04-10 02:28 · Score: 0
  
  It seems to me you didn't bother reading the documentation
20. Re:So... by DarthBart · 2005-04-10 02:45 · 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"
21. Re:So... by aliquis · 2005-04-10 04:27 · 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.
MOD PARENT UP! by Anonymous Coward · 2005-04-09 11:05 · 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!
BSD??? by PhotoGuy · 2005-04-09 12:07 · Score: 1, Funny

But I thought....????

-d

--
Love many, trust a few, do harm to none.
News flash by Jacer · 2005-04-09 12:15 · Score: 0

It's dead. We...Think?

--
--fetch daddy's blue fright wig, i must be handsome when i release my rage
ok i'll bite... by torrents · 2005-04-09 12:46 · Score: 0

in soviet russia bsd confirms your death...

--
Get your torrents...
Sorry, I'm trolling... by pp · 2005-04-09 13:24 · 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.
1. Re:Sorry, I'm trolling... by Anonymous Coward · 2005-04-09 15:36 · Score: 0
  
  Actually, NetBSD did hold one or two of the performance records for a couple of months, but have since been demolished by Linux, which has held all records since late last year.
  
  It would be surprising to see NetBSD regain any of the records any time soon, due to the inability of their network stack to scale to multiple CPUs.
waah by Anonymous Coward · 2005-04-09 14:13 · Score: 0

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

So fork it and do better.
Re:Developer Laments: What Killed FreeBSD by Anonymous Coward · 2005-04-09 18:18 · Score: 0

shut up, fuck it and fork it.
Obligatory by Anonymous Coward · 2005-04-09 20:13 · Score: 0
1. Post 'Netcraft confirms ....'
2. Fail to get any mod points, either Troll or interesting or funny
3. This confirms no-one is moderating this thread
4. This in term confirms BSD is dying
5. ????
6. Profit!!!
Re:BSD by Anonymous Coward · 2005-04-09 21:04 · Score: 0

It is now official. Netcraft has confirmed: *BSD is dying
One more crippling bombshell hit the already beleaguered *BSD community when IDC confirmed that *BSD market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.

You don't need to be the Amazing Kreskin to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood.

FreeBSD is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: FreeBSD is dying.

Let's keep to the facts and look at the numbers.

OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.

Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.

All major surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a miracle could save this dying OS at this point in time. For all practical purposes, *BSD is dead.

Fact: *BSD is dying
Re:The next person who says "Netcraft" is dead mea by Anonymous Coward · 2005-04-09 21:17 · Score: 0

It is official. Netcraft has confirmed: *BSD is dying
One more crippling bombshell hit the already beleaguered *BSD community when IDC confirmed that *BSD market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.

You don't need to be the Amazing Kreskin to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood.

FreeBSD is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: FreeBSD is dying.

Let's keep to the facts and look at the numbers.

OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.

Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.

All major surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a miracle could save this pitiful OS at this late date. For all practical purposes, *BSD is dead.

Fact: *BSD is dying
For Whom The Bell Tolls by Anonymous Coward · 2005-04-09 21:20 · Score: 0

Elegy For *BSD

I am a *BSD user
and I try hard to be brave
That is a tall order
*BSD's foot is in the grave.

I tap at my toy keyboard
and whistle a happy tune
but keeping happy's so hard,
*BSD died so soon.

Each day I wake and softly sob
Nightfall finds me crying
Not only am I a zit faced slob
but *BSD is dying.
PAM support? by _pruegel_ · 2005-04-10 01:04 · Score: 1

This Pam? What took the BSD guys so long?
Requiem for the Requiem by Anonymous Coward · 2005-04-10 06:28 · Score: 0

Yet another sickening blow has struck what's left of the *BSD community, as a soon-to-be-released report by the independent Commision for Technology Management (CTM) after a year-long study has concluded: *BSD is already dead. Here are some of the commission's findings:

Fact: the *BSDs have balkanized yet again. There are now no less than twelve separate, competing *BSD projects, each of which has introduced fundamental incompatibilities with the other *BSDs, and frequently with Unix standards. Average number of developers in each project: fewer than five. Average number of users per project: there are no definitive numbers, but reports show that all projects are on the decline.

Fact: X.org will not include support *BSD. The newly formed group believes that the *BSDs have strayed too far from Unix standards and have become too difficult to support along with Linux and Solaris x86. "It's too much trouble," said one anonymous developer. "If they want to make their own standards, let them doing the porting for us."

Fact: DragonflyBSD, yet another offshoot of the beleaguered FreeBSD "project", is already collapsing under the weight of internal power struggles and in-fighting. "They haven't done a single decent release," notes Mark Baron, an industry watcher and columnist. "Their mailing lists read like an online version of a Jerry Springer episode, complete with food fights, swearing, name-calling, and chair-throwing." Netcraft reports that DragonflyBSD is run on exactly 0% of internet servers.

Fact: There are almost no FreeBSD developers left, and its use, according to Netcraft, is down to a sadly crippled .005% of internet servers. A recent attempt at a face-to-face summit in Boulder, Colorado culminated in an out-and-out fistfight between core developers, reportedly over code commenting formats (tabs vs. spaces). Hotel security guards broke up the melee and banned the participants from the hotel. Two of the developers were hospitalized, and one continues to have his jaw wired shut.

Fact: NetBSD, which claims to focus on portability (whatever that is supposed to mean), is slow, and cannot take advantage of multiple CPUs. "That about drove the last nail in the coffin for BSD use here," said Michael Curry, CTO of Amazon.com. "We took our NetBSD boxes out to the backyard and shot them in the head. We're much happier running Linux."

Fact: *BSD has no support from the media. Number of Linux magazines available at bookstores: 5 (Linux Journal, Linux World, Linux Developer, Linux Format, Linux User). Number of available *BSD magazines: 0. Current count of Linux-oriented technical books: 1071. Current count of *BSD books: 6.

Fact: Many user-level applications will no longer work under *BSD, and no one is working to change this. The GIMP, a Photoshop-like application, has not worked at all under *BSD since version 1.1 (sorry, too much trouble for such a small base, developers have said). OpenOffice, a Microsoft Office clone, has never worked under *BSD and never will. ("Why would we bother?" said developer Steven Andrews, an OpenOffice team lead.)

Fact: servers running OpenBSD, which claims to focus on security, are frequently compromised. According to Jim Markham, editor of the online security forum SecurityWatch, the few OpenBSD servers that exist on the internet have become a joke among the hacker community. "They make a game out of it," he says. "(OpenBSD leader) Theo [de Raadt] will scramble to make a new patch to fix one problem, and they've already compromised a bunch of boxes with a different exploit."

With these incontroverible facts staring (what's left of) the *BSD community in the face, they can only draw one conclusion: *BSD is already dead.
So What by Anonymous Coward · 2005-04-10 06:37 · Score: 0

IT IS OFFICIAL; WIRED NEWS CONFIRMS: LINUX IS SUPERIOR TO *BSD
*BSD is Dying, Says Respected Journal

Linux advocates have long insisted that open-source development results in better and more secure software. Now they have statistics to back up their claims.

According to a four-year analysis of the 5.7 million lines of Linux source code conducted by five Stanford University computer science researchers, the Linux kernel programming code is better and more secure than the programming code of *BSD.

The report, set to be released on Tuesday, states that the 2.6 Linux production kernel, shipped with software from Red Hat, Novell and other major Linux software vendors, contains 985 bugs in 5.7 million lines of code, well below the average for *BSD software. NetBSD, by comparison, contains about 40 million lines of code, with new bugs found on a frequent basis.

*BSD software typically has 20 to 30 bugs for every 1,000 lines of code, according to Carnegie Mellon University's CyLab Sustainable Computing Consortium. This would be equivalent to 114,000 to 171,000 bugs in 5.7 million lines of code.

The study identified 0.17 bugs per 1,000 lines of code in the Linux kernel. Of the 985 bugs identified, 627 were in critical parts of the kernel. Another 569 could cause a system crash, 100 were security holes, and 33 of the bugs could result in less-than-optimal system performance.

Seth Hallem, CEO of Coverity, a provider of source-code analysis, noted that the majority of the bugs documented in the study have already been fixed by members of the Linux development community.

"Our findings show that Linux contains an extremely low defect rate and is evidence of the strong security of Linux," said Hallem. "Many security holes in software are the result of software bugs that can be eliminated with good programming processes. But NetBSD's developers don't follow these processes, which is why we can safely predict that the project is dying."

The Linux source-code analysis project started in 2000 at the Stanford University Computer Science Research Center as part of a large research initiative to improve core software engineering processes in the software industry.

The initiative now continues at Coverity, a software engineering startup that now employs the five researchers who conducted the study. Coverity said it intends to start providing Linux bug analysis reports on a regular basis and will make a summary of the results freely available to the Linux development community.

"This is a benefit to the Linux development community, and we appreciate Coverity's efforts to help us improve the security and stability of Linux," said Andrew Morton, lead Linux kernel maintainer. Morton said developers have already addressed the top-priority bugs uncovered in the study.
NetBSD and SMP and other advanced features by Anonymous Coward · 2005-04-10 15:07 · Score: 0

So NetBSD took its time and finally integrated PAM (OpenPAM in this case) and a hue and cry arose.

It was still a very quick merge compared to the continous saga of SMP. People can say lots of nice things about NetBSD and compare it to the messiness of FreeBSD but FreeBSD (and DragonFlyBSD) have better SMP support than NetBSD.

What is the status of NetBSD's SMP support, support for ACLs, MAC, (i.e. TrustedBSD features), UFS2, etc.
Yay! by Anonymous Coward · 2005-04-10 20:59 · Score: 0

Long live NetBSD!
FUD for the FUD by Anonymous Coward · 2005-04-12 02:30 · Score: 0

BLBLBLBLBLARGGLALALBLABLALBLHLHLBLBLHFLBHG.

asdfl;kjasdfl;aksdjfl;kasdjfl;kasdjffdsjkl;asdf