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?
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.
You must be joking because NT is *far* more scalable than FreeBSD.
And I'm no NT or Microsoft lover.
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.
You are. Solaris has a microkernel. Two peice static core and everything else is dynamically loaded. IMHO a far superior model to using modprobe.
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.
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
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.
"A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
They wanted to test a real OS, one that can scale to more than 2 processors.
Wow, a troll on slashdot, how novel. And an intelligent one as well, again how novel... *gag
Considering NT was scaling multi-processors before Linux even existed, this is a bit of a rich statement. (Especially since Linux didn't even consider SMP until 1996, when it was a mature feature of NT by then.)
Considering there is 128-way SMP version of Windows (running on NT) available, I would assume NT knows how to handle more than 2 processors, just a guess though.
Also considering the desktop versions of WindowsXP support 2 processors standard - and NT has for years and years, I might suggest that it even has an edge on some OSes that SMP is just becoming realistic. (XP does Dual Processors with HT, effectively managing 4 virtual CPUs and this is the desktop edition for the average Joe.)
Now should we talk about how it hasn't been until later versions 2.4 of Linux that in an SMP world, process affinity even become stable. (According to Intel, AMD and other people trying to create real world Linux SMP solutions.)
Or we could talk about hotplug of memory and processors with Linux - which is still not supported as it is with NT and Solaris. (And Linux you even get the fun of reconfiguring if you want to flip processors in downtime even.)
Call NT a Toy OS all you want, if you actually knew a little about the NT architecture and not just the 'windows buzz', that RUNS ON NT, then you probably wouldn't be laughed at so easily.
*Cheers.
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
> 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.
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
As noted in other reply, the reason for Solaris' small set of supported platforms is not primarily technical.
However, your point does illustrate that "the lack of abstraction" in Linux isn't that much of an issue in portablity. Moreover, I think the paragraph exaggerates the whole issue. First, I guess all mentioned solaris modules *are* to some extent platform specific (eg. some #ifdef to handle 32/64 bit ints on x86/UtraSparc code are inevitable; and I'd expect to find some assembly in most of the modules anyway). Second, Linux has some logic separated in clear modules, even though they are part of a "monolithic" kernel (eg. swapfs can be used as kernel module; embedded Linux kernels may not provide paging or vm at all.)
It comes down to fundamental issues on OS design. The article presents the clean & layered design as a portability advantage versus the quick & dirty design as a speed advantage. It's just a basic view that's been teached for years.
But wrt. portability in this case it turns out to be not that much of an issue in practice. I would not be surprised either if in practice Solaris turns out to be competitive in latency too, even though the books teach differently...
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!
Considering there is 128-way SMP version of Windows (running on NT) available
I might be wrong, but AFAIR, the largest SMP configuration supported by NT is 32 CPUs (or, probably, 16 Hyperthreading-CPUs) because of a constraint compiled into the kernel (Windows "Datacenter Server" Edition).
Anyway, even if you could run NT on some 128 CPUs, it would not scale well. If you actually knew a little about the NT implementation and not just the "microsoft propaganda", you'd possibly figure out, that a lot of (theoretically independent) code portions in the NT kernel synchronize on only one mutex-like synchronization lock (CRITICAL_SECTION) that is shared between these code portions
Example:
If you've got 50 independent data structures, you could use 50 mutex locks (one for each data structure), to protect it form becoming corrupted due to simultaneous modification by multiple threads. The NT design in this example would be to use only 5 CRITICAL_SECTION locks for the 50 independent data structures (one for every 10 data structures), so one thread modifying a data structure will potentially lock out 9 other threads who could be modifying 9 other data structures.
The lack of fine grained synchronization on NT makes it scale pretty bad, especially compared to Solaris (which scales so well probably mainly because of very fine grained and sophisticated synchronization, for example by using RW-locks instead of mutex-like CRITICAL_SECTIONs in situations where this is possible).
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.
Even if it is a partial list, XFS and JFS are two of the major Linux filesystems. It'd be like leaving out FAT32 support out of a list of filesystems that Windows supports. They're just too major to be left out.
Cyric Zndovzny at your service.
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.
Aksherly WindozeXP Desktop only supports max. two 'processors', virtual or not. You gotta get yersel' WindozeXP Pro (woot!) if you want sheer processor indulgence of 4.
## NB: Comment here
Apparently Red Hat doesn't think so. If you talk to them then the only journaling filesystem for Linux is the awful ext3... unless you want to recompile your own kernel and void your support of course.
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.
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...
Considering NT was scaling multi-processors before Linux even existed, this is a bit of a rich statement. (Especially since Linux didn't even consider SMP until 1996, when it was a mature feature of NT by then.)
... oh you can't, without destroying your point.
:
I find it rather rich that trolls like you have the guts to call others trolls, using rhetoric to prove your point and hoping nobody will notice.
Linux 2.0 came in June 1996 with SMP support. So if SMP was not considered in Linux until 1996, you are basically saying that in less than 6 months, SMP was implemented in Linux better than in NT, where you say it was a mature feature ?!!!
I would call that a feat.And I wonder how you can call SMP a mature feature in NT, when it was not scaling better than in Linux, which was implemented in less than 6 months, like you implied.
Considering there is 128-way SMP version of Windows (running on NT) available, I would assume NT knows how to handle more than 2 processors, just a guess though.
I never heard of any 128-way SMP version of Windows. I heard of a custom secret implementation that supposedly does that, that's all. But no version of Windows commercially sold actually does that. And SMP versions of Windows scales very poorly.
Also considering the desktop versions of WindowsXP support 2 processors standard
Against that's false. Home edition does not support 2 processors standard (HT is not SMP nor 2 processors support), Pro edition does. Stop lying
and NT has for years and years, I might suggest that it even has an edge on some OSes that SMP is just becoming realistic. (XP does Dual Processors with HT, effectively managing 4 virtual CPUs and this is the desktop edition for the average Joe.)
Continuing your lies huh ? HT is not SMP, stop your nonsense. SMP was realistic in Linux way before NT, despite SMP being implemented in NT first : that speaks volumes for NT OS, and tend to prove GP point. Again, WinXP Pro support your 4 virtual CPUs, not Home. The distinction is important, if you want to make Linux comparison, because standard desktop editions of Linux distros come with SMP support. For Windows, standard desktop edition is XP Home, which has no such support. It could, but it doesn't.
Now should we talk about how it hasn't been until later versions 2.4 of Linux that in an SMP world, process affinity even become stable. (According to Intel, AMD and other people trying to create real world Linux SMP solutions.)
Still lying huh ? Process affinity wasn't becoming stable at end of Linux 2.4, it was just not implemented before. And it ended up implemented pretty fast. But I know why you added the word 'stable' in your rant : rhetoric implying it was there but not stable before.
Anyway, despite not having process affinity, Linux kernel was running circles around NT kernel, so you should keep this subject hidden.
Or we could talk about hotplug of memory and processors with Linux - which is still not supported as it is with NT and Solaris. (And Linux you even get the fun of reconfiguring if you want to flip processors in downtime even.)
Well, you got me there. I did not even know that there was this type of hardware supported in x86 architecture. You are not credible though, because these kind of hotplug are only in limited set of configurations, not available to most Linux programmers, that's why, if they exist, they are still not implemented. There are little numbre of devs that can afford a E25K you know ? But you chose a good example, forgetting the load of other features that Linux kernel has, that makes NT kernel a toy OS. Stability is enough to kill any of your arguments though. You will give me crap about NT running for months (with 1 service) and you having seen Linux crash, the difference is that
Stability in Linux is the norm, in NT it's the exception.
I mean that a Linux crash is news, while a NT running for years is news too.
Call NT a Toy OS all you w
You only need to think a little more to find the answer to your question - and that is before OpenSolaris, Sun was the sole maintainer so any arch port decisions were done from a purely business-related standpoint. Sun as a company had no interest in seeing Solaris running on DEC Alpha hardware or a HP PA-RISC machine.
... you need to think of the whole picture.
Now that there is OpenSolaris, there's already a project to port it to PPC (bit of history: there was a version of Solaris 2.4 (circa 1994) that Sun made and it ran on PPC 604 CPUs, rumor has that it was one-off for a "special customer")
So don't just knee-jerk and say Well Linuxth runths on 35 plathforms so Solaris must be hardth to portht
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?
I'm referring to Red Hat Enterprise Linux not Fedora. As I said, Red Hat seems to imply that ReiserFS/JFS/XFS isn't "Enterprise" quality enough for their RHEL product line. Not trolling, just stating the facts. Why would I lie about something so easy to check? Just go install RHEL and you'll see there are no options for advanced journaling filesystems beyond ext3.
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?
Indeed. That's why RedHat is a distribution to be avoided. I don't trust their support to be worthwhile when they press ext3 as an enterprise-grade filesystem. I'll stick with distributions such as Debian, which do offer support for the filesystems which are used for intensive tasks.
Cyric Zndovzny at your service.
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
According to the Windows server 2003 enviroment training manual for the MCSE. Datacentre edition, is OEM and supports 32 way on 32 bit systems 64GB max memory, 64 way on 64 bit with 512GB ram and there is also a special configuration of 2 x 64 way partitions to allow 128 way. So that's the facts from the horses mouth.
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 :-)