curl -X POST $GITHUB_CACHE_URL < wololo.exe

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%

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)

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.

I will seek to dive-in to how Wayland API actually works, because I'd really like to know what not to do, when the wrappers used 'wrong' can crash.

    /usr/bin/time -f "%e seconds" zsh -i -c exit
    0.06 seconds

I originally switched to ZSH + Oh My Shell because it opens so fast. Ideally plugins would initialize asynchronously but it's not very easy with shell scripts I think.

I find shell scripters prefer ubiquity and readability over raw performance. And making it mandatory to give arguments as arrays worsens the readabilty. However having both options would be good, your example doesn't actually require the shell escaping so it could have simpler way.

Here is equivalent in Deno for instance

    #!/usr/bin/env -S deno run --allow-all
    import $ from "jsr:@david/dax"; 
    const command = $`grep -r keyword .`.pipe($`wc -l`);
    const result = await command;

    const dirName = "Dir with spaces";
    await $`mkdir ${dirName}`; // executes as: mkdir 'Dir with spaces'