Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×

NetBSD v3.0 Released 132

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!"
This discussion has been archived. No new comments can be posted.

NetBSD v3.0 Released

Comments Filter:
  • by Anonymous Coward on Friday December 23, 2005 @05:37PM (#14329320)
    Hrrmph. As a loyal VAX owner, I need to note that it seems that although NetBSD claims to support some gawd-awful high number of architectures...many are left behind to basically fend for themselves.
    Just because NetBSD v3 is out, doesn't mean it runs on anything except a few of the common Intel/PPC chips.

    It would be nice to be able to complete a full VAX build without some bizarre GCC error forcing me to go look for a workaround.

    VAX 4-ever!
    • Heh, the last version that actually builds and works correctly on my VAX is 1.4
      • Yes, but 3.0 will boot on my electric toothbrush. That's all that matters.

        :-D

      • i guess they are limited to volunteer efforts, if you have a VAX, have the time, and are skilled enough, you could maintain the port, but unfortunately they dont have the resources to test and confirm all architectures for all releases.
      • Hmm... just wondering, if I post what version each of the obscure pieces of hardware I have lying around manages to run, will all of those posts get a +5 interesting moderation?

        Anyway, its a vaxstation 3100 m20 with 16mb ram and monochrome graphics with a local (scsi) disk for swap and temp storage, it is netbooted. When trying to run 1.5 or 1.6 and build a world, the machine just hangs after some 2 days of work. 1.4 finishes building a world but it takes forever to do so (actually, something like 7 or 8 days). I never tried 2.x and current however, maybe I should when I can be bothered to connect it again and setup mopd on some machine here.
        • 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. H

          • 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.

            Hmm, and there was a typo (more then one, actually) in my last pist, it is a 3100 m30 also. I still hav
      • I tried 1.5 and 1.6 a long time ago on my VLC4000, but it was not stable. It would hang around once a month, so I tried to install an old VMS but I'm too ignorant of this OS to build a server out of it. Finally, it ended up on OpenBSD. 3.1 was fine and *relatively*
        stable on it. Now it runs 3.7 very smoothly. The only time it reboots is when I accidentely
        walk on the power plug.

        I like the idea of building front-end servers/proxies out of rare combinations of OSes
        and platforms. It reduces the risk of getting a
        • I like the idea of building front-end servers/proxies out of rare combinations of OSes and platforms. It reduces the risk of getting a bug exploited. I've used an easily exploitable version of openssh for 2 years without a break-in ;-)

          Careful wtarreau. Thems' fightin' words. Get ready to be verbally attacked by all the dorks who spew "security through obscurity" as if it applies when avoiding the #1 targetted arch. I agree with you, I like using obscure hardware (slightly: sparc64, macppc) and software (luc
          • Lots of people seem to have come to the belief that obscurity cannot provide anything positive at all.

            Your comment points out another good aspect of the cross-platformness of NetBSD. You can run the same codebase on an obscure arch or on i386. It's the same codebase so the 'many eyes' aspect argued for by the 'security through obscurity baaaaad' jihad applies, but you can run that same code on an obscure arch, which renders your binaries a further layer impenetrable, even while running on the same codeb
    • Why does VAX need to be supported?
      please feel free to enlighten me.
      • by possible ( 123857 ) on Friday December 23, 2005 @06:20PM (#14329552)
        Why does VAX need to be supported?

        Because porting to non x86 architectures forces you to fix bugs. If the code is faulty, it may work for 99% of the x86 users, but crash for the remaining 1% of x86 users. But since none of the developers can reproduce the problem, it's a case of "I dunno, works on my machine, I'm not going to spend time looking for it". Whereas on other architectures, incorrect code may fail 100% of the time due to aligment, different exception handling, etc.

        NetBSD doesn't just suck on VAX. It sucks on ppc (aka, Macs) too. And up til recently it sucked badly on amd64. Most of NetBSD's "supported architectures" haven't worked for years, because they often cross-build instead of doing native builds.

        • It's funny, on OpenBSD stories people ask for cross compiling and on NetBSD stories people talk smack about it. Not that you're wrong, cause you're not. I just find that funny that the OpenBSD people are always saying why cross compiling isn't an answer when NetBSD fans talk about it on OpenBSD stories and here it is spilling in the opposite direction.
          • by darkjedi521 ( 744526 ) on Friday December 23, 2005 @07:01PM (#14329793)
            There is a happy medium between the two. A cross build can save time, but the code should be tested on the real hardware. Especially if one is claiming to support some of the more interesting CPUs out there. I've heard stories of DEC redoing parts of VMS/Ultrix/Tru64 to work around CPU bugs. 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.
            • by Anonymous Coward
              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 be
            • There is a happy medium between the two. A cross build can save time, but the code should be tested on the real hardware.

              The theory is that building release on the intended arch is a good test of that arch. You could cross compile on x86 to VAX, then test the VAX binaries on the VAX and not find anything wrong. Whereas building release for the VAX on the VAX may turn up problems that you otherwise might not find.

              I agree though, that there should be a happy medium. Cross compiling for dev work and then final
              • On older VAX systems (and on my Mac SE/30) cross-compiling is essential. It's likely that a full kernel and userland build, plus a reasonable set of the packages, on an SE/30 would take long enough that the build wouldn't be done before the next release. The SE/30 is Processor-clock, IO, and Memory bound to be a small system in today's world. My MicroVAX 3100 is even smaller and slower in some regards.
        • I just downloaded macppccd-3.0.iso hoping it would be an improvement over 2.1 but the 3.0 cd doesn't even boot on my b&w G3.

          Perhaps they should consider timely complete release notes for each architecture? I don't think 2.1 macppc release notes and errata have yet appeared...

          Meanwhile, much as I love BSD (preferably FreeBSD) on i386 I haven't found it terribly useful on powerpc. If it weren't for Debian my macs would have to run mac os.
      • Because there are still people around who like to run a VAX. It is also the platform that saw BSD come of age (BSD was started on the VAX's "genetic predecessor", the PDP-11)
    • ...doesn't mean it runs on anything except a few of the common Intel/PPC chip

      In other words, it runs on 90% of their users' computers, and the developer time on those architectures was well-spent. Sorry, but pandering to hobbyist users of obscure hardware (yes, today it is) is a waste. In a world of finite resources, tasks must be prioritized. 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
      • In other words, it runs on 90% of their users' computers, and the developer time on those architectures was well-spent. Sorry, but pandering to hobbyist users of obscure hardware (yes, today it is) is a waste. In a world of finite resources, tasks must be prioritized.

        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, V

      • by darkjedi521 ( 744526 ) on Friday December 23, 2005 @06:45PM (#14329680)
        They claim the VAX is a supported platform. Therefore, NetBSD/vax should work for the most part (barring any inherent limitations in the VAX architecture.
      • NetBSD claims to be extremely portable - portability is the main stated goal.
        If 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.

        • by LizardKing ( 5245 ) on Saturday December 24, 2005 @07:07AM (#14331794)

          NetBSD claims to be extremely portable - portability is the main stated goal.

          Well, one of the goals [netbsd.org], 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.

          • 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.
            • 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/ [netbsd.org] and http://www. [openbsd.org]

              • It was actually only recently I tried NetBSD - approximately 4 weeks ago. What I found - the documentation for MOP booting a VAX with NetBSD is 404 - Not found. Googling brings up at least three or four different documents, none of which matched the files that were actually on ftp.netbsd.org. I spent quite a bit of time looking for documentation that actually matched what seemed to exist on the ftp site.

                I eventually gave up and found that not only did OpenBSD have the documentation for MOP booting right whe
    • by zaft ( 597194 ) on Friday December 23, 2005 @07:02PM (#14329795) Homepage
      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.
    • True. I recently dug out my VLC and decided to put in a bigger disk and move up from 1.5.... Nothing works. The MOP bootloader does not work, had to use the one from 1.5. Once I got it booted and ran the installer, the HD boot blocks to not work, even after running 'installboot' as advertised (another showstopper bug). Not even the 1.5 bootblocks will work now. So I have this system installed, but I can't even boot to it.

      I'd love to contribute to fixing it, but I'm not a programmer by any means. I think tha
    • Use OpenBSD then. The latest version of OpenBSD runs well on a VAX. When I got my VAX, I was intending to put NetBSD on it but then I discovered the documentation for netbooting the VAX to install was poor and inconsistent, to say the least (with many of the web pages being 404 - Not Found). By contrast, the OpenBSD instructions were contained in the actual installation documentation, just where you'd expect, along with the other methods of installation. The OpenBSD documentation was clear and concise, and
    • 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.

    • by Anonymous Coward
      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
    • There is always openVMS. I assume a Vax port still exists??

      Alot of opensource software has been ported and a recent defcom showed Apache running on VMS on an alpha proved to be the most secure platform. Perl, X, and many other programs run on it.
  • by NotFamous ( 827147 ) on Friday December 23, 2005 @05:38PM (#14329322) Homepage Journal
    Two, we hardly knew thee.
    • Three, we hardly will know you. No offence.

      (I've never seen netbsd in the wild... Hell, it doesn't even appear in tech news other than it being born and pronounced dead)

      • I've never seen netbsd in the wild...

        Then you really should get out more. No offence.
        Chances are you might run into (not literally, I hope) a laser printer, a robot, or a webcam running NetBSD [netbsd.org].

        If only hardware vendors like BroadCom would realize there are more kinds of animals in the world than just penguins, I'd love to get NetBSD running on my Asus wireless router someday...
  • So, does this mean (Score:1, Interesting)

    by ch-chuck ( 9622 )
    I can install NetBSD on my, oh, (picks obscure platform) VAX, and have xen run multiple virtual vaxes?

  • by rune2 ( 547599 ) on Friday December 23, 2005 @06:00PM (#14329468) Homepage
    Netcraft surrenders...
  • I'm underwhelmed. (Score:1, Informative)

    by Anonymous Coward

    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.

  • Obligatory (Score:4, Funny)

    by m50d ( 797211 ) on Friday December 23, 2005 @06:18PM (#14329544) Homepage Journal
    I'm compiling it on my toaster right now!
  • by Anonymous Coward
    Anyone got any?
  • by Anonymous Coward
    I've run OpenBSD and FreeBSD but what compelling reason would there be for me to run this variant? Riddle me this, is it worth my time installing this on a test box?

    • Try it and see if you feel more at home, if you don't you havn't lost anything.
    • by Nimrangul ( 599578 ) on Friday December 23, 2005 @07:03PM (#14329802) Journal
      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.
    • This isn't a compreshensive list, but its performance is apparently better than FreeBSD on single-processor systems, and it's deffinitely better than OpenBSD. Pkgsrc has more software than OpenBSD's ports, NetBSD is a bit more up to date (eg OpenBSD lacks the sendfile system call), some people don't like the way OpenBSD is set up, etc.

      I use OpenBSD because I want a firewall and I don't mind the way it's set up, but I can see reasons to use NetBSD.
      • Pkgsrc has more software than OpenBSD's ports

        But that doesn't preclude running pkgsrc on OpenBSD, which I do -- OpenBSD3.8 running in qemu, on NetBSD3.0 ;)

        -yb
        • 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.

          • Yeah, I'm running a webserver here on NetBSD, but have just bought a compaq proliant 6000, got some extra xeons off a friend, and now it has 2.6gig ecc memory too. I hear that Linux scales better on multi processor hardware, so have Slackware installed, and pkgsrc from NetBSD. Anyone know if 3.0 is better than 2.x on multicpu architectures?

            NetBSD is a lovely OS to work with though, I intend to keep DNS and mail running on it. I'd keep my quad xeon raid monster on it, but seen a study comparing Solaris, Linu
            • That was a single-process multi-thread setup, which NetBSD doesn't seem to handle very well (or it wasn't set up properly for that bench, which is also a popular claim).

              See how NetBSD 3.0 and DragonFly BSD 1.4 do compared to FreeBSD 6 and post some good benches. That'll be interesting.
    • it cant hurt to try it out. i mean unless you're still on a dial-up connection bandwidth is cheap and so is recordable media. i'm no zealot when it comes to the *nixes, (read i use bsd and linux) i tried the last release of netbsd but it wasnt for me so i went back to freebsd.
    • I used to use FreeBSD and OpenBSD exclusively but what got me started with NetBSD was once I wasn't able to get FreeBSD or OpenBSD installed on one of our boxes, only NetBSD managed to get itself installed. Then I began to discover NetBSD of its well thoughtoutness in various aspects, and most of my servers are NetBSD now ...

      Just give it a try and you'll see what I mean.
      • by ci4 ( 98735 )
        I was about to say the same. It started with my laptop - OpenBSD not supporting the modem part of a Xircom combo cardbus adapter, FreeBSD completely failing even to begin installation - and that's the whole sequence of them between 4.4 and 5.3 (haven't tried since). NetBSD (1.6 at the time) ran first time and the Xircom got me connected to the ISP first time. Since then I have it running permanently on some five machines in the office doing various In(ter|tra)net serving and desktop duties; only one box is
    • OpenBSD, FreeBSD and NetBSD serve different markets. FreeBSD is the larger enterprise class BSD, suitable for both desktop and server. NetBSD and OpenBSD can fit these roles but are far better on embedded systems. If you want SMP (typically not important for embedded systems), FreeBSD is further ahead. I've built a couple of commercial embedded systems, all proprietary, but my home network runs Linux, NetBSD and FreeBSD (and did run OpenBSD in the past). I'm familiar with the issues in embedded systems deve
    • For me, a part of the reason I find it valuable is that I am into all sorts of old classic UNIX hardware, and want a modern OS to run on all of it. I have the following systems and can/have run NetBSD on:

      Intel Boxes (regular PIII boxes, a Quad Pentium Pro Server, 486 laptops, Pentium Laptops...)

      My Macintosh SE/30 and my Quadra 650

      My Beige G3 Macintosh.

      My Sun Sparcstation IPC, IPX, Classic, 5, 10, 20.

      My Sun UltraSparc 1, 2, and 5 systems.

      My SGI 02 systems.

      My IBM RS/6000 (prep architecture)

      My PPC Mac clone (
  • What exactly does one do w/a Dreamcast running BSD anyways?
  • One great thing about netbsd is the possibility of handheld netbsd. Find out more Here. [handhelds.org] Some people have tried using it on flash cards with great success, a good choice if that is the case is 256mb's to get the full effect. Handheld BSD is great though, give it a try.
  • by drwho ( 4190 ) on Friday December 23, 2005 @10:04PM (#14330497) Homepage Journal
    "Of course it runs NetBSD" - the old saw, it seems. But I think that NetBSD is falling down in this regard. Many ports don't work properly, or haven't been updated in ages. Mailing lists lie dormant, waiting for attention, such as SBMips (BroadCom Sybyte MIPS) - in spite of Wasabi Systems (which is basically the commercial arm of NetBSD) having a press release about Broadcom support back in 2002, not much is being done in extending NetBSD to the CPUs used in consumer-grade equipment like Linksys routers. It's not even available for a fee: Wasabi doesn't have it in their development products and doesn't plan to. Linux is clearly quite far out in front in this regard.

    And it's not only MIPS: VAX ports are stale as well, from what I see here. This is sad. I like the idea of portability, and I like NetBSD - but I don't find that it lives up to its repuation in portability. Yes, someday I'll shut up and work on ports to the platforms I care, but in the meantime I am using Linux on the Broadcom CPUs and finding I enjoy it..almost too much to bother with NetBSD.
    • That's a lot of FUD - your comments reveal a lot of bias - simply because a port becomes stale doesn't mean that there's anything less valid about "of court it runs NetBSD" -- it's the fact that the software has been ported to so many platforms that puts it in such good shape for being ported to new platforms. A quiet mailing list says nothing about a port either - perhaps it means that the port is in such good shape that no one needs to talk about it? Also, there's not much relevance about it not being por
    • Many of the mailing lists fall silent because for older systems there are harldy any peripherals left to add support for. There's also a limited number of people running NetBSD on some of those architectures, it may only be the maintainers whi turn those boxes on regularily! However, SGI MIPS is quite active with ongoing work to support the R10000 processor and improve processor cache support for older models. VAX is far from stale, with support for colour framebuffers recently added and improved - despite

  • by Anonymous Coward
    I have a special place in my heart for NetBSD. I once was living poor, and was given a small, mips based computer. The only modern OS I could run was NetBSD, and it ran great! Never crashed and was well documented enough for me to figure out whatever I wanted to do.

    Here are some reasons you might want to try it out:

    1. Geeky history lesson. In my mind there was a golden age of geekiness going on during the 70s and early 80s centered around the creation of BSD. Reading the many stories in the Jargon Fil

Professional wrestling: ballet for the common man.

Working...