<!-- retain these comments for translator revision tracking -->
<!-- Original version: $Revision: 1.20 $ -->
<chapt id="compat">Compatibility issues

<!-- FIXME add question on Ooo - MS Office compatibility -->

<sect id="arches">On what hardware architectures/systems does &debian; run?

<p>&debian; includes complete source-code for all of the included programs,
so it should work on all systems which are supported by the Linux kernel;
see the <url name="Linux FAQ" id="http://en.tldp.org/FAQ/Linux-FAQ/intro.html#DOES-LINUX-RUN-ON-MY-COMPUTER">
for details.

<p>The current &debian; release, &release;, contains a complete, binary
distribution for the following architectures:

<list>

<item><em/amd64/: this covers systems based on AMD 64bit CPUs with AMD64 extension
and all Intel CPUs with EM64T extension, and a common 64bit userspace.

<item><em/arm64/: supports the latest 64-bit ARM-powered devices.

<item><em/armel/: little-endian ARM machines.

<item><em/armhf/: an alternative to armel for ARMv7 machines with hard-float.

<item><em/i386/: this covers systems based on Intel and compatible processors,
including Intel's 386, 486, Pentium, Pentium Pro, Pentium II (both Klamath
and Celeron), and Pentium III, and most compatible processors by AMD, Cyrix
and others.

<item><em/ia64/: Intel IA-64 ("Itanium") computers.

<item><em/mips/: SGI's big-endian MIPS systems, Indy and Indigo2;
<em/mipsel/: little-endian MIPS machines, Digital DECstations.

<item><em/powerpc/: this covers some IBM/Motorola PowerPC machines, including
the Apple Macintosh PowerMac models, and the CHRP and PReP open architecture
machines.

<item><em/ppc64el/: 64-bit little-endian PowerPC port, supports several
recent PowerPC/POWER processors.

<item><em/s390x/: 64-bit port for IBM System z machines, replaced s390.

</list>

<p>The development of binary distributions of Debian for 
<em/hurd-i386/ (for GNU Hurd kernel on i386 32-bit PCs),
<em/mipsel64/ (for 64 bit MIPS in little-endian mode),
<em/powerpcspe/ (port for the "Signal Processing Engine" hardware),
<em/sparc64/ (for 64 bit SPARC processors),
<em/sh/ (for Hitachi SuperH processors), and
<em/x32/ (for amd64/x86_64 CPUs using 32-bit pointers)
is currently underway.

<p>Support for the <em/m68k/ architecture was dropped in the Etch (Debian 4.0) release, because
it did not meet the criteria set by the Debian Release Managers. This
architecture covers Amigas and ATARIs having a Motorola 680x0 processor for
x>=2; with MMU. However, the port is still active and available for
installation even if not a part of this official stable release and
might be reactivated for future releases.

