[Gllug] An article for you from an Economist.com reader.

[Daniel P. Berrange]

On Wed, Jun 23, 2004 at 01:07:34PM +0100, Amias Channer wrote:
> On Wed, 23 Jun 2004 12:07:50 +0100
> Tethys <tet at createservices.com> wrote:
> > 
> > Amias Channer writes:
> > 
> > >> This seems to me to be a contradiction in terms. If your source is
> > >> freely available and modifiable, then where's your monopoly? (You
> > >> might have *most of the market*, but you have no monopoly lock.)
> > >
> > >So you don't use redhat in a production enviroment then ?
> > 
> > Yes, I do. Like Nix says, though, where's the monopoly lock?

The Linux Standarsd Base, in particular the file system standard
has made great progress in unifying many aspects of competing
distros. Many distros are now also sharing their high level packaging
tools (ie Yum & Apt) reducing lock in. Debian adopted anaconda
for installation elminating that major difference between RH and
Debian.

> I belive if you want to use oracle on redhat you are locked to certain
> distro versions and possibly even kernel version , also if you want to

This lock-in is from Oracle - they are the ones distributing the
closed source software. They are the ones who choose to distribute
.o files for which there is /no/ guarenteeed ABI compatability
across even minor libc releases, rather than .so files for which
there is compatability. Don't want lock-in here - then use PostgreSQL
of another free DB solutions.

> deploy perl applications on a production system you can only use the
> modules that they have rpm'ed or risk having to fight rpm with cpan
> and make your system hard to audit or re-create.

This is a bit of a bitch brought about because of the way Perl
chooses to deal with locating modules. Debian have patched their
version of Perl to make packaging 3rd party modules easier (ie
no need to overwrite managed modules from base Perl package).
Basically stock perl always chooses modules from base package
first, then looks in site & vendor directory trees. Debian
switched that so its order site, vendor, base. I've got an open
BugZilla to try and get future RH distros to adopt this patch
too. So yes its a bit of a lock in - but not a delibraate one
of the part of the vendor.

> This ammounts to a lockin because moving to another distro becomes
> difficult the more you develop your system.

This is the area Linux Standards are helping to address, but its
not a magic bullet. The only way to remove all barriers is to
make all distros the same - which kind of defeats the purpose.
Its all really about choice - you can decide which OS to adopt
and while switching OS / distro is never easy, at least if its 
open source, you will have hugely more choices.


Dan.
-- 
|=-            GPG key: http://www.berrange.com/~dan/gpgkey.txt       -=|
|=-       Perl modules: http://search.cpan.org/~danberr/              -=|
|=-           Projects: http://freshmeat.net/~danielpb/               -=|
|=-   berrange at redhat.com  -  Daniel Berrange  -  dan at berrange.com    -=|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
URL: <http://mailman.lug.org.uk/pipermail/gllug/attachments/20040623/22701fe2/attachment.pgp>
-------------- next part --------------
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug