From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from minnie.tuhs.org (minnie.tuhs.org [50.116.15.146]) by inbox.vuxu.org (Postfix) with ESMTP id DC9AB260C0 for ; Mon, 24 Jun 2024 17:18:13 +0200 (CEST) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 08D9E43318; Tue, 25 Jun 2024 01:18:08 +1000 (AEST) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) by minnie.tuhs.org (Postfix) with ESMTPS id 552F443317 for ; Tue, 25 Jun 2024 01:18:01 +1000 (AEST) Received: by mail-pl1-x62a.google.com with SMTP id d9443c01a7336-1f9aeb96b93so31898485ad.3 for ; Mon, 24 Jun 2024 08:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1719242281; x=1719847081; darn=tuhs.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=3QY8bwTcbCDkXns/aRHnyqRZtdkBBrEuemwL5UwXRSU=; b=nxXFRWE76UqS3GaqT447jCC/o8UIJrvdFO7GZ7XE1YNjcxinEeNFT4ygfmRtAgnVGC pv28/3bIzWxmdaEkvcNf6qdd50DFCV0NPW0qi8xJv1T4kAqtjDpu/fCy5eb21H65W8H8 lg8aMAhWc/pjoSYaQi6s2tX1ey989S5iGN+dPC7iRAyTZVcblFA9/aWaoWL6hc20+Dcv m7hU/31aDiLQmta9KewzrO1MWQzvsGkBV8Mi4XUd677a/3NJgTIKNUoe0I2ZdLzHLfSu iQNFt+aRYeL5+VmGzga3ZFl4KRkjhshcDLCc2uTyJup/mCogPQMHetcuWjJSdmV+0ncb XJfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719242281; x=1719847081; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=3QY8bwTcbCDkXns/aRHnyqRZtdkBBrEuemwL5UwXRSU=; b=bghrrfpvrZrimBpk5rHhZeb3ZOdDqKy2K6uBo2u7UP6ZZug5eFr5TckBRbbbbIr3cV rDW0Ovy4djaikXfGTW7GJIuiRwWqqxFjs7iqSAsFliHXW7Em2E3vwdwDrVO3WOCbGRXW IPrWYEd36ZzlwdhD4bgc6GDAM5JweFpsMuMPhoo+9FucX947w//LV6DPehJO1e1cJymP gHPTIPAB0Hen8V8gRwow1rtnOsKJAAd9mJLUXOCblsbcRBCCn27lKa5SAxF39MyznnmA OlNU5g5qgdCC9zEX9Pg/ekQQ1AhFmMvxUiVmsaZVQADhlUiJaegn5ZaugsU7I05qZ7TG pf7g== X-Forwarded-Encrypted: i=1; AJvYcCVSNIyhlI8QZEPSW2759+DmjGTnJ2UArzBGbmZD6RS90lDfR/JoyI2xFTkNf9Nf6lG8TsmtQnjIqnAgE4n3 X-Gm-Message-State: AOJu0Yzvz5EfCy3NmddoKMyR07ju+UJuhqCPjtWerHeu2/YkRezacrak mMB8IUE9CWgeckvHoTFq1okU76ViACeV3b/kDlRQQGZ/FpJh5Hf9+OECZtzpqc4hiTFda2Yt/0q J+fYcX9vY5M+EdhqHv4X/vTS58mrp1GWnfY4Npg== X-Google-Smtp-Source: AGHT+IEW0mu2PMGER3w/sTVOpxlU4XsxDeDnkKlamSsIYKzWR8Kj+7zbkpsPQBy1UkNo7nS5b8sZEH4P6X5DD6kbCog= X-Received: by 2002:a17:90a:b116:b0:2c8:858:7035 with SMTP id 98e67ed59e1d1-2c8614096cemr3476299a91.25.1719242280625; Mon, 24 Jun 2024 08:18:00 -0700 (PDT) MIME-Version: 1.0 References: <87jzikt900.fsf@gmail.com> <877cej5gsp.fsf@gmail.com> <87le2xvo4y.fsf@gmail.com> <76644602-7257-4050-b625-050966280e1c@case.edu> <1d0f3aa8-af0c-1ee2-7625-7dc1a825c457@makerlisp.com> <6e98901c-16cd-9a46-105e-8e694353c666@riddermarkfarm.ca> <20240624140337.GB280025@mit.edu> In-Reply-To: From: Warner Losh Date: Mon, 24 Jun 2024 09:17:49 -0600 Message-ID: To: Dan Cross Content-Type: multipart/alternative; boundary="0000000000006b8a06061ba4497f" Message-ID-Hash: PS2CXQ3TUTJCQSM6FKVKI7SBC4KKW7ZE X-Message-ID-Hash: PS2CXQ3TUTJCQSM6FKVKI7SBC4KKW7ZE X-MailFrom: wlosh@bsdimp.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Stuff Received , tuhs@tuhs.org X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000006b8a06061ba4497f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jun 24, 2024 at 8:33=E2=80=AFAM Dan Cross wrote: > On Mon, Jun 24, 2024 at 10:12=E2=80=AFAM Theodore Ts'o wr= ote: > > On Sun, Jun 23, 2024 at 04:15:40PM -0400, Stuff Received wrote: > > > My opinion is that the authors simply did not have access to other > > > systems or were not interested. Sometimes, one finds a disclaimer to > > > that effect. I understand that but I am irked when they claim POSIX > > > compliance. > > > > I get irked because Posix compliance applies to OS's (a specific > > binary release of the kernel plus userspace runtime environment), and > > not to applications. > > > > Also, compliance implies that it has passed a specific test process, > > after paying $$$$ to a Posix Test Compliance Lab, and said compliance > > certificate gets revoked the moment you fix a security bug, until you > > go and you pay additional $$$ to the Posix compliance lab. Basically, > > it's racket that generally only companies who need to sell into the US > > or European government market were willing to play. (e.g., at one > > point there were Red Hat and SuSE distributions which were POSIX > > certified, but Fedora or Debian never were.) > > > > A project or vendor could claim that there product was a "strictly > > conforming POSIX application[1], but that's hard to actually prove > > (which is why there is no compliance testing for it), since not only > > do you have to limit yourself to only those interface guaranted to be > > present by POSIX, but you must also not depend on any behavior which > > specified to be "implementation defined" (and very often many > > traditional Unix behaviors are technically "implementation defined", > > so that VMS and Windows could claim to be be "POSIX compliant > > implementation".) So a strictly POSIX conforming application was > > likely only relevant for very simple "toy" applications that didn't > > need to do anything fancy, like say, networking. > > Also, what is "POSIX" changes over time: new things are added, and > occasionally something is removed. Indeed, a new version was just > released a couple of weeks ago. So what does it mean to say that some > OS conforms to POSIX? Which version? For some very old systems, > particularly those that are no longer being substantially updated but > that may have conformed to an older version of the standard, they may > have credibly claimed "POSIX compliant" at some point in the past, but > time has left them behind. > Certification only lasts a certain amount of time... And the compliance isn't with POSIX, but POSIX.1-2008 or POSIX.1-2024. The advantage of POSIX, though, is that it tries to keep up with the change= s in interfaces, tastes, etc. So aiming for it is a useful "fuzzy cloud" of what's currently most likely to be portable to most modern (read: released in the last decade or less) systems. > It is unreasonable to constrain program authors to ancient versions of > standards just because some tiny fraction of people want to use an old > system. > Indeed. Ancient systems in general are best dealt with by some common sense build hacks. libposix can handle the missing functionality for people that care about these ancient systems, and "layered" include systems work for systems that are at least new enough to have #include_next (and #include "/usr/include/stdio.h" for those that don't). Pushing that jo= b to a thousand package writers is a loser. I've done this for various older systems that I've dabbled with and it becomes a question of how much is enough... I do similar things to build a few Linux applications on FreeBSD w/o bothering the authors too much (I fix bugs that don't matter on Linux, but make my shim layer smaller though). But that's mostly a modern -> modern so C dialect is identical (enough), and the only troublesome interfaces are the Linux Specific ones which I map to FreeBSD functionality. I've never formalized this since I only have a few I care about that are a bit resistant to accepting FreeBSD patches... > Consider 4.3BSD, for example: it shipped with a compiler that predated > the ANSI C standard, and doesn't understand the ANSI-style function > declaration syntax. Should one restrict oneself to the traditional C > dialect forever? If so, one loses out on the substantial benefits of > stronger type checking. Or consider better string handling functions > that came later (`snprintf` is an obvious example, but I would argue > `strlcpy` and `strlcat` as well). Should we restrict ourselves to > laborious and error-prone shenanigans with `strlen` and `strcpy` just > to keep code running on a Sun4c machine under SunOS 4? I really don't > think so. > Yea. > - Dan C. > > > > (Berkeley sockets couldn't be required because AT&T Streams. Oh, > > joy.) > Sockets are standardized these days in POSIX, though. IPv6 is optional, though if you support it, you have to support it with the interfaces defined. Same with Raw Sockets. But most of that's there (and been there since 2008 or earlier) > > [1] > https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap02.html#= tag_02_02_01 > > > > Can you tell I'm a bit jaded and cynical about the whole Posix > > compliance/conformance thing? :-) > Yea, Just because POSIX says so has been a terrible excuse for doing something silly. FreeBSD has long recognized it. However, in moderation, POSIX is a very good thing. Exact, pedantic, 100% conformance with no flexibility... isn't. Warner --0000000000006b8a06061ba4497f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jun 24, 2024 at 8:33=E2=80=AF= AM Dan Cross <crossd@gmail.com&g= t; wrote:
On Mon= , Jun 24, 2024 at 10:12=E2=80=AFAM Theodore Ts'o <tytso@mit.edu> wrote:
> On Sun, Jun 23, 2024 at 04:15:40PM -0400, Stuff Received wrote:
> > My opinion is that the authors simply did not have access to othe= r
> > systems or were not interested.=C2=A0 Sometimes, one finds a disc= laimer to
> > that effect.=C2=A0 I understand that but I am irked when they cla= im POSIX
> > compliance.
>
> I get irked because Posix compliance applies to OS's (a specific > binary release of the kernel plus userspace runtime environment), and<= br> > not to applications.
>
> Also, compliance implies that it has passed a specific test process, > after paying $$$$ to a Posix Test Compliance Lab, and said compliance<= br> > certificate gets revoked the moment you fix a security bug, until you<= br> > go and you pay additional $$$ to the Posix compliance lab.=C2=A0 Basic= ally,
> it's racket that generally only companies who need to sell into th= e US
> or European government market were willing to play.=C2=A0 (e.g., at on= e
> point there were Red Hat and SuSE distributions which were POSIX
> certified, but Fedora or Debian never were.)
>
> A project or vendor could claim that there product was a "strictl= y
> conforming POSIX application[1], but that's hard to actually prove=
> (which is why there is no compliance testing for it), since not only > do you have to limit yourself to only those interface guaranted to be<= br> > present by POSIX, but you must also not depend on any behavior which > specified to be "implementation defined" (and very often man= y
> traditional Unix behaviors are technically "implementation define= d",
> so that VMS and Windows could claim to be be "POSIX compliant
> implementation".)=C2=A0 So a strictly POSIX conforming applicatio= n was
> likely only relevant for very simple "toy" applications that= didn't
> need to do anything fancy, like say, networking.

Also, what is "POSIX" changes over time: new things are added, an= d
occasionally something is removed. Indeed, a new version was just
released a couple of weeks ago. So what does it mean to say that some
OS conforms to POSIX? Which version? For some very old systems,
particularly those that are no longer being substantially updated but
that may have conformed to an older version of the standard, they may
have credibly claimed "POSIX compliant" at some point in the past= , but
time has left them behind.

Certificatio= n only lasts a certain amount of time... And the compliance isn't
=
with POSIX, but POSIX.1-2008 or POSIX.1-2024.

The advantage of POSIX, though, is that it tries to keep up with the chang= es
in interfaces, tastes, etc. So aiming for it is a useful "= ;fuzzy cloud" of what's
currently most likely to be port= able to most modern (read: released in the
last decade or less) s= ystems.
=C2=A0
It is unreasonable to constrain program authors to ancient versions of
standards just because some tiny fraction of people want to use an old
system.

Indeed. Ancient systems in gene= ral are best dealt with by some
common sense build hacks. libposi= x=C2=A0can handle the missing functionality
for people that care = about these ancient systems, and "layered" include
syst= ems work for systems that are at least new enough to have #include_next
(and #include "/usr/include/stdio.h" for those that don= 9;t). Pushing that job
to a thousand package writers is a loser. = I've done this for various older
systems that I've dabble= d with and it becomes a question of how much
is enough...

I do similar things to build a few Linux applications on = FreeBSD w/o
bothering the authors too much (I fix bugs that don&#= 39;t matter on Linux,
but make my shim layer smaller though). But= that's mostly a modern ->
modern so C dialect is identica= l (enough), and the only troublesome
interfaces are the Linux Spe= cific ones which I map to FreeBSD
functionality. I've never f= ormalized this since I only have a few I care
about that are a bi= t resistant to accepting FreeBSD patches...
=C2=A0
Consider 4.3BSD, for example: it shipped with a compiler that predated
the ANSI C standard, and doesn't understand the ANSI-style function
declaration syntax. Should one restrict oneself to the traditional C
dialect forever? If so, one loses out on the substantial benefits of
stronger type checking. Or consider better string handling functions
that came later (`snprintf` is an obvious example, but I would argue
`strlcpy` and `strlcat` as well). Should we restrict ourselves to
laborious and error-prone shenanigans with `strlen` and `strcpy` just
to keep code running on a Sun4c machine under SunOS 4? I really don't think so.

Yea.
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Dan C.


> (Berkeley sockets couldn't be required because AT&T Streams.= =C2=A0 Oh,
> joy.)

Sockets are standardized the= se days in POSIX, though. IPv6 is optional,
though if you support= it, you have to support it with the interfaces defined.
Same wit= h Raw Sockets. But most of that's there (and been there
since= 2008 or earlier)
=C2=A0
> [1] https:= //pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap02.html#tag_02_0= 2_01
>
> Can you tell I'm a bit jaded and cynical about the whole Posix
> compliance/conformance thing?=C2=A0 =C2=A0:-)
Yea, Just because POSIX says so has been a terrible excuse for = doing something
silly. FreeBSD has long recognized it. However, i= n moderation, POSIX is a very good
thing. Exact, pedantic, 100% c= onformance with no flexibility... isn't.

Warne= r
--0000000000006b8a06061ba4497f--