On Thu, 2002-02-07 at 08:57, Brett Simpson wrote:
> Hey everyone. I'm putting togethor a comparison of Solaris-Linux. My information or opinions may not always be 100% correct so I would like to run this by everyone. While I know Redhat isn't the only Linux distribution it's the only one my management will support on our systems.
>
> Here it is.
I'm very much pro-Linux, but we have to be fair and reasonable,
otherwise we just come across as another Linux hothead trying to push
their beliefs on everyone else.
And yes, I'm ripping this to tiny little bloody pieces like a rabid dog
on a hot day, but don't take it personally.
> Solaris to Redhat Linux comparison
>
> 1: Lower Hardware costs.
> Special & higher grade hardware can be purchased at a lower cost with an Intel server. (i.e. Hardware raid, Multiple processors, more harddrive space, video encoding cards, & more memory)
This is almost certainly the biggest advantage of Linux over Solaris
unless you want to run Solaris/x86 which has now apparently been
discontinued and has nowhere near the range of hardware support as
Linux.
> 2: Some specialized software is only available on Redhat Linux while not available on Solaris.
> . (i.e. Ncpmount * Allows connections to Netware, Smbmount * Allows connections to Windows, & Wine - Windows emulation (for Winzip on Transpt))
Conversely, there are many software packages available on Solaris that
are not available on Linux. Typically higher-end vertical market and
engineering type applications, which are often the types of applications
people buy Sun hardware to run...
Most "general purpose" (i.e. stuff that's not specifically built to run
on Linux or PC hardware) "Free" software usually works just as well on
Solaris as it does on Linux. Of course, that's usually entirely
dependent on the developer(s) desire and access to sufficient resources
to make sure it works properly cross-platform.
> 3: Standard industry software is packaged & supported by Redhat that reduces the complexity, maintenance, & time for building & maintaining a server. (i.e. Bash, Openssh, Perl, Gcc, Apache...)
> For Solaris these must be downloaded from a 3rd party Sun site. Not only are they unsupported by Sun but they are typically out of date.
www.sunfreeware.com
Please explain how it's any different for RedHat to package Apache with
the distro versus downloading an Apache binary package from sunfreeware
to install on your Solaris box, other than one is already on the CD and
one has to be downloaded.
All the standard GNU tools are kept up-to-date on every supported
platform about as well as any other. GCC on Solaris should be
reasonably expected to work as well as GCC on Linux. You can download
prepackaged binaries for Solaris from the abovementioned website that
take about as long to install as an RPM under Linux.
And you have to assume the way the software packaged with RedHat is the
way you want it configured. I frequently need Apache, some database,
whatever, built with different options than the prepackaged version was
built. So in either case (Linux or Solaris) I'll build from source
anyway.
> 4: Lower 3rd party software costs.
> Other products like Cold Fusion, Pkzip, & ChiliASP cost more on Solaris. This is typical across the industry for most software on Solaris.
This is generally true, but also take into consideration the packages
that simply aren't available on Linux at any price.
> 5: Simple server recovery.
> A Linux server can be recovered quickly using cd recovery software (mkcdrec from sourceforge). This eliminates the need to do a complete reinstall of Linux and reconfigure any special software. Recovery time will vary from 30 to 60 minutes and cd images are created nightly.
> A Solaris recovery could take anywhere from several hours to several days depending on the severity of the problem & the complexity of the server. If our main web server was hacked then a complete rebuild would be necessary. Backups couldn't be considered reliable. Ghost cannot be used on Sun hardware.
The Solaris install CD can easily be used as a recovery CD and I have
done it on several occasions. Sure you need someone familiar with
Solaris recovery procedures to do it, but the same can be said of
Linux.
Recovery time in either case is entirely dependent on the level of
recovery and should be roughly similar in both cases. Dependent on your
backup strategy of course. Different backup strategies for Solaris vs.
Linux boxes will of course incur different restoration times. If you
backup your Linux box to a tape library and your Solaris box to floppy
disks, of course it'll take longer to restore your Solaris box. You
cannot directly compare different strategies.
"rsync" works quite well on both platforms.
Why are you implying that Solaris backups should not considered reliable
after a hack while Linux backups could be? It's the identical situation
in either case. Throwing "Solaris" into that equasion is misleading.
You can no more trust backups of an 0wn3d Linux box than any other
platform.
I should also point out that, outside of malicious behaviour, higher-end
Sun hardware is extremely fault-tolerant. You'll wind up paying
kilobucks to buy similarly fault-tolerant Compaq hardware and Linux may
not support all the fault-tolerant features like CPU and PCI hotswap.
If you need 99% uptime, cheapo PC hardware is perfectly adequate.
If 99.999% uptime is required, generic PC hardware will often manage
that kind of longevity, but for the PHB types to be reassured, you'll
spend a lot on high-end Compaq or high-end Sun equipment.
If 100% uptime is a requirement, you're much better off going with a
really high-end mainframe; that's what they're designed for. (Of
course, the IBMs can run Linux.)
> 6: Installing the updated versions of widely used software packages requires numerous dependencies complicating the install on Solaris. Redhat and other independant software vendors can regularly updates these packages and others in an easy to install rpm format.
>
> (i.e. Bind, Apache, Sendmail, Samba, Perl, Openssh, Openssl, & others)
This is effectively the same as #3 and therefore has the same rebuttal.
> 7: Lower downtime with updating Redhat Linux.
> Redhat Linux only requires downtime for a kernel update. All other updates can be automatically installed without bringing the server down. Kernel updates haven't been needed on any of our Linux servers yet.
> Sun recommends bringing down Solaris for patching. This is a manual process that requires downtime.
Both sets of statements are misleading.
Linux requires downtime for kernel updates. As does Solaris. Sun does
recommend bouncing the box for _certain_ patches - typically the ones
that perform kernel updates.
On the one hand, I see many more patches come out for Linux distros,
which typically means they are more proactive at fixing problems.
On the other hand, typically you will install a Solaris box, apply all
existing patches, bounce the box and put it into production and
typically will not have to manage it except for security updates which
happen fairly infrequently.
Automated patching of Solaris boxes is as simple as writing a few
scripts. However, it's usually a bad idea to allow ANY system to
automatically update themselves. See below:
Unless a patch for Solaris *or* Linux is security-related or directly
related to the box' function, a good Sysadmin will just leave the thing
alone. There's no sense in patching up a box that is working perfectly
just because the patch is available if the patch doesn't directly affect
the functionality of the system or is security-related. i.e. the proper
attitude is, "If it works, don't fix it."
> 8: Additional drawbacks to Solaris.
> Your forced to install a resource hungry graphical user interface.
No more so than you are forced to run X on Linux. You can opt not to
start up the X shell on Solaris by removing a file from the rc.d
directories.
> Resource intensive applications that rely heavily on the CPU perform poorly on Solaris. Arcims is an example.
Generally true, but it depends entirely on the type of computing the
application performs.
Perhaps a better comparison would be to say that performance-wise, SPARC
chips cost orders of magnitude more than Intel chips. (I can buy a
brand-new Athlon 1.33Ghz chip for somewhere around $150, while it costs
something like $15K to upgrade a middle-range Sun box with another CPU -
more or less depending on your relationship with your Sun vendor.)
> Insecure Telnet is installed by default.
No competent sysadmin puts a default installation on the net and assumes
it's secure. Any competent sysadmin can secure a Solaris box roughly as
well as any Linux box can be secured. (Although I would have to build
and install ipfilter on the Solaris box while ipchains/iptables is
typically part of most standard Linux distros.)
> On Solaris 7 and below insecure root access to ftp was allowed. This was finally fixed in Solaris 8 but only under pressure from customers.
So disable ftp. See above answer.
> Login passwords are limited to 8 characters. Even if you set the password to "thispasswordislong" Solaris will only allow you to login with "thispass". This allows for reduced time on brute force password crackers. This applies to Telnet, FTP, Secure Shell, and anything else that relies on the Solaris login facility.
This I don't have enough knowledge to support or dispute. It depends on
whether or not Solaris still depends on "crypt" to encrypt passwords.
If you don't enable MD5 password hashes on your Linux box, "crypt" only
considers the first 8 characters of the password significant. This is a
fundamental aspect of "crypt."
> Solaris is a closed source operating system. Developers typically use Linux for developing new applications. Solaris ports and updates are becoming more and more infrequent.
The first sentence of that statement is a fact. The rest would need
hard facts to be anything but random statements.
> New Sun servers come with non standard keyboard and mouse connectors. Two 280Rs we have need a special USB adaptor, another two E250s need a special vga adaptor, and the remaining E450 uses a proprietary Sun connector. All of our Intel Compaq servers relies on industry standard PS2 keyboard and mouse connections controlled through a central switchbox.
Errr, ok. If you're buying E450's, you can afford to buy a KVM switch
that works with Sun equipment.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
#!/usr/bin/perl -w
$_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map
{$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;
$t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z)
[$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join
"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d=
unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d
>>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*
8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}
print+x"C*",@a}';s/x/pack+/g;eval
usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \
| extract_mpeg2 | mpeg2dec -
http://www.cs.cmu.edu/~dst/DeCSS/Gallery/
http://www.eff.org/ http://www.anti-dmca.org/
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 15:47:47 EDT