The FreeBSD January-February 2004 Status Report has been published to the freebsd-current and freebsd-stable mailing lists. The archived messages are available online here, and the report is here.
FreeBSD Jan-Feb 2004 Status Report available
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
FreeBSD has to be about the worst case of second system effect I can possibly imagine. This is spread throughout the entire project in various forms. The most notable instance is the design decisions made in FreeBSD 5.x, namely the decision to scrap virtually everything in the current API for threading and SMP and start from scratch, using the theoretically superior M:N threading model. Meanwhile, in practice, this has left FreeBSD plagued by delays. We’re coming up on year 5 of the FreeBSD 5.x project, and the ULE scheduler still isn’t the default in any release, and shouldn’t be due to stability issues. It’s a clear case of “biting off more than you can chew”.
Package management remains a huge problem, such as multiple versions of the same package being installed, destroying the dependancy structure and breaking attempts to provide apt-like upgrades with tools like portupgrade. FreeBSD’s supposed solution, libh, absolutely reeks of second system effect as well. libh is not only a new packaging system, not only a new installer, it’s an installer FRAMEWORK which can be used to write any number of installers. Meanwhile we’re stuck with the archaic sysinstall, which forces many packages to be distributed in chunks, and which now core dumps if you attempt a binary upgrade on 5.x systems.
I don’t mean to sound like a zealot, but I think Linux has taken a much more sensible approach. The kernel’s SMP scalability and threading evolved over time, using existing code and existing interfaces rather than taking a throw the baby out with the bathwater approach. NPTL uses many of the same interfaces to the kernel as LinuxThreads, they were simply refined to improve scalability. Considering FreeBSD implemented many of these same interfaces with rfork, they could’ve easily taken a LinuxThreads -> NPTL approach.
FreeBSD seems like it will eventually be a great operating system… by today’s standards. The problem is our standards will change before FreeBSD’s problems as seen today are actually addressed.
FreeBSD has to be about the worst case of second system effect I can possibly imagine.
And what do you call Windows Longhorn?
The most notable instance is the design decisions made in FreeBSD 5.x, namely the decision to scrap virtually everything in the current API for threading and SMP and start from scratch, using the theoretically superior M:N threading model.
FreeBSD 4.x had a Big Giant Lock on the whole kernel, which kept kernel code from scaling to multiple processors at once. This is how Linux worked back in the 2.0/2.2 days. Linux 2.4 got rid of most of Linux’s global lock, and Linux 2.6 has all but eliminated the rest of it. The FreeBSD team HAD to get rid of the Big Giant Lock in order to scale to multiple processors. And the threading was done in userspace… there’s no way to scale across multiple processors doing that.
Have you seen the Lithium Benchmarks? FreeBSD KSE/ULE is outperforming NPTL/Linux 2.6, especially on things like locking and conditions. So theory has panned out…
Package management remains a huge problem, such as multiple versions of the same package being installed, destroying the dependancy structure and breaking attempts to provide apt-like upgrades with tools like portupgrade.
Funny, I’ve never had problems with FreeBSD’s package management or portupgrade. In fact, I find FreeBSD’s packaging system to be much more flexible than rpm/dpkg, and the only things that come close to rivaling the ports tree are pkgsrc and portage, both of which are copies of the ports idea that are trying to improve upon it.
I don’t mean to sound like a zealot, but I think Linux has taken a much more sensible approach. The kernel’s SMP scalability and threading evolved over time, using existing code and existing interfaces rather than taking a throw the baby out with the bathwater approach. NPTL uses many of the same interfaces to the kernel as LinuxThreads, they were simply refined to improve scalability. Considering FreeBSD implemented many of these same interfaces with rfork, they could’ve easily taken a LinuxThreads -> NPTL approach.
You are obviously a clueless zealot. LinuxThreads on FreeBSD was a hack for cases where threading was useless if it couldn’t scale across mutliple processors, and the only real cases that come to mind are databases. KSE has fixed all of that. It’s done now, why are you complaining about how long it took?
FreeBSD seems like it will eventually be a great operating system… by today’s standards. The problem is our standards will change before FreeBSD’s problems as seen today are actually addressed.
FreeBSD is a great operating system today. In my experience FreeBSD 5.2.1 is much more stable than the whole Linux 2.4 series was until partly through 2.4.1x, when the stability problems were finally addressed.
I don’t know what alternate reality you live in, but some of us just want to get our work done, and for that we choose FreeBSD. I don’t see any compelling technical reasons to use Linux over FreeBSD… my systems are all perfectly capable of handling their workloads. It’s all about personal preference, and some of us simply prefer FreeBSD.
And what the hell does ANY OF THIS have to do with the FreeBSD status report? I think you just saw a FreeBSD related story and decided to troll.
Have you seen the Lithium Benchmarks? FreeBSD KSE/ULE is outperforming NPTL/Linux 2.6, especially on things like locking and conditions. So theory has panned out…
I’d love to see your sources on that.
I don’t know why everyone is calling you a troll. That was actually a pretty well-reasoned comment, applying a well-known phenomenon (second system effect) to an existing OS. I think he definitely has a point that some things (like the new threading model) are too much to chew on at once. Linus, ever the pragmatist, tends to evolve the kernel gradually instead of trying to make huge improvements all at once.
I have to agree with Rayiner Hashem here. Your comment seemed pretty well-reasoned and well thought out to me as well. I like FreeBSD 5.* a lot but I share a lot of those frustrations nonetheless. Particularly with the dependency issues.
SPARCticus:
Have you seen the Lithium Benchmarks? FreeBSD KSE/ULE is outperforming NPTL/Linux 2.6, especially on things like locking and conditions. So theory has panned out…
How about a link to those benchmarks? I’m not having any success with google.
anyone want to give a brief description of what exactly second system effect is? that would help out the less technical people here…
If it means hacking on pieces and kludging then the troll (they’re a troll irregaradless of any valid points they have since their intentions are clear from any of the past posts they’ve made– though that doesn’t deminish the points-in-themselves however) would seem self-contradictory since they are calling it both “kludgy” and “biting off more than it can chew” which is charging both with pragmatism (ie kludging) AND idealism (ie biting off more than they can chew). These are completely self-contradictory traits. Like a kosher bacon double cheeseburger.
The idealism of FreeBSD also seems to be supported by Rayiner Hashem (IP: —.res.gatech.edu)’s contrasting it with Linux’s pragmatism.
Now unless in fact the FreeBSD project really is that bass-ackwards (I’m not an insider so AFAIK it could be…) this seems like bollocks.
—
Now for a question (sorta OT) I’m a CS student and have considered switching to FreeBSD because to me “just works” takes a backseat to learning and from what I hear FreeBSD is more technically interesting (Micro-kernel, more idealism, interesting approach to disk access (ie. slices))… anyone want to comment from a CS (*NOT* IT/Admin. !) P.O.V.?
FreeBSD does not have a microkernel.
No microkernel? I thought FreeBSD was built on top of Mach which is a micro-kernel… and if it isn’t how could they get threads into user-space as the Troll claims or is that wrong? Oh geez, I knew less than I thought.
The “second system effect” is a general observation about software systems. What usually happens to a development team on their first project is that they are unsure about the success of the project, so they act very cautiously, implementing a very simple, straightforward system. If the first project is very succesful, they are emboldened, and start working on a second project.
They’re now sure of the success of the success of the second project, so they go all out, trying to implement all the features that they couldn’t implement the first time around. The system becomes very complex, and the project becomes hard to manage. Usually, deadlines are missed, and the resulting product is released with a lot of bugs and require lots of stabilization afterwards.
Multics is the classic example of the second-system effect at work. Very featureful, very sweeping, very powerful, and very hard to manage. UNIX actually reflects the aftermath of the second-system-effect. After the failure of the second system, the project implementors are sobered, and the third system is again simple and straightforward.
FreeBSD is a monolithic kernel. The usual implementation of Mach, however, has a BSD running on top.
You don’t need a microkernel to have userspace threads. FreeBSD uses what’s called an M:N threading model. The kernel offers regular kernel threads, and has a regular thread scheduler. The threading library then has another scheduler that creates one or more userspace threads. As execution needs change, the userspace scheduler maps one or more userspace threads to kernel threads. The kernel uses upcalls to communicate important information to the scheduler in userspace, so it can manage the userspace threads.
To my knowledge, none of the BSDs use microkernels, although Darwin (the core of Mac OS X) is based directly on Mach, and DragonFly is evolving towards something that can be thought of as a microkernel-like OS.
If Apple really wanted to, it would be very easy for them to make XNU (Darwin’s kernel) into a true microkernel, but it’s not likely that they will, as linking the BSD bits into it has made it faster, and it’s really not that much less stable for it.
“The most notable instance is the design decisions made in FreeBSD 5.x, namely the decision to scrap virtually everything in the current API for threading and SMP and start from scratch, using the theoretically superior M:N threading model…”
Stop right here. This basic assumption is wrong. FreeBSD had NO ‘current API threading and SMP’ in kernel. Support for SMP in 4.x series was nothing more than infamous big kernel lock preventing multiple processors running kernel code at the same time. Scrapping it was the only way to make a progress. Similarly, FreeBSD had no support for threads on kernel level, so there wasn’t even an API to scratch.
“I don’t know why everyone is calling you a troll.”
Kind of depends on how you define troll. A thread is posted. The first comment on the list is somebody trashing whatever OS or app or company is being discussed, and then much of the rest of the discussion is spent arguing over that first comment. How often do we see that in here? At least once a day. Does the person posting that initial comment everytime realize they’re starting a flame war? How can they not knowing in advance that all OSes have fanatics who are going to respond?
People could be a whole lot more tactful in here.
This seems like a well thought out argument to me, not a troll. This is backed up by the fact that everyone who dislikes what you have to say is resorting to childish name-calling, changing the subject “What do you call Longhorn?”, anecdotal evidence “I’ve never had any problems”, “in my experience FreeBSD is better”.
Guys, if Mullighan has made any incorrect observations or assertions, make well reasoned arguments against them. If you can’t do that, then just don’t post anything. I hate to say it, but many of the respondants come across like “desperate teenage FreeBSD zealots” themselves. You aren’t doing your cause any justice.
Support for SMP in 4.x series was nothing more than infamous big kernel lock preventing multiple processors running kernel code at the same time. Scrapping it was the only way to make a progress.
Linux went through the exact same thing, except they decided to go with the inferior 1:1 threading model, instead of the superior M:N one now employed by FreeBSD. Linux’s SMP code is currently more mature than FreeBSD’s however.
Excepting the fact that FreeBSD is a complete OS whereas Linux is not, they seems to stay pretty close technologically.
Linux went through the exact same thing, except they decided to go with the inferior 1:1 threading model, instead of the superior M:N one now employed by FreeBSD. Linux’s SMP code is currently more mature than FreeBSD’s however.
We’ll see whether it is inferior in time. Of course it is inferior if you are a FreeBSD developer, but they haven’t yet come up with the goods AFAIK.
Is the guy commenting on the article or merely venting his grievances against FreeBSD? Is he giving us facts or just his opinions? Does he proved a balanced analysis of FreeBSD’s development or simply rag on the parts he doesn’t like? And finally, he ends it up by suggesting it ought to be more like Linux. This is not using tact and this not engaging in civilized conversation. This is the usual my OS is better than your OS comment.
We’ll see whether it is inferior in time. Of course it is inferior if you are a FreeBSD developer, but they haven’t yet come up with the goods AFAIK.
True; we’ll see, but KSE is ready now, and FreeBSD comes complete with 1:1 threading as well, so you can benchmark both, on an application by application basis.
M:N is superior to 1:1 threading, plain and simple. There are countless papers, google for them, read them. M:N is merely harder to get going initially, and FreeBSD has just come out of that stage.
OK he must have known it would anger FreeBSD supporters so in that sense it is a troll. But first of all, he never said it was better than Linux, just that he thought Linux took a more sensible approach to the specific problems of SMP and threading.
Hard to argue with that if you think about the fact that the first stable release of FreeBSD 5 might be less scalable than Linux 2.4. And that they both started out more or less the same way 5 years ago (start of Linux 2.3, FreeBSD 5).
Second, it really isn’t that bad to admit to mistakes and learn from them, and learn from other projects. I think most FreeBSD developers would say they definitely bit off too much in retrospect.
Yeah, beating the horse just to evoke a response doesn’t get anyone anywhere – but some of the comments might tarnish FreeBSD’s community’s image though. I say ignore him or come up with some calm, rational and reasonable arguments.
True; we’ll see, but KSE is ready now, and FreeBSD comes complete with 1:1 threading as well, so you can benchmark both, on an application by application basis.
I very much look forward to seeing them. With FreeBSD vs FreeBSD benchmarks, you could of course conclude that 1:1 is better than M:N *for FreeBSD*.
I’m sure we’ll see Linux and other benchmarks as well though, which will provide a stronger case.
M:N is superior to 1:1 threading, plain and simple. There are countless papers, google for them, read them. M:N is merely harder to get going initially, and FreeBSD has just come out of that stage.
Well it is assuming that it takes longer to do a kernel context switch than a user context switch plus any additional overhead (if any?) required to support user thread scheduling. This isn’t plain and simple to me, at least.
Hi
“Linux went through the exact same thing, except they decided to go with the inferior 1:1 threading model, instead of the superior M:N one now employed by FreeBSD. Linux’s SMP code is currently more mature than FreeBSD’s however.
”
Linus and all the core developers like to patch things incrementally. 1:1 model is a very valid alternative to M:N considering that the performance boost in 2.6. if you want to cite papers you can do that and provide it. FreeBSD packaging system has its problems. Gentoo provides a better one IMHO. its a improvement on the freebsd ports system with USE variables and more flexibility. Arch is pretty good too. Debian once it improves its installer is a very robust system.
The advantage of not having a complete OS as a single system but multiple distributions allows different people to cater to different market segments. the one size fits all thing wont work in the OS market. We need more specialisation and a dynamically evolved system like Linux has more oppurtunity here. You dont Microsoft badmouth BSD license or the system not because they like it but they can use it to their advantage. GPL prevents them from monopolising the system.
Linux has also acted as a gateway. An introduction to Unix like systems for current freebsd users. The fast evolving nature of Linux does create some problems in certain areas though. We can probably see both these operating systems evolve faster and faster. Linux probably will achieve better deskop market share while FreeBSD should focus on its strength on the server. If M:N does work better in the future Linux users can easily base their work on the freebsd code while Freebsd can offer it as an alternative due to GPL. we already see such GPL components being offered in a similar fashion
The OS market is really getting interesting these days
regards
Rahul
Slow and steady wins the race.
Fast and reckless wins the ladies. 🙂
If they really bit off more than they could chew it’ll be interesting to see what they aim the 6 series at (which they will launch when 5.3 goes stable and in June-ish IIRC)? Will they scale-down their ambitions or do they (the core developers) like the way the 5 series has proceeded. Any FB developers wanna speak out here?
http://www.aims.net.au/chris/kse/docbook/
this is a great start, searching the freebsd mailing list will show many debates about the advantages between Linux’s 1:1 and why M:N is superior for for better scalability.
Linux had working implementations both of M:N threading (NGPT) and 1:1 threading (NPTL). They chose NPTL because it was both fast and easy to implement. The kernel developers found that context-switches in Linux (which have been historically very fast) were fast enough where the theoretical performance advantages of the M:N model didn’t make much of a differences. It should also be noted that Solaris, in version 9, has switched from a M:N threading model to a 1:1 threading model.
http://wwws.sun.com/software/whitepapers/solaris9/multithread.pdf
I might have the solaris versions wrong, but I don’t believe so. Someone feel free to correct me if I did get them wrong, however:
Solaris 8 included capabilities for 1:1 threading, and M:N was the default. I believe you could use the 1:1 model by linking to a different library. It went so well (less bugginess, more performance) that they made 1:1 the default in Solaris 9.
My point is not that one is better than the other. My point is that obviously if it works well for Solaris then 1:1 can certainly work well for other platforms. I think imediately dismissing one implementation when not really knowing anything about the subject suggests zealous bias rather than any objectivity.
Comparisons between FreeBSD’s M:N model and Linux 2.6’s 1:1, in my opinion, is not the best way to compare these 2 ideas. The benchmarks could just indicate that one OS needs more work in the area of threading than the other. I’m thinking comparing FreeBSD’s M:N to FreeBSD’s 1:1 would give a better picture. Though it could just tell us, as an earlier poster mentioned, which one is better for FreeBSD.
Though it would seem that having the added complexity of mapping userspace threads to kernelspace threads, and in addition to the kernel’s scheduler, you have a userspace scheduler, would add a significant amount of both overhead and complexity. So obviously the issue must go deeper then that.
Slow and steady wins the race.
Do you mean FreeBSD is currently going slow and steady, so it will win the race?
Or that Linux started out slow and steady with its SMP work hence it is winning the race now?
Well it is assuming that it takes longer to do a kernel context switch than a user context switch plus any additional overhead (if any?) required to support user thread scheduling.
Let’s not forget about the overhead of having one kernel thread for *every* userland thread when you start using heavilly threaded applications (“enterprise” databases come to mind). Things get evil pretty quickly.
…or does every FreeBSD Status Report story generate a “Which is better, M:N or 1:1 threading” debate?
You dont Microsoft badmouth BSD license or the system not because they like it but they can use it to their advantage. GPL prevents them from monopolising the system.
Oh, it’s nice to see that some people still just don’t get it. The whole point of the BSDL is to let people do almost anything they wish with the code, including MS. Even if MS were to take a copy of FreeBSD and make it completely closed source, FreeBSD would still be open and free. RMS has you very handilly brainwashed if you believe otherwise.
Do you not understand the idea of a gift? The very idea that more a more restrictive license (GPL) is more free is laughable, and even more so is the fact that so many people have bought into it.
Lets get back to technical merrit now shall we?
Is it just me… or does every FreeBSD Status Report story generate a “Which is better, M:N or 1:1 threading” debate?
I don’t think you’re dreaming it up. As a whole, it seems that OS enthusiasts need to get a life.
FreeBSD had no support for threads on a kernel level, so there wasn’t even an API to scratch.
Not quite. rfork() took parameters to more or less emulate the behavior of Linux’s _clone(), which is used to spawn a LWP under at least LinuxThreads, and I believe is still used by NPTL as well. There was a native rfork()-based port of LinuxThreads as well, which could be used in place of libc_r.
Of course, this is only really useful for multiprocessor FreeBSD 4.x systems. FreeBSD 5.x users can simply link MySQL against a KSE threads library.
The trolling that has been going on is unfounded. Statements like ULE isnt the default schedular is untrue. Here are the facts which the writier either doesnt know about or is falsifying:
1)FreeBSD: ULE Becoming Default Scheduler In -current
Posted by jeremy on Saturday, December 13, 2003 – 08:28
http://kerneltrap.org/node/view/1785
2)I have had no issue with portupgrad in anyway, shape or form. Please provide data and back up your statement. Please read the man page for using the upgrade script.
3)Your statement of upgrading from stable to current is equivalent to upgrading from 2.2 to 2.4 or 2.4 to 2.6. How is this any different from Linux kernel upgrades?
4)Archaic sysinstall? Is that archaic, like the command line? Please quantify your statement? You cite debian as an example, they have just upgraded their install proceedures using Anaconda. And it is text based, looks like slackware or sysinstall.
5)POSIX Threads: Have you read what is going on with KSE and POSIX Threads. Here is a summary:
Kernel Scheduler Entities (KSE), is a kernel-supported threading system similar in design to Scheduler Activations [Anderson, et. al.]. It strikes a balance between user-level (1:N) and kernel-level (1:1) threading models, giving most of the advantages of both, and few of the disadvantages of either.
http://www.freebsd.org/kse/
I have backed up my statements and addressed yours. Please back up your statements.
1. I quote “We’re coming up on year 5 of the FreeBSD 5.x project, and the ULE scheduler still isn’t the default in any release”. That is correct as far as I know.
2. … (I’m not the one with the possible problems, so I can’t say anything here)
3. I’m not sure what statement you are referring to, but upgrading the kernel in a Linux system is very different to upgrading the entire OS in FreeBSD… as I don’t know what you are referring to I can’t give you anything better.
4. He said it was archaic because “[it] forces many packages to be distributed in chunks, and which now core dumps if you attempt a binary upgrade on 5.x systems.”. Maybe he has other reasons though.
5. All he said was that they could have taken a LinuxThreads -> NPTL approach, which is true. And it might have been done sooner considering KSE has been in the works for 3 years or so and is only just made the default in their unstable CURRENT branch.
Let’s not forget about the overhead of having one kernel thread for *every* userland thread when you start using heavilly threaded applications (“enterprise” databases come to mind). Things get evil pretty quickly.
Not much memory overhead because they share basically everything except execution context. 8K per process on IA-32, and that is soon to come down to 4K. Algorithmically it isn’t a great problem either – Linux’s scheduler is O(1).
So it isn’t too bad.
My point is not that one is better than the other. My point is that obviously if it works well for Solaris then 1:1 can certainly work well for other platforms. I think imediately dismissing one implementation when not really knowing anything about the subject suggests zealous bias rather than any objectivity.
Check what the “pthread guru” David Butenhof has to say[1] regarding the SUN’s implementation on M:N threads:
“Yes, it is hard to get M:N working right, though there are real advantages. (System Software development is not generally dedicated to the principle of avoiding “hard” problems, after all.) But the history of Sun’s trouble with M:N isn’t nearly as much technical as political. Even when developers tried to address design problems, they weren’t allowed. So, yes, giving up on M:N probably was the best course, for Sun. M:N isn’t something that can be done halfway — you either commit to the whole thing and follow through, or you’re better off not trying. Unlike Solaris, the Tru64 UNIX M:N scheduling model was actually designed to work, and does. It (like all else) isn’t perfect, but it scales, it supports detailed and effective debugging, and it’s cleanly and deeply integrated with the kernel.”
[1]: http://tinyurl.com/2zs6w
Stelios
“FreeBSD’s supposed solution, libh, absolutely reeks of second system effect as well. libh is not only a new packaging system, not only a new installer, it’s an installer FRAMEWORK which can be used to write any number of installers. Meanwhile we’re stuck with the archaic sysinstall, which forces many packages to be distributed in chunks, and which now core dumps if you attempt a binary upgrade on 5.x systems.”
libh was a proposed solution quite some time ago. While the docs are still publicly available, many developers have long regarded that approach as overkill (doing “too much”) and there hasn’t been any libh work for at least a year(..if that). There are dragonfly developers that are attempting an alternate solution for the “archaic installer” problem. They will most likely be successful, but it may take a while.
Like everything else in *bsd/oss development, people, time and testing are necessary to generate improved functionality. There has long been a shortage of people contributing to core kernel work and general testing in bsd (shortage being a relative term – it depends on what other OS projects you’re comparing with). Along those lines, you’re either part of the solution or part of the problem – you can complain here on osnews, you can simply use something else, or you can give them a hand.
Hi
“Oh, it’s nice to see that some people still just don’t get it. The whole point of the BSDL is to let people do almost anything they wish with the code, including MS. Even if MS were to take a copy of FreeBSD and make it completely closed source, FreeBSD would still be open and free. RMS has you very handilly brainwashed if you believe otherwise.”
Actually you dont get it. GPL prevents people from having to compete against a proprietary version of their code. BSD isnt designed for this. BSD allows complete freedom while GPL could be called share alike or democratic.
A license is as much a legal and technical issue as a political one. I dont care for what RMS may say. The license is a legal document and it speaks for itself
regards
Rahul
Yet here we are arguing about M:N vs 1:1 threading BSDL vs GPL etc. The first one I can sort of understand as it is a technical thing. But another license arguement? Come on folks who really cares?
On another note why are people comparing 5.x with kernel 2.6.x? One is stable and production ready the other is still in beta and not meant for end user use just yet. Going from this, one should not expect bug free operation when using 5.x while they certainly should with 2.6.x.
Though the fact that a certain poster who is kicking on FreeBSD here is doing the same about SkyOS in another thread leads me to believe that they don’t really have anything of merit to say but rather just can’t stand people using something other than Linux. I’m really sorry if you feel that way, but it’s your loss. Later all.
Jared
Bah!
There are no problems with the packaging system, just occasional problems with a package. Gentoo offers no more flexability. Simple put man ports and learn how to bloody use it!
BTW linux does not all ways act as a gateway, there is plenty chance for some body to jump right into to FreeBSD with no prior unix expeirence.
BTW please stop spreading anti-BSDL FUD, it is annoying.
Dude, GPL is far from being democratic and allows no freedom and inhibits innovation by putting roadblocks in the way. The way it does this is it prevents stanards from easily being adoptable between things.
BTW you should care what the nute case says, since he was one of the ppl originally responsible for it.
BTW on a seperate note to the ops/whatever what the bloody heck was up with not modding that troll, Mullighan (IP: —.com) – Posted on 2004-03-18 02:18:30, down!?!?! That was nothing but complete and blatant FUD and trolling. If you don’t believe feel free to browse the maillist archive and ect on freebsd.org and see why for yourself.
For some of us, it’s lovely to get the BSD news… I mean some actually like Operating systemS (as in more than one).
Choosing FreeBSD for a task is not necessarily a choice between Linux (the kernel only???) and FreeBSD… but perhaps other merits. Perhaps it’s our general interest in operating systems… perhaps we find FreeBSD handy to work with… perhaps we find it easier to secure a FreeBSD install… perhaps it’s rapsheet looks better to us historywise…. perhaps our upcoming 10 years with this computer sounds more manageable with BSD and it’s upgrademethods…. perhaps we prefer the license… perhaps we don’t care about Linux????
I’m happy to see the newsitem, I couldn’t care less what choice Linux made about threading… I’m not interested in Linux anyway… so why bother taking it up. It’s very few BSD users who are unaware of Linux existence… so let us be alone. IF we wanted to know about how you feel about threading, we’d probably check some linuxforum about “BSDs are Dying with it’s growing userbase”..
Why do I get the impression that there are many people here that are against anything that is not Linux? Really, is the OSS movement about getting to people to use OSS or getting people to use Linux?
Linux development tends towards an attitude of “we only want users”. On the other hand, FreeBSD is taking the time to explore interesting ideas in computing. So thanks to FreeBSD making the tough choice of spending a lot of time on M:N threads, we will have an open implementation of this idea. This is great as it allows people to compare and contrast M:N threading vs 1:1 threading.
Things like smartupdates are also interesting, as well as the FreeBSD vm. Smartupdates may be impractical in many systems due to being very closly tied to the kernel. Non-the-less, it just shows that there are alternatives to traditional journaling that work very well.
The FreeBSD vm has great performance, but more interesting is it’s development. It’s quite complex and uses a new paradigm in programming known as aspect oriented programming. That was an interesting idea, and an interesting application of that idea.
In short, FreeBSD and the BSDs in general do great service to computing and OSS. They try out new ideas and in doing that give a lot of knowledge to the community at large. If you happen to like Linux then good for you. But please refrain from the “FreeBSD suxors, you should use Linux” type comments. Some of us are interesting in more than just taking over the world with Linux. Some of us are interestd in technology.
Personaly, I’m very interested to see how the 5.x series turns out. I’m also very interested in DragonFLY, since they are doing some cool work too.
And what exactly oh master of my knowledge, do I not understand about the GPL?
I assure you, I have a pretty damned good understanding of it, and very likely a better understanding than do you.
Hi
“And what exactly oh master of my knowledge, do I not understand about the GPL?
I assure you, I have a pretty damned good understanding of it, and very likely a better understanding than do you.”
Your claims are otherwise. When you talk about RMS and freedom you should understand the license is different from idealogy. its a legal document and the gnu chain of tools including gcc is fundamental to the development of every free software including *BSD too.
The reason GPL is being attacked is because it only allows a free foundation of software without proprietary components over it. BSD is free for all. GPL is share alike
If you have a better understanding of GPL tell me what you understand and why is it better?
regards
Rahul
its a legal document and the gnu chain of tools including gcc is fundamental to the development of every free software including *BSD too.
Wow. Where to begin unbrainwashing you. The BSDL is no less a legal ‘document’ as you call it than is the GPL. A license is a license regardless of the details.
As far as the GNU toolchain being ‘fundamental to all free software’ wow, I mean, wow. It’s definately true that GCC has long been used in the BSDs as well as under Linux, but if you’ve been following the BSDs in the last year or so, you’d have noticed all the work being done to make the kernels and userlands compile cleanly with ICC and other free compilers. Just the other day I built FreeBSD 5.x with ICC. No need for GCC there.
The reason GPL is being attacked is because it only allows a free foundation of software without proprietary components over it.
Uhm, no. What I ‘attack’ every now and then the idea that the GPL (a very restrictive license) is more free than the BSDL (which has far fewer restrictions, fewer restrictions == more free, simple logic that irritatingly gets lost on simple minds). I don’t care if people like or use the GPL, but for some twisted reason, I do care about the fact that so many folks have allowed themselves to be brainwashed by RMS into believing that the GPL is ‘more free’ and the idea that it is needed to ‘protect’ ‘free software’ from anybody.
Mindboggling how easilly people fall for things like that.
I don’t care much for ideologies. I have my own, sure, but none of them involve software.
Hi
”
Uhm, no. What I ‘attack’ every now and then the idea that the GPL (a very restrictive license) is more free than the BSDL (which has far fewer restrictions, fewer restrictions == more free, simple logic that irritatingly gets lost on simple minds). I don’t care if people like or use the GPL, but for some twisted reason, I do care about the fact that so many folks have allowed themselves to be brainwashed by RMS into believing that the GPL is ‘more free’ and the idea that it is needed to ‘protect’ ‘free software’ from anybody. ”
Point me to where RMS says that. I have not been brainwashed. GCC still is fundamental along with the rest of the gnu toolchain even if you happen to use ICC
BSD is free because it allows you do anything about it. GPL demands that you share what you work upon as the base. RMS says that choosing GPL means you dont have to compete with proprietary forks of what you might as well as happen to have developed under BSD before and he is right about that.
I said GPL is a legal document because many people just look at the idealogy and say I dont use GPL because i dont agree with what RMS says. I am just pointing out that there is a difference between what you get through GPL and what RMS says he wants to achieve. BSD is definitely a legal doc too
regards
Rahul
Enough of the “my threading impl is better than yours” arguments.
The only way that you can really test is in a real world application. Java, a factor in why the Linux threading model was overhauled, springs to mind.
Let’s compare in 12 months time the performance of, say, tomcat running on native JVMs on FreeBSD and Linux once optimisations have taken place.
I’d also be curious to see what sort of performance can be achieved with DragonFly. Hopefully the fundamentals of the fork won’t diverge too much that the FreeBSD Java porters won’t also port to DragonFly…
http://osnews.com/story.php?news_id=6338
RMS says that choosing GPL means you dont have to compete with proprietary forks of what you might as well as happen to have developed under BSD before and he is right about that.
I never had issue with this statement. I also don’t have issue with competing against proprietary forks, as the free version will still be available. As (for example) GCC still has to compete with other compiler collections, it strikes me as a moot point anyway, you’ve not eliminated the competition, proprietary or not.
In a Universe such as ours that is getting larger all the time, there is room enough for all possibilities, even ones that we don’t like.
*shrug*
Hi
“I never had issue with this statement. I also don’t have issue with competing against proprietary forks, as the free version will still be available. As (for example) GCC still has to compete with other compiler collections, it strikes me as a moot point anyway, you’ve not eliminated the competition, proprietary or not.
The difference is that the competition with gcc is not using gcc’s code. Very big difference there
regards
Rahul