Flutterby™! : Solaris vs Linux 2001-11-13 18:18:08+00

Solaris vs Linux

2001-11-13 18:18:08+00 by Dan Lyke 8 comments

Part of my current work is going to be deployed on Solaris Intel. We've been doing development on Linux. Obviously every OS has its own quirks, but first impressions are that the I/O subsystem in Solaris is roughly half the speed of Linux. It's no wonder that Microsoft sees Linux as "the" threat to Windows.

The HAL for Solaris intel isn't the greatest. In Solaris x86's favor, it's rediculously easy to port from Solaris sparc to x86. A threaded webserver (embedded scripting, some insane modules) I maintained in a previous life literally was just a recompile for x86 (which was very popular in Japan at the time for some reason)

We bought some Intel boxes running linux from a Big Systems Vendor not so long ago, with their in-house RAID controller. RAID 0 performance with three drives individually rated at something like 40 mpbs was a big 40 mbps. Went to software RAID, and got 80 mbps on the same config, but that's an 80 mbps limited by CPU.

Moral, I think: the tradeoff is predictability vs. performance. I don't trust random linux configs to perform as well as they should; I trust Solaris x86 to work properly with the hardware Sun's certified. What one chooses depends on how much time one has to test, etc, I think.

Mike Kite (mkite@smallternative.com) has done more with Solaris on Intel than anyone I know. His general impression is that it is slow and, compared to Linux, there isn't much hardware available.

At the same time, Mike H. at HTS has been running Red Hat Linux on a Sparc for a production server for quite some time. Why the heck are you bothering with Solaris on Intel? Is there actually something on Solaris that isn't supported under Linux?

Some companies will want Solaris on Intel. In passing, istr reading somewhere that Sun is going to abandon Solaris on Intel altogether. Don't have an authoritative source for that though.

Yeah, threads aren't processes, but they still crash the hell out of some of the profiling tools and make the debuggers hard to use, aaaand, I'm not sure that the large file support really is any better, just "officially supported" for one of the packages we're using. But this project is one string of "that's not the way I would've done it"s, so one more weirdness is just one more weirdness.

Yeah, Sun has a relatively short Hardware Compatability List. Definitely not as much hardware available, but again, the tradeoff is that you know the hardware is gonna work right.

As of a couple of years ago, network performance on Solaris x86 was much better. Probably not true anymore, assuming you don't run into network driver problems on the linux side.

If you were to run this on a big Sun/Sparc box, I'd say you want Slowlaris as the hardware support for the special hardware is worth it. For the $$ though, you can buy a LOT of Intel/AMD hardware and RAM and run Linux or BSD. better. I am sure you'll have this code compiling and running on both well, just in case.

<quote>I'm not sure that the large file support really is any better, just "officially supported" for one of the packages we're using. </quote>

That answers that question. The big software vendors are a little slow at 'supporting' new versions of Linux. Last I heard, Sybase still isn't supporting the 2.4 kernel AT ALL, even for ASE 12.5. This means no real bigmem support or large file support - and for enterprise RDBMS this is a major issue. Of course, I was running Sybase ASE 11.0.3.3 (the free, unsupported version) on a box with a 2.4 kernel and 4GB of RAM. I never got to try large files though.