More Training, More Gaining: Everything You Need to Know About Training Volume by greg_nuckols
Behold: the most in-depth resource on training volume anywhere on the internet. The most big-picture summary of the article is that higher training volumes tend to facilitate more muscle growth and larger strength gains. But, it also explores many rabbit holes: muscle swelling, sarcoplasmic hypertrophy, bioenergetic constraints, epistemology, volume cycling, formal logic, shitposting with a purpose, and so much more.
keywords: forgejo docker dokploy ssh
i'm running my own forgejo instance via dokploy (i.e. in a docker container). as i'm currently the only user and scale/performance isn't a problem, i opted for sqlite, so i didn't even have to set up a postgresql instance (which would have been trivial in dokploy anyway).
there was just one hickup: private repositories were not accessible via ssh. this is necessary for authenticating from dokploy if the goal is to redeploy on push:
after a short while i found the reason: git with ssh inside of docker needs either its own ssh server with a custom port or ssh-passthrough configured see the docs.
the custom port solution was recommended, but i opted for the "clean" ssh-passthrough route and subsequently lost several hours of my spare time (special thanks to gemini and claude, without i'd never had made it even that far).
the steps outlined in the gitea documentation (forgejo is a fork of gitea) are a bit simplistic; in my case several more steps were necessary.
gitssh-shell bash script in gits home directory. the contents is, roughly #!/bin/bash
exec /usr/bin/docker exec -i -u git \
--env SSH_ORIGINAL_COMMAND="$SSH_ORIGINAL_COMMAND" \
forgejo /usr/local/bin/gitea --config=/data/gitea/conf/app.ini serv key-7
git user to the ssh-shell scriptauthorized_keys (this is the icky part)testing all this required a lot of use of ssh -vT git@<your_forgejo_domain> until all parts aligned. the welcome message should then display Hi yourusername! You've successfully authenticated, but Forgejo does not provide shell access..
now it worked, but only for my ssh key. if i added a second user to my forgejo instance i would have had to add their key to the authorized_keys file manually.
the problem here is the ssh authentication via authorized_keys - the entry with the public key must be present in the host and the forgejo containers authorized_keys file. this has to be solved through forgejo's key management. if the user adds an ssh key through the web interface, the application should write this into the containers authorized_keys file and the hosts git user should use the containers authorized_keys file instead of its own.
this is where i ran into the final problem that made me undo all progress and switch to the ports solution. the proper configuration would, in theory, be:
Host SSH config (/etc/ssh/sshd_config):
Match User git
AuthorizedKeysCommand /usr/local/bin/forgejo-keys %u %k
AuthorizedKeysCommandUser git
Key lookup script (/usr/local/bin/forgejo-keys):
#!/bin/bash
# This script fetches keys directly from Forgejo
docker exec -u git forgejo /usr/local/bin/gitea --config=/data/gitea/conf/app.ini admin user list-keys "$1" 2>/dev/null || true
the problem here is that the gitea executable doesn't have a admin user list-leys command. going through the documentation now it seems the command was changed to
AuthorizedKeysCommand /path/to/gitea keys -e git -u %u -t %t -k %k
for now i'm keeping the custom ssh server, though.
closing some tabs but saving them here
Bad Actors are Grooming LLMs to Produce Falsehoods GenAI powered chatbots’ lack of reasoning can directly contribute to the nefarious effects of LLM grooming: the mass-production and duplication of false narratives online with the intent of manipulating LLM outputs. As we will see, a form of simple reasoning that might in principle throttle such dirty tricks is AWOL. Here’s an example of grooming. In February 2025, ASP’s original report on LLM grooming described the apparent attempts of the Pravda network–a centralized collection of websites that spread pro-Russia disinformation–to taint generative models with millions of bogus articles published yearly.
it's indirect grooming: the propaganda articles also exist on their own and some people might also read them on their own, without LLM filtering. are people who are susceptible to LLM misinformation (i.e. take LLM output uncitically at face value) are also those who have always been susceptible to misinformation through traditional misinformation channels?
people are often unable to identify satire, and they're often not even to blame, because some self-labelled satire websites are just creating fabrications1 that are not satire in the classical sense, then labelling it satire in fine print on the hidden about page.
what are the solutions? train independent models to recognize misinformation, propaganda and satire and implement those as pre-training or pre-output filters?
usually not very funny, but that depends on your sense of humor i guess.
↩song of the day: Being Square - Donkey Kid - it's an absolute banger and i can't get it out of my head
i've been playing around with koog over the weekend and honestly, i'm struggling. the documentation and examples left me with a lot of questions and many hours of trial and error, though maybe that's just because i'm new to the field.
the biggest problem was grasping the difference between session/state, history and memory. koog is a kind of framework/DSL, and the graph workflow is quite confusing. currently execution often ends without feedback and i really don't know why.
TBC