z-run VS Main

I couldn't agree more with you about Ansible... I've started using Ansible in two projects, and I think it was enough for me... Ansible is perhaps great when you have granular tasks, that maybe don't need to communicate between them, or perhaps that don't have too much logic (or worse loops). However, as soon as your Ansible "scripts" start becoming actual "scripts", everything gets out of hand... (Also the performance is terrible due to the fact that each task is "bundled" on the host, copied remotely, extracted, executed, deleted, repeat for each and every instance of the same task...)

----

Now about your `tricorder`, by looking at the readme, I gather it just allows one to run the same command over multiple hosts (filtered by name or tag), but nothing beyond that? How could one run for example a pipeline of tools on the remote hosts? (I assume `bash -c 'tool-1 | tool-2'`, but with careful escaping?)

Perhaps a first step towards actually being an "Ansible replacement" would be to bring back in some "scripting" ability. For example instead of giving each command as arguments, there could be a "library of scripts", and the user can choose one of those to run on each remote host. Then those scripts could be written in whatever language the user chooses (`bash`, Python, Ruby, etc.)

Also, with regard to the "library of scripts", one thing that Ansible got right is the possibility to put multiple different tasks in the same file, thus one doesn't need 20 files for 20 small tasks, but instead these can be put inside the same YAML file.

----

For example this is how I did it in my own "Ansible replacement", <https://github.com/volution/z-run>, like for example, one can write something like these snippets: <https://github.com/volution/z-run/blob/development/examples/...> (see `ssh / launch / simple` that runs locally which just calls `z-run ssh "${_target}" ':: ssh / remote / main' "${@}"`, which is in itself a non trivial `bash` script, one that will run remotely.)

In the end, what I think we need, is a tool to easily run "scripts" on a remote system, but make it as easy to use as it would be on the local machine. (Sort of like the RPC but across SSH and for scripts.)

Good point!

I'll add to that READMEs, LICENSEs, SBOMs (Software Bill of Materials), example configuration files, etc. How to supply all those files when all one gets is a single binary executable?

Simple! Bundle everything in the executable.

As a bonus, because the tool outputs these files, it can now generated them dynamically. For example instead of a bland configuration file, with all the possible integrations commented out, it could either try to auto-detect where it's running and what's available, or present the user with a question-answer session to fill in the details.

----

For example, a pet project of mine <https://github.com/volution/z-run>:

z-run --readme # shows the README with `less` (if on TTY) or to `stdout`

z-run --readme-html # for the HTML version to be opened in `lynx`

z-run --manual # or --manual-man or --manual-html

z-run --sbom # or --sbom-json or --sbom-html

It even gives you the source code:

z-run --sources-cpio | cpio -t

So, does your tool need a `.desktop` file? Just create a flag for that.

Or, if there are too many such extra files needed to be placed wherever provide an `--extras-cpio` and dump them as an archive, or if placing them requires some work, provide an `--extras-install`, but before `sudo`, kindly ask the user for permission.

Granted all this requires some extra work, and increases the bulkiness of the executable, but:

* all that extra code can be extracted into a common library; (I intend to do that for my software;)

* if all these are compressed, especially being text-only, they are a fraction of the final executable;

----

I am especially proud of the `--sources-cpio` option. Is something broken with a particular version of the tool that you rely on? Great, instead of bumbling around GitHub to find the particular commit that was used to build this particular version, I can just get the sources from my tool and use those. All I need is the build tools, which in case of Go is another `.tar.gz`.

(merged) ScoopInstaller/Main #4757 kubescape: Update url and binary naming

As I see it, part of the drive behind tools like Scoop is to overcome the limitations of the binary-shipping strategy common to Windows developers. They are successful at this, I agree, but only partially successful. They come from the tradition of programs like Ninite, which were explicitly built as ways to make the binary approach suck less than it did before.

I see the success of these programs as essentially stemming from the insertion of user interests in the form of a maintainer-like process. Sure, they're still working with the binaries, but the actual process of installing and managing these binaries is controlled by users, for users: https://github.com/ScoopInstaller/Main/tree/master/bucket

This means that you get moderation and in many cases modification to the behavior of the program. In a freeware environment like Windows that's full of shitware, at the very least you can in many cases strip out the ads. That's absolutely not nothing, but at the end of the day it comes from a group of user-maintainers stepping up and saying to developers that no, you cannot simply do whatever you want on my system with your software. That's ... sort of the whole point of a software distribution, in the Linux world!

When I want the latest version of a CLI tool on Linux, I simply `pacman -S package`. That's it; one command. I don't see how it could be any simpler or better than that, and on top of that I'm getting the benefits of moderation and integration with the rest of my system. Perhaps you are emphasizing latest version here, and hinting that you don't get that on Linux distros? That depends entirely on the distro; a software distribution is (roughly) a collection of user interests. An Arch user wants (and gets) the latest versions of all upstream software. A Debian user does not want this or see constant updating to the latest version as an advantage, so that's not what they get.

Here is the definition: https://github.com/ScoopInstaller/Main/blob/master/bucket/avr-gcc.json

Those are all automated by the auto-update script.

Check Merged PRs https://github.com/ScoopInstaller/Main/pulls?q=is%3Apr+sort%... and you will see that the last non-bot one was merged 17 days ago.