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

Jon Steinhart jon at fourwinds.com
Sun Dec 13 11:56:41 AEST 2020

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.


More information about the TUHS mailing list