gofakeit VS coreutils

I have to admit that I fell into a rabbit hole, and I noticed that popular tools like fakerjs or gofakeit[0] did not meet my needs.

I needed to generate realistic-looking identities; the person's photo must match the gender, same for the age, the skin color of the person must correspond with the origin of the surname, the first name should be common in the targeted country, and the residential address must be real, among other things.

You would not use this for test data btw, a common use case for this would be for marketing or spamming operations where you need realistic data. My consciense does not accept the later however ;-)

[0] https://github.com/brianvoe/gofakeit

Thank you! No, it’s just random data (here’s a link: https://github.com/brianvoe/gofakeit/blob/master/data/address.go)

So, is JR yet another faking library written in Go? Yes and no. JR indeed implements most of the APIs in fakerjs and Go fake it, but it's also able to stream data directly to stdout, Kafka, Redis and more (Elastic and MongoDB coming). JR can talk directly to Confluent Schema Registry, manage json-schema and Avro schemas, easily maintain coherence and referential integrity. If you need more than what is OOTB in JR, you can also easily pipe your data streams to other cli tools like kcat thanks to its flexibility.

Tangentially related, but there is a package out there called go-fakeit github.com/brianvoe/gofakeit.git for generating random data, which doesn't sound like it entirely maps with what you're doing, but there may be some overlap.

Its not much but I have had success with a random data generator package for golang called https://github.com/brianvoe/gofakeit. Its not live changing but hopefully it helps out enough developers.

Using mock data is a great way to speed up the prototyping process. We will use the GoFakeIt package to create a little dummy data generator to insert into our PDF.

The new v6 release now supports the ability to have localized rand that allows for concurrent generating of random data. Crypto/rand has now been integrated as well as if you have a custom rand that fulfills the math/rand source64 interface you can use it with gofakeit. Let me know your thoughts.

https://github.com/brianvoe/gofakeit

https://github.com/coreutils/coreutils/commit/fcfba90d0d27a1...

A summary of other changes just released in GNU coreutils 9.5 are:

* mv accepts --exchange to swap files

> some are simple like yes(1)

Not that simple: https://github.com/coreutils/coreutils/blob/master/src/yes.c

The -S / --split-string option[1] of /usr/bin/env is a relatively recent addition to GNU Coreutils. It's available starting from GNU Coreutils 8.30[2], released on 2018-07-01.

Beware of portability: it relies on a non-standard behavior from some operating systems. It only works for OS's that treat all the text after the first space as argument(s) to the shebanged executable; rather than just treating the whole string as an executable path (that can happen to contain spaces).

Fortunately this non-standard behavior is more the norm than the exception: it works at least on modern GNU/Linux, BSDs, and macOS.

[1] https://www.gnu.org/software/coreutils/manual/html_node/env-...

[2] https://github.com/coreutils/coreutils/blob/b09dc6306e7affaf...

> building a cat from scratch

> That would be an interesting project.

Here is the source code of the OpenBSD implementation of cat:

> https://github.com/openbsd/src/blob/master/bin/cat/cat.c

and here of the GNU coreutils implementation:

> https://github.com/coreutils/coreutils/blob/master/src/cat.c

Thus: I don't think building a cat from scratch or creating a tutorial about that topic is particularly hard (even though the HN audience would likely be interested in it). :-)

the yes command, writing to /dev/null, is making IO calls, which interfere with predictable scheduling.

If you look at the source code for yes, https://github.com/coreutils/coreutils/blob/master/src/yes.c

it builds a buffer of output and then writes that in a for loop

  while (full_write (STDOUT_FILENO, buf, bufused) == bufused)

Looking at the source of nohup, if the execvp() of the child happens then it _must_ have already done the signal (SIGHUP, SIG_IGN) so - WTF?

This got me wondering so I went and looked and it seems like lo and behold there was actually a commit to the GNU ls source just 2 weeks ago.

https://github.com/coreutils/coreutils/blob/master/src/ls.c

"maint: prefer char32_t to wchar_t"

even an empty file? Yes. so now it was a file with a copyright disclaimer and nothing else. And the koan-like question comes to mind is "Can you copyright nothing?" well AT&T sure tried.

Then somebody said our programs should be well defined and not depend on a fluke of unix, which at this point was probable a good idea. so it became "exit 0"

Then somebody said we should write our system utilities in C instead of shell so it runs faster. openbsd still has a good example of how this would look.

http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr....

At some point gnu bureaucracy got involved and said all programs must support the '-h' flag. so that got added, then they said all programs must support locale so that got added. now days gnu true is an astonishing 80 lines long.

https://github.com/coreutils/coreutils/blob/master/src/true....

http://trillian.mit.edu/~jc/humor/ATT_Copyright_true.html

> Yes, ls is maintained. Although, maintained is a very strong word. It exists.

Why would it be a strong word? Here it is, in src/ls.c: https://github.com/coreutils/coreutils

It is then packaged by tens of operating system distributions, who themselves maintain extra patchsets, some of which are then upstreamed.

It is installed and used on millions (billions?) of devices, for 3 decades.

It's a very reliable and trusty "sharp stick of metal" :)