--- title: OpenBSD's ports tree keeps GPL coreutils and rejects... description: A mailing list exchange on the OpenBSD ports list debates whether to package uutils, a Rust reimplementation of GNU coreutils, as an alternative to existing... canonical: https://daily.dev/posts/openbsd-s-ports-tree-keeps-gpl-coreutils-and-rejects-uutils-rust-rewrite--1eyxr3wii twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: OpenBSD's ports tree keeps GPL coreutils and rejects uutils (Rust rewrite) | daily.dev og:description: A mailing list exchange on the OpenBSD ports list debates whether to package uutils, a Rust reimplementation of GNU coreutils, as an alternative to existing... og:url: https://daily.dev/posts/openbsd-s-ports-tree-keeps-gpl-coreutils-and-rejects-uutils-rust-rewrite--1eyxr3wii og:image: https://api.daily.dev/og/posts/1eyxr3Wii.png og:image:alt: OpenBSD's ports tree keeps GPL coreutils and rejects uutils (Rust rewrite) og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # OpenBSD's ports tree keeps GPL coreutils and rejects uutils (Rust rewrite) **[Lobsters](https://daily.dev/sources/lobsters)** · 2 min read · 0 upvotes · 0 comments ## Summary A mailing list exchange on the OpenBSD ports list debates whether to package uutils, a Rust reimplementation of GNU coreutils, as an alternative to existing GNU utility ports. Theo de Raadt pushes back sharply on the proposal, arguing that subtly different tool behavior in a pipeline is undesirable regardless of license, and suspects the pitch for Rust-based utilities reflects an ideological agenda rather than genuine technical need. He also notes Ubuntu 26.10 has adopted uutils coreutils as sufficiently mature, while other uutils reimplementations remain less stable. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Has Ubuntu adopted the Rust-based uutils coreutils instead of GNU coreutils? Ubuntu 26.10 has adopted uutils coreutils, the Rust reimplementation of GNU coreutils, because the project reached a level of maturity and stability considered reliable enough for use. Other uutils reimplementations of different GNU utility sets are described as still more of a work in progress and not yet at the same maturity level. _Developers weighing GNU versus Rust coreutils across distros can follow adoption shifts like this on daily.dev._ ### Why is OpenBSD hesitant to package uutils as an alternative to GNU coreutils? OpenBSD developer Theo de Raadt objects because subtly different command behavior in reimplemented utilities risks breaking pipelines that rely on precise, standardized output from tools like ls, sed, or cut. He argues no one wants a drop-in utility replacement that behaves slightly differently, regardless of its permissive MIT license, and suspects the push for a Rust-based alternative reflects agenda rather than practical need. _Anyone evaluating coreutils rewrites for compatibility risk can track this kind of maintainer pushback on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 1 discussion and 23 comments across lobsters (as of 2026-09-30). **TL;DR:** Most commenters find OpenBSD's decision to reject the uutils packaging proposal reasonable given the risk of breaking scripts that depend on GNU-compatible behavior, though many push back on the framing of the debate as ideologically charged 'Rust agenda' drama rather than a pragmatic packaging discussion. **Sentiment:** 10% positive · 55% mixed · 35% skeptical **The case for** - Some argue uutils explicitly aims to be a drop-in replacement with differences treated as bugs, so compatibility concerns may be overstated. - A few note the proposal wasn't actually about changing the base system, just optionally packaging an alternative in ports. - Packaging under a separate prefix/path could avoid conflicts entirely, as one commenter demonstrated with their own package. **The pushback** - Several argue that even subtle behavioral differences in coreutils-compatible tools risk breaking scripts and pipelines that depend on exact GNU semantics. - Some see the original proposal (reusing g-prefixed names and replacing the compatibility layer) as a bigger and riskier change than simple ports packaging. - Bundling multiple uutils projects of varying maturity into one package was called needlessly risky. - One commenter suspects the underlying motive is stripping GPL code from Ubuntu for proprietary use, not genuine technical merit. **By community** - lobsters (mixed): Commenters largely support the pragmatic case for rejecting the proposal but are split on whether the 'Rust agenda' framing and hostility are fair or manufactured drama. **Hottest debate:** Whether uutils genuinely aims for zero behavioral differences from GNU coreutils or is just 'almost compatible,' and whether that distinction justifies the rejection. **Open questions** - Does OpenBSD have any package-alternatives mechanism (like Gentoo's eselect) to let competing implementations coexist? - Would packaging uutils under a separate prefix/namespace resolve the compatibility concerns without conflict? **Highlights** > I think part of the backstory is that the Rust Evangelism Strike Force has targeted the OpenBSD project in the past, only to be shut down for the simple reason that OpenBSD supports way more platforms than Rust does, and doing the "base builds base" bootstrap is essentially impossible outside mainstream archs (and even then it takes way longer with Rust). de Raadt is a testy guy in the best of times. Reminding him of previous attempts to push Rust is a bad idea. > — [gerikson on lobsters · 7 points, 1 comments](https://lobste.rs/s/vmmq7g/openbsd_s_ports_tree_keeps_gpl_coreutils#c_midifl) > > I wish we could discuss the pros and cons of various alternatives without painting some group as a supervilain. It's not painting them as a supervillain it's a descriptive name that came from *within the Rust community*. If someone proposes Rust, you will often find that you're talking to someone who uses Rust, contributes to the Rust ecosystem, and is well versed in the benefits and drawbacks of Rust. You can have a useful discussion with them. Often the result is that you find a use case for Rust. At other times you'll find you're talking to a member of the Rust Evangelism Strike Force, who will dismiss all legitimate concerns about Rust in specific contexts, dismiss all of the limitations of Rust *that the maintainers are very public and happy to talk about*, and claim that Rust is the perfect solution to these problems. You cannot have a productive conversation with these people and the fact that they jump into discussions all over the place telling you the rewriting everything in Rust is the solution to all of your problems means that often the positive aspects of Rust are drowned out. When I was at Microsoft, I coauthored a technical strategy document that recommended Rust in a lot of places and was used internally to motivate $10 M of internal Rust-directed funding and a $1 M donation to the Rust Foundation. I currently have a £2.7 M grant to make Rust a first-class citizen of the CHERIoT ecosystem, which will also let us move some of our core RTOS components over to Rust (I'm especially excited about Verus for this, because being able to have formally verified properties inline in the code is a *massive* win). I've had a lot of productive conversations with active Rust contributors and we've upstreamed some initial fixes that came out of the CHERI work. But the RETF is *absolutely* convinced that I have an irrational hatred of Rust and my opinion should be discarded on every Rust-related topic. If they're your only interaction with the Rust community, I can well understand the hostility. They're about as obnoxious as Ruby evangelists were 20 years ago. > — [david\_chisnall on lobsters · 2 points](https://lobste.rs/s/vmmq7g/openbsd_s_ports_tree_keeps_gpl_coreutils#c_flp14t) > I think this message could clear it up: https://www.mail-archive.com/ports%40openbsd.org/msg143900.html Coreutils are a package largely used on OpenBSD for software that depends on them. So replacing them with something else, "overwriting" these tools means that people will run into issues caused by those incompatibilities. I think this might not be clear to non-OpenBSD users: GNU coreutils is NOT what you get when you install OpenBSD. The major use case for having those are essentially a compatibility layer. This is not about adding a port, this is about replacing a compatibility layer with something that is going to work worse, simply because they are not the same tools. And if tweaks would need to be made then these tweaks can target what is available on OpenBSD, completely cutting out the need for any coreutils dependency. > — [reezer on lobsters · 3 points, 1 comments](https://lobste.rs/s/vmmq7g/openbsd_s_ports_tree_keeps_gpl_coreutils#c_nzhihg) > > The end goal is no differences. Absolutely not. There are lot of opinionated differences to make them more intuitive by default. rg is more intuitive than grep. fdfind is more intuitive than find. It really shows. But then, it subtly break (or not). For some times, I had been a great fan of those Rust utils because it was easier, with colours by default. Then I started to discover some discrepencies, to trully learn how to use the old GNU utils and I started to understand why there were build that way. No, I trully believe that the agenda in Ubuntu is to remove as much GPL code as possible to include in proprietary products. And it is quite surprizing that it is now Theo De Raadt that would defend the GPL at this point ;-) > — [ploum on lobsters · 1 points, 3 comments](https://lobste.rs/s/vmmq7g/openbsd_s_ports_tree_keeps_gpl_coreutils#c_qgriu5) > The main issue really are all the useless GNUisms found in scripts all over the place. It was a great strategy by the FSF to deviate from POSIX instead of working with POSIX to extend the standard, achieving an effective vendor lock-in. We see the same for instance with make and awk, as well. There needs to be more diversity among the core utilities, however, it means a huge maintenance overhead. The OpenBSD developers are smart not to pick up this weight. > — [FRIGN on lobsters · 3 points](https://lobste.rs/s/vmmq7g/openbsd_s_ports_tree_keeps_gpl_coreutils#c_bg9hu3) **Source threads** - [lobsters](https://lobste.rs/s/vmmq7g/openbsd_s_ports_tree_keeps_gpl_coreutils) · 16 points · 23 comments ## Similar posts on daily.dev - [Rust Coreutils Continues Working Toward 100% GNU Compatibility, Proving Trolls Wrong](https://daily.dev/posts/rust-coreutils-continues-working-toward-100-gnu-compatibility-proving-trolls-wrong-cuwdym0d1) · Phoronix · 1 upvotes · 0 comments - [Ubuntu Rust: How Canonical Is Modernizing Core System Tools](https://daily.dev/posts/ubuntu-rust-how-canonical-is-modernizing-core-system-tools-6irulsi7d) · JetBrains · 6 upvotes · 0 comments - [Project Discussion / Foundations](https://daily.dev/posts/project-discussion-foundations-ejlc9xpww) · Lobsters · 0 upvotes · 0 comments - [Bugs Rust Won't Catch](https://daily.dev/posts/bugs-rust-won-t-catch-wdxkf3gzv) · Hacker News · 2 upvotes · 0 comments --- Tags: [#rust](https://daily.dev/tags/rust), [#openbsd](https://daily.dev/tags/openbsd) [View this post on daily.dev](https://daily.dev/posts/openbsd-s-ports-tree-keeps-gpl-coreutils-and-rejects-uutils-rust-rewrite--1eyxr3wii) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"OpenBSD's ports tree keeps GPL coreutils and rejects uutils (Rust rewrite)","url":"https://daily.dev/posts/openbsd-s-ports-tree-keeps-gpl-coreutils-and-rejects-uutils-rust-rewrite--1eyxr3wii","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/openbsd-s-ports-tree-keeps-gpl-coreutils-and-rejects-uutils-rust-rewrite--1eyxr3wii"},"datePublished":"2026-09-30T09:37:55.064Z","dateModified":"2026-09-30T11:08:36.556Z","description":"A mailing list exchange on the OpenBSD ports list debates whether to package uutils, a Rust reimplementation of GNU coreutils, as an alternative to existing...","image":"https://media.daily.dev/image/upload/s--0_ODbtD2--/f_auto/v1722860399/public/Placeholder%2008","thumbnailUrl":"https://media.daily.dev/image/upload/s--0_ODbtD2--/f_auto/v1722860399/public/Placeholder%2008","isAccessibleForFree":true,"articleSection":"Lobsters","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Lobsters","logo":"https://media.daily.dev/image/upload/s--tl8v_Fku--/f_auto,t_logo/v1698841318/logos/lobste.jpg","url":"https://daily.dev/sources/lobsters"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/openbsd-s-ports-tree-keeps-gpl-coreutils-and-rejects-uutils-rust-rewrite--1eyxr3wii","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"rust,openbsd","timeRequired":"PT2M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Lobsters","item":"https://daily.dev/sources/lobsters"},{"@type":"ListItem","position":3,"name":"OpenBSD's ports tree keeps GPL coreutils and rejects uutils (Rust rewrite)"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/openbsd-s-ports-tree-keeps-gpl-coreutils-and-rejects-uutils-rust-rewrite--1eyxr3wii#faq","mainEntity":[{"@type":"Question","name":"Has Ubuntu adopted the Rust-based uutils coreutils instead of GNU coreutils?","acceptedAnswer":{"@type":"Answer","text":"Ubuntu 26.10 has adopted uutils coreutils, the Rust reimplementation of GNU coreutils, because the project reached a level of maturity and stability considered reliable enough for use. Other uutils reimplementations of different GNU utility sets are described as still more of a work in progress and not yet at the same maturity level. Developers weighing GNU versus Rust coreutils across distros can follow adoption shifts like this on daily.dev."}},{"@type":"Question","name":"Why is OpenBSD hesitant to package uutils as an alternative to GNU coreutils?","acceptedAnswer":{"@type":"Answer","text":"OpenBSD developer Theo de Raadt objects because subtly different command behavior in reimplemented utilities risks breaking pipelines that rely on precise, standardized output from tools like ls, sed, or cut. He argues no one wants a drop-in utility replacement that behaves slightly differently, regardless of its permissive MIT license, and suspects the push for a Rust-based alternative reflects agenda rather than practical need. Anyone evaluating coreutils rewrites for compatibility risk can track this kind of maintainer pushback on daily.dev."}}]} ```