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_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 22613 invoked from network); 5 Apr 2021 03:00:06 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 5 Apr 2021 03:00:06 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 357109CA7F; Mon, 5 Apr 2021 13:00:05 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id B129B9CA5B; Mon, 5 Apr 2021 12:59:12 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="nIgiTYn3"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 899F19CA5B; Mon, 5 Apr 2021 12:59:10 +1000 (AEST) Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) by minnie.tuhs.org (Postfix) with ESMTPS id 7ABE59C883 for ; Mon, 5 Apr 2021 12:59:09 +1000 (AEST) Received: by mail-pl1-f180.google.com with SMTP id v8so5000071plz.10 for ; Sun, 04 Apr 2021 19:59:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=L4PQGTi9BxrtaVSEyRdgMaUxdgr4vd8xPEPypIaifQk=; b=nIgiTYn3HF4gvIKHP36bnf86v+yzzLSIQrDMIwDTSyG26l75lvR4K25md5BvdgU/ct TZft1a3dCx1BJgH8XDKvMEqO/oGPip/1dqZSVoF5zCx2NjKXNliXUCcyfvbgkUUyWaSt KppCQMvecsakHlEYaDhykOrt62pnMsjTKt104FD/YeI5eemntHlpwSErDLmxLoqzE0xw tteG91rRKWP7c7g6/+FhzsD4zBURZe37GyaV5+sI++ICK4Zb3hGVPXbdT6Wq33k35Nt8 gJeDqtFLjeMT/wjXwqay79nkTRxR2EvlBDW/jf/6t/B8Ou0onqsYTfyHZX4AXSSUwtOn 8RTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=L4PQGTi9BxrtaVSEyRdgMaUxdgr4vd8xPEPypIaifQk=; b=C7A8v8JwjzI9IsQTiJ3YX+nZGJvFxNCzoB5QBwXWO4I9A1a18UxdML2liB7bHHztS0 NibVMzx3Pq5YCFnVguRKs2uBvCmHdBgwqswNw8xiVBq6wsoQKNOxXRFHBqFwQ672MCxl cQsVky0BLCN9VRIs3PjtHCOWYBaz5BVfiRqHb1I5Z6k0xSIhUteWcwQkYuCREx6he6UB kNHyOfWD2Yu1Ir3bPr8uBLU3Z2Q+WGFe1mGidF9Gc4gwQMKRn6UGaKOqh5LDSzFAgfsU WkWSIxrDF88/N6AKD6bh/qYxkwhQijPS9TlmNJknrTnUdn2cDWcBLOQDq8gdSTFWbmMQ La0Q== X-Gm-Message-State: AOAM532CX/UkTP/uPn1SgMtXyr+kvPebHDwMQCf4VZ30/qRPZ/BFCXY8 9Xcojoj83ApiHldIjm5RAp5kdkmvqznPe7a2kKM= X-Google-Smtp-Source: ABdhPJywrvbY34jb0QWxWbnhoGBK0uT/8ya+KEnRln9ptUXiCqyOrMweTOjw/Yr/Ar0qLXu0NV3evBQatp38yXuUTl0= X-Received: by 2002:a17:90b:360b:: with SMTP id ml11mr23778942pjb.98.1617591548737; Sun, 04 Apr 2021 19:59:08 -0700 (PDT) MIME-Version: 1.0 References: <584DED5A-1226-4AF7-A191-C34CAFA53686@pobox.com> <20210404022356.GR28660@mcvoy.com> <20210404085520.GA6494@naleco.com> <9BF72B30-C353-4F61-8DF0-738F8E9536EE@iitbombay.org> In-Reply-To: <9BF72B30-C353-4F61-8DF0-738F8E9536EE@iitbombay.org> From: Kenneth Goodwin Date: Sun, 4 Apr 2021 22:58:57 -0400 Message-ID: To: Bakul Shah Content-Type: multipart/alternative; boundary="000000000000a77a8105bf30e1d6" Subject: Re: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: TUHS main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --000000000000a77a8105bf30e1d6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On storage discipline- UNIX derived systems deliberately don't enforce file formats. In the UNIX philosophy Everything is a file. Inter program portability can be achieved in a multitude of ways. Pure ascii format with either defined field widths or the more common "special character" delimited fields. Ie pipe delimited or comma or : delimited. xml formatted. There are several conversion programs available as well as write your own. On Sun, Apr 4, 2021, 9:36 PM Bakul Shah wrote: > On Apr 4, 2021, at 4:33 PM, Clem Cole wrote: > > > > On Sun, Apr 4, 2021 at 7:01 PM Bakul Shah wrote: > >> >> >> On Apr 4, 2021, at 3:25 PM, David Arnold wrote: >> >> For us UNIX historians, we need to be careful and learn from our own >> history here -- the Cell Phone/Mobile target is the engine for the next >> Christenian style disruption. It is by far the #1 target for people >> writing new programs (which I find a little sad personally - but I >> understand and accept -- time has marched on). In the end, a small mobi= le >> target will be the tech on top, and available will be driven by market >> behavior and those suppliers will be "who has the gold.=E2=80=9D >> >> >> I feel I should point out that both the dominant mobile operating system= s >> are Unix-hased. The UI is necessarily new, but astonishingly the 50 yea= r >> old basic abstractions are the same. >> >> >> Except Unix is kind of hard to see. It wasn't just the hierarchical file >> system but the idea of composability. Even now we whip up a shell >> "one-liners" to perform some task we just thought of. All that is lost. = And >> not just on mobile devices. For example search through email messages fo= r >> something in an email "app". And no UI composability. We have to use >> extremely heavyweight IDEs such as X-Code weighing at 15GB (even "du -s >> /Application/X-code" takes tens of seconds!) to painstakingly construct = a >> UI. We can't just whip up a dashboard to measure & display some realtime >> changing process/entity. There may be equally heavyweight third party to= ols >> but there has been no Bell Labs like research crew to distill it down to >> the essence of composable UI and ship it with every copy. The idea that >> users too can learn to "program" if given the right tools. >> > > Exactly my point. The only difference I suspect is I just don't bother > with the IDE (Xcode or VS). Frankly, vi/emacs, or as we discussed a few > days ago, ed is still way more preferable when I'm programming. > > > Many things are easier to convey visually. It would be neat if unix > paradigms can be extended to visual design as well. And you certainly can= 't > do visual design easily in vi/emacs. Just like in Autocad you need both > interactivity and programmability for creating visual elements. > > I mentioned in another email Intel's new development suite - OneAPI. > Absolutely speaking for myself here, I am a bit at odds with management W= RT > to much of it, as I feel the direction is a bit miss guided. But I do > understand why Intel is doing it/trying. Everyone in the industry seems > to be saying "use my Framework, my language, my solution and I will solve > your problem." "You will sell more copies of the program if you use my > portal, *etc*." Intel to compete, needs to do the same things. To > me, it seems a bit like fairy dust - a promise that will work for a set o= f > people, and of course, some firms like my own employer will keep making > money (or in the words of the Dr. Sueuss Lorax character: "Biggering and > Biggering." As I said in the previous message, it is driven by the othe= r > golden rule. > > > IMHO a bigger need is some discipline on storage. As things stand, it is > hard to extract data from applications for legitimate uses but not so har= d > to extract for illegitimate uses. If app A for some specific domain dies, > there is no guarantee that app B for the same domain can use A's data. > > What I always felt made UNIX powerful was that it did not seem like the > BTL folks were trying to sell anything. They were trying to solve real > problems they and the folks at AT&T had when it came to realistically > building and deploying systems. Yes, there were hidden from the profit > motive at the time because of the unique rules of the 1956 consent degree > and we all were winners because of it because they say -- sure here you c= an > use it too. > > > Similar conditions existed and exist to a certain extent in research orgs > of some companies but I think that is a necessary condition, not > sufficient. The right research crew can bring in another kind of > interactivity -- in creativity, in trying out and critiquing each others' > ideas and building on them. And you still need the right key people. > > Now that we are back to a winner take all market, (OSVM/360 *vs.* VMS > *vs.* winders ...) I think we have traded away designing for the sake of > getting the job done properly, for designing to sell as many as possible = ( > *i.e.* be sexy and capture a market, not be simple and do the job well). > > > --000000000000a77a8105bf30e1d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On storage discipline-=C2=A0
UNIX derive= d systems deliberately don't enforce file formats. In the UNIX philosop= hy=C2=A0
Everything is a file.

