Slashdot Mirror

← Back to Stories (view on slashdot.org)

FreeBSD 5.0 Developer Preview #1 Released

Posted by timothy on from the excellent-smithers dept.

An Anonymous Coward writes: "The FreeBSD developers just announced the release of an official snapshot of the upcoming FreeBSD 5.0 which should be expected in November. Time to try out amazing new feature like background fsck, FFS snapshots, KSC, devfs, SMPng and many more. Check the Release Notes for detailed information." Read on for a list of ISO mirrors, too.

Thanks to AEtherSPOON, you can spare the main servers and use one of these FTP mirrors to grab the ISO:

12 of 109 comments (clear)

  1. background fsck by mjed · · Score: 3, Interesting

    Sounds interesting, but fsck isn't something you should run in the background. I mean, do you really want to be writing to the disk at the same time you're checking for errors? Maybe it's just my parinoia. If the developers pull this off safely and with no or barely any noticable slowdown, my hat is off to them.

    --
    I'm a repairman in an imperfect world.
    1. Re:background fsck by ChadN · · Score: 5, Informative

      The design of the BSD file system, when using "softwrites", is specifically engineered to handle this. It does require a rather sophisticated fsck (and one that is aware of how softwrites works). On the other hand, this also removes some of the complexity of the file system (which is not to say it isn't tricky code, but tricky in a different way from, say, a journaled filesystem)

      --
      "It's overkill, of course. But you can never have too much overkill." - Anonymous Slashdot Coward
    2. Re:background fsck by mosch · · Score: 4, Insightful
      Sounds to me like you don't understand how the BSD filesystem works. While Linux has started implementing journaling filesystems in order to get better recoverability, BSD used a different technique. It shifts the filesystem from valid state to valid state, in a manner where the only error that can occur due to a crash is a harmless wasted inode, wasting a little disk space. This can be cleaned up with a fsck.

      Because the only error that can exist on a UFS filesystem with SoftUpdates enabled is this wasted space, there's no problem running the fsck as a background process.

    3. Re:background fsck by Fweeky · · Score: 3, Informative

      > Come back up immediately after an unclean shutdown, but have a background task sucking up IO bandwidth for an hour or three.

      FFS fsck's quite fast, actually. As for sucking up IO; background fsck can be ran at a higher nice value.

      IO operations for niced tasks are reduced in favour of other tasks competing for IO; so, you *could* have fsck running for hours if your system's doing a lot of IO and fsck is running at a nice of +20, but you're unlikely to notice it on anything but an accurate IO benchmark.

      See Running "fsck" in the Background, section 7.

  2. Dropping 80386 from default kernel: Good Idea by finite_automaton · · Score: 5, Insightful
    I would say that it is about time that both *BSD and Linux look at dropping support for 80386 chips from the default kernel.

    From the FreeBSB-5.0/DP1 release notes:

    Support for the 80386 processor has been removed from the GENERIC kernel, as this code seriously pessimizes performance on other IA32 processors. The I386_CPU kernel option to support the 80386 processor is now mutually exclusive with support for other IA32 processors; this should slightly improve performance on the 80386 due to the elimination of runtime processor type checks.
    Supporting 386 chips is a good idea, but it should not be the default. I would like to be certain that the kernel that I build is taking advatage of the new features that my processor offers.
    1. Re:Dropping 80386 from default kernel: Good Idea by castlan · · Score: 3, Informative

      Just because a kernel supports the Intel 80386 CPU doesn't mean that later x86 processors can't leverage their advances with the same kernel. It seems that you didn't fully register the last phrase in your blockquote. When a kernel supports advanced instructions, CPUs with lesser instruction sets must run tests to see which instructions are supported, and which they need to ignore. This significantly slows down the relatively underpowered 386 class CPUs, while post-Pentium grade CPUs hardly notice anything.

      The trouble isn't that advanced instruction sets aren't utilized, but that there is no streamlined kernel for 386s that doesn't waste their precious time. Let me fictionalize a dramatization:
      "Are you superscalar?"
      "no"
      "Do you grok MMX?"
      "no"
      "Have you heard of SSE?"
      "huh?"
      "Do you have the Pentium Floating point Bug?"
      "The what?"
      "Do you mind if I waste another 16,000,000 cycles asking you rhetorical questions?"
      "no - at least not until I get my I386_CPU optimized kernel, so that I can make every kHz count!"

      Support for i386 chips in the generic kernel should definitely be the default, even if it did mean that the advanced features in the latest CPUs couldn't be fully exploited. For one thing, you need to ship the lowest common denominator so that the lower boxes can even run in the first place. Not to mention that it is much more sensible to ask a Terahertz Sexium w/Frobnitz CPU to recompile a kernel than a piddling 16MHz 80386 with a whopping 8MiB RAM. By the time the poor thing grinds out a useable vanilla kernel, your latest generation system is starting its third bout of "make world".

      It's called perspective... not everybody can track the latest revision of every hardware component. Some systems actually have uptimes higher than your IQ. (Hmm, was that last bit an insult? better think about it...)

      -castlan

    2. Re:Dropping 80386 from default kernel: Good Idea by Fweeky · · Score: 3, Informative

      Except generic code that runs on any i386-i686 is going to be less optimizable and more verbose than code that runs only on i486-i686.

      386 lacks certain instructions (e.g. cmpxchg); the compiler's not going to do a CPU check every time such an instruction will be useful, it'll just choose a solution that works everywhere, and you can be sure code that's good for a 16MHz 80386 that's just pulled the series out of 16bit hell is not going to be good for a 1600MHz Pentium 4 that doesn't even impliment the instruction set natively.

      Besides which, anyone running i386 level hardware is hardly going to be interested in any of the new stuff in 5.0; they're probably still running 2.x, 3.x or maybe 4.x.

  3. Re:This is shamelssly offtopic, but.... by jeffy124 · · Score: 3, Interesting

    the story told to my OS class was that Theo for whatever reason split from either Free or NetBSD to OpenBSD. For a while, the two were pretty much the same. Then someone r00t3d Theo's machine. Thus OpenBSD took on the task of being the most secure OS out there, and I think they've done a pretty good job, particularly in their development practices that encourage finding bugs and getting things right the first time.

    --
    The One Rule Of Chess You'll Ever Need: Don't play someone who carries a kit in their bookbag.
  4. Re:This is shamelssly offtopic, but.... by Tuzanor · · Score: 4, Informative
    Theo was the maintainter of NetBSDs SPARC port. For whatever reason, (it really depends who you ask. NetBSD guys says Theo was a dick, the people who sided with Theo say that one guy had a problem with him and blew everything way out of proportion) Theo was kicked out. Later Theo grabbed what he could of NetBSD and forked it into OpenBSD.

    You are right on Theo getting rooted. This sufficiently propelled the OpenBSD team into the security first approach that has made them so famous.

  5. Re:Almost there, buddy by Tuzanor · · Score: 3, Informative

    Thats not the real Theo. Its really spelled Theo de Raadt, not DeRaadt. Its just some troll who likes to think he acts like him.

  6. Re:This is shamelssly offtopic, but.... by castlan · · Score: 3, Interesting

    Right, it wasn't Tara, but IPF. OpenBSD didn't end up killing Tara...er, IPF, but disowning it. But that was mostly IPFs fault. So then IPFs twin sister PF showed up claiming to be the rightful heiress to the OpenBSD fortunes, and now IPF is forced to hang around the FreeBSD family much more then ever, which is making their local firewall jealous.

    Then in a big suprise, IPF comes back from her romping aroung NetBSD, FreeBSD and the red-light district of commercial Unix to deliver a bastard child... er, fork, of OpenBSD 3.0, and the Twin Suns of OpenBSD are silently duking it out through their invisible firewalls with divergent syntax. FreeBSD slips SMP into NetBSDs drink, and then, stay tuned for next weeks episode of "As Make World Tunes"...

    I think this post clearly indicates that it is my bedtime. Theo vs. NetBSD's remainder is old dead news. IPF wasn't as "Free (libre)" as the BSD community had assumed, and when Mr. IPF held this over Theo deGUUYs's head, deGUUY had a schitzoid reaction and hacked it out of OBSD. The remainder of the BSD community has more important things to worry about, OBSD embraced and extended a Free IPF alternative in time for the 3.0 release, and again OpenBSD has taken the high road.

    Theo is an unfairly maligned jerk who maintains a Free OS with uncompromizing values, where NetBSD and FreeBSD don't mind "bending the(ir) rules" now and then. He is most definitely not a software visionary, who rather believes that a 30 year old security model is the best choice for today's global internetwork of secure systems - because that way there are no surprises. The FreeBSD guys are hardworking arbitrary freeware oligarcho-capitalist volunteers just trying to keep thier releases regular.

    Darren Reed helped OpenBSD become what it is today, just as Theo de Raadt helped NetBSD become what it was, but both groups parted ways. IPF feels like a second class citizen without OpenBSD, so Mr Reed forked his own openbsd30.ipfilter.org, but IPF plays nice with most Unices. PF is now the OBSD Chosen One. Soap Operas should be criminalized. Support FreeBSD; but pay for OpenBSD, for when the shit hits the fan. Better safe than sorry, better secure than friendly. Computers don't need hugs. Oh, and Soap Operas need to be outlawed. Not to mention criminalized. Save Tara - she's a hottie.

  7. SoftUpdates, Not softwrites by sirket · · Score: 3, Informative

    Sigh, at least get the name right, even if you have no id ea how the technology works.

    -sirket