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.5 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from minnie.tuhs.org (minnie.tuhs.org [IPv6:2600:3c01:e000:146::1]) by inbox.vuxu.org (Postfix) with ESMTP id 45DAF27314 for ; Tue, 14 May 2024 13:10:59 +0200 (CEST) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id CA33443328; Tue, 14 May 2024 21:10:48 +1000 (AEST) Received: from mail-oa1-x2e.google.com (mail-oa1-x2e.google.com [IPv6:2001:4860:4864:20::2e]) by minnie.tuhs.org (Postfix) with ESMTPS id 20E8543327 for ; Tue, 14 May 2024 21:10:37 +1000 (AEST) Received: by mail-oa1-x2e.google.com with SMTP id 586e51a60fabf-22ed075a629so3096789fac.3 for ; Tue, 14 May 2024 04:10:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715685035; x=1716289835; darn=tuhs.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=3mtq9R11ezRKEtcRWL5MeqK+2rHbPEI79qxiteOP1Rk=; b=FYZhAo2X6TK8rwWrYXFDe4boRV8v2lEBd2xQ4znD7ShPx/dmH61dSmpDlPB/xYIrYa omwl8KpyzlN4sF6iTZz07+zQeEm3pZgBdFEUhpb2ACJkCRsp3wzZqH4qxM+QzWpYFZAG lPqeWIPkxwg9/intACmtcCbgyXOR3OKqB6oSZykG8VelgPEew1ZtbOVJP1USYfNmQ+el MaXbkE3ekG8twZaPPPe6Zw/6LB477seoNI76O6N/PrTFZqrAyz34GCnyjfArLyK72lAC e2ESeYBJ3UvG2osFgIaQQxTMtYtUiRrWqHWUv3Zss5Ki881g37fMsUqxYh58kqAdnNxb nzzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715685035; x=1716289835; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=3mtq9R11ezRKEtcRWL5MeqK+2rHbPEI79qxiteOP1Rk=; b=ktzTu2ztL+fPryG2daDwsX1032k57+HBiHFowFeNTpkqhIn8CFlhcbHOhICrlasMrC +56VwHWZu8FPyM1MBZ9i22iBRPsmfUj5xCsq+fQR6UDr6b5WqduSiq0AHHC/VbikmCRJ gTNC7taarZI1dWgRzRrbo+doD4Co6oAOZS3nUYcC4/XaRwqeGJi+q2NhTx8lAQkJaeFT PnL3DLfaF8KJwZ0h74YnOGF77T0Stwq+axwkHWpgfQpNcRCJb0ut+31s+KkLT/PmaUYH 0jDYrdqiQmi6j3VZhh5o22XtWvAXTMbJN1fc2Hk/d2IzR16ll1ag49Axjnj4jRHIp5Vz H/IQ== X-Gm-Message-State: AOJu0Yz8lFlx1oceLtctp2P8VB4MhspmQNKbF8kHQzZN+JXFonAcO02m YX9aEnrDcyqPjcRBIxcI3N5Uc9WdLiON5IFzC2BRl2rRLUsKIeIMq/mzfQ== X-Google-Smtp-Source: AGHT+IFljImHDD3LXuxNkpWvhyBy132+/Mkh6doQ1Hnq/a8kXD7kj5cffwzDbOljA6nKyg3E6uCxyw== X-Received: by 2002:a05:6870:d6a5:b0:233:1901:7523 with SMTP id 586e51a60fabf-24172fb5eadmr15824341fac.55.1715685034828; Tue, 14 May 2024 04:10:34 -0700 (PDT) Received: from illithid (ip68-12-97-90.ok.ok.cox.net. [68.12.97.90]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-6f0fd081385sm897621a34.53.2024.05.14.04.10.33 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 May 2024 04:10:34 -0700 (PDT) Date: Tue, 14 May 2024 06:10:32 -0500 From: "G. Branden Robinson" To: TUHS main list Message-ID: <20240514111032.2kotrrjjv772h5f4@illithid> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hmvxie5ux6tk2oah" Content-Disposition: inline In-Reply-To: Message-ID-Hash: TC3TWNQUDH7ZIMK3BUU3KP3DGPQUJ2GZ X-Message-ID-Hash: TC3TWNQUDH7ZIMK3BUU3KP3DGPQUJ2GZ X-MailFrom: g.branden.robinson@gmail.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 X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: If forking is bad, how about buffering? List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --hmvxie5ux6tk2oah Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I've wondered about the cat flag war myself, and have a theory. Might as well air it here since the real McCoy (and McIlroy) are available to shoot it down. :) I'm sure the following attempt at knot-slashing is not novel, but people relentlessly return to this issue as if the presence of _flags_ is the problem. (Plan 9 fans recite this point ritually, like a mantra.) I say it isn't. At 2024-05-14T17:10:38+1000, Rob Pike wrote: > I agree with your (as usual) perceptive analysis. Only stopping by to > point out that I took the buffering out of cat. I didn't have your > perspicacity on why it should happen, just a desire to remove all the > damn flags. When I was done, cat.c was 35 lines long. Do a read, do a > write, continue until EOF. Guess what? That's all you need if you want > to cat files. >=20 > Sad to say Bell Labs's cat door was hard to open and most of the world > still has a cat with flags. And buffers. I think this dispute is a proxy fight between two communities, or more precisely two views of what cat(1), and other elementary Unix commands, primarily exist to achieve. In my opinion both perspectives are valid, and it's better to consider what each perspective wants than mandate that either is superior. Viewpoint 1: Perspective from Pike's Peak Elementary Unix commands should be elementary. Unix is a kernel. Programs that do simple things with system calls should remain simple. This practices makes the system (the kernel interface) easier to learn, and to motivate and justify to others. Programs therefore test the simplicity and utility of, and can reveal flaws in, the set of primitives that the kernel exposes. This is valuable stuff for a research organization. "Research" was right there in the CSRC's name. Viewpoint 2: "I Just Want to Serve 5 Terabytes"[1] cat(1)'s man page did not advertise the traits in the foregoing viewpoint as objectives, and never did.[2] Its avowed purpose was to copy, without interruption or separation, 1..n files from storage to and output channel or stream (which might be redirected). I don't need to tell convince that this is a worthwhile application. But when we think about the many possible ways--and destinations--a person might have in mind for that I/O channel, we have to face the necessity of buffering or performance goes through the floor. It is 1978. Some VMS or, ugh, CP/M advocate from those piddly little toy machines will come along. "Ha ha," they will say, "our OS is way faster than the storied Unix even at the simple task of dumping files". Nowhere[citation needed] outside of C tutorials is cat implemented as int c; while((c =3D getchar()) !=3D EOF) putchar(c); or its read()/write() system call equivalent. The output channel might be across a network in a distributed computing environment. Nobody wants to work with one byte at a time in that situation. Ethernet's minimum packet size is 64 bytes. No one wants that kind of overhead. While composing this mail, I had a look at an early, pre-C version of cat, spelling error in the only comment line and all. https://minnie.tuhs.org/cgi-bin/utree.pl?file=3DV2/cmd/cat.s putc: movb r0,(r2)+ cmp r2,$obuf+512. blo 1f mov $1,r0 sys write; obuf; 512. mov $obuf,r2 Well, look at that. Buffering. The author of this tool of course knew the kernel well, including the size of its internal disk buffers (on the assumption that I/O would mainly be happening to and from disks). But that's a "leaky abstraction", or a "layering violation". (That'll be two tickets to the eternal fires of Brogrammer Hell, thanks.) Once you sweep away the break room buzzwords we understand that cat is presuming things that it should not (the size of the kernel's buffers, and the nature of devices serving as source and sink). And this, as we all know, is one of the reasons the standard I/O library came into existence. Mike Lesk, I surmise, understood that the "applications programmer" having knowledge of kernel internals was in general neither necessary nor desirable. What _should_ have happened, IMAO, is that as stdio.h came into existence and the commercialization and USG/PWB-ification of Unix became truly inevitable, is that Viewpoint 1 should have been salvaged for the benefit of continuing operating systems research and kernel development. But! We should have kept cat(1), and let it grow as many flags as practical use demanded--_except_ for `-u`--and at the _same time_ developed a new kcat(1) command that really was just a thin wrapper around system calls. Then you'd be a lot closer to measuring what the kernel was really doing, what you were paying for it, and you could still boast of your elegance in OS textbooks. I concede that the name "kcat" would have been twice the length a certain prominent user of the Unix kernel would have tolerated. Maybe "kc" would have been better. The remaining 61 alphanumeric sigils that might follow the 'k' would have been reserved for other exercises of the kernel interface. If your kernel is sufficiently lean,[3] 62 cases exercising it ought to be enough for anybody. Regards, Branden [1] https://news.ycombinator.com/item?id=3D29082014 [2] https://minnie.tuhs.org/cgi-bin/utree.pl?file=3DV1/man/man1/cat.1 [3] https://dl.acm.org/doi/10.1145/224056.224075 --hmvxie5ux6tk2oah Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEh3PWHWjjDgcrENwa0Z6cfXEmbc4FAmZDRqEACgkQ0Z6cfXEm bc5Cmw/+LQ+sWhGNHjNKjHujXspR70zwiKKqePFnfuigQlaG+xQOwxHZbinSk0Ht jMFOCyD6bEfna6kkozK0o7Kt17yJ5/awdWa3BAZJOOfRY9lCfhi8cxXZT1qN/qeh mX+r1wNKcrLWuAuiJQPEMHOXoGK8WBTCi+OhGHxBNZ75IoLViPeu5C9odJ2YfrTU CChweQRuTO0XClsYxqf5nw6O/90HFSfd8P+gQ1+nvjOaKohNX8zzobU6/IEK+R1a vs/SFecinLUDTMBYY8RwP81fDSSbpQQbRzPXUdbV6whK+Q3y7EOmkO1YP0Uqo+/M L5Sq1X9O04uL8In8L3OvYEDfXEh921bKBNkyyMy/4utGXsxYLSwf4kEJM3Dhd7gj oHDiVlh1apS0uMLBKe1z1WfT16wy+q/PQXTxt3vEThjPSnqT7bcnZLVoCgFjVSbE P17OCFRD33gRDlw22vZowVvqowupxmGUZVzMTXGCYhE91JxFyhOboPt+bWU8CWnW dkFQsR3lcNa7hIfjS47RSwedKdHwBlA0tg7gVedlYohVi7URyJJmr6B6hWrl8svF 9Xh4zpS2AoZi3EZiQ0B0IR3ImO/aHyQpWlre6Xe0ghwIvpItQjFLfyI6XlEnseW4 Hnw79s6ySYcBS2FcLfZVw42FguTF5xE+3ZjICavjEhXbuiONSqs= =PcKZ -----END PGP SIGNATURE----- --hmvxie5ux6tk2oah--