245 karma · joined January 26, 2019
Everyone in heaven is an Accelerationist these days. I like to think Sam gave up his crusade and went sailing with Jan and Renfrew.
Starlink has always been primarily a high gain 4G/5G antenna.
Unfortunately most of the work of GitHub actions is configuring the runners and setup data, which requires you to use lots of yaml to invoke unvetted public repositories (actions) written in JavaScript to do what is easier done as shell scripts, and then use shell scripts to workaround the limitations of actions.
State is impossible, data is even more impossible, and caching is completely broken. And if you use your own runners, GitHub actions don’t even clean up their own garbage. I suspect it’s the same on public runners, but just statistically less likely to affect you, but a potential security vulnerability.
I’ve been working 2 things:
1. A front end that crafts GHA workflow yamls from a sane configuration with common tasks baked in.
2. An event and reporting system so you can see what is happening during a workflow — not after — without having to scroll through GitHub’s hideous log output in html or download and unzip the full log.
Take GitHub Actions, for example.
There is no need to distinguish between functions, modules classes, lambdas, or whatever.
Hence, no need to distinguish their start or ending with keywords, as long as you can determine their scope.
Brackets determine scope, and unlike indentation or words, that is all they are used for.
Every client has to have duplicate modules for every territory that they operate in and if they begin to operate in another territory, that has to be copied in — or they have to keep a copy of all territory modules for every client. I think it is probably the former, since they talk about pruning and ignored imports.
It had been more than 20 years since Carmack pulled an all nighter working on Doom, and he’s been coasting along ever since.