If you provide a fixed string as the random source, then it will "randomise" in the same way every single time. To prove this, let's test it.
$ printf '%s\n' a b c | shuf --random-source=<(echo durian)
On my system, the output is the same every time I run the command above. (I suspect it might be different depending on the implementation, but it should still be the same every time.) You are hard-coding the randomness, as per this XKCD:
It's not really random; it's just producing the same output every time. The size of the fixed-string source is irrelevant. It's still fixed.
There's relevant info in the link you provide relating to the random quality of the random source:
/dev/urandom suffices for most practical uses, but applications requiring high-value or long-term protection of private data may require an alternate data source like
The latter two options are "more random" than the first. The implication is that the more random the source, the more random the shuffling. Hence, fixed strings are not particularly robust.
shuf specifically, the length of the fixed string is relevant. For example, the following fails.
shuf -i1-19 --random-source=<(echo durian)
However, if you restrict output to
-n16, it works, but
-n17 fails. I tested a few different words and permutations, and as I reduce the number of characters in the source, the maximum
-n goes down.
source length max -n
I'm not sure of the direct relationship, but presumably additional sorted items (in
-n) require more source characters as seeds. Nevertheless, in
shuf at least, once you pass this minimum threshold, each additional character makes no difference to the randomness per se. In the above example, if you change the 50th character the output will still be the same.