implement an illumos uname

Issue #5 resolved
Garrett D'Amore repo owner created an issue

We need to set ourselves apart. Our tree is a good place to do it.

See http://wiki.illumos.org/display/illumos/Modernizing+Uname for more details about how this can be done.

We propose that instead of starting at 5.14.0, we start with the following:

uname -s "illumos" uname -r "0.1.<yyyymmdd>"

For example: 0.1.20140815

Its not immediately (to me at least) clear when we'll bump this to 1.0, but it will probably be when we have a working distribution, and a ready to present illumos-core to the greater illumos community. Its likely that we won't bother to bump the minor number until then.

Its unclear to me when we'll bump from 1.0, but it will probably be to 1.1, rather than 2.0. The 1.0 -> 2.0 transition type of time should probably be measured in units of decades rather than years or months.

We'll want the puname utility and the user flag to allow legacy applications to still get the old uname.

Note that for this first integration / effort, we should not change the default. Meaning, the compile time chosen default should leave uname -s -r at SunOS 5.11 for now.

Comments (8)

  1. Garrett D'Amore reporter

    Updates.

    uname -r -- 0.9.<x>

    <x> is the number f months since august 2010. (August 3, 2010 being illumos' birthday.)

    We are using 0.9 for now because 0.0 is ... ugly. And we want a micro number that isn't huge. After a few decades, 12 * 20 = only 240. That's quite manageable. We can reset the micro number when rolling minor numbers too. That can be decided for each minor number.

  2. Garrett D'Amore reporter

    Actually, let's change the default too. Its a pain to change it more than once.

    This affects zones, btw. sn1 should return SunOS 5.11, and solaris10 SunOS 5.10

  3. Log in to comment