Slashdot Mirror
FreeBSD 5.3-BETA5 Available
Nirbo writes "FreeBSD 5.3-BETA5 is now available! Get it while it's hot! Here is the mailing list post. Remember folks, this is currently the last beta that will be released for 5.3, we're only a week from a Release Candidate, and two weeks from a release!"
The link in the write-up is bad; here's one that works.
"Remember folks, this is currently the last beta that will be released for 5.3" Not quite accurate "We will add at least one more beta (BETA6)to accomodate testing."
Does anyone know if ULE is put back in as the default scheduler? The 4BSD scheduler is stronger, and better in almost every aspect, but unfortanly not on the desktop where you'll notice the difference.
The reason I ask is that my less than experienced FreeBSD users that have cron'ed cvsup and buildworld might complain that performace when using VLC is decreasing; it's annoying to have to explain possible reasons without knowing.
The mentioned disabled PREEMPTION option seams to indicate this, but I'm not familiar with that option as I'm very happy with the old RELEASE which has another option (options SCHED_ULE).
Im using gentoo - running linux
kernel-2.6.8
(SMPx2way with low latency and pre-emptive enabled)
What are the main differences between the latest FreeBSD kernels and the linux ones.
A lot of people say FreeBSD is better because "its more stable" or "it has a more mature kernel" I've seen little evidence to substantiate these common claims. Whilst they may have been true some years ago are they really true today?
Apart from the cool things like the ports system and userland differences, licensing differences aside- At the core level of the kernel what makes a new FreeBSD kernel better than a new linux kernel?
(Genuine Question)
Nick...
Electronic Music Made Using Linux http://soundcloud.com/polyp
I'd just like to apologize for the link being bad, I don't know how it happened... I copied it from my browser, and tested it, but somewhere along the lines, I must have not noticed somethign happening. :p, Thanks to the one who posted the link in a comment.
However, when I tried recompiled my kernel with options PREEMPTION, I had two complete lockups under heavy load (compiling in the background, running KDE, etc). During beta4, I removed options PREEMPTION for this reason. Now I've put it back, and I experience similar problems. I got error messages repeatedly (and the OS stopped responding for a few seconds now and then) when downloading files (with roughly 500Kb/s from network shares. Perhaps the same errors would pop up in other circumstances of heavy disk I/O. The messages were like this:
After removing PREEMPTION, problems went away. Note that I used preemption with SHED_4BSD, not ULE!On the other hand, 5.3 will be an excellent release. Other than problems with preemption (which I don't quite understand, I mean preemption, so I would be glad if someone explained to me what it does exactly!), the BETAS were quite stable. In BETA5, the old problem of floppy not working with ACPI on some chipsets (I have via) is solved. Start up time is very fast, I think it is faster than 5.2.1. (it starts up roughly 2x faster than slackware with 2.6.7 kernel on the same box.) Perfomance on the desktop is similar to previos 5.x releases (and I have a few problems with KDE 3.3 now).
Oh yes, another question. options PREEMPTION is listed under the SMP section of /usr/src/sys/conf/NOTES. Is preemption SMP specific? From the few things I've read (and the even fewer things I could understand :() I didn't think it was. Can someone explain this to me? And: does preemption help with latency? (I have problems with sound in some games, and I think they are latency related).
I agree that DragonFly has fantastic potential and that FreeBSD 5.x has been a long and bumpy road. However, when your post begins with:
Yeah, I know. It's a beta. However,
Stop typing.
These guys are sure doing their very best to follow in Linux's footsteps.
You're fairly misinformed.
This compared to FreeBSD 5.x, which forked from 4.x over three years ago, and still has major issues getting anything resembling a multithreaded/MP safe networking stack. It really does look as if they took the hard way.
Like Linux, FreeBSD seems content on reimplementing the same tired technologies as have all of the big UNIX vendors, in nearly the same ways, for the sake of being the same. There is nothing innovative in either one.
Linux actually hasn't "reimplemented the same tired technologies blah blah". Linux hasn't locked itself to death like FreeBSD 5, and like everyone said it would. It remains very lightweight, having probably the fastest single threaded general purpose UNIX kernel for most operations. It can boot into busybox, with full network stack and virtual memory support in as little as 2MB, it can scale to 512 CPUs in huge and complex NUMA hierachys. It is simple enough that dozens and dozens of people are familiar and capable with core vm, ipc, process, architecture, etc code and locking. As opposed to what seems like about 4 or 5 for FreeBSD 5.
Linux gets most of its scalability from lockless data structures, as well as lightweight per-object locks, and good design. Doing lockless and per-cpu paths in DFBSD isn't anything frighteningly new. They're going about it slightly differently, but at the end of the day you still have a set of points (which is generally the kernel->user interfaces and the kernel->hardware interfaces) that *must* be consistient/serialised/locked/atomic.
Unlike many who have posted here, I actually read the article ;)
Here's a great sleeper / not widely publicized feature:
NDIS Binary Compatibility
a.k.a. "Project Evil".
FreeBSD i386 can use binary Ethernet and WLAN network drivers written to the Windows XP NDIS 5.1 specification. It is a little cumbersome to convert a NDIS driver into a FreeBSD Kernel Loadable Module (KLD)
Prevent linux based DDOS's!
http://linux.denialofservice.org/
Linux actually hasn't "reimplemented the same tired technologies blah blah".
:P
Right. A UNIX-like kernel that is single threaded, that has aquired bits of code from other UNIX-like operating systems in order to scale better on modern systems. No astounding reimplementations there.
Linux hasn't locked itself to death like FreeBSD 5, and like everyone said it would. It remains very lightweight, having probably the fastest single threaded general purpose UNIX kernel for most operations.
You have no idea what you're talking about. Linux is currently way ahead of FreeBSD in the fine grained locking arena. Linux is where FreeBSD wants to be, and has done so mostly in the same ways that FreeBSD is attempting to implement now. Sure, there are lockless algorythims in Linux, and there are a few in FreeBSD as well.
It can boot into busybox, with full network stack and virtual memory support in as little as 2MB, it can scale to 512 CPUs in huge and complex NUMA hierachys.
The low end is fairly typical of UNIX-like systems, Linux and BSD both. The high end you are refering to, is assuradly not a vanilla kernel, nor will it be for some time to come. Many of the patches used to make Linux scale that well go against Linus' ideal kernel architecture, and therefore won't see mainstream usage for ages, if ever. Contrast this with DragonFly's new architecture, that has been redesigned at it's core for just this kind of scalability as standard practice, and we'll see in a year or two which one is high end champ.
It is simple enough that dozens and dozens of people are familiar and capable with core vm, ipc, process, architecture, etc code and locking.
The very same could be said about FreeBSD, despite the fact that you cluelessly think otherwise.
Linux gets most of its scalability from lockless data structures, as well as lightweight per-object locks, and good design. Doing lockless and per-cpu paths in DFBSD isn't anything frighteningly new.
Never claimed them to be. However, I did claim DragonFly to be a more modern system than Linux, due to DF's multithreaded, message-passing architecture, as opposed to Linux's archaic single threaded, monolithic structure (and no, being able to load modules at runtime does not make a kernel cease to be monolithic). In the not too distant future, DragonFly will have the ability to run some drivers as userspace processes, thus making the system far more stable than could be possible otherwise, as these select drivers would be running in their own protected memory spaces.
They're going about it slightly differently, but at the end of the day you still have a set of points (which is generally the kernel->user interfaces and the kernel->hardware interfaces) that *must* be consistient/serialised/locked/atomic.
I never made a claim that this was not the way things are. Like any other system, DragonFly certainly employs serializing mechanisms, including, the simple mutex. The DragonFly developers, and Matt Dillon in particular, seem to have a better grasp on how best to architect a kernel in the modern day.
You're fairly misinformed.
Damn. I was thinking the exact same thing about you...
Uhm no, I think I'll refrain for taking your advice here.
You see, the thing is, that DragonFly can quite easilly be seen as an operating system that has been in beta since it's inception (well before the first release was made, it was announced that the "first release" would be more of a technical preview, rather than a production release), and yet it's quality has been consistently higher than both the beta releases of the FreeBSD 5.x branch, but higher quality than the FreeBSD 5.x releases.
Surely, you'd be nuts to run either in a production environment at the present time, but experience and records (mailing lists of both project's) indicate that DragonFly is the more reliable choice, despite the fact that it's newer, and using a less widely used architecture. The changes in DragonFly have been small, and gradual, evolutionary, so as to not break things for long periods of time. With every single beta release, the FreeBSD folks have added new features, or removed previously new features due to limited testing (which is a situation that is hardly helped by removing them from prime testing environments such as well, beta releases).
Of the core goals shared by both projects, the DragonFly team has consistently done more with less (fewer developers, less time, etc.) and have a more stable code base to show for it. Sure, it may be missing some features that FreeBSD 5.x might have done a half-assed job of implementing as of the time of this writing, but the features in DragonFly are far more likely to work for all the attention to detail and the sheer quality of the developers work, combined with the saner choices of simpler, less difficult to debug abstractions (like LWKTs and the serializing tokens, the message passing system etc.).
For as long as I've known of and used FreeBSD, I've been a tremendous fan, so don't take this as fanatisism for a competing system. To me however, DragonFly is merely a more worthy upgrade path from the FreeBSD that I've come to trust and rely on, than is the monstrosity that is FreeBSD 5.x.
"Project Evil" is available on DragonFly as well. It was ported over from the excelant FreeBSD code.
Although I'm not sure about the other BSDs, or of Vanilla (Linus') Linux, I'm fairly certain that this will soon be fairly mainstream in all non-Windows operating systems at least until proper open source drivers are developed for all operating systems in question.
Right. A UNIX-like kernel that is single threaded, that has aquired bits of code from other UNIX-like operating systems in order to scale better on modern systems. No astounding reimplementations there. :P
It actually hasn't aquired bits of code from other UNIX-like operating systems in order to scale better.
You have no idea what you're talking about. Linux is currently way ahead of FreeBSD in the fine grained locking arena. Linux is where FreeBSD wants to be, and has done so mostly in the same ways that FreeBSD is attempting to implement now. Sure, there are lockless algorythims in Linux, and there are a few in FreeBSD as well.
No, FreeBSD is doing it with heavyweight mutexes, Linux did it with light weight critical sections and lockless algorithms.
The low end is fairly typical of UNIX-like systems, Linux and BSD both.
Not FreeBSD 5, no way you could boot a working system in 2MB. Probably not FreeBSD 4 either, for that matter.
The high end you are refering to, is assuradly not a vanilla kernel, nor will it be for some time to come.
Well not their 2.4 kernel. It has a global scheduler ferchistsake. The vanilla 2.6 kernel actually *does* run on the 512 CPU systems. Most of the other code SGI uses is related to performance measurement.
Many of the patches used to make Linux scale that well go against Linus' ideal kernel architecture, and therefore won't see mainstream usage for ages, if ever.
Bullshit. Which patches?
Contrast this with DragonFly's new architecture, that has been redesigned at it's core for just this kind of scalability as standard practice, and we'll see in a year or two which one is high end champ.
Oh yeah? I haven't even seen numbers of DFBSD on a 2 way system, and it has already been 2 years.
Never claimed them to be. However, I did claim DragonFly to be a more modern system than Linux, due to DF's multithreaded, message-passing architecture, as opposed to Linux's archaic single threaded, monolithic structure (and no, being able to load modules at runtime does not make a kernel cease to be monolithic).
Oh my god you are retarded. Linux *IS NOT SINGLE THREADED* How the fuck do you think it can run on a multi CPU machine if it is SINGLE THREADED. Answer me that right now.
In the not too distant future, DragonFly will have the ability to run some drivers as userspace processes, thus making the system far more stable than could be possible otherwise, as these select drivers would be running in their own protected memory spaces.
Well if running drivers in userspace makes your system far more stable, I suggest your system is too unstable to start with.
I never made a claim that this was not the way things are. Like any other system, DragonFly certainly employs serializing mechanisms, including, the simple mutex. The DragonFly developers, and Matt Dillon in particular, seem to have a better grasp on how best to architect a kernel in the modern day.
Well they sure *think* they do. So far they're short on results though.
Damn. I was thinking the exact same thing about you...
That is because you're so misinformed.
Here Here. I completely agree. When all of the underpinning of DFLY are implemented and they get their ports system up, I can see a lot of FreeBSD users moving to it in droves. Maybe then the FreeBSD team (well, what's left of it) will take notice.
>> It is simple enough that dozens and dozens of people are familiar and capable with core vm, ipc, process, architecture, etc code and locking.
> The very same could be said about FreeBSD, despite the fact that you cluelessly think otherwise.
Actually no. If you think otherwise then you obviously don't follow FreeBSD development.
For example, there have recently been a lot of scheduler problems. All the kernel developers can reproduce them easily, but nobody can fix them. One guy (Julian) is having a try, and a couple of others sometimes throw ineffectual patches around. BUT IT IS NOT FIXED. This is just about the most important piece of code a unix operating system can have, and they've known about the problems for months and months, but NOBODY CAN FIX IT.
Furthermore, tell me one known problem with the Linux kernel that has gone unfixed for more than a month. Nope, there aren't any.
VS BETA3
Beta3 had problems with doing a make update and 5.2.1 on a multi-processor Xeon box was 'rebooting'. 5.0 and Windblows NT 4 on the same hardware lacked the reboot feature.
JDK1.4 even built under BETA5.
All the little fork'n processes look good.
Beta 6 is out the mailing list post