[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Enterprise Wishlists...



On December 16, 2003 12:31 am, Peter Vandenabeele wrote:
> On Mon, Dec 15, 2003 at 07:53:11PM -0800, Michael Peddemors wrote:
> [...]
>
> > Which begs the question, how important is WINE for the environment?
> >
> > Our experience has shown that we can get about 90% Linux penetration at
> > the desktop, and have a client who is happy, and can perform all of their
> > enterprise tasks..  The last 10% are running Windows Apps they "can't
> > live without".  This is legacy stuff.. And that is always a factor in any
> > enterprise change..
>
> What is the solution you implemented most succesfully in actual customer
> projects to this "last 10%"?
>
> * leave some Windows PC's in place
> * use a central Windows server with something like Citrix
> * use Wine
> * use VMWare or the likes

For the most part, solution #1, and the company will look to changing over the 
rest if/when their requirements change.  IE The last company had a small 
telco software to monitor incoming/outgoing calls.  The product cost was only 
$1000 in the first place, so it wasn't viable to 'custom develop' an app for 
Linux, and the time involved to make sure it ported to Wine wasn't worth it, 
so a single station stayed on Windows for that.  As well, 6 members in the 
accounting staff were using an accouting application on Windows, that they 
had heavily invested in.  Now that they have moved 90% over to Linux, they 
recognize all future expenditures should run on Linux, or be web based.  And 
when they will wait for a Linux version of call counting software, and they 
are looking to port the accounting software to Wine in the future, otherwise 
they expect that in the future a Linux FrontEnd will be avialable. They 
managed to do this project with no investment in porting software, and this 
is the preferred scenario.  Another company looked at porting an application 
because it was used in every station, and the only thing holding them from 
migrating to Linux. Personally, I don't think there is anything wrong with 
leaving a few Windows PC's in place, if it makes the staff's time more 
effective.  It is a business decision, balancing the needs of the client, 
against the higher admin and licensing costs of the machine.

Using a central Windows server usually can't be justified for the smaller 
remaining windows implementations, and using VMWare isn't as attractive to 
the customer, except in specific cases.  Using single Windows boxes make it 
easily to migrate one task/computer at a time to Linux, and Samba integration 
makes the Windows box become a Thick Client first, and slowly a thin client, 
and taking advantage of the Linux stability for file storage etc..

(BTW, Enterprise needs a MUCH better Samba interface.  Linneighbourhood is the 
best at this time, and as much as we tried to make Komba work, it needed far 
more work in a Thin Client environment than Linneighbourhood.  A standard for 
handling windows share mounting would really help, as long as we are 
expecting it to coexist into existing Enterprise environments.)

> Am I right that once you get to 90% Linux (actually 90% Open Standards,
> the implementation seems less important for this issue), the integration
> problems between Linux and Windows start to decrease (compared to a 50-50
> situation).

No, we find that in typical office environments, the main inhibitors are only 
a few programs that are used company wide, and once those changes are 
excepted, you are at 90% deployment.

Most computers are used for the same general task load, except for a few 
stations where either specialized processes happen, or previous investments 
in custom software are still in place.

Main stumblers to reach 90%??  Well, users of outlook, advanced excel, some 
sites that ONLY work on IE, collaborative tools, and after that it is ease of 
use of tools.  The other proprietary softwares that are used that can't be 
satisfied by Linux deployments economically are normally only used by 10% of 
the staff.

(Sure, there are have stumblers that frustrate people.. ie Oo control panels 
that don't resize small enough in 800x600 :)

But it is all about, 'Can my people be productive, and can I save money at the 
same time'.  To that, I state, 90% of them can, and we can integrate with the 
other 10% seamlessly..

Another example is staff who have invested years of training on a product.. 
say Adobe PhotoShop .. you can't expect to switch them over to Gimp and have 
them productive right away... For those persons you may not change; in the 
future you might hire a eg Gimp graphics person if you expand that 
department.  

But this is why companies always had a few apple computers in a Windows work 
environment..  So this is no different.. 

(In one case, the company hired a developer who only knew the Windows versions 
of the program, (Oracle Developer) and at his hourly rates it was cheaper to 
drop one Windows PC in than having his productivity drop.  Of course, now 
they have learnt, and consider the developers experience in Linux before 
hiring :)

> Thanks,
>
> Peter
> _______________________________________________
> kde-debian mailing list
> kde-debian@kde.org
> https://mail.kde.org/mailman/listinfo/kde-debian

-- 
"Catch the Magic of Linux..."
--------------------------------------------------------
Michael Peddemors - Senior Systems Developer 
LinuxAdministration - Internet Services
NetworkServices - Programming - Security
Wizard IT Services http://www.wizard.ca 
Linux Support Specialist - http://www.linuxmagic.com
LinuxMagic is a Registered TradeMark of Wizard Tower TechnoServices Ltd.
--------------------------------------------------------
(604)589-0037 Beautiful British Columbia, Canada

This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to which they
are addressed. If you have received this email in error please notify
the system manager. Please note that any views or opinions presented in
this email are solely those of the author and do not necessarily
represent those of the company.



Reply to: