[TUHS] MacOS X is Unix (tm)

[TUHS] MacOS X is Unix (tm)

[David]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 978 bytes --]


> On Dec 31, 2016, at 8:58 AM, tuhs-request at minnie.tuhs.org wrote:
> 
> From: Michael Kjörling <michael at kjorling.se>
> To: tuhs at tuhs.org
> Subject: Re: [TUHS] Historic Linux versions not on kernel.org
> Message-ID: <20161231111339.GK576 at yeono.kjorling.se>
> Content-Type: text/plain; charset=utf-8
> 
> I might be colored by the fact that I'm running Linux myself, but I'd
> say that those are almost certainly worth preserving somehow,
> somewhere. Linux and OS X are the Unix-like systems people are most
> likely to come in contact with these days

MacOS X is a certified Unix (tm) OS. Not Unix-Like.

http://www.opengroup.org/openbrand/register/apple.htm

It has been so since 10.0. Since 10.5 (Leopard) it has been so noted on the above Open Group page. The Open Group only lists the most recent release however.

The Tech Brief for 10.7 (http://images.apple.com/media/us/osx/2012/docs/OSX_for_UNIX_Users_TB_July2011.pdf) also notes the compliance.

	David

[TUHS] MacOS X is Unix (tm)

[Kurt H Maier]

On Sat, Dec 31, 2016 at 02:37:04PM -0800, David wrote:
> 
> MacOS X is a certified Unix (tm) OS. Not Unix-Like.

I am confused by your apparent argument that a thing cannot be like
itself.

khm

[TUHS] MacOS X is Unix (tm)

[Nick Downing]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5951 bytes --]

One significant area of non compliance with unix conventions is its non
case sensitive filesystem (HFS and variants like HFS+ if I recall). I think
this is partly for historical reasons to make Classic / MacOS9 emulation
easier during the transition. But I could never understand why they did
this, they could have put case insensitivity in their shell and apps
without breaking the filesystem.

Anyway despite its being unix I can't really see it gaining much traction
with serious unix users (when did you last get a 404 from a major website
with a tagline "Apache running on MacOSX"?), the MacPorts and Fink repos
are a really bad and patchy implementation of something like
apt/ctan/cpan/etc (I think possibly at least one of those repos builds from
source with attendant advantages/problems), it does not support X properly,
the dylibs are non standard, everything is a bit broken compared with Linux
(or FreeBSD) and Apple does not really have the motivation or the manpower
to create a modern, clean system like unix users expect.

Open sourcing Darwin was supposed to open it up to user contributed
enhancements but Apple was never serious about this, it was just a sop to
people who claimed (correctly) that Apple was riding on the back of open
source and giving nothing back to the community. Since Apple refused to
release any important code like drivers or bootstrap routines the Darwin
release was never really any more useable than something like 4.4BSDLite.
People who loved their Macs and loved unix and dreamed of someday running
the Mac UI on top of a proper unix, put significant effort into supplying
the missing pieces but were rebuffed by Apple at every turn, Apple would
constantly make new releases with even more missing pieces and breakage and
eventually stopped making any open source releases at all, leaving a lot of
people crushed and very bitter.

As for me I got on the Apple bandwagon briefly in 2005 or so, at that time
I was experimenting with RedHat but my primary development machines were
Windows 98 and 2000 (occasionally XP). My assessment was RedHat was not
ready for desktop use, since I had trouble with stuff like printers and
scanners that required me to stay with Windows (actually this was probably
surmountable but I did not have the knowledge or really the desire to spend
time debugging it). That's why I selected Apple as a "compromise unix"
which should connect to my devices easily. I got enthusiastic and spent a
good $4k on new hardware. Shortly afterwards Apple announced the Intel
transition so I realized my brand new gear would soon be obsolete and
unsupported. I was still pretty happy though. Two things took the shine off
eventually (a) I spilt champagne on my machine, tore it down to discover my
beautiful and elegant and spare (on the outside) machine was a horrible
hodgepodge of strange piggyback PCBs and third party gear (on the inside),
this apparently happened because options like the backlit keyboard had
become standard equipment at some point but Apple had never redesigned them
into the motherboard, the whole thing was horribly complicated and fragile
and never worked well after the teardown (b) I got seriously into FreeBSD
and Linux and soon discovered the shortcomings of the Mac as a serious
development machine, everything was just slightly incompatible leading to
time waste.

Happily matters have improved a lot. Lately I was setting up some Windows 7
and 10 machines for my wife to use MS Office on for her uni work. Both had
serious driver issues like "The graphics card has crashed and recovered".
And on the Windows 10 machine, despite it being BRAND NEW out of the box
and manufacturer preloaded, the wifi also did not work, constantly crashed
requiring a reboot. Windows Update did not fix these problems. Downloading
and trying various updated drivers from the manufacturer's website seems to
have for now, except on the Windows 7 machine where the issue is noted and
listed as "won't fix" because the graphics card is out of date, the fixed
driver won't load on this machine. Given this seems to be the landscape
even for people who are happy to spend the $$ on the official manufacturer
supported Windows based solutions, Linux looks pretty easy to install and
use by comparison. Not problem free, but may have fewer problems and easier
to fix problems.

It appears to me that with the growing complexity of the hardware due to
the millions of compatibility layers and ad hoc protocols built into it,
the job of the manufacturers and official OS or driver writers gets harder
and harder, whereas the crowdsourced principle of open source shows its
value since the gear is better tested in a wider variety of realistic
situations.

cheers, Nick

On Jan 1, 2017 9:46 AM, "David" <david at kdbarto.org> wrote:


> On Dec 31, 2016, at 8:58 AM, tuhs-request at minnie.tuhs.org wrote:
>
> From: Michael Kjörling <michael at kjorling.se>
> To: tuhs at tuhs.org
> Subject: Re: [TUHS] Historic Linux versions not on kernel.org
> Message-ID: <20161231111339.GK576 at yeono.kjorling.se>
> Content-Type: text/plain; charset=utf-8
>
> I might be colored by the fact that I'm running Linux myself, but I'd
> say that those are almost certainly worth preserving somehow,
> somewhere. Linux and OS X are the Unix-like systems people are most
> likely to come in contact with these days

MacOS X is a certified Unix (tm) OS. Not Unix-Like.

http://www.opengroup.org/openbrand/register/apple.htm

It has been so since 10.0. Since 10.5 (Leopard) it has been so noted on the
above Open Group page. The Open Group only lists the most recent release
however.

The Tech Brief for 10.7 (http://images.apple.com/media/us/osx/2012/docs/OSX_
for_UNIX_Users_TB_July2011.pdf) also notes the compliance.

        David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170101/ba0065e9/attachment.html>

[TUHS] MacOS X is Unix (tm)

[Tim Bradshaw]

On 1 Jan 2017, at 00:43, Nick Downing <downing.nick at gmail.com> wrote:
> 
> One significant area of non compliance with unix conventions is its non case sensitive filesystem (HFS and variants like HFS+ if I recall). I think this is partly for historical reasons to make Classic / MacOS9 emulation easier during the transition. But I could never understand why they did this, they could have put case insensitivity in their shell and apps without breaking the filesystem.

In fact this is an option: you can construct HFS+ filesystems which are case-sensitive and some are (I think the filesystem used for time machine is case-sensitive).  FWIW case-insensitive-case-preserving (which is the default) seems to be the naming option which is least vulnerable to awful braindeath: case-sensitive is clearly purer but is ExtremelyVulnerable, while non-case-preserving ends up like THIS or requires magic hacks.

More importantly, there was a fairly significant cohort of people -- I am one of them -- whose first serious exposure to Unix was BSD 4.x.  Many of those people were then terribly scarred by Sun's defection to SysV (the early Solaris 2s were just seriously grim).  If, 10-12 years ago, you wanted a desktop machine which ran a BSD-derived system, which did not require you to spend a lot of time grovelling around in the guts of broken device drivers and/or did not suffer from minor updates which caused the real-time-clock to stop or something, which had a window system which was not a crappy Windows knockoff and for which a reasonable competent set of desktopy applications was available if you wanted them, then MacOS was the only option.  Indeed, it was the only option even if you relax the BSD requirement.  Linux clearly is a lot better now from that perspective (although based on my experiences with Ubuntu they still do not really understand why 'let's just completely change how everything works every two years' is not a great idea for users: the CADET software-development model is alive and well).

--tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170101/db447d87/attachment.html>

[TUHS] MacOS X is Unix (tm)

[Ron Natalie]

