[TUHS] Re: FD 2

On Mon, Jan 30, 2023 at 11:09:03AM -0500, Dan Cross wrote: 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. 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-i… 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