From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 9558 invoked from network); 31 Dec 2021 19:34:49 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 31 Dec 2021 19:34:49 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 5C88A9D00C; Sat, 1 Jan 2022 05:34:48 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 910259CF51; Sat, 1 Jan 2022 05:34:37 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=ccc.com header.i=@ccc.com header.b="dg1v/pc4"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 886B59CF51; Sat, 1 Jan 2022 05:34:35 +1000 (AEST) Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com [209.85.160.180]) by minnie.tuhs.org (Postfix) with ESMTPS id DCA029CF06 for ; Sat, 1 Jan 2022 05:34:34 +1000 (AEST) Received: by mail-qt1-f180.google.com with SMTP id p19so24823123qtw.12 for ; Fri, 31 Dec 2021 11:34:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccc.com; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=ELyelvSSLx08gM97cpse7qnnzwJ0Qpr7jUXIcpd6nm0=; b=dg1v/pc47Uui5zuF02h4YIw3psypcy8TXVOJCi+RKUGAlDNbmktOyhorM7WoEGIGBX BHJHDE0r5CgasWbnRrhfHbptB0LdPf98v54Jl3oWLqsq9HDAy03ZP/2vXwLC4UKarlS5 gJQwR7uRQkhXcxaMZgw1tKF82yceSchn7Z8Qk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=ELyelvSSLx08gM97cpse7qnnzwJ0Qpr7jUXIcpd6nm0=; b=OeQam78U7rpRlQJrz/24FAdzARMfiWyTkggrx3VH9dJNbpocbCt8je0N6nGge3TKOS Af7i+LGuqIeRz6itufmd1K5hJiuJSJU8PDb7RIUeOwuhsuIUs/rkMkfYtd0ZFBkymWSK QgiPhDNJXRZL9wyxoEFnoYYjwuzz8uEscPZtpRRBzAXYRW8qyKbwnt/OJm/0X+U9V9cz aa7CxqndDD0r7Ok75eZb5jSJePr9jqWU9g0z3j5FClwmrG8GPRASLrrUSHrhgRKYB1CY wwEzhKmJrk75GJvHOQUmSpWlMVZNuik7veOslguSr/SVNHa5snuhq9hLfLU6qxo/OGfO onHA== X-Gm-Message-State: AOAM532HueSe0P4nqsdArLzGEUuSOd0nfmLddqkwiLwG1Ze839TOjgns gy4xcym8kbJ7G8SLB3lxbV6FPZU0RyeUUhge0gyolSd2lHpWqg== X-Google-Smtp-Source: ABdhPJyVs2Gga5gZY1ezgCz/YOFZPlTmRYxLl2R1dM/GhvdecfSL34RzUcQ9Y3p7pOUrV01m7rdigq4jnXppY/x4Bj4= X-Received: by 2002:ac8:70d0:: with SMTP id g16mr31361845qtp.71.1640979273616; Fri, 31 Dec 2021 11:34:33 -0800 (PST) MIME-Version: 1.0 From: Clem Cole Date: Fri, 31 Dec 2021 14:34:07 -0500 Message-ID: To: Rob Pike Subject: [COFF] on progress -- was [TUHS] moving directories in svr2 X-BeenThere: coff@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Computer Old Farts Forum List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: COFF Content-Type: multipart/mixed; boundary="===============4369322786682312467==" Errors-To: coff-bounces@minnie.tuhs.org Sender: "COFF" --===============4369322786682312467== Content-Type: multipart/alternative; boundary="000000000000b0258705d476423e" --000000000000b0258705d476423e Content-Type: text/plain; charset="UTF-8" Moving to COFF since while this is a UNIX issue its really attitude, experience and perspective. On Thu, Dec 30, 2021 at 8:01 PM Rob Pike wrote: > Grumpy hat on. > > Sometimes the Unix community suffers from the twin attitudes of a) > believing if it can't be done perfectly, any improvement shouldn't be > attempted at all and b) it's already done as well as is possible anyway. > > I disagree with both of these positions, obviously, but have given up > pushing against them. > > We're in the 6th decade of Unix and we still suffer from unintended, > fixable consequences of decisions made long long ago. > > Grumpy hat off. > > -rob > While I often agree with you and am a huge fan of your work both written and programming, I am going to take a different position: I am very much into researching different solutions and love exploring them and seeing how to apply the lessons, but *just because we can change a change*, *does not always mean we should*. IMOI: *Economics has to play into equation*. I offer the IPv4 to IPv6 fiasco as an example of a change because we could (and we thought it would help - hey I did in the early 1990s), but it failed for economic reasons. In the end, any real change has to take into account some level of economics. The examples of the differences in the shell is actually a different issue -- that was territorial and not economics -- each vendor adding stuff that helped them (and drove IVS/end users of multiple platforms crazy). The reality with SunOS sh vs Ultrix sh vs HP-UX sh vs System V (att sh) was yet another similar but different -- every manufacturer messed with a V7 derivative sh was a little different -- including AT&T, Korn et al. For that matter you (Rob) created a new syntax command with Plan9 [although you did not try to be and never claimed to be V7 compatible -- to your point you break things where you thought it matters and as a researcher I accept that]. But because all the manufacturers were a little different, it was exactly why IEEE said -- wait a minute -- let's define a base syntax which will work everywhere and it is something we can all agree and if we all support it -- great. We did that, and we call that POSIX (and because it was designed by compromise and committee - like a camel it has some humps). *But that does mean compromise -- some agreed 'sh' basics needs to keep the base level.* The problem Ted and Larry describes is real ... research *vs.* production. So it begs the question, at what time does it make it sensible/ (worth it/economically viable) to move on? Apple famously breaks things and it drives me bonkers because many (most I would suggest) of those changes are hardly worth it -- be it my iPhone or my Mac. I just want to use the darned thing BTW: Last week, the clowns at Telsa just rolled out a new UI for my Model S --- ugh -- because they could (now I'm fumbling trying deal with the climate system or the radio -- it would not do bad if they had rolled out a the new UI on a simulator for my iPad so I could at least get used to it -- but I'm having to learn it live -- what a PITA -- that really makes me grumpy). What I ask for this august body to consider is that before we start looking at these changes is to ask what we are really getting in return when a new implementation breaks something that worked before. *e.g.* I did not think systemd bought end users much value able, must like IPv6 in practice, it was thought to solve many problems, but did not buy that much and has caused (continues to cause) many more. In biolog every so often we have an "ice age" and kill a few things off and get to start over. That rarely happens in technology, except when a real Christianen style disruption takes place -- which is based on economics -- a new market values the new idea and the old market dies off. I believe that from the batch/mainframe 1960s/early 70s world, Unix was just that -- but we got to start over because the economics of 'open systems' and the >>IP<< being 'freely available' [which compared to VMS and other really proprietary systems] did kill them off. I also think that the economics of completely free (Linux) ended up killing the custom Unix diversions. Frankly, if (at the beginning) Plan9 has been a tad easier/cheaper/more economical for >>everyone<< in the community obtain (unlike original Unix release time, Plan9 was not the same rules because AT&T was under different rules and HW cost rules had changed things), it >>might<< have been the strong strain that killed off the old. If IPv6 has been (in practice) cheaper to use than IPv4 [which is what I personally thought the ISP would do with it - since it had been designed to help them] and not made as a premium feature (i.e they had made it economically to change), it might have killed of IPv4. Look at 7 decades of Programming Language design, just being 'better' is not good enough. As I have said here and many other places, the reality is that Fortran still pays the salary of people like me in the HPC area [and I don't see Julia or for that matter, my own company's pretty flower - Data Parallel C++ making inroads soon]. It's possible that Rust as a system programming language >>might<< prove economical to replace C. I personally hope Go makes the inroads to replace C++ in user space. But for either to do that, there has to be an economical reason - no brainer style for management. What got us here was a discussion of the original implementation of directory files, WRT links and how paths are traversed. The basic argument comes from issues with how and when objects are named. Rob, I agree with you, that just because UNIX (or any other system) used a scheme previously does not make the end-all. And I do believe that rethinking some of the choices made 5-6 decades ago is in order. But I ask the analysis of the new verse the old takes into account, how to mitigate the damage done. If its economics prove valuable, the evolution to using it will allow a stronger strain to take over, but just because something new vs. the old, does not make it valuable. Respectfully .... Happy new year everyone and hopefully 2022 proves a positive time for all of you. Clem --000000000000b0258705d476423e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Moving to COFF since while this is a UNIX issue its really attitude, e= xperience and perspective.

