My observations, I'm not saying that anyone is wrong, or right for that
matter........
Any environment that will want more than a couple of systems done at
a time will be well served to automate the process, you can have Windows
or Linux done in similar time, as Matthew noted, Windows loads from CDs,
and Linux from the network in most cases. I think that the majority of
the time difference is the media.
Don't forget that just installing a few systems isn't all there is
to it, if you have any real number of systems you will need to do some
infrastructure bits.
Taking just Windows and Redhat examples
- Windows Update, you surely won't just take the patches off of the
net and apply them without testing. That'll take more systems, and an
infrastructure, WSUS, to manage what to push out to which systems, when
in your environment
- Redhat Network, it's really a lot like WSUS, the main difference
is that it can be used to do a lot more than just patch management,
provisioning of new systems being the one biggie.
These will require one or more servers, as well as test systems. Even
patches that are perfect to the one thing that they are designed to fix
provide opportunities to hone your troubleshooting skills when some
strange app decides that it doesn't like that fix, it was depending on
the "broken" functionality.
Larger enterprises typically don't take vendor provided installations
and put them in production, most to all systems are reloaded before
going into production. We do that for Windows, servers, workstations,
whatever. Our installations for Windows are very automated, and get all
of the installation of patches and apps done before the user ever sees
their new system. The number of minutes elapsed isn't always the
issue, it's the number of minutes that a technician needs to spend doing
something to it. We load several servers, and dozens of workstations,
all with Windows, in a fairly short bit of time. Workstations take
about an hour, servers about two, but only about 5 to 10 minutes of the
technician's time.
Kevin
Matthew Lavigne wrote:
As one that does both of these in a test environment, where setting up
consistently is more important then almost anything other then the
testing, and we set up quite a few of both boxes each week, I will say
the following:
Linux is can be configured (through kickstarts and scripting) to set
itself up and configure with zero interaction. This is based on using
a kickstart, and then scripting in the postinstall to catch the system
prior to the normal redhat firstboot, and then redirecting to script
the remainder of any production software that needs to be installed or
configured. Reboots required == 1, user interaction required= boot
the system and select the installation type (test type). End result,
a completely configured system the next time that it is powered on.
Number of Configs or CDs required == 1
Windows can be and is set up about the same. CD required == 1 per
system type, because the unattended installer has to have custom paths
for each separate system. Number of reboots required == 3 minimum (1
in the OS install, reboot and then one following patch installation).
User interaction required is to login and execute the patch installer
and verify that applications are installed. End result is a system
that is completely configured the next time that it is powered on.
Windows does not have the same install flexibility that the Linux
kickstart does such as allowing multiple different config types and
that is the primary weakness.
Time on the installers,
Linux about 10 minutes
Windows about 35 minutes
This is one the same system on a Gig network, so it is the
OS/Installer/Media (windows installs via CD not network). But as Will
commented earlier, there are a multitude of ways to configure linux to
install and windows has quite a few similar options.
In closing I think that Magnus' point is that depending on the
skillset and the tools that the person installing/configuring has
invested the time in perfecting either windows or linux can be mass
rolled out, and configured relatively quickly. The issue as I see it
is that the end user on the desktop is more likely to be able to keep
a window box running then a linux box (assuming standard exposure
levels and not geek exposure levels)
Matthew
Jim Ray wrote:
i define "there" as taking less time to set up for operation for the
customer and, therefore, costing less money due to less labor.
using my own production rate, i can load a linux desktop will all
patches and applications in an hour. it takes at least twice as long
to do so with winders.
using the production rate of two different experts who have loaded
servers for me, they take longer to get a server functional in linux
than it takes me in winders.
so, from a cost point of view, desktops in linux are ready to go.
the server side will probably come along in the near future. it has
come a long way yet still has a ways to go.
now, when the law of large numbers kicks in (ie a thousand desktop
PCs), the extra server labor amortized by the number of desktops
makes it a no brainer. for the small business environment, though,
extra server labor is a bad thing.
seeya,
jim
ps i hope all is well at yonderway :-)
Magnus wrote:
On 3/4/06, Jim Ray <[EMAIL PROTECTED]> wrote:
key word is yet. desktops are there. when the server side comes
around, microsoft had better look out...
Actually I think you have it backwards.
Server side has been "there" for some time with Linux.
Desktop is more painful for non-geeks. Heck, desktop is painful for
*geeks*
but geeks seem to be masochistic when it comes to Linux desktops.
--
TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
TriLUG Organizational FAQ : http://trilug.org/faq/
TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
