Slashdot Mirror
NetBSD 2.0 Release Engineering Process Underway
jschauma writes "James Chacon of the NetBSD Release
Engineering team has announced that the Release Engineering process for
the much awaited NetBSD 2.0 release
has begun! At this time, the expected final release is scheduled for the end
of May 2004. Please see James' message to the netbsd-announce
mailinglist for details."
I've been running NetBSD -current (a bit like running Debian unstable for all you Linux types) since a little before the scheduler activations were merged in last year. I'd stuck with stable releases before that, but switched as -current got around some quirks in my oddball laptop that stable didn't.
My intial experiences with scheduler activations (which has a pthread compatible library layered on top of it), were a bit disappointing. Complex applications like Mozilla and some other desktop applications broke, as they relied on less than POSIX compliant features in certain other OS'es. Once those wrinkles were ironed out, -current became as rock solid as the stable releases.
The only thing NetBSD lacks once 2.0 is released is an ALSA compatability layer. Having read the scant, poorly written documentation on the ALSA website I'm at a loss to see what it really has that OSS doesn't, but that seems to be what Linux based MIDI and audio apps are migrating to.
Chris
What other forums are available to BSD users?
The posts to this forum have become so warped by SLF zealotry that there is no longer any value reading SlashDot.
I have been tracking (more or less on a weekly basis) -current on my laptop (Omnibook 6000, before that - -4000, using the same disk without reinstall...), as well as on a couple of servers and a workstation in the office, including an old IPX, some dual Athlon MPs, even a dual Opteron system. One needs a bit of time to get used to some quirks in the process, but the result is most rewarding, especially with the native threads (scheduler activations) in place. I do have occasional glitch - most likely due to my habit of using 'make replace' way too often to upgrade packages, but the stability generally has been excelent. I started with NetBSD at the time as it was the only BSD to support both the modem and the Ethernet part of my Xircom adapter (OpenBSD did not support the modem part, FreeBSD and - at least - Mandrake up to 9.2 - refused to install on the laptop for some reason - never bothered to check, as NetBSD did all what was required...).
If only there were a native pkg for OpenOffice (recent - the earlier port did not work at all under -current for me).
But it does not work with a really important component of my hardware inventory: USB wifi adapters. Once it does, I'll put it all on it.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
What other forums are available to BSD users?
The mailing lists for NetBSD and FreeBSD are excellent. The OpenBSD ones tend to get cluttered up with spam, as the list admins (if they exist) seem to be a bit lax.
Chris
Not sure what your getting at. I assume you're talking about comparisons between Scheduler Activations and the plethora of scheduler algorithms available for Linux. NetBSD's SA is not a conventional scheduler in the "new, expermental one every week" Linux sense. They are a sophisticated system that allows layering of higher level abstractions like POSIX threads.
Chris
http://deadly.org
I use to be indecisive, but now I'm not so sure.
Does this mean that OpenBSD's packet filter don't make it to 2.0? Well, I don't worry much because some one will surely port it later.
Linux has one scheduler for the entire 2.5 / 2.6 development cycle, and the previous one before that I think lasted a lot longer.
Linux right now has probably the most complete POSIX threads implementation, and the most advanced CPU scheduler (supporting SMT, SMP, NUMA) compared to the three major free BSDs. FreeBSD's scheduler, for example is a clone of Linux's scheduler (which I think is currently missing at least the NUMA part and they can't seem to get it stable). Not sure about NetBSD's scheduler... but anyway, as you see, Linux hardly needs to change schedulers every week.
* 9/2003 is really old for current.
Oh yeah, and the Linux 2.6 kernel is out too...
* Softdeps != journaling, of course journaling is going to win vs. soft deps. Duh.
Oh? Most BSD people always say how much better SU is than journalling. I guess they would say that though.
* RAIDframe still has a ways to go
Looks like it.
* Default file system creation options for NetBSD ffs are far from optimal on high power systems. Tweaking those would probably give a significant performance boost, with or without softdeps.
What options? What are their default settings, and what should they be on high power systems?
* BSD developers typically do not sacrifice portability for speed.
Neither does the Linux kernel. In fact, they are ported to more CPU architectures than NetBSD, and are faster than FreeBSD and NetBSD in most recent benchmarks.
It was not so long ago that Linux distros had async file I/O on ext2 without journaling. Naturally async is going to be faster than the default safer sync option on ffs.
That has no relevance to this test, which tested a journalled filesystem. And most Linux distros I think have been using journalled file systems for about 4 years.
Can anyone make a guess as to when some i386 ISO images might be available for testing? Thanks.
Screaming Electron
BSD Hound
BSD Forums
etc.
You could try Google BSD
From Improving
Passive Packet Capture: Beyond Device Polling.
"Linux, a very popular OS used for running network appliances,
performs very poorly with respect to other OSs used in the same
test" (FreeBSD and Win2k).
"The Linux kernel module is almost as fast as the userspace
FreeBSD application".
Percentage of packets captured (in user space), using device polling, at
80,000 packets per second? Linux 5.6%, FreeBSD 99.9%. Linux manages
99.5% only using a kernel module.
SO LINUX MUST GO TO KERNEL SPACE TO ALMOST BE AS FAST AS FREEBSD
WITHIN USER SPACE!
Maybe if you BSD is dying trolls stopped crapping on here about BSD
dying and instead actually learned a language apt for your OS of choice,
you might actually be able to bring Linux up to "dead status" with the
BSD's.
But wait, it gets worse! While trying to capture packets from a
DoS application, Linux could only manage capture rates of 0.8% in user
space and 9.7% in kernel space, while FreeBSD managed 74.7% in user
space!
"FreeBSD performs much better than Linux"
"it is obvious that a vanilla FreeBSD systems is much more
efficient than a vanilla Linux system when used for packet
capture."
Admittedly, this is a fairly obscure platform, so the install scripts probably aren't as well developed as, say, i386, but still, it'd be nice...
Good Google BSD search
What about this then ?
Even if this is some kind of testing kernels, this definitly doesn't look like "reliable" to me...
http://kerneltrap.org/node/view/867