NetBSD Goodies: 2.0 RC1 Tagged, New pkgsrc Branch

jschauma writes "The NetBSD Releng Team has announced that the first Release Candidate for NetBSD 2.0 (ie NetBSD-2.0_RC1) has been tagged. This is a major milestone in the much anticipated release of NetBSD 2.0: from now on, any pullups must address some form of show-stopping issue to even be considered. The NetBSD Project encourages all users to test the binary snapshots that will soon be available on the release engineering ftp server. If no pullups are necessary, then the 2.0 release should occur around the middle of October. Any fixes resulting in pullups will cause a second RC cycle to begin and add approximately 1-2 weeks more to the timeline." Further, "The NetBSD Packages team announced that a new pkgsrc-2004Q3 branch was created, and the freeze on committing to the pkgsrc trunk is now over. This branch, which includes a total of 4959 actively-maintained and supported packages, deprecates the last stable pkgsrc branch (pkgsrc-2004Q2); all maintenance will take place on this new pkgsrc-2004Q3 branch. Please see our online documentation of the NetBSD Packages Collection for details."

Comments

Cool!

[torstenvl]

I'll be really interested to see what NetBSD 2.0 is like. It seems like FreeBSD gets all of the attention (and all of the user base); I myself use FreeBSD on my laptop. However, there are some benchmarks that place NetBSD above FreeBSD, and you certainly can't beat the hardware support! Imagine... I could put it on my SPARC and be in the exact same environment as I have on my x86 laptop!

Re:Cool!

[Shanep]

I could put it on my SPARC and be in the exact same environment as I have on my x86 laptop!

I have not used NetBSD much. I mostly use OpenBSD.

So keep that in mind when I say...

I hear a lot of people say that the user experience across architectures varies a lot with NetBSD. Even between popular archs like x86, macppc and sparc64.

I use OpenBSD on those and find it very familiar on each, including the use of X.

I can't wait for NetBSD 2.0 though.

Re:Cool!

[LizardKing]

I hear a lot of people say that the user experience across architectures varies a lot with NetBSD. Even between popular archs like x86, macppc and sparc64.

That's peculiar, as one of NetBSD's strengths is the consistency across platforms. I use it on machines as diverse as a VaxStation VLC, SparcStation 5 and a Dell laptop - the installation, configuration and use of NetBSD on all of them is identical. Of course, I wont be running Mozilla on the Vax, but it makes a great little webserver.

Re:Cool!

[Shanep]

That's peculiar, as one of NetBSD's strengths is the consistency across platforms.

Yes, that is what I thought prior to hearing the opposite. I'm too busy to back it up with any links, so I hereby retract the statement! ; )

I wouldn't want to be the cause of any unfounded rumour, especially against any BSD.

multi-platform

[CaptainPinko]

I could put it on my SPARC and be in the exact same environment as I have on my x86 laptop!

As you could with FreeBSD, OpenBSD, and Linux I"m pretty sure. IIRC the point of constantly porting the NetBSD kernel is to make sure the code is flexible and robust and doesn't build-up any system dependent kludges. I'd consider the platform independence as a sign of good design rather than as a goal.

Re:multi-platform

[0racle]

FreeBSD only supports sparc64 aka UltraSPARC not the earlier sparc chips. NetBSD seems to have the best support for both sparc32 and sparc64, with Linux distros in a close second only because they don't all seem to be updated as often, except debian which is your best bet for linux on a sparc. OpenBSD's sparc support is excellent except for SMP which hopefully will come sometime, it just doesn't seem to be much of a priority.

Re:multi-platform

[he who meows]

But does any comparable set of userland tools do so as well?

Re:multi-platform

[torstenvl]

From http://www.kernel.org/:
"These days it also runs on (at least) the Compaq Alpha AXP, Sun SPARC and UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH, IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64 and CRIS architectures."

Check, check, check, check, check, dunno, check, in progress, in progress, check, check, nope (who needs Itanium? :-P), check, check, never heard of it.

