Of note is Theo's answer which follows below:
---
Theo de Raadt Sun, 20 Sep 2026 12:03:20 -0700
David Uhden Collado <daviduh...@gmail.com> wrote:
> Stuart Henderson wrote:
> > On 2026/09/20 07:01, David Uhden Collado wrote:
> >> The main goal of the packaging is to make these implementations usable
> >> as alternatives to the existing GNU utility ports without requiring
> >> source changes in dependent ports.
> >>
> >> For example, uutils-coreutils installs the same g-prefixed command names
> >> as sysutils/coreutils, including gcat, gls, gcp, gdate, gsort, gstat,
> >> gtail, gtimeout and the other GNU-compatible utilities. They are
> >> symlinks to the upstream multicall binary, which is installed under
> >> libexec/uutils.
> > ...
> >> Each package conflicts with its corresponding GNU implementation and
> >> declares the GNU port as a secondary @pkgpath.
> > I don't think this is a usable approach for ports.
>
> The truth is, I find these Rust reimplementations quite
> interesting. Ubuntu 26.10 has already adopted uutils coreutils because
> the project has reached a level of maturity and stability where it can
> be used reliably. The other reimplementations are still more of a work
> in progress.
Smells like agenda.
> I also think they fit quite well with OpenBSD as alternatives to GNU
> utilities, particularly because they use a permissive MIT license.
Argument is vaguely like: because we already have permissive licenced
utilities, our user base are really interested in having a second set of
permissive licenced utilities which are very subtly different.
That makes no sense. Noone wants subtly different behaving binaries as
part of their workflow. If someone runs the openbsd ls command as part
of a pipeline that uses openbsd sed, or openbsd cut, or some other
openbsd utility and it parses a non-standized output characteristic
by accident, there are no people in this universe who wants to replace
that ls with a different ls and get surprised by un-standardized tooling
behaviour clash.
> I'm not sure yet whether it's possible to install the individual
> utilities as separate binaries. This is new territory for me, since
> uutils is structured as a metapackage, and because it's written in
> Rust.
Oh, because it is written in Rust.
Your agenda is showing.
I couldn’t agree more with Theo on this one. I suspect a lot of people interested in doing this stuff haven’t had to maintain anything for a long time (10 years+). This to me feels like the painful switch between SunOS and Solaris we had to do back in the day. Lots of very small differences. And you have to maintain them forever if you have dual stacks of tools.
Not only that the rust ecosystem imports a HUGE difficult to control surface area.
Always feels like a vanity project when I see ideological rewrites. Also didn’t they introduce a ton more CVEs doing this on the Ubuntu side.
Interestingly, the mailing list discussion being talked about happened roughly a week after this Hacker News thread highlighted afresh all of the Ubuntu LaunchPad bugs being left hanging; and highlighted a major problem with rm that, probably not coincidentally, suddenly saw fresh attention after being around for years, the same day as the Hacker News entry appeared.
I completely missed that thread. Just the first post is horrifying.
About a year ago I switched from Debian to FreeBSD (after going back the other way in 2003) because even that was getting wonky. Glad I’m far far away from this crap.
bel8 · · focus · HN ↗
<a href="https://www.mail-archive.com/ports@openbsd.org/msg143875.html" rel="nofollow">https://www.mail-archive.com/ports@openbsd.org/msg143875.htm...
Of note is Theo's answer which follows below:
---
---sdcfgy · · focus · HN ↗
Not only that the rust ecosystem imports a HUGE difficult to control surface area.
Always feels like a vanity project when I see ideological rewrites. Also didn’t they introduce a ton more CVEs doing this on the Ubuntu side.
JdeBP · · focus · HN ↗
* <a href="https://news.ycombinator.com/item?id=49697392">https://news.ycombinator.com/item?id=49697392
sdcfgy · · focus · HN ↗
About a year ago I switched from Debian to FreeBSD (after going back the other way in 2003) because even that was getting wonky. Glad I’m far far away from this crap.