Supported platforms

This page represents an official policy of the MIT Kerberos project. Edit this page only in accordance with changes agreed by the community; other changes will be reverted.

Extent of support

The word "support" here does not mean that the MIT Kerberos Team in any way provides commercial-grade end-user support for MIT Kerberos. This list of platforms is subject to change at any time, but we will make an effort to follow the principles described in the Rationale. Input from Consortium Sponsors will affect the list of supported platforms, particularly if a sponsor contributes resources (staff expertise, equipment, etc.) for that platform.

This list of supported platforms reflects our priorities for the functionality and portability of the cross-platform source code product. Special platform-specific products such as Kerberos for Windows (KfW) and Kerberos for Macintosh (KfM) are not addressed here.

A platform's appearance on the support list indicates that we will treat problems on that platform with the highest priority relative to problems on other platforms. It indicates the amount of resources that the MIT Kerberos Team is willing to expend to resolve such problems. Platforms not on the support list receive a lower priority. For example, a platform-specific problem reported on an unsupported platform will get preemptively closed unless accompanied by a very well-written patch that poses negligible integration cost for us.

On the supported platforms, we expect that the code on the git master branch will normally build and function correctly. Where a supported platform is a family of platforms, (e.g., Linux, BSD) the MIT Kerberos Team may not have daily access to, or expertise with, every specific member of that family of platforms. For problems peculiar to a mainstream member of a family of supported platforms, but not present on a specific platform for which we have equipment or expertise, we will expend more effort working with the originator of a problem and with the Kerberos community to reach a solution than we would for an unsupported platform. Problems that relate to a specific CPU architecture on a supported platform, even a CPU architecture that we lack access to, will receive higher priority than CPU-architecture dependencies on unsupported platforms.

Supported platforms

• Mac OS X, specifically a "Darwin" command-line build treating the OS as a typical UNIX platform, but potentially using some features specific to Mac OS X. This is not the same as OpenDarwin.
• GNU/Linux (as an OS family; currently Debian, Ubuntu, or Red Hat on x86_64 and x86)
• Solaris (SPARC or x86_64/x86)
• BSD (as an OS family; currently NetBSD on x86_64 and x86)

Generally we use gcc on these platforms, but will also use Sun Workshop compilers on Solaris to achieve compiler diversity.

The specific operating system releases we use will vary, but will typically be a formal release no more than two or three years old. Under some circumstances, the specific operating system release will reflect MIT-specific concerns such as which release is currently used in the MIT Athena environment.

Rationale

CPU architecture

Most x86 or x86_64 platforms except Mac OS X client can run on a virtualized host. If we want to aggressively minimize physical hardware, we need only retain a small number of virtualization x86 hosts and a possibly larger amount of Mac and SPARC hardware.

We desire a certain breadth of CPU architecture coverage to detect regressions related to byte order issues or word size issues.

Our desired CPU architecture coverage is:

{ 32-bit, 64-bit } x { big-endian, little-endian }

and can be most easily achieved by:

• SPARC (big-endian 32-bit and 64-bit (on v9))
• x86_64 (little-endian 64-bit)
• x86 (little-endian 32-bit; subset of x86_64)

Strict alignment vs non-strict alignment is also useful to test, but not enough to justify another full axis to the coverage matrix. Currently, SPARC gives us the benefit of having strict alignment, while x86 is non-strict. Additional factors such as fixed-size instruction word vs variable-size instruction word are not worth additional effort at this time.

Desired OS flavors

• Mac
• Windows (not directly addressed in this article)
• System V
• GNU/Linux
• BSD

Retaining coverage of more "pure" System V derived OSes would be nice, but these are generally OSes that pose significant porting difficulties (e.g. HP-UX). We think that Solaris is sufficiently close to System V lineage for our purposes.

Portability assumptions

We generally make some assumptions about the capabilities of the platforms we are willing to support. See the main portability assumptions page for details.