11–20 of 36 posts
The title should be: “I don’t like Mtime comparison. Here’s why.” If your name is Dijkstra and it’s 1968 feel free to use the phrase “considered harmful”, otherwise use plain language.
Anti-considered-harmful consided harmful. What's wrong with the usage? It is short and concise.
The title should be: “I don’t like Mtime comparison. Here’s why.” If your name is Dijkstra and it’s 1968 feel free to use the phrase “considered harmful”, otherwise use plain language.
Anti-considered-harmful consided harmful. What's wrong with the usage? It is short and concise.
It's such a ridiculously inflationary overused meme to the point that it's getting annoying.
There are other contenders: https://news.ycombinator.com/item?id=31836787
(In hindsight, I completely forgot "X shades of Y" in this list)
Weird that there is such detailed technical information alongside this statement: > And anyway, purists might argue that the "content" of a directory doesn't change when the files it points to change; the content is merely a list of filenames and inode numbers, after all, and those stay the same, no matter what happens inside those inodes. Purists make me sad. Or maybe Unix makes the author sad? You can’t wish the OS…
The title should be: “I don’t like Mtime comparison. Here’s why.” If your name is Dijkstra and it’s 1968 feel free to use the phrase “considered harmful”, otherwise use plain language.
The original title of the letter, as submitted to CACM, was "A Case Against the Goto Statement", but CACM editor Niklaus Wirth changed the title to "Goto Statement Considered Harmful". Regarding this new title, Donald Knuth quipped that "Dr. Goto cheerfully complained that he was always being eliminated."
Reading that same link, Wirth didn’t invent the cliché, either.
The title should be: “I don’t like Mtime comparison. Here’s why.” If your name is Dijkstra and it’s 1968 feel free to use the phrase “considered harmful”, otherwise use plain language.
The phrase "GOTO considered harmful" was actually used by Niklaus Wirth, not Edsger Dijkstra. Dijkstra had submitted his letter with the title "A Case Against the Goto Statement"; and Wirth, as editor, changed it.
But also, it was already a journalistic cliché outside of computer science before Wirth applied it to Dijkstra's letter.
Since all builds have an mtime of 0 as timestamps are the biggest source of reproducibility issues [2], QML loads outdated cache objects which will then load invalid bytecode at runtime and therefore causing a crash.
Our initial plan was to utilize a hash of the binary [3] which should be IMHO the most straightforward, unlikely to break and future-proof way to solve the problem. The currently suggested implementation's performance could most likely be improved by generating the hash once on startup instead of every time when a QML resource is loaded, but I believe since it's already cached in memory, hashing is not that expensive, binary sizes are usually relatively small and resource loading (of embedded ones) doesn't happen that often, it should be already reasonably fast (real performance test haven't been done yet).
The big challenge will be upstreaming it, once we've proven it to properly work. The current approach has been apparently rejected [4] and was declared to be a downstream issue, which I personally don't agree with, since sooner or later reproducible builds will become the norm and therefore will affect everyone. Current ideas to work around it require individual solutions per distribution/ISV, as this would mean they'd have to come up with domain specific criteria for cache invalidation (as the store path/derivation hash on NixOS) and to maintain a downstream patch for this solution and furthermore wouldn't work for local build processes (e.g. from within an IDE).
Lesson of the day: never use mtimes, they'll bite you in the ass sooner or later!
[1] https://github.com/NixOS/nixpkgs/issues/177720
[2] https://reproducible-builds.org/docs/timestamps/
[3] https://github.com/qt/qtdeclarative/commit/5106afcd76e377a6b...
[4] https://github.com/NixOS/nixpkgs/issues/177720#issuecomment-...
So we might have a reliable mtime alternative in Linux soon in 2022.
I really do think it's unfortunate that the OS cannot keep something like a "write count" for each file. That would be enough. Possibly it would even be good enough to know the number of times a file had been opened for writing.
Weird that there is such detailed technical information alongside this statement: > And anyway, purists might argue that the "content" of a directory doesn't change when the files it points to change; the content is merely a list of filenames and inode numbers, after all, and those stay the same, no matter what happens inside those inodes. Purists make me sad. Or maybe Unix makes the author sad? You can’t wish the OS…
He lost me here. As much as that's a would be cool kinda feature it smacks of a special kind of tunnel vision: what's the point of anything but what you happened to be working on?
Consider how many writes happen on your system. Consider what sliver of a fraction of them even come under mtime scrutiny. The idea is to amplify those writes all the way up the directory hierarchy? For every write? And contend on ever write to /home/?
We already needed a noatime, if it wasn't for make I could imagine a nomtime too.