[TriLUG] microsoft ad

Kevin Flanagan kevin at flanagannc.net
Sat Mar 4 20:26:45 EST 2006


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 <jim at neuse.net> 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.
>>>  
>>>
>
>



More information about the TriLUG mailing list