12 Mar
2017
12 Mar
'17
9:04 p.m.
Hello all.
I was perusing the list of officially branded UNIX systems, according to
the "UNIX 03" specification and tests done by the Open Group, and I
found there listed something called "Huawei EulerOS 2.0".
https://www.opengroup.org/openbrand/register/xy.htm
Intriguing, ain't it?
So I went to Wikipedia, to see what it has to say about such a beast.
https://en.wikipedia.org/wiki/Single_UNIX_Specification#EulerOS
And I quote: "EulerOS 2.0 for the x86-64 architecture were certified as
UNIX 03 compliant. The UNIX 03 conformance statement shows that the
standard C compiler is from the GNU Compiler Collection (gcc), and that
the system is a Linux distribution of the Red Hat family."
So, Linux (some variety of it, very closely resembling Red Hat) is now a
"officially branded" UNIX.
I think Mr. Stallman can now say: mission accomplished. GNU *is* now
UNIX. (Linux the kernel might not be a FSF project, but it certainly is
under the GNU General Public License.)
--
Josh Good
13 Mar
13 Mar
4:15 p.m.
Josh Good <pepe(a)naleco.com> wrote:
Hello all.
I was perusing the list of officially branded UNIX systems, according to
the "UNIX 03" specification and tests done by the Open Group, and I
found there listed something called "Huawei EulerOS 2.0".
https://www.opengroup.org/openbrand/register/xy.htm
Intriguing, ain't it?
So I went to Wikipedia, to see what it has to say about such a beast.
https://en.wikipedia.org/wiki/Single_UNIX_Specification#EulerOS
And I quote: "EulerOS 2.0 for the x86-64 architecture were certified as
UNIX 03 compliant. The UNIX 03 conformance statement shows that the
standard C compiler is from the GNU Compiler Collection (gcc), and that
the system is a Linux distribution of the Red Hat family."
They would need to mention how they passed the test.
Given that there have been many problems last time, there was a collaboration
between the Linux people and the OpenGroup:
http://www.opengroup.org/personal/ajosey/tr20-08-2005.txt
I would guess that this company dod modify software inorder to become compliant.
Jörg
--
EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
14 Mar
14 Mar
7:58 p.m.
On 13 March 2017 at 06:15, Joerg Schilling <schily(a)schily.net> wrote (in part):
Given that there have been many problems last time,
there was a collaboration
between the Linux people and the OpenGroup:
http://www.opengroup.org/personal/ajosey/tr20-08-2005.txt
I would guess that this company dod modify software inorder to become compliant.
As they note (http://developer.huawei.com/ict/en/site-euleros ):
Derived from the source-code for the CentOS distribution. In due
course, I may try it. If this actually works back to most
distributions, it *may* one day become possible to actually have
Linux-distro-derived code compile on Unix systems.
N.
8:14 p.m.
Nemo <cym224(a)gmail.com> wrote:
On 13 March 2017 at 06:15, Joerg Schilling
<schily(a)schily.net> wrote (in part):
In case people write POSIX compliant code...
BTW: passing the POSIX certification does not verify that the system is POSIX
compliant.
The Linux kernel does e.g. not correctly implement the waitid() syscall and the
POSIX validation test suite does not yet check for the deviation.
On a real POSIX system, the following test program passes, but this currently
only applies to Solaris, SCO UnixWare, recent FreeBSD and recent NetBSD:
/*--------------------------------------------------------------------------*/
#include <stdlib.h>
#include <unistd.h>
#include <sys/wait.h>
#include <stdio.h>
/*
* Non-standard compliant platforms may need
* #include <signal.h> or something similar
* in addition to the include files above.
*/
extern void handler(int sig, siginfo_t *sip, void *context);
extern void dosig(void);
pid_t cpid;
int
main()
{
siginfo_t si;
pid_t pid;
int ret;
dosig();
if ((pid = fork()) < 0)
exit(1);
cpid = pid;
if (pid == 0) {
_exit(1234567890);
}
ret = waitid(P_PID, pid, &si, WEXITED);
printf(" ret: %d si_pid: %ld si_status: %d si_code: %d\n",
ret,
(long) si.si_pid, si.si_status, si.si_code);
if (pid != si.si_pid)
printf("si_pid in struct siginfo should be %ld but is %ld\n",
(long) pid, (long) si.si_pid);
if (si.si_status != 1234567890)
printf("si_status in struct siginfo should be %d (0x%x) but is %d (0x%x)\n",
1234567890, 1234567890, si.si_status, si.si_status);
if (si.si_code != CLD_EXITED)
printf("si_code in struct siginfo should be %d (0x%x) but is %d (0x%x)\n",
CLD_EXITED, CLD_EXITED, si.si_code, si.si_code);
if (CLD_EXITED != 1)
printf("CLD_EXITED is %d on this platform\n", CLD_EXITED);
return (0);
}
/*
* Include it here to allow to verify that #include <sys/wait.h>
* makes siginfo_t available
*/
#include <signal.h>
void
handler(int sig, siginfo_t *sip, void *context)
{
printf("received SIGCHLD (%d), si_pid: %ld si_status: %d si_code: %d\n",
sig, (long) sip->si_pid, sip->si_status, sip->si_code);
if (sip->si_pid != cpid)
printf("SIGCHLD: si_pid in struct siginfo should be %ld but is %ld\n",
(long) cpid, (long) sip->si_pid);
if (sip->si_status != 1234567890)
printf("SIGCHLD: si_status in struct siginfo should be %d (0x%x) but is %d
(0x%x)\n",
1234567890, 1234567890, sip->si_status, sip->si_status);
if (sip->si_code != CLD_EXITED)
printf("SIGCHLD: si_code in struct siginfo should be %d (0x%x) but is %d
(0x%x)\n",
CLD_EXITED, CLD_EXITED, sip->si_code, sip->si_code);
}
void
dosig()
{
struct sigaction sa;
sa.sa_sigaction = handler;
sigemptyset(&sa.sa_mask);
sa.sa_flags = SA_RESTART|SA_SIGINFO;
sigaction(SIGCHLD, &sa, NULL);
}
/*--------------------------------------------------------------------------*/
On Solaris, this prints something like:
received SIGCHLD (18), si_pid: 11860 si_status: 1234567890 si_code: 1
ret: 0 si_pid: 11860 si_status: 1234567890 si_code: 1
On Linux, it prints something like:
received SIGCHLD (17), si_pid: 5434 si_status: 210 si_code: 1
SIGCHLD: si_status in struct siginfo should be 1234567890 (0x499602d2) but is 210 (0xd2)
ret: 0 si_pid: 5434 si_status: 210 si_code: 1
si_status in struct siginfo should be 1234567890 (0x499602d2) but is 210 (0xd2)
Jörg
--
EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
Given that there have been many problems last
time, there was a collaboration
between the Linux people and the OpenGroup:
http://www.opengroup.org/personal/ajosey/tr20-08-2005.txt
I would guess that this company dod modify software inorder to become compliant.
As they note (http://developer.huawei.com/ict/en/site-euleros ):
Derived from the source-code for the CentOS distribution. In due
course, I may try it. If this actually works back to most
distributions, it *may* one day become possible to actually have
Linux-distro-derived code compile on Unix systems.
15 Mar
15 Mar
5:27 a.m.
On 2017 Mar 14, 15:14, Joerg Schilling wrote:
On a real POSIX system, the following test program
passes, but this currently
only applies to Solaris, SCO UnixWare, recent FreeBSD and recent NetBSD:
So IBM AIX, HP/UX and Mac OS X are wrongfully-branded UNIX systems?
Nice to know.
--
Josh Good
5:11 p.m.
Josh Good <pepe(a)naleco.com> wrote:
On 2017 Mar 14, 15:14, Joerg Schilling wrote:
Well, this is your wording...
The background is just that around 1995, The OpenGroup added the waitid()
interface that has been introduced in 1989 by SVr4. At that time, the OpenGroup
standard text was correct and interested companies could have implemented the
interface correctly.
Jörg
--
EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
On a real POSIX system, the following test
program passes, but this currently
only applies to Solaris, SCO UnixWare, recent FreeBSD and recent NetBSD:
So IBM AIX, HP/UX and Mac OS X are wrongfully-branded UNIX systems? 
7:42 p.m.
On Wed, Mar 15, 2017, at 07:11, Joerg Schilling wrote:
The background is just that around 1995, The OpenGroup
added the waitid()
interface that has been introduced in 1989 by SVr4. At that time, the
OpenGroup
standard text was correct and interested companies could have implemented
the
interface correctly.
What was the rationale for including the requirement we are discussing?
Even granting that it *did* (there doesn't seem to be any version of the
standard online early enough not to have the supposed mistake in the
text, present in SUSv2 and Issue 6, of allowing waitid to give an 8-bit
value, so we have only your word) Is it really desirable that the
standard *should* include novel SVR4 features not present in earlier
versions of Unix that do not add any particular value?
8:14 p.m.
Random832 <random832(a)fastmail.com> wrote:
What was the rationale for including the requirement
we are discussing?
Even granting that it *did* (there doesn't seem to be any version of the
standard online early enough not to have the supposed mistake in the
text, present in SUSv2 and Issue 6, of allowing waitid to give an 8-bit
value, so we have only your word) Is it really desirable that the
standard *should* include novel SVR4 features not present in earlier
versions of Unix that do not add any particular value?
It seems that you do not understand POSIX the right way.
POSIX does not invent new features but rather standardizes existing features
present in existing UNIX implementations.
The fact that SUS introduced waitid(), obviously intended and correctly
worded an interface as defined by SVr4 in 1989.
The fact that later versions introduced a different wording has been identified
as a bug from the standardization process and this bug has been corrected in
the technical corrigendum 2 of the current standard. You may read this at:
http://pubs.opengroup.org/onlinepubs/9699919799/toc.htm
If you like to understand the real problem, it may be better to give more
information about the deviations:
- AIX only returns 8 bits from the exit() code but is otherwise correct.
- HP-UX behaves similar to AIX
- Mac OS X returns the lower 24 bits from the exit() code and sign extends
the result.
Mac OS X however returns a zeroed out si_pid and si_code and thus it's
waitid() is completely unusable. I have no idea how Apple could ever
pass the POSIX compliance tests.
- Previous *BSD implementations did and Linux does clobber important
information early in the kernel and thus would need to change their
kernel data flow to make waitid() behave correctly.
- FreeBSD did this in July 2015 within 20 hours after reporting
- NetBSD did this change last year in April within a few days.
- The Linux kernel people have been informed and replied that there is
no interest in becomming compliant.
- The Cygwin people have been informed and replied that they have been
Solaris compatible in the past but now are bug by bug Linux compatible.
It seems that AIX did introduce it's bug as a result from lately adopting and
being hit by the bug in the standard. AIX in addition release the currently
latest release one week before the bug in the standard was fixed.
I cannot speak for the other OS.
Jörg
--
EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
9:16 p.m.
On Wed, Mar 15, 2017, at 10:14, Joerg Schilling wrote:
It seems that you do not understand POSIX the right
way.
POSIX does not invent new features but rather standardizes existing
features
present in existing UNIX implementations.
Yes but what I was suggesting was that this may have been a case of too
eagerly standardizing a new feature that one implementation had added
without considering whether there was a good reason to impose that
feature on other implementations.
I mean, surely not *everything* that SVr4 does is in POSIX. There must
therefore be some rationale for selecting which features, particularly
features that are not already universal, to standardize. So what was the
rationale for including this one?
14 Mar
14 Mar
3:06 a.m.
On Sun, Mar 12, 2017 at 04:04:12PM +0100, Josh Good wrote:
And I quote: "EulerOS 2.0 for the x86-64
architecture were certified as
UNIX 03 compliant. The UNIX 03 conformance statement shows that the
standard C compiler is from the GNU Compiler Collection (gcc), and that
the system is a Linux distribution of the Red Hat family."
Inspur K-UX is similar - a Chinese repackaging of RHEL.
Interestingly, it seems that Red Hat have not gone down the certification
route themselves - perhaps they don't see any value in it?
Cheers, MJ
--
Michael-John Turner * mj(a)mjturner.net * http://mjturner.net/
3:35 a.m.
On Mon, Mar 13, 2017 at 5:06 PM, Michael-John Turner <mj(a)mjturner.net>
wrote:
Interestingly, it seems that Red Hat have not gone
down the certification
route themselves - perhaps they don't see any value in it?
Or in there case, negative value. RH likes to have the world believe
they are Linux. They don't want anything lessening their brand.
Certification would make RH < UNIX I suspect which is not what they want.
Certification has always been about the ISV's, and if they can convince the
ISV to test on their implementation directly (and they have) they don't
need it.
It's the old he who has the gold. It's a crappy attitude and its just what
pisses people off about MS, Apple or in the old days DEC or IBM.
Sad.
Clem
4:20 p.m.
Clem Cole <clemc(a)ccc.com> wrote:
???Or in there case, negative value. RH likes to
have the world believe
they are Linux. They don't want anything lessening their brand.
Certification would make RH < UNIX I suspect which is not what they want.
Certification has always been about the ISV's, and if they can convince the
ISV to test on their implementation directly (and they have) they don't
need it.
RH did make several strange things that did make me wonder whether they are
really an OSS company, but they have a person working in the OpenGroup core
team.
This person (Eric Blake) usually helps to connect to developers from glibc, but
he of course knows about the problems GNU software has with the POSIX standard.
He is one of the active people in the teleconferences and he does not try to
bend POSIX to follow what is in use on RH-Linux.
I remember several cases where he helped to convince GNU people to make their
programs POSIX compliant.
Jörg
--
EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
5:35 p.m.
On 13 Mar 2017, at 21:35, Clem Cole <clemc(a)ccc.com> wrote:
Or in there case, negative value. RH likes to have the world believe they are Linux.
They don't want anything lessening their brand. Certification would make RH <
UNIX I suspect which is not what they want. Certification has always been about the
ISV's, and if they can convince the ISV to test on their implementation directly (and
they have) they don't need it.
Well, in particular a lot of the kind of organisations RH sell to (banks) had experiences
with Unix which were not that good: places I worked spent an enormous amount of money on
very expensive machines with hardware-redundancy features which were at best marginally
functional, and certainly not functional enough to rely on. These features compared very
badly with the things that IBM Z-series machines could do (it might be that the IBM/AIX
machines were better in this regard: I didn't deal with them very much).
Of course we'd argue that this is not the fault of Unix, and that's a different
discussion. But the people who have spent 9-figure sums on all this marginally-functional
tin that the Unix vendors foisted on them don't look at it that way: they just want
something which is not Unix, and which runs on cheap tin. Linux is not Unix, and runs on
cheap tin.
--tim
3:51 a.m.
On 2017 Mar 13, 21:06, Michael-John Turner wrote:
On Sun, Mar 12, 2017 at 04:04:12PM +0100, Josh Good
wrote:
I've wondered about that too. The cost of doing the certification tests
themselves --not including the engineering time to prepare the tests--
probably is about US$ 100,000 so Red Hat should be able to afford it.
My theory is that Red Hat sees more value in *not* passing the UNIX
certification tests. As if thus Red Hat was stating: "Linux is the
new standard, and Red Hat makes it happen. Anything else out there,
is just legacy."
And truth be told, probably most (all?) of the "certified UNIX" systems
on the list have some "Linux compatibility" layer of some kind built
into them. So compatibility with whom is the compatibility that matters?
--
Josh Good
And I quote: "EulerOS 2.0 for the x86-64
architecture were certified as
UNIX 03 compliant. The UNIX 03 conformance statement shows that the
standard C compiler is from the GNU Compiler Collection (gcc), and that
the system is a Linux distribution of the Red Hat family."
Inspur K-UX is similar - a Chinese repackaging of RHEL.
Interestingly, it seems that Red Hat have not gone down the certification
route themselves - perhaps they don't see any value in it? 
6:11 a.m.
That was the thing that tipped me off late in the nineties that Linux was succeeding -
only the big
vendors - and Microsoft - were ignoring Linux, everybody else had Linux-compatibility tick
boxes.
Particularly when FreeBSD incorporated one such item ...
Then when IBM took Linux to the mainframe, it was pretty obvious that it wasn't
solely a hobby OS any
longer.
Wesley Parish
Quoting Josh Good <pepe(a)naleco.com>om>:
<snip>
My theory is that Red Hat sees more value in *not*
passing the UNIX
certification tests. As if thus Red Hat was stating: "Linux is the
new standard, and Red Hat makes it happen. Anything else out there,
is just legacy."
And truth be told, probably most (all?) of the "certified UNIX" systems
on the list have some "Linux compatibility" layer of some kind built
into them. So compatibility with whom is the compatibility that
matters?
--
Josh Good
"I have supposed that he who buys a Method means to learn it." - Ferdinand Sor,
Method for Guitar
"A verbal contract isn't worth the paper it's written on." -- Samuel
Goldwyn
4:30 a.m.
For the true Linux fan-person, it might be seen as a detriment. :)
On 3/13/2017 5:06 PM, Michael-John Turner wrote:
Inspur K-UX is similar - a Chinese repackaging of
RHEL.
Interestingly, it seems that Red Hat have not gone down the
certification route themselves - perhaps they don't see any value in it?
2624
days inactive
2627
days old
15 comments
9 participants
participants (9)
-
Arthur Krewat -
Clem Cole -
Josh Good -
Michael-John Turner -
Nemo -
Random832 -
schily＠schily.net -
Tim Bradshaw -
Wesley Parish