how on earth does openssh not only have incredibly fucked versioning but is the only package i've ever seen to mention a "privilege separation" chroot path which actively breaks non-root builds. are you fucking kidding me bruh. "privilege separation chroot" defaulting to /var/empty and it immediately errors if it can't create it????? why are your version strings like that bruh?????
201
Replies
·
0
Boosts
@SRAZKVT all this line of thinking led me to believe, as you said above, that this is not a matter of checksums, but of data representation.
@SRAZKVT this is why i find the idea of something like radix bucketing or bloom filters so generative, because there is no unbounded monotonic negative incentive like collision reduction in a classical hash table (which is always improved by just allocating more memory = paying more money), but instead the ability to leverage anything you know that the compiler and libraries can't!
in particular, each bucket over a finite input domain corresponds to a relation (i.e. edge) across inputs (vertices). so, if you design your hash function not just to use the output bits to distinguish, but also to share features of the data to link together, you can use that to construct a graph.
@SRAZKVT that's fucked up. i don't even know what you can do with that. i just realized it
@SRAZKVT git lets you provide diff engines with a terrible config API, which i'm pretty sure is absolutely not used internally but just to display in certain user-facing commands. this is SUPER HILARIOUS because uhhhhhhhhhhh doesn't that mean the diff engine can just lie
@SRAZKVT you mentioned compression above--i believe compression of the canonical state is not what we're interested in per se but rather normalization
@hipsterelectron @SRAZKVT normalization brings to mind the oft-forgotten existence of smudge and clean filters which are arbitrary commands that you run to convert between the stored and working states of files.
@c0dec0dec0de @hipsterelectron what i dislike the most about clean smudge is they require you to put commands when a search and replace going both ways would be less error prone and easier, because pretty much nobody is going to use this for something other than a password or api key or similar
@SRAZKVT @c0dec0dec0de a search and replace is absolutely better than a process execution which linus knows damn well has nothing like the semantics required to make this even just "correct" (as in ensuring the stored state matches only when nothing has changed) let alone "not an obvious backdoor"
@SRAZKVT @c0dec0dec0de ok i think i figured out why i said (2) https://circumstances.run/@hipsterelectron/116968933719719946
(1) [i wasn't sure, but] i think tracking filesystem state can/should be done separately from defining a very domain-specific conception of "normalized" file state. because i think "normalized" state logic must be (a) repo-specific and tracked with the code (b) just hyper-specific to the needs of the maintainers, but i absolutely believe it makes sense for many techniques to be used by an OS making no application-specific assumptions.
(2) so that allows me then to feel comfortable about the "stored => working" transform, which is even more subjective than the repo-specific normalization logic, and as @c0dec0dec0de proposed, solves indentation.
@SRAZKVT @c0dec0dec0de (3) furthermore, that split in (1) from "files are byte strings and directory entry names are byte strings" [which more directly tracks filesystem state in an OS] to "files and directories are normalized" [which improves UX for state changes as a tool for expert craftsppl]--that's also where we would probably tack on stuff like networking, signatures, and mutable refs like branches.
i think push and pull are BAD and WRONG, and NEITHER merge NOR rebase make sense. when two users make parallel modifications from a shared basis, git refuses to represent that:
[local branch "bbb"]
A --> B [me]
\_> C [sarah]
[sarah branch "ccc"]
i don't "pull", but i might fetch:
[i snapshot locally]
bbb: [A -> B]
[i fetch sarah]
sarah!ccc: [A -> C]
this is actually a distinct problem with git, which is that "reflog" records HEAD and there's absolutely no fucking record of when each new object was added, and CERTAINLY no linear replayable log of modifications to named states. this is ALSO the problem with FUCKING PYPI!!!!!
@SRAZKVT @c0dec0dec0de this is what a state-based system would do for parallel modifications:
[on bbb, and i want to have sarah!ccc]
A --> B\_> [diff B<->C]
\_> C/ [no +/-, because no directionallity implied]
that's a terrible illustration. the point is that we don't "start from" A. i shouldn't even have written it, because we don't care about the merge-base, since we're not replaying every state. there's also no +/- or green and red or blue and yellow--the two states B and C must be merged (by me).
@SRAZKVT @c0dec0dec0de in fact, while modifications to different files being unrelated seems like a reasonable default, it is not in fact always or even often the case. if i modify the body of function f() and sarah has added a new call to f(), those changes are absolutely conflicting
@hipsterelectron @c0dec0dec0de no they aren't, unless something in the api of that function was modified
but yes merges can result in broken code, even if an automatic merge is succesful
@hipsterelectron @c0dec0dec0de but remember that these are context free merges, they do not know more than the content of the files, and they do not have any further information about the context in them (such as what kind of structure can be expected)
i believe that is an important property to hold, as otherwise you would be locked to the supported languages or tools, which is something i specifically do not want. a way of running ci on each commit to check it all still works should be sufficient to catch those errors
@SRAZKVT @c0dec0dec0de i was just thinking about the comment you made last weekend ish about automated API/ABI change detection. but that's not a property of the source files at all. your definition is exactly right
