RIIR
RIIR
Posted Feb 16, 2025 22:41 UTC (Sun) by pizza (subscriber, #46)In reply to: RIIR by marcH
Parent article: Rewriting essential Linux packages in Rust
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?
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