OS/X (Mac) is Mach-derived   I think you do it a disservice to call it
BSD-derived.    While the kernel-to-application interface was compatible
with 4.2 BSD, the kernel is largely of CMU's only creation.

The thing came layered with Doug Gwyn's (where is he? I invited him) BRL SV
on BSD user environment to silence the critics that it wasn't SVID
compatible.    I hadn't even realized it until I got a few Mach kerneled
machines (notably our NeXT cube) and found that it had my version of the
Bourne shell with job control and command line editing hacked in (to battle
the tcsh guys at BRL because I detested the csh syntax and Korn's shell
hadn't gotten out of the labs yet at that point).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170101/40ec1261/attachment.html>

[TUHS] MacOS X is Unix (tm)

[Michael Kjörling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1674 bytes --]

On 1 Jan 2017 11:43 +1100, from downing.nick at gmail.com (Nick Downing):
> One significant area of non compliance with unix conventions is its non
> case sensitive filesystem (HFS and variants like HFS+ if I recall). I think
> this is partly for historical reasons to make Classic / MacOS9 emulation
> easier during the transition.

Just a side note, but ZFS takes the middle ground of making this a
trivially tunable option. Just set casesensitivity=[sensitive |
insensitive | mixed] on the relevant file system (that's right, like
almost everything else that matters in daily use in ZFS, it's a file
system property, not a pool property). I suspect that the major use
case for casesensitivity=insensitive is support for operating systems
that are normally used with case insensitive file name matching.

By setting `mixed`, userland software can apparently specify whether
it wants case-sensitive or case-insensitive matching on a per-request
basis. I suspect that requires ZFS-specific knowledge in the software.

Of course the default is `sensitive`.

Something similar to `mixed` could have been done in OS X and HFS/+;
just make the default case sensitive, and adjust on a per-process
basis if the process is running through the compatibility layer. (Or
the other way around, if preferred. It's not like either way would
have been significantly more work than the other, and it _would_ have
been moving the ecosystem in a Unixy direction.)

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

[TUHS] MacOS X is Unix (tm)

[Tim Bradshaw]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1241 bytes --]

Yes, I know it's Mach: I really meant the userland and (to a smaller extent) the system calls.  Given my aim of a desktop machine on which to live that's actually all I care about: if I have to worry about the guts of the kernel then the system has failed to provide what I need from it.

> On 1 Jan 2017, at 13:01, Ron Natalie <ron at ronnatalie.com> wrote:
> 
> OS/X (Mac) is Mach-derived   I think you do it a disservice to call it BSD-derived.    While the kernel-to-application interface was compatible with 4.2 BSD, the kernel is largely of CMU’s only creation.
> The thing came layered with Doug Gwyn’s (where is he? I invited him) BRL SV on BSD user environment to silence the critics that it wasn’t SVID compatible.    I hadn’t even realized it until I got a few Mach kerneled machines (notably our NeXT cube) and found that it had my version of the Bourne shell with job control and command line editing hacked in (to battle the tcsh guys at BRL because I detested the csh syntax and Korn’s shell hadn’t gotten out of the labs yet at that point).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170101/509cdc79/attachment-0001.html>

[TUHS] MacOS X is Unix (tm)

[David]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2285 bytes --]

MacOS is the best of a bad lot, in my opinion. Unix at the core and as a result pretty well able to withstand attacks from the outside world. For a desktop OS, not too bad.

Linux is to diversified at this point to make it to the desktop any time soon. As a server OS it is a wonderful thing and I am willing to work with it there any time. Though the differences between Linux A and Linux B are sometimes grating on my ability to get the code I am paid to work on running in all environments.

Windows is just broken. Yes, it is getting better (for some definition of better) with each release. The ability to hack and attack usually has this common vector. It is usually chosen by some IT guy because the initial cost is low and it is what they got trained to use sometime in history.

As to Doug Gwyn and The BRL code, I ported all of that onto an early Celerity release. Celerity was 4.2 and I did the port to get the feature set that some customers were clamoring for. And Ron, you may have been the one to send me your patches for the Bourne shell way back when. I do remember doing that integration for Celerity as well.

	David

> On Jan 1, 2017, at 5:56 AM, Tim Bradshaw <tfb at tfeb.org> wrote:
> 
> Yes, I know it's Mach: I really meant the userland and (to a smaller extent) the system calls.  Given my aim of a desktop machine on which to live that's actually all I care about: if I have to worry about the guts of the kernel then the system has failed to provide what I need from it.
> 
> On 1 Jan 2017, at 13:01, Ron Natalie <ron at ronnatalie.com> wrote:
> 
>> OS/X (Mac) is Mach-derived   I think you do it a disservice to call it BSD-derived.    While the kernel-to-application interface was compatible with 4.2 BSD, the kernel is largely of CMU’s only creation.
>> The thing came layered with Doug Gwyn’s (where is he? I invited him) BRL SV on BSD user environment to silence the critics that it wasn’t SVID compatible.    I hadn’t even realized it until I got a few Mach kerneled machines (notably our NeXT cube) and found that it had my version of the Bourne shell with job control and command line editing hacked in (to battle the tcsh guys at BRL because I detested the csh syntax and Korn’s shell hadn’t gotten out of the labs yet at that point).

[TUHS] MacOS X is Unix (tm)

[Tim Bradshaw]

Well: where I work the default desktop is RHEL as far as I know (there are management and admin people who have Windows desktops I think, and laptops are Windows).  This is a scientific environment however: if there were not desktop linux systems they'd need an even bigger farm of headless machines (probably VMs) so there was cultural compatibility with the HPC.  And of course mail is Outlook/Citrix so they cheat there.

I think the answer is that it works if you remember that you are not deploying 'Linux' but RHEL or Ubuntu (or MacOS!) or whatever.  Scale also helps.

--tim

> On 1 Jan 2017, at 19:33, David <david at kdbarto.org> wrote:
> 
> Linux is to diversified at this point to make it to the desktop any time soon.

[TUHS] MacOS X is Unix (tm)

[Kurt H Maier]

On Sun, Jan 01, 2017 at 11:33:45AM -0800, David wrote:
> Linux is to diversified at this point to make it to the desktop any time soon.

I haven't had a job that didn't provide a Linux workstation since the
early 2000s.  Linux has made it to the desktop already, regardless of what
goes on in discount electronics stores.  It's not particularly good at
the desktop, but then, it's not particularly good at anything else,
either.  Like any other operating system, you get out what you put in.

Happy new year.

khm

[TUHS] MacOS X is Unix (tm)

[Larry McVoy]

On Sun, Jan 01, 2017 at 12:28:50PM -0800, Kurt H Maier wrote:
> On Sun, Jan 01, 2017 at 11:33:45AM -0800, David wrote:
> > Linux is to diversified at this point to make it to the desktop any time soon.
> 
> I haven't had a job that didn't provide a Linux workstation since the
> early 2000s.  Linux has made it to the desktop already, regardless of what
> goes on in discount electronics stores.  It's not particularly good at
> the desktop, but then, it's not particularly good at anything else,
> either.  

I'd like to know where you can get a better performing OS.  The file systems
scream when compared to Windows or MacOS, they know about SSDs and do the
right thing.  The processes are light weight, I regularly do "make -j"
which on my machines just spawns as many processs as needed.

$ time make -j
real    0m17.336s
user    1m7.652s
sys     0m5.116s

$ time make -j12	# this is a 6 cpu/hyperthreaded to 12
real    0m16.473s
user    1m5.856s
sys     0m4.736s

So if I size it to the number of CPUs it is slightly faster.  On the other
hand, when I tell it just spawn as many as it wants it peaks at about 267
processes running in parallel.

Solaris, AIX, IRIX, HP-UX, MacOS would all thrash like crazy under that 
load, their context switch times are crappy.

Source: author of LMbench which has been measuring this stuff since the
mid 1990s.

[TUHS] MacOS X is Unix (tm)

[arnold]

"Ron Natalie" <ron at ronnatalie.com> wrote:

> OS/X (Mac) is Mach-derived   I think you do it a disservice to call it
> BSD-derived.    While the kernel-to-application interface was compatible
> with 4.2 BSD, the kernel is largely of CMU's only creation.
>
> The thing came layered with Doug Gwyn's (where is he? I invited him) BRL SV
> on BSD user environment to silence the critics that it wasn't SVID
> compatible.    I hadn't even realized it until I got a few Mach kerneled
> machines (notably our NeXT cube) and found that it had my version of the
> Bourne shell with job control and command line editing hacked in (to battle
> the tcsh guys at BRL because I detested the csh syntax and Korn's shell
> hadn't gotten out of the labs yet at that point).
>

I remember Ron's job control stuff. I even backported it to the BSD v7
Bourne shell and posted it to one of the sources groups.

I don't remember a history mechanism by Ron, but I do remember one that I
did; it was very csh style.  I don't think tcsh was around then. This
is ~ 1984-1986 time frame.

Ron - can you give more detail about your history mechanism?

Thanks,

Arnold

[TUHS] MacOS X is Unix (tm)

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1860 bytes --]

David <david at kdbarto.org> wrote:

> MacOS X is a certified Unix (tm) OS. Not Unix-Like.

Given that MacOS X is not POSIX compliant, I would call it a UNIX-alike.

Note that passing the certification tests unfortunately does not grant 
POSIX compliance :-(

Try e.g. this program on Mac OS X:

#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.
 */

int
main()
{
        siginfo_t       si;
        pid_t   pid;
        int     ret;

        if ((pid = fork()) < 0)
                exit(1);
        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);
}

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] MacOS X is Unix (tm)

[Ron Natalie]

I added TCSH command line editng.   The history was you could scroll back
through your previous commands.    By default, the thing used an emacs-like
command binding, but it was entirely configurable.
Most of the Mach /bin/sh were my earlier shell with only job control.    The
command editing one didn't make Doug's distribution.

I also remember sitting down with some other guys and explaining how the BSD
job control worked.    For this garnered me a mention in some of the early
linux docs.
I also remember having a nice discussion of shell internals with Dave Korn
at another show.    The two of us had a lot of stories about banging our
heads on the shell internals.
The most significant change out of the labs was between SV and SVR2 when
someone finally got rid of all those Bourne macros that made the C look like
Algol or whatever.

[TUHS] MacOS X is Unix (tm)

[arnold]

"Ron Natalie" <ron at ronnatalie.com> wrote:

> The command editing one didn't make Doug's distribution.

That explains why I never saw it... :-)

> The most significant change out of the labs was between SV and SVR2 when
> someone finally got rid of all those Bourne macros that made the C look like
> Algol or whatever.

Yes, I remember that. It was a real breath of fresh air.  It was
really USG at that point and not "the Labs" (= the Research group).

I think shell functions came in at that point, too.

Thanks,

Arnold

[TUHS] MacOS X is Unix (tm)

[Nemo]

On 2 January 2017 at 06:31, Joerg Schilling <schily at schily.net> wrote:
> David <david at kdbarto.org> wrote:
>
>> MacOS X is a certified Unix (tm) OS. Not Unix-Like.
>
> Given that MacOS X is not POSIX compliant, I would call it a UNIX-alike.
>
> Note that passing the certification tests unfortunately does not grant
> POSIX compliance :-(

Interesting -- I had always thought that UNIX03 incorporated IEEE
1003.x (http://www.opengroup.org/openbrand/register/xym0.htm ).

So what is missing and why?

N.

P.S. As UNIX is a registered trademark of X/Open, anything passing
UNIX03 is UNIX by definition.

[TUHS] MacOS X is Unix (tm)

[Chet Ramey]

On 1/2/17 6:34 AM, Ron Natalie wrote:
> I added TCSH command line editng.   The history was you could scroll back
> through your previous commands.    By default, the thing used an emacs-like
> command binding, but it was entirely configurable.
> Most of the Mach /bin/sh were my earlier shell with only job control.    The
> command editing one didn't make Doug's distribution.

I think the command editing lives on via pdksh and its descendents, in a
more limited form.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://cnswww.cns.cwru.edu/~chet/

[TUHS] MacOS X is Unix (tm)

[Chet Ramey]

On 1/2/17 6:31 AM, Joerg Schilling wrote:
> David <david at kdbarto.org> wrote:
> 
>> MacOS X is a certified Unix (tm) OS. Not Unix-Like.
> 
> Given that MacOS X is not POSIX compliant, I would call it a UNIX-alike.
> 
> Note that passing the certification tests unfortunately does not grant 
> POSIX compliance :-(

That's pretty much exactly what it means.  You have either found a bug or a
place where the interpretation is disputed.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://cnswww.cns.cwru.edu/~chet/

[TUHS] MacOS X is Unix (tm)

[Larry McVoy]

On Mon, Jan 02, 2017 at 11:44:06AM -0500, Chet Ramey wrote:
> On 1/2/17 6:31 AM, Joerg Schilling wrote:
> > David <david at kdbarto.org> wrote:
> > 
> >> MacOS X is a certified Unix (tm) OS. Not Unix-Like.
> > 
> > Given that MacOS X is not POSIX compliant, I would call it a UNIX-alike.
> > 
> > Note that passing the certification tests unfortunately does not grant 
> > POSIX compliance :-(
> 
> That's pretty much exactly what it means.  You have either found a bug or a
> place where the interpretation is disputed.

Joerg is pretty smart, he's been around the block.  There have been
multiple POSIX standards, just like there is C9, C11, etc.  My guess is
MacOS got certified for an earlier standard and hasn't kept up.

[TUHS] MacOS X is Unix (tm)

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1367 bytes --]

Nemo <cym224 at gmail.com> wrote:

> On 2 January 2017 at 06:31, Joerg Schilling <schily at schily.net> wrote:
> > David <david at kdbarto.org> wrote:

> > Note that passing the certification tests unfortunately does not grant
> > POSIX compliance :-(
>
> Interesting -- I had always thought that UNIX03 incorporated IEEE
> 1003.x (http://www.opengroup.org/openbrand/register/xym0.htm ).
>
> So what is missing and why?

The problem is that only by failing, you can approach a test suite that gives a 
sufficient code coverage.

The current method is that every time a bug in the test suite or the POSIX test 
is discovered, the text and/or the test suite is fixed. Platforms that passed 
the test are however not withdrawn their state. They just need to fix their 
problem in case they like to get a certification for the next version of the 
standard, if they implemented things the wrong way.

BTW: The OpenGroup manages the POSIX text and after a new version has been 
accepted, it is reviewed by the IEEE people. This usually causes aprox. 6 
months of delay, but no real changes in the text.

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] MacOS X is Unix (tm)

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1197 bytes --]

Larry McVoy <lm at mcvoy.com> wrote:

> Joerg is pretty smart, he's been around the block.  There have been
> multiple POSIX standards, just like there is C9, C11, etc.  My guess is
> MacOS got certified for an earlier standard and hasn't kept up.

The test suite seems to be written to test for the problems of a genetic UNIX.

It does not test a lot of things that are known to be correct in e.g. Solaris.

If you like to verify other implementations (like e.g. Mac OS X), you need to 
check other places in the interfaces and the problem with "waitid()" is that 
the POSIX text has been correct when waitid() has been introduced in 1996, but
later a bug slipped in. A bug that has been fixed just a year ago (in case of
e.g. waitid()).

In order to get a fix for waitid(), we would need to wait until Apple certifies 
their OS for ISSUE 7 + TC2. This is because ISSUE 7 + TC2 has been accepted by 
IEEE in December 2016...



Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] MacOS X is Unix (tm)

[Chet Ramey]

On 1/2/17 11:49 AM, Larry McVoy wrote:
> On Mon, Jan 02, 2017 at 11:44:06AM -0500, Chet Ramey wrote:
>> On 1/2/17 6:31 AM, Joerg Schilling wrote:
>>> David <david at kdbarto.org> wrote:
>>>
>>>> MacOS X is a certified Unix (tm) OS. Not Unix-Like.
>>>
>>> Given that MacOS X is not POSIX compliant, I would call it a UNIX-alike.
>>>
>>> Note that passing the certification tests unfortunately does not grant 
>>> POSIX compliance :-(
>>
>> That's pretty much exactly what it means.  You have either found a bug or a
>> place where the interpretation is disputed.
> 
> Joerg is pretty smart, he's been around the block.  There have been
> multiple POSIX standards, just like there is C9, C11, etc.  My guess is
> MacOS got certified for an earlier standard and hasn't kept up.

This came up on the Posix list.  He found what I consider to be a bug.
The fact that Mac OS X passed the compliance test and got the branding
is not in dispute.
> 


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://cnswww.cns.cwru.edu/~chet/

[TUHS] MacOS X is Unix (tm)

[Larry McVoy]

On Mon, Jan 02, 2017 at 12:05:15PM -0500, Chet Ramey wrote:
> On 1/2/17 11:49 AM, Larry McVoy wrote:
> > On Mon, Jan 02, 2017 at 11:44:06AM -0500, Chet Ramey wrote:
> >> On 1/2/17 6:31 AM, Joerg Schilling wrote:
> >>> David <david at kdbarto.org> wrote:
> >>>
> >>>> MacOS X is a certified Unix (tm) OS. Not Unix-Like.
> >>>
> >>> Given that MacOS X is not POSIX compliant, I would call it a UNIX-alike.
> >>>
> >>> Note that passing the certification tests unfortunately does not grant 
> >>> POSIX compliance :-(
> >>
> >> That's pretty much exactly what it means.  You have either found a bug or a
> >> place where the interpretation is disputed.
> > 
> > Joerg is pretty smart, he's been around the block.  There have been
> > multiple POSIX standards, just like there is C9, C11, etc.  My guess is
> > MacOS got certified for an earlier standard and hasn't kept up.
> 
> This came up on the Posix list.  He found what I consider to be a bug.
> The fact that Mac OS X passed the compliance test and got the branding
> is not in dispute.

Only somewhat on point but...

My first job at Sun was doing POSIX conformance in SunOS 4.x.  Nobody else
wanted to do it so they hired me (through Lachman) as a contractor to
do it.  As an aside, I'm super stoked I got to this work, it was early
enough in my career that there were plenty of wholes in my knowledge.
Having to POSIX really plugged those wholes and brought the whole kernel
into focus if that makes sense.

Anyhoo, if the POSIX test suite now is anything like the one back then
(late 1980's), it's a steaming pile of shit.  It was absolutely trivial to
pass that test and have all sorts of stuff that wasn't POSIX compliant.
I ended up writing a lot of my own tests to make sure SunOS actually
conformed to the spec.  It was really painstaking work but it gave me some
good habits.  My POSIX book is all marked up with one color for it passed
the test suite and another color for when I believed SunOS conformed.

As a further aside, this was one of the best years in my life.  I was
young and fit, and Sun wouldn't let me bill more than an average of 40
hours/week.  I lived close to campus and it wasn't hard for me to do 80
hours in a week (which was more productive than 80 hours in two weeks,
longer bursts of work meant I didn't have to ramp up state as often).
So I'd work a week and then take the week + 2 weekends off.  I skiied
29 days that winter and spent 6 weeks backpacking in the Sierras.
It was glorious.

And I still got SunOS to conform in about a year.  Gave a presentation
about it at some conference and the NCR or NEC team came up to me and
asked "where's the rest of your team?".  I asked them if they were
talking about my docs person (Kennan Rossi, great guy, either he or I
hacked vi to allow for multiple targets on the same tag so you could
tag on VOP_OPEN and it would say 1 of 19, the first tag got you to the
macro, the next one got you to vop_open, the next got you to ufs_open,
etc, through all the file systems.  Without that you really couldn't
say if open() had POSIX semantics in all cases).

Anyhoo, they said "no, the rest of the kernel hacking team".  I just
looked at them and said "it's just me".  They had 3 kernel people and had
been working on it for years and were not done.  My guess is that SunOS
was far closer to conforming than whatever kernel they were working on,
they didn't strike me as stupid people.

I loved that project.  Hard work but man did you see how Unix was hung
together (and where it had wandered) as a result.  Super useful education
for me.

And I was parked in Steve Kleinman's office (he was over doing a sun4
hardware bringup).  I read all the technical stuff he had stashed there
and decided that this guy had really good taste.  So when Sun wanted to
hire me (they bought out the Lachman contract) I said "sure - on two
conditions: (a) I work for Steve (who I hadn't even met, was just sure
he was very smart) and (b) I get a modification to my employee contract
that says I can't be penalized for skipping meetings (I had figured out
that most, not all, but most meetings were a waste of time)."  Sun gave
me both after some amount of churn :)  Fun times.  Steve and I hit off
famously, one of the most fun people I've ever worked with because we
both had pretty deep knowledge about the stuff we worked on and we could
have super fast technical discussions (that nobody else could understand
because we jumped forward so fast).

[TUHS] MacOS X is Unix (tm)

[Christian Neukirchen]

Chet Ramey <chet.ramey at case.edu> writes:

> On 1/2/17 11:49 AM, Larry McVoy wrote:
>> On Mon, Jan 02, 2017 at 11:44:06AM -0500, Chet Ramey wrote:
>>> On 1/2/17 6:31 AM, Joerg Schilling wrote:
>>>> David <david at kdbarto.org> wrote:
>>>>
>>>>> MacOS X is a certified Unix (tm) OS. Not Unix-Like.
>>>>
>>>> Given that MacOS X is not POSIX compliant, I would call it a UNIX-alike.
>>>>
>>>> Note that passing the certification tests unfortunately does not grant 
>>>> POSIX compliance :-(
>>>
>>> That's pretty much exactly what it means.  You have either found a bug or a
>>> place where the interpretation is disputed.
>> 
>> Joerg is pretty smart, he's been around the block.  There have been
>> multiple POSIX standards, just like there is C9, C11, etc.  My guess is
>> MacOS got certified for an earlier standard and hasn't kept up.
>
> This came up on the Posix list.  He found what I consider to be a bug.
> The fact that Mac OS X passed the compliance test and got the branding
> is not in dispute.

I seem to remember HFS+ had non-POSIX-compliant rename(2) semantics
with respect to atomicity... so the tests ran on UFS?
(And what good for is the result then, when noone else uses that?)

-- 
Christian Neukirchen  <chneukirchen at gmail.com>  http://chneukirchen.org

[TUHS] MacOS X is Unix (tm)

[Chet Ramey]

On 1/2/17 12:32 PM, Larry McVoy wrote:
> On Mon, Jan 02, 2017 at 12:05:15PM -0500, Chet Ramey wrote:
>> On 1/2/17 11:49 AM, Larry McVoy wrote:
>>> On Mon, Jan 02, 2017 at 11:44:06AM -0500, Chet Ramey wrote:
>>>> On 1/2/17 6:31 AM, Joerg Schilling wrote:
>>>>> David <david at kdbarto.org> wrote:
>>>>>
>>>>>> MacOS X is a certified Unix (tm) OS. Not Unix-Like.
>>>>>
>>>>> Given that MacOS X is not POSIX compliant, I would call it a UNIX-alike.
>>>>>
>>>>> Note that passing the certification tests unfortunately does not grant 
>>>>> POSIX compliance :-(
>>>>
>>>> That's pretty much exactly what it means.  You have either found a bug or a
>>>> place where the interpretation is disputed.
>>>
>>> Joerg is pretty smart, he's been around the block.  There have been
>>> multiple POSIX standards, just like there is C9, C11, etc.  My guess is
>>> MacOS got certified for an earlier standard and hasn't kept up.

I totally agree that this happened.  Apple ships bash-3.2 as their shell,
and there is a combination of bug fixes and subsequent interpretations
that renders it non-conformant to the Posix of today.  Lots of things
change in 14 years.  My objection was that the original statement lacked
nuance.


> Anyhoo, if the POSIX test suite now is anything like the one back then
> (late 1980's), it's a steaming pile of shit.  It was absolutely trivial to
> pass that test and have all sorts of stuff that wasn't POSIX compliant.

I find this very easy to believe.  I ran bash through several versions of
the 1003.2 -- back then -- conformance test, and the earliest ones (early
to mid 90s) were obviously written to ensure that ksh passed.  Just chock
full of constructs and builtins that were ksh-specific.  Most of that
stuff got cleaned up eventually, but the first versions were clearly the
product of someone who was not familiar with Posix or historical versions
of sh at all.

The worst part was the multiple subsequent discussions on the austin-group
list that ended up with some resolution like "yes, I know this is what the
text of the standard says, but this is what we really meant."  Definitely
a moving target.

> As a further aside, this was one of the best years in my life.  I was
> young and fit, 

Weren't we all.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://cnswww.cns.cwru.edu/~chet/

[TUHS] MacOS X is Unix (tm)

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3690 bytes --]

Larry McVoy <lm at mcvoy.com> wrote:

> I'd like to know where you can get a better performing OS.  The file systems
> scream when compared to Windows or MacOS, they know about SSDs and do the
> right thing.  The processes are light weight, I regularly do "make -j"
> which on my machines just spawns as many processs as needed.
...

> So if I size it to the number of CPUs it is slightly faster.  On the other
> hand, when I tell it just spawn as many as it wants it peaks at about 267
> processes running in parallel.
>
> Solaris, AIX, IRIX, HP-UX, MacOS would all thrash like crazy under that 
> load, their context switch times are crappy.
>
> Source: author of LMbench which has been measuring this stuff since the
> mid 1990s.

Could you give a verification for this claim please?

My experiences are different.

From what I can tell, the filesystem concepts in Linux are slow and it is 
usually not possible to tell what happened in a given time frame. It however
creates the impression that it is fast if you are the only user on a system,
but it makes it hard to gauge a time that is comparable to a time retrived 
from a different OS. This is because you usually don't know what happened in
a given time.

If you e.g. use gtar to unpack a Linux kernel archive on your local disk, the 
wall clock run time of gtar is low, but it takes some time before the first 
disk I/O takes place and the disk I/O continues until a long time after gtar 
already returned control to the shell.

If you however use star for the same task and do not specify the "-no-fsync" 
option, star takes 4x longer than gtar to return control to the shell. If you
do the same on Solaris using the same hardware, a standard star extract (with 
the default fsync) takes only 10% more real time with UFS compared to the time
without fsync and the time is aprox. the same as the unpack time on Linux 
using gtar. This is because on Solaris, disk I/O starts immediately even when 
you use gtar and there is no time wasted with filling the kernel cache before 
I/O starts.

Aprox. 12 years ago, I converted the central web server for the OSS hosting 
platform berlios.de (*) (at that time the second largest one) from Linux to 
Solaris and the performance did increase ponderably.... Even worse, at the 
same time, I did a test where I unpacked the Linux kernel archive using gtar
and switched off the power just after gtar returned control to the shell. The 
result was a rotten filesystem that could not be repaired by fsck.

***
So my question is: did you manage to find a method to gauge something 
on Linux that is comparable to other platforms or do you also suffer from the
problem that Linux tries to hide the real time needed for filesystem 
operations?
***

BTW: ZFS has a similar problem as Linux: It is extremely slow when you ask it 
to to things in a way that result in a known state. ZFS however does not result 
in a rotten FS when you switch the system off while it is updating the FS.


*) The reason for this conversion was that Linux completely stalled 3-4 times a 
day and only a reset did help. There was no way to get the reason for that 
problem using Linux debug tools. After the conversion to Solaris, it turned out 
that memory overcommitment on Linux was the reason for the freeze. Since we had 
two CPUs, the Linux kernel could copy on write pages faster than searching for 
processes to kill in order to recover.



Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] MacOS X is Unix (tm)

[David]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2152 bytes --]

MacOS passes this except for the si_status test. MacOS uses a signed int there. I’m not sure what the standard says.

	David

> On Jan 2, 2017, at 3:31 AM, Joerg Schilling <schily at schily.net> wrote:
> 
> David <david at kdbarto.org> wrote:
> 
>> MacOS X is a certified Unix (tm) OS. Not Unix-Like.
> 
> Given that MacOS X is not POSIX compliant, I would call it a UNIX-alike.
> 
> Note that passing the certification tests unfortunately does not grant 
> POSIX compliance :-(
> 
> Try e.g. this program on Mac OS X:
> 
> #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.
> */
> 
> int
> main()
> {
>        siginfo_t       si;
>        pid_t   pid;
>        int     ret;
> 
>        if ((pid = fork()) < 0)
>                exit(1);
>        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);
> }
> 
> Jörg
> 
> -- 
> EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
>       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
> URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] MacOS X is Unix (tm)

[David]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1524 bytes --]

My complaint about Linux here is not that it isn’t useful or isn’t a development workstation for some people, it is more that it won’t be a desktop for your mother/father/brother-in-law any time soon.

The fragmentation of Linux is what is holding it back. If I purchase a Mac or Windows box I know what I’m getting and I know that millions of others have the same thing. If I want support there are store fronts for both that I can walk into and get expert help without much hassle. No such thing exists for Linux and I don’t think it is going to happen this year. As in: this is not the year that Linux takes over the desktop. I don’t think it will happen next year either. :-)

	David


> On Jan 1, 2017, at 12:12 PM, Tim Bradshaw <tfb at tfeb.org> wrote:
> 
> Well: where I work the default desktop is RHEL as far as I know (there are management and admin people who have Windows desktops I think, and laptops are Windows).  This is a scientific environment however: if there were not desktop linux systems they'd need an even bigger farm of headless machines (probably VMs) so there was cultural compatibility with the HPC.  And of course mail is Outlook/Citrix so they cheat there.
> 
> I think the answer is that it works if you remember that you are not deploying 'Linux' but RHEL or Ubuntu (or MacOS!) or whatever.  Scale also helps.
> 
> --tim
> 
>> On 1 Jan 2017, at 19:33, David <david at kdbarto.org> wrote:
>> 
>> Linux is to diversified at this point to make it to the desktop any time soon.
> 

[TUHS] MacOS X is Unix (tm)

[Random832]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 545 bytes --]

On Tue, Jan 3, 2017, at 09:06, David wrote:
> MacOS passes this except for the si_status test. MacOS uses a signed int
> there. I’m not sure what the standard says.

The problem isn't the fact that it's signed, it's the fact that it's
only a 24-bit value (i.e. the high 8 bits are replaced with
sign-extension of bit 23). Look at the hex - expected 0x499602d2 vs
actual 0xff9602d2

However, OSX only claims compliance to Issue 6 (unistd.h _XOPEN_VERSION
600), and the text requiring that the full 32-bit value be preserved is
new to Issue 7.

[TUHS] MacOS X is Unix (tm)

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 559 bytes --]

David <david at kdbarto.org> wrote:

> MacOS passes this except for the si_status test. MacOS uses a signed int there. I???m not sure what the standard says.

The standard says that si_status is a signed int.

Which version are you using?

It seems that Apple changed things... recently?



Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] MacOS X is Unix (tm)

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3524 bytes --]

Random832 <random832 at fastmail.com> wrote:

> On Tue, Jan 3, 2017, at 09:06, David wrote:
> > MacOS passes this except for the si_status test. MacOS uses a signed int
> > there. I???m not sure what the standard says.
>
> The problem isn't the fact that it's signed, it's the fact that it's
> only a 24-bit value (i.e. the high 8 bits are replaced with
> sign-extension of bit 23). Look at the hex - expected 0x499602d2 vs
> actual 0xff9602d2
>
> However, OSX only claims compliance to Issue 6 (unistd.h _XOPEN_VERSION
> 600), and the text requiring that the full 32-bit value be preserved is
> new to Issue 7.

The text requiring the full 32-bit value is not new....

It was required in 1996 already, but then somebody introduced a bug into the 
text and that was not aligned with the expected behavior.

BTW: the 24 bits are a result of coding a new wait interface into the historic 
ABI by using the top 16 bits in the wait() argument value.

I should write a test program that retrieved the waitid() results from the the 
SIGCHLD handler and see whether that is OK as well.

Here is the new code:

#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_handler = handler;
	sigemptyset(&sa.sa_mask);
	sa.sa_flags = SA_RESTART|SA_SIGINFO;

	sigaction(SIGCHLD, &sa, NULL);
}

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] ZFS (was: Re: MacOS X is Unix (tm))

[Michael Kjörling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1734 bytes --]

On 3 Jan 2017 14:17 +0100, from schily at schily.net (Joerg Schilling):
> BTW: ZFS has a similar problem as Linux: It is extremely slow when you ask it 
> to to things in a way that result in a known state. ZFS however does not result 
> in a rotten FS when you switch the system off while it is updating the FS.

In all fairness to it, ZFS never (at least that I have seen) _claims_
to be a high performance file system. Lots of people (myself included)
point out that it is _anything but_. Its Merkle tree data structures
on disk, copy-on-write behavior and ubiquitous, nearly free snapshots
are, in fact, prone to encourage fragmentation along with causing
normal I/O patterns to require massive seeking on rotational media.
Its saving grace in terms of performance is caching; just try setting
primarycache=none or sync=always and observe your system grind to a
halt I/O-wise almost no matter what else you do.

Yes, I use ZFS; nearly exclusively so on my main machine. Yes, it has
saved my rear a few times with disk/cabling/controller combinations
that have somehow not been quite happy together (for whatever reason,
LSI 9211, SFF-8087 to SFF-8482 breakout cables, and HGST SATA disks is
not a good combination). But not even ZFS is perfect, and its design
does have several sharp edges to watch out for alongside the
performance implications. Where ZFS shines IMO is in the end-to-end
integrity guarantees department and its integration of the volume and
file system managers into a cohesive whole.

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

[TUHS] MacOS X is Unix (tm)

[Derek Fawcus]

On Tue, Jan 03, 2017 at 04:08:56pm +0100, Joerg Schilling wrote:
> 
> I should write a test program that retrieved the waitid() results from the the 
> SIGCHLD handler and see whether that is OK as well.
> 
> Here is the new code:

