[TUHS] Re: FD 2

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

On Mon, Jan 30, 2023 at 11:09:03AM -0500, Dan Cross wrote:
> > > At one point it struck me that Plan 9 didn't succeed as a widespread
> > > replacement for Unix/Linux because it was bad or incapable, but
> > > rather, because people wanted Linux, and not plan9.
> >
> > Many people make that mistake.  New stuff instead of extend old stuff.
> 
> Some would argue that's not a mistake. How else do we innovate if
> we're just incrementally polishing what's come before?

The challenge is how do you extend the most common interfaces so that
you don't break the most common workflows and applications, without
adding too much backwards compatibility hair, and without stiffling
innovation.  I think we can err in both directions --- break the
world, and no one will adopt the OS, and too much backwars
compaibility and it's much, much harder to innovate.

The happy medium which Linux uses is that the userspace interfaces
should mostly stay compatible ("thou shoult not break userspace")
unless there are really, really good reasons (such as security
vulnerabilities) when you can't really do that.  But internal
interfaces, including those that might be used by out of three kernel
modules --- it's totally fair game, and if you have academics who have
professors who were trained up on the 4.14 kernel, when they were in
graduate school --- sorry, your knowledge is out of date, and you can
either force your graduae students to use an obsolescent kernel for
their research, or you're going to have to get with the times.

(I remember in the early days of BSD where people considered it a
feature that academic research tools wouldn't be broken; I believe I
remember hearing that as excuses not to rework with networking and tty
layers, whereas Linux rewrite the networking stack from scratch 2 or 3
times, and we've since completely reworked the block layer to deal
with ultra-fast devices, even if that meant that all external device
drivers would be broken.)

Of course, there will be kvetching no matter where you draw the line,
but simply saying, to *hell* with the old ways of doing things, and we
can't break anything, even internal interfaces, are both recipes for
failure IMHO.

> > As you said, people don't want to give up their mental model when that
> > model works.  They'll only give it up when there is at least a factor
> > of 2 improvement that they care about.  These days it feels like people
> > are stuck enough that they want a factor of 10.
> 
> Yup, that's about right. The mainframe is still going strong, after all!

One of the things that we can at $WORK is to be able to translate
storage TCO costs (cost per byte, cost per IOPS), cost of CPU
utilization, and cost of memory, etc., into SWE-equivalents.  So when
we propose a new initiative, we'll take the cost to implement the
project, as well as the cost to change all of the downstream users in
the software/storage stack, and do a cost benefit comparison.

For example, we might take the cost to implement the use of some new
storage technique, such as Hybrid SMR[1], dd a generous buffer because
projects always take longer and cost more than you first might think,
and then compare it to the 5 year storage TCO costs, using
SWE-equivalents as the common unit of comparison.  And the project
will only get green-lighted if the benefits exceed the costs by a
goodly margin.

[1] https://blog.google/products/google-cloud/dynamic-hybrid-smr-ocp-proposal-improve-data-center-disk-drives/

Of course, things are different if you are working in academia, where
things like getting published in a venue that will help build you or
your associates' tenure case are going to be more important.

In any case, if we are going to claim that programming is an
engineering discpline, then engineering tradeoffs are important to
remember.  Companies or departments who forget this lesson are much
more likely to get reminded of it when the activist investors start
pushing for layoffs, or when you start wonderng why your company had
to get sold off to the highest bidder...

						- Ted