RE: [EXTERNAL] Re: Help request and introduction

[Jason Zions]

The Open Group created those documents in the first place. They have electronic 
bits; they've never released them. The business model (how to pay for the work 
of developing and maintaining those standards) involved people paying to access 
the docs. The only available enforcement mechanism for that was "dead trees 
only".

"Converting them" would violate the Open Group copyright.

-Original Message-
From: J William Piggott  
Sent: Monday, May 18, 2020 9:15 AM
To: Geoff Clare 
Cc: austin-group-l@opengroup.org
Subject: [EXTERNAL] Re: Help request and introduction



On Mon, 18 May 2020, Geoff Clare wrote:

> J William Piggott  wrote, on 17 May 2020:
>> 1) I am unable to log in to Mantis. My credentials work on other
>>opengroup.org assets, but Mantis fails with:

>
> I have created an account for you and told Mantis to send you a 
> password reset email. (We disabled self sign-up because of spammers.)

Thank you very much; log in was successful.

>
>> 2) Could anyone offer links to, or send me, the xpg3 and xpg4 standards?
>
> They were never released as electronic documents, only paper.

Is there any interest in converting them? I would be willing to do the work (I 
cannot say how long it would take though). Did The Open Group inherit the 
copyrights?

>
>
> --
> Geoff Clare 
> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
>

RE: system() and pthread_atfork()

[Jason Zions]

> From: Schwarz, Konrad  
> Sent: Thursday, January 2, 2020 5:00 AM
> To: Karstens, Nate ; 
> mailto:austin-group-l@opengroup.org
> Subject: [EXTERNAL] RE: system() and pthread_atfork()
> 
>> -Original Message-
>> From: Karstens, Nate 
>> Sent: Thursday, December 19, 2019 12:26 AM
>> To: mailto:austin-group-l@opengroup.org
>> Subject: system() and pthread_atfork()
>> 
>> The current definition of system() does not define if the pthread_atfork() 
>> handlers are called. We ran into a
>> scenario where this caused a problem and wanted to share it with the mailing 
>> list to better understand why those
>> handlers are not required and get some advice on how best to proceed. 
>
> I think the right solution is for POSIX to require system() and popen() to 
> call pthread_atfork() handlers.
> I haven't noticed any arguments against such a solution and it clearly fills 
> a need.
>
> I suggest you open a corresponding defect report on http://austingroupbugs.net

Both system() and popen() will, nearly immediately, exec() completely new 
processes. Under many circumstances, the new processes will not interact with 
objects maintained by any registered pthread_atfork() handlers. Any work those 
handlers do will, in those cases, be completely wasted as a result of the 
exec(). That is one argument against your proposed solution.

I doubt this is "undefined" by accident. In other words, I doubt this is a 
defect. If there's no discussion in rationale, I could see that being a defect, 
but defects in non-normative text are, by definition, not actually defects.

The way to proceed, I believe, is for a portable application to provide its own 
implementations of system() and popen() which provide precisely the semantics 
required by that application. Open source implementations of both system() and 
popen() are readily available and can be altered to call your pthread_atfork() 
handlers as you see fit, without regard to what the platform's implementation 
might, or might not, do.

RE: system() and pthread_atfork()

[Jason Zions]

Both system() and popen() will, nearly immediately, exec() completely new 
processes. Under many circumstances, the new processes will not interact with 
objects maintained by any registered pthread_atfork() handlers. Any work those 
handlers do will, in those cases, be completely wasted as a result of the 
exec(). That is one argument against your proposed solution.

I doubt this is "undefined" by accident. In other words, I doubt this is a 
defect. If there's no discussion in rationale, I could see that being a defect, 
but defects in non-normative text are, by definition, not actually defects.

The way to proceed, I believe, is for a portable application to provide its own 
implementations of system() and popen() which provide precisely the semantics 
required by that application. Open source implementations of both system() and 
popen() are readily available and can be altered to call your pthread_atfork() 
handlers as you see fit, without regard to what the platform's implementation 
might, or might not, do.

From: Schwarz, Konrad 
Sent: Thursday, January 2, 2020 5:00 AM
To: Karstens, Nate ; austin-group-l@opengroup.org
Subject: [EXTERNAL] RE: system() and pthread_atfork()


> -Original Message-

> From: Karstens, Nate 
> mailto:nate.karst...@garmin.com>>

> Sent: Thursday, December 19, 2019 12:26 AM

> To: austin-group-l@opengroup.org

> Subject: system() and pthread_atfork()

>

> The current definition of system() does not define if the pthread_atfork() 
> handlers are called. We ran into a

> scenario where this caused a problem and wanted to share it with the mailing 
> list to better understand why those

> handlers are not required and get some advice on how best to proceed.



I think the right solution is for POSIX to require system() and popen() to call 
pthread_atfork() handlers.

I haven't noticed any arguments against such a solution and it clearly fills a 
need.



I suggest you open a corresponding defect report on 
http://austingroupbugs.net

