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,HTML_MESSAGE,LOTS_OF_MONEY, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 14298 invoked from network); 13 Dec 2020 03:03:57 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 13 Dec 2020 03:03:57 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id A0AA393D5C; Sun, 13 Dec 2020 13:03:54 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 7DFF493D37; Sun, 13 Dec 2020 13:03:23 +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="rrTGvVYx"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 3DC7F93D37; Sun, 13 Dec 2020 13:03:22 +1000 (AEST) Received: from mail-qk1-f177.google.com (mail-qk1-f177.google.com [209.85.222.177]) by minnie.tuhs.org (Postfix) with ESMTPS id E703193D29 for ; Sun, 13 Dec 2020 13:03:20 +1000 (AEST) Received: by mail-qk1-f177.google.com with SMTP id d14so11891768qkc.13 for ; Sat, 12 Dec 2020 19:03:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dzZUjqOauEaUhGEJKnoPELpEpxy/JginwdPAiflxLPs=; b=rrTGvVYxG3fywV64Wn/D3HuRJOX64LvXUfUUIYWKSQcXjsjFoGAdPlDnqMCBR7G3ik t9fSofUXM6lMWooSyPyRloqSJKV5yb3z0zMYxL3v0tXfvNv9s19RKRdbmzqXeYClGJec qDic2i7tkMji1RwCquDSoz/VgcqHCWdJikw6jiDvTSrvwBiBYGvcp/SRw1Mqs+sfYkRa wFGerZfz0L5Yu4ErTL3wqTcDtyjTJMzhJ5uwe7ydcJ2zBFYrlI34Oso/lY+DDmzwy6c8 16nTz4xm6gTi+hudDEH5N9cXE4yRU2rx2Uvw+Pj8JksjgdZ+E+SiHHMxFQBCocSOU5Oh treQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dzZUjqOauEaUhGEJKnoPELpEpxy/JginwdPAiflxLPs=; b=DooZSVPDJbQ0OV1zJ39RHzqsRqkjZ10Tj9+nLUSuqxIDna+QBGCR9H+fAlrE40Kb0A tn8LDBjMiYwSKWkRJK0dRmhsNZlt5J7qjgdExjtE9lgbuC+EDlh4B/TXXfZb8tmZ16cC wo4bSKMh3NA5jE68zq9H4GYBLhYwl3hUDbSJaRBstWEL+nmnDsKuSqYzGsLmx4Wsuufh TeZCNm4oichdlK8jL+R/WSPrV/79p71MmXvml76cD3QsfxwJo4A4Omgn2PU+sPRtG4LI TPmukxOsAS7u3lPvtLvBj+7FFSpn+iXeq9GMp9DVRbY012DUQiG4G9bGHxIqTCeJIA+b hxUQ== X-Gm-Message-State: AOAM533wg7nP31+Bo29rgNdUTA1QgQi4fkXzRV+ykj4rHfzp9yXV5pSI sck7ju7ppH5ihTDLmW/gimXUK3W8PJoPeAOI/gQ= X-Google-Smtp-Source: ABdhPJw7HcBLUqWyd0LQz+0u7RCpmR6TyvC6ems/9v+/4tBjJobrZk1CDRd7dOHEiqlzIJCIcLaVtBK5kM7injhQi0I= X-Received: by 2002:a05:620a:15a8:: with SMTP id f8mr24621805qkk.346.1607828599969; Sat, 12 Dec 2020 19:03:19 -0800 (PST) MIME-Version: 1.0 References: <20201209165854.GK52960@mit.edu> <20201213010743.GE575698@mit.edu> In-Reply-To: <20201213010743.GE575698@mit.edu> From: Dan Cross Date: Sat, 12 Dec 2020 22:02:43 -0500 Message-ID: To: "Theodore Y. Ts'o" Content-Type: multipart/alternative; boundary="0000000000008f9ba605b64fc4ef" 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" --0000000000008f9ba605b64fc4ef Content-Type: text/plain; charset="UTF-8" On Sat, Dec 12, 2020 at 8:07 PM Theodore Y. Ts'o wrote: > 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. > Yes, but his aim there was pedagogy, not general use. In that I would argue that he was successful. 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. Sure, but that's Linux. Linux is not (Minix|Plan9|L4). QED, no? Judging (Minix|Plan9|L4) by the same metrics by which one judges Linux is not useful if those systems never aspired to those metrics. > 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, > But the systems Linus mentioned weren't trying to be "successful" open source systems by that definition. That's the point: the central thesis here is that _that may be an important metric for Linux_, and by that metric, Linux is very successful. However Linus Torvalds is suggesting that other systems that explicitly didn't judge themselves along those metrics are _unsuccessful_ in an absolute sense because they didn't "succeed" by the metrics along which Linux succeeded. This is analogous to suggesting that Yo-Yo Ma isn't "successful" because he can't dunk a basketball like Michael Jordan, and consequently isn't as famous. I'm willing to bet that more people know Jordan's name than Ma's, and Ma himself would likely be among the first to admit he's not NBA material, but that doesn't mean he isn't wildly successful as a classically trained cellist. For that matter, Mick Jagger is probably better known than Yo-Yo Ma, but I don't think the latter ever aspired to be the frontman for the Rolling Stones, but I would never suggest that he isn't an accomplished musician as a result. Recall that the original context was a defense of Linux's purely organic evolution vs some notion of "design up front" that Linus suggests both L4 and Plan9 sprang from. Nevermind that that is almost certainly not true of either L4 or plan 9, but rather it's nonsensical to suggest that a more design-oriented focus was the reason they weren't as successful as Linux (as measured by popularity and deployment) as it completely ignores that neither L4 nor plan9 were trying to do what Linux did in the first place. 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. > At one time, MS-DOS was wildly successful. There was a ton of software written for it. That software was useful to a lot of people. But it would be hard to argue that DOS was "better" on some technical plane than Unix. I realize that some of this is moving the goalposts because no one defined what "good" means in context. My definition includes things like complexity, maintainability, and elegance. Some parts of Linux are nice here; some ... not so much. 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"? Yes, I cheated here by not offering a definition. My pre-existing > values are that a system is "good" if it can add value for many > different applications. > Well, my AMC Eagle got me around town, I drove to Bell Labs and back (from central PA) in it when I was 16, and it had a hitch attachment that could haul a camper. The engine was awesome and so was the heater, but every time I drove over a speedbump a part fell off. If it was "good" by the metric of adding value for different applications, then a car that did the same things and where the rearview _didn't_ fall off every time I ran over a pothole would have been better. 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. > One might argue that that misses the point of the interface: using the file interface now allows pretty much all resources to be shared over the network transparently, for example. Was it a purely aesthetic decision, or was it a research angle that opened up new areas for exploration? Indeed, some of the ideas that fell out of that as a consequence of "forcing" everything to look like a file are now in Linux. Per-process namespaces and /proc are obvious examples. But taking it back to Linus's point...Whether one system uses that file interface and another does not is immaterial, and I don't know that anyone seriously argued that the popularity of the system wasn't predicated on that. What you're describing here is a consequence of Linux's popularity; Linux wasn't more popular than plan9 necessarily because it had mmap and sockets and TTYs, but rather because it cloned an existing design that was already very popular and packaged that up free of the legal and financial entanglements of Unix, and also because plan9 just _wasn't trying to be popular in the same way_. 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. > That's fair, but that wasn't the original context. - Dan C. --0000000000008f9ba605b64fc4ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Dec 12, 2020 at 8:07 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:
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 ope= n
> 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 (ema= cs|a web
> browser|a C++ compiler|whatever du jour)?" was, "because the= re's little
> inherent research value in doing that, and this is a research system.&= quot; That
> it was also a workaday system for a handful of folks was incidental; t= he
> goal wasn't world domination, it was advancing research and provid= ing a
> comfortable environment for that work. Linus's response exemplifie= s this
> lack of understanding. (Disclaimer: I was very much an outsider lookin= g 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.

Yes, but his = aim there was pedagogy, not general use. In that I would argue that he was = successful.

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.=C2=A0 Contributions don't get rejected just because "this is a {research,testing} OS&q= uot;.
The goal is to make the open source project as generally useful as
possible.

Sure, but that's Linux. Linux= is not (Minix|Plan9|L4). QED, no?

Judging (Minix|= Plan9|L4) by the same metrics by which one judges Linux is not useful if th= ose systems never aspired to those metrics.

>=C2=A0 =C2=A0 =C2=A0And notice how they aren't all that popular or = well known? "Design" is
> >=C2=A0 =C2=A0 =C2=A0like a religion - too much of it makes you inf= lexibly 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 unwar= ranted. Within
> their domain, that is as research systems, both are quite well known a= nd
> remain highly influential.

>From the open source perspective, it's an extremely important metric,

But the systems Linus mentioned weren= 9;t trying to be "successful" open source systems by that definit= ion. That's the point: the central thesis here is that _that may be an = important metric for Linux_, and by that metric, Linux is very successful.<= /div>

However Linus Torvalds is suggesting that other sy= stems that explicitly didn't judge themselves along those metrics are _= unsuccessful_ in an absolute sense because they didn't "succeed&qu= ot; by the metrics along which Linux succeeded. This is analogous to sugges= ting that Yo-Yo Ma isn't "successful" because he can't du= nk a basketball like Michael Jordan, and consequently isn't as famous. = I'm willing to bet that more people know Jordan's name than Ma'= s, and Ma himself would likely be among the first to admit he's not NBA= material, but that doesn't mean he isn't wildly successful as a cl= assically trained cellist. For that matter, Mick Jagger is probably better = known than Yo-Yo Ma, but I don't think the latter ever aspired to be th= e frontman for the Rolling Stones, but I would never suggest that he isn= 9;t an accomplished musician as a result.

Recall t= hat the original context was a defense of Linux's purely organic evolut= ion vs some notion of "design up front" that Linus suggests both = L4 and Plan9 sprang from. Nevermind that that is almost certainly not true = of either L4 or plan 9, but rather it's nonsensical to suggest that a m= ore design-oriented focus was the reason they weren't as successful as = Linux (as measured by popularity and deployment) as it completely ignores t= hat neither L4 nor plan9 were trying to do what Linux did in the first plac= e.

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.=C2=A0 Yes, those contributors may
have differing objectives, but this also gives you a larger
development community to make the project more useful.

At one time, MS-DOS was wildly successful. There was a ton = of software written for it. That software was useful to a lot of people. Bu= t it would be hard to argue that DOS was "better" on some technic= al plane than Unix.

I realize that some of this is= moving the goalposts because no one defined what "good" means in= context. My definition includes things like complexity, maintainability, a= nd elegance. Some parts of Linux are nice here; some ... not so much.
=

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.=C2=A0 (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.=C2=A0 Granted, at the extremes, this isn't always going= to
be true.=C2=A0 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.=C2=A0 (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 modera= tely
> popular at one point. But damn it was an awful car.
>
> Linux is undeniably useful and it's arguably the most popular oper= ating
> system in the world. And parts of it are really, really good. But simp= ly
> 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"?

Yes, I cheated here by not offering a definition.

My pre-existi= ng
values are that a system is "good" if it can add value for many different applications.

Well, my AMC Ea= gle got me around town, I drove to Bell Labs and back (from central PA) in = it when I was 16, and it had a hitch attachment that could haul a camper. T= he engine was awesome and so was the heater, but every time I drove over a = speedbump a part fell off. If it was "good" by the metric of addi= ng value for different applications, then a car that did the same things an= d where the rearview _didn't_ fall off every time I ran over a pothole = would have been better.

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.=C2=A0 Having a clean architecture=
is useful in so far as it makes reduces maintenance overhead and
improves reliability.=C2=A0 But forcing everything to use a file interface<= br> merely for aethestics' sake is not terribly important for _my_
objective function.

One might argue tha= t that misses the point of the interface: using the file interface now allo= ws pretty much all resources to be shared over the network transparently, f= or example. Was it a purely aesthetic decision, or was it a research angle = that opened up new areas for exploration? Indeed, some of the ideas that fe= ll out of that as a consequence of "forcing" everything to look l= ike a file are now in=C2=A0Linux. Per-process namespaces and /proc are obvi= ous examples.

But taking it back to Linus's po= int...Whether one system uses that file interface and another does not is i= mmaterial, and I don't know that anyone seriously argued that the popul= arity of the system wasn't predicated on that. What you're describi= ng here is a consequence of Linux's popularity; Linux wasn't more p= opular than plan9 necessarily because it had mmap and sockets and TTYs, but= rather because it cloned an existing design that was already very popular = and packaged that up free of the legal and financial entanglements of Unix,= and also because plan9 just _wasn't trying to be popular in the same w= ay_.

= 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.

That's fair, bu= t that wasn't the original context.

=C2=A0 =C2= =A0 =C2=A0 =C2=A0 - Dan C.

--0000000000008f9ba605b64fc4ef--