1,510 karma · joined March 11, 2015
OpenRouter allows to make an API key locked to certain provider, I do that myself.
There is another alternative too, releasing interface only packages, then hoping everyone agrees to use those. JavaScript/TypeScript people actually did this already for one very tricky one, validation, see Standard Schema [1], which was great success. But I would hope to see more, for instance interfaces around typical building blocks like job queues, email sending etc.
I (now) know why I don't like that, because regular book and magazines, you don't have to think about how you hold it. Your thumb isn't going to magically flick a page by accident if you take a firm grip on it. With gestures only e-ink books, I have to take extra caution how I hold it so that it doesn't trigger something.
Instead of obj?.:method?.(…) it would be like obj#:method#(…)
Replace # with your favorite extra character instead of questionmark.
They made that intentionally at the beginning:
> Currently there is consensus that Node.js should NOT run TypeScript files inside `node_modules. It is not supported to avoid package maintainers to release TS only package.
curl -X POST $GITHUB_CACHE_URL < wololo.exe
It would make me pause, but now that it is a misfeature in YAML configuration it is more widely used. Point of bash scripts they are auditable, and understandable.I didn't prescribe what the bash script would be, because it would differ on use case. If I wanted to share artifacts from other runs I would probably use podman and make sure I start new runs from known good condition, but because I understand that. Some other would use nix or whatever else.
> Cache scope is per-repo, shared across pull_request_target runs (which use the base repo's cache scope) and pushes to main. A PR running in the base repo's cache scope can poison entries that production workflows on main will later restore.
This is very difficult to understand, and teach to new people, because everything is configured as YAML, yet everything is layed out in the background to directories and files.
What if your CI pipeline was old-school bash script instead? This would be far more obvious to greater amount of people how it works, and what is left behind by other runs. We know how directories and files work in bash scripts.
Could we go back to basics and manage pipelines as scripts and maybe even run small server?
Pretty impressive that it is faster than the Go version already.
It is so annoying that each agent has its own ideas where it tries to get the docs, usually by blindly grepping.
What would be disadvanatages of this approach? I don't like Arc's myself either, I would like to see what is best alternative for those in multi threaded apps.
set filepath="C:\some path\having spaces.txt"
for /F "delims=" %%i in (%filepath%) do set dirname="%%~dpi"
for /F "delims=" %%i in (%filepath%) do set filename="%%~nxi"
for /F "delims=" %%i in (%filepath%) do set basename="%%~ni"
echo %dirname%
echo %filename%
echo %basename%
It is just as intuitive as one would expect.Most of the supply chain vulnerabilities that ended up in the NPM would have been mitigated with having mandatory testing / stable branches, of course there needs to be some sort of way to skip the testing but that would be rather rare and cumbersome and audited, like it is in Linux distributions too.
Have a branch called testing, and packages stay in testing for few weeks, after which they go to stable. That is how many Linux distributions handle packages. It would have prevented many of these.
Advising every user of npm/pnpm to change their settings and set their own cooldown periods is not a real choice.
It works pretty well, agent which I choose to run can only write and see the current working directory (and subdirectories) as well as those pnpm/npm etc software development files. It cannot access other than the mounted directories in my home directory.
Now some evil command could in theory write to those shared ~/.npm-global directories some commands, that I then inadvertently run without the container but that is pretty unlikely.
In Wayland you have multiple ways to render windows, not just the XDG top level window. It works via surfaces, and here is a list I've discovered so far:
- XDG Top Level Window
- Child Window
- Popup Surface
- Layer surface (like task-bars, shell overlays)
- Subsurface (region in another surface)
- IME Panel Surface (surface that follows text cursor)
There probably is others too.It is diffifcult to find high-level toolkits that support all of the above.
Since running destroy and deploy also takes a long time, gets stuck, throws weird errors etc, one still needs to read the docs for many things and understand the constructs it outputs.