The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Jon Steinhart <jon@fourwinds.com>
To: The Eunuchs Hysterical Society <tuhs@tuhs.org>
Subject: Re: [TUHS] Were cron and at done at the same time? Or one before the other?
Date: Sat, 12 Dec 2020 17:56:41 -0800	[thread overview]
Message-ID: <202012130156.0BD1ufbY2698480@darkstar.fourwinds.com> (raw)
In-Reply-To: <20201213010743.GE575698@mit.edu>

Theodore Y. Ts'o writes:
> > 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.

My two cents here is that the problem with the evolution of linux is that
many, many people are adding new stuff while the existing stuff is decaying.
Sure, the kernel is pretty stable, but user land is a mess where one has a
choice of many versions of everything, each of which is broken in a different
way.  My engineer's perspective is that the overcomplexity from lack of
architecture is resulting in reliability and maintenance issues.

And, if you can actually make a better file system, please go for it, you're
a better person than me.  I've looked that that code, and it's huge, has no
clearly defined entry and exit points, and is undocumented.  While I've been
too busy to deal with stuff, I found some minor bugs and a possible big
performance improvement just from trying to read the code.

I don't think that "it mostly works most of the time" is a great metric.

Jon

  reply	other threads:[~2020-12-13  1:57 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-09  4:35 M Douglas McIlroy
2020-12-09 15:40 ` Clem Cole
2020-12-09 15:46   ` Niklas Karlsson
2020-12-09 16:01   ` Bakul Shah
2020-12-09 16:11     ` Clem Cole
2020-12-09 17:05       ` Bakul Shah
2020-12-09 17:42         ` Dan Stromberg
2020-12-09 23:46           ` Nemo Nusquam
2020-12-14 20:28     ` Dave Horsfall
2020-12-14 22:23       ` Thomas Paulsen
2020-12-14 23:04         ` Andrew Hume
2020-12-14 23:59       ` Harald Arnesen
2020-12-17  4:08         ` John Cowan
2020-12-15  2:57       ` Bakul Shah
2020-12-15  3:05         ` Warner Losh
     [not found]   ` <CAC20D2PXZY9aWgDf-RknROs6JbKEUjzbQ2BRzfTgTR07pXni3g@mail.g mail.com>
2020-12-09 16:04     ` John Foust
2020-12-09 16:40   ` Warner Losh
2020-12-09 16:53     ` Jon Steinhart
2020-12-09 16:58   ` Theodore Y. Ts'o
2020-12-09 19:58     ` Dan Cross
2020-12-09 20:30       ` Will Senn
2020-12-13  1:07       ` Theodore Y. Ts'o
2020-12-13  1:56         ` Jon Steinhart [this message]
2020-12-13  2:58           ` Theodore Y. Ts'o
2020-12-13  3:07             ` Jon Steinhart
2020-12-13 16:49               ` Theodore Y. Ts'o
2020-12-13 19:06                 ` [TUHS] Were cron and at done at the same time? Or one before the other? [ really linux and filesystems ] Jon Steinhart
2020-12-13  3:02         ` [TUHS] Were cron and at done at the same time? Or one before the other? Dan Cross
2020-12-09 23:22     ` Bakul Shah
2020-12-09 23:44       ` Steffen Nurpmeso
2020-12-09 23:51         ` Steffen Nurpmeso
2020-12-10  0:19   ` [TUHS] Cole's Slaw John Gilmore
2020-12-10  0:29     ` Larry McVoy
2020-12-10  0:53       ` Erik E. Fair
2020-12-10  3:10         ` George Michaelson
2020-12-12 21:11       ` Dave Horsfall
2020-12-10  1:49     ` John Cowan
2020-12-10  2:12       ` Jon Steinhart
2020-12-12  2:56   ` [TUHS] Were cron and at done at the same time? Or one before the other? Dave Horsfall
2020-12-12 19:10     ` scj
  -- strict thread matches above, loose matches on Subject: below --
2020-12-13  2:02 Noel Chiappa
2020-12-13  2:08 ` Clem Cole
2020-12-09 19:25 Noel Chiappa
2020-12-08 18:11 ron minnich
2020-12-08 18:51 ` Mary Ann Horton
2020-12-08 19:05   ` Larry McVoy
2020-12-08 19:20     ` Michael Kjörling
2020-12-09  2:00       ` Dave Horsfall
2020-12-08 19:39   ` Clem Cole

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202012130156.0BD1ufbY2698480@darkstar.fourwinds.com \
    --to=jon@fourwinds.com \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).