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, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 14479 invoked from network); 5 Apr 2021 20:45:17 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 5 Apr 2021 20:45:17 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 31FA79CA96; Tue, 6 Apr 2021 06:45:17 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 2BFDC9C883; Tue, 6 Apr 2021 06:44:42 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="key not found in DNS" (0-bit key; unprotected) header.d=kev009.com header.i=@kev009.com header.b="P96h2//X"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 981009C883; Tue, 6 Apr 2021 06:44:40 +1000 (AEST) Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com [209.85.219.179]) by minnie.tuhs.org (Postfix) with ESMTPS id 576E39C83D for ; Tue, 6 Apr 2021 06:44:39 +1000 (AEST) Received: by mail-yb1-f179.google.com with SMTP id z1so13780047ybf.6 for ; Mon, 05 Apr 2021 13:44:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kev009.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=D6BRP3lD3TZYpYFxCsO9SsBccPfqWBDbPSe644+np0U=; b=P96h2//XNg6TVqDIIfwU76CLi4q9I60vGMxKBXOKGE2j+oJZog4+8JegTrkd20ezwL HjnTCZOpqMKZpFUsY3hkDXfJjsTqaovpLEdcoqS9wlKLBNl71vC5m0wkkkulkLOk3mLZ AAOiAXaE9Y0tWD2jswPSkv+ztDJ1YDtZLAUL8= 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:content-transfer-encoding; bh=D6BRP3lD3TZYpYFxCsO9SsBccPfqWBDbPSe644+np0U=; b=B9IzIhLGJ2DVzyieOiGXl5e1R9OOQ24Q/RYkv8AmvFHRV4JeOFUYaZlhfzIZ1LA7lx jOwX7jvKtOv3iJVc9rXTXqa3NUs/1PWoFwiHocaK2Ll1VYycnfveqpU4t6VAHGKSXzfP CzK6Fj/7eMkDRrY+CvAy05G+AoViuFAXV5BPe/qqzfln+sX5NKhFjQOxcV3Y478FBeT0 2nf3rH+iAbIBOUsm0b270a30EXeoe/W77m1xg+NdLPHLl7eT8vo9Q4LnX0Gm4Yj7jIMb A92cKf+428+53nVOpCJ9m4JDmjdFdERDaKRS3lp558mTJg2gl2Rzy4gr5lODzPf3lDe3 h89w== X-Gm-Message-State: AOAM533rcPDdTrZM8unFmV7nGBQgeFqvqx9rIVZhjxQ3GXkn4afmhG4B PJ+nm7bOkD9cyHBXfrFW61egK/E3/fYKLDDU9d+Fhw== X-Google-Smtp-Source: ABdhPJz72Mzb7fwp9WYID2mtSjFH+w/Afg55wTPcH81XC4lPjb8M1IZjLQXUGcycGQhbfpqNURCG6asvYOOPM1/E428= X-Received: by 2002:a25:ae94:: with SMTP id b20mr2956734ybj.297.1617655478294; Mon, 05 Apr 2021 13:44:38 -0700 (PDT) MIME-Version: 1.0 References: <584DED5A-1226-4AF7-A191-C34CAFA53686@pobox.com> <20210404022356.GR28660@mcvoy.com> <20210404085520.GA6494@naleco.com> In-Reply-To: From: Kevin Bowling Date: Mon, 5 Apr 2021 13:44:26 -0700 Message-ID: To: Clem Cole Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Bakul Shah , TUHS main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On Sun, Apr 4, 2021 at 4:34 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 hi= story here -- the Cell Phone/Mobile target is the engine for the next Chris= tenian 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 acce= pt -- time has marched on). In the end, a small mobile target will be the = tech on top, and available will be driven by market behavior and those supp= liers 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 year= 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-lin= ers" to perform some task we just thought of. All that is lost. And not jus= t on mobile devices. For example search through email messages for somethin= g in an email "app". And no UI composability. We have to use extremely heav= yweight IDEs such as X-Code weighing at 15GB (even "du -s /Application/X-co= de" takes tens of seconds!) to painstakingly construct a UI. We can't just = whip up a dashboard to measure & display some realtime changing process/ent= ity. There may be equally heavyweight third party tools but there has been = no Bell Labs like research crew to distill it down to the essence of compos= able 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 w= ith the IDE (Xcode or VS). Frankly, vi/emacs, or as we discussed a few da= ys ago, ed is still way more preferable when I'm programming. > > I mentioned in another email Intel's new development suite - OneAPI. Abs= olutely speaking for myself here, I am a bit at odds with management WRT to= much of it, as I feel the direction is a bit miss guided. But I do under= stand 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 pr= oblem." "You will sell more copies of the program if you use my portal, et= c." Intel to compete, needs to do the same things. To me, it seems a b= it like fairy dust - a promise that will work for a set of people, and of c= ourse, some firms like my own employer will keep making money (or in the wo= rds of the Dr. Sueuss Lorax character: "Biggering and Biggering." As I sa= id in the previous message, it is driven by the other golden rule. > > What I always felt made UNIX powerful was that it did not seem like the B= TL folks were trying to sell anything. They were trying to solve real prob= lems 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 t= he time because of the unique rules of the 1956 consent degree and we all w= ere winners because of it because they say -- sure here you can use it too. > > Now that we are back to a winner take all market, (OSVM/360 vs. VMS vs. w= inders ...) I think we have traded away designing for the sake of getting t= he job done properly, for designing to sell as many as possible (i.e. be se= xy and capture a market, not be simple and do the job well). You guys are onto an interesting thread. If you have time read this https://danluu.com/essential-complexity/ . One thing I find interesting about this article is Dan, who externally seems at least a magnitude smarter and more productive than me, seems to miss that the approach he uses to debunk Brooks is largely a failure of design that probably predates his entry to the problem by layering ever more accidental complexity instead of solving the essential complexity. For instance, a circular buffer of arbitrary size (to the hardware and monetary constraints of his example) could be used to efficiently hold resource usage and drive important business or engineering decisions. A cascading set of buffers could be used to hold higher fidelity data at the top level and decreasing fidelity for longer time series intervals. It doesn't match his approach, which allows finding signal fidelity in extremely noisy data, but that's a problem of its own creation. The non-UNIX approach to things (IDEs, frameworks, big overlay APIs, microservices etc) definitely help with certain things people are willing to pay a lot of money for. However they lend themselves to creating and fixing ever more accidental complexity with ever more accidental complexity. I guess the thing we really like about UNIX, historically, was that it did a good job at exposing the programmer to the essential complexity. If you need to make things go fast, it's right there in your face. If you need to do resource accounting or just about any other task, there's a way to do it on fundamentally limited hardware. Big hardware and lots of people haven't made the essential complexity easier. UNIX, which was developed with discipline, still exerts a positive effect on the essential complexity in systems development when embraced. When not embraced, it becomes a liability (15GB Xcode). Regards, Kevin