Slashdot Mirror
FreeBSD 5.3 RC2 Released
ValiantSoul writes "FreeBSD 5.3 Release Candidate 2 was just released. This new RC includes an updated network stack that fixes a bug where the system stops responding when under severe network load, the complete disabling of the ULE scheduler due to instability, and other fixes. Originally the FreeBSD team decided not to release a RC 2 however the fixes in the latest CURRENT were important enough to do so. As long as there are no severe problems with RC 2, this will be the last test release until a final one. See the full announcement on the mailing lists."
Whell, FreeBaSeD is only on Version 5.3 - speak to the hand, thats so like 2002 retro - You aren't all that and a bag of potato chips.
Like whateva, Solaris is on version 8 and Fedora is on 9, Slickware is leading with 10, Gentoo is Gentoo is.... As if I would use something so not invouge. I run this click so I might just use 2003 since it has such highya numba.
Where is my lip gloss. Don't mess with me. I'm one crazy mo-fo. I once popped a cop cause he wasn't giving my props in Oak town. I've heard that somewhere.
If you're really concerned about the $.20 or the downloading, you should probably just track the branch using CVS until release. Is FreeBSD on 2 CD's now? I thought it was one disk, and one rescure disk.
I've actually given up downloading the entire thing and now just use the mini install cd. For me the first step after setting up a system is always updating the ports tree and installing from ports anyway.
This is just more proof that the folks over at FreeBSD are committed to releasing nothing that's not at-or-near perfect. For sure, nothing will hold the -RELEASE tag unless I'd run it at home if not in a production environment.
Personally, I'm happy that they're more concerned with stability than they are with the release schedual. The bugs in RC1 were pretty severe if not overreaching.
I am really impressed with the work that went into this RC. GDB fixes, plus work on memory allocations and networking data structures.
Bravo! I hereby increase my bid to $52,000.
Sincerely,
Jeff Merkey
(Please remember that directing vitriol against the mentally disabled may be a violation of Federal Hate Crimes statues)
Yeah, but this release is probably just to show off to the NetBSD team that the FreeBSD team has the guts to stick with the demon logo.
Lemon curry???
"1. Why not fix the new schedular?" "2. Why did it take so long for them to realise it wasn't going to work" 5.x has been too slow. They want to release a stable, functional operative system. Despite of the lack of the ULE scheduler there're a lot of stable areas and new features in FreeBSD 5.X which people need in the real world to solve real problems. Hence the "need" of a 5.x-based "stable" release, to leave 4.x behind (just for mainteinance) and start to work 100% with 5.X. The ULE scheduler has some problems but it also has a lot of good things that work, it'll be just delayed to get maximum stability for 5.3. It looks like they don't want to have Yet Another Delay. Other operative systems (linux 2.6, windows, other BSDs) are also a natural competition for freebsd and freebsd needs a stable 5.x to face them because 4.X is just old and misses lots of features. I'd guess the ULE scheduler will be fixed and enabled by default in 5.4.
[Man with OS slung over his shoulder] 'ere's one!
[FreeBSD, slung over shoulder] But I'm not dead yet!
[Man with cart] 'e sez e's not dead.
[Man with OS] Don't mind 'im, what does he know?
[Man with cart] Well
[FreeBSD] Netcraft? Netcraft! Well, that bloody does it!
FreeBSD jumps off the second man's shoulder and begins to club both men, vigorously.
See what I've been reading.
...includes an updated network stack ...
In other news, Microsoft has declared they have just improved the network-stack of Windows XP, making it more robust under heavy loads....
10 ?"Hello World" life was simple then
What is the best way to upgrade to this version? Download the CDs? Through the ports? Do you have some sort of strange method that no one else has heard of? The answer falls under then 3rd option. Although every FreeBSD user should have heard of it. It's called cvsup. Take a look at the FreeBSD handbook. It will describe the process much better than I ever could. Look for the heading "make world".
Understanding is a three-edged sword. -- Kosh Naranek
The ULE scheduler was supposed to be the default scheduler. It was placed as the default in 5.2. Between 5.2 and 5.3 kernel preemption was enabled. Some serious flaws in ULE popped up leading to crashes and other instability. Due to the complexity of ULE and preemption together only a handful of core people are able to fix this.
Since 5.x has been hold back long enough it was decided to drop ULE as the default scheduler for 5.3 and concentrate on releasing 5.3.
This doesn't mean that nobody is working on fixing the problem nor that ULE will not be the default scheduler. It is just going to take a while before it happens.
The reason for totally disabling ULE in 5.3 was to focus on other bugs in 5.3 and fix ULE on current (6.0) and then backport this to a later 5.x release.
I suggest you read cvs-src summaries at http://www.xl0.org/FreeBSD/ which gives a view on what is happening on current.
You should settle to this method as it is the preferred way of keeping your system up-to-date, wether on updating between releases or incooperating security or maintainance updates from the respective RELEASE branches.
Basically after having your source updated to the latest RELENG_5_3 branch, typically via cvsup(1), it consists of the following steps:
# make buildworld
# make buildkernel
# make installkernel
# reboot
single mode:
# mergemaster -p
# make installworld
# mergemaster
# reboot
It is very straight-forward, still be sure to read about the details in the handbook.
I remember a few months ago that 5.3 was the target for making the 5.X branch the official "stable" branch. Any word on when 5.X goes stable if not with this release?
"Watch your cornhole, bud."
Let's not get too huffy here about ULE. Anyone care to bring remember the ugly VM wars of the early 2.4 series? Even now there's still plenty of LKM traffic over scheduling in the 2.6 kernel. The unfortunate thing is that I think a bunch of the work is for naught. I believe Dragonfly (at least in concept) will end up being much more scalable. If that proves true, I'd hope that down the road they re-merge to focus resources on IMHO is the most robust of the FOSS OS's.
> i'm using 1024x768 @75Hz (128 columns of text!) and it's a dream for coding in. i don't wanna use X, so only way i'll be happy in fbsd is if i can get big BIG console windows like this. anywhere from 128 to 132 cols is good enough for me.
(i already checked fbsd web site man pages for wscons, and it looks like 800x600 with 90 cols is the max???)
First of all, you'd need man syscons, not wscons.
At any rate, I'm currently using 132x43 character mode on my console, which works fine as logn as you have a graphics card with a vesa 1.2 bios or better, and have enabled vesa support (either by compiling it into your kernel or by loading the vesa kernel module)
800x600 (with 90 text collums) seems to be the maximum for graphics mode with syscons, but for character mode it seems to rather support anythign that your vesa bios supports.
Som if all you need is a 132x43 text mode screen, then yeah, that will work fine. If you need graphics mode, checkout the manpages on vga, vgl and vesa and see if that woulf work for you.
My daemon pumpkin http://www.joyrank.com/misc/daemon-finish-20041028 .jpg
I did Tux last year with a stencil I found on the net so this year I made the daemon one from scratch. Kinda rough in a few places but overall, I was pretty satisfied with the results.
Cheers,
> This 5.3 release is full of bugs and is slow too.
It certainly has some bugs. Regarding slow, it is far from slow for what I happen to do with it, but it might be for your case.
> It still does not release the Big Giant Lock like it was promised a year ago.
It does for some and not for other cases. It is definitely not free from giant locks for now.
> It looks like it's time to give the DragonFly branch of FreeBSD 4 a try.
I find Dragonfly very interesting but at the moment it is not usable for production for me for the simple reason that it lacks support for hardware that I have and use (and so does FreeBSD 4.x), so little choice there (alternative woudl be to run Linux on that hardware)
What hardware?
Broadcom gigabit ethernet chipset (yea, I know its crappy, but it is on many mid/lowcost systemboards, and it does work well enough for most workstation purposes)
Any graphics hardware with accelerated opengl that actually performs somewhat better then software rendering.
Support for multiple audio cards, preferably with virtual audio channels.
Now, those may not be features you require, fine for you. I do happen to need them, so I will pcik a platform that supports them.
If/when Dragonfly happens to support either smp on a hypersparc machine or most of the hardware that I happen to use every day, it will have a good chance of finding a spot on a machine here.
I wonder about your post tho. Commenting on the scheduler and locking problems is justified tho hardly new, but do you think you are doing anyone a favor by acting similar to that HawkinsOS guy? (ie, hijack each and every FreeBSD related thread anywhere to promote your system of choice while re-iterating the same argument over and over)
I really need to disagree with the previous two posters on this. The early adopter's guide recommends backup-install-restore rather than cvsup from source.
Np, glad to help
I should add, that I found the tag specification somewhat confusing. The default is ".", which is current. Current is now FreeBSD-6.0 probably very unstable.
Your tag should be tag=RELENG_5_3, although it may need to be tag=RELENG_5. I'm pretty sure I read somewhere that for the most up to date 5.3 you need tag=RELENG_5_3. This will make sense after reading the make world section of the handbook.
I did google on the make world process for clarity. You may come across a site "BSDVault" that is rather helpful.
Sorry I can't provide any links. The school net connection is always overloaded, so all I can stand waiting on is the gentoo forums and slashdot.
Understanding is a three-edged sword. -- Kosh Naranek
I know a 16yo girl who installed FreeBSD on her own. She loves using Firefox, Gaim, and AbiWord.
She even tells me about how she uses Yahoo chat rooms to get FreeBSD support (when I'm not around).
That should keep most people busy and relieve dial-up users from download-hell.
The DVD seems to be very cheap, so even with international shipping, it shouldn't cost a fortune.
Rainer
Windows 2000 - from the guys who brought us edlin
Anyone who can read the handbook should be able to install it and use it. The problem is that not many people (including myself a year ago) want to spend the time to RTFM. The handbook really is well put together though. FreeBSD certainly isn't as "easy" to get up and running as Fedora or Mandrake, but it's certainly possible. Only severe issue I've had with FreeBSD lately is with my Compaq laptop. If you want to run FreeBSD, avoid Compaq like the plaque. I can't even boot into the installer (it shuts the machine down). At least it runs arch linux...
Unlike most Linux distros FreeBSD is really easy to upgrade. Go ahead and install RC1. Updating FreeBSD amounts to:
% cvsup
% make buildworld
% make installworld
% reboot
It's a little more complicated than that, but not much more.
Get the CD and install on a spare machine. BEAT THE HELL OUT OF IT.
If you find a bug you will be a GOD in the eyes of those that want to run 5.3 production-style.
I vote wait untill that release is FULLY READY TO GO OUT THE DOOR. 5.3 is critical to further acceptance of FreeBSD, further commercial funding support, further legitimacy of the platform, and confidence in the developers/Release Engineering team.
If you need it now, run the RC. Unless a TON of people need 5.3 NOW, the developers should feel no pressure to get it out the door. They should feel pressure to get testers to find problems. They should feel pressure to find people that like inflicting damage on a running OS. Find those twisted individuals and give them a RC CD and a keyboard. Hear their stories.
Make it good as the worlds's eyes will be upon this relase and any further potential problems. RC2 should be fixing a much smaller list of bugs.
WE'RE STILL PLAYING AROUND WITH SCHEDULER CHOICES!! ???? I'd suggest more RCs. Blank CD-R media is CHEAP. Corporate downtime when bugs are discovered 1.5 weeks out from a release IS NOT!
Test Test Test Test Test. Beat the hell out of it - portinstall all ports. Rock the box and see how she holds. Try and crash it. Pound it from the network. Pull a live disk. JMP to a block of random bytes. Run 200 instances of your JVM. Start up as many desktop applications as possible. Try and kill your install and see how Beastie holds.....
5.3 is going to ROCK but SHOULD NOT BE RUSHED!!! If it needs time, by all means give RE-team time!
I hope we don't have to see a 5.3.1 release.
Perhaps the developers should require a certain variation in hardware platforms tested on or a given number of people to run it with no problems before final release.
(I don't run FreeBSD in a corporate environment or profess to know much about RE's testing process. Just trying to get in people's heads that extreme testing WILL make this release a HUGE success.)
> i'd prefer a "real" graphics mode (like Linux fbdev) because that way i can use image/video software like mplayer/fbi/links2 on the console (but maybe it's ok to limp along with svgalib for now...)
/boot/loader.conf) and ensure that you have softfonts loaded (see the 'configure' menu of the installer, goto 'Console' and from there got 'Fonts' and select the font(s) suitable for your language)
Hmm, that seems to work on a radeon 9200 here when using xvidx driver, but yeah, using background graphics would be a reason to want graphics mode.
Eventho xvidx manages to play a movie as background of a text mode console, it isn't without flaws (scaling does not always work properly, and cpu cost is rather high when compared to using xvideo for example, not to mention the impact on responsiveness of the machine)
I prefer the speed and low resource use of a character mode console, tho that seems mostly relevant on low-end hardware, and changes as soon as you want to use something like xvidx. I found I'm usually better off using a very minimal x-windows setup for running graphics mode programs in such cases on FreeBSD.
> i'm sure my video cards have vesa1.2, they're not that old. here's 'lspci' output:
01:00.0 VGA compatible controller: Trident Microsystems CyberBlade/i1 (rev 6a)
01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] SiS630 GUI Accelerator+3D (rev 31)
Hmm, from what I can tell both should work indeed, just ensure you have the VESA module loaded (add vesa_load="YES" to
You should now be able to do a vidcontrol 132x43 and such.
Btw, the 800x600 pixel mode that FreeBSD's syscons driver supports is actually intended for forcing certain laptops into graphics mode so X can properly use it later. I happen to use it to get a console on tv-out for a pc I use as media center. Supporting hires screens for text doesn't seem part of the plan for it. Interestingly, vidcontrol on my system lists quite a few graphics modes beyond 800x600, but refuses to consider them as valid when trying to switch to them.
I just upgraded my desktop at work to RC2 from 5.2.1. The hiccups were minimal (remove PFIL_HOOKS, add devices io and mem, re-download HFS support), and for my trouble my problems getting my iPod to talk to the USB 2.0 interfaces have all gone away. While I was at it, I added LDAP NSS and PAM support ports and am now a very happy camper! Kudos to everyone involved.