Julian Elischer announced that Kernel Scheduled Entities – Milestone 3 (KSE-MIII) have been merged into the -current FreeBSD source tree. The KSE project is a major effort to allow for multi-threaded applications to scale and perform better, especially on SMP servers. The effort involves a considerable amount of re-working the various internal kernel data structures, and though not actually considered part of FreeBSD’s “next generation” symmetric multiprocessing project (SMPng), each project greatly enhances the other. Read the full story over at KernelTrap.
KSE-MIII Merged Into FreeBSD-Current 5.0
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSAlert.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Having read the article, and specifically the email, there are so many disclaimers (this should be re-written, this should be re-rewritten), does not work on SMP, and others, I wonder if this was worth the effort of just a lack of confidence on the part of the author….
Some troll wrote: “[…] I wonder if this was worth the effort of just a lack of confidence on the part of the author.”
Whatever man.
Was your comment worth the effort?
I’m sure these guys aren’t exactly getting paid to do this — They’re making progress here — this is a _good_ thing. I’m sure if you can do better they’d welcome the help.
“Is it worth it?” is not the right question to ask about this – not that there is a right question to be asked. In case you’re not a troll, I’ll give some background.
FreeBSD currently has two branches, called stable (4.x) and current (5.x). As its name implies, stable is meant to be solid; it doesn’t change that much and a version of stable you grab from CVS will probably work correctly. Current is where most of the development happens; it changes a fair bit and it is not uncommon for parts of it to be broken for hours or days at a time. From time to time a release is made; at present time all releases come from the stable branch. It is expected that most people will run a release version or track the stable branch. Although current can be used in a traditional sense, most of those who run current do so because they’re coders or testers.
The KSE work is a very large undertaking that radically changes some basic kernel structures and functionality. As such, it belongs in the current branch. Due to the extent of the changes and the fact that they impact (and depend on) changes made by others, it makes sense that KSE development be broken up into several stages. This commit marks milestone 3; there still remains work to be done.
“Is it worth it?” suggests that you don’t think it would be worth “upgrading” to a system with KSEs. In the short term, that’s probably true, not so much because of the potential problems of KSEs but because it implies you would have to run current (which is not wise for most users). In the long term, the FreeBSD developers have decided that KSEs are the way to go.
Those people who do run current (and presumably will “upgrade” to KSEs in the short term) should be reading the mailing list on which Julian posted those messages. The fact that the messages showed up on KernelTrap and OSAlert does not mean that Joe User should be running this. Treat such postings as status reports, not as calls to come and fetch a tarball.
Should I be grabbing 4.x or 5 if I just want to get the feel for FreeBSD?!?
“- The dog ate my homework… ok and my bills too!”
4.x, as the poster before you said. If you want to get the feel for a w.i.p. FreeBSD, go ahead and grab Current, but you’re not likely to want to.
I’m running -CURRENT since some time, and it worked relatively fine, but I didn’t update my source tree since friday, means I don’t run the KSE 3 changes. Reading the mailing list, some library is broken bigtime, so I’ll wait till it’s fixed.
Definitely go for 4.6, 5.0 would be a nightmare for a beginner.
Will they make the installer a better program or are we going to be stuck with this turd forever?
“From time to time a release is made; at present time all releases come from the stable branch.”
This is not always true. Sometimes the STABLE branch lags behind the RELEASE. In fact, it is relatively common. There are sometimes features in RELEASE that are not supported in STABLE because they haven’t been around long enough to ensure that they are rock solid stable.
“Will they make the installer a better program or are we going to be stuck with this turd forever?”
What is wrong with the installer program? It works fine. But to answer your question, yes, there is a team working on a new sysinstall tool that will have a GUI interface.
Personally, I don’t think its necessary. The installer works fine the way it is. And it doesn’t make assumptions about my system that end up trashing other file systems without even asking me first like certain Linux distros that shall remain nameless.
Simba: Umm the STABLE branch NEVER lags behind the RELEASE for the same major version number. The RELEASE is the “stable” version, while the STABLE is the more “unstable” version that will become the next release. All of the development that goes into the next release is made in the STABLE branch. I know that seems wrong, but thats how they named it. The STABLE branch is never rock solid except right before a new release (they now always have a few RCs at this time). Compared to the CURRENT branch, STABLE is much more “stable”.
Great I appreciate the work they are doing in sysinstall. I know many “old skool” types and unix die hards hate this gui stuff but it really eases the stress level during installs. After installing suse 8.0 recently, it was almost shocking seeing a text based interface for installing an OS but I digress, the devil is in the functionality of the program. The part that always makes my pulse rise is the weird way one must tell sysinstall where they want it. If the FBSD team takes nothing else from Linux distros, it should be to perhaps use a Mandrake-like partitioning system with some added oomph and they’d have a killer app on their hands for partition config. I will be following 5.0 with interest as time progresses.
Just to eliminate confusion, I was referring to the bootloader program in the post above. hehe sorry!
“Great I appreciate the work they are doing in sysinstall. I know many “old skool” types and unix die hards hate this gui stuff but it really eases the stress level during installs”
It doesn’t when certain GUI Linux installers decide to overwrite swap partitions on hard disks that you specifically told the installer not to use. And then when you search the tech database to find out what the hell happened, they tell you the only way to avoid that is to physically unplug the drive from the system. It would be nice if they would tell you that beforehand