Slashdot Mirror

← Back to Stories (view on slashdot.org)

FreeBSD 5.3 Release Candidate Released

Posted by timothy on 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)."

3 of 135 comments (clear)

  1. FreeBSD 5.X issues by PinkFluid · · Score: 3, Interesting

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

    1. Re:FreeBSD 5.X issues by martin · · Score: 4, Interesting

      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.

  2. Re:Scheduler? by 1UnixGeek · · Score: 4, Interesting

    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 ?