Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Announcements Operating Systems Software BSD

FreeBSD 5.3 Release Candidate Released 135

Posted by timothy from the now-it's-on-probation dept.
Cronopios writes "The FreeBSD Release Engineering Team has just announced the availability of FreeBSD 5.3-RC1. This will likely be the only Release Candidate before the final release of 5.3, so please give it a try and report/fix any bug you find. You can read the announcement, check the schedule and the 'Known Issues' (problems that are still being worked on at this time)."
This discussion has been archived. No new comments can be posted.

FreeBSD 5.3 Release Candidate Released More

FreeBSD 5.3 Release Candidate Released

Comments Filter:

  • Bind version changed (Score:5, Informative)

    by Cronopios ( 313338 ) on Wednesday October 20, 2004 @08:46AM (#10574731) Homepage Journal
    An important difference is that BIND 9.3.0 has replaced BIND 8.x as the default name server.
  • This is very good news.

    I've been working with 5.3 beta 7 for the last few weeks. It is such a great system!

    Perl 5.8.something is on there and even applications like WebGUI [webgui.nl] work like a charm. :)

    I hope the official will be out soon. :)

    • Re:Very good news (Score:3, Interesting)

      by gtoomey ( 528943 )
      I've been doing the same, & the only problem I found was that I could only boot in safe mode with an nforce motherboard. KDE is looking good.

      I'll try it my wireless usb adaptor soon.

      • I had a similar problem on my AMD 64 box, I don't know if this problem is related to yours, but compiling a kernel without ACPI worked like a charm.
        • Ah, it just occured to me: compiling the kernel without acpi is the suggested way. From /usr/src/sys/i386/conf/NOTES:
          # Note that building ACPI into the kernel is deprecated; the module is
          # normally loaded automatically by the loader.
          device acpi
          options ACPI_DEBUG
          options ACPI_MAX_THREADS=1

      • Re:Very good news (Score:4, Informative)

        by inquisitor ( 88155 ) on Thursday October 21, 2004 @03:36AM (#10584142) Homepage Journal
        Have you got plug-and-play-OS turned on in your motherboard BIOS? If you do, turn it off; FreeBSD 5.x (and some later 4.x) has problems with the option, and Windows doesn't need it anymore. I didn't have to turn off ACPI that way...

        (This is occasionally listed as "Device Configuration" or whatever, like on my Toshiba laptop, in which case the right answer is "All Devices".)

  • Binutils upgrade (Score:2, Informative)

    by theapodan ( 737488 )
    Basic binutils are upgraded too, but I find it particularly interesting that the Darwin msdosfs tools are getting incorporated into the BSD tree.

    Cool.

  • Scheduler? (Score:1, Interesting)

    by Anonymous Coward
    So how come they're not using the new scheduler?

    • Re:Scheduler? (Score:4, Interesting)

      by 1UnixGeek ( 823787 ) on Wednesday October 20, 2004 @01:16PM (#10577872)
      There appear to be bugs in the new SMP scheduler (SCHED_ULE) that no one can track down that cause mysterious crashes and lockups when a system is run under heavy load. The real issue seems to be that only a couple people in the project understand the complex kernel threading model enough to be able to find and resolve bugs, and even they don't seem to be able too most of the time ?

  • 4x vs 5x performance (Score:2, Interesting)

    by Anonymous Coward
    Hi

    I have been following news for quite a while now and I have tested several fbsd releases form
    4.X and 5.2.1 releases from all I have noticed is that I liked 4.X very much especially the memory management, harvest performance, actually the overall performance and the widely available documentation, well that's one of the main reasons why freebsd is known to me.

    Know you guys coming close to the 5.3 -stable release alot of users are going to upgrade/switch, right, because this is what we have been waiting f
    • "As all you have noticed the above^ part, will fbsd have the same performance or better? When will this be ready 5.3.X ? Could I get some more accurate information about this? Since I'm planning to use it on my desktop." You don't want a 5.3.*X* release, as 3-numbered released on FreeBSD are used to address critical bugs. Let's hope it stays 5.3-RELEASE/STABLE, heh.

  • FreeBSD 5.X issues (Score:3, Interesting)

    by PinkFluid ( 23536 ) on Wednesday October 20, 2004 @09:28AM (#10575093)
    Am I the only one that feels that FreeBSD 5.X has gone in the wrong direction?

    I run FreeBSD 5.X on my desktop since I don't feel it's ready to replace the production servers running happily with 4.X; and 5.X and the desktop feels very sluggish and slow in many areas compared to 4.X.

    Maybe 5.X is faster on SMP, but on uniprocessor I think it's definitely a set-back compared to 4.X.

    I feel FreeBSD 5.x is not yet ready, even it's almost 2 years late based on the original predictions(5.X-STABLE at least).

    I don't want to start a flamewar, it's just that I cannot get rid of this bad aftertaste that 5.X left me with.

    I really really hope FreeBSD improves over time - it was a fine OS. Meantime DragonFlyBSD is something to keep an eye on ... it sounds promising, although only time will tell...

    • Re:FreeBSD 5.X issues (Score:5, Interesting)

      by martin ( 1336 ) <maxsec@nosPaM.gmail.com> on Wednesday October 20, 2004 @10:17AM (#10575579) Journal
      Looking at the 5.3 issues on questions@freebsd.org most people wouldn't trust 5 as stable yet, and on a uniprocessor most say 5 is slower than 4.x.

      I do note there are tentative plans for a 4.11 release, but as most of the work is concentrating on 5.x it's existence maybe a still birth.

      BTW MacOS X 10.4 (Tiger) is based on 5.x rather than 4.x technology so someone's trusting enough..

      And yes 5.2.1 is definitely fast on SMP systems then 4.10.

      • Re:FreeBSD 5.X issues (Score:4, Informative)

        by Drishmung ( 458368 ) on Wednesday October 20, 2004 @03:09PM (#10579111)
        BTW MacOS X 10.4 (Tiger) is based on 5.x rather than 4.x technology so someone's trusting enough..

        That's just the BSD subsystem---i.e. userland. Memory and I/O in particular have almost nothing in common with BSD and so FreeBSD UP vs MP performance etc. are not going to have any effect on Darwin.

        I'd be interested to know long it will be before the ports tree has reasonably complete support for 5.3.

        • I'd be interested to know long it will be before the ports tree has reasonably complete support for 5.3.


          That's easy: now.

          The ports tree supports both branches, and most updates are tried on 5.x before 4.x, so the ports support for 5.3 is quite good.

          Anedoctal evidence: all but one of the ports I tried to use work on 5.3 (the exception was a direct connect client). That include ALL that comprises a full workstation (Linux feature complete, so to speak).
          • > Anedoctal evidence: all but one of the ports I tried to use work on 5.3 (the exception was a direct connect client). That include ALL that comprises a full workstation (Linux feature complete, so to speak).

            Just as anecdotal..

            ever got multimedia/mjpegtools to build on 5.x?
            (its about the only reason for me to keep compat4x support around on my fbsd 5 workstation)

            Most of the ports tree does work quite well tho.

        • This is true - MACH kernel underneath, but alot of the stuff about the relatively small kernel is 5.x based, more than the pure userland stuff.

          The MACH kernel is very small is needs alot more 'support' from userland stuff than GNU/linux or FreeBSD does. I guess it depends on where the code breaks are for MACH and how much of the 5.x kernel is added on to it in terms of drivers etc.
          • Darwin is a monolithic kernel [opendarwin.org], a mixture of Mach, FreeBSD and IOkit.

            My understanding is that IOkit is quite different from Mach or FreeBSD---to the extent that drivers have to be pretty much rewritten from scratch. I also thought (though I'd be happy to be corrected) that the memory subsystem, and in particular the multiprocessor stuff, was mostly Mach. In fact, mostly 'Darwin' by now.

            If the 'problematic' bits of FreeBSD 5.x are in the memory, threading and driver sections, then I would not expect those to

    • Re:FreeBSD 5.X issues (Score:5, Informative)

      by agshekeloh ( 67349 ) on Wednesday October 20, 2004 @10:33AM (#10575731) Homepage
      5.X still has all of the debugging options on by default.

      This can cut your performance by a good 50% or so.

      Debugging gets turned off last thing before release. (I'm not sure if a RC has debugging or not, mind you, but the BETAs certainly do.)
    • The 5.x branch is not targeted at production use before it's first stable release.

      As an other poster already said, the unstable and rc branches contain debugging code that cost performance. Don't let the stability of 5.x fool you into thinking it to be a final system yet. The team did a great job introducing loads of new features, pushing FreeBSD on top of current technology again, but polishing these new features (which actually should bring 5.x to beat 4.x performance wise afterwards) will mainly happen
      • I tried everything, even turning off debugging and SMP and recompiled the kernel. It helps a bit, but it still feels sluggish. I will wait until -RELEASE comes out, and if the proformance is still not whre it should be then I'll start seriously looking at the alternatives ...

        • Is it really the OS itself that is sluggish, or is it Xorg and X type apps that are sluggish?

          Two different things, and it could all be perception. ;)
          • Well, actually it's X + KDE.
            • How sluggish KDE is? For me it works quite nicely (see my post below) - even though I load up a load of things at startup (lots of applets, oooqs - openoffice quick starter -, etc.). I'm only asking because if it is extremely sluggish, check if you have tcp/udp blackhole set to 2/1 respectively - that slows things down quite a bit. I know, of course, that 'it works for me' is not particularly helpful though.. :/
    • The thing that *really* is of concern for the future of FreeBSB 5.x is the very complex SMP/Thread coding model in is used in 5.x and the fact there only seems to be 2-3 individuals on planet earth that are able to fix and fix bugs in the code. (See the recent posting(s) in the -arch mailing list for some examples of this. This is really a cause of major concern for the future of 5.x. Matt Dillon (aka the Dragonfly BSD project) has constantly been sounding alarm bells about this but no one on the project se

    • Re:FreeBSD 5.X issues (Score:5, Informative)

      by Brandybuck ( 704397 ) on Wednesday October 20, 2004 @12:46PM (#10577457) Homepage Journal
      If you have not already done so, TURN OFF the debugging switches in your kernel. Non -RELEASE versions of 5.x are going to have major performance issues simply because they've got so many debugging switches on. So turn them off, or wait for -RELEASE to appear in a couple of weeks.

    • Re:FreeBSD 5.X issues (Score:2, Interesting)

      by guroove ( 231050 )
      Someone please correct me if I'm wrong, but wouldn't taking out the smp lines in the kernel config fix the problem of slow performance on single CPU systems? I have had 5.3-Beta on an old 433 MHz system for a few weeks now, and I have been using it as my home NAT machine. It routes packets way faster than by linksys router did, and seems to be much faster than a similar system I installed at work that runs FreeBSD 4.10-STABLE.
      • I tried disabling both debugging and SMP, and it helped, but still seems FBSD 4.X is still MUCH faster on the desktop and UP system.

        Also note, that these is just the "feel" of the desktop. I did not perform any serious benchmarks and other things, so it is 100% subjective.

      • Correct. And the SMP options have been removed from GENERIC for 5.3-RELEASE. This means that a default install of FreeBSD 5.3 will include a non-SMP kernel. They will be including docs for creating an SMP kernel after installation, and are investigating a method for shipping both a UP and SMP kernel, giving the user a choice of which to install. They don't expect that to come through until 5.4, though.

        Here's [freebsd.org] the Head's Up message posted to the -current mailing list.

    • I ran FreeBSD 5.3 since beta3 on my desktop, and beta 5 (booo!!!) on a server (don't start shouting at me, it is a low traffic webserver/firewall/nat - I know, I know...). Desktop performance: with ULE (I don't need preemtption) it is simply fantastic!! Sometimes I have to check if portupgrade/make is still running, because I almost can't tell the difference (playing movies - divx/xvid - in mplayer, using openoffice, whatever). Don't qutoe me on this (this is totally subjective!) but I feel KDE 3.3 more res

    • Re:FreeBSD 5.X issues (Score:3, Interesting)

      by Baki ( 72515 )
      Did you recompile the kernel without WITNESS option?
      The beta GENERIC kernels have lots of debugging which slows down a lot.

    • DragonFlyBSD (Score:4, Informative)

      by ceallaigh ( 584362 ) on Wednesday October 20, 2004 @04:47PM (#10580274)
      If you have concerns about the path being taken for FreeBSD 5.x, I highly recommend you take a look at DragonFlyBSD.

      DragonFlyBSD [dragonflybsd.org]

      DragonFly is an operating system and environment designed to be the logical continuation of the FreeBSD-4.x OS series. These operating systems belong in the same class as Linux in that they are based on UNIX ideals and APIs. DragonFly is a fork in the path, so to speak, giving the BSD base an opportunity to grow in an entirely new direction from the one taken in the FreeBSD-5 series.

      • Re:DragonFlyBSD (Score:2, Interesting)

        by archen ( 447353 )
        Kernel stuff aside, does Dragonfly lean towards the 4x userland or 5x userland?

        • Re:DragonFlyBSD (Score:2, Informative)

          by setagllib ( 753300 )
          It was forked from 4.x so large portions of userland are still 4.x's, but have had imports that bring many components up to 5.x and beyond (e.g. RCNG from NetBSD/FBSD5.x, gcc 3.4 snapshot [not default nor exclusive since some kernel/boot bits aren't compatible]).

          DragonFly BSD is a "too good to be true" project, I would have to say. Its developers are highly talented and very quick in their work, and the stability has been very high given the massive changes made to vital kernel facilities. Sure there hav
    • I love 5.2.1 on the desktop, avoid it on servers. The only servers I have with 5.2.1 are the ones with dual processors, all others run 4.10-STABLE and have been up for many, many months. I'll wait and see how 5.3 does. I won't be upgrading my desktop (at least for now) which is running 5.2.1-RELEASE, because I'd need to rebuild pretty much everything -- and we all know how XFree86 and GNOME upgrades tend to be a pain in the ass. As for the server market, I'm waiting on 5.3 for two months now for a dual xe

    • Re:FreeBSD 5.X issues (Score:2, Informative)

      by anholt ( 3908 )
      Desktop sluggishness is something that gets complained about a lot, and I know I hate the feel we have on the desktop right now. Currently, scheduler work has been focused on 4BSD with server loads, notably mysql. SMP performance with supersmack (mysql test) has gone up something like 50% in the last few months, thanks to netperf and 4BSD scheduler improvements. What would be nice to see is somebody fixing ULE (the new scheduler) both in terms of server performance and fixing those remaining bugs, since

  • How? (Score:3, Interesting)

    by captnitro ( 160231 ) * on Wednesday October 20, 2004 @11:58AM (#10576772)
    I have a question. I have a number of small systems of varying specifications (all x86) and I'd love to be in on stress-testing 5.x; I'd love to have been in on testing all the BETAS. But my daily operations in FreeBSD are limited to working in Gnome or XFCE under a few IDEs, compiling ports, doing some maintenance work on servers, playing games, reading Slashdot, etc., none of which I find particularly stressful to the system. If it was, I would be inclined to believe it was a port problem, not a system problem.

    What is the best way to stress test FreeBSD that will put it through its paces?

  • Something of note (Score:5, Informative)

    by the real darkskye ( 723822 ) on Wednesday October 20, 2004 @11:58AM (#10576774) Homepage
    If you've been tracking 5.3-Beta and want to switch to the RCs and eventual RELEASE, don't forget to change your cvsup tag to RELENG_5_3 else you will end up with 5.3-STABLE, which isn't.
    • For those tracking the release, the RELENG_5_3 tag for cvsup is working. Right now, there's not much difference in the source trees for RELENG_5 and RELENG_5_3, and changes could still be made to the RELENG_5_3 tree, so it's not the official release bits just yet.

      But, you can start updating your cvsup supfiles in anticipation. :)

  • anyon want to bet on the actual release date? (Score:3, Interesting)

    by CaptainPinko ( 753849 ) on Wednesday October 20, 2004 @12:43PM (#10577397)
    when I first saw the schedule when it said October 17th I was betting on Halloween, but now I think it may be longer. With that many Known Issues and one marked as "errata candidate" and with that many "Needs Testing" I'm guess that either a) FreedBSD 5.3 will be released in the Beginning of December (last of the majour BSDs to release) or b) 5.3 will be called the first stable but 5.4 will really be.

    Anyone have any predictions?

    • I think 5.3 will be quite STABLE. On the other, I don't think 5.3 is a real 5.x release. I know it sounds silly, but as long as the old 4BSD sheduler is the default scheduler, I consider it something like a hybrid. I know this is just one thing of the many improvements/features of the 5.x branch, but this is the one (as a desktop user) I feel mostly. Of course I use ULE, but this switch back (for the sake of PREEMPTION) gives me the feeling of incompleteness.

      Hopefully, as soon as the release process is over, they will switch back to ULE in -current (officially, that is. in every dmesg/kernel config file I have seen on current, most developers run ULE). And I hope 5.4 will be the ULE release!

      So, to answer your question: yes, 5.3 will be STABLE (and not only in name. the whole 5.x series is fairly stable, at least beginning with 5.1, or at least as stable as your average linux distro). I think it will be out on my birthday :))) (nov 11). But I also think that 5.x will be really ready when they have ULE back as default (ditch preemption if it needs be, ULE is so much better in every other aspect).

    • pssst! it's out :))))
      Updating collection src-all/cvs
      Edit src/UPDATING
      Add delta 1.342.2.13.2.2 2004.11.04.18.52.55 scottl
      Add delta 1.342.2.13.2.3 2004.11.04.19.12.41 scottl
      Edit src/share/misc/bsd-family-tree
      Add delta 1.82.4.2 2004.11.04.19.11.55 scottl
      Edit src/sys/conf/newvers.sh
      Add delta 1.62.2.15.2.5 2004.11.04.18.51.30 scottl

  • ndiscvt (Score:5, Informative)

    by Burb ( 620144 ) on Thursday October 21, 2004 @06:32AM (#10584760)
    The ndiscvt tools that allow you to convert your NDIS network drivers into kernel modules works really well (at least in BETA7). I'm very impressed. (My only gripe was that it had problems reading my .INF file because it was unicode; I converted to ANSI and all was well). I can now run a pretty good GNOME desktop on my Acer laptop with wireless access.
    • Anyone tried this with the Intel Pro Wireless (Centrino) cards? I've to a T42 coming soon, would like to have it work on the Intel card, otherwise I'll have to find an Aironet on ebay. I've seen it mentioned as an example, but do the drivers really work well, or is it worth getting more compatible hardware?
  • I have had almost no problems. My system is almost always under load. Except randomly when compiling I get "cc:segfaults". I can restart the make process and it will skip on through. Some times it will segfault elsewhere depends on how long the compile is. Then sometimes it will go through a long compile without incident. Doing a "make -jX" doesn't seem to make a difference. My cflags are basic "-O2 -pipe" with the processor type set at "p2". I don't think it's hardware no other applications segfault or any
    • I had the exact same problems (segfaults only during compiles at random points) until I realized it was my crappy sdram. I have an AthlonXP 2400+ and my mb can accept either sd or ddr rams. Wheny I had 256Mb sdram, I had to change the FSB of my processor and ram from 133 to 100 (proc was recognized as XP 1800+) in order to have everything build properly. Later, when I upgraded to 512DDR, all my problems went away.
      • Hey cool, thanks. Well I'm not too excited about running memtest on it. It's got 3 ram slots. With a 256, 128, 64. Found another 64, I just swaped them... maybe that will be the bad one. I can always hope.

Slashdot Top Deals

Sentient plasmoids are a gas.

Close