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 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 19855 invoked from network); 30 Jan 2023 16:49:13 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 30 Jan 2023 16:49:13 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 0F27642615; Tue, 31 Jan 2023 02:48:51 +1000 (AEST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by minnie.tuhs.org (Postfix) with ESMTPS id D20B34260E for ; Tue, 31 Jan 2023 02:48:45 +1000 (AEST) Received: from cwcc.thunk.org (pool-173-48-120-46.bstnma.fios.verizon.net [173.48.120.46]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 30UGmeZd013389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Jan 2023 11:48:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1675097321; bh=VTaSfMfmJPISSX04X8yovI9gzomYhvisesw7328j9VI=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=iYB21kSyy83YilzyW5tHAts2+Mgce8R2YA0uvk0jmTOR7pHyfjlh49Li8aORNidt/ fWxDpi/at3S5qdpG4NE3scC6VNUAlqwKwjKcPdyK33TIWMedbKz3OD8DwLc7bRdFDT WiJ1ZgFkMK+1NBkEPy0AL5BK8AGWHXlYfugpi8Jr12SAsSDWSMXjlhbM84j8QiTUQv GDZZrRU7j6XuNP1QYv1FeF7D1k3KW4q8EuuA0B38O/k/8oNjaDbInSrLkxvk8dEuJS wGFhSDuohfvkiTHJUowawSeSNik8bs7Kii95ACJl6pkJCAZVmGYKJMfBuqVYMdeAT2 Y/eySsDHipSdA== Received: by cwcc.thunk.org (Postfix, from userid 15806) id 006A515C359D; Mon, 30 Jan 2023 11:48:39 -0500 (EST) Date: Mon, 30 Jan 2023 11:48:39 -0500 From: "Theodore Ts'o" To: Dan Cross Message-ID: References: <202301300750.30U7oQTh013304@freefriends.org> <20230130150219.GD12306@mcvoy.com> <20230130152703.GE12306@mcvoy.com> <20230130154555.GF12306@mcvoy.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Message-ID-Hash: A4NEJ3L3O2CICXMTLIQHE2EGRXJ4RDRL X-Message-ID-Hash: A4NEJ3L3O2CICXMTLIQHE2EGRXJ4RDRL X-MailFrom: tytso@mit.edu X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: tuhs@tuhs.org X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: FD 2 List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Mon, Jan 30, 2023 at 11:09:03AM -0500, Dan Cross wrote: > > > At one point it struck me that Plan 9 didn't succeed as a widespread > > > replacement for Unix/Linux because it was bad or incapable, but > > > rather, because people wanted Linux, and not plan9. > > > > Many people make that mistake. New stuff instead of extend old stuff. > > Some would argue that's not a mistake. How else do we innovate if > we're just incrementally polishing what's come before? The challenge is how do you extend the most common interfaces so that you don't break the most common workflows and applications, without adding too much backwards compatibility hair, and without stiffling innovation. I think we can err in both directions --- break the world, and no one will adopt the OS, and too much backwars compaibility and it's much, much harder to innovate. The happy medium which Linux uses is that the userspace interfaces should mostly stay compatible ("thou shoult not break userspace") unless there are really, really good reasons (such as security vulnerabilities) when you can't really do that. But internal interfaces, including those that might be used by out of three kernel modules --- it's totally fair game, and if you have academics who have professors who were trained up on the 4.14 kernel, when they were in graduate school --- sorry, your knowledge is out of date, and you can either force your graduae students to use an obsolescent kernel for their research, or you're going to have to get with the times. (I remember in the early days of BSD where people considered it a feature that academic research tools wouldn't be broken; I believe I remember hearing that as excuses not to rework with networking and tty layers, whereas Linux rewrite the networking stack from scratch 2 or 3 times, and we've since completely reworked the block layer to deal with ultra-fast devices, even if that meant that all external device drivers would be broken.) Of course, there will be kvetching no matter where you draw the line, but simply saying, to *hell* with the old ways of doing things, and we can't break anything, even internal interfaces, are both recipes for failure IMHO. > > As you said, people don't want to give up their mental model when that > > model works. They'll only give it up when there is at least a factor > > of 2 improvement that they care about. These days it feels like people > > are stuck enough that they want a factor of 10. > > Yup, that's about right. The mainframe is still going strong, after all! One of the things that we can at $WORK is to be able to translate storage TCO costs (cost per byte, cost per IOPS), cost of CPU utilization, and cost of memory, etc., into SWE-equivalents. So when we propose a new initiative, we'll take the cost to implement the project, as well as the cost to change all of the downstream users in the software/storage stack, and do a cost benefit comparison. For example, we might take the cost to implement the use of some new storage technique, such as Hybrid SMR[1], dd a generous buffer because projects always take longer and cost more than you first might think, and then compare it to the 5 year storage TCO costs, using SWE-equivalents as the common unit of comparison. And the project will only get green-lighted if the benefits exceed the costs by a goodly margin. [1] https://blog.google/products/google-cloud/dynamic-hybrid-smr-ocp-proposal-improve-data-center-disk-drives/ Of course, things are different if you are working in academia, where things like getting published in a venue that will help build you or your associates' tenure case are going to be more important. In any case, if we are going to claim that programming is an engineering discpline, then engineering tradeoffs are important to remember. Companies or departments who forget this lesson are much more likely to get reminded of it when the activist investors start pushing for layoffs, or when you start wonderng why your company had to get sold off to the highest bidder... - Ted