FWIW, on 10.10.5 [1] this gives essentially the same result as the prior program,
the signal handler seeing the same sign extended 24 bit value:

$ ./posix2
received SIGCHLD (20), si_pid: 2281 si_status: -6946094 si_code: 1
SIGCHLD: si_status in struct siginfo should be 1234567890 (0x499602d2) but is -6946094 (0xff9602d2)
ret: 0 si_pid: 2281 si_status: -6946094 si_code: 1
si_status in struct siginfo should be 1234567890 (0x499602d2) but is -6946094 (0xff9602d2)

Mind,  one should probably assign the handler to sa.sa_sigaction, as someone
could implement the struct w/o both fields in a union.

As I recall,  there are also other bugs in OSX to do with poll() handling,
so that would be another area where the conformance tests fall short.

DF

[1] Darwin Old-MBA.local 14.5.0 Darwin Kernel Version 14.5.0: Sun Sep 25 22:07:15 PDT 2016; root:xnu-2782.50.9~1/RELEASE_X86_64 x86_64

[TUHS] ZFS (was: Re: MacOS X is Unix (tm))

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]

Michael Kjörling <michael at kjorling.se> wrote:

> On 3 Jan 2017 14:17 +0100, from schily at schily.net (Joerg Schilling):
> > BTW: ZFS has a similar problem as Linux: It is extremely slow when you ask it 
> > to to things in a way that result in a known state. ZFS however does not result 
> > in a rotten FS when you switch the system off while it is updating the FS.
>
> In all fairness to it, ZFS never (at least that I have seen) _claims_
> to be a high performance file system. Lots of people (myself included)
> point out that it is _anything but_. Its Merkle tree data structures

Well in practice ZFS is amazingly fast.

Wat I wanted to mention is that some methods to make things fast or to look 
like they were fast may result in a slow system in case you ask it to produce a 
known state at a given arbitrary time.

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] MacOS X is Unix (tm)

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1131 bytes --]

Derek Fawcus <dfawcus+lists-tuhs at employees.org> wrote:

> FWIW, on 10.10.5 [1] this gives essentially the same result as the prior program,
> the signal handler seeing the same sign extended 24 bit value:
>
> $ ./posix2
> received SIGCHLD (20), si_pid: 2281 si_status: -6946094 si_code: 1
> SIGCHLD: si_status in struct siginfo should be 1234567890 (0x499602d2) but is -6946094 (0xff9602d2)
> ret: 0 si_pid: 2281 si_status: -6946094 si_code: 1
> si_status in struct siginfo should be 1234567890 (0x499602d2) but is -6946094 (0xff9602d2)

OK, then the main change during the past 8 years was that Apple now includes 
the siginfo structure in sys/wait.h and that si_pid and si_code are now filled 
in.

> Mind,  one should probably assign the handler to sa.sa_sigaction, as someone
> could implement the struct w/o both fields in a union.

Done - thank you....

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] MacOS X is Unix (tm)

[Random832]

On Tue, Jan 3, 2017, at 10:08, Joerg Schilling wrote:
> Random832 <random832 at fastmail.com> wrote:
> > However, OSX only claims compliance to Issue 6 (unistd.h _XOPEN_VERSION
> > 600), and the text requiring that the full 32-bit value be preserved is
> > new to Issue 7.
> 
> The text requiring the full 32-bit value is not new....

Is there some other text you have in mind other than "The exit value in
si_status shall be equal to the full exit value (that is, the value
passed to _exit(), _Exit(), or exit(), or returned from main()); it
shall not be limited to the least significant eight bits of the value."
in the description of signal.h (not present in Issue 6 or SUSv2)? Or
maybe something from "2.13. Status Information" (whole section is new in
Issue 7).

In SUSv2, the text of exit() states "If the parent process of the
calling process is executing a wait(), wait3(), waitid() or waitpid(),
[...] it is notified of the calling process' termination and the
low-order eight bits (that is, bits 0377) of status are made available
to it." with no indication of any of these functions allowing the parent
process to get more bits of status. More or less the same text appears
in Issue 6, with some rearrangement due to waitid being part of the XSI
option.

> It was required in 1996 already, but then somebody introduced a bug into
> the text and that was not aligned with the expected behavior.

Oh, so there was a bug in *the text*. That would be the text of the
standard that OSX conforms to?

[TUHS] MacOS X is Unix (tm)

[David]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]

I’m running Yosemite, Sierra won’t run on my hardware.

Does the standard expect an int to be a specific size? I can’t imagine this to be the case. On Mac ints are 32 bits, as are longs. Unlike Linux where long defaults to 64 bits.

So keeping the code I work on portable between Linux and the Mac requires more than a bit of ‘ifdef’ hell.

	David

> On Jan 3, 2017, at 6:49 AM, Joerg Schilling <schily at schily.net> wrote:
> 
> David <david at kdbarto.org> wrote:
> 
>> MacOS passes this except for the si_status test. MacOS uses a signed int there. I???m not sure what the standard says.
> 
> The standard says that si_status is a signed int.
> 
> Which version are you using?
> 
> It seems that Apple changed things... recently?
> 
> 
> 
> Jörg
> 
> -- 
> EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
>       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
> URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] MacOS X is Unix (tm)

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3170 bytes --]

Random832 <random832 at fastmail.com> wrote:

> On Tue, Jan 3, 2017, at 10:08, Joerg Schilling wrote:
> > Random832 <random832 at fastmail.com> wrote:
> > > However, OSX only claims compliance to Issue 6 (unistd.h _XOPEN_VERSION
> > > 600), and the text requiring that the full 32-bit value be preserved is
> > > new to Issue 7.
> > 
> > The text requiring the full 32-bit value is not new....
>
> Is there some other text you have in mind other than "The exit value in
> si_status shall be equal to the full exit value (that is, the value
> passed to _exit(), _Exit(), or exit(), or returned from main()); it
> shall not be limited to the least significant eight bits of the value."
> in the description of signal.h (not present in Issue 6 or SUSv2)? Or
> maybe something from "2.13. Status Information" (whole section is new in
> Issue 7).

This has now been worded to make it obvious that masking off bits is not 
permitted - except for the historic UNIX wait()/waitpid() interfaces.

> In SUSv2, the text of exit() states "If the parent process of the
> calling process is executing a wait(), wait3(), waitid() or waitpid(),
> [...] it is notified of the calling process' termination and the
> low-order eight bits (that is, bits 0377) of status are made available
> to it." with no indication of any of these functions allowing the parent
> process to get more bits of status. More or less the same text appears
> in Issue 6, with some rearrangement due to waitid being part of the XSI
> option.

SUSv2 is the standard with the correct text:

Here is a part of it's wait() description:

WEXITSTATUS(stat_val)
    If the value of WIFEXITED(stat_val) is non-zero, this macro evaluates to 
the low-order 8 bits of the status argument that the child process passed to 
_exit() or exit(), or the value the child process returned from main(). 

from the signal.h description:

int           si_status exit value or signal

So masking is only mentioned for wait() and waitpid()

> > It was required in 1996 already, but then somebody introduced a bug into
> > the text and that was not aligned with the expected behavior.
>
> Oh, so there was a bug in *the text*. That would be the text of the
> standard that OSX conforms to?

In SUSv2, it did just describes the waitid() interface without mentioning that
there is a mask. People at that time seem to believe that everybody knows that
si_status is a full int.

Note that the WEXITSTATUS() macro does not apply to waitid().

Later, the wrong masking text has been added.

POSIX never introduced own inventions, but rather standardizes existing 
features. The siginfo/waitid() interface has been introduced by SVr4 in 1989 
and platforms that correctly implement SVr4 compliance of course all return the 
full int.

Apple seem to have known that the compliance test did only check for

	"more than 8 bits"

by using a 16 bit exit() value in the tests...

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] MacOS X is Unix (tm)

[Derek Fawcus]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 974 bytes --]

On Tue, Jan 03, 2017 at 09:39:36am -0800, David wrote:
> I’m running Yosemite, Sierra won’t run on my hardware.
> 
> Does the standard expect an int to be a specific size? I can’t imagine this to be the case.
> On Mac ints are 32 bits, as are longs. Unlike Linux where long defaults to 64 bits.

Depends:

$ uname -a
Darwin Old-MBA.local 14.5.0 Darwin Kernel Version 14.5.0: Sun Sep 25 22:07:15 PDT 2016; root:xnu-2782.50.9~1/RELEASE_X86_64 x86_64
$ cat size.c
#include <stdio.h>

