RIIR [LWN.net]

RIIR

Posted Feb 16, 2025 19:27 UTC (Sun) by marcH (subscriber, #57642)
In reply to: RIIR by pizza
Parent article: Rewriting essential Linux packages in Rust

> it still makes zero economical sense to preemptively rip out and replace the existing plumbing in literally billions of structures.

This is where software analogies always breaks down: the Economy.

- With software, replacing the existing plumbing in ONE house is barely cheaper than replacing it in ALL houses.
- The duplication cost is so negligible that a single guy doing some DIY work in his garage for fun - NOT for economical reasons - can (and here: does!) end up replacing the plumbing in all houses across the world.

The previous point was not about the economy at all. It was about "innovation". While it's not visible to users at all, there is "behind the scenes" innovation in uutils because it's a production-grade, potentially mass-deployed Rust project. It's admittedly less rocket science and more engineering but the latter matters too.

to post comments

RIIR

Posted Feb 16, 2025 22:41 UTC (Sun) by pizza (subscriber, #46) [Link] (5 responses)

> - With software, replacing the existing plumbing in ONE house is barely cheaper than replacing it in ALL houses.

That would be true if everyone, and every device, ran identical software in lock-step. Heck, even when the software components _are_ identical, they're often (usually!) integrated in different (if not completely bespoke) manners.

In the longer run, integration (and subsequent maintenance) is usually more work than writing the original software. (not unlike plumbing!)

> The previous point was not about the economy at all. It was about "innovation". While it's not visible to users at all, there is "behind the scenes" innovation in uutils because it's a production-grade, potentially mass-deployed Rust project.

"innovation" implies something new, not a 100% re-implementation (and necessarily quirk-for-quirk compatible) of existing (and well-maintained!) code.. Would you still be calling uutils "innovative" if it was written in oh, Ada, Java, Python, or PHP?

RIIR

Posted Feb 16, 2025 23:23 UTC (Sun) by marcH (subscriber, #57642) [Link] (4 responses)

> > - With software, replacing the existing plumbing in ONE house is barely cheaper than replacing it in ALL houses.

> That would be true if everyone, and every device, ran identical software in lock-step.

This is more and more irrelevant... I just gave a reminder that software marginal costs are negligible, which limits software analogies. How many devices are actually running what software does not matter: marginal software costs are still negligible and the economic aspect of software analogies still fails.

> "innovation" implies something new,...

Obviously.

> ... not a 100% re-implementation (and necessarily quirk-for-quirk compatible) of existing (and well-maintained!) code

That's part of your definition. My definition is "not in mass production yet" and it does not require cars to fly.

> Would you still be calling uutils "innovative" if it was written in oh, Ada, Java, Python, or PHP?

No because:
1) There would most likely be significant performance regressions (which obviously matter in "core" utils) instead of the progressions observed with Rust.
2) None of these languages are recent in 2025, they have all been in production for decades none of them needs any sort uutils-like project to help them get battle-hardened and "upgraded" to mass production.

So I suspect uutils in Java would be non-event.

Here's another analogy: designing and selling an electric car with a brand new, solid state battery design today would be "innovative" because it would help the solid state battery company scale up. That would be innovative even if the car company did nothing innovative besides trusting, partnering with and ultimately helping the innovative battery company doing all the innovative research and even when customers see "only" more range and less fire risk (= the battery equivalent of memory corruption?)

Once a few other Rust rewrites like uutils will be in "mass production" stage (e.g.: enabled by default in some distributions), then I agree the next ones won't be as "innovative" - and will get less press coverage. But there are several domains: first graphical application, first kernel driver, etc. Each domain has different engineering challenges requiring different "innovative" solutions.

RIIR

Posted Feb 17, 2025 14:32 UTC (Mon) by pizza (subscriber, #46) [Link] (3 responses)

> This is more and more irrelevant... I just gave a reminder that software marginal costs are negligible, which limits software analogies. How many devices are actually running what software does not matter: marginal software costs are still negligible and the economic aspect of software analogies still fails.

Just because *you* dismiss it as irrelevant doesn't make it so. The world is far larger than you.

"Marginal software costs" refer to the production of additional identical _copies_. If said copies are not identical, that margin rapidly grows. The computing world is anything but homogeneous.

Or are you seriously arguing that a binary driver written for a specific Windows version will enable that hardware to work on MacOS, all currently-supprorted Linux LTS distributions, and one of countless RTOSes running on the dozen-ish major microcontroller architectures? Heck, even if that driver was provided in source form, it's going to be a ton of work to enable the others -- and it's most likely to be simpler, faster, and cheaper to start over from scratch for each one.

> 2) None of these languages are recent in 2025, they have all been in production for decades none of them needs any sort uutils-like project to help them get battle-hardened and "upgraded" to mass production.

So... the "innovation" here is "Figuring out how to make Rust good enough to compete with stuff that's existed for decades?"

> Here's another analogy: designing and selling an electric car with a brand new, solid state battery design today would be "innovative" because it would help the solid state battery company scale up.

"helping the battery company scale up" is an example of longer-term planning and/or investment, not innovation.

(The battery technology itself, including specific manufacturing processes, may be innovative)

RIIR

Posted Feb 17, 2025 17:49 UTC (Mon) by marcH (subscriber, #57642) [Link] (2 responses)

> Just because *you* dismiss it as irrelevant doesn't make it so.

It's irrelevant to "Is uutils innovation?" which is the very specific disagreement in this subthread. Feel free to discuss software marginal costs or any other very interesting but unrelated question anywhere else.

> The world is far larger than you.

Thanks, that's very useful to know.

> So... the "innovation" here is "Figuring out how to make Rust good enough to compete with stuff that's existed for decades?"

Yes. It's a very important innovation milestone towards getting rid of memory corruption and 70% of vulnerabilities in operating systems, browsers (the other operating system) and more. You're entitled to your definition of "innovation" but mine does not stop outside the lab.

It's just a word definition; let's agree to disagree.

> "helping the battery company scale up" is an example of longer-term planning and/or investment, not innovation.

Not for the very first customer, no. It's most often a partnership and a huge bet.

RIIR

Posted Feb 17, 2025 17:57 UTC (Mon) by marcH (subscriber, #57642) [Link]

> ... your definition of "innovation" but mine does not stop outside the lab.

Simply because many "innovations" die once they leave the lab.

This is especially true with software which gets created and dies orders of magnitude more than in other fields (darn, and now I'm close to making your economic digression relevant...)

RIIR

Posted Feb 19, 2025 7:00 UTC (Wed) by marcH (subscriber, #57642) [Link]

> > So... the "innovation" here is "Figuring out how to make Rust good enough to compete with stuff that's existed for decades?"

> Yes. It's a very important innovation milestone towards getting rid of memory corruption and 70% of vulnerabilities in ...

From https://lwn.net/Articles/1008721/

> Ultimately, Poettering said that he is "happy to play ball" but does not want systemd to be the ones to solve the problems that need to be solved in order to use Rust.

That's the boring, last part of innovation: making it "mainstream". Rust is getting very close but not quite there yet. If ever?