From http://www.netbsd.org/Releases/formal-1.6/NetBSD-1 .6.2.html:
"The NetBSD operating system is a full-featured, open source, UNIX-like operating system descended from the Berkeley Networking Release 2 (Net/2), 4.4BSD-Lite, and 4.4BSD-Lite2. NetBSD runs on 52 different system architectures featuring 17 machine architectures across 11 distinct CPU families, and is being ported to more. The NetBSD 1.6.2 release contains complete binary releases for 40 different machine types."

There are certainly some that Linux supports that NetBSD doesn't, but not many. And as far as sheer number, NetBSD wins hands down.

Besides. At a certain point, you get past the serious marker, because you've exhausted all the common platforms. At that point, only one thing matters: Can I run *Nix on my Atari?

Re:multi-platform

[LizardKing]

OpenBSD has ported the SMP work from NetBSD, giving it multiprocessor support in an amazingly short amount of time. I think this porting was largely the work of one programmer, which is some achievement. From postings on the OpenBSD Journal it appears that support is available for SMP on sparc and i386 at least.

Re:multi-platform

[Anonymous Coward]

Pffth. The "system architectures" number that NetBSD likes to tout is not impressive. A system architecture typically needs a bit of specific bootup and maybe chipset specific setup code, perhaps a few constants changed, a system specific driver or two. Not to say that NetBSD supports more than Linux, but just that Linux probably has lost count and nobody cares anyway.

A CPU ISA, now that is the important metric...
Linux supports:
alpha
arm
arm26
cris
h8300
i386
i a64
m32r
m68k (with and without an mmu)
mips
parisc
ppc
ppc64
s390
sh
sh64
sp arc
sparc64
v850
x86-64

NetBSD supports:
alpha
arm
arm26
i386
m68k (with standard and a sun mmu)
mips
ns32k
parisc
ppc
sh
sh64
sparc
s parc64
vax
x86-64

So the places you can run NetBSD but not Linux are on an old m68k from Sun, some old "ns32k" thing, and the old old vax. I'm sorry, but these are "who cares" systems *far* more than even ia64.

The CPUs that you can run Linux on that NetBSD doesn't support are cris h8300 ia64 m32r ppc64 s390 v850. In other words, modern CPUs from embedded to "big iron" to G5 desktops.

So the actual things that matter are: Can I run *Nix on my G5? My 512 CPU IA64 supercomputer? My POWER5 server? Or my handful of modern embedded CPU architectures? I really don't give a rat's ass about my Atari (although no doubt you can run Linux on that as well).

Re:multi-platform

[OttoM]

OpenBSD 3.6 has SMP support for i386 and amd64. sparc is not supported. sparc and other platforms might get support in upcoming releases.

Check the OpenBSD 3.6 page for other new things in the 3.6 release.

Re:multi-platform

[bodgit]

There are certainly some that Linux supports that NetBSD doesn't, but not many. And as far as sheer number, NetBSD wins hands down.

Also consider that the code base is a lot more portable too. I regularly crossbuild the entire base NetBSD OS for SuperH, MIPS, Sparc (both 32 & 64), etc. from Linux/i386 with a single command, I currently can't do that for Linux OOTB. (Would be great to do so).

Re:multi-platform

[Anonymous Coward]

I like how you list CPU architectures, not platforms. Like there is absolutely no difference between an old 68K amiga and the Sun 3/260 I have downstairs?

Adding support for a new CPU type in NetBSD is fairly easy... the code is clean and portable. I'm sure most of those processors could be easily supportable if there was sufficient desire, but personally, I don't even know what the "cris" processor is, and what machine runs the h8300 processor? Its more likely a matter of nobody having the hardware, or the time, to spend porting to a machine nobody has.

With all the garbage I've had installed with "out of the box" linux installs, randomly changing the whole VM system in the middle of a "release" OS, and the like, I far prefer the stability of a release version of NetBSD. If it wasn't for having to power off my NetBSD server here at home to replace a failed 120GB drive a few weeks back, I'd have almost 2 years of uptime (the UPS helps ;-) ). We run RedHat at work on our servers, and besides the damn date problem (tell me again why exaclty uptime can't count over 250-some-odd days?), I've had more random crashes and poor VM behaviour on RedHat than I've ever had with NetBSD.

