Slashdot Mirror
NetBSD v3.0 Released
FullMetalAlchemist writes "After six release candidates, the NetBSD project has finally released a gold version of a major mile stone; v3.0. I'm looking forward to this release a good deal. If I wanted to, I could build our entire office infrastructure on it thanks to Xen. Major Changes can be found on the NetBSD website, and there are several ways to get the release. Get downloading!"
No WPA support, very little support for 802.11g devices, and a lot of missing things as compared with other modern OSes (a current, working DRI implementation and support for ACPI suspend/resume would both be very nice)... this is a pretty disappointing release.
I've always liked NetBSD for being very cleanly implemented, but the way things have been going lately, I might wind up having to switch to FreeBSD or *shudder* Linux for some upcoming projects.
How kind of you tell the developers what to develop and prioritize on something they do for free.
By releasing first for x86, the NetBSD devs demonstrate their sanity by working on the software that would benefit the most users. Today, VAX doesn't matter, so why should they support it at all?
I got news for you: Developers work on certain architectures because they want to.
I agree that it's frustrating to not be able to natively compile the VAX port, that's not really the same thing as saying (as in the subject line) that the VAX port "stopped working". It works just fine.
It's supposed to be comparable to the FreeBSD 5 series for speeds, I've seen no benchmarks against the newer 6 series, but can assume they're still within a pretty reasonable range of eachother, not too much else unless you want to run on a platform other than i386.
As far as OpenBSD comparisons go; performs better overall, less secure, pf is not integrated into the system as tighly, and it's support of it's various platforms aren't always as good as those of OpenBSD's, since they do their support through cross compiling instead of native work.
You may prefer NetBSD's speed over OpenBSD or NetBSD's support for alternative platforms, it's all in what you're trying to do.
I'm sick of following my dreams - I'm just going to ask them where they're going and hook up with them later.
Well if you've got a BBA --I dont sadly-- and you've cross compiled the apps you want to use on another *faster* machine, then pretty much anything.
Also a VGA cable would be good too, trying to read NetBSD's console on TV at 47Hz really Hz the eyes.
/. is good for you.
Linux is a kernel. NetBSD is an operating system.
When Linux runs on a platform, most of the time it means an incredibly stripped-down variant that has almost no features runs on the platform. In addition, no support is thrown in to port the rest of the operating system (e.g. userland, applications, etc.).
When NetBSD runs on a platform, most of the time it means the default NetBSD userland, kernel, and everything else in the source repository will run on the platform. In addition, NetBSD tends to be careful about incorporating new features (Linux had support for hot-swappable CPUs at one point...).
Bullshit, the VAX port works fine. What doesn't work is building it natively using the default settings. This is because of a problem building groff - it triggers some undiagnosed compiler bug. You can work around this by building groff without optimisation, or cross compiling on another architecture (which if you do it on a modern PC is much faster than building on any VAX). The releases and snapshots of NetBSD are cross compiled, which is why the longstanding groff compilation bug still exists.
NetBSD claims to be extremely portable - portability is the main stated goal.
Well, one of the goals, third down on the official list.
f it only runs well on x86, NetBSD becomes basically irrelevant - FreeBSD is far better on x86, and OpenBSD (whose goal is security and implenetation and correctness) is more portable (OpenBSD runs fine on VAX). Essentially, if NetBSD doesn't actually talk the talk they have about portability, all they are is an inadequate OpenBSD that is less secure and less portable - and it has no advantages.
Since FreeBSD 5 and NetBSD 2, performance on x86 has been very close and often better on NetBSD. Check out the benchmarks and studies posted on the advocacy mailing lists. FreeBSD is suffering portability issues thanks to the original focus on x86 alone. OpenBSD only works on a reasonable number of platforms because it absorbs a lot of work from NetBSD, the VAX port is a good example, where NetBSD supports more models of the VAX. NetBSD is arguably as secure as OpenBSD, but has far more features and performs much, much better.
One of the more proactive NetBSD/VAX users complained recently about the native build problems and a personal fear of "featureitis". It looks like some Slashdot cretin has picked up on that and decided to try and piss on the NetBSD 3.0 announcement with what is largely a non-issue.
I installed NetBSD 2.1 on my VaxStation 3100 m30, and it works fine. My DEC monitor broke, so I don't know if the monochrome framebuffer driver still works, but there has been considerable work on the VAX framebuffers recently so I would expect so. I've never needed to bootstrap an install with mopd, because the bootable CD's work fine with an old Sun CD-ROM drive - you can pick them up dirt cheap on Ebay.
I can't comment on the uptime with the 3100, as it only gets switched on for a few hours at a time. However, my 4000VLC has been running continously for several months acting as a minimalistic intranet server.
It's worth emphasising that pkgsrc is not just for NetBSD. It works on OpenBSD, DragonflyBSD, Solaris, Irix, Darwin and others. It even works on various flavours of Linux, including Debian.
Well, I'd disagree that NetBSD performs better on a VAX - it's currently uninstallable and un-runnable on most VAXen due to the problems already stated in this thread (starting with inadequate netbooting documentation, and a MOP booting procedure that doesn't even work). Essentially they say they support the platform, but haven't really supported it since 1.4.
Oolite: Elite-like game. For Mac, Linux and Windows
Care to try out version 3.0? The netbooting issue was solved, perhaps as long ago as versions 2.0.1. Version 1.6 shipped with a broken boot.mop, but worked find if you booted the install from a CD or used the boot.mop from 1.5. As for NetBSD/VAX being "unrunnable" once installed, that's just bullshit, or else I must be imagining the VS4000 VLC and VS3100 m30 humming away next to me.
NetBSD supports more models of VAX than OpenBSD - try comparing the lists on http://www.netbsd.org/Ports/vax/ and http://www.openbsd.org/vax.html. NetBSD also supports more devices, such as framebuffers and SCSI controllers.
Somehow reminds me of some of the people I work with. Something breaks, I jump in and try to fix it (and have a good reputation, and now everyone calls me when they have really bizzare problems, because I'll figure them out). Then there's most (not all) of the other people, something breaks, "oh it doesn't work, someone should look at this, really sucks, its useless, yadda yadda." God forbid when I find out, I should ask "did you actually do something like, dig into it yourself? Send an email asking for help?" -- Dead Silence.
Ok, so Vax doesn't self-build because of a *known* issue (although for myself, I'd rather cross-build on my Dual-Xeon 2ghz box, rather than wait 8 days, I agree it *should* be fixed). Other than that, perhaps you would enlighten us on all the other issues you have with the Vax port?
Heh, and classic, my word-image deal for submitting this is "critics".
Just cause something works on paper or builds fine on i386 doesn't mean the binary will run on VAX, Alpha, PA-RISC, PDP-11, MIPS, etc, etc, etc.
Quite true. And I personally think NetBSD does a fairly good job of picking up on things, but there are just some things a basic regression test is never going to find, and for that you rely on user testing and user feedback. And if the userbase is small... (I have a VS4000/60 here I've been meaning to load NetBSD up on since probably 1.6.2 days, but I've just been way to busy with "life" and actually trying to get *rid* of some of my older stuff, that I'm not sure when I'll get to it).
I've seen a lot of comments here about bugs in 1.5 and 1.6, and people just "not using it after that", and its sad, I think NetBSD could do a better job of testing, but I also think that to some extent bugs are to be expected. Hey, I ran an old Interdata mini back in the day, where one release of "OS/32" changed the disk structure slightly, "run fastchek on your disks after booting the new OS". Wasn't me, mind you (I'm overly cautious sometimes), but somone installed it and corrupted every disk on the system (bug in the code to fix the disk structure). 2 weeks later the big red piece of paper came out from the vendor "warning, don't install this", there's QA for you.
Of course, if people want to compare, I seem to recall Windows95 having an issue crashing after like 45 days. Hmm, and then 98.. so 3 years to fix that? And trust me, I use Linux (mostly RedHat) at work, and if I just tossed up my hands and said "this sucks, I'm never using it again" (while I would like to, I have no great love of linux and its hacked-together virtual memory "design" that keeps changing).. well, I wouldn't have a job and be able to pay my bills. Yes, for home, I like to just set something up and have it "just work", and truthfully I've had far better luck on that with NetBSD on "obscure" platforms than w/ Linux.
One look at the "status" page for the Linux/VAX project:
"30 November 2005 -- Toolchain
A cross-compiled GCC-4.2 (checked out from SVN, plus some patches), running on a VAX, properly compiled a "Hello World!" program."
In June of 2001 "Kernel boots to shell prompt and forks properly", and don't get me wrong, I think they've made *good* progress with it, having seen how non-portable some of the Linux kernel code was (they started w/ 2.2 I believe), and they just manged to get a *cross-compiled* (cough cough, nudge nudge, to the guy who started this thread complaining about NetBSD cross-compiling while the local-compile fails) GCC built and running, and able to compile "Hello World" (woohoo!).
As someone who's written device drivers, played with porting GCC to other architectures (note that the GCC people themselves have dropped support for most of the architectures they supported back in the 2.x days, and its been left completely to "volunteers"...), and misc kernel work, it annoys me when people think a major change is going to go in (for instance, the change when NetBSD went to UVM) and the next release is just going to "work fine". People try, but people are human, things sometimes get missed, thats why my general rule is to always beware of a ".0" release (ie, 1.5.0, 1.6.0, 2.0, 3.0 - note that with the change in version numbering, 1.5->1.6 was some pretty major changes, whereas now they've gone to 2.0->3.0 being major changes, and 2.0->2.1 being fairly minor in terms of changes).
What NetBSD *needs* is more people taking the time to do real-world testing of new releases, and providing feedback, rather than saying "I tried 1.5 and 1.6, and had issues, so I'm sticking with 1.4, and I'm never going to bother even trying 2.0,2.1,3.0".