Windows does not Stink, Now Really OT (was RE: Re: Look for help on windows server platform)

I had no intention of getting another Linux/Windows religious war

going. Really.

I have been doing Subversion servers on Win32 for years, on Fedora

once, and on FreeBSD once. I am much more familiar with how Subversion

works on Win32, and thought I might be missing something in the

Subversion+Apache feature set since I don't have much experience with

the server running on a *nix. It appears Subversion "just runs" on

Win32, just the same way it "just runs" on a *nix.

None of the anti-Win32 points, and some of the other anti-Windows follow

ups, are really helpful. They are at best tangentially half-true, or

just false.

>> I'm not 100% sure why "linux as a subversion server is better".

>>

>> As far as I know, Apache==Apache, Subversion==Subversion, etc.

>>

>> Can someone elaborate on that?

>

> Security, since Linux has much b etter ability to turn unnecessary or

> undesired services by simply never installing them.

. At install time, Win 2003 server does not allow any

  inbound network access until it's been updated and had its "role"

  set, which will/not install various services or drivers (eg IIS).

> Security, since Linux almost never requires rebooting to implement the

> latest software or security patches.

. Some things require reboots for Win 2003, some don't.

  For speed sake, some Win32 server parts are implemented

  in the kernel (loaded at boot time for obvious reasons),

  so to changes to them require restarts. User-mode activities

  (eg Subversion maintenance, Apache, IIS, blahblahblah)

  clearly don't.

> Security, since tools like SSH and sudo allow much safer and easier

> management of user accounts and administrative privileges.

. SSH exists for Win32 in about a zillion implementations. It

  doesn't come on the Microsoft-supplied CDROM, you have to have

  a clue about being a server admin to get it. But if you are

  running a *nix server, you also have to have a clue, right?

  Even without SSH, the network traffic for Windows domain

  account management, using the CLI or GUI tools, is

  encrypted natively. LDAP traffic can be wrapped in

  SSL by using certificates.

> Security, since the web and office suites tools on Linux are

> historically far more secure than those for Microsoft.

. I'm not sure what an Office Suite has to do with the Subversion

  server family functionality. One of the things that makes the

  Microsoft office suites "unsecure" is the ability to do scripting

  and macros. I am currently migrating some Word document

  content into another doc, while scripting the revision history

  baked into each document. That fuctionality is not there for

  OpenOffice or Star Office.

  IE is a mess, but then again I use FireFox primarily,

  probably just like everyone else on this list. But again

  what that has to do with running Subversion baffles me.

> Security, since the update time of a particular discovered software

> vulnerability in Linux is usually measured in days if not hours and

> announced publicly rather than kept concealed and revealed only after

> Microsoft has gotten around to fixing it in a public patch, which in

> some cases has been more than a year and the flaws thus never publicly

> acknowledged by Microsoft or announced by CERT.

. I think MS does a pretty bad job at that, as a corporation

  they don't do anything unless if affects their bottom line.

  So while I don't like that they do that, I understand. One

  thing in their favor is that they have to compete in this

  area, so they are now moving to a Linux-style reaction to

  security flaws.

  Aha, now this is a pro-Subversion-on-Linux reason. I think

  it could have been worded a little better, something like

  "if your Subversion server can be accessed via the

  internet, realize that if there is a Windows net-centric

  security flaw it might not be addressed as quickly

  compared to a Linux implementation". But persuading

  your boss (in some cases that means betting your job)

  that going with a given Linux means immediate security

  relief sounds kinda risky to me. But YMMV.

> Direct expense, since even a commercial Linux license is usually much

> less than the price of a Windows Server license and permits multiple

> clients easily for whatever services are running on it.

. I have experience with Red Hat Enterprise (a "commercial Linux

  license") in large environments and it is not much cheaper

  than a Windows 2003 Server license. An apples to apples

  comparison is almost always impossible,

  but it is safe to say that Linux will be cheaper than Windows

  in a large environment by a hair's breadth, and sometimes the price

  goes the other way after you add other offerings like application

  servers or support desk hotlines. I think a Subversion-

  centered argument based around OS purchase/support

  price is a borderline waste of time.

> Better management of swap space, in my experience since the 2.6

> kernel came out.

. I don't have time to do speed testing (I'm spending enough time

  writing this email), but I have serious doubts that my 44

  TortoiseSVN clients will say that repositories hosted on Linux respond

  faster to repositories hosted in Win2K3 because the swap space

  is managed better. In my experience, the bottleneck is that

  expanse between the server swap space and the client desktop,

  otherwise known as the network. If benchmarks exist showing

  faster checkouts from one OS platform versus another, I'd like to

  see them. I've got clients all over the globe and speed counts,

  but after the packets cross over a dozen routers and firewalls, I

  don't see swap management impacting performance.

> Vastly easier duplication of a server setup to new or replacement

> hardware.

. Norton Ghost, and a dozen other commercial/shareware/freeware

  products like it, gives the ability to duplicate an HD. In

  addition, I once took a SQL Server-dedicated machine,

  removed the hard drive, placed it in new machine,

  and the OS detected the different network hardware, different video

  card, different SCSI and IDE configuration, new sound card (it was on

  the motherboard, don't ask why), and even played a startup waveform

  at logon. SQL Server started up and things went on. SQL

  Server is fairly finicky, much more so than Subversion+Apache

  ever will be. What would make that "vastly easier" under Linux?

> Less expensive hardware to run the server, allowing easy availability

> of a

> hot failover setup when coupled with the ease of mirroring a

> repository under Linux.

. Where exactly is the hardware cost savings when choosing

  Linux over Windows? I am guessing you are saying that with the

  money saved over buying a Linux license over a Windows one,

  more hardware can be bought. So what do you do with the $500

  you saved? Get another gig of RAM? Add another HD+controller?

  How does that translate to more Subversion functionality?

  Adding some anecdotal reality, I ran qmail on RH 5.2 on

  my AlphaAXP box in 1999, that is when Linux was acutally

  lean and mean. These days you get almost as much

  memory-sucking and disk-sucking bloat as Windows.

  In addition, I have a Subversion server (also a web server)

  running Win2K3 in a VMWare instance, and I "starve" it with

  only 256mb of RAM, the host is a dual PIII-933. It's 10 Clients

  get served via Apache, and a large svn export takes about

  a minute longer than it does with a dedicated Subversion

  host. Nobody seems to care about the lost minute.

  Finally, mirroring on Windows is also as easy. Svk. SCP.

  Robocopy. Xcopy. SFTP. WinRAR-copy-WinRAR. Etc.

> Easier recovery from failed hardware, since it's trivial to boot a

> Linux

> system with a live CD and image the disk elsewhere in cases where

> Windows has been hopelessly thrashed or the NTFS file system is

> hopelessly garbeled.

. I think a couple of metaphors were mixed there, but I

  finally found another point that could be made. Maybe it

  could be worded as "If your disk environment is

  consistently unstable, you might want to use EXT3, which only

  runs on Linux, instead of NTFS, which is all that Microsoft

  has to offer". Then again, if your disk environment is

  consistently unstable, you might not want to host source

  and version control on the box.

> Considerably better support for 64-bit hardware.

. What does that have to do with repository read/write to

  a svn server? Or even local file:// access?

  I'll go out on a limb and say that if Berkeley DB is the

  repository store, and BDFS is using 64-bit memory addressing

  (can it do that?), you will get more speed from Subversion

  on a 64-bit Linux implementation because the database has more

  breathing room. But come on.

> The list goes on.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 8 16:59:48 2006