Re: [TUHS] Were cron and at done at the same time? Or one before the other?

[Dan Cross <crossd@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 8927 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 11302 bytes --]