Marcel Moolenaar has been very busy with GDB code as of late, having imported gdb version 6.1.1 in late June and now supplying a patch to freebsd-arch@ that adds kernel debugging and helpful features to FreeBSD’s gdb and ddb code, including thread awareness. Other interesting additions include optimizations for the 64-bit platforms, compression for remote gdb, and improved symbol handling.
FreeBSD: Revamp of Kernel Debugging Code w/ Thread Awareness
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSAlert.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
That sounds like quite a job.. The FreeBSD team has always impressed me, they don’t have the funding Linux has, or the corporate backing but their kernel is still competetive with Linux 2.6 (when comparing 5.x), and their kernel code is just so extremely tidy and well commented.
So when is the release date of FreeBSD 5.3?
It’s slated for mid summer, I’m betting we will see it a bit later though, late August at the earliest.
But as with all release management in FOSS, when it’s ready.
Sure, GNOME and so on have timebased releases and I think that’s a good thing.. it’s still not strict though, GNOME is fairly good at hitting within 2-3 weeks of their deadlines.
But with most FOSS projects, it’s still a feature based release cycle, and that means when it’s ready.
i like the fact that the BSD are more designed and their evolution tends to be more intentional than it does with Linux. Linux seems to grow more unpredictably. I do wish that the Linux experts would publish papers and discussions like the BSD people do – only last week I was reading a thorough paper on the NetBSD UVM. i can find no similar items for Linux.
“i like the fact that the BSD are more designed and their evolution tends to be more intentional than it does with Linux. Linux seems to grow more unpredictably.”
other than some kind of percieved high ground both of these operating systems evolve over time. they design/redesign things. they reimplement stuff and so on. this is pretty silly thing. what can be accepted is that freebsd tends to be more conservative. openbsd has a time based release while netbsd evolves slowly
“I do wish that the Linux experts would publish papers and discussions like the BSD people do – only last week I was reading a thorough paper on the NetBSD UVM. i can find no similar items for Linux.”
you realise that lwn.net and linux related sites like ibm developerworks publish extensive documentation about various stuff related to the kernel.
”
But with most FOSS projects, it’s still a feature based release cycle, and that means when it’s ready”
actually foss projects tend to have adhoc releases that are neither feature nor time based. kde is an example of that. they have a set of features but if there is something they need to present they push the features to the next release like the relatively short release cycle of kde 3.3 for akademy compared to the long life cycle for kde 3.2 because they didnt need to hurry about anything.
That sounds like quite a job.. The FreeBSD team has always impressed me, they don’t have the funding Linux has, or the corporate backing but their kernel is still competetive with Linux 2.6 (when comparing 5.x), and their kernel code is just so extremely tidy and well commented.
I’m sorry, but their 5.x kernel isn’t even competitive with their 4.x kernel, let alone Linux 2.6. Really, I would honestly not have a problem if it was, but everything I have seen says it isn’t, and the best that even the zealots can do is whine about how the guy doing the benchmarks is biased, etc etc.
Basic software engineering principle: preoptmization leads to failure.
First, the ULE scheduler is still in its infancy. Second, our primary concern, at the moment, is getting KSE working reasonably.
FreeBSD hasn’t made it to STABLE yet, any opinions about it’s speed at this point are moot.
Make it work first. Then, make it fast.
> Make it work first. Then, make it fast.
Amen.
“Basic software engineering principle: preoptmization leads to failure.
”
right.
“corporate backing but their kernel is still competetive with Linux 2.6 ”
this is premature comparison which is plainly wrong. freebsd 4.x doesnt scale as well as linux 2.6. 5.x has been looking into 2.6 and even taking up ideas from there. so it might even improve upon it. currently linux 2.6 leads the benchmarks
“Basic software engineering principle: preoptmization leads to failure.”
right.
“corporate backing but their kernel is still competetive with Linux 2.6 ”
this is premature comparison which is plainly wrong. freebsd 4.x doesnt scale as well as linux 2.6. 5.x has been looking into 2.6 and even taking up ideas from there. so it might even improve upon it. currently linux 2.6 leads the benchmarks
Whoever keeps clicking on “Report abuse”, please desist. It is for offensive content (ie. racism, excessive bad language, etc.), and *not* for a post that points out something that you happen to personally dislike and would like to censor.
If Linux really isn’t faster than FreeBSD, by all means refute the point and link to some proof. I suspect you can’t though.
> If Linux really isn’t faster than FreeBSD, by all means
> refute the point and link to some proof. I suspect you can’t
> though.
and
> this is premature comparison which is plainly wrong. freebsd
> 4.x doesnt scale as well as linux 2.6. 5.x has been looking
> into 2.6 and even taking up ideas from there. so it might
> even improve upon it. currently linux 2.6 leads the
> benchmarks
The tests show linux outperforming freebsd in several areas, although BSD still shows stellar performance in concurrent network access[1]. This should be common knowledge by now *especially* for freebsd users, but it sounds like some of you have not been paying attention to progress and obstacles in the 5.x tree. As a user of the platform, it’s really important that you reflect accurate information about your claims, otherwise you just sound uninformed and it has a negative impact on how the project is percieved.
[1] Check the kerneltrap comments section of this article:
http://kerneltrap.org/node/view/3170
OK, I’ll try again. Gee, someone can falsely claim that Linux is thrown together in an ad hoc way, and not “designed” and lacking published design papers, and that is no problem, but you can’t even add a bit of harmless sarcasm when refuting the false claim.
you realise that lwn.net and linux related sites like ibm developerworks publish extensive documentation about various stuff related to the kernel.
Not to mention dozens of books.
Oh here are a few papers too after a 2 minute google search.
http://www.skynet.ie/~mel/projects/vm/guide/pdf/understand.pdf
http://people.redhat.com/drepper/nptl-design.pdf
http://lxr.linux.no/source/Documentation/block/biodoc.txt?v=2.6.5
http://lxr.linux.no/source/Documentation/sched-design.txt?v=2.6.5
Neither the benchmark nor the discussion do much to convince me of FreeBSD’s greatness. The benchmark in question is, quote, “closed-source, so I cannot give away details”. Please! If this were a Linux guy “proving” BSD is behind with a closed benchmark, all hell would break loose.
Somehow you missed the point I was making. FreeBSD *has* warts and *is* behind linux. The point about stellar network performance is that “in the benchmarks” FreeBSD is not underperforming in that area. I’ve seen plenty of instances where Linux has hedged it out. And there is no “benchmark” in question, there were benchmark(s) (well.. two). As an excersize, I’ll leave it up to you to go back and re-read the reference and come to the obvious conclusion. Don’t be so reactionary, it’s a very straightforward discussion.
Neither the benchmark nor the discussion do much to convince me of FreeBSD’s greatness. The benchmark in question is, quote, “closed-source, so I cannot give away details”. Please! If this were a Linux guy “proving” BSD is behind with a closed benchmark, all hell would break loose.
All hell *did* break loose, in as much as you can accuse someone of inaccurate and unproveable testing methods. Since you’re so good at searching google, you can certainly find the responses recieved from that particular benchmark. And of course, the point was not to “prove” BSD was behind, but was a simple test to observe how well a *custom* application performed on both platforms. Why so black and white?
Somehow you missed the point I was making. FreeBSD *has* warts and *is* behind linux. The point about stellar network performance is that “in the benchmarks” FreeBSD is not underperforming in that area. I’ve seen plenty of instances where Linux has hedged it out. And there is no “benchmark” in question, there were benchmark(s) (well.. two). As an excersize, I’ll leave it up to you to go back and re-read the reference and come to the obvious conclusion. Don’t be so reactionary, it’s a very straightforward discussion.
Err, yes there is a “benchmark” in question. Ivan Voras’ Web CMS system is the one which showed FreeBSD beating Linux on “concurrent network access”. That is the one which is closed source.
And what do you mean “don’t be so reactionary”?! Your conjecture was that FreeBSD has stellar concurrent network access based on that benchmark. My *REACTION* was that it is highly improbable due to the proven and docuemnted shortcomings in FreeBSD’s networking performance (especially FreeBSD 5) which I gave some links to, and the fact that the test was closed and unable to be reproduced and verified.
All I did was refute your claim. Are going to REACT to this post?
All hell *did* break loose, in as much as you can accuse someone of inaccurate and unproveable testing methods. Since you’re so good at searching google, you can certainly find the responses recieved from that particular benchmark.
I didn’t really care to. I can imagine though.
And of course, the point was not to “prove” BSD was behind, but was a simple test to observe how well a *custom* application performed on both platforms. Why so black and white?
You’ve lost me here, what are you talking about? Facts are “black and white” because that is true or false. That is generally what I try to stick to when talking about computers. So yes, that is why I am being “so black and white”. I might ask you: why do you accept anything less?
Are the FreeBSD guys going to implement ELF TLS anytime soon? I’d love to begin using this feature but without losing portability to FreeBSD.
LOL, dude, seriously your best off asking questions like this is on a mailing list, not here… probally current would be best, if it is like you say it is.
For FreeBSD stuff this place is best left to entertianment as the posters above have shown and not info.
http://lists.freebsd.org/pipermail/freebsd-stable/2004-April/006972…
I personally love FreeBSD, I’ve used the 5.x series on and off for months, and I really enjoy their mode of development – it seems like their publish papers and debate solutions, rather than just hack something together..
I still wish there was a real FreeBSD desktop effort though, something to give us a graphical installer with tools to setup X and install a nice GNOME desktop.. in the lines of Anaconda which Fedora Core uses.
I hate that I have to recompile my kernel just to make my cd drive work as it’s support to (atapicam seems to be needed for many operations) and stuff like that, but the system itself is wonderful. I know it’s mostly for servers, but I really like it on my desktop as well, and many people like me do, FreeBSD is not just for the server.
I love FreeBSD and I’m looking forward to the 5.3 release, and of course, Marcus is the man…. but for now Fedora Core stay on my computer, since it’s easy to maintain and easy to install (no compiling, minimal need for CLI).
What drive and waht are you trying to do?
Never found any use for atapicam myself or any thing it was required by, other than some cdrecord tools which can’t handle acd. So I don’t use it and use burncd.
I have a Lite-ON cdwriter, the specific model eludes me right now.
anyways I need atapicam to get sound-juicer running as well as nautilus-cd-burner (cdrecord). Without atapicam burncd yeilds coaster burns and I cannot mount iso9660 volumes correctly.
All things I would expect my system to do out of the box.
Odd… sounds like a bad CD drive or something major wrong with it or your setup some where…
try grip