2.0 has been a long time in coming, but I far prefer the NetBSD philosophy of "do it right, before you release it" rather than the seeming linux philosphy of "relese it, and we can always fix it later".

Re:multi-platform

[ArbitraryConstant]

IIRC, there was a request on misc@ for a dual processor G4 box.

From a user and soon-to-be commiter

[agent dero]

For those of you that don't know, NetBSD 2.0 is going to be _awesome_

I run -current on 3 machines (x86,sparc32,sparc64) and it's just cool. One of the features that come to mind (really don't think it's in 1.6.2) is FFS2 (FFS being their file system)

SMP is still being worked on, I don't know about the status of the i386 port, but for sparc64, SMP is to the point where the kernel will spin up that second CPU.

(Of course, we never paid a developer full time to hack SMP ::cough:: ::cough:: ;) [mods, it's a joke])

Re:From a user and soon-to-be commiter

[bhima]

I don't suppose you know if LKM has been improved...

I've got a nice little Cobalt Qube 2 that is very under utilized due to the fact that it cannot load the PPTP module mppe, it fails with

"Mmpe.o: ld: /usr/pkg/lkm/mppe.o: Not enough room for program headers (allocated 3, need 4)"

Re:From a user and soon-to-be commiter

[agent dero]

There seems to be evidence supporting the fact that LKM may be supported in the 2.0 release (if not already)
here's a clue, see date

Check on the port-cobalt page for more info, and if you feel really daring, sign up for the port-cobalt[at]netbsd.org mailing list ;)

Re:From a user and soon-to-be commiter

[LizardKing]

I'm running -current on sparc, vax and i386. I also thought about putting it onto my NeXTstation, but I'd miss NeXTstep too much.

FFS2 is not totally trustable yet, although I do use it on my laptop. As for SMP, it now works on a number of ports including i386. I'm sure I also saw someone mention that it could spin up a second processor on an SMP Vax(!) machine. On the more popular SMP ports (i386, sparc, sparc64) the SMP support actually *uses* the extra processors as well as recognising them.

The other big feature in NetBSD 2.0 is the native threading support. This is based on scheduler activations, which is far more scalable than more common threading implementations. It took a while to get stable, but has uncovered numerous bugs in multithreaded applications. This is because the pthread implementation that sits on top of scheduler activations was quite exacting in it's conformance to the POSIX specification. This meant that sloppy thread programming that was acceptable on other platforms showed up more readily on NetBSD.

The only outstanding issue that I ahve with thr release candidates is that gdb seems to be a bit flaky. This may be a problem with missing support for SA threading, but it's not something that I have any time to look into.

Re:From a user and soon-to-be commiter

[bhima]

I've memorized the port-cobalt page and I already subscribe to many NetBSD mailing lists.

Thanks tho....

Re:From a user and soon-to-be commiter

[noselasd]

>The other big feature in NetBSD 2.0 is the native threading support.
>This is based on scheduler activations, which is far more scalable than
>more common threading implementations.
Just cause it has a cool name, does that make it better ?
Where are the benchmarks backing your claims.

If it's just about the mixing of scheduling in both user and kernel space,note that Solaris has this and is moving away from it. IBM made NGPT a m:n thread library for linux, but the new NPTL (kernel space only scheduling) outperformed it.

Re:From a user and soon-to-be commiter

[Anonymous Coward]

The problem for the other architectures compared to NetBSD concerning scheduler activations is the fact that NetBSD has a smaller and cleaner core.
This is the same reason NetBSD is so simple to port; as a *BSD programmer I can tell you that NetBSD code is so clean you can eat it.

I'm not using NetBSD, I only code for it, but with the release of 2.0 I will move away some of our production machines from FreeBSD. I love FreeBSD, it's what I use, but the code is no where near as clean.

I don't really want to mention Linux, because it's butt ugly dirty code in about 95% of the code you look at, it's an achivement that it works at all; it's a complete wonder that it works so well as it does, probably the huge amount of involuntary(unknowing) testers that does the trick.