Inter program portability can be achieved in = a multitude of ways.

Pur= e ascii format with either defined field widths or the more common "sp= ecial character"=C2=A0 delimited fields. Ie pipe delimited or comma or= : delimited.

xml format= ted.

There are several c= onversion programs available as well as write your own.

On Sun, Apr 4,= 2021, 9:36 PM Bakul Shah <bakul@= iitbombay.org> wrote:
On Apr 4, 2021, = at 4:33 PM, Clem Cole <clemc@ccc.com> wrote:


On Sun, Apr 4= , 2021 at 7:01 PM Bakul Shah <bakul@iitbombay.org> wrote:


On Apr 4, 2021, at 3:25 PM, David Arnold <david= a@pobox.com> wrote:

=C2=A0For us UNIX historians, we need to b= e careful and learn from our own history here -- the Cell Phone/Mobile targ= et is the engine for the next Christenian style disruption.=C2=A0 It is by= =C2=A0far the #1 target for people writing new programs (which I find a lit= tle sad personally - but I understand and accept -- time has marched on).= =C2=A0 In the end, a small mobile target will be the tech on top, and avail= able will be driven by market behavior and those suppliers will be "wh= o has the gold.=E2=80=9D

I feel I should point out that both the dominant m= obile operating systems are Unix-hased.=C2=A0 The UI is necessarily new, bu= t astonishingly the 50 year old basic abstractions are the same.

