3 ms·

> I suppose Linux is more open, but there is still the very noticeable centralisation of app-store-like repositories, the discouragement of installing software

by creshal 11y ago

> I suppose Linux is more open, but there is still the very noticeable centralisation of app-store-like repositories, the discouragement of installing software via other means, and the bureaucratic process of getting software into those repositories. Not quite. What is recommended against, if at all, is installing directly from source. You're encouraged to build packages instead and use those. (And mainstream distributions have wrappers that let you build packages from arbitrary sources, if the developer doesn't provide packages for your distribution.) It's like recommending Windows users to use .msi packages over copying files directly to %PROGRAMFILES%, which isn't the worst advice.

pdkl95 11y ago
> What is recommended against, if at all, is installing directly from source. Nonsense. There is a recommendation to leave /usr/{bin,include,lib,share} to the package manager, but the /usr/local prefix is specifically for locally managed installs. ./configure --prefix=/usr/local Support for arbitrary prefix (such as $HOME) installs has always been possible, so you don't even need root to install from source: ./configure --prefix="${HOME}" Also, the recommendation to keep /usr managed by the package manager is just that - a recommendation. It's probably a very good idea to use the package manager for those files, but it isn't a requirement. As you, the owner of the computer, still have ultimate control[1], you can install whatever you want wherever you want. It may not be a great idea unless you really know what you're doing, but freedom necessarily includes the freedom to shoot yourself in the foot. [1] as opposed to MS asserting control by limiting how software can be installed, and the forced updates that change anything, uninstalling without your permission, and reset configuration options
- green7ea 11y ago
  The $HOME/.local directory is made for home installs. I learned this not too long ago and it has been very useful ever since.
  - pdkl95 11y ago
    Well sort of. The custom for many, many years is to simply use $HOME as the prefix, and putting $HOME/bin in your $PATH. Avoiding those directories (and other stuff that was traditionally located directly in $HOME) was probably why the more recent "desktop environments" used $HOME/Desktop as their "top" directory for the GUI environment. Later on, some people felt that all the configuration files in the home directory ($HOME/.rc and similar) was a mess, so the $HOME/.config was proposed as the "proper" location for configuration files. Of course, this just resulted in programs using both* directories, depending on when they were written. Years later, in their usual over-engineered style, the freedesktop.org people later extended this idea into the XDG Base Directory Specification[1], which is where $HOME/.local enters the story. Of course, they don't actually specify it as a prefix suitable for use in "./configure --prefix=" (which would have made a lot more sense). The only define the share directory for use with XDG_DATA_HOME: $XDG_DATA_HOME defines the base directory relative to which user specific data files should be stored. If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used. Of course, now you have to lookup the relevant environment variable and specify all the detailed directory options to autoconf if you want to actually support their spec, which probably looks something like # pick one PREFIX=$HOME #PREFIX=$HOME/.local ./configure --prefix="${PREFIX}" \ --sysconfdir="${XDG_CONFIG_HOME:${HOME}/.config}" \ --localstatedir="${XDG_CACHE_HOME}:${HOME}/.cache}" \ --datarootdir="${XDG_DATA_HOME}:${HOME}/.local/share}" XDG isn't a bad idea, but it's poorly specified and as that example shows, it can conflict with convention at times. None of that makes $HOME/.local (or any other prefix) wrong - it's your homedir, you can organize it as you like. That's one of the nice features I really like about autoconf - it makes it very easy to install software anywhere you want, even unusual/non-standard locations. [1] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html http://standards.freedesktop.org/basedir-spec/basedir-spec-l...
- pbhjpbhj 11y ago
  Back in the day when I was using Slackware and configure-make-install-ing software I'd use checkinstall (https://help.ubuntu.com/community/CheckInstall https://help.ubuntu.com/community/CheckInstall) so that I could ensure installations wouldn't leave stale files all over the system. Now I've probably only got a handful of programs (from github) that are self compiled; instead I use Ubuntu and PPAs.

by creshal 11y ago

pdkl95 11y ago

> What is recommended against, if at all, is installing directly from source. Nonsense. There is a recommendation to leave /usr/{bin,include,lib,share} to the package manager, but the /usr/local prefix is specifically for locally managed installs. ./configure --prefix=/usr/local Support for arbitrary prefix (such as $HOME) installs has always been possible, so you don't even need root to install from source: ./configure --prefix="${HOME}" Also, the recommendation to keep /usr managed by the package manager is just that - a recommendation. It's probably a very good idea to use the package manager for those files, but it isn't a requirement. As you, the owner of the computer, still have ultimate control[1], you can install whatever you want wherever you want. It may not be a great idea unless you really know what you're doing, but freedom necessarily includes the freedom to shoot yourself in the foot. [1] as opposed to MS asserting control by limiting how software can be installed, and the forced updates that change anything, uninstalling without your permission, and reset configuration options

green7ea 11y ago
The $HOME/.local directory is made for home installs. I learned this not too long ago and it has been very useful ever since.
- pdkl95 11y ago
  Well sort of. The custom for many, many years is to simply use $HOME as the prefix, and putting $HOME/bin in your $PATH. Avoiding those directories (and other stuff that was traditionally located directly in $HOME) was probably why the more recent "desktop environments" used $HOME/Desktop as their "top" directory for the GUI environment. Later on, some people felt that all the configuration files in the home directory ($HOME/.rc and similar) was a mess, so the $HOME/.config was proposed as the "proper" location for configuration files. Of course, this just resulted in programs using both* directories, depending on when they were written. Years later, in their usual over-engineered style, the freedesktop.org people later extended this idea into the XDG Base Directory Specification[1], which is where $HOME/.local enters the story. Of course, they don't actually specify it as a prefix suitable for use in "./configure --prefix=" (which would have made a lot more sense). The only define the share directory for use with XDG_DATA_HOME: $XDG_DATA_HOME defines the base directory relative to which user specific data files should be stored. If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used. Of course, now you have to lookup the relevant environment variable and specify all the detailed directory options to autoconf if you want to actually support their spec, which probably looks something like # pick one PREFIX=$HOME #PREFIX=$HOME/.local ./configure --prefix="${PREFIX}" \ --sysconfdir="${XDG_CONFIG_HOME:${HOME}/.config}" \ --localstatedir="${XDG_CACHE_HOME}:${HOME}/.cache}" \ --datarootdir="${XDG_DATA_HOME}:${HOME}/.local/share}" XDG isn't a bad idea, but it's poorly specified and as that example shows, it can conflict with convention at times. None of that makes $HOME/.local (or any other prefix) wrong - it's your homedir, you can organize it as you like. That's one of the nice features I really like about autoconf - it makes it very easy to install software anywhere you want, even unusual/non-standard locations. [1] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html http://standards.freedesktop.org/basedir-spec/basedir-spec-l...
pbhjpbhj 11y ago
Back in the day when I was using Slackware and configure-make-install-ing software I'd use checkinstall (https://help.ubuntu.com/community/CheckInstall https://help.ubuntu.com/community/CheckInstall) so that I could ensure installations wouldn't leave stale files all over the system. Now I've probably only got a handful of programs (from github) that are self compiled; instead I use Ubuntu and PPAs.