Re: Why Linux, Why Debian
On Mon, 16 Feb 2004 18:18, Philip Brown <email@example.com> wrote:
> On Sat, Feb 14, 2004 at 03:33:09PM +1100, Russell Coker wrote:
> > On Sat, 14 Feb 2004 07:45, Philip Brown <firstname.lastname@example.org> wrote:
> > > If someone is specifically interested in
> > > "how does solaris compare with linux", I would suggest finding a
> > > SCSI-based x86 machine, and doing the comparison on that box.
> > Why SCSI? For the same money IDE will significantly outperform SCSI.
> > One of the advantages of x86 systems is that you can use cheap IDE disks
> > instead of expensive SCSI disks.
> Because solaris's IDE drivers are somewhat hacky. If you do the comparison
> on an IDE sytem, you will most likely end up comparing how sucky solaris's
> IDE drivers are to linux, as opposed to comparing the two kernels in
So compare Linux with IDE disks and Solaris with SCSI. Linux should still
win, it did last time I performed such a test!
Solaris 2.6 has UFS as the only file system for disks. In my tests UFS was
slower than Ext2 in Linux 2.2.x for file creation and deletion, even when
running on machines with faster CPUs and disks. Using ReiserFS the
performance difference of create/delete was very amusing.
ReiserFS in Linux 2.2.x could outperform tmpfs on Solaris 2.6 for file
According to my tests anything that could be done with one CPU and a few disks
would be much faster on Linux 2.2.x than Solaris 2.6. Now that we've had
three major Solaris releases and two major Linux releases it would be
interesting to see if those things have changed.
Also Linux wins on disk IO through having so many file systems. Ext3,
ReiserFS, XFS, and JFS all have their benefits, when you use Linux you get a
choice, with Solaris you only get one option (which probably won't win in any
> > ssh is significantly slower on SPARC Linux than on SPARC/Solaris or
> > Intel. Something about the optimisation of the crypto code. While there
> > are issues like that it's difficult to do good tests for comparing
> > machines.
> errr.. that sounds rather odd. Surely, using gcc x.y.z on sparc linux,
> should result in pretty much the same optimization as on sparc solaris,
> when it comes to user-level code.
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page