<p>Support for the <em/hppa/ (Hewlett-Packard's PA-RISC machines) and
<em/alpha/ (Compaq/Digital's Alpha systems) were dropped
in the Squeeze (Debian 6.0) release for similar reasons. The
<em/arm/ was dropped too in this release, as it was superseded by 
the <em/armel/ architecture.

<!-- info from Jessie Release Notes -->
<p>Support for the 32-bit <em/s390/ port (s390) was discontinued and replaced
with s390x in Jessie (Debian 8). In addition, the ports to IA-64 and
Sparc had to be removed from this release due to insufficient developer
support.

<p>For more information on the available ports see the
<url id="http://www.debian.org/ports/" name="ports pages at the website">.

<p>For further information on booting, partitioning your drive, enabling
PCMCIA (PC Card) devices and similar issues please follow the instructions
given in the Installation Manual, which is available from our WWW site at
<url id="http://www.debian.org/releases/stable/installmanual">.

<sect id="kernels">What kernels does &debian; run?

<p>Beside Linux, Debian provides a complete, binary distribution for the
 following operating system kernels:

<list>

<item>FreeBSD: provided through the <em/kfreebsd-amd64/ and
<em/kfreebsd-i386/ ports, for 64-bit PCs and 32-bit PCs respectively.  These
ports were first released in Debian 6.0 Squeeze as a <em/technology preview/.
However they were not part of the Debian 8 Jessie release.
</list>


<p>In addition to these, work is in progress on the following adaptations:

<list>

<item><em/avr32/, port to Atmel's 32-bit RISC architecture,

<item><em/hurd-i386/, a port for 32-bit PC. This port will use GNU Hurd, the new
operating system being put together by the GNU group,

<item><em/sh/, port to Hitachi SuperH processors.

</list>

<p>There were attempts to port the distribution to the NetBSD kernel,
providing <em/netbsd-i386/ (for 32-bit PCs) and <em/netbsd-alpha/ (for Alpha
machines) but these ports were never released and are currently abandoned.

<p>For more information on the available ports see the
<url id="http://www.debian.org/ports/" name="ports pages at the website">.


<sect id="otherdistribs">How compatible is Debian with other distributions
                         of Linux?
	
<p>Debian developers communicate with other Linux distribution creators
in an effort to maintain binary compatibility across Linux distributions.
Most commercial Linux products run as well under Debian as they do on the
system upon which they were built.

<p>&debian; adheres to the <url name="Linux Filesystem Hierarchy
Standard" id="http://www.pathname.com/fhs/">. However, there is room for
interpretation in some of the rules within this standard, so there may be
slight differences between a Debian system and other Linux systems.

<p>&debian; supports software developed for the <url
id="http://www.linuxbase.org/" name="Linux Standard Base">.  The LSB is a
specification for allowing the same binary package to be used on multiple
distributions.  The Debian Etch release is certified for LSB Release 3.1, see
the <url name="Linux Foundation Certification webpage"
id="https://www.linux-foundation.org/lsb-cert/productdir.php">.
Discussion and
coordination of efforts towards ensuring Debian meets the requirements of the
Linux Standard Base is taking place on the <url
id="http://lists.debian.org/debian-lsb/" name="debian-lsb mailing list">.

<sect id="otherunices">How source code compatible is Debian with other
  Unix systems?
	
<p>For most applications Linux source code is compatible with other Unix
systems. It supports almost everything that is available in System V Unix
systems and the free and commercial BSD-derived systems. However in the Unix
business such claim has nearly no value because there is no way to prove it.
In the software development area complete compatibility is required instead
of compatibility in "about most" cases. So years ago the need for standards
arose, and nowadays POSIX.1 (IEEE Standard 1003.1-1990) is one of the major
standards for source code compatibility in Unix-like operating systems.

<p>Linux is intended to adhere to POSIX.1, but the POSIX standards cost real
money and the POSIX.1 (and FIPS 151-2) certification is quite expensive;
this made it more difficult for the Linux developers to work on complete
POSIX conformance. The certification costs make it unlikely that Debian will
get an official conformance certification even if it completely passed the
validation suite. (The validation suite is now freely available, so it is
expected that more people will work on POSIX.1 issues.)

<!-- <p><strong>(The authors would very much like to give you a pointer to
an on-line document that described that standard, but the IEEE is another
one of those organizations that gets away with declaring standards and then
requiring that people PAY to find out what they are.  This makes about as
much sense as having to find out the significance of various colored lights
on traffic signals.)</strong> -->

<p>Unifix GmbH (Braunschweig, Germany) developed a Linux system that has
been certified to conform to FIPS 151-2 (a superset of POSIX.1). This
technology was available in Unifix' own distribution called Unifix
Linux 2.0 and in Lasermoon's Linux-FT.
<!-- I had to comment this out for obvious reasons... SVD
 <url name="Linux-FT" url="http://www.lasermoon.co.uk/linux-ft/linux-ft.html">.
Currently Unifix merges its patches into the Linux kernel, gcc and other
tools; so it is expected that their fixes towards POSIX.1 conformance will
be available in Debian (and other distributions).
-->

<!-- TODO: explain better how to unpack .debs onto non-Debian systems -->
<sect id="otherpackages">Can I use Debian packages (".deb" files) on my
  Red Hat/Slackware/... Linux system? Can I use Red Hat packages (".rpm"
  files) on my &debian; system?

<p>Different Linux distributions use different package formats and different
package management programs.

<taglist>
<tag><strong/You probably can:/
  <item>A program to unpack a Debian package onto a Linux host that is been
  built from a `foreign' distribution is available, and will generally work,
  in the sense that files will be unpacked.  The converse is probably also
  true, that is, a program to unpack a Red Hat or Slackware package on a host
  that is based on &debian; will probably succeed in unpacking the package
  and placing most files in their intended directories.  This is largely a
  consequence of the existence (and broad adherence to) the Linux Filesystem
  Hierarchy Standard.
  The <url name="Alien" id="http://packages.debian.org/alien"> package is
  used to convert between different package formats.

<tag><strong/You probably do not want to:/
  <item>Most package managers write administrative files when they
  are used to unpack an archive.  These administrative files are generally
  not standardized.  Therefore, the effect of unpacking a Debian package
  on a `foreign' host will have unpredictable (certainly not useful) effects
  on the package manager on that system.  Likewise, utilities from other
  distributions might succeed in unpacking their archives on Debian systems,
  but will probably cause the Debian package management system to fail when the
  time comes to upgrade or remove some packages, or even simply to report
  exactly what packages are present on a system.

<tag><strong/A better way:/
  <item>The Linux File System Standard (and therefore &debian;) requires that
  subdirectories under <tt>/usr/local/</tt> be entirely under the user's
  discretion.  Therefore, users can unpack `foreign' packages into this
  directory, and then manage their configuration, upgrade and removal
  individually.
</taglist>

<!-- It would be useful to document all the ways in which Debian and Red Hat
systems differ.  I believe such a document would do a lot to dispell
fears of using a Unix system. SGK -->

<sect id="non-debian-programs">How should I install a non-Debian program?
	
<p>Files under the directory <tt>/usr/local/</tt> are not under the control
of the Debian package management system.  Therefore, it is good practice
to place the source code for your program in /usr/local/src/.  For example,
you might extract the files for a package named "foo.tar" into the directory
<tt>/usr/local/src/foo</tt>.  After you compile them, place the binaries
in <tt>/usr/local/bin/</tt>, the libraries in <tt>/usr/local/lib/</tt>,
and the configuration files in <tt>/usr/local/etc/</tt>.

<p>If your programs and/or files really must be placed in some other
directory, you could still store them in <tt>/usr/local/</tt>,
and build the appropriate symbolic links from the required location
to its location in <tt>/usr/local/</tt>, e.g., you could make the link
<example>ln -s /usr/local/bin/foo /usr/bin/foo</example>

<p>In any case, if you obtain a package whose copyright allows
redistribution, you should consider making a Debian package of it, and
uploading it for the Debian system.  Guidelines for becoming a package
developer are included in the Debian Policy manual (see <ref id="debiandocs">).

<sect id="termcap">Why can't I compile programs that require libtermcap?
	
<p>Debian uses the <tt>terminfo</tt> database and the <tt>ncurses</tt>
library of terminal interface routes, rather than the <tt>termcap</tt>
database and the <tt>termcap</tt> library.

<p>The low-level <tt>terminfo</tt> library has been split out from the general
<tt>ncurses</tt> library, making a new package called <tt>libtinfo5</tt>.
<tt>libncurses</tt> is linked to <tt>libtinfo</tt>, so users who are compiling
programs that require some knowledge of the terminal interface should replace
references to <tt>libtermcap</tt> with references to <tt>libncurses</tt>.

<p>To support binaries that have already been linked with the <tt>termcap</tt>
library, and for which you do not have the source, you will have to find the
library source and compile it yourself. Debian used to provide a package called
termcap-compat which contained both <tt>libtermcap.so.2</tt> and
<tt>/etc/termcap</tt>, but this was removed from the distribution in 2005.

<sect id="accelx">Why can't I install AccelX?
	
<p>AccelX uses the <tt>termcap</tt> library for installation. See
<ref id="termcap"> above.

