From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id a8398f8b for ; Sun, 19 Jan 2020 19:46:15 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id AAA1F9C153; Mon, 20 Jan 2020 05:46:14 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 2BF1B9C11C; Mon, 20 Jan 2020 05:45:47 +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="IffWjBQ7"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 7E35F9C11C; Mon, 20 Jan 2020 05:45:44 +1000 (AEST) Received: from mail-qt1-f182.google.com (mail-qt1-f182.google.com [209.85.160.182]) by minnie.tuhs.org (Postfix) with ESMTPS id 781F99C10B for ; Mon, 20 Jan 2020 05:45:43 +1000 (AEST) Received: by mail-qt1-f182.google.com with SMTP id e25so14739164qtr.13 for ; Sun, 19 Jan 2020 11:45:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4IFz+/xxgsNYfVqH/7jPxa9Dn+W0/dBAj9/uzbRilI8=; b=IffWjBQ73P6pjKqWeSiVsfMt1tAN1cockJs5J0YyCKGFROPlOjBmeRHVM4iUAztU2N 5Gv4ErWHOSn3eZjZmSHMtXNC/TbREFhFNKPs1qmG9I+ghn0dz72iUBs4pYnSsdjWhH9a ZowvXM4lvfF6TnlOej+YMqwbOiaGVKC0vV81nWzVtp+x0HWrvmKSHPhJKTjbRUkOWfwR ABNMkrDSltayQiHHRjrM1GQOALsessxXijLumUZuyguxygbFF5bBvnBhwegoAJU8mCW+ 2CbPmDQd7OSnNI7X3+sKC1UuJu1ie46kzT60CqgUE4jkWrf5e0WNAzTcOZSazVqZEh2K UnAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4IFz+/xxgsNYfVqH/7jPxa9Dn+W0/dBAj9/uzbRilI8=; b=TyVsPcneQZhYccp8IWO9bvrp5Svd9w2Py7bmVgXiA9UcTJhShD9fQBFxjR70+nHadQ gR76U7YX3sv4YYttgMoce21x9I9Cn70reRXVdla/l2jaNfZTl5Pxtm5ojqmyfpID1U1j j3ReUjLtCXkaXC5GnBtQsCORWkMcvXWBDFpI2Y2FWtZMqvLhB7UJsuXZMLwkhKTyvINr rEY/sQoM0pD9mqOsyAApq5e1FaZgQUc7iqCJDsDYCIibQrR+vE7gpOEXi8VmDy6EGVoK BTCZIMyoobI0nGnQaPsVNAm2nPzEqGOH0YDSPW9OOxtpiaIr9nF7t69xzuC+VxdIFgv1 ydWg== X-Gm-Message-State: APjAAAUTnGAc9F8atVpd1EBm5/bUlBwMbYV5GhwurbJcZ9T/WzhXfBgi vxyiMZ9KQpagJGfXnQS6iRerdOVrzr8= X-Google-Smtp-Source: APXvYqw92gWe6pWg6zPXGge8pMoBgV8xFzdRuP+Q5YnYbnKaG1dyZ9f1XNTFDh3GNLNn67aPs/v7SA== X-Received: by 2002:ac8:3fd5:: with SMTP id v21mr17111178qtk.345.1579463142215; Sun, 19 Jan 2020 11:45:42 -0800 (PST) Received: from ?IPv6:2600:8800:7c80:98b:2d5c:f86e:1064:4caf? ([2600:8800:7c80:98b:2d5c:f86e:1064:4caf]) by smtp.gmail.com with ESMTPSA id h1sm16740621qte.42.2020.01.19.11.45.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Jan 2020 11:45:41 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Adam Thornton In-Reply-To: Date: Sun, 19 Jan 2020 12:45:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <60F817C2-3C85-42CF-8C3F-7BE8EDBA551E@gmail.com> References: <5A5107E4-06AD-4C2B-B590-15C17B301D44@cfcl.com> <20200119102937.3s2hwl3ziupa7ese@unixfarts.net> To: TUHS main list X-Mailer: Apple Mail (2.3608.40.2.2.4) Subject: Re: [TUHS] "What UNIX Cost Us" 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: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" > On Jan 19, 2020, at 9:33 AM, Warner Losh wrote: >=20 > Benno's talks (systemd and this one) weren't wrong. Systemd *is* a = dumpster fire. It has a lot of cool ideas, but is coded by someone that = has poor listening skills and is more stubborn than he's technically = competent. It's had a crapton of severe security bugs in it. It's given = us abominations like eth4156 as a NIC name. It doesn't like it when you = & a job and log out for Pete's sake. It's a total mess that breaks = everything to try to push the state of the art. Hoo boy. I just had this argument on one of the Slacks I=E2=80=99m on. > Beno's talk on it may have been a little over the top, but he's not = wrong about much of his criticism. Systemd has swung too far from the do = one thing and do it well philosophy, admittedly in ways that are = ham-fisted and don't necessarily mean that it's philosophically wrong, = that it shows at least some of thee wisdom of simplicity. No, it=E2=80=99s philosophically wrong. I will grant that there is a problem there that needs solving. Let=E2=80=99= s look at BSD rc and SysVinit; they=E2=80=99re both extremely difficult = to automate installing and uninstalling services. SysVInit works better = than rc in that regard, but they=E2=80=99re both kind of crappy. = Let=E2=80=99s look at the things that suck about SysVInit: 1: no actual dependency graphs. Sure, there was a whole framework of = magic comments to sorta-kinda-glue one in. Didn=E2=80=99t work very = well. 2: tons of shell ceremony around start/stop/restart What you want in an init system is: First and foremost, a process manager, that acts as a signal handler of = last resort. * It would be nice if it _can_ and _usually does_ run as PID 1, but = doesn=E2=80=99t insist on it. * Has a firm notion of =E2=80=9Cthis service depends on _that_ = service=E2=80=9D and can sequence startup and shutdown appropriately. * Has a declarative syntax that lets you configure most services with = just a little declarative text, probably with an escape hatch for more = complicated services Here=E2=80=99s what you don=E2=80=99t want _in your init system_: A new approach to logging that puts your logs in a human-unreadable = binary format. A system-wide event bus. This is actually quite a good idea, but it = doesn=E2=80=99t need to be part of the init system. A sound manager. You get the idea. Yeah, SysVInit needed to be superseded. Runit, Daemontools, Upstart all = had reasonable approaches. But the devouring hippo of SystemD won, = mostly because Lennart worked at Red Hat. And it=E2=80=99s a terrible = idea because it tangles all these things together. It=E2=80=99s also a = terrible idea because your init system should have goals other than time = from pressing the power button to getting a login prompt on Lennart=E2=80=99= s laptop, but I digress. >=20 > Figure a dozen file paths out, cat the right thing to them so other = files show up and then you can do the same thing again? That's not a = sane interface. Everything isn't a file. =20 [=E2=80=A6] To be fair: BSD sockets are not pretty, and they=E2=80=99re not elegant. = They won, and SysV Streams were worse in a lot of ways, but I still = suspect there was some way of doing a TCP/IP stack that seemed more = Unixy, without (maybe) needing DNS (or a service locator) in a sidecar = userland process=E2=80=A6but as soon as you start thinking about it, = yeah, it gets gross. > At Netflix we use sendfile for our stuff. It's one of the least unixy = things in the kernel. It reads from a file, then TLS encrypts the file = and sends it out the socket. This means state has to be carefully = managed with some setup in userland before the handoff. The other = non-unixy thing is that it's all non blocking. sendfile asks for a set = of pages from a file. When they are ready, it gets a callback to = schedule encryption, and when that fires it's scheduled to the NIC for = transmission and either retransmission or freeing up depending on the = ACKs that come back. At ~190Gbps, this isn't something one can do with = the normal Unix interfaces, which was the point of his talk. He's not = wrong, but his examples could use some work. And here we see Unix as a victim of its own success. It=E2=80=99s = pretty damn weird, when you think about it, that we=E2=80=99re using a = half-century-old typesetting system to power both the front and back = ends of sending cat pictures and porn videos in real-time all over the = planet all the time. This also speaks to = https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19= .pdf (mentioned here several months ago). The fork()/exec() model is = great in a single-threaded pipeline-processing model. But, yeah, it=E2=80= =99s totally true that it (and read()/write()) is not the best thing for = writing user-facing nonblocking GUIs. > The real world is messy, and often requires complexity. Going too = simple for simplicity's sake is just as bad as going too complicated for = complexity's sake. A proper balance is needed. And he's not wrong to = make that point. That said: Linux now has _way_ too many syscalls. I would be = flabbergasted if the rarely-used ones are not crawling with exploitable = bugs. I am surprised that Google hasn=E2=80=99t done more with fuchsia = + gvisor (well, maybe they have but haven=E2=80=99t showed us yet). = Gvisor is a fascinating experiment in worse-is-better, in that, no, it = makes no attempt to replace _all_ the Linux system calls, just the ones = that _the programs you really want to run_ use. Things do grow cruft over time. And things change over time. = Containers are absolutely essential to what I=E2=80=99m doing these = days. They were not ten years ago. Alpine is going there (in terms of = a minimal container-focused support system (=3D=3D OS layer), but = clearly the more-right thing would be something like = gvisor-plus-something-like-fuschia: my container only contains _code_ = for the syscalls my application actually uses. Can=E2=80=99t exploit = what isn=E2=80=99t there. This also hits the =E2=80=9CPeople shouldn=E2=80=99t be using C in = 2020=E2=80=9D argument. But _that_ in turn is less about C not = providing modern strong typing features and letting you play fast and = loose with pointers and making you do your own memory management, and = more about: your computer is really, really not a PDP-11 anymore. A = language that provides the abstraction of a simple in-order execution = stream is _lying_ to you. The problem with that is that thinking about something as bizarrely = complex as modern CPUs and writing software to exploit the way they = actually work is _really really hard_. Wow, that was a ramble. Anyway: Benno=E2=80=99s not wrong. But = everything=E2=80=99s historically contingent, right? We=E2=80=99ve got = a half-century of C and a half-century of a typesetting system that got = too big for its britches, that=E2=80=99s now running, basically, the = entire underpinnings of the 21st century=E2=80=A6I was going to say = =E2=80=9Ceconomy=E2=80=9D but really, it=E2=80=99s =E2=80=9Cworld.=E2=80=9D= Adam