Peter Köhlmann <peter.koehlmann@xxxxxxxxxxx> espoused:
> Mark Kent wrote:
>
>> Jim Richardson <warlock@xxxxxxxxxx> espoused:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On Sun, 30 Sep 2007 11:53:51 +0100,
>>> Mark Kent <mark.kent@xxxxxxxxxxx> wrote:
>>>> Roy Schestowitz <newsgroups@xxxxxxxxxxxxxxx> espoused:
>>>>> ____/ Jim Richardson on Sunday 30 September 2007 05:47 : \____
>>>
>>>>>
>>>>>> When OOrg on the distro you use can support ooxml, does that mean you
>>>>>> are locked it?
>>>>>
>>>>> No.
>>>>
>>>> Yes, it does, and as I keep pointing out, you are always locked-in to a
>>>> point, the question being the height of the exit barrier, ie., how much
>>>> will it cost.
>>>>
>>>> Jim seems unable to process this.
>>>>
>>>
>>> if *all* distros *all* lock you in, no matter what, then the term is
>>> meanigless, and Roy, singling out Linspire for that, is equally
>>> meaningless.
>>
>> It's not meaningless, but you're still failing to process the concept.
>> The issue is about the cost of exit. The cost can be minimised, or it
>> can be maximised. When maximised, it can (as has happened to me in my
>> day job) amount to millions.
>>
>> Surely you can see that some situations will be less expensive to exit
>> from than others?
>>
>
> By now I actually think that you are completely nuts and an imbecile
And yet you still reply - perhaps this is more of a clue about thee than
me?
>
> You are simply babbling incoherent idiocy with your "exit barriers" with
> regards to an "import filter" which actually enables to bypass those
> very "barriers"
I'm sorry that you are finding the concepts confusing; let me try to
explain it a different way:
1. Everything has an exit barrier. If nothing else, just the
opportunity cost alone (the oft-used how much is your time worth
argument).
2. Exit barriers can be artificially raised by the exploitation of
technological barriers. Technological barriers come in several forms,
and can be additive:
2.1 Proprietary protocols
2.2 Proprietary file formats
2.3 Proprietary, binary-only applications or modules
2.4 Restrictive licensing (eg., non-GPL-compliant)
They are all nasty. In this example, we're discussing the use of (2.3)
in order to try to solve problems caused by (2.2). Unfortunately, this
causes a particular type of lock-in, as follows:
3.1 Particular glibc version
3.2 Particular kernel version (because of libc issues)
3.3 Particular processor type
3.4 Particular hardware stack
Or, we might be discussing the use of (2.4) to resolve the problems
caused by (2.2). The results could well be much the same, but are
likely to include essentially the same set, as shown immediately above.
So, in order to minimise the lock-in, the proper route is to have
"import filters" which are subject to no licensing restrictions
whatsoever, and be distributed in a GPL-compliant form. I think it
unlikely that both these conditions are being met.
--
| 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 |
|
|
