[Gllug] is this a big problem?

[Mike Brodbelt]

Matthew Thompson wrote:

> 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.

I have rarely had cause to alter source code for Linux software to fix
problems. I have however found access to said source invaluable for
diagnosing awkward problems. The ability to grep through the source tree
for a package (and with debian, to know that source corresponds to what
you're running) looking for the origin of an error message I've seen in
the logs has been invaluable on occasion.

> 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.

That assumes that the only advantage provided by access to code is the
ability to change that code. I don't think that's the primary benefit,
and where I have changed things, those changes could be easily reproduced.

> 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.
> 
> 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.

Friends of mine who work at banks seem to spend most of their time
trying to sort out problems with "100% compatible" applications. The
notion of 100% compatibility in this industry is almost entirely
fallacious. Banks and large customers have enough leverage with
manufacturers to get stuff fixed. Small customers don't - open source
allows the small guys to exercise the same level of control over their
software that the banks get by virtue of having a budget of millions.

> 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.

With Windows you will always be a passenger. With open source solutions,
you have at least some choice as to where you're going. It's not
perfect, and there are some arrogant groups of developers out there who
seem to enjoy ignoring their users, but it's definitely better.

> You can fiddle with the internals of a lot of Microsoft software -  
> you just need to know where to look.

I disagree with that statement - the ability to change the settings they
saw fit to expose is not "fiddling with the internals".

> 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.

In Windows, you look in the registry in one of numerous places. On
Linux, you look in /etc, or /etc/<appname>, or for user settings, in
/home/<username>/.<appname>. I prefer the Linux way, especially because
it uses text based configs, and I have grep.

This of course excludes software like GNOME, which throws out years of
good practice in favour of intractable junk in random places, stored as
XML. This is every bit as bad (if not worse) than Windows.

> 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.

Developing software for Windows doesn't require writing to Win32 any
more. You can develop aps for the browser - AJAX looks like it could
actually deliver what Java promised years ago, but has consistently
failed to achieve. That might be the way of the future for business
applications.

Mike.
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug