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=-1.0 required=5.0 tests=LOTS_OF_MONEY, MAILING_LIST_MULTI,MONEY_NOHTML,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 1715 invoked from network); 13 Dec 2020 01:08:37 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 13 Dec 2020 01:08:37 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 9CBD7945BD; Sun, 13 Dec 2020 11:08:31 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 74E2693D37; Sun, 13 Dec 2020 11:07:53 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id C3C9A93D37; Sun, 13 Dec 2020 11:07:49 +1000 (AEST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by minnie.tuhs.org (Postfix) with ESMTPS id 95CE193D29 for ; Sun, 13 Dec 2020 11:07:48 +1000 (AEST) Received: from callcc.thunk.org (pool-72-74-133-215.bstnma.fios.verizon.net [72.74.133.215]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0BD17hTJ000951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 12 Dec 2020 20:07:44 -0500 Received: by callcc.thunk.org (Postfix, from userid 15806) id 8C9ED420136; Sat, 12 Dec 2020 20:07:43 -0500 (EST) Date: Sat, 12 Dec 2020 20:07:43 -0500 From: "Theodore Y. Ts'o" To: Dan Cross Message-ID: <20201213010743.GE575698@mit.edu> References: <20201209165854.GK52960@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [TUHS] Were cron and at done at the same time? Or one before the other? 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: The Eunuchs Hysterical Society Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On Wed, Dec 09, 2020 at 02:58:27PM -0500, Dan Cross wrote: > To circle back to plan 9 for a moment, this was something that the open > source folks who found their way to 9fans just couldn't grok. The answer to > the question, "why don't you do all this work to support (emacs|a web > browser|a C++ compiler|whatever du jour)?" was, "because there's little > inherent research value in doing that, and this is a research system." That > it was also a workaday system for a handful of folks was incidental; the > goal wasn't world domination, it was advancing research and providing a > comfortable environment for that work. Linus's response exemplifies this > lack of understanding. (Disclaimer: I was very much an outsider looking in > there, but it seems clear enough in retrospect.) There was a similar dynamic with Minix, where Prof. Tanenbaum rejected contributions to Minix because Minix wa a teaching system, and he wanted to keep it simple. The contrast is that with Linux, that contributions are accepted from a large number of people, working at a large number of companies, that all have different goals, and the challenge of maintainers is to balance off the goals of many different contributors. Contributions don't get rejected just because "this is a {research,testing} OS". The goal is to make the open source project as generally useful as possible. > And notice how they aren't all that popular or well known? "Design" is > > like a religion - too much of it makes you inflexibly and unpopular. > > That's a terrible metric. > > I submit that neither of those systems were created with the explicit goal > to become "popular", and the claim of inflexibility is unwarranted. Within > their domain, that is as research systems, both are quite well known and > remain highly influential. >From the open source perspective, it's an extremely important metric, since if a system is generally useful, such that many different entities find the system to be useful, that means that the project will have more and more contributors. Yes, those contributors may have differing objectives, but this also gives you a larger development community to make the project more useful. The challenge is how to structure the project so that you can usefully use a larger and larger number of contributors, and how to mediate conflicts when objectives are in tension with each other. (For example, sometimes adding lots of fine-grained locking to improve CPU scalability often comes at the cost of trashing UP and small SMP performance.) However, it's surprising how often that with the right amount of encouragement, things like SMP vs UP performance is not an either/or, but a both/and. Granted, at the extremes, this isn't always going to be true. If you have to squeeze an OS into super-tiny micro-controller, or if you want to optimize scalability for a massiely large Sunfire E10k/E12k/E15k server, the only way to do this is with a huge number of fine-grained locks in Solaris. (And given the profit margins on million dollar E10k versus a cheap Ultrasparc 5 workstation, it's not surprising that Solaris would optimize performance for an E10k.) > This is a common but annoying line of thought in the computer world: > because something is useful and popular, it is good. My first car was a > 1985 AMC Eagle; it was undeniably useful. It may have even been moderately > popular at one point. But damn it was an awful car. > > Linux is undeniably useful and it's arguably the most popular operating > system in the world. And parts of it are really, really good. But simply > put, that doesn't mean that its evolutionary path has landed in an > inherently good place. The question is what your objective function such that you consider the endpoint evolutionary path is "a good place"? My pre-existing values are that a system is "good" if it can add value for many different applications. So I have a bit of an engineer's perspective of a system is good because it is useful --- and part of being useful is that it is secure, and reliable, and cost effective. Having a clean architecture is useful in so far as it makes reduces maintenance overhead and improves reliability. But forcing everything to use a file interface merely for aethestics' sake is not terribly important for _my_ objective function. And if popularity means that I can have engineers from Tencent, and Huawei, and IBM, and SuSE, and Oracle, and Google all helping me make a better file system for Linux, as opposed to having one company shoulder all of the development costs --- then heck yes, I'll take popularity any day. Cheers, - Ted