101–110 of 111 posts
I post this every time this topic comes up. Piping from the internet into your shell is a bad idea. https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...
I used to think that. But is it really that much worse than `pip install` random stuff? Or Homebrew, or Linux package managers - it's not like these things get audited.
Earlier quoted context omitted.
> devs either properly package their apps, or don't release them at all. There's still no widely accepted answer for what 'properly package their apps' looks like. You could want snaps or appimages or a flatpak, or rpms or debs or docker containers or nix flakes or cargo crates or python virtual environments or jars or javawebstarts or portable windows executables or windows msis or webasm packages or web pages ... t…
>There's still no widely accepted answer for what 'properly package their apps' looks like. You could want snaps or appimages or a flatpak, or rpms or debs or docker containers or nix flakes or cargo crates or python virtual environments or jars or javawebstarts or portable windows executables or windows msis or webasm packages or web pages ... Any single one of them is better than curl|sh. Just pick one. Even shippi…
What do you mean by platform? If you only ship a .deb, there are going to be a lot of linux and unix users who simply can't use your stuff.
I've seen quite a few tools use curl to bash to work in macOS, windows and multiple flavours of unix. There aren't a huge number of other approaches that can allow that.
Earlier quoted context omitted.
I used to think that. But is it really that much worse than `pip install` random stuff? Or Homebrew, or Linux package managers - it's not like these things get audited.
You didn't read the article, I'm 99% sure.
> I would have just expected it to install it in the proper location (hopefully not in my home directory) and leave the rest of the configuration to me While I don't advocate for piping curl to bash, this is exactly what I expect an installer to do. It should provide sane defaults that don't require me to fiddle around with manpages or other documentation and config files before I can even use the thing. I'd say that…
>I think what's missing is some standardization around what an installer is allowed to do and flags to tell it when to make certain changes as well as explicit logging for what exactly was changed or added where, but that's not going to be solved if everybody has their own bespoke bash script for installation. YOU ARE RIGHT! What's more, we can make common installer code so everyone could just use same rules and docu…
I post this every time this topic comes up. Piping from the internet into your shell is a bad idea. https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...
Earlier quoted context omitted.
Windows uninstall isn't guaranteed* to be perfect but it's much better in this regard. It's common on Windows to have uninstaller apps that go around cleaning up the crumbs of the application. The equivalent on macOS isn't unheardof but it's rare.
I assure you that the vast majority of Windows software leaves config files and registry entries behind when uninstalled.
piping curl to bash is a heresy, an abomination that cannot be tolerated. it is an affront to my intellect and sensibility. it is an ethical turpitude and degeneracy that cannot be understated in its depravity. It reduces the user to nothing more than an endured, pseudotrutworthy ball of lard in the developers formal equation of installation. As it is an installation however it beseeches the administrator, the root,…
Doing something called "piping curl to bash" is not a good idea. It's like trying to do something on someone else's computer without asking permission first. It puts you in the place of being in charge, even though it isn't your computer. Doing this can cause trouble and make the person who owns the computer very unhappy with you.
> OK, now explain the above in verses of King James English.
Behold, the ground thy code doth touch,
Is holy and hallowed much.
The rites of Posix and decree,
Beseech thee not to speak unless spoken free.
Alone thou approachest the throne divine,
Unless in favor of God's law thine.
To wield the sudo sword alone is sin most dire,
And damnable contempt before heaven's fire.
Forsooth 'tis treason unspeakable this day!
curl|/bin/bash shalt thou never say!Earlier quoted context omitted.
Also true of literally every OS, on the inherited wisdom that separating the config from the actual application allows it to persist through upgrades and reinstalls easily. There are certainly other ways to do that, but this is how it has been done since forever.
Windows uninstall isn't guaranteed* to be perfect but it's much better in this regard. It's common on Windows to have uninstaller apps that go around cleaning up the crumbs of the application. The equivalent on macOS isn't unheardof but it's rare.
In my experience what is common will be the inverse of that. And leaving config files spread throughout the system is one thing. Sometimes the uninstaller doesn't even remove the Program Files directory leaving it behind with cache, tmp files, etc. (Things that shouldn't even be there in first place but anyway.)
Earlier quoted context omitted.
XDG is a specification of Free Desktop, a body that I don't trust. Standardizing filesystem locations can't be a bad thing; but an awful lot of it is tied into the requirements of GNOME Desktop, a project which seems to be trying to rule the world, and which I don't want to help with. Perhaps if XDG were cut loose from the Free Desktop project, more developers and maintainers would pay more attention to it.
That's one reason. Another reason is that while some effort was spent on writing this spec, apparently (?) almost no effort was spent on promoting/enforcing it: there is another top-level comment in this thread from a 10-year Linux application developer that says they've learned about XDG from this very post. And indeed, there are lots of tremendously popular apps out there (Slack, for instance) that use e.g. $HOME/D…
Earlier quoted context omitted.
That's one reason. Another reason is that while some effort was spent on writing this spec, apparently (?) almost no effort was spent on promoting/enforcing it: there is another top-level comment in this thread from a 10-year Linux application developer that says they've learned about XDG from this very post. And indeed, there are lots of tremendously popular apps out there (Slack, for instance) that use e.g. $HOME/D…
Because '$HOME/Downloads' is the default for `xdg-user-dir DOWNLOAD` and most users never change it.