RE: Are BSDs evidently more fault tolerant than (say) SysV and Linux?

[Jason Zions]

I do not see any way this is related to the business of the Austin Group, and 
the entire discussion should just stop.

-Original Message-
From: Danny Niu  
Sent: Monday, November 25, 2019 6:15 PM
To: Shware Systems ; austin-group-l@opengroup.org
Subject: [EXTERNAL] Re: Are BSDs evidently more fault tolerant than (say) SysV 
and Linux?

Well, when I mention "deep in the kernel", I meant that maybe the BSD kernel is 
better capable of handling mis-behaving user-space processes and crashes, 
sudden disconnection of live-and-hot hardwares, and probably can isolate events 
occurring in the kernel. 

Also, I don't quite understand what is "operator error", does it mean "user 
error"? 

发件人: Shware Systems 
日期: 2019-11-26 09:54:16
收件人: "danny...@hotmail.com" , Austin Group Mailing List 

主题: RE: Are BSDs evidently more fault tolerant than (say) SysV and Linux?

It would help if you were more specific about which varieties of "faults" 
you're thinking of, software related, hardware related, operator error?


On Monday, November 25, 2019 Danny Niu  wrote:
Actually I've also asked this on Unix.StackExchange.com, but it gets closed for 
being too broad, and I can't think of a way to make it specific. 
One of those fellows mentioned it's because the way BSD UFS filesystem 
implemented made it more fault tolerant. 

But I think there must be a more fundamental reason, Somewhere deep in the 
kernel that made the operating system family More fault tolerant than others. 

Does anyone on the list know where such mention exist(ed)? 

Thanks. 

RE: Bug 1228: allow shells to exclude "." and ".." from pathname expansions

[Jason Zions]

The amount of sheer invention swirling around this issue is amazing.

The question "Does POSIX / WG15 / OpenGroup create new interfaces out of whole 
cloth" was settled more than two decades ago. I was in the room when it 
happened. The answer to that question is "No". In the POSIX/WG15/OpenGroup 
world, a "Sane Standard" documents what implementations do, not what some 
collection of individuals believe they ought to do.

There are no implementations that have a "globskipdot" option or anything like 
it. The fact that the standard does not document such a (non-existent in any 
real implementation) option cannot be regarded as an error to be corrected; 
this is invention.

If the MOA which governs the behavior of the IEEE POSIX standards committee, 
JTC1/SC21/WG15, and The Open Group with respect to IEEE 1003 and ISO/IEC 9945 
has been altered to allow or encourage invention, it's news to me. And should 
this committee decide to go there, I can promise an avalanche of sheer 
invention will arrive within the next year, if I have to spend vacation time to 
dream it up and find a half-dozen sock puppets with whom I can forge consensus 
with regard to "need" and "sanity".

This door was slammed shut and welded closed. That's not how POSIX changes 
anymore, for better or worse.

You want to make this change? Show me two mainstream implementations that 
address the issue. Even if they need harmonization, that's a place to start. 
The old TCOS-SS SEC PAR Evaluation Criteria didn't have a hard and fast rule 
for just how "mainstream" it had to be, but 0.1% of the installed base of 
recent releases of UNIX (and now Linux) wouldn't have met the bar. But without 
real world implementations to examine, without a pool of real-world experience 
with the proposed feature to draw on, this is inappropriate for consideration 
for the POSIX standard.

What was the old rule of thumb? "If it's not boring, it's not ripe for 
standardization." The amount of argument in this thread alone demonstrates that 
"boring" doesn't apply here.

Implementations drive the standard into new content. The standard does not  
drive implementations into new code.

Jason Zions

-Original Message-
From: Andreas Grapentin  
Sent: Tuesday, June 4, 2019 6:12 AM
To: Joerg Schilling 
Cc: nickstough...@gmail.com; dwhee...@ida.org; austin-group-l@opengroup.org; 
a...@gigawatt.nl
Subject: Re: Bug 1228: allow shells to exclude "." and ".." from pathname 
expansions


This discussion seems to currently spiral into conflicting opinions about 
whether sane shell globbing of .*/ should include `../' and `./'.
However, the originally discussed issue was whether the introduction of an 
option to control the globbing behaviour of the shell should be specified in 
the standard or not.

I would personally offer the opinion that any `sane' or `expected'
behavior must depend on the use case. Situations can be constructed where each 
of the two possible behaviours can be desirable:

  # should probably not include ../
  $ rm -r .*/

  # should probably include ../
  $ grep '#include' .*/*.{c,h}

As such, I would agree that it seems to make sense to specify a globskipdot 
option in the shell and require consistent behaviour from readdir across 
filesystems. Especially since for the application an argument produced by a 
glob expansion is indistinguishable from one typed explicitly.

The next question to answer though, would then be what the default setting for 
the option should be... :)

Best,
Andreas


-- 

--
my GPG Public Key: https://files.grapentin.org/.gpg/public.key
--