Scott Long released the March-Sepetember 2003 Status report, reviewing the past seven months of FreeBSD development. The paper is loaded with updates covering Bluetooth, ACPI, dynamically linked /bin, icc support, cryptographic support, java, KSE, porting OpenBSD’s pf, and much more. Elsewhere, this paper describes an automated system for building and distributing binary security updates for FreeBSD, and describes the challenges encountered.
Glad to see KSE has come along, and it looks like FreeBSD 5.2 will see the inclusion of a KSE-based pthreads library instead of the current libc_r. This will drastically improve FreeBSD’s scalability on SMP systems, and will give FreeBSD a threading model roughly on par with NPTL on Linux.
I’m sorry Linux zealots, but I’m afraid BSD isn’t dying… *grin*
Excellent news on the pf port, just showing the further collabaration between the *BSD teams. In porting pf to Linux the FreeBSD developers discovered bugs and reported them to the OpenBSD team, who in turn fixed the bugs on their side as well, resulting in a better pf for everyone. That’s open source collaboration at its best…
I’m also glad to see that they are porting pf to FreeBSD. The binary security updates sound very interesting as well. It will make it much easier for people to keep up with security updates with out the need to recompile.
Well, it will be a great combination when made available, KSE/Java and improved SMP. What I would love to see is more developers getting on board the FreeBSD project, maybe once I get some time I’ll start getting onto the C/C++ bandwagon and submit some patches ๐
Bascule, the only beef Linux have with FreeBSD is that it isn’t GPL. For me, I really don’t give a tinkers cuss about licenses. I’m working on a small project, once made available I’ll probably license under the IDGAS License (I Don’t Give A Shyte). In a nut shell, you can do what ever you want with it, and I really don’t care.
For me, its the code, not the license that is important, that is what a number of Linux fanboys lose focus on. They’re too wrapped up in the GPL hype instead of being more concerned with the code. Sure, politics are fun but they shouldn’t be the main focal point of software development.
The only problem GPL-enthusiasts can have with the BSD-license is that they might fear that a commercial entity would hijack the project.
It doesn’t look like anything like this is going to happen. The proprietary forks of BSD and X11 licensed programs have largely died, leaving the free alternatives dominating the scene (XFree86 and the *BSDs).
In the case of FreeBSD, they actually got code from BSD/OS released under a free license and incorporated into FreeBSD. Rather than threatening FreeBSD’s freedom, BSD/OS eventually contributed to its development.
People releasing code under the BSD license obviously must not care about the possibility that some of the code might be incorporated into a proprietary product, but the concern of some people that proprietary products would threaten the free ones seems overly paranoid.
Too be honest the two of them are nearly identical about griping about each other.
eg. “*BSD is dieing” vs. “Linux sucks give me FreeBSD anyday” etc. etc. (roll eyes)
what should separate us from them is that we are actually adults as oppose to fanBOYS (or fanGIRLS) ๐
i’m a long term Linux user, other then install FreeBSD (which was simple to do) i’ve never really used it, but i don’t disrepect ya for using it, nor do i dish it, after all the important thing is that both are opensource and can learn from each other. Plus both been *nix’s they are quite alike. same reson i like IRIX well also cause my octane is a cool machine as well though ๐
humm interesting paper
i like that binary diff concept and the author will to change what on his opinion is wrong about freebsd way to deal with periodic system security updates. He gives some examples, windows update, rhat up2date, debian apt-get etc. Ok i understand theres a concern here,(some hardware limited hardware boxes) but really who uses freebsd should be aware of this “difficulties” (whatever they mean good or bad) afraid of recompilling the sys ? afraid of aplying a patch ? afraid of making world? that afraidness doesnt belong here.
despite that he points to many pittfalls on this technology,
“Another limitation arises from the fact that we only re-
place files, rather than adding or removing them. This
immediately means that this system is restricted to up-
dates within a single version ยญ while the effect of a se-
curity patch will be to modify some files, upgrading to a
new version would require installing entirely new files.”
“files will result in updates not being performed. This
means that the set of potential users is restricted to those
who have performed a binary install and not recompiled
any FreeBSD files. We do not consider this to be a se-
rious limitation, considering that our stated target audi-
ence is those users who are unable or unwilling to re-
compile from source.”
“A more serious issue arises with the kernel: We can only
provide updates for the GENERIC kernel. While this
may be sufficient for some users, a very obvious class
exists for whom this is not sufficient”
“On the other hand, for various reasons it seems unlikely
that this same approach could be applied to software
from the FreeBSD ports tree. First, while pre-built pack-
ages are available, most people build ports from source;”
I know it’s a minor thing, but I don’t like the idea of a dynamically linked root filesystem. It is my understanding that it has traditionally been statically linked so that when bad things happen, one can still boot into single user mode without needing to mount /usr, or for libraries to be on the root filesystem or for a crunched binary to be there either. All for better PAM support? Sigh.