5 ms·

I got hung up on the claim "Touch is by default idempotent. ... A second call won’t have any effects". The whole point of touch is to have an effect every singl

I got hung up on the claim "Touch is by default idempotent. ... A second call won’t have any effects". The whole point of touch is to have an effect every single time you run it. It updates the file atime and mtime. That may seem harmless in your application, but it's definitely not no effect. Also promiscuous touching is the source of a bunch of bogus last modified dates in source code bundles.

deleted 7y ago
[deleted]
joshspankit 7y ago
In other words: When promiscuous touching, always make sure you’re not making things unsanitary.
- vages 7y ago
  I'm sure you can find a way to avoid promiscuous touching if you read the (gentle)man page.
- dang 7y ago
  Please don't do this here.
stephenr 7y ago
I had the same thought about `ln -sf` - removing and recreating the symlink aren't no-effect.
- fpoling 7y ago
  To avoid that I use readlink in my scripts to read the previous value of the link and call ln -s only when the value is not what is expected.
kousikk 7y ago
Last modified timestamps in source code are a bad idea and they make builds non-hermetic. Better to fix up those scenarios in code than work around them. Irrespective you have a good point that touch does have side effects.
- rgoulter 7y ago
  FWIW, I don't think "hermetic" is in widespread usage. My understanding is that "hermetic builds" refer to the kind of thing that tools like Guix, Nix, etc. go for. Something like "Declare all the inputs and dependencies to get a reproducible output".
  - pmarreck 7y ago
    I prefer "deterministic" in this case (I think?)
    - rectangletangle 7y ago
      I've always heard "deterministic" or "reproducible," curious if the term "hermetic" is somehow different in this context.
      - gen220 7y ago
        Google’s release engineering docs describe hermetic build processes as those which are “insensitive to the libraries and other software installed on the build machine. Instead, builds depend on known versions of build tools, such as compilers, and dependencies, such as libraries. The build process is self-contained and must not rely on services that are external to the build environment.” Basically, if your build process requires you to pull code from any repository that you do not own, it isn’t hermetic. If you have to `pip install` or `go get` a third party (or even in-house!) dependency from a source that you do not control, your build is not hermetic. Effectively, this means that you have to have versioned copies of all of your third party dependencies, and version-specified build graphs. Very hard to do without a mono repo and a build tool. In the context of the GP, I’d say that deterministic would have been a better word choice. A reliance on time stamps technically wouldn’t make a build process non-hermetic, but it would definitely make it non deterministic. It’s technically possible to have hermetic builds without having reproducible builds, although that would be a very bizarre org. :)
dymk 7y ago
Within the scope of the article, which is about modifying the structure and logical contents of the filesystem (a-la `chef converge` - the author never once mentions FS metadata), it's idempotent.
farslan 7y ago
Op here. Yeah you’re right. I’ve mentioned it though in the context of file contents. Just updated to make it clear.
riazrizvi 7y ago
I've heard Idempotency confused with Consistency. Idempotency is where a function f can be applied (as a composition) multiple times and it gives the same result, so Idempotency: f(f(x)) = f(x). Whereas Consistency: f(x) = f(x) = f(x). An example of an idempotent function f is RaiseToThePowerZero(x) on x > 0. We usually take consistency for granted, so it's perhaps better to think of an example of a non-consistent function f which would be RandomNumberGenerator().
- JoeAltmaier 7y ago
  Better examples: Write("filename", position, data) is idempotent; Append(handle, data) is not.
  - riazrizvi 7y ago
    Write("filename", position, data) inputs 3 arguments and outputs probably only 1, a file. So is not a function that you can convolute, you cannot pass the output of Write() as the input to another Write(). So instead, f: SetFirstWordOfFileToZeros(file)=>file, would be a better example if we want file functions. Then SetFirstWordOfFileToZeros(SetFirstWordOfFileToZeros(file))=SetFirstWordOfFileToZeros(file).
    - JoeAltmaier 7y ago
      Yes mathematically composability is part of it. That's because math functions return the same type. Its easy to express the 'state' of a function as the value of the operation. There's a wider idea of idempotency in computing - that state changes in general respond to operations. Repeating the same function more than once (because the network stuttered or the sender resent the message) and arriving at the same state is a common example.
