39 updates
by Volker Weber
39 updates after a fresh install out of a brand new Windows 2003 Server box (hiding behind this box). That is pretty steep. Of course they can't all be installed because certain patches need to be installed separately.
Whoever comes up with numbers that Windows servers have the same maintenance cost as Linux servers, has installed neither lately. It starts when you have to babysit the Windows install, where a Linux install asks you a few questions upfront and then does its thing, instead of asking questions during the whole process. Then you hit update, select all, hit go and get your second cup of coffee. The MS guy does the update, reboot, update, reboot, update shuffle. Oh, that would be me ...
Downloading the Windows 2003 Server Service Pack 1 now. 333 Megabyte at 12 kByte/s. Should be finished by tomorrow morning.
Update: Moved the download from the Windows server to the Mac client which cut the required time from eight hours to 48 minutes.
Comments
Mmh, I lately installed a SuSE Enterprise Server 8 (for Domino). The Online Update took more than an hour (which was good compared to some other installations I remember), asked me a few questions upfront and then didn't do its thing, but stopped the process repeatedly with a lot of dialogs about daemons to restart afterwards. No chance to leave it unattended. Did I mention it failed to reboot because it didn't update some drivers on a certified platform?
I beg to differ in one point: If you're unlucky enough to use the wrong Linux distribution, you may well find yourself in a situation where you have to babysit the installation of updates like you would have to if you were using Windows. Unless you install apt-get for SuSE that is ;-)
@Oliver: überschnitten ;-)
Unfortunately, there's no apt-get for SLES available. You can, however, download all patches using wget and apply them using rpm. Most likely, you'll have to reboot the server afterwards anyhow but this way you get rid of the annoying information boxes. That way I upgrade most of the SLES/SLOX servers I'm responsible for.
@Stefan:
I always use apt-get for my fedora installations and a quick google search shows a lot of results. For example:
http://soiland.no/software/apt-sles/
What I am wondering about : is there any reason why the download would go faster on the mac than on the windows server itself ?
Anything technical you can nail down, Volker ?
Alex, I have no idea. It sits on the same physical network in the same subnet as the Mac. The machine was running Windows 2000 Server before but I did a fresh install on a clean disk.
For what it’s worth, I’ve noticed similar behaviour when performing downloads on my home network: the Win98 and WinXP machines are slower than the OS X machine, but I don’t know why.
I’m certainly no Windows expert: perhaps it’s related to how Windows resolves IP addresses and domain names? For example, connecting to other machines at home or at work using Windows Explorer is always very slow — linking with SMB is lightning fast by comparison.
Detlev, let me quote the site you named: "It might not be legal according to the SLES license to distribute freely the SuSE RPMs (although the source code might be free to distribute). Instead of investigating the legal matters and create an SLES9 apt-archive for the world, it's easy to just create a local archive."
So, using apt-get in this environment has the only benefit of being able to install a new package including all dependencies. However, if you only want to update your installation, there's no difference in just downloading the RPM package and using rpm -Fvh *.rpm. The benefit of using apt to install a new package is imho somewhat negated by the fact that you first have to built your own package lists so apt can actually use them.
Ben, even if the domainnam/ip resolving of Windows should be slow, this process is only required once per download.
The number of updates reminds me of my recent windows server experience:
New installed Windows 2000 Server: 7 important updates
After installing SP4: 43 important updates.