int main()
{
	printf("sz(int) = %lu, sz(long) = %lu\n",
		(unsigned long)sizeof(int),
		(unsigned long)sizeof(long));
	return 0;
}

$ cc -o size size.c
$ ./size
sz(int) = 4, sz(long) = 8
$ file size
size: Mach-O 64-bit executable x86_64
$ cc -m32 -o size size.c
$ ./size
sz(int) = 4, sz(long) = 4
$ file size
size: Mach-O executable i386

As I recall the same applies on linux for amd64, with the size of
logn changing depending upon if one compiles as x86 or amd64.

ILP32 vs LP64

DF

[TUHS] MacOS X is Unix (tm)

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 886 bytes --]

David <david at kdbarto.org> wrote:

> I???m running Yosemite, Sierra won???t run on my hardware.
>
> Does the standard expect an int to be a specific size? I can???t imagine this to be the case. On Mac ints are 32 bits, as are longs. Unlike Linux where long defaults to 64 bits.

POSIX requires "int" to be at least 32 bits and all UNIX implementations I am 
aware of, use the LP64 model for the compiler. Here int is 32 and long is 64 
bits.

Microsoft still does and "True64" did use the ILP64 model. This allows lazy 
written software to work even though it does not the right data types for 
pointer arithmetic.

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] MacOS X is Unix (tm)

[Larry McVoy]

On Tue, Jan 03, 2017 at 02:17:00PM +0100, Joerg Schilling wrote:
> Larry McVoy <lm at mcvoy.com> wrote:
> 
> > I'd like to know where you can get a better performing OS.  The file systems
> > scream when compared to Windows or MacOS, they know about SSDs and do the
> > right thing.  The processes are light weight, I regularly do "make -j"
> > which on my machines just spawns as many processs as needed.
> ...
> 
> > So if I size it to the number of CPUs it is slightly faster.  On the other
> > hand, when I tell it just spawn as many as it wants it peaks at about 267
> > processes running in parallel.
> >
> > Solaris, AIX, IRIX, HP-UX, MacOS would all thrash like crazy under that 
> > load, their context switch times are crappy.
> >
> > Source: author of LMbench which has been measuring this stuff since the
> > mid 1990s.
> 
> Could you give a verification for this claim please?

First, it was two claims, fast file system, and fast processes.  You 
seem to have ignored the second one.  That second one is a big deal 
for multi process/multi processor jobs.

If you have access to solaris and linux running on the same hardware, 
get a copy of lmbench and run it.  I can walk you through the results
and if LMbench has bit rotted I'll fix it.

http://mcvoy.com/lm/bitmover/lmbench/lmbench2.tar.gz

> >From what I can tell, the filesystem concepts in Linux are slow and it is 
> usually not possible to tell what happened in a given time frame. It however
> creates the impression that it is fast if you are the only user on a system,
> but it makes it hard to gauge a time that is comparable to a time retrived 
> from a different OS. This is because you usually don't know what happened in
> a given time.

You are right that Linux has struggled under some multi user loads (but then
so does Netapp and a lot of other vendors whose job it is to serve up files).

There are things you can do to make it faster.  We used to have thousands 
of clones of the linux kernel and we absolutely KILLED performance by walking
all those and hardlinking the files that were the same (BitKeeper, unlike
Git, has a history file for each user file so lots of them are the same 
across different clones).

