Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
BSD Operating Systems

FreeBSD 5.0 Developer Preview #1 Released 109

Posted by timothy 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:
This discussion has been archived. No new comments can be posted.

FreeBSD 5.0 Developer Preview #1 Released More

FreeBSD 5.0 Developer Preview #1 Released

Comments Filter:

  • Freebsd 5.0 DP1 (Score:2, Insightful)

    by Jeff Probst ( 459812 )
    Do any of the linux distros have a beta release program as excellent as FreeBSD's?

    • Re:Freebsd 5.0 DP1 (Score:2, Interesting)

      by BRTB ( 30272 )
      Well, at any time you want you can download a snapshot of Slackware [slackware.com]'s current tree, which is the development happening in realtime... probably can't get any faster beta releases then that ;)
      • We pulled a snapshot of FreeBSD 5.0 a year ago.
        Here's a few tid bits:
        uname -v
        FreeBSD 5.0-CURRENT #0; Mon Oct 30 20:41:51 EST 2000
        root@servername_here:/var/obj/usr/src/sys/GENERIC

        uptime
        1:55PM up 367 days, 2:31, 1 user, load averages: 1.00, 1.00, 1.00

        Running flat out since it's only compile from cvs.
        • It's certainly impressive and all, but -- if you aren't interested in recompiling it, playing with it, keeping track of its progress, possibly helping out with development/debugging -- why are you using -current at all? Was there some crucial feature which you needed and couldn't find in -stable?
      • The same is possible and has always been possible for FreeBSD. You can grab the entire source tree whenever you choose, then build your own system. If this doesn't suit you then snapshots are made daily, just not an ISO. There's really no point in building a 650MB image daily when there are better methods for keeping up to date.

        Perhaps next time please look into things before boasting that Slackware does something that FreeBSD doesn't.
        • brtb:
          Well, at any time you want you can download a snapshot of Slackware's current tree, which is the development happening in realtime... probably can't get any faster beta releases then that ;)

          essdodson:
          Perhaps next time please look into things before boasting that Slackware does something that FreeBSD doesn't.

          ::looks:: now where did I say something against FreeBSD? I was just responding to the original poster who asked...

          Jeff Probst:
          Do any of the linux distros have a beta release program as excellent as FreeBSD's?

          Sure I was saying good things about Slackware, but I didn't mean to imply that FreeBSD didn't have similar development methods; if I did I apologize, that wasn't intended.

        • er,

          from: http://snapshots.jp.freebsd.org/

          ftp://snapshots.jp.freebsd.org/pub/FreeBSD/snaps ho ts/i386/ISO-IMAGES/

          Burn it, and you can install latest FreeBSD by CD-ROM. These images are updated every 06:00 GMT (about an hour to finish). All CD-ROM images are "bootable"; you can install FreeBSD without floppies.

          Bootonly" CD-ROM is only 3 megabytes, contains CD-ROM boot image and some installation documents. No ordinary distributions are not in this CD-ROM image. You can fetch whole distribution via network or other media.

          "Live" CD-ROM is a bootable (single-user mode) live filesystem. All FreeBSD base distributions are extracted to this. You may want to use this image instead of fixit.flp, since all commands are available. CAUTION:I don't know why, but 5-current kernel can't mount CD-ROM for root filesystem. As a result, live-current.iso boots fine but that's all (if you have any other filesystems for root). Of course you can use live-current.iso as a live filesystem CD-ROM (mount and browse/copy files).

          "Duplex" CD-ROM contains both 4-stable and 5-current distribution. No kidding you... when it boots, you can select which version of FreeBSD to install. Maybe suitable your freebsd-users-group event :-)
          ----
          Jason

  • background fsck (Score:3, Interesting)

    by mjed ( 514439 ) <cohen@fuckMicrosoft.com> on Monday April 08, 2002 @06:38PM (#3306510) Homepage
    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.

    • Re:background fsck (Score:5, Informative)

      by ChadN ( 21033 ) on Monday April 08, 2002 @06:47PM (#3306548)
      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)
      • Sigh, at least get the name right, even if you have no id ea how the technology works.

        -sirket

    • Re:background fsck (Score:2, Informative)

      by Aniquel ( 151133 )
      To quote: "fsck(8) now has support for foreground (-F) and background (-B) checks. Traditionally, fsck(8) is invoked before the filesystems are mounted and all checks are done to completion at that time. If background checking is available, fsck(8) is invoked twice. It is first invoked at the traditional time, before the filesystems are mounted, with the -F flag to do checking on all the filesystems that cannot do background checking. It is then invoked a second time, after the system has completed going multiuser, with the -B flag to do checking on all the filesystems that can do background checking. Unlike the foreground checking, the background checking is started asynchronously so that other system activity can proceed even on the filesystems that are being checked. Boot-time enabling of this feature is controlled by the background_fsck option in rc.conf(5)."

    • Re:background fsck (Score:4, Insightful)

      by mosch ( 204 ) on Tuesday April 09, 2002 @03:02PM (#3311811) Homepage
      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.

    • I hate defragmenting my drive every so often. Computers should be able to run indefinitely on their own!

      Does FreeBSD or any other OS already have background defragmenting that does not cause danger to the files on disk with regard to crashes?

      We are going to need a background defragmenter anyway as soon as non-volatile ram is here (like MRAM). Or doesn't RAM (HEAP?) fragment in the first place?

      I'm no expert but I've never heard of it. And I do think it's a basic necessity.

      Can anyone please tell me if background defragmenting of HD or RAM is already here or not?
      And if not, please tell me if you think we'll see something like this anytime soon.

      thanks.
      • FFS (the filesystem used by the BSDs) is designed not to require defragmenting, not in the sense of Microsoft FAT-type filesystems. (FFS uses different algorithms for laying the data out on disk, which I unfortunately can't explain well enough to be of use.) So it's kind of a non-issue here.

        RAM fragmentation: "Fragmentation" is a vastly over-used word in the computer world. As applied to filesystems, it means a suboptimal layout of disk blocks on the disk, therefore requiring lots of seeks to read/write the data blocks. RAM disks are random access, and it generally takes the same amount of time to grab a disk block from a RAM disk no matter where it is. The word "fragmentation" can be applied to memory but in a different context that what you cited.
      • >Does FreeBSD or any other OS already have background
        > defragmenting that does not cause danger to the files on
        > disk with regard to crashes?

        Here's these freebsd guys, they work hard and produce yet another amazing trick. Then you go and ask for something completely different.

        On the other hand, yeah, you're right. Unconscious defrags, that would be ultra cool. DEAR FILESYSTEM PEOPLE: WE WANT IT ALL. ALL AT THE SAME TIME, without THINKING.

        Personally, I want my laptop to be able to crash, in the middle of building software, and it's no big deal. Recently I had the battery run out while building, and the root partition wouldn't fsck anymore. Wasted!! (suse 7.1 running 2.2.18; build partition was ReiserFS, root partition was ext2. I'm sure other linux's are ==ly suspect.) I cleaned thoroughly and reinstalled (root is now ReiserFS).

        Not what you would call consumer friendly.

        Extra credit: after rebooting, resume the make, from where it left off.
        :-)

  • Dropping 80386 from default kernel: Good Idea (Score:5, Insightful)

    by finite_automaton ( 302001 ) on Monday April 08, 2002 @06:50PM (#3306565)
    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.
    • 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
      • You have to ask youself, who would be using an outdated i386 and at the same time keeping current with FreeBSD? You can pick up Pentium Is or old 486s for next to nothing. They are not asking you to "track the latest revision of every hardware component", but instead keep within the last say 8 years. If you have the time to track the latest FreeBSD release, then you have time to throw together a new box. If you have special needs for using an i386 box and nothing else will work, then make world on another computer and install over nfs. There are just so few running an i386, why kill performance for the whole? I never use the GENERIC kernel, but those new to FreeBSD (like the dumbass writers who do their non scientific benchmarking) use GENERIC and their performance suffers. Building a new kernel is easy, but many do not know how.

        P.S. Having high uptime just shows that you have a lazy admin and a system with exploits.
        • I confess the last bit was trollish, using loaded words like uptime and IQ to draw out goats - I was hoping for something tastier than lazy exploits, but kudos on the temperance. In deference, if the none of the significant updates are kernel related, then there is no reason to bring down the system. I suppose 3-5 months covers (in days) the mean IQ of any general populace. Perhaps that is enough time to uncover a corruption related issue in the kernel worthy of a power cycle.

          Yes, I actually agree with the general thrust of your post. I am just against artificial obsolesence of hardware, even if there is an abundance of superior alternatives available. If landfill material can instead be tools, then that is a Good Thing. Cutting 386 support while retaining i486, or even up to Pentium Pro support, will not make a dent on any "real world" benchmarks, much less "kill performance". To gain any performance worth noting, you need at minimum a custom kernel. Damn the dumbasses and their toy benchmarks, is that the influence that should shape a genuinely useful system? If a company's oversized paperweight can be usefull to a non-profit interest, then is .05% of 2 Million KHz really a more significant consideration?

          Expedient "out-of-box" support for maximal hardware should be a primary goal, even a stand alone 386 if it is feasible. Once any P4 is running, a simple kernel recompile would be almost insignificant anyway... the userland is a significant part of the performance equation. If you want the ignorant "journalist" to see the glory of FreeBSD via their myopic benchmark, the answer is to have make world a part of the standard install for all performance oriented systems. If you still need to impress the writer who can't be bothered to select the "high performance install" option, then have the installer automate the make world on all hardware more recent than the Foo86. This is the Right Thing To Do in any case, and without the high-end performance strawman, there is no reason to drop older hardware support in current releases. The unfortunate alternative is the start of a very bad precedent, and each successive generation would be easier to cut. Where exactly would the line be drawn? At the Intel shareholders meeting? When it comes to technology, the slope is in-deed very slippery.

          Also, keep in mind that older hardware can still be useful for maintaining performance as a reference point. When 4.0 outruns 5.0, then perhaps it would be a good time to hunt down whatever code bloat has been introduced. If this drag was not the foreseen result of an engineered tradeoff to gain scalability, then the 386 has performed a valuable service as the whistle-blower. Flexibility is an asset, and shouldn't be pissed away.
          • After thinking about this for a while, I realize that having i368 support would not be that bad. Having it install on the most hardware is most likely the best option.

            What I would like to see is a option after sysinstall has finished up to build a custom kernel if sys was installed. Maybe it could take the information from dmesg and set itself up to be optimized for your processor and maybe even remove hardware not on your system. I doubt I would ever use it, but a new user may. And it would save them the time of searching through LINT. I have always wondered if a loaded module would be slower then if it were compiled in the kernel. I usually compile everything I need in, so running a higher securelevel won't stop me from loading what I need.

            Your make world idea in the install sounds great. I wonder if doing a make world with CPUTYPE=iXXX or CFLAGS options in make.conf would increase performance by any further distance. I will have to see. I have not done a make world in a while :)

      • 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.
    • Almost nobody should be using the GENERIC kernel by default anyways. The only reason to do that is if you don't understand the kernel config file (which is, admittedly, not an easy thing to grasp for newbies).

      The GENERIC kernel ought to boot just about everything, IMO, simply because it is "generic".
  • Anyone know how the snapshot feature is supposed to work, or have any experiences with it that they'd like to relay?

    It sounds similar, if not identical, to what an ISP of mine used around 1994-1995 (and perhaps still do). They had a NetApps filer for their users' home directories, which provided a few .snapshot directories.

    Inside of .snapshot were the ghosts of ~ past. Which was -very- nice when you changed or deleted something and then change your mind about it hours, days, or weeks later. One could go back in time, and retrieve any of several periodic revisions of anything which had been modified.

    Incidentally, the aforementioned shell box was also running FreeBSD, although a much earlier incarnation than that being discussed here.
  • "The kernel is now aware of the concept that there are smaller units of scheduling than a process (but only one thread per process is allowed at this time)."

    The one feature I've been waiting for the most isn't quite there -- kernel-land threads.

    Still though, I'd rather have it right than 'ready'.

    besides, I'm relieved that I can continue to listen to my euro trance shoutcast stream uninterrupted by ISO image downloads ;)
    • The one feature I've been waiting for the most isn't quite there -- kernel-land threads.

      I'm not sure what you mean here. Threads that exist entirely in the kernel have existed for some time now. If you're talking about kernel-scheduled userland threads, then yes, they are not quite there yet. Note that this is different than linux threads, which are just forked processes that happen to share the same address space. FreeBSD can do that too, and in fact has a 'linux-threads' package.

      • Re:Threads (Score:2, Informative)

        by Anonymous Coward
        What he means is: kernel-land threads as opposed to user-land threads. Kernel threads are independently schedulable (the scheduler deals with threads not processes), user threads run in one process and take turns executing within that process's cpu allocation (timeslice) using a library to switch stacks and do partial context switches. User threads are not seen by the kernel and are not independently schedulable by the kernel. I.e. if one user-land thread blocks, none of the user-land threads in that process will run since the kernel only schedules the process, even if these threads are capable of running. Also, within a single process, user-land threads cannot execute in parallel on SMP machines while kernel-land threads can.

        Threads that exists in the kernel are probably currently implemented in a way similar to linux's clone and FreeBSD's rfork(): they are probably really processes sharing the kernel address space.

Slashdot Top Deals

For God's sake, stop researching for a while and begin to think!

Close