[Gllug] is this a big problem?

[Nix]

On Sat, 27 Aug 2005, Mike Brodbelt moaned:
> 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.

Indeed. And when there *is* a bug, the ability to *fix* it is also
invaluable :) not that I'm expecting random people to be able to fix
bugs in something huge like Mozilla or GCC, but you can often at least
isolate bugs and send a bug report off. You tend to get fixes rather
fast if you can point to a specific patch causing trouble :)

But the transparency is probably even more critical when the brown stuff
hits the rotating blades, and the ability to shove misbehaving code
under a debugger or under valgrind.

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

Unless the changes were enormous or to rapidly-changing code, the answer
to this question will invariably be `no'.

(In any case, if you're hacking at the code to something in a way that's
large enough to cause third parties to kill support contracts, you'd
better know it well enough that the only time you'll need support for it
is when you've hit a really serious wall --- or when you're off sick or
on holiday.)

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

Exactly. Upstream normally knows how to use diff and patch, and if they
don't, you probably shouldn't be trusting them as a source of support :)

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

Indeed. Most of these compatibility problems turn out to be due to
bespoke changes rammed into the apps at the insistence of these same
banks :/ having that much leverage is *definitely* a double-edged sword,
and they keep on cutting themselves with it.

(To the banks, `bespoke' means `excellent'. To the banks' software
suppliers, it means `oh crap, not again'.)

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

Indeed, and this time because they make the changes themselves, they
can hire whosoever they want to make future changes or fixes. Do that
with software from a single source (i.e., any proprietary stuff).

>                                                         It's not
> perfect, and there are some arrogant groups of developers out there who
> seem to enjoy ignoring their users

Unless those developers are working on something really critical (like
glibc :( ) they will get outcompeted by those who are nice to their
users, and who turn those users into codevelopers. :)

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

Indeed. That's customization, a quite different thing. I'm adding some
DCOP interfaces to some KDE software that hasn't got what I need at the
moment: could you add a new VBA function to Excel if you wanted it?

(Oops, no.)

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

... and glimpse, and htdig, and beagle, and a myriad of very fast search
tools. :)

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

Nah: you can still grep .gnome and .gconf and/or .kde/share :) and
fundamentally gconf storage is as plain-text files (unless you change
the backend to something like the berkeley db one). So it's still
greppable.

It's still much better than the Windows approach.

-- 
`... published last year in a limited edition... In one of the
 great tragedies of publishing, it was not a limited enough edition
 and so I have read it.' --- James Nicoll
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug