Roy Schestowitz <newsgroups@xxxxxxxxxxxxxxx> espoused:
> Kernel and filesystem talks at OLS day two
>
> ,----[ Quote ]
>| Mathur asked why not XFS or an entirely new filesystem? Largely, she
>| explained, because of the large existing Ext3 community. They would be able
>| to maintain backward compatibility and upgrade from Ext3 to Ext4 without the
>| lengthly backup/restore process generally required to change filesystems. The
>| XFS codebase, she says, is larger than Ext3's. A smaller codebase would be
>| better.
> `----
>
> http://www.linux.com/feature/115767
>
This is a really good example of lock-in, in that the exit barrier
is technical. If the maintainers of ext3 give up, or make migration
difficult to a next version, then anyone running, say, several hundred
datacentres with several thousand servers would have a huge exit cost
on their hands, with all the complexity, risks of data-loss, procedural
and manpower problems involved in making a change, should they need or
wish for some feature in a subsequent system.
Worse, if ext3 be abandoned, ext4 introduced but in a non-compatible way,
then sooner or later, the datacentres will have no choice but to change,
if nothing else, because their support organisations will not be able
to guarantee security on old kernels, for example.
The advantage you have with open-source rather than binary solutions is
that you have an additional option, which is that you can pay someone
to maintain the existing code-base yourself, which means that you are
not over someone else's barrel.
Now, imagine a situation where, rather than an open filesystem driver,
a closed one had been used, or, worse still, a binary driver to a RAID
array controller, and the vendor didn't wish to provide upgrades after
a certain point, or went out of business, say. Now you have a *huge*
problem, you have *no choice* but to replace thousands of cards at least,
along with find new vendors, and test, swapout, transfer data and so on.
This is how lock-in works, and binary drivers in a kernel are potentially
extremely risky, at least when most people do not understand how to
quantify or to mitigate risk.
One method is to use multiple suppliers, and that can help /to a
point/, but even then, if the underlying cause is, for example, reduced
availability of a driver chip, then that probably won't help a great
deal, but you should, in principle, but over more than one barrel,
although each one is smaller.
You can take that argument further still and have several vendors, which
is my favoured approach when dealing with technically locked devices of
one kind or another, however, this brings two further problems, firstly,
you need to integrate your systems against multiple combinations of
capability, and if you have thousands of nodes (as I have) that in itself
can be quite complex, furthermore, you get a new logistics problem. In my
case, I have thousands of sites in the UK, plus thousands scattered /all
over the planet/. The more vendors you have, the more your logistics
becomes expensive - 3 vendors means 3 spare cards in every spares
location, rather than just one. That is *3* times more expensive.
/This/ is why open-source solutions are better - they are considerably
less expensive because they mitigate risk in ways which proprietary
(binary) solutions cannot. This isn't FUD, it's my real day job.
--
| Mark Kent -- mark at ellandroad dot demon dot co dot uk |
| Cola faq: http://www.faqs.org/faqs/linux/advocacy/faq-and-primer/ |
| Cola trolls: http://colatrolls.blogspot.com/ |
| My (new) blog: http://www.thereisnomagic.org |
|
|
