Logging off from here, every time I open the app I see nothing but a dystopian nightmare. Why do I care if AI is doing X or Y now?
I'm gonna go enjoy my last weeks before being forced to use AI to code, code like it's 1990s. Me and my vim against the world :)
it's crazy how the AI advancements revealed how much we resent each other. im not good at math or drawing but i never resented the math people or the artists for their ability to do that stuff
In Unix you can just "unlink" the file while you have an open handle to it, and it'll be physically deleted once you close it. Gives you similar behavior.
But this comes with an issue: race condition!
In the window between your open, unlink another process may move the file or even delete and create a new one in its place.
Unfortunately, there is no funlink, since unlink works over dents (directory entries) while an open fd holds an inode (the actual data) and the same inode can be pointed to from multiple dents (links)
To make it a little more robust you have to do this dance:
1. Use a loop of statat+readlink (O_NOFOLLOW, O_DIRECTORY) to resolve the parent directory in user space (basically follow the symlinks) [1]
2. use openat with the now resolved parent dir fd and dent name (again O_NOFOLLOW)
3. unlinkat(dfd, name, O_NOFOLLOW)
---
And even after all of this... you can still have the ABA race between step 2-3, but now the window of opportunity is smaller.... and so is the attack surface (ie an unprivileged process can no longer swap the file under you to make it a symlink to some sensitive file that only your process's user has permission to delete and have your unlink do the removal it otherwise couldn't)
Anyway, I'm realizing this became a long response... but worth mentioning: if you are creating the file to begin with O_TMPFILE is something to consider!
VFS is a nightmare and Linux needs an unlinkat which can accept a dent_ino parameter and have it only perform the unlink if it still matches the given inode to prevent this issue
[1]: a correct "linux faithful" implementation of this step alone (that produces the same errors as a single open() would with long path, deep link chains, infinite loop handling etc) is a 400-500 lines of code soaked in pain which I've written before.
The code comments here are pretty informative about the actual cache line size per architecture with a good amount of citations.
https://t.co/DUX89OW2LA
Most code assumes cache lines are 64 bytes. but thatโs a bad assumption on hardware with wider lines.
C++ gives you std::hardware_destructive_interference_size specifically to avoid false sharing without hardcoding a cache line width.
@zemotion Patent question. Could you create a proprietary image file format, patent the decoder and then if someone steals these raw files and tries to convert them to other image formats, you could go after them for infringing that patent?
IMHO that's attacking the issue at the wrong layer,
- If you have zfs just use `zfs set dedup=on` to enable block level deduplication [1]
- If you have some space to spare for a block device, you can use Linux's lvmvdo (works for any file system sitting on top, friendlier towards block-aligned ones)
These solve the content deduplication problem (actual storage space waste, across *all* of your projects!)
Then for build speed, use sccache. However, sccache does not yet natively try to use clone_file, which is sub-optimal as it tries to do a hard copy of the content... you can speed that up by changing sccache (see issue #1053)
[1]: btrfs has a similar concept, but not personally a user.
@shayonj This is true in the theoretical sense, but in practice we have made systems that are orders of magnitude slower than what's possible due to historical baggage. So my reaction to seeing something much faster is usually: nice! what stupid historical mistake did you undo?
@malik672_ Just being more intentional with my time, I'm using "StayFocused" chrome extension. I was spending too much time "talking" with AI... so had to stop myself from doing that.
I'm gonna do this too! This will be unsealed in exactly 1 year.
sha512:6dcf1861ccf14d8ca2e4c9d3907e62604a1d9cb0d1131168de9b733fc1ba3ee4639c386e9fd9dd197b24e895ad9b7edb8d30ed1ab4d2ba06f1defe6ff223ca04