- mehrdadn 7y ago
  > as a convolution Sorry, what does idempotency have to do with convolution?
  - 7y ago
mehrdadn 7y ago
Just a note... even reading a file updates the access time, so if you reason this way then no program touching any files in the worktree will ever be idempotent... which seems to lose the utility of the concept.

deleted 7y ago

[deleted]

joshspankit 7y ago

In other words: When promiscuous touching, always make sure you’re not making things unsanitary.

vages 7y ago
I'm sure you can find a way to avoid promiscuous touching if you read the (gentle)man page.
dang 7y ago
Please don't do this here.

stephenr 7y ago

I had the same thought about `ln -sf` - removing and recreating the symlink aren't no-effect.

fpoling 7y ago
To avoid that I use readlink in my scripts to read the previous value of the link and call ln -s only when the value is not what is expected.

kousikk 7y ago

Last modified timestamps in source code are a bad idea and they make builds non-hermetic. Better to fix up those scenarios in code than work around them. Irrespective you have a good point that touch does have side effects.

rgoulter 7y ago
FWIW, I don't think "hermetic" is in widespread usage. My understanding is that "hermetic builds" refer to the kind of thing that tools like Guix, Nix, etc. go for. Something like "Declare all the inputs and dependencies to get a reproducible output".
- pmarreck 7y ago
  I prefer "deterministic" in this case (I think?)
  - rectangletangle 7y ago
    I've always heard "deterministic" or "reproducible," curious if the term "hermetic" is somehow different in this context.
    - gen220 7y ago
      Google’s release engineering docs describe hermetic build processes as those which are “insensitive to the libraries and other software installed on the build machine. Instead, builds depend on known versions of build tools, such as compilers, and dependencies, such as libraries. The build process is self-contained and must not rely on services that are external to the build environment.” Basically, if your build process requires you to pull code from any repository that you do not own, it isn’t hermetic. If you have to `pip install` or `go get` a third party (or even in-house!) dependency from a source that you do not control, your build is not hermetic. Effectively, this means that you have to have versioned copies of all of your third party dependencies, and version-specified build graphs. Very hard to do without a mono repo and a build tool. In the context of the GP, I’d say that deterministic would have been a better word choice. A reliance on time stamps technically wouldn’t make a build process non-hermetic, but it would definitely make it non deterministic. It’s technically possible to have hermetic builds without having reproducible builds, although that would be a very bizarre org. :)

dymk 7y ago

Within the scope of the article, which is about modifying the structure and logical contents of the filesystem (a-la `chef converge` - the author never once mentions FS metadata), it's idempotent.

farslan 7y ago

Op here. Yeah you’re right. I’ve mentioned it though in the context of file contents. Just updated to make it clear.

riazrizvi 7y ago

I've heard Idempotency confused with Consistency. Idempotency is where a function f can be applied (as a composition) multiple times and it gives the same result, so Idempotency: f(f(x)) = f(x). Whereas Consistency: f(x) = f(x) = f(x). An example of an idempotent function f is RaiseToThePowerZero(x) on x > 0. We usually take consistency for granted, so it's perhaps better to think of an example of a non-consistent function f which would be RandomNumberGenerator().

JoeAltmaier 7y ago
Better examples: Write("filename", position, data) is idempotent; Append(handle, data) is not.
- riazrizvi 7y ago
  Write("filename", position, data) inputs 3 arguments and outputs probably only 1, a file. So is not a function that you can convolute, you cannot pass the output of Write() as the input to another Write(). So instead, f: SetFirstWordOfFileToZeros(file)=>file, would be a better example if we want file functions. Then SetFirstWordOfFileToZeros(SetFirstWordOfFileToZeros(file))=SetFirstWordOfFileToZeros(file).
  - JoeAltmaier 7y ago
    Yes mathematically composability is part of it. That's because math functions return the same type. Its easy to express the 'state' of a function as the value of the operation. There's a wider idea of idempotency in computing - that state changes in general respond to operations. Repeating the same function more than once (because the network stuttered or the sender resent the message) and arriving at the same state is a common example.
mehrdadn 7y ago
> as a convolution Sorry, what does idempotency have to do with convolution?
- 7y ago

mehrdadn 7y ago

Just a note... even reading a file updates the access time, so if you reason this way then no program touching any files in the worktree will ever be idempotent... which seems to lose the utility of the concept.