RIIR
RIIR
Posted Feb 15, 2025 12:04 UTC (Sat) by pizza (subscriber, #46)In reply to: RIIR by marcH
Parent article: Rewriting essential Linux packages in Rust
And the production facilities and distribution are essentially free, because this magical material is produced by self-replicating spherical unicorns that feed on greenhouse gasses.
But even if all these properties were somehow true, it still makes zero economical sense to preemptively rip out and replace the existing plumbing in literally billions of structures.
Posted Feb 16, 2025 19:27 UTC (Sun)
by marcH (subscriber, #57642)
[Link] (6 responses)
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 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.
Posted Feb 16, 2025 22:41 UTC (Sun)
by pizza (subscriber, #46)
[Link] (5 responses)
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?
Posted Feb 16, 2025 23:23 UTC (Sun)
by marcH (subscriber, #57642)
[Link] (4 responses)
> 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:
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.
Posted Feb 17, 2025 14:32 UTC (Mon)
by pizza (subscriber, #46)
[Link] (3 responses)
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)
Posted Feb 17, 2025 17:49 UTC (Mon)
by marcH (subscriber, #57642)
[Link] (2 responses)
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.
Posted Feb 17, 2025 17:57 UTC (Mon)
by marcH (subscriber, #57642)
[Link]
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...)
Posted Feb 19, 2025 7:00 UTC (Wed)
by marcH (subscriber, #57642)
[Link]
> 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?
Posted Feb 20, 2025 7:07 UTC (Thu)
by ssmith32 (subscriber, #72404)
[Link]
Yeah, production/packaging and distribution is essentially free for the software in question ("small" command line tools).
You never have the "lone maintainer" problem for the production and distribution of large pipes and fittings, at least produced at the scales we're discussing, because you simply _can't_.
It may not feel that way for the lone maintainer, for sure, but an objective comparison of the costs demonstrates otherwise.
RIIR
- 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.
RIIR
RIIR
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.
RIIR
RIIR
RIIR
RIIR
RIIR