I was looking at simplifying the interface a bit.
Given we've not released this yet, the first release
of the interface is important to define compatibility.
In summary I was thinking dropping support for the buz32 variant
as it would allow us to avoid specifying the 32/64 variants entirely.
I.e. the new interface would be:
gear/N equivalent to gear[64]/N
gear[32]/N 32-bit GearHash with a 32-byte window
gear[64]/N 64-bit GearHash with a 64-byte window
buz/N equivalent to buz[4095]/N
buz[W]/N 64-bit BUZHash with a W-byte window, W >= 8
Advantages:
* The user selects the hash family and content window,
not needing to worry about implementation width.
_bit_ with correlation with window _byte_ width is confusing anyway.
* Gear variant is effectively chosen with the window size.
* BUZHash window and arithmetic width are independent,
so exposing both dimensions provides little practical value.
* BUZHash would no longer have a 42 MB average-size restriction.
I've attached am info doc update for the above proposal.
Also for split's use cases I'm not use --random-source is required.
The built-in table already gives portable reproducibility,
and I can't think of split(1) needing keep boundary selection secret.
cheers,
PadraigFrom 9a11792d4af8aeb4d59497c9b4febae682022d2b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= <[email protected]>
Date: Mon, 27 Jul 2026 18:25:44 +0100
Subject: [PATCH] doc: split: adjust info docs to simplified interface
* doc/coreutils.texi (split invocation): Remove buz32 as an option.
---
doc/coreutils.texi | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 2ea65ae75..aa9bb38a4 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -3300,8 +3300,8 @@ option syntax @option{-@var{lines}}. New scripts should use
Put @var{size} bytes of @var{input} into each output file.
@multiplierSuffixes{size}
-Content-defined chunking (CDC) might be done with @var{size} specifying
-@var{hash} function, average and maximum sizes of chunks:
+Content-defined chunking (CDC) is performed with @var{size} specifying
+a @var{hash} function, average and maximum sizes of chunks:
@c to avoid line length limits
@macro vh
@@ -3318,17 +3318,17 @@ Content-defined chunking (CDC) might be done with @var{size} specifying
@vh[@var{w}]/@vn/@var{k} like @vh[@var{w}]/@vn and @vh/@vn/@var{k} combined
@end example
-Supported @var{hash} functions are @samp{gear32}, @samp{gear64}, @samp{buz32}
-and @samp{buz64}. BUZHash supports arbitrary sliding window size, GearHash
-window is fixed to be 32 and 64 bytes. Alternative seed value for @var{hash}
-functions might be specified with @option{--random-source=@var{file}}.
-Size of @var{file} needed depends on @var{hash} function:
+Supported @var{hash} functions are @samp{gear}, and @samp{buz}.
+BUZHash supports arbitrary sliding window size, while GearHash can be more
+efficient, as its window is fixed to be 32 or 64 bytes. Alternative seed values
+for @var{hash} functions can be specified with
+@option{--random-source=@var{file}}, with the required size of @var{file}
+depending on @var{hash} function:
@example
-@samp{gear32} 1KiB, unless entropy is completely absent
-@samp{gear64} 2KiB
-@samp{buz32} 5KiB, with a little bit of luck
-@samp{buz64} 10KiB
+@samp{gear[32]} 1KiB, unless entropy is completely absent
+@samp{gear[64]} 2KiB
+@samp{buz} 10KiB
@end example
@optItem{split,-C,@w{ }@var{size}}
--
2.55.0
