Go and read the thread yourself [1] and you will see that the reason it was rejected was that no one saw a reason to take on the maintenance burden when you already need to have Gnu Core Utilities in ports to be able to build a heap of other ports. Focusing on theo@ calling out the submitter for having their judgement clouded by "Because Rust" misses the point.
[1]: https://www.mail-archive.com/ports@openbsd.org/msg143875.htm...
Besides, Rust already has a solid presence in ports and I know several experienced OpenBSD developers dabbling in it. But the language will never make it into base in its current form as OpenBSD expects self hosting and I think everything in base is Posix(-like), apart from Perl, but I have not taken the time to go digging through my /usr/src.
"Also, some contributions had carried comments and code over from GNU coreutils, against our own rule that uutils is an original implementation. We reviewed the tree and rewrote what we found, in comments and in the few functions that followed the C too closely"
https://www.mail-archive.com/ports@openbsd.org/msg143875.htm...
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.
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.
Also stuff like: "Set Permissions at Creation Time, Not After"
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.
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.
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.
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 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.
It's the projects shield, and pretty good one at that ;)
Linux went through this evolution with Linus Torvalds, and plenty of other projects have managed to have strong leadership without the hostility.
But you can, it's also a really good way to shy away "over-sensible" individuals, if you think that was rude.....well ;)
>Linux went through this evolution with Linus Torvalds
Not he's still the old one, just without "retro abortion"
You say that like it’s a good thing but it’s really not. All you’re doing is poisoning your own well. Shitting your own bed. And other analogies that emphasise an own goal.
The last thing a project with limited broader appeal, and that appeal diminishing with the homogenisation of POSIX platforms, is someone trying their hardest to make their community even less appealing to others.
> if you think that was rude.....well ;)
Id already said that comment was tame. What I’m saying is that Theo is more generally rude.
whoever wrote/generated the article does not seem to understand email syntax
It's unfortunate that the supposed pillar of security dismisses Rust on dubious grounds. Yes, there is agenda coming from Ubuntu. And yet, Rust IS the secure alternative to C/C++ (alternative is a misnomer, it's better than the latter on all fronts), so OpenBSD dismissal is very superficial.