Could Apple consider replacing traditional BSD utilities with uutils?

This idea is based on a few key points:

  1. GNU Coreutils has essentially become the de facto standard with the widespread adoption of GNU/Linux. Apple has been attracting modern developers by being 'Linux-like' (via POSIX-compliant), especially since Linux has largely won the race in the general-purpose Unix-like OS space. Adopting uutils would allow scripts to run much more seamlessly across macOS and Linux.
  2. uutils is compatible with GNU Coreutils, and its MIT license avoids the strict restrictions associated with GPLv3.
  3. By aligning base commands more closely with Linux, I think this would give macOS another compelling advantage over WSL2 for developers.

As far as I know, back in the early 2000s, Steve Jobs frequently used Linux as a point of comparison to explain Mac OS X's POSIX compatibility in an accessible way. In my personal view, Apple has indeed been consciously or unconsciously aligning its development experience closer to Linux (perhaps even more so than traditional BSD).

Could Apple consider replacing traditional BSD utilities with uutils?

If you don't mind me asking, what are the specific behavior/tools/changes you'd like us to adopt?

The biggest reason our tools diverge from other systems is that their underlying implementations are in fact different. For example, "copyfile()", which has become the system core copy API, doesn't exist on Linux. In a similar vein, fts() (the directory enumeration API underneath copyfile) does exist on Linux (at least some versions), but it's generally considered a legacy API and isn't in wide use.

Critically, these differences aren't purely cosmetic. copyfile() doesn't just duplicate bytes from one file to another. Within a filesystem, it uses clonefile() to avoid unnecessary duplication and, in the even more complicated case, when copying between APFS volumes, it preserves clone state (copying an initial file, then using that file as the "source" for any related clones) to minimize directory growth crossing file systems. It also handles the complexity of determining exactly which file system attributes (and you'd be surprised at how complicated this is) should/should not be preserved, an issue which is both operating system and file system specific.

Switching to fts(), our adoption of it is tied to a very long (all the way back to Classic MacOS) preference for using "bulk" file metadata retrieval[1] instead of making individual syscalls for every file. Historically, this approach was less common on other operating systems, but it was a critical performance optimization on HFS+ and has significant benefits on HFS+.

That's an extended example from one area of the system, but the basic dynamic is common to many other system components. The core reason we maintain our own command line tools is simple: macOS doesn't work differently than other Unix systems[2].

All of that's why I asked my original question. That is, while the reasons above make it unlikely that we'll simply move to a different tool chain, it's certainly possible that we might include tools or implement options that were particularly useful. If there are specific things you'd like us to adopt, then the best approach is to file bugs explaining what you'd like us to do and why. Note that the "why" is the most important point there, not the what.

[1] Using a single syscall to retrieve the metadata about multiple files using a single syscall instead of making multiple syscalls for every file.

[2] Developers familiar with the history of Unix's divergence and evolution will note how broadly that statement could be applied.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Could Apple consider replacing traditional BSD utilities with uutils?
 
 
Q