Slashdot Mirror
A Comparison of Solaris, Linux, and FreeBSD Kernel
v1x writes "An article at OpenSolaris examines three of the basic subsystems of the kernel and compares implementation between Solaris 10, Linux 2.6, and FreeBSD 5.3.
From the article: 'Solaris, FreeBSD, and Linux are obviously benefiting from each other. With Solaris going open source, I expect this to continue at a faster rate. My impression is that change is most rapid in Linux. The benefits of this are that new technology has a quick incorporation into the system.'"
If only they could compare the NT kernel along with them
*sigh*
perpetually dwelling in the -1 pits
At this point, in order to see the kernel, you have to sign off on MS's shared source license. By doing that, anybody in the OSS world who signs, is then at risk of being at the receiving end of a MS lawsuit. It would be just as bad as signing off on a SCO license.
I prefer the "u" in honour as it seems to be missing these days.
And let the flamefest begin...
Cheers,
RoadkillBunny
" A Comparison of Solaris, Linux, and FreeBSD Kernel"
One is crunchy, the other's chewy, and the last is malt flavoured.
Solaris 10, Linux 2.6, and FreeBSD 5.3... all have strengths, weaknesses, features, and deficiencies... so why hasn't the OSI succeeded in the cross-pollination of these three great OS's? If they're really going to benefit from each other, why not get some linux kernels with SMF or better SMP out there? When will apt finally replace /usr/ports in FreeBSD? And when will Soalris' TCP stack not suck by implementing code from Linux or BSD? I hug all three of these OS's on a daily basis, but if open source is really working why can't we seem to make an OS out of these three that flat out rocks?
Does anybody know why ReiserFS 3 hasn't been ported to any of the BSDs yet? ReiserFS 4 looks as though it's pretty revolutionary, if distributions settle on that as a default, I can see that giving quite an advantage to Linux compared with the other kernels.
I noticed that the article didn't mention LUFS. This alone allows for tremenduous possibilities, not least of which is rapid development of filesystems. Do any other systems (besides GNU HURD) have userspace filesystems?
Bogtha Bogtha Bogtha
The article was a little bit short and without sufficient substance to be noteworthy on slashdot, I think.
For every problem, there is at least one solution that is simple, neat, and wrong.
Interesting comparison between the Linux and Solaris kernels from someone who used to work SunSoft in the kernel group.
http://www.ultralinux.org/faq.html#q_1_15
First off, neither the Solaris or FreeBSD kernel are microkernels. That being said, there are a couple different things available under Linux which are analogous to Dtract. The only downside as compared to Dtrace, you can't insert probes dynamically at runtime. But then this is all of the top of my head of course, so I may be way off.
Free will is just an illusion
While not entirely equivalent, kprobes do give you an excellent way to examine and monitor the current system state.
However, the quality of a kernel is not automatically improved by the inclusion of DTrace. Not to disparage Solaris and FreeBSD, but DTrace is primarily for kernel developers and sysadmins. The common user and app developer have little use for either DTrace or kprobes.
A) All of those OSes are macro.
B) Linux has SystemTap, which goes above and beyond what DTrace is capable of. It is still in heavy development by Red Hat (Intel and IBM also helped start up the effort), and it's already quite a product.
Your post was one big troll, why do you find it amusing to spread random misinformation?
Regards,
Steve
Neither Solaris nor FreeBSD are microkernels. Perhaps you are thinking of Mach?
Also, issues preventing the porting of DTrace to other systems would be because of licensing, not technology.
The term is usually "monolithic kernel", rather than "macrokernel".
Cyric Zndovzny at your service.
How about data from this century?
They wanted to test a real OS, one that can scale to more than 2 processors.
The only thing that is clear is that you're a moron.
Solaris and FreeBSD are both 'macrokernels'.
And I don't think anyone will ever want to know whether or not you can see Linux "comparing in the enterprise", so don't be too worried about that.
For hyperthreaded CPUs, FreeBSD has a mechanism to help keep threads on the same CPU node (though possibly a different hyperthread). Solaris has a similar mechanism, but it is under control of the user and application, and is not restricted to hyperthreads (called "processor sets" in Solaris and "processor groups" in FreeBSD).
I am positive that the 2.6 kernel understands hyperthreading and does something similar to FreeBSD. Why wasn't that mentioned? Did the author not know that?
Overall through, it was interesting. I'd read it as a longer series, if they had one. This is an area that I'm interested in. I read kernel-traffic, and subscribe to LWN (you should to!) almost entirely to read the kernel page. I've learned so much about operating systems and computers from reading about the improvements in the Linux kernel, why the old version wasn't good enough, etc. While I no longer use Linux since I got my Mac (OS X fills all my needs), I continue to learn a large amount about computer architecture and operating system concepts from it.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
Your data is so old that the byline is by one "T. Rex."
Just "gittin-r-done," day after day.
Plan 9 had userspace filesystems. Moreover, it encouraged services to export control interfaces as filesystems -- so you could mount a service and then configure it using open(), read() and write().
Have a look at the Plan 9 wiki. You can even run it inside vmware or Xen.
Anyone know if FreeBSD is still using the big lock for SMP?
If you don't want crime to pay, let the government run it.
You make some interesting points.
My karma is not a Chameleon.
Thats completely twisting the articles wording around. What gives; pay attention when you read things. He was comparing what happened, assuming a failure had already happened, from a developing perspective. From my non-biased eyes, I could see that he was trying not to flame differences, but to instead show similarities, to show how they each approach things with a different overall goal in mind.
I gathered from it that; linux wants speed and compatability (x86 oriented goal), solaris wants customizeability and reliability (speed and compatability arent an issue if you make your own souped up hardware), and BSD is somewhere in between (???).
If Tyranny and Oppression come to this land,
it will be in the guise of fighting a foreign enemy. -James Madison
1. The SELinux kernel wasn't mentioned; it's security model is different, perhaps better in the final analysis than OpenSolaris.
2. The concept of Solaris containers is nearly science fiction. Building them and then watching them through dtrace is a work of art, as in the Sistine Chapel. LVM is a different school of thought that gets to a similar conclusion; this all skewed by the beauties of VMWare and multiple instance/clustering management possibilities.
3. The licenses-- very important differences in licenses-- are glossed==> ignored. There's all that messy intermingling of licensing trivia that's somehow an invisible characteristic of all of this. Fooey.
4. While Sun can speak anytime Sun wants, at least there were other citations mentioned early. This is Sun propaganda. Remember that. Well thought out propaganda, but propaganda, not a third party examination of the facts and implications.
5. There are other *nixes missing. Consider that real-time OS and embedded OS considerations are real, and while BSD and Linux has made progress there, Solaris is essentially missing, unless you consider weird programming profiles still based on non-Solaris OS.
These are just the extemporaneous thoughts. Take this article with a grain of salt, although it's not bad for a vendor-hosted view.
---- Teach Peace. It's Cheaper Than War.
I know plenty about ReiserFS. Had you read my post you would have understood that the problem is not with the concepts and algorithms of ReiserFS. The problems are not with the idea nor the Linux implementation, but instead with trying to tack the Linux implementation onto the FreeBSD kernel.
You cannot take code from two radically different projects, stick them together as is being proposed by others, and then have it magically work. You could run into issues with the FreeBSD file buffering subsystem, for instance. Code that may work perfectly under Linux may very well fail under FreeBSD. And you can't have filesystems failing.
It's a problem of merging two distinct and different codebases, not a problem with ReiserFS itself.
Cyric Zndovzny at your service.
There was no mention of XFS or JFS for Linux. Indeed, for certain server applications those filesystems prove to be very effective.
Cyric Zndovzny at your service.
You are. Solaris has a microkernel. Two peice static core and everything else is dynamically loaded. IMHO a far superior model to using modprobe.
Moderators:
Before moderating CyricZ's posts, please take the time to view his posting history.
He posts a LOT and only makes stupid and/or overly obvious points, and he often mis-represents people's comments when replying.
Basically, he is full of himself, and reviewing a few of his posts reveals him.
Read this comment for more information.
Yeah, it's more of a life style choice.
Do you even lift?
These aren't the 'roids you're looking for.
Indeed, the professionalism of the Solaris and FreeBSD developers can serve as a model for the entire open source community. Now, it's not surprising that the Solaris developers project a very professional image, considering their business roots. Many of the FreeBSD developers are professional consultants, who know how to properly deal with clients.
Indeed, the instance of the KOffice developer who went around publically insulting a long time KDE and KOffice user is a perfect example of the sort of unprofessional behaviour that should be avoided.
One thing you do not see from the Solaris and FreeBSD developers is insults directed at their users, clients and customers. There may be internal squabbling between the developers, but as true professionals they will keep this between themselves.
Cyric Zndovzny at your service.
he claims that due to it's abstraction Solaris should be easier to port then Linux.
if so why does Solaris only run on 2 CPU types (x86 and Sparc) while Linux runs on far more (somewhere around 20 IIRC, Debian supports over 11)
Since they wrote the linux kernel, SCO engineers had a lot of skill and foresight to create such a great operating system.
Don't say it isn't true - or our lawyers will be calling.
Dynamically loaded kernel modules != microkernel, retard. Solaris is not a microkernel.
The article is purely technical, and does not focus on topics (like licensing) that often lead to flamewars and other disagreement. Indeed, it is written in such a way that only the technical issues are discussed, rather than ideological issues.
Cyric Zndovzny at your service.
It is superior, also because it runs driers in the same context as the microkernel. That's why it's faster than Mach or QNX
(%i1) factor(777353);
(%o1) 777353
"As most of us know, goatseFS is NOT a filesystem."
GoatseFS is sort of the Roach Motel(TM) of filesystems. Your data checks in, and no one wants it back.
It mainly has to do with historic reasons. Until a few months ago, Solaris was a proprietary, closed source system running only on Sun's SPARC-based hardware, and on some x86-based systems (albeit with fairly poor hardware support). Sun had very little reason to perform ports to other platforms, and since the source code was not available to others under an open source license, such ports were not performed by a third party.
But we're seeing that change now. There's a PowerPC port in the works, for instance.
Cyric Zndovzny at your service.
I put the title in all caps because I am responding to dozens of people claiming Solaris is monolithic. It is not. The Solaris microkernel is a stripped-down SVr4 kernel. Drivers are loaded from it and run in the same context for performance reasons, everything else outside of scheduling, interrupts, and a few other services runs strictly in user space and is dynamically loadable. I've heard the model referred to as an "object-oriented" architecture, since modules can call functions in other modules, though Mach, the famous microkernel, is also pretty thoroughly object-oriented, as is Windows XP's kernel, so this is somewhat confusing when used as a term to differentiate the architecture from a microkernel.
(%i1) factor(777353);
(%o1) 777353
Moderators:
Before moderating CyricZ's posts, please take the time to view his posting history.
He posts a LOT and only makes stupid and/or overly obvious points, and he often mis-represents people's comments when replying.
Basically, he is full of himself, and reviewing a few of his posts reveals him.
Read this comment for more information.
Wow... you obviously don't know jack about FBSD community...
/. user getting forcibly corrected (rightfully so), and somehow stating that as the norm, and that a community that has had some seriously obnoxious prima donna devs is a good model.
Granted, not stating all are asses, not even stating a significant percentage; merely pointing out that you're being an idiot and pointing at one example of a
So... you're trolling, effectively. Good job also, I took the bait.
I wish I had mod points right now plus the ability to Moderate this entire article as Flamebait :)
But flamewars are so much fun to read, so bring it on!
I find it quite interesting that (at least according to the article) Solaris (which supports a few x86, and mostly Sun's Sparc line) has a full abstraction, while Linux (which supports some large number processor architectures) goes with less abstraction; with FreeBSD somewhere in the middle. It certainly does yield higher performance for Linux, and makes sense in that respect...It's just interesting that the OS that seemingly runs on fewer processor architectures and has been controlled by an incorporated company would take the abstraction route, while the OS that runs on a far greater number of processor architectures and is not tied to corporate funding (directly, at least) is more focussed on less abstraction & fewer layers.
P.S. Sorry to repeat myself on that...just not sure how best to say it.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
If I was wrong then it would have been more than acceptable for that KOffice developer to point out that I was incorrect. However, I was not. I was completely right. That's why he had to resort to insults in his discussion with me. Since I was wielding the truth, he had to rely on childish namecalling.
Regardless, it was a very unprofessional act to perform. At least there are others on the open source community who do set a good example for the other developers.
Cyric Zndovzny at your service.
Those VMware images are for older versions of vmware and do not run under current 5.x version of VMware. Or at least I was unable to get them working in the 15 or so minutes I spent with them.
Aparently you need to stop reading the media and do a bit deeper research into what systemtap is and how unstable it is. You can start with Active Bug, non guru mode. That bug affects non-guru mode, which is supposed to be safe to use in production. Nothing like that ever happens in dtrace. Why you may ask? Because its developed to be safe in Production use at the expense of giving up some features. For a more indepth comparison of systemtap and its problems check out the links mentioned in my blog's SystemTap Links. Systemtap vs. dtrace the debate continues is a good place to start.
Of course, systemtap is still in its infancy, perhaps after a couple re-writes that seem standard in major components in the Linux Kernel, they can make it stable. But today its, not and any where near stable. There for your statement of "Linux has SystemTap, which goes above and beyond what DTrace is capable of. It is still in heavy development by Red Hat (Intel and IBM also helped start up the effort), and it's already quite a product." Is complete rubish. Of course one would have to think about. If its still under heavy development, also shows just how far from ready it is.
Of course, the truth really is that DTrace is far more feature rich than systemtap is, or will be for a long time. Systemtap biggest stumbling block is "guru mode" that allows the user to disable any protection that systemtap engineers have added. Systemtap's language is lacking in some basic concepts, like variable types like struct and typeset, making guru mode necessary for far too many scripts, and in-escapable when userland probes are created. Along with the other problems documented in my blogs.
You may try and dismiss me as a troll, but nothing could be farther from the truth. I'm stating the facts, I have also contributed to the Systemtap product, and commented on code changes. But I refuse to sit quietly as people try and pass Systemtap off as stable or better than DTrace. Dtrace is stable, and Enterprise Production ready and more full featured than Systemtap, even though they have left out features, that have to be worked around by the programmer.
Are you trying to troll the AC? There's no GoatseFS in there.
Game! - Where the stick is mightier than the sword!
Its been what, 2-3 years since the open-source solaris announcement came out? How much has been open sourced? AFAIK, all the have opened sourced is DTrace (a very cool tool/framework), but nay else. Lets see them open up the kernel internals like the thread model... I am skeptical that Sun will ever release their Kernel as open source as I recently had Sun reps argue with me that Linux/FreeBSD is 'single threaded' and cant scale across more than one cpu, to which I replied 'Bovine Scatlogical Pathology'. Sun is a hardware company people, and keeping Solaris uber-elite and closed source is their only way to sell expensive hardware.
Wow! Is that all it takes to get a +5 Insightful now? So I guess this will be modded Troll or Flamebait.
I can never really understand why FreeBSD ports is better than Debian's APT. Perhaps it's only because they look at "package installation" as the only use for these tools, whereas I use these tools for "package management". Everything comes down to the packagers who make and maintain the packages and the quality of the tools used to make and maintain the packages. I've used FreeBSD, Gentoo, and finally Debian for servers and desktops. Based on my experience APT is a more elegant solution to package management compared to FreeBSD Ports and Gentoo Portage for the following reasons:
Package Building
Although building Debian packages can be a bit overwhelming especially for newcomers, it really shines especially if you have installed debhelper, dh-make, dbs, dpatch, and lintian. What's really great about APT is the automatic runtime dependency resolution prior to packaging the final debs. After building the package and before it gets packed into a deb, a dependency checker is run through it and it will automatically figure out the runtime dependencies for you. On FreeBSD Ports and Gentoo Portage, you have to figure out and specify runtime dependencies yourself.
The "Dusty Deck" Problem
When I install a package using ports or emerge, it will also install the dependencies. But most of the time you will essentially be installing from source (and yes I am aware that Ports and Portage also have pre-built packages). When you do that, Ports and Portage will install and build the build-time dependencies of the package you are installing. Now, that's fine if those build-time dependencies are also needed at run-time. But some dependencies are only used at build-time and will never be used again until you upgrade the packages that depend on them. You can decide to remove them after build time, but then when you update the package they will be downloaded, rebuilt, and installed again. You eventually grow tired of this cycle that you just leave these build-time only packages and then they continue to accumulate on your disk mostly wasting space.
This is probably the reason why there are "developer" packages for libraries that contain only the header files and the link libraries. Once you're done with building, you can uninstall the developer package. Try doing that under Ports or Portage. Oh, wait! You can't. The runtime and build-time dependencies are all in one package.
Package Uninstallation
Now this is where Ports and Portage, IMHO, really suck. When I uninstall a package from my system I want it gone. apt-get remove --purge and a properly packaged deb will do that for you. Ports and Portage will leave "package cruft" on your system. "Package cruft" can be anything from stale config files to build-time dependecy packages. You will have to track and remove those things manually.
I know these three points can be resolved on both Ports and Portage if the packages are done correctly. This is where APT has an advantage over Ports and Portage: being able to make a proper package. On Debian, with the tools I mentioned above installed, a package maintainer's life is greatly simplified.
Ports (and Portage) does Rock, but only if all you ever care about is package installation and not package management (package building, installation and uninstallation).
. As a USER, what I really care about is overall performance of a kernel.
Ok, so as a USER, why would you care about MySQL? Because as a SYSTEM ADMINISTRATOR, what I really care about is stability and easy of administration. Once performance reaches "good enough", I could give a shit about improved performance. Hardware is cheap, a $5,000 1U MP system can blast down just about anything I'm going to care about.
But, I want it to work today, tomorrow, next week, and next year. I want to reboot when I plan to (doing a kernel update, for instance) and only then. It had better be stable, and shouldn't be all that noticable in my day-to-day schedule. Doing updates had better not involve a half-day compiling, because downtime is !@#!@ expensive.
But, performance? Can you name a SINGLE INSTANCE where you chose your O/S based on some performance graph? Unless your technology depends on Windows (I feel for you if it does) any of the *nixes out there are "good enough" to do just about anything up to the very high end. (Linux/BSD/Solaris/AIX/OSX/etc) Even at the very high end, it's unlikely the choosing the "worst" OS will cost more than switching to the "best" OS!
In the end, it really doesn't matter all that much. Pick what you like, and roll with it. Performance is way down the totem pole, pay attention to stability, security, licensing, and compatability with your specific needs. Then, worry abouut performance!
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Did you not see that the FS table is a partial list? The author only mentions it like two times.
The article is quite fair, generally, and honest in what's included vs. left out of the discussion.
The articles pointed to by this article seem to be pretty blatant solaris propaganda (or at least solaris fanboyism). Just check out this gem that the article claims contains facts. Here's just one great quote from the article:
"Currently Solaris 10 patches are still free for servers without support contracts which is nice for enterprise, but is really important for home users and hobbyists. Of major Linux distributions only Debian and Gentoo has free patches available, but using Debian puts you into the situation that is called "Not a Red Hat"(NRH): Red Hat commands well over 60% of Linux marketplace and that instantly shows in the availability of RPMs, commercial applications, books and other things. "
When was the last time I wished I could go through rpm hell instead of just apt-get install? Idiotic.
--
The Switchboard, a free, browser based, internet phone
You know shit, you fatherless bastard child of crackyness.
The guy is using MySQL, is that what you use when you need stability or enterprise class reliablity? Linux is the sane choice here, it enjoys wider hardware support and is faster. Not that I expect someone capable of posting a misguided pissy little rant such as yours to appreciate sanity.
> There's no GoatseFS in there.
:)
But if there were, I bet it would be an open system. A very open system!
(Sorry...)
It is even worse than that. A monlithic kernel means that almost everything (kernel, device drivers, filesystems, etc.) runs in kernel mode. A microkernel uses messaging to move everything but the kernel out of kernel mode. An exokernel runs on a skeleton of code in kernel mode and everything else (including the kernel) runs in userland. An example of an exokernel is QNX. An exokernel provides very very reliable system uptime but at the expense of performance.
I believe that Linux, Solaris, and BSD are all monolithic kernels as are the Windows kernels (NT and others). OS X is a microkernel.
The three types of kernels are a spectrum trading performance for reliablity. Like most everything else in programming it is a trade off between two inversly related goals.
"Those that start by burning books, will end by burning men."
Just because there's a version of NT that can run on a 128-CPU SMP box doesn't mean it scales that in real-life situations.
If it did, with all Microsoft's billions of dollars, how come there's no NT equivalent to this for Linux, or this for Solaris?
Those two bad boys scale damn near linearly. I know that, I don't have assume that. I can afford a 7-figure house because I can make those things sing. That Sunfire E25K has 72 CPU slots, and each UltraSPARC-IV chip has 2 full CPUs on each die. The IBM 595 has 64 CPU slots, and when I was at SC-04 in Pittsburgh last year, IBM claimed they were working on an 8-way version of their Power CPU. That's 512 CPUs on an SMP box.
There's nothing like that in the NT world that anyone could buy. And you don't have to sign some NDA that would keep you from getting a job in a lot of places to see the source code for either OS.
Keep your damn toy OS, and your self-admitted assumption that "NT knows how to handle more than 2 processors", because there's no commercially-available system to support that assumption.
You may try and dismiss me as a troll
"try to dismiss".
DTrace isn't just for kernel developers and sysadmins -- it's also for any type of developer. Take for example the recent DTrace support for Java, php, and Ruby. To your second point, you care about DTrace because you care about absolute performance. Maybe yours is a configuration that never suffers from performance degradation during a period of aberrant activity, but most applications do have some conditions where performance drops unacceptably. In those cases, you're at a huge disadvantage on a system that doesn't have DTrace to help you diagnose and resolve the problem.
And they're coming to Linux in 2.6.14, the port of the 9P protocol has been included. FUSE (a alternative filesystem-in-userspace approach) has also been included
Secondly, OS X is a monolithic kernel. Mach is a microkernel, and some of the Mach functionality is used by OS X, particularly at a higher level since it provides a clean mechanism for moving data from kernel to user space (Mach ports), allowing things like power state change notifications without polling. All parts of the OS X kernel, however, run in ring 0.
Oh, and a well designed microkernel doesn't sacrifice performance. Microkernels can be much faster when performing asynchronous operations, it's just when they are crippled by the need to provide something like a POSIX interface, which heavily favours monolithic kernels, that they lose out. Compare QNX running native QNX code, to QNX running POSIX code (and Linux running POSIX code) doing the same thing as an example.
I am TheRaven on Soylent News
I was very surprized given Linux's advantage of the "Viral" GPL license and big development bucks (although Apple puts $ into FeeBSD), that they were so close. Omitted in Linx's favor is its much faster thread implementation. LET COMPETITON RULE!
Actually, I have several children. They're all adults now, too. And to top it off, I was correct. That's probably why the KOffice developer had to resort to insults, rather than the truth, in our discussion.
Cyric Zndovzny at your service.
And there he goes again. More babbling with practically no point.
How is it that this troll keeps getting modded up? I'm guessing it's because he comes close to looking legitimate, but how many times can you fall for it?
So OS speed is important in terms of scalability. In this case they should have looked at the graph before buying.
Fortunately, Linux/Samba has matured and this would not be a problem today.
By all means, moderators, read the original thread CyricZ linked to.
I just fucking love how you subtly misrepresent the whole thing by implying it's a developer "publically insulting" a "long time" user, when really it was a developer simply refuting the *misinformation* posted by YOU.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
Ok, so as a USER, why would you care about MySQL? Because as a SYSTEM ADMINISTRATOR, what I really care about is stability and easy of administration. Once performance reaches "good enough", I could give a shit about improved performance. Hardware is cheap, a $5,000 1U MP system can blast down just about anything I'm going to care about.
It's fair to say then, you obviously have very modest requirements.
Unless your technology depends on Windows (I feel for you if it does) any of the *nixes out there are "good enough" to do just about anything up to the very high end. (Linux/BSD/Solaris/AIX/OSX/etc)
Wrong (sadly).
Even at the very high end, it's unlikely the choosing the "worst" OS will cost more than switching to the "best" OS!
Also wrong, there is a huge difference, though the gap varies depending on the role.
For example, Mac OS X - which I love dearly - is the slowest operating system this side of 'Slowaris' (which has that nickname for a reason), and is many times slower than Linux (on the same hardware). It's embarrassingly slow at some things. If it was a person, it would be part of a 'Care in the Community' program. It's as close to being 'autistic' as an operating system can be.
However, it has some really great features, including the quartz UI and really good multitasking for user software, which are what make the poor performance otherwise very bearable.
We have lots of FreeBSD systems here, while there are no issues with lower end systems (where there are multiple systems in a load balanced group not doing very much) they don't live up to our needs under stress, you start finding bugs with software under high load (often these are not always the fault of the OS - but exist none the less). You can also run up against kernel limitations (and find FreeBSD doesn't like really large file shares, or it buckles under certain types of load, or it behaves in a way that is not agreeable with some existing software you need to use).
This is especially with multiple CPU dual HT systems IME, even with just regular dual CPU HP DL360/DL380 systems. You can certainly coax better performance out of the FreeBSD systems but for a whole host of tasks (mail, web, dns, proxies, databases, etc) even after significant time doing manual optimisation of your software and multiple kernel recompiles (to determine optimum settings) Linux wins hands down every time IME, not least because more developer hours are spent optimising and testing those applications (and libraries) on Linux.
I can't speak for JFS, but I have FC4 and centos boxes here using XFS with the stock redhat kernels. Try again, troll.
Yes, people buy this in thousands ... Itanium ??? I wonder what the uptime of such a beast would be. 2 days ? Hell m$ os is really damm leaky if you start putting pressure in the hw. Perhaps m$ is the customer ... (that may suffice)
Why do you even take time to make a post like this, anonymous, none the less...
If you have the urge to comment so bad, just type in...
"I'm a troll and can't think past my hatred or bias, so I will disagree and rip anythng you posted apart even if I have to make stuff up to do it."
Just make that your tag line, it will save you and us a lot of time...
Sun originally used Motorola 68030 chips but was moving toward the SPARC. Furthermore, the SPARC chip was specified in terms of a RISC design by (among others) software engineers. This led to an entire instruction set being specified prior to the hardware technology being available to implement it.
Instructions not implemented in hardware would generate an illegal instruction fault, which would emulate the instruction in software and then return control. It was not until later that operations such as division could be done in silicon, or floating point operations, or the like. Optimizing for a particular processor meant not issuing instructions that were not implemented for that processor. That is why SPARCv8 instructions can run on SPARCv7 chips, they just are not as efficient.
Of interesting note is the subsequent addition of the VIS instruction set, which drastically departs from the original technology to compete with Intel's MMX technology 9now incorporated into every chip).
You EXPECT 32/64 bit "ifdefs", and some assembly in each mentioned Solaris module?
Go read the source. Go read Linux source.
Then come back and comment.
I know this is Slashdot, but PLEASE!
Just another "Cubible(sic) Joe" 2 17 3061
For the record, that language construct can almost always be re-written as "OpenBSD secured [something in the kernel] a few years ago". I'm not even a particularly big OpenBSD fan, but if someone's talking about adding entropy to something that might possibly be too predictable, then OpenBSD probably did it five releases back.
Dewey, what part of this looks like authorities should be involved?
Reiser's a sharp guy, but he doesn't have the only game in town.
Dewey, what part of this looks like authorities should be involved?
> Well done. Come back when it's released and you can run it safely on a production system. Can you
> elaborate your claims? ("Linux has SystemTap, which goes above and beyond what DTrace is
> capable of....")
Here is a short summary of what it does better. These are taken from Solaris Dynamic Tracing Guide
Dtrace understands Structs, Unions, Type and Constant Definitions, systemtap does not, to get this functionality you have to use guru-mode, in other words kiss stability and safety good bye. Of course the systemtap will develop work arounds for defined kernel routines, but if you are developing a drive or in userland there is no support.
Aggregations this is one of the most powerful features, it allows you graph data and see trends, and is smart enought to capture trends and not store huge amounts of data to do so, far more advanced than systemtraps version.
Intelligent and configurable Buffers and Buffering, dtrace trys it best to capture the data you can adjust the size of its buffers to meet your needs, but knows when its overwhelmed and drops a probe activation, but it always records the event and lets the user know about it. No such feature exists in systemtap.
Output Formatting, systemtap is just now getting this feature, of course systemtap inability to handle structs, unions, and typedef makes systemtap version servely limited.
Speculative Tracing is a feature unique to dtrace, the ability to tentatively trace data and then later decide whether to commit the data to a tracing buffer or discard it.
Options and Tunables, dtrace is configurable to the needs of the script writer, systemtap is not. dtrace also has an extensive list of probes it can use, systemtap has 3 or 4 types of probes, dtrace probes go from high level concepts that allows the programmer to deal with highlevel abstracts, or low level probes that deal with the kernel on a per funcion basis.
High Level: lockstat Provider, profile Provider, syscall Provider, vminfo Provider, sysinfo Provider, proc Provider, sched Provider, io Provider, fpuinfo Provider
Low Level: fbt Provider, sdt Provider, mib Provider, plockstat Provider, fasttrap Provider User Process Tracing Perhaps someday it will be intergrated into systemtap, but with the lacking of struct, union and typedefs, they are useless, you want to crash your kernel because you needed to see how your code was interacting with a struct?
Statically Defined Tracing for User Applications: "DTrace provides a facility for user application developers to define customized probes in application code to augment the capabilities." This is how developers can use dtrace with interpeted languages like, php, java, ruby, etc. It can also be expanded to server processes, for instance, you can create a probe that fires everytime your webserver is connected to.
Postmortem Tracing "extraction and processing of the in-kernel data of DTrace consumers. In the event of a system crash, the information that has been recorded with DTrace may provide the crucial clues to root-cause the system failure. DTrace data may be extracted and processed from the system crash dump to aid you in understanding fatal system failures." Crashdumps alone are something that linux doesn't do, an Oops is not a crashdump. A crashdump is a core file for the whole system that can be loaded into a debugger so you can look at complete system at the moment of the failure not just the kernel stack and a few variables.
To whoever was trolling/FUDing about FreeBSD's "market share" etc... here's what Netcraft was actually saying in their most recent article about this OS last year:
"[FreeBSD] has a secured a strong foothold with the hosting community and continues to grow, gaining over a million hostnames (...) since July 2003."
Full text + stats
See the e2fsck documentation. This isn't normal of course; "ext" means "extended". That is, it allows filesystems larger than the 64 MB of the original Minix filesystem.
Erm, I was actually challenging the guy who said that Systemtap was better to actually prove that. I am a Dtrace guy. Well, you pre-empted pretty much anything he/she might have said in response :-)