Just as comparison, micro alpine's package has 4MB (installed) while its staticly compiled binary version it downloads from github has 11MB. The repo's package would make it more micro.
Does it do this?
From https://github.com/zyedidia/micro#quick-install-script
Quick-install script
curl https://getmic.ro | bash
The script will place the micro binary in the current directory.
From there, you can move it to a directory on your path of your choosing
(e.g. `sudo mv micro /usr/bin`).
Such scripts remind me of DOS-era "installers", and they are awful:
- it is unknown whether your distribution is supported or not
- this script is probably not tested on many distributions and can break something
- it is unsafe, because you are running a code that some random person posted on the Internet without any sandboxing
There are many solution that try to fix that: appimage, flatpak, snap and what not. All of them of some degree of success, and pitfalls. I, for example, am happy user of flapak, running steam games on a alpine distro without much problems.
But for this specific thing I just don't get why there is a curl/bash command. It is a wide available piece of software that you can easily install using distro’s repo. Don't want to user terminal? Just download any "mainstream" distro and will have a store like software available, type micro, click install and done.
Is there fragmentation in linux? Yes. Is is hard to guarantee it will work on every distro? Yes, a lot worse on software you can't compile. But micro IS NOT the demonstration of it.
There is no reason whatsoever micro should have "curl | bash" on the front page.
Note that you must install micro to a directory accessible to all users when doing
this, typically /usr/bin. cd to that directory before running this script.
E.g.:
$ cd /usr/bin
$ curl https://getmic.ro/r | sudo sh
or
$ su - root -c "cd /usr/bin; wget -O- https://getmic.ro | GETMICRO_REGISTER=y sh" getmicro can use update-alternatives to register micro as a system text editor.
For example, this will allow `crontab -e` open the cron file with micro.
To enable this feature, define the GETMICRO_REGISTER variable or use the URL
`https://getmic.ro/r`.
Note that you must install micro to a directory accessible to all users when doing this...
Again, so?
Again, my point is: you should never ask the user to run sudo from curl (or actually, don't curl to bash at all). There are plenty ways to sploit that. Again, I know it needs root to move the bin to a root owned folder or update the default editor, but, again, you should never ask (or suggest) the user to pipe shit from the internet, it is security risk.
Also there is not even reason for it, micro is available in every distro.
It is completely irresponsible to encourage piping random Internet sources to sudo or to (ba)sh, and I'm quite tired of hearing the ridiculous justification that "everyone does it".
https://www.rust-lang.org/tools/install
https://deno.land/manual@v1.36.1/getting_started/installatio...
I'm not disagreeing with you, as a beginner, I'm just trying to learn.
And I'm using "OS" in a liberal sense, to also mean "different linux distros" and "BSDs".
---
One, you have to also think about what happens after installing. You have to consider upgrades, uninstalls, and also errors happening during those processes. With these scripts, if something goes wrong you're mostly on your own (though yes, you can go to the specific support channels for the specific software to fix the specific problem for your specific situation).
Your Deno link at least is versioned so it would be less bad to debug if something goes wrong, but that's only relatively speaking.
A package manager deals mostly with static archives, and keeps track of any file controlled by it. It is trivial to know whether a particular file belongs to a specific package or not. Upgrades can be centrally managed. Since it knows about what programs it has installed, it can print you a list of names and versions of everything so you can compare it against a list of CVEs or something.
Custom installation scripts are custom, and each has their own way to do these things.
---
Second, those instructions tell you to run a random script without even verifying its integrity first. No versioning for that script, no auditability trail, no signature to guarantee that the script is indeed the same as the script's author uploaded some moment in the past and has not been tampered with since.
A package manager deals (usually) with static archives whose signatures are verified before trying to do anything with them. An install operation is a simple, boring, "extract archive". Maybe with a small post-install script (that was part of the signed archive).
And the public keys used by the package managers are (usually) already in your local machine, so for most operations you are using an already-known public key to validate signatures.
(Note: Presence of a signature does not imply the software is trusted. It only means that the person that signed the thing had access to the private key.)
---
Third, though this sometimes causes problems (but I have never experienced them, or at least nothing comes to mind), the maintainer of your OS package repository usually knows your OS better than the upstream developer, and can apply patches to the packaged software that can be bug fixes, or even disabling/removing telemetry that the upstream software has enabled by default.
And with a package manager you know there's at least one other person (the maintainer of the package) that has used this program in this specific OS. There may be the case that some versions are just packaged without actual testing (just "git pull & run packaging scripts" or the equivalent), but in those cases there's the escape hatch of installing a previous, working version of the package.
---
With that said. If you were to ask me if there would be a situation where I would use those scripts, then _maybe_ (big maybe) it would be (1) inside a container where I don't care about any garbage left behind because I can nuke the whole thing at once; or (2) in an isolated environment where I don't even care if the script needs root privileges (this second case implies I would not do this in Docker).
the reality is that you run code you haven’t personally read and vetted everyday. so the idea that you need some stranger to bless a package for you to be trustworthy doesn’t make a whole lot of sense.
I want to get my applications directly from the application developer, because that way I can make sure that I'm using the officially supported version of the app and that no one has meddled with the code.
If I don't trust the application developer, I simply don't install the application.
No, they (the developers) can’t guarantee that, nor is their job.
You would trust them to develop a reliable software and you would trust the maintainer to guarantee the it will be properly compiled for specific OS version, has the proper permission set and has all dependencies it requires to run.
To ask the software developer to pack and make sure it works for all distribution would be huge amount of work that is beyond their knowledge (which it is not a issue). Also it seems one is not aware how to properly do it when they comes up with a not so bright ideas like the “curl | bash”.
It is not you don’t trust the developer, it is that there are people who know how to better distribute it.
obs.: this is in the context of micro and general FOSS that is easily available and distributable.