On Tue, Jan 25, 2011 at 11:56, Chris Albertson
<albertson.chris_at_gmail.com> wrote:
> On Tue, Jan 25, 2011 at 12:43 AM, Oliver Marshall
> <Oliver.Marshall_at_g2support.com> wrote:
>> Hi,
>>
>>
>>
>> As far as subversion is concerned, is there any reason to go for one OS over
>> another when setting up a new subversion server? Are any of the hooks or
>> features OS dependant?
>
> Choose the OS that is the best stabilty nd the best file system
> performance. That would be Solaris and ZFS. But more people know
> about Linux so that is what they recommend.
And if the skillset in your shop is primarily Windows, using Solaris
or Linux would require a lot of expensive training, or hiring an
expensive new system admin (or contracting for one on an as-needed
basis), for a single service.
> But do think about the
> file system and how you will be able to continue running and not have
> to re-boot or power down if a drive fails. Lots of ways to handle
> that.
That's going to vary not just by OS but by implementation, hardware &
drivers as well. My repositories are stored on a SAN, so drive failure
is completely abstracted from the host OS of the Subversion server.
> Last I looked (a while back) Windows required a re-boot after
> almost any trivial change of settings.
It seems like it's been a very long time since you've looked at
Windows. I'm trying to remember the last time we had to reboot our
Windows Subversion server for anything other than an OS or other
critical software patch. Certainly not for "trivial" settings changes.
> It would be good if you could
> add additional storage space or even swap out drive without a re-boot.
> ZFS is made just for that.
Windows can handle this as well. Again, it's a matter of having the
right hardware that's designed for the application. We dynamically
expand LUNs on our SAN regularly - no reboot of Windows required. Or,
if needed, detach storage & attach new storage, again without a
reboot. Hot swapping of physical drives requires hardware support too.
> Windows is not as nice for remote access.
> Again because you need to re-boot and of course the re-boot kills the
> remote link.
Windows remote access works just fine, in fact that's how I access
*all* of my servers - RDP, not even the virtual console under VMware.
Or for scripting, WMI & WinRM. When the system comes back up from a
reboot, you can remote in right away.
Windows is not the third-rate OS you're making it out to be in this post.
Received on 2011-01-25 18:26:26 CET