On Thu, Dec 30, 20= 21 at 8:01 PM Rob Pike <robpike@gmail.com> wrote:
=
Grumpy hat on.

Sometimes the= Unix community suffers from the twin attitudes of a) believing if it can&#= 39;t be done perfectly, any improvement shouldn't be attempted at all a= nd b) it's already done as well as is possible anyway.

I di= sagree with both of these positions, obviously, but have given up pushing a= gainst them.

We're in the 6th decade of Unix and we still s= uffer from unintended, fixable consequences of decisions made long long ago= .

Grumpy hat off.

-rob
While I often agree with you and=C2=A0am a huge=C2=A0fan of your=C2=A0work= both written and programming, I am going to take a different position:
I am very much in= to researching=C2=A0different solutions and love exploring them and seeing = how to apply the=C2=A0lessons, but just because we can change a change, does not always mean we should.=C2=A0 IMOI: Economics has to = play into equation.

<= /div>

I offer the IPv4 to IPv6 fia= sco as an example of a change because we could (and we thought it=C2=A0woul= d help - hey I did in the early 1990s),=C2=A0but it failed for economic=C2= =A0reasons. =C2=A0 In the=C2=A0end, any real change has to take into accoun= t some level of economics.=C2=A0
The examples of the differences in= the shell is actually a different issue -- that was territorial and not ec= onomics=C2=A0-- each vendor adding stuff that helped them (and drove IVS/en= d users of=C2=A0multiple platforms crazy).=C2=A0 The reality with SunOS sh = vs Ultrix sh vs HP-UX sh vs System V (att sh) was yet another similar but d= ifferent -- every manufacturer messed with a V7 derivative sh was a little = different -- including AT&T, Korn et al. =C2=A0 For that matter you (Ro= b) created a new syntax command with Plan9 [although=C2=A0you did not try t= o be and never claimed to be V7 compatible -- to your=C2=A0point you break = things where you thought it matters and as a researcher I accept that]. =C2= =A0 But because all the manufacturers were a little different, it was exact= ly why IEEE said -- wait a minute -- let's define a base syntax which w= ill work everywhere and it is something we can all agree and if we all supp= ort it -- great.=C2=A0 We did that, and we call that POSIX (and because it = was designed=C2=A0by compromise=C2=A0and committee=C2=A0- like a camel it h= as some humps).
But that does mean compromise -- some agreed 'sh' basics needs= to keep the base level.

