NetBSD Goodies: 2.0 RC1 Tagged, New pkgsrc Branch 55
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."
Cool! (Score:3, Interesting)
multi-platform (Score:2)
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 (Score:4, Informative)
Re:multi-platform (Score:1)
Re:multi-platform (Score:3, Insightful)
"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?
From http://www.netbsd.org/Releases/formal-1.6/NetBSD-1
"The NetBSD operating system is a
Re:multi-platform (Score:1, Insightful)
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
p
Re:multi-platform (Score:2, Insightful)
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, o
Re:multi-platform (Score:1)
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 (Score:4, Informative)
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 [undeadly.org] it appears that support is available for SMP on sparc and i386 at least.
Re:multi-platform (Score:4, Interesting)
Check the OpenBSD 3.6 page [openbsd.org] for other new things in the 3.6 release.
Re:multi-platform (Score:2)
Re:Cool! (Score:2)
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! (Score:3, Informative)
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! (Score:2)
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.
From a user and soon-to-be commiter (Score:5, Interesting)
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
Re:From a user and soon-to-be commiter (Score:2)
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 (Score:2)
here's a clue, see date [netbsd.org]
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 (Score:2)
Thanks tho....
Re:From a user and soon-to-be commiter (Score:5, Informative)
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 (Score:2)
>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 schedulin
Re:From a user and soon-to-be commiter (Score:2, Insightful)
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 me
Re:From a user and soon-to-be commiter (Score:3, Informative)
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 [gw.com].
oddness with ipf 4.1.3 and 2.0_BETA (Score:1, Informative)
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 di
Re:oddness with ipf 4.1.3 and 2.0_BETA (Score:3, Informative)
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.
Re:Go NetBSD! (Score:1, Offtopic)
New logo? (Score:2, Interesting)
Changelog (Score:2, Informative)
Re:Timing the Releases of the BSDs (Score:1)
That's funny. uname must be lying to me.
Re:Timing the Releases of the BSDs (Score:1)
BSD Trilogy (Score:3, Informative)
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 (Score:2)
NetBSD and FreeBSD tend to release when what they're working on is ready. Must be their doing.
I2 Land Speed Record: NetBSD did it again. :-) (Score:1)
NetBSD does it again. After the original Internet2 Land Speed Record set in 2004 May 3 [netbsd.org] 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 includi
Make that RC3, actually (Score:2)
- Hubert