thingification

I wonder if this is a CS problem somebody solved in 1954. Does somebody have the link to that paper?

(I'm not serious about 1954 in particular, I am about hoping somebody here knows the CS literature better than me)

I think my is-this-LLM alert is triggered not by mere use of phrases / constructions beloved of popular LLMs, but by things like unmotivated magpie-ish use of those phrases.

I didn't get that reading this (I didn't read the whole piece but I had read the parts you quote before reading your comment).

Often the LLM-beloved constructions are good usage in the right contexts.

I read Alien Clay and another book by him, which it turned out is basically the same book, which I found disappointing.

I think I've been waiting since the 90s hoping somebody will figure out how to make this a real thing (or was it the early 2000s?)

As I recall it seemed to be just one guy, David Chaum, who did so much to show how so many of these things could work, but the rest of us have somehow managed to do very little with his ideas. What are we missing?

But they'll block it entirely later right, once they've whittled down the objectors?

Seems we lack a nail-on-the-head term for this "but of course you'll still be able to ..." frog-boiling. We collectively fall for it every time!

If you can instead construct a list of existing instances to grandfather in, that doesn't suffer from this problem. Of course many linting tools do this via "ignore" code comments.

That feels less arbitrary than a magic number (because it is!) and I've seen it work.

To be more concrete:

In the source code - e.g. requirements.in (in the case of pip-tools or uv's clone of that: uv pip compile + uv pip sync), one lists the names of the projects one's application depends on, with a few version constraints explained with comments (`someproject <= 5.3 # right now spamalyzer doesn't seem to work with 5.4`).

In the compiled output - i.e. the lock files (pip-tools or uv pip sync/compile use requirements.txt for this) one makes sure every version is pinned to one specific version, to form a set of versions that work together. A tool (like uv pip compile) will generate the lock files from the source code, picking versions that are declared (in PyPI metadata) should work together.

My advice: pip-tools (pip-compile + pip-sync) does this very nicely - even better, uv's clone of pip-tools (uv pip compile + uv pip sync), which runs faster. Goes nicely with:

- pyproject.toml (project config / metadata)

- plain old setuptools (works fine, doesn't change: great)

- requirements.in: the source for pip-tools (that's all pip-tools does: great! uv has a faster clone)

- pyenv to install python versions for you (that's all it does: great! again uv has a faster clone)

- virtualenv to make separate sandboxed sets of installed python libraries (that's all it does: great! again uv has a faster clone)

- maybe a few tiny bash scripts, maybe a Makefile or similar just as a way to list out some canned commands

- actually write down the commands you run in your README

PS: the point of `uv pip sync` over `uv pip install -r requirements.txt` is that the former will uninstall packages that aren't explicitly listed in requirements.txt.

uv also has a poetry-like do-everything 'managed' everything-is-glued-together framework (OK you can see my bias). Personally I don't understand the benefits of that over its nice re-implementations of existing unix-y tools, except I guess for popularizing python lockfiles - but can't we just market the idea "lock your versions"? The idea is the good part!

That might be fine in your context. People's problems are real, though. What they're almost always missing is separating the source code from the compiled output ("lock files"). Pick a tool to help with that, commit both files to your ("one's") project, problem solved.

People end up committing either one or the other, not both, but:

- You need the source code, else your project is hard to update ("why did they pick these versions exactly?" - the answer is the source code).

- You need the compiled pinned versions in the lock file, else if dependencies are complicated or fast-moving or a project goes unmaintained, installing it becomes a huge mindless boring timesink (hello machine learning, all three counts).

Whenever I see people complaining about python dependencies, most of the time it seems just that somebody lacked this concept, or didn't know how to do it with python, or are put off by too many choices? That plus that ML projects are moving quickly and may have heavy "system" dependencies (CUDA).

> I think ['The Secret War' by Brian Johnson is] an earlier version of ['Most Secret War' by R V Jones]

Most Secret War is R V Jones' memoir of his personal involvement in radar, aerial navigation, aerial surveillance etc. in British military intelligence. I read it a long time ago but I don't remember it as a dry read at all - dramatic times after all.

Brian Johnson was involved in writing and producing the BBC documentary and a book. So it's not an earlier version of the same thing. The documentary is on youtube I think - a good watch, but I'd recommend reading Jones' original book.

For the benefit of anybody thinking "with gitlab I'm safe from this": If you're saying (and perhaps you're not) that some other git hosting service

- gives you control over gc-ing their hosted remote?

- does not to your knowledge have a third-party public reflog or an events API or brute-forceable short hashes?

if so, especially the second of those seems a fragile assumption, because this is "just" the way git works (I'm not saying the consequences aren't easy to mentally gloss over). Even if gitlab lacks those things curently (but I think for example it does support short hashes), it's easy to imagine them showing up somehow retroactively.

If you're just agreeing with the grandparent post that github's naming ("private") is misleading or that the fork feature encourages this mistake: agreed.

Curious to know if any git hosting service does support gc-ing under user control.

I found the post you're replying to helpful (and it made me laugh): I've come across the abbreviation POLA many times, with its non-jokey meaning "principle of least authority". I've also come across "principle of least astonishment" (Larry Wall or some other Perl contributor maybe?) but I'd never noticed that was (presumably?) a jokey reference to principle of least authority - I guess because I came across the joke first back was I was barely a programmer and I've never seen it abbreviated.

But maybe it never was a reference to POLA proper - "principle of least privilege" is more widespread I think, outside of the object capability community. And maybe "least astonishment" came first!

You're saying there's a github API that takes as an argument a secret, and creates a git commit containing that secret? I'm very surprised. Can you provide a reference to the API call?

It uses types to get quoting right? Or it quotes everything (regardless if it's already quoted)?

Ironically, the first time I saw the former was in a Python templating library (in the early 2000s -- from distant memory I think it might have been the work of the MemsExchange team?)

You use both terraform and ansible in the same project? I always thought of them as competitors filling more or less the same role, do you find it useful to use them together? Is it that hetzner and digitalocean TF providers do a good job but provide limited functionality, and ansible fills in the gaps for you?

People deploying low-traffic side projects - to VPSes or similar that allows price capping - and who do use a database: what deployment stack do you use these days?

I assume Docker + something is most popular, but what something? Does terraform work sanely for cheap virtual hosting? Ansible? I don't want to manually install any more stuff than the minimum I can get away with!