NetBSD and DragonflyBSD is probably the perfect mix for the future, as far as I'm concerned. But I dubt that it will happen at the level I want it to.

Re:From a user and soon-to-be commiter

[LizardKing]

Solaris has a poor threading implementation, even Sun's own engineers admit that. However, that shouldn't be taken as proof that all M:N implementations are poor. In a demonstration at BSDCon Japan 2003, NetBSD's scheduler activations outperformed FreeBSD 5 and Linux NPTL. See the tech-misc mailing list thread that starts from here: http://news.gw.com/netbsd.tech.misc/701.

oddness with ipf 4.1.3 and 2.0_BETA

[Anonymous Coward]

I have a few 2.0_BETA machines doing NAT and running squid - I rebuilt one after the ipf 4.1.3 update (couple of weeks ago-ish) and NAT stopped working properly - for example, a webpage that pushed the user through from http to https would never get to the https page. The was other odd brokenness with NAT too, but this one stood out for the users :/

I moved the machine back to a build a couple weeks before that, before the 4.1.3 update - no problems so far. (Nothing else changed on the machines, though I did try a squid update to the latest in pkgsrc, no help). ipfstat looks fine, too...

I can't really help debug this with this machine as I need it working working 100% of the time. However if anyone has suggestions, I will consider them.

Having said that, the 2.0_BETA machines I have at home (running a build with 4.1.3 in it) do not have this problem. Quite odd.

Note, when I say "rebuild" above I am keeping userland and kernel in sync (crucial when something like ipf is updated anyway), plus etcupdate-ing.

Re:oddness with ipf 4.1.3 and 2.0_BETA

[LizardKing]

Did you rebuild both the kernel and userland after the ipfilter update? I couldn't get NAT working until my userland was back in sync with the kernel.

New logo?

[Zetta Matrix]

I want to see the new logo already. They announced the contest about six months ago... how long does it take to choose a logo, even with open source bureaucracy? :)

Changelog

[ozzmosis]

Here is the Changelog from 1.6 to 2.0

BSD Trilogy

[bsd4me]

Has anyone else noticed that the three major BSD variants are all going to have major releases within about two weeks of each other?

FreeBSD 5.3 is scheduled for a Oct 17 release. NetBSD 2.0 is scheduled for a mid-October release. OpenBSD 3.6 is scheduled for a Nov 1 release.

Hmmm?

Re:BSD Trilogy

[ArbitraryConstant]

OpenBSD's done releases on every May 1st and Nov 1st for years... They didn't do it. :)

NetBSD and FreeBSD tend to release when what they're working on is ready. Must be their doing. :)

Re:Timing the Releases of the BSDs

[torstenvl]

What? FreeBSD doesn't support chrooted Apache?

That's funny. uname must be lying to me.

Re:Timing the Releases of the BSDs

[krog]

OpenBSD is secure, but so is NetBSD. I have been running NetBSD continuously on MITnet (a high-profile network with frequent hacker attacks) since 1997 and I have been hacked exactly 0 times. Not saying I would have been hacked with OpenBSD, but zero breaches in seven years is a pretty compelling record (especially when I compare to my Red Hat-using friends).

I2 Land Speed Record: NetBSD did it again. :-)

[ulib]

From NetBSD's website :

NetBSD does it again. After the original Internet2 Land Speed Record set in 2004 May 3 was broken, NetBSD shines again: researchers at the Swedish University Network (SUNET) have broken once more the Internet2 Land Speed Record, using the upcoming version, NetBSD 2.0.

The new records are 124.935 Pbmps in a single stream (was 69.073 Pbmps), and 122.367 Pbmps in multiple streams. NetBSD was used once more due to the "scalability of its TCP code".

More information about this record including the NetBSD configuration can be found here for single stream and here for multiple streams. And here is the website of the Internet2 Land Speed Record (I2-LSR) competition.

Make that RC3, actually

[hubertf]

There was some nasty NFS glitch n RC2, which led to RC3.

- Hubert