Slashdot Mirror
FreeBSD 5.3-BETA2 available
Nirbo writes "One week after FreeBSD 5.3-BETA1, FreeBSD 5.3-BETA2, is now available to those wishing to update to the most current FreeBSD on the 5.x branch.
It's available from the Main FTP servers, and probably a few more places by this point.
BETA-3 is due out September 3rd, but for those who don't want to go a single day without updating, you can find snapshots (and the ISO images) here."
Just because the *BSD's explosive growth is minscule compared to Linux's explosive growth, that hardly means it's dying...
:D)
:D... now if only we could get off such dependancies as Linux Compatibility for out Flash plugins, we'd be set as both a Linux-ally, and a Linux competitor...
:D
For every 10 Linux users, every 1 has enough sense to fall through the cracks in the Linux Kernel and land in BSD-country (See, we can troll too
Rather, the boom of Linux in recent history has sparked a lot of BSD numebrs to jump too
With 2.5 Million active sites according to Netcraft (Who also run BSD... coincidence? Not really.), *BSD is hardly dead... just too busy disputing the death rumours to really make a show of it's vast and productive life
I'm quite impressed how quickly the beta's follow eachother. Even if changes between 5.2 and 5.3 aren't major. (haven't read the changelog though)
It makes me wonder why it takes so much longer for Microsoft with all its resources to go from one beta to the next, even with all the software that has to be tested.
home
I, FreeBSD, have NOT failed:
--To support SMP
FreeBSD has SMP support and has for a long long time. SMPnG is SMP Next Generation. It's a complete overhaul of a feature that's already supported.
--To generate media attention
Mac OS X is based on BSD. That's generated lots of media attention. I should also mention that slashdot is a form of media, and has gotten your attention.
--To spawn a professionally managed distribution
Did I mention mac OS X yet? No, oh. How about BSDi? That doesn't count? Oh. Well, I'll have to argue that FreeBSD is much more professionally managed than most Linux distro's (which are a hodgepodge shit-show of amateur code).
--To innovate
FreeBSD SoftUpdates. Ports (which the beloved Gentoo copied and is what most people claim is Gentoo's best feature).
--To be relevant.
BSD is generating news on slashdot, therfore it is relevant and very very important.
Guess I don't understand why you think that your NIC being detected is the the end all be all for an OS. If you have been around a the BSD circles for a while you should know that it does not support as much hardware as Linux. However, what it does support is usually supported quite well. Instead of complaining about it, go to the store and buy one it does support, it's not like they are expensive...at the very least, see what you can do to get support for the NIC you are talking about. Open Source operating systems are open so that folks like you, can contribute code to fill in the known holes. If you aren't a programmer, fine, but look for other ways of helping. Yeah, FreeBSD 5-stable has been a long time coming, but like you said, there are alternatives for those who simply cannot wait.
Have you submitted a bug report of any kind about this? That is what the BETA is for, and it is why it has the BETA tag.
While I respect your opinion, I do wish you would hold judgement until the final release is made.
-If God wanted people to be better than me, he would have made them that way.
Hmm, it would be interesting to know what network card you are having trouble with. This quite sounds like a bug to me.
With regards to your comments about FreeBSD 5.x and Dragonfly, I'd like to mention a few things..
- It is very easy to have a high speed of development in a new project. People are focussed on the project goals and there is little 'distraction' in the form of people actually using the project. It is about as difficult to keep an old project making progress because of the opposite conditions being true in general.
- If KSE and ULE are such good ideas is debatable, but seeing your post, you are interested in trying them. This architecture took its time to develop, and if you followed the smp mailinglist in the last few years, you'd see that that development was not easy, and in fact, noone before FreeBSD managed to implement this architecture in a workable way (while it looks very promising in theory, in practise it comes with lots of nice little problems)
I think Dragonfly is a very usefull addition to the *BSD family because of the exact work that you mention, a multithreaded network stack.
It may bring more equally important new developments in the future if it can keep up its pase of development.
> DragonFly seems to be doing better in this department (it looks as if thier "light weight kernel threading" subsystem has allowed them to almost completely multi-thread their network stack in roughly a one month period (the project itself being little over one year old)
I did my own reimplementation of the FreeBSD network stack at some point so I do have some idea what the code looks like and what kind of work would be involved..
The biggest part of it is properly splitting up the code, as it is now, it is mostly concentrated in a few HUGE functions that are almost impossible to maintain.
From there to a multithreaded implementation is not such a big issue once you have settled on an architecture for multithreading inside the kernel.
It seems that the method chosen by Dragonfly results in a lot less work in the kernel then what FreeBSD chose.
> while the FreeBSD folks *still* have not made significant progress doing the same with 5.x (no, even with 5.3 there is more code that cannot function without the big giant lock than there is code that can run happily without it)).
How much code can run without it is hardly relevant. How much time is spent running such code is of major relevance.
This of course would suggest that the network stack is something to look at....
At any rate, lightweight kernel threads lead to fast results for Dragonfly. If it will keep supporting that in the future is a question for me. Almost always such quicker solutions come to bite you a little bit later. If it does however then all the better. It is good to actually see multiple different branches of development for this.
mergemaster is the most painful part of a FreeBSD upgrade. 20 minutes of paging through files that I've never touched and probably never will (with a couple of minor exceptions).
/usr/defaults/ and then letting the user put his overrides into a file of the same name in /etc/. Just as we do with rc.conf. Throw in a switch to mean "update everything in /etc/defaults/ without asking me" and everyone should be happy. (That is, the curious and the masochists can still page through every changed config' file.)
I see its purpose, but it could be made much less painful by putting most of those files into
K.C.