[Gllug] is this a big problem?
Liam Smit
liam.smit at gmail.com
Fri Aug 26 15:54:02 UTC 2005
> Can the average sys admin fix software? I know I'd not be able to
> delve into the reams and reams of sourcecode to find the problem with
> an LDAP installation if I had ascertained that the software was at
> fault.
If the problem is at a source code level for either Linux / Microsoft
and changing the source code is not an option then they are both
equally broken and will remain that way. Then again I've managed to
get open source software fixed for me by the developers. That said I
find most problems to be down to configuration. If it is a
configuration issue then knowing how it all fits together because you
put it together and not some automated 'wizard' system will be a big
help.
> I also know that my IT director would want assurances that the code
> changes I'd made would be easily transplantable into future releases
> and that the changes I had made were not locking us into a system
> that could not be supported by third parties.
Your business model seems to be based on finding outside parties to be
responsible for your systems. If that is the way it is setup then you
will obviously have to keep to software configurations which are
supported.
> Linux in the enterprise is often supported by maintenance contracts -
> the cost of Linux for us is now the cost of a SUSE maintenance
> contract - this is about the cost of a Windows Server license - we've
> already paid for the bulk of our CALs and if we don't get rid of
> Windows altogether we'd have to keep buying the CALs.
Ah yes CALs. Licences to use your computer to access your data on your
other computer because that computer is running Microsoft software.
I'd recommend:
a.) migrate that server to something which does not require CALs
b.) running a pilot study and getting a price break from Microsoft so
that they don't lose you as a customer.
c.) be extremely wary of buying anymore CALs or products which require CALs
Not that we don't have Windows machines which require CALs to access
certain servers but these servers aren't exactly godsends and are
probably going to get replaced with something better eventually. The
users hate the client software for it so would welcome the chance to
move to something better.
> This is where you have to consider - for the bulk of companies which
> are running applications because they are 100% compatible - Sales,
> bespoke databases etc - with what other companies are running is a
> 100% approach to linux really faesible.
That's not compatibility between applications that is using the same
application that everyone else is. Might want to consider interfaces
and documents based on open standards because that sounds very locked
into a vendor.
> We produce products for the bulk market so we have to support
> Windows. Linux is used where it has technical advantages - higher
> throughput, greater adherance to standards. However these are areas
> where Micrsoft is picking up speed.
I have no problem in you or me or anyone else releasing products for
the Windows using market place, I draw the line at requiring people to
use one Windows and only Windows to use a product or using Windows
myself.
> > As to pushing down software to keep user machines up to date that
> > sounds like someone is shoe horning the fat client model to fit the
> > thin client model.
>
> So it's better to leave users running old software versions?
Did i say that?
> I'm not
> talking about pushing installs of Micrsoft Office but our small
> (<10Mb) internal applications are perfectly suited to being checked
> and pushed at logon.
Well as they say there are many ways to skin a cat and that is one of them.
You can do the same with *nix.
> > Of course the chances that the Microsoft person will be able to fix
> > anything if it breaks are also pretty remote. Retry, reboot, reinstall
> > anyone?
>
> The chances that a ys admin will be able to fix the problem with
> software are pretty remote wether the software is Linux, Windows, VMS
> etc - however Microsoft's technical support is very good and have
> helped us with a number of obscure problems. We've never had to pay
> and the results have always been pretty quick. The only problem
> they've not been able to fixed appears to be a platform specific
> problem with SMP Athlons on a certain chipstet.
Some sys admin if he can't get anything fixed. Well you are lucky with
Microsoft support I've heard some not so good things about it. Then
again I know someone who works at Microsoft and use him for answers so
I've never had the pleasure of phoning them. My OSS problems tend to
disappear like magic when I susbscribe to the list of the specific
component causing trouble. This is not usually neccessay deu to man
pages, google & lug.<g>
> > There's something to be said for simple wizard based setup of systems
> > but it's also good to learn the system internals. It means you know
> > how it works, why it breaks and where to look to fix it.
>
> You can fiddle with the internals of a lot of Microsoft software -
> you just need to know where to look. And there are arguments to
> benefit it being better that you know where to look to make changes
> rather than having to look in those places to get started.
Windows registry? I must admit that the GL Lug is a lot less techncial
than the ones in South Africa where you can working config files doing
whatever it is you are trying to implement.
> We use Linux, We use Windows but ultimately the choice comes down to
> business requirements. We have a requirement to develop applications
> on and for Windows. Because of this and the complexity of our
> internal applications we're not in a position to use Linux across the
> board - however we use it where it benefits us, but not for cost. On
> that it remains relatively cost neutral.
Well I won't tell you to switch when it's not in your best interest to
do so but you might want to plan to get yourself into a position where
you have more control over the situation. I look forward to the day
when I can dictate policy that means no more anti-virus software and
far less license tracking, product keys, etc is necessary.<g>
cheers
Liam
--
Gllug mailing list - Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug
More information about the GLLUG
mailing list