With the news that debian is looking to adopt uutils, will Whonix also be moving to uutils?

With the news that debian is looking to adopt uutils, will Whonix also be moving to uutils?

I have heard three good arguments against uutils.

  1. Rust is an unstable language, with an unstable compiler. This means that it cannot be considered reliable enough to trust for mission-critical software.
  2. The uutils versions of the GNU coreutils do not behave identically. They have several serious bugs, some of which are serious security bugs.
  3. The GNU coreutils, written in C, can be made memory-safe by compiling them with Fil-C. Pizlix: Memory Safe Linux From Scratch

Does whonix agree or disagree with this reasoning?

Kicksecure and Whonix are based on Debian:

Therefore in virtually all cases, we inherit core system changes from Debian.

Note that Debian is unlikely to switch to uutils. See the discussion at:

(Note that the title of the thread is unintentionally misleading; this initial post was made by a GNU coreutils contributor who believed Debian was moving to uutils. The ensuing discussion clarified this.)

Intentionally declining to comment. Opinions on uutils are very unlikely to have an impact on whether we end up using it.

Moderation comment:

Per Development Discussion Policy, this thread may be locked if debate around architectural decisions develops, or becomes controversial. This forum isn’t the right place to express criticism of uutils, coreutils, or the developers or communities of either project.

1 Like

This forum isn’t the right place to express criticism of uutils, coreutils, or the developers or communities of either project.

But it is the right place to discuss Whonix’s “freedom software principles":

If Debian ever takes up MIT uutils, there will be a problem for Whonix. But as you said, it is not clear that they will, so we shouldn’t sound the alarm yet.

@qtzvytqr77x4t5cq

Rust is an unstable language, with an unstable compiler. This means that it cannot be considered reliable enough to trust for mission-critical software.

This is a poor argument. There is nothing wrong with Rust. The compiler is slow by some measures, but I’ve never heard anyone complain that it’s “unstable”. If you mean it isn’t mature, well, 2026 Rust isn’t 2018 Rust. I think it’s plenty mature now.

The uutils versions of the GNU coreutils do not behave identically. They have several serious bugs, some of which are serious security bugs.

The MIT uutils are not complete. They’re supposed to be feature-for-feature drop-ins, but they are not. Not yet.

This makes it curious why Ubuntu is rushing forward with them. I have a very cynical view of this, especially given the “the licensing issue is not up for discussion” policy surrounding it. It has turned me off permanently from Ubuntu. I’ve banished the OS from my life.

The GNU coreutils, written in C, can be made memory-safe by compiling them with Fil-C.

Yeah, well, who knows? Maybe.

A better point is that GNU coreutils have been around and battle tested for ages. They’re not bleeding edge applications. They are not in desperate need of Rust rewrites.

And undercooked, feature-deficient Rust rewrites aren’t exactly a great calling card. Just because Rust can get rid of memory safety bugs doesn’t mean bad programmers can’t add many business logic bugs.

The whole thing stinks of a corporate conspiracy aimed at further entrenching corporate control. As I’m sure you know, corporations fear the GPL like vampires fear the Cross.

I still believe that rewriting everything in Rust is a good idea. However, the licensing politics around “oxidation” has turned me off the idea almost completely. I used to support the idea of rewriting the Linux kernel in Rust. But now I am against it. There is too much risk, and the Rustacean culture is indifferent at best.

These days, if it’s not GPL, I try to avoid it. I’ve stopped using a number of handy tools that sit a little too close to GNU userspace, bat for example. I no longer tolerate this. I use cat, or I’ll write my own pager. Then I’ll learn more, and I can release it in GPL.

If Debian were to switch, and Whonix followed, it would put me in a bind. I would be less inclined simply to banish Whonix. Maybe uninstall MIT uutils and reinstall GNU coreutils?

Whonix may be under GPL license, and that may be reasonably construed as “support the GPL”, however Whonix hasn’t formalized any “GPL yes MIT no” (preference). Related policy:

The existing moral authorities (as imperfect some of them might be [1] I keep referring to are FSF, OSI and Debian DFSG. And all 3 organisations do accept the MIT license.

From GNU

Various Licenses and Comments about Them

Not the best commentary.

But still accepted.

As per above, MIT does qualify.

Whonix Default Application Policy does express:

Must be Freedom Software / Open Source.

but doesn’t have a “chose GPL over other licenses” preference. Software selection and configuration as a distribution is difficult enough, I don’t think we have the luxury to prefer some FSF, OSI, DSFG approved licenses (GPL) over others (MIT).

As per Whonix usual No Intentional User Freedom Restrictions - if it comes to that - replace one package from Debian with another package from Debian should be easy - unless Debian stops packing GNU coreutils - but that is even more hypothetical and far fetched at this point (this would require no Debian Developer interested in maintaining the package anymore, that seems highly unlikely at the time of writing).


[1] Open Source AI Definition - Lack of Consensus in the Definition by the Open Source Initiative