[Context] new Open Solaris support
Hello, we just got new binaries for Open Solaris (on intel) from Michael Krauß. (Many thanks.) On TL their name is i386-solaris (uname returns solaris), the current name that Hans suggested a while ago is sunos-intel. We started with "sun" (sparc-solaris on TL), but that doesn't work at the moment. What name do you suggest for the two architectures? (I'm thinking about renaming sunos-intel into solaris-intel.) Thanks, Mojca
On TL their name is i386-solaris (uname returns solaris), the current name that Hans suggested a while ago is sunos-intel. We started with "sun" (sparc-solaris on TL), but that doesn't work at the moment.
solaris-intel, in that order (to match osx-intel, etc.). SunOS has a slightly older tune to it, since it's the name that Sun used for its OS, before it was changed to Solaris (about 15 years ago, and clearly we are not going to support that). Arthur
Arthur Reutenauer wrote:
On TL their name is i386-solaris (uname returns solaris), the current name that Hans suggested a while ago is sunos-intel. We started with "sun" (sparc-solaris on TL), but that doesn't work at the moment.
solaris-intel, in that order (to match osx-intel, etc.). SunOS has a
I agree with that. I would have preferred "i386" instead of "intel" and "linux-i386" instead of "linux" and "linux-x86_64" instead of "linux-64" but it is I assume it is too late to change that now? Best wishes, Taco
On Thu, Nov 27, 2008 at 12:10 AM, Arthur Reutenauer wrote:
On TL their name is i386-solaris (uname returns solaris), the current name that Hans suggested a while ago is sunos-intel. We started with "sun" (sparc-solaris on TL), but that doesn't work at the moment.
solaris-intel, in that order (to match osx-intel, etc.). SunOS has a slightly older tune to it, since it's the name that Sun used for its OS, before it was changed to Solaris (about 15 years ago, and clearly we are not going to support that).
Just one more thing ... uname -s returns SunOS? Why does TeXLive use solaris then? (I was confused by the latter.) On Thu, Nov 27, 2008 at 9:29 AM, Taco Hoekwater wrote:
I would have preferred "i386" instead of "intel" and "linux-i386" instead of "linux" and "linux-x86_64" instead of "linux-64" but it is I assume it is too late to change that now?
The price to pay would be one broken update procedure. The names seemed a bit weird (too long) to me, that's all. We kept the names that Hans had (back then when there was still only support for both flavours of linux, windows and mac) Apart from linux no uname value made sense. Windows has none, and I bet that many Mac owners have never heard of Darwin. I do not favor those weird names for linux, but if more people say that we should use them, I have no problem with that. One thing that is a bit weird is that those strings (linux-64 osx-intel etc.) are hardcoded in luatex, if I remember correctly. (I might be wrong.) At that level they should indeed better be called linux-i386. But I should check again to remember all the details of past discussions. Mojca
Mojca Miklavec wrote:
On Thu, Nov 27, 2008 at 12:10 AM, Arthur Reutenauer wrote:
On TL their name is i386-solaris (uname returns solaris), the current name that Hans suggested a while ago is sunos-intel. We started with "sun" (sparc-solaris on TL), but that doesn't work at the moment. solaris-intel, in that order (to match osx-intel, etc.). SunOS has a slightly older tune to it, since it's the name that Sun used for its OS, before it was changed to Solaris (about 15 years ago, and clearly we are not going to support that).
Just one more thing ... uname -s returns SunOS? Why does TeXLive use solaris then? (I was confused by the latter.)
What is now called Solaris used to be called SunOS, but it was initially more a new name than a new design. Some versions of the system even had double names, iirc, a bit like OSX and Darwin. The output of uname() is used by programs, so it was probably left unchanged for compatibility reasons.
The names seemed a bit weird (too long) to me, that's all. We kept the names that Hans had (back then when there was still only support for both flavours of linux, windows and mac) Apart from linux no uname value made sense. Windows has none, and I bet that many Mac owners have never heard of Darwin.
Sure, I was just a tad unhappy about the chip architecture names, because "i386" are not the only chips made by Intel and chips for that platform are also made by AMD, etc. But it is not very important, and you are right that users will probably not know the official names anyway.
One thing that is a bit weird is that those strings (linux-64 osx-intel etc.) are hardcoded in luatex, if I remember correctly. (I might be wrong.) At that level they should indeed better be called linux-i386. But I should check again to remember all the details of past discussions.
"Hans-style" platform names are available as the variable os.name, and there is os.type, and there is also a working os.uname function (even on windows). os.type can be: "windows", "msdos", "unix" os.name can be: "windows", "msdos", "bsd", "sysv", "generic", "linux", "freebsd", "openbsd", "solaris", "sunos", "hpux", "irix", "macosx" The names "bsd", "sysv" and "generic" are used for otherwise undetermined flavors of unix. Best wishes, Taco
On Thu, Nov 27, 2008 at 10:30 AM, Taco Hoekwater
Mojca Miklavec wrote:
On Thu, Nov 27, 2008 at 12:10 AM, Arthur Reutenauer wrote:
On TL their name is i386-solaris (uname returns solaris), the current name that Hans suggested a while ago is sunos-intel. We started with "sun" (sparc-solaris on TL), but that doesn't work at the moment. solaris-intel, in that order (to match osx-intel, etc.). SunOS has a slightly older tune to it, since it's the name that Sun used for its OS, before it was changed to Solaris (about 15 years ago, and clearly we are not going to support that).
Just one more thing ... uname -s returns SunOS? Why does TeXLive use solaris then? (I was confused by the latter.)
What is now called Solaris used to be called SunOS, but it was initially more a new name than a new design. Some versions of the system even had double names, iirc, a bit like OSX and Darwin.
The output of uname() is used by programs, so it was probably left unchanged for compatibility reasons.
OK, so I'll keep solaris then.
The names seemed a bit weird (too long) to me, that's all. We kept the names that Hans had (back then when there was still only support for both flavours of linux, windows and mac) Apart from linux no uname value made sense. Windows has none, and I bet that many Mac owners have never heard of Darwin.
Sure, I was just a tad unhappy about the chip architecture names, because "i386" are not the only chips made by Intel and chips for that platform are also made by AMD, etc.
Eeeeeem ... mea culpa. That's right. I was a bit biased by Macs. In Mac word the official distinction between processors is "ppc"/"powerpc" vs. "intel" (nobody says i386; maybe also because 64-bit machines still claim to be "i386"). I agree that solaris-intel is not the right name. In the mac world "intel" comes with a reason. Under solaris it does not make too much sence. (For macs we actually provide universal binaries as well, but we did not make the switch [yet].) solaris-i386? Some other proposals?
But it is not very important, and you are right that users will probably not know the official names anyway.
One thing that is a bit weird is that those strings (linux-64 osx-intel etc.) are hardcoded in luatex, if I remember correctly. (I might be wrong.) At that level they should indeed better be called linux-i386. But I should check again to remember all the details of past discussions.
"Hans-style" platform names are available as the variable os.name, and there is os.type, and there is also a working os.uname function (even on windows).
os.type can be: "windows", "msdos", "unix"
os.name can be: "windows", "msdos", "bsd", "sysv", "generic", "linux", "freebsd", "openbsd", "solaris", "sunos", "hpux", "irix", "macosx"
The names "bsd", "sysv" and "generic" are used for otherwise undetermined flavors of unix.
Where luatex probably wouldn't compile anyway :) :) :) [just joking] Thanks for the warning, Mojca
I agree that solaris-intel is not the right name. In the mac world "intel" comes with a reason. sence.
Are you saying we should use "osx-intel", but "solaris-i386"? That would be absurd. In any case, we must use the same processor name for all the platforms that run on it.
Under solaris it does not make too much sence.
Why? For Sun, the duality Sparc / Intel is just as much advertised as is PowerPC / Intel for Apple. Arthur
Arthur Reutenauer wrote:
I agree that solaris-intel is not the right name. In the mac world "intel" comes with a reason. sence.
Are you saying we should use "osx-intel", but "solaris-i386"? That would be absurd. In any case, we must use the same processor name for all the platforms that run on it.
How about: intel == i386 amd64 == x86_64 (and just forget about ia64 == itanium) and then: freebsd freebsd-intel linux-64 linux-amd64 linux-ppc linux-ppc linux linux-intel (or just linux?) mswin mswin osx-intel osx-intel osx-ppc osx-ppc osx-universal osx-universal sun solaris-sparc (this *is* sparc, yes?) - solaris-intel Best wishes, Taco
How about:
intel == i386 amd64 == x86_64 (and just forget about ia64 == itanium)
Sounds good to me. Since Intel imposed its name on the x86 processor family, it sounds only fair that we choose AMD for the subclass of 64-bit processors :-) By the way, I wonder how Intel, the company, feels about all this; I read somewhere that Xerox was unhappy about its name being used as a synonym for photocopy (and it's indeed amazing how the widespread the word has become, I even saw it in Kazakhstan. Of course, there it's spelled ксерокс).
and then:
freebsd freebsd-intel linux-64 linux-amd64 linux-ppc linux-ppc linux linux-intel (or just linux?) mswin mswin osx-intel osx-intel osx-ppc osx-ppc osx-universal osx-universal sun solaris-sparc (this *is* sparc, yes?) - solaris-intel
Looks great, but I don't know if the change can be made today without breaking everything. And yes, the "other" processor for Solaris is Sparc. Ultra-Sparc, to be more precise, a 64-bit family of processors. Arthur
On Thu, Nov 27, 2008 at 1:21 PM, Arthur Reutenauer
How about:
intel == i386 amd64 == x86_64 (and just forget about ia64 == itanium)
Sounds good to me. Since Intel imposed its name on the x86 processor family, it sounds only fair that we choose AMD for the subclass of 64-bit processors :-) By the way, I wonder how Intel, the company, feels about all this; I read somewhere that Xerox was unhappy about its name being used as a synonym for photocopy (and it's indeed amazing how the widespread the word has become, I even saw it in Kazakhstan. Of course, there it's spelled ксерокс).
and then:
freebsd freebsd-intel linux-64 linux-amd64 linux-ppc linux-ppc linux linux-intel (or just linux?) mswin mswin osx-intel osx-intel osx-ppc osx-ppc osx-universal osx-universal sun solaris-sparc (this *is* sparc, yes?) - solaris-intel
Looks great, but I don't know if the change can be made today without breaking everything.
OK, so for the time being, I'll use solaris-intel and rename sun to solaris-sparc (which is broken anyway since I didn't get any new binaries :P) I would not rename linux, and I only know two freebsd users so far (we could start parsing the logs and savisg some info), so renaming freebsd into freebsd-intel should not be a problem. (Don't these binaries work on "all" processors?) We can do that for 64-bit linux as well ... just read forward ... I still have an item on my TODO list: create a more user-friendly installer (& switch to git somehow). I would do any renames (and maybe switch to osx-universal?) together with that move (old binaries can stay on the server for some time). If people will want to swich to the new installer, they "won't notice" renaming. (Actually, if they reinstall again, the installer should download another tree and leave the old one there - in case of any troubles, reruning [some new version of] first-setup.sh should solve the problem entirely.) Mojca
Just one more thing ... uname -s returns SunOS?
I'll check for Solaris 9 when I'll have electricity at my new apartment :-) But we shouldn't feel bound by that anyway.
Why does TeXLive use solaris then? (I was confused by the latter.)
Why shouldn't it? We can't rely too much on the output by uname anyway. Arthur
Hello Michael, Open Solaris should work in minimals now. I hope that you'll figure out how to compile XeTeX (and maybe how to resolve the tiny problem with ctangle), but you should nevertheless be able to play with it now. I took XeTeX binaries from TeX Live. If you want to use the most recent binaries (luatex, metapost) it is then up to you to either apply for SVN account or to keep sending them every now and then. Please tell me if everything seems to work fine, so that we can fix any remaining issues. Mojca
participants (3)
-
Arthur Reutenauer -
Mojca Miklavec -
Taco Hoekwater