FreeBSD Upcoming Release Dates 16
"The following constitutes the FreeBSD provisional release schedule into mid-2002. The release engineer and the FreeBSD project have always committed to a "best effort" where these dates are concerned and will continue to do so, but all dates are also subject to change without notice given prevailing conditions in the source tree.
2001-04-20: FreeBSD 4.3 released
--
2001-08-20: FreeBSD 4.4 release date
2001-11-11: FreeBSD 5.0 release date [EARLY ACCESS]
2001-12-15: FreeBSD 4.5 release date
2002-03-15: FreeBSD 5.1 release date [GENERAL ACCESS]
2002-04-20: FreeBSD 4.6 release date
2002-07-15: FreeBSD 5.2 release date [BEGIN -STABLE]
The dates for 5.x are particularly SWAGish in nature and I'm sure that a lot of people in -current will scream and jump up and down about a November release date, but all of us here also know that when we wait for a dot-zero to be "ready". It turns into a multi-year debacle, during which time *nobody* is pleased, and we finally end up rushing something out the door at the last minute anyway except that it's rushed because it's overdue and everyone's upset, not because we had an aggressive deadline. 5.0 certainly won't be perfect, nor will it achive all the goals we'd originally envisioned for it, but then that's been true every single time we've done this and somehow we've survived. :)
I'm also proposing that we branch fairly late in 5.x so that we have quite a bit of time to finish a few works in progress, but we still have some time to talk about that. The 4.x schedule should be fairly accurate as it stands since no significant issues are forseen there.
- Jordan"
Which company will it be this time? (Score:1)
2 & 3 Walnut Creek (Sigh -- RIP)
4 BSDI (Greed kills -- RIP)
5 Wind River
Which company will be next? May I suggest SGI, since they're not long for this world...
Software release schedules (Score:1)
This is part of the reason I like FreeBSD. They actually have coherent release schedules, instead of Linus' lets-mess-around-with-the-VM right before we release a "stable" kernel. The FreeBSD release schedule is nice and predicatable. Think tortoise versus hare. The game is not over for FreeBSD.
Re:5.0 Branch to Have SMPng (Score:1)
The SMPng page says that FreeBSD 5.0 "should" scale to 32 CPUs, but their SMP implementation is effectively the same as Linux 2.2, which could only scale well to 2-4 CPUs.
FreeBSD 6.0? (Score:1)
Does anyone have any links about the plans for FreeBSD 6.0? I read somewhere that it will include some of the security features from TrustedBSD and some improved SMP, but I can't find any details.
Re:Cardbus Support (Score:1)
Re:I really hope these releases do well (Score:1)
I run into this problem often under Win98.
Re:I really hope these releases do well (Score:1)
You see. Those are exactly the features I want in a network/server OS!!
I have waited so long, just to be able to log into my servers and click on things with a mouse pointer. And there is nothing like quite feel like a GUI in the morning.
I'm glad that I can now add another array, some more memory, a faster proc, and a new OS while taking only a modest performance hit. It's worth it. Because, "at least with NT you have pretty winders to click on and a mouse to move."
Re:5.0 Branch to Have SMPng (Score:1)
Uh.. no. It is effectively the same as Sun Solaris. BTW, the work-in-progress SMPng has already been tested on 8-way Alpha big-iron.
Re:I really hope these releases do well (Score:1)
Re:Cardbus Support (Score:2)
You may want to check out the mailing list archives to see the progress and which CardBus chipsets they support. The mailing list archive page can be found here [freebsd.org] and the archive search page is here [freebsd.org].
Re:5.0 Branch to Have SMPng (Score:2)
I've noticed a recent trend towards trashing FreeBSD's SMP because of "the giant spinlock." What people don't realize is that one large spinlock can be a viable method of locking for the purposes of threading (that is, multiprocessing). It would seem that someone who has a moderate clue about threading and writing SMP-capable operating systems has commented on this, and feels it's bogus, and one or more of the general breed of "BSD is ubersux" trolls has gotten a hold of this and thinks it's the ultimate death knell for FreeBSD/smp. Obviously, you don't really know much about locking at all. It should at least be pointed out that no matter how many locks you have, it is more important to keep the system OUT of a locked state as much as possible, and FreeBSD does this well enough. It's not as if the system is constantly locked and able to use only one CPU. Most processing occurs in userland, far away from kernel locks, so it doesn't tend to matter all that much. Now, granted, using one spinlock isn't necessarily the best way to do things, at least not in an OS. However, it's not the worst either. Combined with the fact that it allowed fairly rapid updating and deployment of FreeBSD/SMP, I think the choice to use that 'giant spinlock' was valid. It allowed SMP code that by all accounts worked better at least than the 2.0 Linux kernel's (if not 2.2 as well) to be deployed until a better solution could be created.
A better solution will be deployed in FreeBSD 5.0 with the introduction of SMPng. I do not doubt that the 2.4 Linux kernel does a better job at SMP than FreeBSD (release/stable) does, but I think it's worth noting that Linux's SMP has been now five or six years in the making to get to this point, and that the Linux and FreeBSD development and advancement models are significantly different. Where Linux takes gradual steps, FreeBSD (and BSDs in general) tend to take large leaps. That's just a difference in implementation timing. Furthermore, it's perfectly reasonable to expect two open-source systems to leapfrog each other in terms of capability as ideas and code move from one to the other, and it's really not something to gloat over. What one does better today, the other will do better tomorrow. It doesn't really matter. To those of you babbling on and on about 'the giant spinlock', you might want to go do some research into the theory, and practice, of implementing locks in threaded systems. Until then, shut up, please.
Re:5.0 Branch to Have SMPng (Score:2)
Re:I really hope these releases do well (Score:2)
Uh... there never was a FreeBSD 1.2. I think that is suffient proof you are a troll. (also the VM system in 1.x is not the same as in later versions)
5.0 Branch to Have SMPng (Score:3)
Re:I really hope these releases do well (Score:3)
First - NT certification was based on a machine that did NOT have a network card. That was NT 3.51.
Second - To get C2 certfication, someone has to PAY over 20,000 dollars. As you MUST have knowledge of someone how paid, will you share it? Oh wait.... YOU ARE A TROLL who has no facts to backup your claims.
Feel free to post again when you have some facts, k?
Re:I really hope these releases do well (Score:4)
This is irrelevant since FreeBSD is picking from BSD/OS not the other way around. IOW, FreeBSD is not dependent on BSD/OS. They have no dependence on BSDi which is no more; Wind River has a portion of it now.
FreeBSD's C2 security certification is horrible also. Even NT can do better than it!
C2 certification is a joke. The U.S. Government does not even seem to follow it since they use NT 4 in many places without it conforming to C2.
Actual memory bandwidth performance is a fraction of all of Sun's offerings...
Memory bandwidth is a hardware item. Sun's architecture is much faster than x86. OS's have little control over the design of the memory bus.
the multiprocessor support is a joke since it has a poorly implemented semaphore locking mechanism.
This has been acknowledged and is why SMPng is being worked on.
But even then the open source nature of FreeBSD will cripple it - all open source code does is allow poor quality code be used in mission critical systems.
You are now comparing FreeBSD development style against Linux. You obviously have never done your "fair share of testing on the VM scheme" as you stated. If you had, you would know how FreeBSD is developed. Thankfully, it is nothing like Linux, but you should already know that.
Recent tests done by SysAdmin magazine have *BSD coming in last place in terms of performance when paired against Linux and Solaris.
Without even basic tuning for FreeBSD? They did not even have SoftUpdates active. Sorry. The test was flawed.
I think its time to let FreeBSD be merged out of use and let operating systems such as Solaris, NT, or even Linux take its place.
With the incredible growth FreeBSD has been experiencing, your opinion is a joke.