----- Original Message -----
From: <Steve.Craft@sungard.com>
To: <users@subversion.tigris.org>
Sent: Thursday, June 08, 2006 10:57 AM
Subject: 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.
[ All your messages seems to have this double spacing problem. I'll correct
it. ]
> 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.
Good. Glad to hear it.
> 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.
Uh-oh. I wrote them, so I disagree. Let's see.
>>> 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).
Good. What about sharing the C:$ drive, if you've allowed enough networking
to do simple Windows printing even as a client? And what about after the
"role" is set? I remember that the sharing.
>> 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),
Well, yes, and for lots of other reasons. But can you tell in advance which
software installations and security updates require a reboot under any
Windows release? It's nearly impossible! And it sometimes blocks additional
updates.
> so to changes to them require restarts. User-mode activities
> (eg Subversion maintenance, Apache, IIS, blahblahblah)
> clearly don't.
The reasons for reboots vary: there's not just the kernel, but registry
changes and core DLL changes that cannot be done on an active DLL, that
require a reboot to retire the old one. It's a serious issue.
>> 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?
Yes, and one of my clues is to avoid with a plage having to do my own
hand-written installations. Antoher is to use vendor supported, or at least
distribution supported, tools when possible. But they're certainly not part
of the distribution for Windows.
> 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.
You *CAN*, and it often works as you claim. But you might be really startled
at what happens when someone starts using old Win9x machines on the network:
it's quite embarassing. The tendency for it to dumb itself down to support
those older Windows clients is ectremely embarassing.
>> 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.
Ouch. I do sympathize with the difficulty. But the problem has to do with
the underlying server itself. It's often difficult to run a server without
the office suite, for various non-Subversion reasons.
It only takes one unsuspecting new admin, opening the infested Word document
or email from the boss while using the server, to trash the server or do
serious oddnesses to it. Linux and UNIX and Mac have been vastly more
resistant to that kind of problem.
> 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.
Directly, little to nothing. Indirectly, since it imperils the server, these
kind of security issues should be taken into account when selecting the
platform.
>> 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.
No, they're really not. They've apparently improved over the past year, but
they still draw a cloak of trade secret or NDA concealment over their
security efforts, especially when patching bugs that have only been reported
privately. The result is a set of long-standing bugs sitting in CERT or
other security groups' archives that are sometimes more than a year old
before addressed, and some long-standing issues that have never been fixed
and would require re-engineering of the operating system to fix. (We'll see
if Vista has the video driver security issues.)
> 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.
A Subversion server *MUST* be reachable by some group of network clients,
unless it's all being done with local "file:" access, and that's fairly
unusual. And saying that "if it can be accessed from the Internet" makes a
difference leads to a demonstrably risky policy, sometimes known as the
"hard crunchy outer shill, soft chewy underbelly" that leads to internal
servers being threatened by any attack that successfully attacks even one
machine inside the network. Laptops, in particular, are prone to bringing in
viruses and worms from the outside world, and forcing wild panics as
unpatched internal machines are infested or become vectors for the virus to
spread.
There are interesting ways to try and deal with this, but one core approach
is to simply keep the servers up to date on their security software, avoid
running unnecessary services, etc.
>> 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.
I'll disagree. First, I assume you were buying RHEL? Yes, license costs for
that are comparable to Windows Server 2003. But the RHEL includes, built-in,
the office suite, SSH, a good perl implementation, and even a decent (if out
of date) version of Subversion.
Second, if you're penny pinching, you can use a free distribution like
CentOS (which I highly recommend), Ubuntu, Debian, Fedora Core, Mandriva,
etc. I've actually installed OS's and various server software for more than
10,000 servers in one month, mostly Linux but including at least 500 Windows
machines (mostly dual-boot). The Windows servers were amazing pains, much
more prone to requiring hands-on probing to keep in service.
Similar savings apply to the BSD's: you wind up needing to pay for the Linux
expertise in-house this way, but for larger deployments, it often takes
fewer personnel and fewer man-hours than you'd need for Windows servers, in
my large-scale deployment expertise.
>> 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.
I don't have hard numbers: I'd love to gather them. My client support for
Subversion has been in internal networks, so the local networks have been
very fast, and people are doing large software bundles. The result is that
the server does get a very serious memory use while doing checkouts, and the
*CLIENT* is very sensitive to the amount of available RAM or quality of
swap.
>> 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
I'm stunned. I've had serious, serious, serious problems with this. I assume
that the machines you used were quite "vanilla"? All relativily standard
components, nothing only manufactured within the last six months? This has
been a serious bane of my existence for Windows machines, especially when
vendors low-bid hardware and use some very, very odd components.
> Server is fairly finicky, much more so than Subversion+Apache
> ever will be. What would make that "vastly easier" under Linux?
See my above experience deploying more than 10,000 machines in one month.
Admittedly that was a few years ago.
>> 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?
I've also successfully run servers of numerous types on much less hardware
for Linux than the nominal requirements for a Windows server. Mail servers,
web servers, heavily used DNS servers, authentication servers, and recently
Subversion servers.
Running Windows 2003 Server on a 128 Meg of RAM, 300 MHz box is a sad joke.
But I recently set up a completely functional copy of a Subversion server on
exactly that hardware using RHEL, mostly to provide a testbed for the more
commercial grade server and some planned changes for it, partly to provide a
walkthrough for a new administrator. Set up a hot-copy job to access it via
NFS or transfer updates via other means, and you have a nice little failover
server or debugging server.
Install it with CentOS instead, and you don't even need a license but can
return full compatibility with a RHEL equipped server. (I've done that,
too.) Now, me, I'd also be inclined to set up the network on both of them to
have a seondary, inactive port that is where the Subversion actually lives
and keep it live on the active server: switch on the failover in "read-only"
mode while swapping out the hardware or doing scheduled maintenance on the
main server, just to keep things accessible.
The switchover bit is feasible under Windows, too, I'm just describing how
I'd use a really cheap Linux server to do it.
> How does that translate to more Subversion functionality?
By requiring less hardware, it's easier to keep a good failover setup.
> 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.
Oh, goodness, I know your complaint. I don't think it's *THAT* bad, but it's
gotten troubling. The "Yum" tool, or its cousin apt for other distributions,
has really turned into my friend for running rampant through the OS and
throwing out unnecessary widgets.
But at least it's still possible to throw them out: Go ahead, try throwing
out the IPv6 stuff out of Windows, or the PCMCIA tools on systems that have
no such devices.
> 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.
Hold: remember that swap handling I mentioned above? It's not clear to me
that this is a valid test: For one thing, 2x933 is a very resepectable
amount of CPU power. Second, have you tried it with a number of simultaneous
downloads (the basic Slashdot effect)?
> Finally, mirroring on Windows is also as easy. Svk. SCP.
> Robocopy. Xcopy. SFTP. WinRAR-copy-WinRAR. Etc.
Symlinks and hardlinks become.... adventureous. None of the SSH based
systems support them, except rsync-over-SSH or perhaps tar-over-SSH.
>> 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.
No, I clearly failed to make my point. If your filesystem becomes corrupted,
due to OS difficulties or the beginning of a hardware failure, then it is
vastly easier and safer to use a Linux rescue or live CD disk to repair or
duplicate the filesystem than it is to recover or repair a Windows system
This is not so much about NTFS or ext3, but rather about the ease and
availability of file system management and other system tools in Linux
recovery tools than for Windows. Backups are great, but recovering from
backup is often a lengthy and painful process, and prone to missing the last
day or so's work.
Unfortunately, NTFS is often a nightmare to recover lost files from on a
trashed filesystem. There are some good tools, but they are notoriously
expensive, and I've had very good success with basic "fdisk" operations on
ext2 and ext3, fixing the filesystem without expensive additional software.
I've had much less success with NTFS. Admittedly, Reiserfs has not been so
successfully saved, but I went through quite a lot of this with the IBM
"Deathstar" drives when they started all failing in the same few months for
both Linux and Windows machines.
>> 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.
I'm saynig that the basic Linux OS's are better supported for 64-bit. It's
not so much a performance issue for Subversion (until you seriously,
seriously load the server!), but some companies are buying 64-bit systems as
a matter of course now. I just ran into that myself, and submitted the
patches to fix RPM compilation for them.
I wouldn't recommend BDB anymore for Subversion: I'd recomend FSFS, for
various reasons.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 8 18:46:17 2006