51–60 of 111 posts
Earlier quoted context omitted.
> a reliable way to uninstall the program, without leaving any mess behind cc: Anyone working on macOS
Uninstalling macOS apps is usually as simple as removing the app bundle.
Earlier quoted context omitted.
> "we the users" could mandate Yuck. As I said: > Instead, it is always someone else's problem. "I am the customer mentality" has been with FOSS and Linux for awhile, but one wishes people might shake themselves out of their stupor for 2 seconds to realize: "You're getting all this stuff for free." Instead, every user wants to man the battlements on Reddit and tell devs how to do the thing. Re: the parent, she/he sho…
Yet somehow as a developer I have no problem at all realising that it is user-hostile to take liberties with their system. It's violating trust and I have no need to do it in order to provide, even to install, a piece of software.
`curl | bash` is pretty upfront about what it is. It would seem the user is the one taking liberties, but perhaps I'm missing your point?
Earlier quoted context omitted.
> but that actually asks your users for even more control of their systems Or you can support one of the limited-capability package ecosystems, like Flatpak or Snap or AppImage. Then it's sort of like installing an app on your Android phone: the installed app (and its updates) only get to interact with the system through a customized sandbox that must first be described to, and accepted by, the user.
Sure, but there is plenty of software for which that doesn't make any sense, since the whole point is to interact with your system. ohmyzsh is a good example, as are most SDKs, as is plenty of specialty software.
Essentially, an SDK in this sense would be a sandboxed plugin for a non-sandboxed system-level meta-SDK manager, that knows how to use these SDKs (in their sandboxes!) to compile and/or test-run things; where a test-run gets granted capabilities that the SDK-as-compiler does not itself possess, per a capabilities manifest fed in with the meta-SDK development project.
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 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.
APT is part of the core Debian distro. I don't know about "audited", but it's tested, and it's maintained. And the packages in "main" are also tested.
I don't program in Python, and I don't know how Pip packages are audited. An awful lot of the packages in Debian main are Python and Ruby libraries, and I suspect that they are rarely used: I assume most Python and Ruby users rely on their own language-specific package manager.
I also regret the arrival of distro-agnostic package managers like Flatpak. But that's fine; I understand why developers use them, and I'm not going to rag on them for that decision. I'm just much less likely to install them.
You do not take liberties with someone else's system, there is no need to do it and no excuse for it. You can have a reference example "make install" in your build system that serves as a reference for the packagers without you having to worry about all the 80 different distros. And it better also have a "make uninstall".
Respecting the possibility that a config file or even the bins and libs might already exist as part of the "make install", are just part of the job like writing the software itself, not some unreasonable extra burden.
If you're that much of a baby then I do not want your 'free' gift software and nor should anyone else. What other corners are you cutting everywhere else in the software? What other gross lack of integrity do you think is ok?
Maybe this is more the result of turning every random application into it's own cpntainer. It's fine to have an app installer configure the entire system to suit itself when the entire system is just the container to house the app.
> 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 I don't mean to be facetious, genuinely curios, but to the authors point, isn't that the point of the package management system? It's a standardized and encapsulated way to provide software, with sane defaults, in an auditable way, that respects the users system. I tend to agree with the author here, but I'm sympathetic to the…
Devs who use curl | bash do that because they are control freaks and want and love to make mess in user's homedirs, that is all. This is a an ego issue, not a technical one.
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.
> why do I still have programs on Linux that don’t use xdg directories? Because there are Linux developers who never heard of XDG and just put their stuff wherever. And since ignoring XDG doesn't makes your application completely unusable, they have pretty much zero incentive to learn about it. Crazy world, isn't it?
Perhaps if XDG were cut loose from the Free Desktop project, more developers and maintainers would pay more attention to it.
Earlier quoted context omitted.
Uninstalling macOS apps is usually as simple as removing the app bundle.
If only that were true. Apps leave their config and support files all over the file system.
There are certainly other ways to do that, but this is how it has been done since forever.