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

["Theodore Y. Ts'o" <tytso@mit.edu>]

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