Thanks for the response. Just to let everyone know I'm going to revise this to be fare to the Sun people. No sense in saying something that is misleading. Updates are in bold.
> 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.
Rewrite: 2: While a numer of 3rd party software is not avaiable on Linux the following are needed that are not available on Solaris. (i.e. Ncpmount * Allows connections to Netware, Smbmount * Allows connections to Windows, & Wine - Windows emulation. (Wine is avaiable on x86 Solaris but not Sparc, Sharity lite is avaiable on non linux systems but smbmount isn't available.)
> 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.
3: Software packages like Bash, Openssh, Perl, Gcc, Apache... are available for Solaris in an easy to install pkgadd format but Sun doesn't offer support for these packages as part of there normal OS support. Also a number of packages on sunfreeware are not the latest. For example Apache is currently at 1.3.23 but on sunfreeware it is at 1.3.12. The Redhat Linux apache rpm is at 1.3.22. This makes it easier to reduce the complexity in maintaining a system. While compiling from source is necessary at times it adds complexity.
> 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.
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. As a counter argument a large number of packages that are available on Solaris are not available on Linux. But that is quickly changing. Arcims for example will not work on Linux but the next release will be supported.
> 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.
Your right. Point taken.
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.)
99% is good enough but anything more than a day of downtime won't work.
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. Mkcdrec allows for you to build an iso image of your server that can be burnt to a cd. Then you boot the server off the cd and it will rebuild all the partitions and make the system bootable. The bottom line is to enpower a lesser experieced Administrator to quickly recover a server if I'm gone on vacation.
Ghost cannot be used on Sun hardware.
> 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.
This is what I meant but I'm having trouble trying to pull up an example. If I can't find an example on my network I'll remove it this point.
6: Some of the software we use requires numerous dependencies that are not always available in pkgadd format. While this can also be true of rpm it's much less of a problem.
> 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:
Point taken.
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."
7: Lower downtime with updating Linux.
Linux only requires downtime for a kernel patchs. All other patches can be installed without bringing the server down. Security related patches are applied automatically.
While the same applies to Solaris Sun recommends bringing down Solaris when applying there cluster patches.
> 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.
8: Additional drawbacks to Solaris.
Your forced to install a resource hungry graphical user interface. X can be disabled but eliminates the ability to use multiple shell sessions.
> 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.
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.)
You do have a point that an effective Administrator should not install what is not needed but not everyone is an effective Administrator. As a standard Telnet should be going away in favor of Secure Shell.
> 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.
The reason why I included this is it is another example of how Sun is slow to react to changes. This is similar to the telnet example above.
> 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."
Point taken. Another argument.
>>>> Dig up the numbers. password lengths of 6 are more secure by
a factor of what to a 4 letter password. What is the relative value of a 8
character password to an 8+x character password.
I was able to do a brute force crack on my shadow password file some time ago and was able to crack my password within 20 minutes. The password to 9 charactors long and had two numbers in it. But the last number was at the end of the password. All our new passwords have more random numbers and letters to help alleviate this but in practice a very powerful PC could crack a shadow password file quickly.
> 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.
Point taken. I'll remove this statement.
> 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.
We do have a KVM switch that is geared for Sun servers but we still need the adaptors. It's a real pain to deal with.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
#!/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:48:33 EDT