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_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 12915 invoked from network); 6 Jun 2022 01:10:01 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 6 Jun 2022 01:10:01 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 818C9421D1; Mon, 6 Jun 2022 11:09:57 +1000 (AEST) Received: from mail-oa1-x2f.google.com (mail-oa1-x2f.google.com [IPv6:2001:4860:4864:20::2f]) by minnie.tuhs.org (Postfix) with ESMTPS id 3205E421D0 for ; Mon, 6 Jun 2022 11:09:52 +1000 (AEST) Received: by mail-oa1-x2f.google.com with SMTP id 586e51a60fabf-f2cbceefb8so17486105fac.11 for ; Sun, 05 Jun 2022 18:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hM/hZAZ/P7nr1vH1wT8uvoFVCazwrlCICCg+WhZ5Xu4=; b=a7MqBTzcT+JSUDgU2WvtewkgIOIQl0E825WEgfxe7xy1BMEspgpDP4ac/P9bQYbmMh ZR2LJejOtIsx6FgLGCOwouxDLjUPrdTcBtdqFKCX+SKvj0X0DNZBOF+JPZmhg5Ijt8Wd sMY9DNI7Z3odJBsFcc4GOXRJO9keax2tR2ijb3uy38YIfUQu0uoUWwhMNhV3+K8kYKUr Bic6vSz8PxTx407Bc2hfNyRQPaWLFckTVAQ2gYViW0L4uDj3jtDisj9cUKPibEIElyUu Wi8gc8KMi6z5mQGbJssFW4b8ruyvDRg2/1YTDe2aRtaVFLpGzYODMtf+GuNfSOqpNUNV 0Q0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hM/hZAZ/P7nr1vH1wT8uvoFVCazwrlCICCg+WhZ5Xu4=; b=AVG+l3SoTUkbNl0U+NLQswiiiL+U5WjiRKLbtObskpBgQMCApijoMDLxIHeb9hAnL5 G2OFesCvZHNhB6fOo2miYnWbMj8oFG0t5clY7iawwCBoHa1mVOLrQzzbSrObok8czSyH IqhTH8LopWq2Nt1WuytO7GxGbUkE75yw6TjZQSqXqkEcECLW4vL/7ZjcxCZ+Kqp/uJK5 NBl1NGWD7TPpT42sfeqc8DOpFurH88cMk8UJPJvV4IlLTvkQuNnBQJdoDXEgXhfhtoYI 5mAGdLwJ0Qdm0awH5VyWkxbFegJuKwR20oVY5NW8Ecr+c6Z/wIin6ExFML7X/2AWN6Od ZQLQ== X-Gm-Message-State: AOAM533j4IuRwS0/c8TS6rUFEwE8QakOwUZuPHIBcVc5y5SARr9F0Xdk ZcvJLcEExjZJJtjbDa6doFd3DjMbqNqQGREwNxw= X-Google-Smtp-Source: ABdhPJw8tiagv9tr0fL962ZuJKqT/fUeR5B1l/Hd/yWHYlW06ocbK8RMIMcSm2vYpLKibxsJY31JNNkwvnq8mWVumJw= X-Received: by 2002:a05:6870:3111:b0:f2:9615:3b2e with SMTP id v17-20020a056870311100b000f296153b2emr11971410oaa.49.1654477791159; Sun, 05 Jun 2022 18:09:51 -0700 (PDT) MIME-Version: 1.0 References: <20220603213215.GO10240@mcvoy.com> <20220603214032.GQ10240@mcvoy.com> <20220603223014.GS10240@mcvoy.com> <20220603234822.GV10240@mcvoy.com> <20220604010543.GZ10240@mcvoy.com> In-Reply-To: From: Dan Cross Date: Sun, 5 Jun 2022 21:09:15 -0400 Message-ID: To: "Theodore Ts'o" Content-Type: text/plain; charset="UTF-8" Message-ID-Hash: QHZ67N5PQRFP47DPGUWYN5HSZHYBTQFY X-Message-ID-Hash: QHZ67N5PQRFP47DPGUWYN5HSZHYBTQFY X-MailFrom: crossd@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 CC: The Eunuchs Hysterical Society X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Fwd: [simh] Announcing the Open SIMH project List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Sun, Jun 5, 2022 at 8:35 PM Theodore Ts'o wrote: > [snip] > Part of this comes from the the fact that the Linux kernel, C library, > and core utilities are all shipped separately. The BSDs have often > criticized this, claiming that shipping all of the OS in a single > source control system makes it easier to rollout new features. There > is no doubt upsides from having a single source tree; but one of the > advantages of keeping things separate is that definition of the kernel > <-> userspace interface is much more explicit. Isn't that just an accident of history, though? The GNU stuff was far enough along when Linux got going that he could crib most of it by default to build a "complete" working system; he was just providing the kernel, whereas Unix traditionally had been distributed as a complete system, so the BSDs just kind of followed that model. > That being said, I will note that this always hasn't been true. There > was a brief period where an early Red Hat Enterprise Linux version > suffered from the "legacy Unix value-add disease", where Red Hat had > added some kernel changes that impacted kernel interfaces, which > didn't make it upstream, or made it upstream with a changed interface, > such that when users wanted to use a newer upstream kernel, which had > newer features, and newer device driver support, it wouldn't work with > that version RHEL. Red Hat has criticized *heavily* for that, both by > the upstream development community and by its users, and since then it > has stuck to a "usptream first" policy, especially where new system > calls, or some other kernel interface is concerned. > > One of the reasons why that early RHEL experience kept Red Hat in line > was because none of the other Linux distributions had that property > --- and because the core development in upstream hadn't slacked off, > so there was a strong desire to upgrade to newer kernels on RHEL, and > when that didn't worked, not only did that make customers and > developers upset, but it also made life difficult for Red Hat > engineers, since they now need to figure out how to forward port their > "value add" changes onto the latest and greatest kernel release. Sounds very familiar. I'll wager that just about any large organization with a heavy investment in Linux has a similar problem on their hands. I've _heard_ that Meta is different, but have no first-hand knowledge. > An interesting question is if CSRG had been actively pushing the state > of the art foreward, would that have provided sufficient centripetal > force to keep the HP/UX, SunOS, DG/UX, etc., from spintering? After > all, it's natural to want to get a competitive advantage over your > competition by adding new features --- this is what I call the "Legacy > Unix value-add disease". But if you can't keep up with the upstream > developments, that provides a strong disincentive from making > permanent forks. For that matter, why was it that successive new > releases of AT&T System V wasn't able to play a similar role? Was it > because the rate of change was too slow? Was it because applications > weren't compatible anyway due to ISA differences? I don't know.... Was CSRG doing research, or producing a production system? It sure seems like they were trying to thread a needle there that put them into a weird position. But more generally, it feels like this doesn't take into account the context of the times. $n$ manufacturers back in the minicomputer days were used to writing their own OS for each new machine; sure they adapted Unix, but the idea that they'd treat it differently from that standpoint feels like something that didn't really occur to anyone until the late 80s. By then, the stage was set for the arrival of something like Linux. > One other dynamic might be the whole worse is better is worse debate. > As an example of this, Linux had PCMCIA support at least a year or two > before NetBSD did, and in particular Linux had hot-add support where > you could insert an ethernet PCMCIA into your laptop after the OS had > booted, and the ethernet card would work. However, if you ejected the > ethernet card, there was a roughly 1 in 4 chance that your system > would crash. NetBSD took a lot longer to get PCMCIA support --- but > when it did, it had hot-add and hot-remove working perfectly, while > Linux took a year or two more after that point before hot-remove was > solidly reliable. > > So from a computer science point of view, one could argue that NetBSD > was "better", and that Linux had a whole bunch of hacks, and some > might even argue was written by a bunch of hacks. :-) However, from > the user's perspective, who Just Wanted Their Laptop To Work, the fact > that Linux had some kind of rough PCMCIA support first mattered a lot > more than a "we will ship no code before its time" attitude. And > some of those users would become developers, which would cause a > positive feedback loop. This I can totally buy, but my perception (as very much an outsider) was that people ran --- and continue to run --- Linux because, simply, they want to run Linux. They choose Not to run a BSD or illumos or whatever else because they want to run Linux instead. There was a time in the early 90s when FreeBSD was objectively better in almost all metrics than Linux, including faster networking. But people still wanted to run Linux instead. Why? It just captured the zeitgeist better; the barrier to entry was lower, you didn't have to put up with the "old school Unix" mentality of many of the players (my term for what you have referred to as, "the Gods of BSD" and some of the big egos of the USENIX crowd), and people got religious about the license. Many of the explanations we throw around here are interesting, but too often feel like justifications after the fact. So much of it was simply preference. - Dan C.