on Sun, Jul 25, 2004 at 07:08:46AM -0700, Ryo Furue ([EMAIL PROTECTED]) wrote:
> "Karsten M. Self" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>...
> [...]
>
> I'm not sure whether I understand every point you make (I read your
> message twice but there are still points I don't understand), but I
> think I understand your main point: A binary distribution may not
> work on all Linuxes, but source distribution works because writing a
> portable code is not hard. That may be so.
Not quite.
We've got a few different issues going on here:
- Linux support.
- Multi-distro Linux support
- Multi-arch Linux support.
- Cross platform development.
- Binary distribution.
- Source distribution.
- Support-as-in-runs vs. support-as-in-service
Linux support is where an application runs on Linux -- some Linux,
without specificity as to distribution or architecture. Architecture
("arch") refers to x86/i386, SPARC, IA64, PPC, MIPS, etc. CPU
architecture.
Multi-distro and multi-arch support is wher an application can be run on
more than one distribution and/or architecture.
Cross-platform development is the practice of designing and building
applications for multiple platforms. Eg: Legacy MS Windows _and_ Mac
OS X. Or multiple proprietary Unices. Or GNU/Linux, FreeBSD, NetBSD,
and OpenBSD.
Binary distribution is release by the vendor of binary-only builds of a
product.
Source distribution is the alternative: releasing source code which can
be built by others. Source distribution is *not* the same as FSF free
software / OSI open source. All FS/OS includes source distribution.
Not all source-distributed software is FS/OS.
Support-as-in-runs & support-as-in-service are two wildly different
issues. Unfortunately, English doesn't provide a good word or term to
distinguish between them easily, and usage can be confusing. Basically,
the distinction is between applications which are known to run
successfully with minimal configuration issues, on given platforms
(support-as-in-runs), vs. the vendor providing some form of end-user
support, service-level agreement, on-site service, or other level of
committed service.
Depending on the specifics of an organization, this distinction may or
may not be significant. If you're comfortable running an application
without specific vendor assistance, you may not care. If the
application is sufficiently critical to the organization, and operation
sufficiently sensitive to system differences, you may opt to stick with
the supported configuration only.
> You said that I was moving the goalpost.
I'm referring to the "support-as-in-runs" and "support-as-in-service"
distinction.
> I think you said so because I didn't make a clear distinction between
> a source distribution and a binary one.
No. See above.
> But, if writing a portable code is not hard, why commercial vendors
> write a portable code, compile it for all Unixes/Linuxes, and
> distribute the binaries? Taking my example, why doesn't Intel compile
> their code not only for RedHat, but also for other distributions? I
> understand that they don't want to give away their source code, but at
> least they can distribute binaries for different Linuxes.
I detailed this in some depth in another response to this thread.
Basically: business decisions are driven by more than merely technical
considerations, for better or worse.
It is important to note that when you opt to go with a closed-source
solution, you are implicitly limiting yourself to those distribution
choices the proprietor of the code is willing to allow.
Frequently, vendors argue against source distribution on the part of
trade secrets. Particularly in the area of hardware drivers. You could
view Intel's compiler as a very special case of a device driver, where
the device in question is the CPU.
> I *guess* that doing so would incur some cost which the vendor doesn't
> want to pay. If Debian had as large a share as RedHat, they would see
> the cost worth.
That's part of the issue, but _only_ part. Debian is pretty comperable
to RH, though lagging slightly.
> By the way, I'm not much interested in a debate on whether
> closed-source is a good idea or not. At least, not for this thread.
While I can understand your desires here, the issues aren't seperable.
Proprietary vs. free distribution inherently drives additional dynamics.
> I didn't quote your words because I did't think I can answer you point
> by point. Please let me know if I missed something important.
A few things.
Again, I'd recommend you look at the "Free Software Primer" link.
Peace.
--
Karsten M. Self <[EMAIL PROTECTED]> http://linuxmafia.com/~karsten
Ceterum censeo, Caldera delenda est.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
