PDA

View Full Version : Linux verses Windows for Slimserver



Barry.B
2007-05-20, 07:52
Hi All,

Still considering pros and cons of Mac Mini/PC as storage with either big internal drive or USB external drive (500Gig). If I choose a PC, which is the most reliable OS out of Linux or Windows.
I am currently using XP service pack 2 since the jury is still out on Vista.

I have a PC case sitting doing nothing in the garage (Intel P2 and motherboard), I believe it's not that hard/expensive to put some thing fairly decent in there for a reasonable result. Any suggestions gratefully received.

Many thanks,

Regards,

Barry.B

Mark Lanctot
2007-05-20, 08:50
SS works better with Linux than Windows for me. I used Ubuntu and followed the directions in http://wiki.slimdevices.com/index.cgi?DebianPackage - worked first time and it's continued working on two different hardware setups with 3 versions of Ubuntu, without issue.

That P2 hardware might be a little slow for Ubuntu. You may want to check out SlimCD (http://www.herger.net/slim/detail.php?nr=763) which is lighter on resources and fine for a machine that will be used as a dedicated SlimServer. RAM is still an issue - how much does it have?

Hercules
2007-05-20, 09:37
If it's a dedicated PC, I'd go with Ubuntu. Although you will have to learn a little bit about Linux to get it up and running, it's pretty easy, and once you have done so, it runs fine.

I can't really say I've noticed any difference in reliability between running SlimServer on XP SP2, Vista and Ubuntu. (It runs fine on Vista for me.)

Pale Blue Ego
2007-05-20, 11:00
I have used both Windows and Linux on the same hardware, and Linux is always faster and more reliable. The fastest OS I've found is ClarkConnect, a Linux server OS designed to be run headless and administered over the network from a Windows box. I use it for Slimserver and as a file server for my network.

You can use the P2, but you should give it at least 512 RAM.

Barry.B
2007-05-20, 15:07
The P2 has at least 512 of RAM as we always go over the top with this.
I might just resurrect it and have a play. What's the max size hard drive this will support please.

Thanks for the replies so far, they are much appreciated.

Barry.B

Mark Lanctot
2007-05-20, 15:16
What's the max size hard drive this will support please.

Unless you can find a BIOS update for it, I think it's 36 GB?

egd
2007-05-20, 18:25
Unless you can find a BIOS update for it, I think it's 36 GB?

As Mark said, it depends on the BIOS, however, there may be a workaround in Ontrack Disk Manager if you opt for Windows. I can tell you unequivocally though that Linux would run a hell of a lot quicker as a slimserver host OS, which will be NB on such an old box. Have a look at Xubuntu - it is built with older hardware in mind, though I suspect SlimCD or ClarkConnect may be even more lightweight under the circumstances.

If your BIOS & on-board controller is a limitation spend a few $'s on an ISA SATA controller and disable your on-board controller. From memory this is a way around the partition size limitation in older BIOS', but best to check via Google.

servies
2007-05-20, 23:44
The P2 has at least 512 of RAM as we always go over the top with this.
I might just resurrect it and have a play. What's the max size hard drive this will support please.

Thanks for the replies so far, they are much appreciated.

Barry.B

If you use Linux there is no limit in the HD size.

egd
2007-05-21, 01:23
If you use Linux there is no limit in the HD size.

Only insofar as the BIOS is capable of seeing the full hard drive, which some older BIOS' aren't. A replacement controller would overcome this, if in fact it is an issue for the pc in question.

servies
2007-05-21, 01:41
Only insofar as the BIOS is capable of seeing the full hard drive, which some older BIOS' aren't. A replacement controller would overcome this, if in fact it is an issue for the pc in question.
Linux doesn't use the BIOS, so it's not limited by what the BIOS sees.
The only limit is the 2 Terabyte limit which is to my knowledge the maximum the EXT3 filesystem can handle...

egd
2007-05-21, 03:38
Linux doesn't use the BIOS, so it's not limited by what the BIOS sees.
The only limit is the 2 Terabyte limit which is to my knowledge the maximum the EXT3 filesystem can handle...

I've learned something, then again, perhaps not...

mlsstl
2007-05-21, 03:55
> Linux doesn't use the BIOS, so it's not limited by what the BIOS sees.

I don't believe that is correct. When I built my dedicated Squeezeserver Linux box last fall I ran into an issue with the old motherboard I was going to use. It had a 160 GB drive limitation. While it worked with the 300 GB drive, it could not see all of it. No BIOS upgrade was available so I ended up replacing the motherboard (but they are not expensive these days.)

Stoker
2007-05-21, 05:54
I recently built a linux (Debian) server out of an old PC I had lying around and I had a bios/hard disc problem. The boot disc seemed limited to the size that the bios could support, it wouldn't boot if I installed Debian onto a larger HD. I got round this by using my origonal (30 Gig) HD to hold the Debian OS and just mounted a second (300 Gig) drive for my music on the other IDE channel, works without issue and I can see all of the second drive.

I'd also vote for giving the Linux OS a try, in my experience its more stable than the Windows 2000 it replaced and is definately quicker on library re-scans.

servies
2007-05-21, 05:57
> Linux doesn't use the BIOS, so it's not limited by what the BIOS sees.

I don't believe that is correct. When I built my dedicated Squeezeserver Linux box last fall I ran into an issue with the old motherboard I was going to use. It had a 160 GB drive limitation. While it worked with the 300 GB drive, it could not see all of it. No BIOS upgrade was available so I ended up replacing the motherboard (but they are not expensive these days.)
I'm not aware of a 160GB limitation, there was a 137GB limit which is caused by an 28bit sector address space on much older IDE controllers. nowadays the sector address space is 48 bits large but that has nothing to do with the BIOS, it's a physical limitation of older ATA controllers
Linux doesn't use the BIOS to access the disc and to determine it's size. The only limit the BIOS did put on Linux is that your boot partition had to be on the lower 1024 cylinders of a disk.

see also http://www.linux.com/howtos/Large-Disk-HOWTO.shtml

Mark Lanctot
2007-05-21, 08:53
Linux doesn't use the BIOS, so it's not limited by what the BIOS sees.

It does at boot - it has to, the kernel's not loaded yet! You have to have something initiate all the systems and get to the boot sector so the kernel can load.

Why else would there be a LinuxBIOS (http://www.linuxbios.org/Welcome_to_LinuxBIOS) project?

If you don't believe me, remove your BIOS chip from its socket and try to boot Linux...

servies
2007-05-21, 12:43
It does at boot - it has to, the kernel's not loaded yet! You have to have something initiate all the systems and get to the boot sector so the kernel can load.

Why else would there be a LinuxBIOS (http://www.linuxbios.org/Welcome_to_LinuxBIOS) project?

If you don't believe me, remove your BIOS chip from its socket and try to boot Linux...
That's why I said that the boot partition should be below the 1024 cylinders border. For the rest Linux doesn't use the BIOS at all.
Read that page and you get what it really does. It has very little to do with Linux, just that it probably uses some code that's also found in Linux.

from the site I mentioned:

5. Booting

When the system is booted, the BIOS reads sector 0 (known as the MBR - the Master Boot Record) from the first disk (or from floppy or CDROM), and jumps to the code found there - usually some bootstrap loader. These small bootstrap programs found there typically have no own disk drivers and use BIOS services. This means that a Linux kernel can only be booted when it is entirely located within the first 1024 cylinders, unless you both have a modern BIOS (a BIOS that supports the Extended INT13 functions), and a modern bootloader (a bootloader that uses these functions when available).

This problem (if it is a problem) is very easily solved: make sure that the kernel (and perhaps other files used during bootup, such as LILO map files) are located on a partition that is entirely contained in the first 1024 cylinders of a disk that the BIOS can access - probably this means the first or second disk.

Thus: create a small partition, say 10 MB large, so that there is room for a handful of kernels, making sure that it is entirely contained within the first 1024 cylinders of the first or second disk. Mount it on /boot so that LILO will put its stuff there.

Most systems from 1998 or later will have a modern BIOS.