The problem Ted and Larry describes is real ... research vs.= production.=C2=A0 So it begs the question, at what time does it make it se= nsible/ (worth it/economically viable) to move on?

Apple famously= breaks things and it drives me bonkers because many (most I would suggest)= of those changes are hardly worth it -- be it my iPhone or my Mac.=C2=A0 I= just want to use the darned thing =C2=A0BTW: Last week, the clowns at Tels= a=C2=A0just rolled out a new UI for my Model S --- ugh -- because they coul= d (now I'm fumbling trying deal with the climate system or the radio --= it would not do bad if they had rolled out a the new UI on a simulator for= my iPad so I could at least get used to it -- but I'm having to learn = it live -- what a PITA -- that really makes me grumpy).

What I ask = for this august body to consider is that before we start looking at these c= hanges is to ask what we are really getting in return when a new implementa= tion breaks something that worked before. =C2=A0e.g. I did not think= systemd bought end users much value able, must like IPv6 in practice, it w= as thought to solve many problems, but did not buy that much and has caused= =C2=A0(continues to cause) many more.

In biolog=C2=A0every so often= we have an "ice age" and kill a few things off and get to start = over. That rarely happens in technology, except when a real Christianen sty= le disruption takes place -- which is based on economics=C2=A0-- a new=C2= =A0market values the new=C2=A0idea and the old market dies off. =C2=A0 I be= lieve that from the=C2=A0batch/mainframe 1960s/early 70s world, Unix was ju= st that -- but we got to start over because the economics of 'open syst= ems' and the >>IP<< being 'freely available' [which= compared to VMS and other=C2=A0really proprietary systems] did kill them o= ff. =C2=A0 I also think that=C2=A0the economics of completely free (Linux) = ended up killing the custom Unix diversions.

Frankly, if (at the be= ginning) Plan9 has been a tad easier/cheaper/more economical for >>ev= eryone<< in the community obtain (unlike original Unix release time, = Plan9 was not the same rules because AT&T was under different rules and= HW cost rules had changed things), it >>might<< have been the = strong strain that killed off the old.=C2=A0 If IPv6 has been (in practice)= cheaper to use than IPv4 [which is what I personally thought the ISP would= do with it - since it had been designed to help them] and not made as a pr= emium feature (i.e they had made it economically to change), it might have = killed of IPv4.=C2=A0

Look at 7 decades of Programming Language des= ign, just being 'better' is not good enough.=C2=A0 As I have said h= ere and many other places, the reality is that Fortran still pays the salar= y of people like me in the HPC area [and I don't see Julia or for that = matter, my own company's pretty flower - Data Parallel C++ making inroa= ds soon]. =C2=A0 =C2=A0It's possible that Rust as a system programming = language >>might<< prove economical to replace C.=C2=A0 I perso= nally hope Go makes the inroads to replace C++ in user space.=C2=A0 But for= either to do that, there has to be an economical=C2=A0reason - no brainer = style for management.

What got us here was a discussion of the orig= inal implementation of directory files, WRT links and how paths are travers= ed. =C2=A0 The basic argument comes from issues with how and when objects a= re named. =C2=A0 Rob, I agree with you, that just because UNIX (or any othe= r system) used a scheme previously does not make the end-all. =C2=A0 And I = do believe that rethinking some of the choices made 5-6 decades ago is in o= rder. =C2=A0 But I ask the analysis of the new verse the old takes into acc= ount, how to mitigate the damage done. =C2=A0 =C2=A0 If its economics=C2=A0= prove valuable, the evolution to using it will allow a stronger strain to t= ake over, but just because something new vs. the old, does not make it valu= able.

Respectfully ....

=
Happy new year everyone and hopeful= ly 2022 proves a positive time for all of you.
Clem
--000000000000b0258705d476423e-- --===============4369322786682312467== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KQ09GRiBtYWls aW5nIGxpc3QKQ09GRkBtaW5uaWUudHVocy5vcmcKaHR0cHM6Ly9taW5uaWUudHVocy5vcmcvY2dp LWJpbi9tYWlsbWFuL2xpc3RpbmZvL2NvZmYK --===============4369322786682312467==--