Solaris vs Linux Continues

raffe writes "Solaris Kernel Developer Eric Schrock is bloging more about the Solaris vs. Linux issue and linux kernel moneky Greg is answering on his blog. Eric's first part is is also still up and Greg's answer " Another reader also submitted reviews of the Linux desktop vs. Solaris 9. User reviews are welcome; please note that ITMJ is part of OSTG like Slashdot.

Not much longer

Solaris vs Linux Continues:
http://finance.yahoo.com/q/bc?s=SUNW&t =5y

Re:Not much longer

It's up 45% against 2 years ago, so it looks from the stock that Sun didn't quite die a few years ago and is recovering now.

Solaris 9?

Why are we not seeing Linux vs. Solaris X?

Linux versus X

Just to cover various "Linux versus X" topics, here are some links, obtained by Googling, without RTFA:

• Linux Versus NT [wired.com]
• Linux versus FreeBSD [prohosting.com]
• Linux versus TwinView Nvidia GForce4 MX 4000 [alufis35.uv.es] (ok, it's a bizarre one, but we are being thorough :)
• Linux versus MacOS X Server [prohosting.com]
• Linux Versus On Time RTOS-32 for Real-Time Embedded Systems [on-time.com]

And, most importantly: Linux Versus Linux [currents.net]. (No you can't actually read it..)

Ok, this was the first page.. I got bored copy'n'pasting afterward.

Re:Solaris 9?

Why is this insightful? Solaris 10 isn't out yet so there is no comparison between it and Linux.

Re:Solaris 9?

Actually, after reading the various posts, I would say that a version comparrison isn't worthwhile at all and as the Sun developer mentioned, Linux and Solaris have different philosophies and approaches. Where I dont agree with him is that they have different markets entirely.

As an example, he talks about swapping hardrives and CPU boards in failure events. From Suns perspective of selling an E10K for $1mil to a customer to solve a database problem (as an example), this is a very neccessary feature. From a customers perspective, however, I can solve this problem with either an E10K or a Linux cluster. In the linux cluster I wouldn't care about swapping out a CPU while the machine was running as I would swap out the machine and the _system_ would still be running. Google is solving a traditional big-iron problem very differently then the way Sun would solve it for them.

I disagree with the statement that since Sun solves problem X with solution Y and Linux uses solution Z that they are competing in different markets. Truly there are things that Sun can do that Linux isn't well suited for and vice versa, however, the majority of corporations out there do not fall in either of those two areas. Where Sun has an advantage is not in its technology to solve standard corporate problem X but in its unified marketing, training, support, and existing market base. Those are assets but they are not technical reasons why Solaris is better then Linux at solving the technical problems of a business.

Kernel Recompile

If linux can figure out a way to be built with NO Kernel Recompiling EVER, and have the kernel update as easy as swapping out 1 file, then linux will dominate the market for good.

Re:Kernel Recompile

I really don't think kernel recompiling is the biggest thing keeping Linux from dominating any market. Ease of use is a big thing. Another is simply the myth that OSS is unsupported and/or unreliable. You can point to a thousand studies showing Linux is as good as (or better) than alternatives, but that won't change some peoples minds.

Re:Kernel Recompile

i've used linux for exclusively for over 7 years at home and I've never recompiled my kernel.

properly packaged distros usually do not require a kernel compile.

Re:Kernel Recompile

You know, when I first encountered Linux back in 1997 (IIRC) I managed to successfully build/install my own kernel within an hour of first booting the CD. And I had no UNIX background back then. It's the _easier_ (and well documented) part of finding your way through the system. Setting up Samba, for example, IMHO is more complicated.

Re:Kernel Recompile

The actual compilation step is no big deal; it doesn't actually require any user interaction, and it's reasonably quick. Chances are that you'll spend longer downloading than compiling. The hard parts are configuring and installing the new kernel. Installing is a bit tricky because you want to be able to switch back if the new one doesn't work. Configuring is tricky because there isn't a non-expert tool for it. There really ought to be a configuration tool which would start with a distro-specific configuration, check the devices you have installed, ask you to plug in each USB device you use in turn, check the filesystems in your fstab and detected on your devices, and generate a configuration that supports everything.

All of this is easier in 2.6 than in 2.4 and before, because the kernel developers decided that they really wanted the build process to be efficient and accurate (which they care more about than people who don't do it constantly) and they wanted the configuration system to be consistant and well-specified.

Re:Kernel Recompile

I've not had to recompile a kernel for my desktop Linux systems in a long time - the one that comes with the distro is fine, and gets updated by the distro's tools just fine too.

The only kernel I have to recompile is the rather specialist one for one of my servers which runs a heap of virtual machines. That is expected on an experimental system. If you couldn't recompile the kernel it wouldn't be much good as an experimental system.

I've not had to compile a kernel for a 'production' system in years.

as bad as freddy vs jason

Why do people feel compelled to do these things?

Two excellent tools - hammer, screwdriver.
Both can be used to install fasteners. (nail/screw)
Each tool has its place. And sometimes you can use one tool and its parts in place of the other with no adverse results.

It doesnt make them better than each other.
Just different.

Re:as bad as freddy vs jason

Agreed.

To summarize this article:

So Solaris is designed around high availability, easy problem diagnosis, and fault recovery. In exchange it sacrifices speed and kernel size.

Linux is built to be lean and fast, and sacrifices some high availability and problem diagnosis features to reach that goal. There are five gazillion patches if you want to make Linux something like Solaris, albeit not as integrated.

Soooo.... what is the problem here? The two systems attempt two different goals. That doesn't make them better or worse, it only makes them different. Let the consumers decide what it is they want from a system.

Re:as bad as freddy vs jason

The problem is that people don't like Sun acting like it's playing nice when they think It'll try to stab linux in the back later.

Granted both are good systems, but it's the "Sun's going to turn into SCO" fear that this is about I think.

Re:as bad as freddy vs jason

My problem is that people always assume that's what Sun is going to do when they have ZERO history of pulling that sort of crap. In fact, things get very frustrating because Slashdotters first say "We want company XYZ to support Linux!" then bitch, "Did you see how company XYZ is making money off of Linux?! Evil! Death to them!"

The only loophole in this screwed up logic is if Slashdotters feel that someone is playing defender for them in their favorite spectator sport: court proceedings.

"Wow, IBM is defending themselves against a baseless lawsuit! They're protecting Linux and all that is good, true, and just!"

Whatever.

Re:as bad as freddy vs jason

My problem is that people always assume that's what Sun is going to do when they have ZERO history of pulling that sort of crap.

I think some people would argue that Sun's recent relicensing of Unix from SCO *COULD* be viewed as supporting this type of crap. I would grant that the jury is still out, but their actions during the SCO affair *DO* justify looking at them with a skeptical, but open, mind.

Mix that with Sun's "on again, off again" love/hate relationship with Linux, and its easy to question their motives. Not enough to draw a definitive opinion perhaps, but enough to ask questions. Their previous actions with OSS in general also raises more questions than answers.

They have done some very cool things, like Open Office, but before I start praising or cursing them, I need more information. I don't fully trust them, and I think many people feel the exact same way, sleeping with one ear to the ground, just in case.

Re:as bad as freddy vs jason

You're missing a crucial point in your summary.

A lot of the argument comes down to "Sun hardware is more reliable and has really cool reliabilty features that PC hardware doesn't."

Nobody's going to argue with that.

The other big contender for bullet proof software, (IBM's big iron) runs Linux inside a VM. The VM has the neato bullet-proof stuff, so IBM didn't need to add it to Linux.

bryan

Re:as bad as freddy vs jason

Actually, he was arguing the software in his blog. i.e. Kernel debugging tools, software fault recovery features, maintenance logging, etc.

Not that Sun hardware isn't part of why the machines are usually stable. I can only wish that PC hardware was designed so well. The ability for the hardware and software to specifically complement each other is something that the consumer market has never known in anything other than game consoles and (to a limited degree) Macs. Most consumer hardware consists of off-the-shelf components which make very few special allowances for the software. Thus systems that are part of the Sun hardware design must be emulated in software.

With computer components being as cheap as they are, this could change. All that's needed is a decent replacement to the PC BIOS infrastructure. Something like OpenFirmware would significantly improve the ability for the software to interface with the hardware.

Re:as bad as freddy vs jason

I think part of it is also because Linux runs on off the shelf hardware which is by design, not as reliable as Sun hardware. A PC will never be as reliable as a Sparc server, because the average user doesn't want to pay three to four times more for the hardware. Even a really good PC.

Google runs thousands of off the shelf servers in a way that makes failure a non issue, by having so damn many PCs that you can't tell if a few hundred fail. Its a different type of redundancy that is more cost effective in that particular application.

OpenFirmware may help in some ways, but it will not automatically allow you to hotswap memory, hard drives and even CPUs the way Sun servers can. These features will probably NEVER be included on any x86 type box because if you need those features, then x86 is the wrong architecture for the job. Instead, multiple PPC or Sparc would be the right tool.

I read the article and found nothing that I really didn't already know. Different tools, different jobs. I will continue to use Linux for my servers, but if we ever got to a point where we needed better than 99% uptime and availability then I would be looking at Sun or more likely, Big Iron. Interesting, probably will start a flamewar, but still obvious information. Even the comments on GPL were right on.

Cameras

I'd like to hear from people what their experience is with camera and video drivers for Solaris.

Anybody else tried Solaris Express 10

since last week, because I doubt much has changed since the last Solaris story.

editors asleep at wheel...

raffe writes "Solaris Kernel Developer Eric Schrock is bloging more about the Solaris vs. Linux issue and linux kernel moneky Greg is answering on his blog. Eric's first part is is also still up and Greg's answer " Another reader also submitted reviews of the Linux desktop vs. Solaris 9. User reviews are welcome; please note that ITMJ is part of OSTG like Slashdot.

New words of the day:

moneky
bloging

Moneky bloging!

Re:editors asleep at wheel...

Well, now who is so bold to register "Moneky Bloging" as a Slashdot nick?

Re:editors asleep at wheel...

Whew. Barely made it past that stoopid "type this work exactly as it appears" thing. Scary.

Wait a second. I must be new here.

I thought we had gotten over this already

Solaris on x86 is a joke and nobody would use it unless they have a very special need. So, on x86 (and opteron) Linux and BSD are the way to go. Now, we all know that Solaris scales very well and you'd be crazy if you replaced Solaris with Linux on your shiny new E15k. And, really, that's it, run Solaris on your Sun-branded big iron. If you buy from SGI and IBM you might be running Linux on high end hardware. I don't see why people waste time discussing this. The $25,000 RISC workstation is dead, even more so since the AMD64 was announced, get over it.

Turbo Smorgreff [www.des.no]

Re:I thought we had gotten over this already

The $25,000 RISC workstation is dead

But the RISC enterprise server is not. As long as you have those, it makes sense to have $3000 RISC workstations for the economies of single-vendor support. Especially when those workstations have twice the quality of a half priced Dell or HP workstation.

Showdown: Solaris vs. Linux

What do we all think of this? "Sun's primary focus continues to be on Unix -- the Unix product portfolio," says IDC research director Al Gillen. But that may be a risky strategy. "As Linux grows, if Sun's not riding that wave fully, they leave themselves open to losing part of the market." http://www.newsfactor.com/perl/story/21637.html

Wow...

It's tough for me to believe that people can argue on the internet without it turning into a flame war. Apparently, according to this article, it can happen.

Sun, Needs To Get A Clue

Sun needs to seriously stop trying to piss people off and simply be a company. The hating Microsoft thing was fun and quite funny. This new Anti-linux thing is just dumb. Make your money off your freaking Hardware, if AMD, IBM and Intel are beating your procs, USE their's I'm sure they'd sell to you.

Re:Sun, Needs To Get A Clue

Sun is not anti-Linux. Sun sells Linux too. They claim that Solaris is better and cheper than Red Hat. You can custom make a Linux distro that is better than Red Hat and approaches Solaris. Sun does not address that. I'd say it's good competition. Linux has a lot going for it. Red Hat though has to learn to live with competition and behave more maturely. They were eating the Sun accounts quietly but when Sun turned around ready to compete, Red Hat started behaving like a teenage winer.

Two Points for Debate

* "Reliability is more than just "we're more stable than Windows." - anybody else remember the eCache problems? At a former employer, we applied every patch and none of them fixed the issue. The machines were still spontaneously rebooting when I left six months ago. Sun's response was "upgrade to new hardware at full price."

* "we need to be able to solve the problem in as little time as possible with the lowest cost to the customer and Sun." - a co-worker spent a month corresponding with Sun to get them to admit there's a bug in SunOne AppServer (it compiles JSP pages even if they existed on the server in jar files).

Again, it took him a month to enter a bug into the system. They're not going to fix it, but they've admitted it's a bug.

Re:Two Points for Debate

I think many of these cases happen because people are very bad at driving support contracts. I remember the ecache issues too, and in fact we had machines break because of this. I rang them up and told tem that they were going to replace the relevant bits, because it was clearly a HW issue, and no, we weren't about to install some workaround thank you. The main problem was working out whether we wanted the engineer overnight or next morning. OK, this was on a gold contract, but the only difference is response time: if the machine has a HW issue *tell them to replace it* don't piss around with workarounds. If they argue (they won't, nowadays, but they used to 10-15 years ago) point out how much your paying them and that you might just stop and/or mail someone senior (they do read their mail, even very senior people).

I suppose it may be that you didn't *have* a support contract. Well, sorry, I have about the same sympathy for you as I would if your house burnt down and you hadn't bothered insuring it.

Good Eric

I like Eric's blog. It's probably the first Sun person's blog I've read that isn't filled with debate-class drivel. He actually lays down the facts in a technical, but concise manner which significantly eases getting his point across. Many of the other Sun-sters should take note.

Only 1 Concern in Greg's Solid Reply

Greg's rebuttal to Eric Shrock is airtight and rock solid except for the following statement.

Tell us why we really need to add this new feature to the kernel, and ensure us that you will stick around to maintain it over time.

There really is no way to "ensure" the support of the developer. She has not signed a legally binding contract and could jump ship to the evil empire: Micro$oft.

Therein lies the only potential risk with open source software without the backing of a stable commercial company. The software relies on the goodwill of the developers. How do you ensure "goodwill"?

Therein also lies the reason for Linux exploding in popularity after IBM publically backed it with $1 billion. If any developer were to jump ship and abandon a Linux feature that she developed, allowing it to flounder like a beached whale, IBM would step into the picture and "own" the feature. Under no circumstances would IBM allow its own customers to suffer anything "worse" than 6 sigma reliability.

Text of Greg KH's post (in case of /.'ing)

I was glad to see that Eric took the time to address my previous rebuttal to his previous comments. I welcome good technical discussions like this, in the open, without rude flames by anyone. It's fun, and lots of people get to understand things a bit better about the topic

That being said, I'd first like to address his closing comment, which was regarding my comment about Linux not going anywhere:

For some reason, all Linux advocates have an "us or them" philosophy. In the end, we have exactly what I said at the beginning of my first post. Solaris and Linux have different goals and different philosophies. Solaris is better at many things. Linux is better at many things.

I agree completely. I wasn't trying to put up any "us vs. them" type attitude, I was merely trying to explain in my message the reasons why the Linux kernel has or does not have those different features that Eric was discussing. My comment at the end was a bit glib, I agree, I was merely trying to state that Linux isn't going anywhere, and will welcome all Sun users and developers if they decide that Linux will work for them.

Ok, on to the technical stuff:

First off, thanks for giving specifics about your points of reliability, serviceability, observability, and resource management. Let's address these points.

• Reliability - Of course reliability is more than "better than Windows." Geesh, what a low bar to shoot for these days. Linux had better be able to handle hardware failures where ever possible, when ever it can be detected. Ah, that last part is the biggest issue. Linux most often runs on hardware where such errors can not be detected, as we run on a zillion different platforms (although not as many as NetBSD). For systems that we can detect these kinds of errors, we do (like PCI error reporting on the PPC64 platforms for example.) The hardware that Solaris usually runs on also has that kind of error reporting capabilities, and so the OS takes advantage of it. So Linux and Solaris are pretty equal here. As for the claims that the ZFS people are stating, I think that Linux filesystems like Lustre and SSD do pretty much the same thing (automatic error correction for large collection of disks all without the application needing to fix it up.)
• Serviceability - Sure, things go wrong all the time. That's why enterprise distros add the crash dump, kernel debuggers, and dprobes code to their kernels in order to be able to help service their customers. Nothing different from Solaris there (although you mentioning the ability to have a firmware dump of hardware errors is pretty cool, but again, that's a hardware feature, not an OS one.)
• Observability - DTrace does sound like the all-singing, all-dancing solution to everything that a kernel could possibly report to a user. And if so, I commend you all for creating such a wonderful tool. As for Linux, if you want much the same functionality, use the LTT code, or the dprobes code. Again, many enterprise related Linux distros ship their kernels with these features added to them, as their customers ask for it.
• Resource Management - That sounds pretty much exactly what the CKRM project does for the Linux kernel. Again, enterprise distros ship it, so their customers can have it. And this feature is getting fixed up to be acceptable for the mainline kernel, and will probably get merged into it within a year or so (but again, if you want that option, it's available to you.)

As for the comment about Solaris having these features "more polished" than Linux's, I will not disagree. But they are getting better over time, as companies realize they want these features in Linux, and address any shortcomings that these features may have.

Binary compatibility. You state:

We have customers paying tens of millions of dollars precisely because we claim backwards compatibility.

You have customers paying that much money f

Question for anyone...

Can anyone cite a real life example where Solaris was used in place of linux on a new project for a valid reason? I'm sure such reasons exist.. but I can no longer think of one.

Note: Situations where the choice was made to remain on solaris rather than linux, because you had an E10k or something, I don't consider valid for this question... staying with what you already have and know is a little different.

So.. anyone got an example of some wonderful solaris feature than linux doesn't have?

Re:Question for anyone...

Can anyone cite a real life example where Solaris was used in place of linux on a new project for a valid reason?

Here's one [sartryck.idg.se].

The reasons? Linux couldn't handle emergencies, and wasn't always available.

possible answer - reliability, stability

At work we have a compute farm that includes both Solaris and Linux. How many of each we run is based on the software requiements to do our work, of course.

Overall, Linux does a great job. But we experience odd lockups we can't easily track down. The only alternatives seem to be pulling software developers from their real work to debug the kernel, or paying fat licensing fees to one of the Enterprise class Linux vendors. At that point, Linux is suddenly in the same arena as Sun, WRT price. Of course, there's always the option of simply replacing the hardware; it is fairly cheap compare to Sun hardware. Now there's a green thought. 8^/

And for the monkey's edification, some of us do care about library compatibility. I've certainly run into issues.

And for the record, I haven't been able to get my sound card at home to work on Linux ever since I moved into the 2.4 kernel space.

Linux is a good thing. But so is Solaris. And "Use the source, Luke" is the wrong answer for the average end user-- even the average technical end user. It reminds me of why I picked Linux over BSD almost a decade ago. ``Just write your own damned driver and quit whining.''

If I start hearing much more of that, I'll start looking for an alternative to Linux in a heartbeat-- and I'm referring to the compute farm at work as well as this system at home.

section

Why is this sectioned on Slashdot in 'Linux' and not 'Sun'?

As Danny Devito said in Other People's Money

"They're already dead, they're just not broke yet..."

Sun is already dead, or at least their current product line is.

They'll still be able to sell extreme high end servers and mainframes to a relative handful of corporate and government clients, but everything below this level is already all but lost to them.

They're caught in quite a predicament. Their architecture is getting its clock cleaned by competitors and their OS is spartan and obtuse compared to Linux. They don't have an advantage anywhere that triple 9 availability isn't crucial, assuming of course that their stuff really is stable, robust and ages well. I can't say that it does. It may be stable, but lets see you get Veritas 3.4 running on Solaris 8 with ALL of the latest recommended patches. You can't because two of the patches BREAK Veritas and there is no fix other than backing out the patches, which leaves the system vulnerable. Sun's solution? Spend $15 to $25 thousand dollars to upgrade to the latest version of Veritas. That is just for software mind you. My solution? Replace the damned thing with a Linux server running BRU-Pro for $4 thousand that includes new hardware and software.

I work for the college of engineering at Arizona State University where I support Unix systems for the computer science department. The sun systems here are withering on the vine. Every time one is in need of replacement a Linux system is bought to take its place. I expect that within 5 or 6 years sun systems will be all but gone at ASU. Our central IT organization is going through a similar migration.

This isn't because of some edict from on high either. This is happening because every single time, Linux on commodity hardware makes more sense from multiple angles than Solaris on proprietary and extremely expensive hardware. This will not change, if anything it is going to become more and more true as time goes by.

This is why Sun is doomed if they don't find a new product to sell. Stick a fork in them, they're done.

Why

Because the Sun guy actually makes coherent and valid points whereas this guy says a load of what is essentially meaningless cheer-leading? I think you'll find a lot of businesses like to have a reasonable degree of reliability in their servers. Telling people to get stuffed when ReiserFS decides to randomly shit the bed and completely annihilate your business data won't impress many people (it's done this several times for me on MAINLINE KERNELS, there is absolutely NO excuse for that. Don't tell me to send in dumps and patches, mainline means "this does not NEED debugging and is safe to use", period). I'm not talking running a major financial institution or a nuclear power plant here, I'm talking about being reasonably sure that today's data will still be here tomorrow.

That's just filesystems. Once upon a time Linux was really great because it was amazingly robust, small, fast and elegant. Today we have frequent kernel panics and X server flakiness, gigantic frameworks for desktop environments and gigabyte sized base installs. I suppose I can forgive flaky and sometimes limited support for exotic hardware because PCs are really complicated beasts these days, and a lot of hardware manufacturers are incredibly pig headed about these things but it would really be nice to have my two year old laptop actually wake up from ACPI sleep. No it's not a DSDT error. No I do not want to use Software Suspend because it is a hack. Nevermind the fact that it takes 5 minutes (as in around 300 seconds) to suspend on a 1GB swap with 256MB of RAM and several minutes to wake up again.

Linux sucks, get over it. Yes I use it, that's because everything else sucks more.

Re:Why

Today we have frequent kernel panics

Who's this "we," white man? I can count on the fingers of zero hands the number of times any Linux box I've used has had a kernel panic. Maybe some kernel versions are more susceptible than others, and surely not everyone is as lucky as I am, but you paint this as some kind of common, widespread problem.

gigantic frameworks for desktop environments and gigabyte sized base installs.

Yes, please conflate the kernel with the userland programs that run on top of it, as if that has anything to do with the speed, robustness, size, or elegance of the kernel.

Does Sun love Linux or hate Linux today?

Today is Monday. Does that mean Sun loves Linux or hates Linux? I forget.

More then anything, Sun's demise has to do with the fact that Sun can't figure out what they are doing, and won't stick to their decision for more then a year.

- Is Solaris supported on Intel86 architecture or not?
- Does Sun sell Cobalt appliances or not?
- Does Sun resell Linux or not? Today, is it RedHat or Suse?
- Is Java a programming language or is it a more General Product? What does "Sun Java Desktop" have to do with Java?
- Can I redistrute the JDK with my own applications or not? Wait, just javac?
- Is Java called 'Java', 'Java Two', 'Java one-point-two-and-above' or 'Java Five-point-oh'?
- Where is Java installed today? /usr/j2se ? /usr/jre1.4.1_05b1? /usr/java? /usr/java1.3? C:\jdk1.4.1_03? C:\Program Files\jdk1.4.1_03??? C:\Program Files\Java\j2re1.4.2_04 ? (The last three all exist on my Windows box).

Reliability

Reliability - Reliability is more than just "we're more stable than Windows." We need to be reliable in the face of hardware failure and service failure.

Ah yes, reminds me of college when a fellow student brought down the department Sun box by using the "manual" (ie, paper-clip) eject button on the CD drive when it wouldn't eject his audio CD. Perhaps Sun has gotten better in the last couple years, but this is hardly reliable.

Linaris...Solix...Laris...Soinux...?

In the long term, it might not matter. Much of the tech in the *open source* version of Solaris will possibly move to Linux and visa-versa. *BSD might even benifit. The gotcha is the licence(s) Sun will choose and are they compatable with the mostly GPLed Linux kernel code.

A few links here. [thelinuxshow.com]

Audio interview here. [thelinuxshow.com]

It's typical

It's really typical how this Greg guy doesn't actually address the points that the Solaris guy makes. Let's paraphrase:

Eric: "The core Linux developers don't see the value of features X, Y and Z, so the Linux kernel won't get those features integrated to the main tree."
Greg: "Hey, Linux has X, Y and Z! You just need to get a third-party patch to the kernel!"

'Nuff said.

Solaris is superior to Linux in many ways

I have used Linux for years but I've also used Solaris. Solaris is simply more reliable and more fault tolerant hardware-wise. It's a fact and as Solaris is opened up and more people become aware of it, it will be obvious. Linux is a great OS and works wonders but it's not up to Solaris standards in many ways. Likewise, Solaris isn't as widely used as linux and doesn't support nearly as many peripherals and isn't as good on the desktop.

That said, Sun's cash cow or former cash cow was its hardware not software. Solaris was a nice OS that was icing on the cake. Now that their cash cow is gone, their emphasis will be on Solaris but there's less revenue here. I hope they go bankrupt and GPL solaris personally. :)

The rebuttal wasn't a rebuttal either. It didn't mention kgdb which allows you to debug kernels using source code.. it can also work with UML kernels. Also the rebuttal didn't address the points raised:

Reliability - Reliability is more than just "we're more stable than Windows." We need to be reliable in the face of hardware failure and service failure. If I get an uncorrectable error on a user process page, predictive self healing can re-start the service without rebooting the machine and without risking memory corruption. Fault Management Architecture can offline CPUs in reponse to hardware errors and retire pages based on the frequency of correctable errors. ZFS provides complete end-to-end checksums, capable of detecting phantom writes and firmware bugs, and automatically repair bad data without affecting the application. The service management facility can ensure that transient application failures do not result in a loss of availability.

Serviceability - When things go wrong (and trust me, they will go wrong), we need to be able to solve the problem in as little time as possible with the lowest cost to the customer and Sun. If the kernel crashes, we get a concise file that customers can send to support without having to reproduce the problem on an instrumented kernel or instruct support how to recreate my production environment. With the fault management architecture, an administrator can walk up to any Solaris machine, type a single command, and see a history of all faulty components in the system, when and how they were repaired, and the severity of the problems. All hardware failures are linked to an online knowledge base with recommended repair procedures and best practices. With ZFS, disks exhibiting questionable data integrity can automatically be removed from storage pools without interruption of normal service to prevent outright failure. Dynamic reconfiguration allows entire CPU boards can be removed from the system without rebooting.

Observability - DTrace allows real-world administrators (not kernel developers) to see exactly what is happening on their system, tracing arbitrary data from user applications and the kernel, aggregating it and coordinating with disjoint events. With kmdb, developers can examine the static state of the kernel, step through kernel functions, and modify kernel memory. Commands like trapstat provide hardware trap statistics, and CPU event counters can be used to gather hardware-assisted profiling data via libcpc.

Resource management - With Solaris resource management, users can control memory and CPU shares, IPC tunables, and a variety of other constraints on a per-process basis. Processes can be grouped into tasks to allow easy management of a class of applications. Zones allow a system to be partitioned and administrated from a central location, dividing the same physical resources amongst OS-like instances. With process rights management, users can be given individual privileges to manage privileged resources without having to have full root access.

And of course windows is but a Play Thing.

Solaris wins in big embedded applications

I'm not a developer, but I deal with different types of systems, and appreciate both Linux and Solaris for their respective strengths. In the telecom space, for instance, Solaris is well respected for building embedded applications. While AT&T invented Unix, they never meant it for critcal "five nines" real-time telephone call processing. Yet the dial tone on my desk comes from a Solaris-driven central office switch. (Not Lucent!) While the switch vendor's own code has crashed, the Solaris layer beneath takes a lickin' and keeps on tickin'.

I think the big fallacy in Linux is the driver ABI. Linus likes to change it, as a way of forcing hardware developers to have open-source drivers. Nice Stallmanesque politics, but impractical in the real world, for at least two different reasons.

1) Not all drivers can expose the source. This is often because complex devices hide proprietary details in the code. nVidia does that with its "compile in the stub" 3D drivers. Even more limiting are the wireless-card drivers, wherein regulatory approval is dependent on limiting user access to some of the chip registers which, in an open-source driver, could be used to create out-of-band or over-power emission. Life ain't all Ethernet cards nowadays. I had No Fun trying to make a PCI wireless card work with Linux, partially because of the (older) version dependency of the vendor's binary-only driver. Solaris and indeed most (not all) Microsoft OS versions have been better about that.

2) There's a lot of custom hardware out there. Sure, Linux users generally think about "computers" that are either "desktop" or "server" systems. But embedded systems are even more common. Solaris works in a lot of big ones, like aforementioned telephone switch. Some of those systems use different makers' boards; said phone switch, for instance, is made by a company that buys critical boards from other companies. Changes in the ABI would make a difficult revision process even harder. And even if you make your own peripherals, having to recompile or, gag, rewrite the drivers to meet Linux' latest idea of an ABI is, well, a serious pain in the kiester. Very unprofessional!

So while most mainstream dekstops do get better support in Linux, in part because of the better volume of applications, the Solaris approach still wins for those big systems where an hour of downtime is worth tens of thousands of dollars.

There is no issue

System managers want to observe what's going on inside their kernel about as much as they want to see what's going on inside their bowels. That stuff just has to work, and it has to work automatically and without being noticed. If people ever have to muck around with dtrace or tuning kernel parameters, there is something seriously wrong with Solaris.

As for reliability, even if (and that's a big if, given Sun's historically lousy record) the Solaris kernel actually manages to have a more reliable file system, so what? Those mechanisms still don't protect against many kinds of failures: you still need backups, hot standby servers, and other features if you want high reliability. Beyond a certain point, trying to push reliability of one part of a system is simply wasted effort or even harmful.

Overall, there is no "Solaris vs. Linux" issue. For a small number of applications, Solaris is still the best choice, and for the rest, Linux is the hands-down overall winner.

What Solaris vs Linux?

What a stupid debate. Two decent, useable operating systems, but each optimised for different situations. You could bring in al least three BSD variants, AIX, HP/UX and I don't know how many more, and it would still be a pointless argument.

But one big factor is that the Solaris OS is based on hardware that is largely controlled by Sun, which gives them a big lead, potentially, on reliability and stability. It certainly helps to avoid over-complexity in the handling of hardware issues. Linux has to run on hardware that is often badly documented, if at all. Many of the reliability features of any OS need specific hardware provisions, which are simply not there in a PC.

So it is like comparing apples and oranges, or pears and bananas, or Saddam and Dubya. Actually on that last point I may be wrong, because neither was properly elected.....

Eric is right, but...

I honestly thing Greg missed his point. Eric is talking about the motivating development philosophies of the two systems. The Solaris philosophy is reliability, serviceability, observability, etc. The Linux philosophy is scratch your itch, and keep it simple. Of course nobody in Linux is against reliability (duh!), but it wasn't designed with reliability as foundational principle. Eric captures the difference in this zinger:

Perhaps you're thinking that because some customer really wants something, we just integrate whatever junk we can come up with in a months time. If this were true, don't you think you'd see Kprobes in Solaris instead of DTrace?

The Solaris guys made tracing a core priority and built a complete system for it. Linux waited until someone came along and contributed a system that is light enough to get past some very conservative objections, and lacks many of the features of DTrace. If observability were a core value of the Linux team, the core developers would have been working on this themselves years ago. (This is not to say that Kprobes won't mature into an excellent system, especially with Solaris's lead to follow.)

The only question is whether "scratch your itch" results, in the long term, in a more reliable (observable, etc) system than "design for reliability (observability, etc)". This is sort of a reprise of the "worse is better" argument, and I think it is by no means resolved.

Hardware Support

Out of the box, Linux supports more hardware devices than any other operating system. [from the linux kernel monkey log piece]

Perhaps my varying experiences with Linux over the last decade or so have been unusual, but this just doesn't ring true to me. Does Linux really support more hardware, today, than any other OS? Is there any sort of independently verified comparison list? I guess I could compare the various hardware compatibility lists myself, but if this is unvarnished truth, I'd expect there to be something concrete to show it.

My experience has been that when I shop for hardware for my Linux boxes, I have to be somewhat careful about what I pick. On the other hand, when my dad shops for his Windows boxes, pretty much everything is guaranteed to work (provided it is physically compatible, of course -- not something that only fits in, say, a Macintosh Powerbook).

Perhaps it depends on what "out of the box" means, or what "more hardware" means.

Jon Schwartz

If we are going to post Suns blogs shouldn't we post the Red Hat exec's Blog defending [redhat.com] against Sun?

Both are great!

Each OS has it's strengths and weaknesses. I generally prefer Solaris as it seems to be less chaotic than the linuxes with regards to the complete distribution. Solaris versions are more significant in feature improvement.

Solaris also is more tighly integrated with it's hardware. Maintenance wise I feel much more confident with dealing with a crisis when using Solaris. Linux again seems chaotic in it's hardware support.

And don't forget support. Linux does have great community support, but nothing beats a Sun box with a support contract. Nothing.

Now before you mod me as flamebait, I have to give props to Linux. If your on a tight budget, and you need lean and mean, a linux distro is where it's at. For example, Gentoo 2004.2 can really smoke a Sun in a low-end bang for the buck contest. You also have the ability to change every tiny aspect of the OS if you so choose.

So there you have it. Bottom line for me is, if my reputation is on the line I'm going to choose Solaris any day (on Sun hardware). Otherwise if things aren't so critical and there's a pinch for money, Linux is king.

Self-Healing & Hotswapping || But Patch Reboot

Solaris may still be really reliable. All this Self-Healing & Hotswapping may be nice, but what me very much is making angry is this:

Nearly 50% of the needed patches need single-user mode to get installed and nearly 75% need a reconfigure reboot after applied.

I never need to reboot a Debian GNU/Linux production system that much to hold it up to date.

PS: And Solaris has to be realeased under the GNU GPL too be really cool!

Sun's problem

If you really want HA maybe you shouldn't be getting Solaris (or Linux). You should be looking at offerings from HP or IBM. e.g. OpenVMS, Tandem NonStop, mainframes etc.

Despite what Sun/Solaris fanatics say, Sun systems aren't really that much more reliable or HA than decent x86 systems.

AFAIK if a SPARC CPU dies it still kills stuff that's running on it right? Whereas if a CPU running in lockstep goes belly up, the other CPU can still manage. In fact, Fujitsu SPARC has hardware instruction retry, whereas Sun SPARC doesn't. Sun really is behind in this HA stuff.

So what kind of HA does Sun really provide? Clustering? x86 does clustering.

It was just fortunate for Sun that the people who were so used to Windows availability+reliability found Sun to be such a vast improvement. However it is unfortunate for Sun that nearly the same people are now finding Linux/*BSD on x86 a vast improvement in availability+reliability compared to Windows as well. For a lower price too.

Linux struggling out of hobbiest space; good thing

Lots of products struggle out of their original "space". Mac out of art and school space, Windows out of "cheap desktop PC" space, Sun out of "big/expensive iron" space, and Linux out of "hobbiest space". No problem with this. But it is a struggle, none the less.

its not about kernel recompiling vs not

Sun doesnt need to have its kernel recompiled all the time because it doesnt have as diverse a hardware support as linux does. YES linux could be built with support for just about anything and everything but then it would be called lin-bloatware. Solaris in my experience has performed better than linux for longer periods of time under higher load. I have seen this time and time again (in 2.2 and 2.4 kernel series). We are still running 8 Solaris servers on intel hardware and 8 linux 2.6 based systems on the same hardware. BOTH are configured identically as far as apache and used services are concerned. Generall the Solaris 9 systems are more reliable (even on x86) than the same linux boxes on 2.4. Yet to be determined for 2.6 although 2.6 does appear to outperform the solaris system at this stage (uptime yet to be determined).

So realistically solaris is still king between linux and solaris. However FreeBSD is still more of a realistic competitor to solaris.. Where is the press on that?

But in the end any *nix flavor is better than none. Long live solaris and linux both have thier benefits and both have drawbacks. Realistically there is NO PERFECT OS!!. (and as long as humans make OS's there never will be).

Anecdotal tide turning tales

First off, a short tale about Sun. I recently bought a V20z dual opteron rig from them. On two separate occasions, after logging HARDWARE support calls (faulty ram and faulty powersupply), they've phoned me within 2 days and asked why I'm running Linux on the machine, and have I considered running Solaris instead. On each occasion, I've told them that we have no interest in Solaris on x86, but they've gone on to give me a hard sell.

They may well be a company that supports Linux, but they're pretty damn schizo about it :)

The only real pro-Linux argument

Every Anti-Linux argument I have ever had (and some of them I have also started ;-)) has -- at the some point of the discussion -- always directed onto two items by the Pro-Linux part:

- Linux ist faster
- Linux is the only operating system that
will prevail

The first one is an argument, that many great people in computer science have found fundamentally broken for other types of software. The same guys, that state, that Microsoft has made a big design mistake by moving the graphics drivers from user space back into kernel space promote the exactly same design mistakes in the Linux kernel.

This is about the same argument, that people have made, that mono executes faster than .NET. The interesting thing here is, that mono does not implement the slightes security check throughout the complete runtime environment. Solaris may be slow (on = 4 CPUs), but that comes from a huge amount of checking code and locking.

L4Hurd is predicted to about 10% slower than Linux for a typical workload. I do not think, that this is an unacceptable price to pay for subsystems that do not compromise the whole kernel if they contain a buffer overflow.

The other argument is more subtle. It says two things: Linux is the best (which is surely not true _right now_) and that everything else will at some time be obsolete, when Linux has finally caught up in features and gotten better that the competition.

That's a nice one. It means "We want freedom, but we want it our way", very similar the ubiquitous call of standards. When developing the new driver interface for the 2.6 kernel series, the linux kernel developers had the choice between using two very good, already existing oo-driver interfaces (freebsd kclasses and darwin IOKit). They rather choose to implement their own version, incompatible to everything else and to improve it over time on their own. And they believe, implementing an interface badly first and improving it over time is good.

In my opinion, this way of thinking is fundamentally broken. An interface is a defintion of the way modules interact with one another. If it needs to be changed, that is always a big problem. Everybody depending on that interface will need to change his code. The argument from the Linux developers than is "We do not care to change our code and we do not care about everybody else's". In other words: "If you took trust in our interfaces you are a fool, give us your source and we will (probably, if we are in the right mood) fix it for you".

This is not distributed development and it surely it not freedom for anybody else than the "core" developers.

The problem with Linux

is that its a least common denominator OS. All of the development effort goes in to the most commonly used hardware configurations.

This is great if you are running a uni-processor desktop machine, or 2 cpu web server, but if you are doing anything that's even remotely non-trivial, like a cluster with a shared SAN. The support is primitive, to say the least. For these sorts of tasks, Solaris (and other commercial OS's) tend to be a better choice, IMHO.

The entire argument is specious

Mr. Schrock's argument can be responded to quite readily with a single quote: "Ask not what your country [operating system] can do for you but what you can do for your country [operating system]." Thanks Jack, I'll take over from here.
Mr. Schrock's confusion over Linux appears to be rooted in two points of ignorance: "What & Why is Linux" and "What's the difference between a Linux distribution and the Linux kernel".
Linux is a community operating system. Community in the sense of ownership and more importantly contribution. Complaining about Linux missing specific features is not a reflection of the operating system but a reflection of your contribution to it. If your concerns are truly important to you rally around them. That means if you can code do so but if you cannot, work to get others interested, be they other kernel developers or commercial entities. Grousing about how misguided the priorities of others is not constructive in the least and in fact may have the opposite effect, alienating those that would otherwise support your cause.
A Linux kernel 'release' is a snapshot, not truly intended for customer usage, of the current state of Linux kernel development. It is analogous to a private entity's internal development group creating milestone builds of its technology. The fact that the Linux effort is performed in public as opposed to Solaris' private development makes it no less valuable then Solaris' internal builds are for Sun. The similarities don't end there. The Linux operating system has multiple distributions. These are composed of a development snapshot of the Linux kernel plus many other packages necessary to round out what the general public considers necessary for an operating system. Solaris has only a single distribution, packaged by Sun, that contains code seeking a similar aim. Linux distributors, similar to Solaris' sole distributor, may package other code, kernel related or otherwise, to add functionality deemed critical. This is done regardless of the direction of the Linux kernel development effort and not necessarily in line with the Linux kernel contributors desires. This again reflects the public nature of Linux development and is a strong argument in favor of keeping Linux kernel and distribution development distinct.
Why could Sun not work with Linux to make its own distribution incorporating functionality of perhaps its own design? Mr. Schrock submits version tracking as the primary issue, regardless of multiple Linux distributors managing to do this with little complaint. Why even entertain this as an issue? Before complaining about tracking kernel version changes Mr. Schrock, with everyone else, should put forth the effort to work with the community before grousing about the potential negative results. Mr. Schrock's concern regarding the Linux kernel's development community's propensity for rejecting what he believes are important features is a red herring. Not only has Mr. Schrock not invested the time necessary to understand why specific Linux kernel code contributions were rejected but has also never submitted changes of his or Sun's own making to work through the process.
As Mr. Schrock's argument can be responded to quite readily with a single quote: "Ask not what your country [operating system] can do for you but what you can do for your country [operating system]." Thanks Jack, I'll take over from here.
Mr. Schrock's confusion over Linux appears to be rooted in two points of ignorance: "What & Why is Linux" and "What's the difference between a Linux distribution and the Linux kernel".
Linux is a community operating system. Community in the sense of ownership and more importantly contribution. Complaining about Linux missing specific features is not a reflection of the operating system but a reflection of your contribution to it. If your concerns are truly important to you rally around them. That means if you can code do so but if you cannot, work to get others interested, be they other ke

Linux and World domination!

Ok, I'm a Sun employee... but an open mind one.... :-)

As a "GNU/Linux vs. any other OS" (I know it wasn't the article's point, but I really like hard direct attacks, is like instinc to me) I always though that GNU/Linux could have an umbeatable advantage as for the total number of kernel programmers compared to any other OS. To put it on an example:
- Back in 1991 Linux had only 1 kernel developper and 1 user (Linus Torvalds himself).
- In 1995 Linux had 100 kernel developers and 1000 users (Ok, those are numbers invented by me).
- In 2000 Linux had 1000 kernel developers and 100000 users (once more, numbers invented by me).
- Nowadays Linux have 10000 kernel developers and 2000000 users (last time, I promise, numbers invented by me).

The idea, is to try to make a geometrical prediction of when in time Linux will have more kernel developers than the biggest comercial OS has. After that point in time, the comunity can claim to have an unbeatable advantage, since, not only new technologies will be created first on GNU/Linux, but after any other creative comercial OS invent a new technology, it will take a really short period of time to be implemented in Linux.

From that time on, Linux should have the majority of the OS market, leaving niche space to any other OS (something like QNX nowadays).

I welcome any response to this post. Mainly if you think I'm insane, or even better, if you like my idea and have the correct number of kernel developers and users for all the years I listed, so I can do a Taylor aproximation and post a possible time of Linux supremacy, Pinky and Brain style ;-)

Regards!

we don't need no stinkin' drivers

It's not that we don't know how to create a binary api with padding structures out, and offering up new functions, it's the fact that because we have the source to all of our drivers, we do not have to.

This is really circular nonsense thinking.

1. Some people can't make binary drivers because there's no "binary api" (he meant ABI?), but...
2. We don't need a "binary api," we have the source to "all our drivers"

Well duh. You have the source to "all your drivers" because the vast majority of people who would like to distribute binary drivers have given up on Linux. Congratulations on that.

Incidentally, props to the Sun guy for having the balls to make his blog open to public comment. The Linux guy seems to have his setup as read-only. Loser.

What is up with you armchair kernel hackers?

I mean seriously. We have a debate about the relative merits of Solaris and Linux, and you come out and say, "LOL no context haX0rs@!!~ OMFG linux is so wei faster than Slowaris lol!"

I mean, did you even read his blog entry? I know, I know, this is Slashdot. But come on. He isn't comparing Linux and Solaris as gaming platforms. Yeah, your FPS for Doom 3 is probably faster on Linux (LOL d00d don't you know Doom 3 doeznt run on Slowaris haha you fail it!) but what he's talking about is no downtime, ever.

He's talking about kernel debug utilities. About hardware hotswapping. About being up 24x7x365 doing 1000s of database transactions per minute. We aren't talking about your mom's basement here, with your little network, or even the nice little RAID setup you have going at work that saved your employer a pretty penny. We're talking about big iron. Speed is not the issue here; reliability is. One of the reasons Solaris is slower than Linux is because it checks everything. It is one extremely anal system, and it never ever goes down.

Now, I'm a big Linux fan (typing this on my Debian box), but no one who has seriously admined Solaris boxes can say that the two are even remotely equal on big servers. No contest indeed; Solaris kicks the shit out of Linux.

I don't think this will be the case forever. Unlike the anal blogger referenced in the writeup, I think Linux is catching up faster than Solaris is improving. While he makes good points about Linux's lack of sysadmin accessible kernel debugging tools, traceability, etc, people attempting to sell Linux to big vendors will provide those tools.

But Linux isn't ready for the big iron machines Solaris dominates yet. Don't say IBM, please. IBM runs multitudes of instances of the Linux kernel in parallel on their machines, so that if one fails, it doesn't take the whole system down. Those big iron Sun machines run one kernel, baby. Just one.

I tell you, if they open source Solaris (yeah right) we're going to be looking at some pretty amazing code. Some of the best hackers ever have hacked that thing.

Re:What is up with you armchair kernel hackers?

One of the reasons Solaris is slower than Linux is because it checks everything. It is one extremely anal system, and it never ever goes down.

No contest indeed; Solaris kicks the shit out of Linux.

I disagree. I would say that Linux and Solaris in terms of stability are about equal and both _very_ stable. Using the "latest and greatest" of both OSes is not recommended. There have been some issues with Solaris on Sun's lower end servers with IDE drives where the IDE driver was buggy and it would cause the system to freeze. I havn't had a production Linux system crash unexpectedly in over 6 years or so. And Linux does a pretty damn good job of "checking everything" as well. I've had Linux systems stay running with 1 of 2 processors frozen, and I've seen Linux carry on with about every hardware failure possible, and when Linux has found one of these hardware failures, it reports it, and keeps running as much as it can.

I tell you, if they open source Solaris (yeah right) we're going to be looking at some pretty amazing code. Some of the best hackers ever have hacked that thing.

Hmm, I guess you havn't heard [com.com] about solaris going open source.

I would say that all of the big kernel hackers are pretty damn good, beit AIX, *BSD, Solaris, or Linux. Although Linux is the baby of the bunch, they are all proven systems. I've worked with all of them. They all have plusses and minuses, and they are all pretty slick.

Re:GNU OpenSolaris

Exactly! I know they've updated to more modern command-line tools (they've actually grabbed some of the gnu ones) in 10, but Solaris userspace feels so ancient compared to modern linux. Despite what Sun and other proprietary Unix vendors may have you believe, command line tools have been evolving over the last 10 years. (I would bitch about wanting bash or zsh, but I'm pretty sure bash made it into 9.)

Re:GNU OpenSolaris

Will we see GNU / OpenSolaris? Basically all the GNOME / KDE desktop stuff of Linux runing on solaris kernel.

About 4-5 years ago. Sun has been shipping GNOME and KDE for many years now, along with many GNU and Open Source tools. In recent years, Sun has done a lot of development work (and spent a lot of money on) GNOME. GNOME has been the official desktop of Solaris since Solaris 9. The dreaded CDE is still there for legacy reasons (and compliance with certain standards).

But this is slashdot, and we shouldn't let facts get in the way of a good argument.

Re:Crash dumps a "feature" in Solaris?!

I am sorry but you must still be living in the world of "25 years ago". I do not believe for one minute that new linux kernel code is always dropped into the source tree bug free. This is a fact of life. Having good observability and tracing enables bugs to be located quickly, understood quickly and fixed first time in the shortest time. Dtrace takes this a step further by enabling dynamic tracing points in the kernel AND in a userland applications (every instruction if you want). And yes I do know what I am talking about having used these tools to find and fix bugs and remembering what it was like before having them.

Re:Binary Compatibility

Binary compatibility is a specious argument. To get it to work without breaking everything, you have to add abstraction layers for everything -- including stuff you never even though of at the time. Otherwise you will inevitably miss something and eventually, there will be no alternative except to let it break. Timestamps are a good example; the 32-bit space is running out, and the structure of a timestamp will need to be changed. And that is going to break binary compatibility big-style.

Or, you can actually use a programming language as an abstraction layer in its own right. This gives you source compatibility, which is a lot more sensible: it's what C was originally designed for in the first place. Who cares if the old binary won't run against the new kernel and libs, when it is a trivial matter just to re-compile? CPU time is cheap today; even compiling a kernel isn't a slow process anymore. Software that might have taken a week to compile twenty years ago won't take anything like that long today.

It's like, when it's raining, I walk to work in old clothes and carry my work clothes in a bag. I know I'm going to get wet anyway, and it's much easier to keep clothes dry when I'm not wearing them. Yes, it takes me some time to get dried and changed, but I can allow for that. It still works out being less effort than any way I could imagine of keeping my work clothes dry while wearing them.