The reason it killed performance is that Linux, like any reasonable OS,
will put files next to each other.  If you unpack /usr/include/*.h
it is very likely that they are on the same cylinder[s].  When you start
hardlinking you break that locality and reading back and one directory's
set of files is going to force a lot of seeks.

So don't do that.

Another thing that Linux [used to have] has is an fsync problem, an fsync
on any file in any file system caused the ENTIRE cache to be flushed.  
I dunno if they have fixed that, I suspect so.

My experience is that for a developer, Linux just crushes the performance
found on any other system.  My typical test is to get two boxes and time

$ cd /usr && time tar cf - . | rsh other_box "cd /tmp && time tar xf -; rm -rf
/tmp/usr"

I suspect your test would be more like

$ cat > /tmp/SH <<EOF
cd /
for i in *
do	test -d $i || continue
	tar cf /tmp/$i.tar $i &
done
wait
EOF
$ time sh /tmp/SH

and it may very well be that Linux doesn't do that well (though I doubt it
because that's essentially what bkbits.net [our github] was doing and a
dual processor 1ghz athlon with one spinning disk was happily serving up
a bizillion clones of the linux kernel and a lot of other stuff).

[TUHS] MacOS X is Unix (tm)

[Ron Natalie]

> Microsoft still does and "True64" did use the ILP64 model. This allows
lazy written software to work even though it does not the right data types
for pointer arithmetic.
 
Well, there's a predisposition in C for "int" to be the standard word size
of the machine.    On designing for a 64-bit machine, one needs to think
long and hard about the integral sizes.
When we wrote the compilers for the Denelcor HEP, we had that problem.   The
thing had 64-bit words and a partial word mode for 16 and 32 bits.   It
didn't even have the concept of 8-bit math.
We decided that rather than arbitrarily sizing an int to 32, so we had the
char-short-int-long progression, we'd make it the word size.   This means we
had to introduce another keyword for the 32-bit type.
After dismissing "short long" or "long short" as a type, the suggestion was
"medium," but we settled for int32 (this was before the language standards
considered how to manage the system namespaces).

An amusing thing we found basing our code on 4.2 BSD was that there was a
really bad latent bug.     There was a kernel structure that looked like
this:

union  ptrs {
      int* p_int;
      short*  p_short;
      char* p_char;
      long* p_long;
};
   
The kernel would store one sort of pointer in one element and then retrieve
it from another.   This "conversion by union" didn't work on the HEP as the
word pointers had the partial word size encoded in the low order bits.
Reading out a short* where an int* was stored caused the processor to access
the wrong sized entity (though roughly in the proper location).    I had to
run all over the kernel changing those to a void* so that the generated code
could properly convert to the right pointer type.


Don't get me started on the inanity that states that "char" is the smallest
addressable integer.   Char should have been divorced from the integer
sizings and let be the native CHARACTER size alone.

[TUHS] MacOS X is Unix (tm)

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3388 bytes --]

On Tue, Jan 3, 2017 at 1:04 PM, Joerg Schilling <schily at schily.net> wrote:

> "True64" did use the ILP64 model


DEC's Tru64 for Alpha defaulted to LP64 (ex-DECie, Tru64 hacker et al).
You could get ILP64 with compiler switches, but Tru64 was the first of the
LP64 systems.    We chaired the 64 bit team between the vendors and ISV
etc, but I'll not drag that dirt here.

As I like to point out, the greatest gift DEC had to the industry was their
64 bit (LP64) DEC C and C++​ compiler, after 3-5 years before SGI, Sun et
al. (much of that work lives today as the Intel compiler BTW).    As a
result the ISV had to make their code clean.  When Sun, IBM et al followed
suite a few years later, that had better code to work with***.    Besides
the Gimpel Flexelint  <http://www.gimpel.com/html/flex.htm> (a very cool
program and I recommend it highly for serious programmers in the key of
what Larry has been discussing); Judy Ward's incredible diagnostics in the
DEC C++ front-end was the only tool that I know of that really told you
what was going on in your code (funny, I literally am typing this message
after I just returned from lunch with her today, and we we talking about
what we had to do in those days to help people).

Since, I've taken on the topic in Quora so I'll not overly repeat myself
here - there in more detail in that post.  But it really comes down to the
this:  early (v7 and before) C code assumed sizeof(int) == sizeof(*int).
When the Vax was introduced, it was just easier to  go ILP32 when moving
code from the old compilers and in the case of the Vax that made sense but
was not always true.  I personally built an early 68000 compiler that was
LP32 and the MIT guys did it ILP32 in their compiler.  I had no tools like
we would have later, so porting code to the 68000 could >>sometimes<< be an
issue.   The MIT compiler (or its children) became the standard C compiler
for most of the 68000 code [we both were "right"  depending on your design
preference - speed of port vs speed of execution].

When we did Alpha, we had >>long discussions<< about word size.   It was
agreed that LPxx was not reasonably safe (and that proved to be true).  The
problem was that -1 @ 64bits is not 0xFFFFFFFF and those sorts of errors
>>were<< riddled through much code.


Today, I think many of those error have been found, and the fact that most
Intel*64 compilers use LP64 also and code pretty much works is a tribute to
that work.    That said, when we start using a 128bit int, I'm sure "dirty"
code will appear.   If I recall, the Gimpel guys will warning you when you
have a bit mask.

*** Picking on a Sun and the Sun ISV's here a little.   I love to tell the
stories (<-- plural) of ISV's that found their bugs rate on Solaris drop
after the Tru64 port; because we forced them to clean up their act some.
The Sun compiler would accept most anything and generate code, and as Larry
says, much of the resultant code was garbage.   While I can write crappy
program in any language, a compiler with excellent warnings or tools like
Flexelint, will not rid you of structural stuff, it will at least make what
it written unambiguous and thus less likely to take a surprising nose dive
in the field.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170103/5348308e/attachment.html>

[TUHS] MacOS X is Unix (tm)

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 326 bytes --]

On Tue, Jan 3, 2017 at 1:33 PM, Clem Cole <clemc at ccc.com> wrote:

> LPxx was not reasonably safe


​grrr - dyslexia-r-me   LPX was NOW reasonably safe​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170103/a912a199/attachment.html>

[TUHS] MacOS X is Unix (tm)

[Ron Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1526 bytes --]

Yeah, we were kind of unique in developing a few products that cut across many UNIX architectures:

 

Sun 4.1.3 / Solaris 2.0

DEC Alpha

HP 9000 (in various incarnations)

SGI in various incarnations (Oxygen, O2, Onyx, …)

Intel processors in both 32 and 64 bit modes

Ardent

Stellar G1000

MIPS (both MIPS’s native workstation and the DEC SPIM machine)

Some i860 machines from IBM and Oki

IBM RS6000

Cray YMP.

 

The latter was the one that really had some issues.    The thing really only had char and word.   Int, short, and long were all 64 bits.    That one discovered a portability hack.   At least I had put a diagnostic in to catch the fact I hadn’t implemented such a case in the generic code.    I got a call from the guy doing to port (he had to go to the Cray offices) to tell me that the first thing the product said was “You’ve got to be kidding.”

 

Later we bopped back and forth between various NT-based systems including Intel at 32 and 64 bits (don’t get me started about the inane DWORD_PTR type which is not a pointer nor a double word) and on the iTanium (which we dubbed the iTanic).   Never got around to trying the NT Alpha.

 

Not only type sizing issues but having to worry about byte order, etc…

 

I still remember finding a #define notyet 1 in one piece of code on the Ardent…that onewas scary.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170103/afea1887/attachment-0001.html>

[TUHS] MacOS X is Unix (tm)

[Random832]

On Tue, Jan 3, 2017, at 13:04, Joerg Schilling wrote:
> Microsoft still does and "True64" did use the ILP64 model. This allows
> lazy 
> written software to work even though it does not the right data types for 
> pointer arithmetic.

Microsoft uses IL32LLP64 - I don't know what Tru64 uses - google
suggests it's LP64. Wikipedia suggests there was an early port of
Solaris that used ILP64.

[TUHS] MacOS X is Unix (tm)

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1448 bytes --]

Larry McVoy <lm at mcvoy.com> wrote:

> First, it was two claims, fast file system, and fast processes.  You 
> seem to have ignored the second one.  That second one is a big deal 
> for multi process/multi processor jobs.

Both are not aligned with my experiences. 

Note that I replaced Linux from the central web server for berlios.de 
by Solaris around 2005 and that resulted in a noticeable increased overall 
performance which includes fast processes.

> If you have access to solaris and linux running on the same hardware, 
> get a copy of lmbench and run it.  I can walk you through the results
> and if LMbench has bit rotted I'll fix it.
>
> http://mcvoy.com/lm/bitmover/lmbench/lmbench2.tar.gz

I contacted a friend and we are going to set up such a machine and do tests.
This however will take a few weeks.

BTW: I am not using "tar" for my tests but rather "star" as "tar" is too 
unspecific to be used for comparisons and as known implementations (including 
"gtar") are too slow to use them for performance metering.

Since SEEK_HOLE/SEEK_DATA is available, "star -copy ..." is e.g. at least 10% 
faster than any other copying tool, including ufsdump/ufsrestore.

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] MacOS X is Unix (tm)

[jsteve]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3124 bytes --]

NT on the Alpha was... interesting.  The C compiler was a team effort between Microsoft and Dec, but it really really had issues. I had to compile just about anything on /OD ie, no optimizations for anything to really be workable across 2 machines.  The joke being that once they had a solid C compiler, in Visual C++ 6.0 / Visual Basic 6.0 Digitial went to Compaq, and they killed NT Alpha as it was always a threat to Compaq i386 servers.

Alpha servers running NT were basically for people that had gotten themselves in a corner, and needed higher performance, price be damned... And Windows NT 4.0 Entperprise on 8way and UP NT boxes were not cheap by any stretch.  I’ve only seen one in use, and it was a giant DEC Alpha with at the time for 1998 insane specs that would be trivial today... But it was running MS SQL 7.0 for some airline ticking place that used old starship captains as their mascot.  

Qemu can run the MIPS version Windows NT, which is once you’ve installed it, from a user perspective really no different from the i386 version of Windows NT.  The last version of Internet Explorer for the MIPS is version 3.0, which to say is ancient is an understatement.  

Naturally on the Pathworks CD I have, it only has an i386 and Alpha client.  DEC didn’t think you’d dare use Cterm on a PowerPC or MIPS running NT.  Not that it really matters these days, outside of HECnet.

Sent from Mail for Windows 10

From: Ron Natalie
Sent: Thursday, 5 January 2017 2:57 AM
To: 'Clem Cole'; 'Joerg Schilling'
Cc: 'TUHS main list'; david at kdbarto.org
Subject: Re: [TUHS] MacOS X is Unix (tm)

Yeah, we were kind of unique in developing a few products that cut across many UNIX architectures:

Sun 4.1.3 / Solaris 2.0
DEC Alpha
HP 9000 (in various incarnations)
SGI in various incarnations (Oxygen, O2, Onyx, …)
Intel processors in both 32 and 64 bit modes
Ardent
Stellar G1000
MIPS (both MIPS’s native workstation and the DEC SPIM machine)
Some i860 machines from IBM and Oki
IBM RS6000
Cray YMP.

The latter was the one that really had some issues.    The thing really only had char and word.   Int, short, and long were all 64 bits.    That one discovered a portability hack.   At least I had put a diagnostic in to catch the fact I hadn’t implemented such a case in the generic code.    I got a call from the guy doing to port (he had to go to the Cray offices) to tell me that the first thing the product said was “You’ve got to be kidding.”

Later we bopped back and forth between various NT-based systems including Intel at 32 and 64 bits (don’t get me started about the inane DWORD_PTR type which is not a pointer nor a double word) and on the iTanium (which we dubbed the iTanic).   Never got around to trying the NT Alpha.

Not only type sizing issues but having to worry about byte order, etc…

I still remember finding a #define notyet 1 in one piece of code on the Ardent…that onewas scary.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170311/838f7a5d/attachment-0001.html>

[TUHS] MacOS X is Unix (tm)

[Derrik Walker v2.0]

I still have a stack of the "Mac OS X: Sends other UNIX boxes to 
/dev/null" posters someplace.

What a blast from the past!

- Derrik

-- 
-- Derrik

Derrik Walker v2.0, RHCE
dwalker at doomd.net

"Those UNIX guys, they think weird!" -- John C. Dvorak


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3703 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170311/09ca68b4/attachment.bin>

[TUHS] MacOS X is Unix (tm)

[Paul Winalski]

On 3/11/17, jsteve at superglobalmegacorp.com
<jsteve at superglobalmegacorp.com> wrote:
> NT on the Alpha was... interesting.  The C compiler was a team effort
> between Microsoft and Dec, but it really really had issues. I had to compile
> just about anything on /OD ie, no optimizations for anything to really be
> workable across 2 machines.  The joke being that once they had a solid C
> compiler, in Visual C++ 6.0 / Visual Basic 6.0 Digitial went to Compaq, and
> they killed NT Alpha as it was always a threat to Compaq i386 servers.

The C compiler for Windows NT on Alpha was a hybrid--the front end was
the basically unmodified from Visual C++, and the code generator was
the GEM back end that all of DEC's compilers for Alpha used.  There
was an intermediate language translator that converted the output from
the VC++ front end to GEM IL.  DEC's GEM team had no access to the
VC++ front end source code--we worked from the Microsoft IL
specification.  A lot of the early instability of the Alpha NT C
compiler was due to cases where the IL spec was vague, or where things
didn't work quite as advertised.  Technically, it was an interesting
project to work on (sometimes in the old Chinese curse sense of
"interesting").

-Paul W.