upvote
Totally agree, it's the main reason I'll never recommend Linux to anyone, because you can't expect normal people to understand these things.

But it's kinda funny to me that you just said "I was going to run this code on my system, until I saw some other code in the same repo, and now I refuse to run it" :D It's all the same repo, you're willing to try part of the code, but not another part of it. Completely arbitrary.

reply
If I want to try something like this out it's for fun more than anything, and I'm not really willing to invest much time trying to understand where to put the files etc.
reply
The install method is for Windows, Linux and MacOS. Having those install methods is a choice on all three.
reply
Not sure that installer.exe is much better in that regard.
reply
> I was tempted to try it until I saw the curl | bash pipe, then no

I don't quite get that argument. It's the same as the old download installer from random website, double click to run that people have been doing for decades. It only skips the download step. And it's arguably better since at least you can review the contents. When building a Go program it will also happily download stuff from github but I've seen way less complaints about that. And to be fair it's also been an infection vector, from people installing things from shady places (or reputable places but with ill-intent like installing unwanted browser toolbars, DRM rootkits ...), but it's nothing new. Same advice applies, know what you're doing, use reputable sources.

What's a better alternative ?

reply
My big problem with it is uninstallation. If I ever want to remove the program, I have to 1. Hope that the author published an uninstall.sh, or 2. examine the install.sh to see where it spams all its files to and remove them manually. This seems like a major step backwards from package managers.
reply
You're blind-trusting someone to run stuff in the context of your terminal. Sure, it's similar to an installer but the author of the script can also manipulate the script at any time.

One day you run it, it's fine. The next day you run the same command on your machine, it installs malware. No way to tell without inspecting the script every time.

If you download an installer and it's fine, then you can run it again and it's still fine.

reply
I don't think the go module system is great but I am not sure if any programming gets it right and all suffer from many issues, but go has the go.mod and it is easy to see what dependencies are being used both direct and indirect and the user can filter and look though these packages and pin them until they have eyeballed updates to the git repo. I don't feel the most comfortable with it but the whole `curl | sh` is so terrible, no signing no, way of knowing about the integrity of the installer.

> What's a better alternative ?

I do not think the program really needs and installer but if one must then why not just have it under source control that way you get the benefits of git handling all the download bits and the install script being completely offline and just using cp or install commands.

you could tell the user to do this with a pithy command like `git --depth=1 clone $GITSITE/$REPO && $REPO/installer.sh && rm -R $REPO`

reply
I cloned the repository just for the sound files. I may hook them to my terminal for long running jobs when I have some time to have some fun. Maybe a wrapper script.

Hmm, why not?

reply
I also had this thought. So I cloned the repo and got Claude to review it. Then I installed it from the clone.
reply
What did Claude find?
reply
It said other than some GETs for self-updating it didn't do any networks accesses.
reply