illumos core vision

gdamore edited this page Nov 10, 2014 · 1 revision
Clone this wiki locally


illumos-core represents my vision of the future for illumos.

It is a true fork of illumos-gate, but we remerge back in from upstream frequently.

One of the "super goals" of this project is to facilitate distributors who want to integrate illumos-core into different projects, including use cases like appliances and traditional operating system distributions.

Standards Compliant

Our goal for illumos is to be compliant with recent POSIX.1 (IEEE 1003.1) and Single Unix Specification (SUS) standards. Specifically, we desire conformance with SUSv3, and we retain conformance with standards going back to SUSv1 / XPG4.2. Older standards, such as POSIX.1-1988 or -1990, are only supported to the extent that such standards are part of the newer ones. (Note that this is a substantial departure from upstream illumos and Solaris, which continue to claim conformance to POSIX.1-1990, POSIX.2, and so forth.)


We believe it should be possible to "self-host" this repository -- that is that it shall be possible to compile illumos-core while running illumos-core itself.


As much as possible, illumos-core should be self-contained. In an ideal world, it should be possible to achieve all the other goals without adding additional 3rd party components. This is difficult, and may ultimately not be achievable, but as a goal, changes should tend towards this. (Note that this means that someday it would be desirable if we had our own compilers and build tools in our code base, much like the BSDs do.)


Self tests allow for test-driven development, and furthermore allow for us to validate the quality of our software, as well as conformance to standards and reducing the likelihood of introducing regressions. Therefore the code should be testable, and self-tests should be supplied as new code is developed or bugs are fixed. These tests should exist in-tree whenever practical, and should be executed automatically on a periodic basis.


The illumos-core code base today supports x86, amd64, and sparcv9 systems. Portability to other architectures is a goal, and we should retain sparcv9 support at least until another platform (preferably big-endian) becomes available. This doesn't mean we would necessarily drop sparcv9 at the first such opportunity -- but it does put a minimum lower constraint before that should be contemplated. In the meantime, we should investigate use of options like qemu to help ensure that our goals are being met consistently across architectures.


The illumos-gate code base has a great deal of code that is legacy or can serve no useful purpose in a modern system (e.g. wireless USB support - WUSB). There is also code in illumos-gate which is not really intrinsic to illumos, but resides in illumos from historical accident rather than any design requirement or standards conformance requirement (e.g. audioplay). These things increase bloat, and make the code base harder to work with. We elect to remove these from illumos-core. Where things may have value to other distributions, they should be placed in separate consolidations (mini-consolidations) so that distributions may continue to build and integrate them with a minimum of fuss.


The historic illumos and Solaris attitude is slavish compatibility to legacy software built for Solaris. We believe this has been followed to an ultimately harmful end, where such compatibility makes it incompatible with other more widely used systems (e.g. Linux). In some cases, this slavish adherence to the legacy is done in contravention of modern standards. We reject this approach, and instead choose to make (judiciously) changes that make our platform more compatible with open standards, both formal (POSIX) and de facto (Linux). This is not to say that we should throw away compatibility with Solaris lightly -- indeed in most cases we can make changes that do not break the ABI, allowing the vast majority of programs developed for Solaris to continue to run. At the API level, where folks have source code, we can be a little more relaxed, but we should be cautious that many folks who receive software in source code form are not themselves programmers.


Historically illumos has identified ourselves as SunOS 5.11 in our uname. This is a lie. We have never been SunOS 5.11, nor will we ever be. In fact, its clear that illumos is no longer reasonably SunOS, and we believe our strict adherence to that name is actively harmful -- in fact it has in some ways been the exemplar of the compatibility strategy followed by illumos-gate. So, as we reject that strategy, so do we reject the legacy SunOS uname, instead preferring to identity ourselves as "illumos" proper. Note that as we believe that this approach represents the true future of illumos, we are happy with our choice. (Our versioning strategy will be elucidated later.)

Tracking Upstream

We recognize that at least initially, the vast majority of contributions from commercial contributors will come into the upstream illumos-gate. We believe that these contributions are valuable. Furthermore, because of illumos' requirement that changes be acceptable to everyone, they are unlikely to be contentious. So we closely follow upstream, merging frequently, allowing illumos-core to benefit from this upstream. This also will facilitate cherry-picking of changes from illumos-core for integration back into the upstream, should upstream contributors decide to do so.

Releases & Versions

We believe that downstreams -- distributors in particular -- would benefit from having regular releases of the code base, much as Linux, FreeBSD, and so forth do. As we make changes that affect public interfaces, this also allows us to make promises (Interface Stability) that have meaning to consumers. We believe semantic versioning is useful, although its unclear that a full semver approach is necessary. For now, illumos-core versions are numbered with a major.minor.micro, where the major.minor follows semantic versioning (0.9 at present), and the micro is based on the date (number of months since August 2010). Future versions may revisit this, of course. Notably, the releases allow tests to be performed and tracked, and quality metrics to be applied to facilitate decision making by distros. They also allow for maintenance or stabilization branches to be made, to facilitate the needs of the community that would be harder to achieve in a strictly monotonically increasing git repository. These releases are also dependent upon and supportive of the Self-Testing goal previously described.


The illumos-gate is run by bazaar, requiring full consensus for any meaningful change. We believe that this strongly favors the status quo, making change difficult to achieve, and basically preventing any kind of common vision from taking place, as there are too many stakeholders with different goals. So we reject that approach, instead opting for a cathedral approach. In this instance, the project will have a BD to whom ultimate authority for decisions regarding the source code will fall. The BD mantle may pass, but only upon the decision of the BD or the departure of the BD from the project (by death or otherwise). (TBD: how does a new BD get chosen in that case?) However, the BD may appoint assistants to facilitate day to day integrations and decision making, and generally run the project -- it is also expected that these assistants will act in an advisory capacity when decisions concerning the direction or future of the project are contemplated. We recognize that investing absolute control in a single authority figure will be difficult for some people to accept, but we believe that this is better than being stuck in a morass of indecision which is the result of governance by committee. (And people are free to fork the code base at any time should they object to the leadership of this project.) The initial BD shall be Garrett D'Amore, the project founder.