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.
Bit hostile. I get the point that it's unnecessary, but the whole "agenda" thing feels kneejerk. Just say that being written in Rust isn't a good enough reason for adoption.
I disagree. It takes a different personality and position to maintain a project like this. If you aren’t the biggest asshole then you’re at the mercy of the biggest asshole, which probably means you’re going to end up making ideological decisions rather than engineering decisions. Especially seeing has how politicised everything is these days.
Thus has exactly the communication style that is required to support the project.
And yes I have been on the end of a Theo quip. It’s a badge of honour because ultimately he was right.
I agree that strong leadership is a requirement. However there’s a huge difference between being strong against pushy arseholes, and preemptively being an arsehole because people make allowances for your behaviour to others.
This just comes down to effective communication skills. And is evident by the number of other large projects survive without the rudeness.
Theo isnt an example that deserves emulation and admiration.
I’m not sure I agree. My own management experience in engineering and software has shown that strong leadership means saying no quite a lot. Ideas come with best intent mostly but dangerous realities. A soft no is a keep trying to most engineering folk. Shutting something down needs a Theo.
You’re talking as Theo is the only form of strong management. As someone who is also an engineering manager, I can tell you that there are ways of saying “no” without being an arsehole.
I do agree that sometimes you just need to end the discussion. But that doesn’t mean that arsehole comments should be the default character trait.
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:
---
---broodbucket · · focus · HN ↗
hnlmorg · · focus · HN ↗
In fact this feels remarkably tame by his standards.
The guy is undoubtedly an exceptional talent. But his communication skills isn’t one of them.
sdcfgy · · focus · HN ↗
Thus has exactly the communication style that is required to support the project.
And yes I have been on the end of a Theo quip. It’s a badge of honour because ultimately he was right.
hnlmorg · · focus · HN ↗
This just comes down to effective communication skills. And is evident by the number of other large projects survive without the rudeness.
Theo isnt an example that deserves emulation and admiration.
sdcfgy · · focus · HN ↗
hnlmorg · · focus · HN ↗
I do agree that sometimes you just need to end the discussion. But that doesn’t mean that arsehole comments should be the default character trait.
sdcfgy · · focus · HN ↗
hnlmorg · · focus · HN ↗
Or at least that’s our point of contention.