Except Unix is kind of hard to see. It wasn't just the hie= rarchical file system but the idea of composability. Even now we whip up a shell "one-liners= " to perform some task we just thought of. All that is lost. And not j= ust on mobile devices. For example search through email messages for someth= ing in an email "app". And no UI composability. We have to use ex= tremely heavyweight IDEs such as X-Code weighing at 15GB (even "du -s = /Application/X-code" takes tens of seconds!) to painstakingly construc= t a UI. We can't just whip up a dashboard to measure & display some= realtime changing process/entity. There may be equally heavyweight third p= arty tools but there has been no Bell Labs like research crew to distill it down to the essence of compo= sable UI and ship it with every copy. The idea that users too can le= arn to "program" if given the right tools.=C2=A0

Exactly my point.=C2=A0 T= he only difference I suspect is I just don't bother with the IDE (Xcode= or VS).=C2=A0 =C2=A0Frankly, vi/emacs, or as we discussed a few days ago, = ed is still way more preferable when I'm programming.

Many things are easier to con= vey visually. It would be neat if unix paradigms can be extended to visual = design as well. And you certainly can't do visual design easily in vi/e= macs. Just like in Autocad you need both interactivity and programmability = for creating visual elements.

I mentioned in another=C2=A0email Intel's new development = suite - OneAPI.=C2=A0 Absolutely speaking for myself here, I am a bit at od= ds with management WRT to much of it, as I feel the=C2=A0direction is a bit= miss guided.=C2=A0 =C2=A0But I do understand why Intel is doing it/trying.= =C2=A0 =C2=A0Everyone in the industry seems to be saying "use my Frame= work, my language, my solution and I will solve your problem."=C2=A0 &= quot;You will sell more copies of the program if you use my portal, etc<= /i>."=C2=A0=C2=A0Intel to compete, needs to do the same thi= ngs.=C2=A0 =C2=A0=C2=A0=C2= =A0To me,=C2=A0it seems a=C2=A0bit like fairy dust - a promise that will wo= rk for a set of people, and of course, some firms like my own employer will= keep making money (or in the words of the Dr. Sueuss Lorax character: &quo= t;Biggering and Biggering."=C2=A0 =C2=A0As I said in the previous mess= age, it is driven by the other golden rule.
<= /blockquote>
IMHO a bigger need is some discipline on storage= . As things stand, it is hard to extract data from applications for legitim= ate uses but not so hard to extract for illegitimate uses. If app A for som= e specific domain dies, there is no guarantee that app B for the same domai= n can use A's data.

=
What I always felt made UNIX powerful was that it did not seem like the BT= L folks were trying to sell anything.=C2=A0 They were trying to solve real = problems they and the folks at AT&T had when it came to realistically b= uilding and deploying systems.=C2=A0 =C2=A0Yes, there were hidden from the = profit motive at the time because of the unique rules of the 1956 consent d= egree and we all were winners because of it because they say -- sure here y= ou can use it too.

Similar conditions existed and exist to a certain extent in research orgs= of some companies but I think that is a necessary condition, not sufficien= t. The right research crew can bring in another kind of interactivity -- in= creativity, in trying out and critiquing each others' ideas and buildi= ng on them. And you still need the right key people.

Now that we are back to a winner t= ake all market, (OSVM/360 vs. VMS vs. winders ...) I think we= have traded away designing for the sake of getting the job done properly, = for designing to sell as many as possible (i.e.=C2=A0be sexy and cap= ture a market, not be simple and do the job well).

--000000000000a77a8105bf30e1d6--