NetBSD Status Report January - March 2005 111
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."
Re:BSD (Score:1, Offtopic)
"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 (Score:2, Interesting)
Just curious, have there been problems with the adoption of PAM, or it just wasn't a priority?
Re:Wow, that's a bit slow (Score:4, Interesting)
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).
Re:Wow, that's a bit slow (Score:1)
So which is it? LFS-4.0 is current events.
Re:Wow, that's a bit slow (Score:2)
I've setup linux pam on NetBSD, and it works okay (for LDAP auth).
Re:Wow, that's a bit slow (Score:1)
Re:Wow, that's a bit slow (Score:5, Interesting)
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.
Re:Wow, that's a bit slow (Score:2, Insightful)
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
Re:Wow, that's a bit slow (Score:3, Interesting)
I think you misunderstood the closed source part. It was about corporations pressuring to be able
Re:Wow, that's a bit slow (Score:1)
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 s
Re:Wow, that's a bit slow (Score:2)
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
Re:Wow, that's a bit slow (Score:1, Interesting)
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?
Re:Wow, that's a bit slow (Score:2)
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 c
Re:Wow, that's a bit slow (Score:2)
When you show me a BSD exposing a significant security hole (like the Linux signal exploit) or b
Re:Wow, that's a bit slow (Score:2)
Although it would still be nice to have this worked out. In the meantime I've
Re:Wow, that's a bit slow (Score:2)
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 sec
Re:Wow, that's a bit slow (Score:2)
Re:Wow, that's a bit slow (Score:3, Interesting)
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
Re:Wow, that's a bit slow (Score:1, Interesting)
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 o
Re:Wow, that's a bit slow (Score:2)
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.
Re:Wow, that's a bit slow (Score:2, Informative)
Now, if we were talking about network authentication with decent SSL or oth
Re:Wow, that's a bit slow (Score:3, Informative)
Socket traffic between processes on the same machine doesn't have to go over the loopback interface.
(Hint: "UNIX-domain sockets".)
Re:Wow, that's a bit slow (Score:1)
hth
MOD PARENT UP! (Score:1, Funny)
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!
Robustness of Xen support (Score:3, Interesting)
Re:Robustness of Xen support (Score:1)
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.
Re:Robustness of Xen support (Score:2, Informative)
So... (Score:1, Interesting)
Re:So... (Score:1)
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.
Re:So... (Score:2)
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.
Re:So... (Score:5, Informative)
Re:So... (Score:5, Interesting)
Re:So... (Score:1, Offtopic)
Re:So... (Score:1, Insightful)
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 yo
Re:So... (Score:3, Informative)
Re:So... (Score:3, Informative)
Re:So... (Score:2, Informative)
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 th
Re:So... (Score:1)
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 ou
Re:So... (Score:1)
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.
BSD??? (Score:2, Funny)
-d
News flash (Score:1)
Sorry, I'm trolling... (Score:2, Interesting)
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 pe
PAM support? (Score:1)
Re:An observation... (Score:1, Offtopic)