The FreeBSD Release Engineering Team is proud to announce the availability of FreeBSD 5.3-BETA4. This is the fourth BETA of the 5.3 release cycle. It is intended for early adopters and those wishing to help find and/or fix bugs.
FreeBSD 5.3-BETA4 available
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Is it possible to easily FreeBSD from BETA4 to RC1 and the Final RC to the actual release? I’ve only had minor experience with FreeBSD 4.10.
Mainly, i use Mac OS X Panther and Slackware 10/Current.
Typo in my above post:
Is it possible to easily upgrade FreeBSD from BETA4 to RC1 and the Final RC to the actual release? I’ve only had minor experience with FreeBSD 4.10.
Mainly, i use Mac OS X Panther and Slackware 10/Current.
Yes, should be possible without any problems. See the excellent FreeBSD Handbook for more informations.
Thanks, I’ll check that out
i guess this release will also have the latest KDE release 3.3 ….
Yes, it will, but won’t have GNOME 2.8 since port freeze is effective for 1 more week, and the packages for release 5.3 are being built and tested already.
Where are the new iso files
http://ftp.freebsd.org still has BETA3
You’re right, there’s no BETA4 iso files currently on either http://ftp.freebsd.org or http://ftp.nl.freebsd.org mirror.
I’ve just checked the UK mirror and that does have the BETA4 iso files :
ftp://ftp.uk.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/5.3/…
Hope this helps.
i did chech some mirrors but none off them had the BETA4
The uk mirror i did not check
Thank you for your time
yes yuo can, you can play all around even from old revisions back and forth. Thats the beauty of concurrent file system and freebsd easy updating aproach.
Despite its not recommend to do it from big releases. ex: 4.x -> 5.x or 4.x -> 3.x etc.
and the same does apply for “binary” upgrading, usually done from de CD.
make sure u read the /usr/src/UPDATING and the pretty fine handbook, on cvsup/make world section, as already someone pointed out
Nice to see things moving along. A little sad about the ULE scheduler.
I felt the same way about ULE, but at least it sounds like the switch is just buying time to track down recent issues.
http://lists.freebsd.org/pipermail/freebsd-current/2004-September/0…
This is a better link.
http://lists.freebsd.org/pipermail/freebsd-current/2004-September/0…
Then again, 4BSD scheduler isn’t *that* bad, sure, it doesn’t have the bells ‘n whistles of ULE, but from my experience, multi-tasking with it isn’t bad; whilst not awsome, it does the job, and is stable.
Kudos to the FreeBSD for once again putting stability ahead of the gee-wizz factor; we’ll actually have a stable release which is stable, not to start a flame war but it took atleast 20 revisions of the 2.4 kernel *just* to get to the point of stability, 2.6 is lining up to be the same situation.
So is FreeBSD 5.3 using the ULE scheduler our the 4BSD scheduler? All they talk about is that 6-CURRENT is using 4BSD…
I cvsuped RELENG_5 last night. The GENERIC kernel file now lists 4BSD as the default scheduler. I just hope updates to ULE get merged from 6-CURRENT.
I agree with kaiwai, stability first is the hallmark of BSD. I prefer development of ULE to take longer and end up better.
6-Both CURRENT and RELENG_5 switched to 4BSD because it makes it easier to test patches on 6-CURRENT and then apply those on RELENG_5 without having to test for a new scheduler.
When the ULE stability issues (which are showing mostly on preemption cases) are ironed out (after 5-STABLE and 5.3 is released), I think we’ll see 6-CURRENT switch and then later hopefully 5-STABLE also for a later release (5.4 should be awesome).
What exactly is the big deal if they go back to the 4BSD scheduler by default? Anyone can recompile if they absolutely must have or want ULE. It isn’t like it is being deprecated or anything. I definitely give them kudos for trying to make the DEFAULT install stable. Anyone who wants to go through the trouble of enabling experimental stuff has the kernel source and can do a recompile to enable whatever they want.
What I’m sad about in a techno geek kinda way is that ULE is having issues still. I was hoping it would be at a much more stable place. I’m not upset that they are going with the stable vs the latest and greatest.
For me I’m not running enterprise stuff on my machines. They are develpoment boxes and 4BSD seems just fine to me. But I do like progression to new technology even if my eyes can’t tell the difference.
And again my thanks to the FreeBSD team for such an awesome OS.
We’re getting really sick of seeing you trolling in the BSD threads there “buddy.” Stick with your precious Linux stories and leave us be.
You’re not welcome here.
There is no big deal PERIOD
As far as I can tell ULE is the future but there seems to be some issues with the code maintenance of ULE (lack of time from the maintainer and developer of ULE? I don’t know. Someone please fill in).
ULE was fine for most cases and scenarios until the preemtion patches were brought into CURRENT. Before that 4BSD was more stable under some conditions such as very high load and had better performance characteristics with databases but ULE was more responsive under most loads. Now they are going to add patches to 4BSD to mitigate and bring it up to speed under most cases. ULE is more SMP friendly, though, and since that is where the CPU:s are going with multicores and all, then that is where the future lies.
I think it is a wise decision to pass ULE on 5-STABLE until it is solid with the new core of FreeBSD. When it is solid I’m sure it will rock though. My testing of ULE showed excellent responsiveness in Gnome (better than 4BSD) so I’m gonna use it for my desktops and leave the servers on 4BSD.
True, and the one thing alot of techno geeks also need to realise that pre-empting a kernel is not an easy past time; when you’ve got a new scheduler plus pre-empting plus removing the HFL (Huge F*cking Lock), things were bound to go wrong and thus require scaling back.
If it were me, I probably would have first focused on removing the HFL, then once thats achieved, then work on implementing pre-empt and the scheduler.
I wish I knew half of what you guys are talking about.
I’ve burned the iso to cd for beta 1 and did a binary update to my 5.2.1 system. then tried to get kde3.3 but in the middle of “make” it would complain about some problem in /usr/src. well there was nothing in /usr/src/. same thing when i did the binary update from beta 1 to 2. With beta 3 I did a fresh vanilla install and checked /usr/src/ and plenty was there. I cvsup’ed using ports-supfile and finally I have kde3.3 on freebsd 5.3. cool!! (if i did not cvsup i would have installed kde 3.2 from the default set of ports)
i want to keep my existing kde3.3 so I will do an upgrade from beta3 with the beta4 cd. i suspect this will remove items in /usr/src which will brake my ability to upgrade kde3.3 because, as I said before the “make” is looking for something there.
i don’t want to do “make world” and recompile and all that stuff. I’m a virgin and scared. i may have to take that dive though.
(by the way, gnome2.7.92 did not mind the missing /usr/src as it installed and was upgradeable on beta 1 and 2.)
by the way, i just installed slackware10 from a magazines cd and the gnome is looking fine.
by the way, Fedora and Red Hat do not like me. they pout or worse when I get careless. I get mad and throw it out but I always, regretably, try to renew the relationship with each new release.
On the other hand FreeBSD puts up with me quite well. I toss it around and it still says “Hi, what next.” FreeBSD is Rock Stable. Mandrake puts up with me quite well too and is recommended for the masses.
Yes, 5.3 beta4 does come with kde3.3. in light of todays jpeg vulnerability in window world maybe i should stay right here.