Why can't you decided where programs go?

[mintmag]

When installing programs either from a the repository or from a local .deb file it doesn't let you chose which directory you want it installed. I'm curious is there a reason for this. What if the main drive gets full and you want to install programs to another drive.

[CharlesA]

Because there is a specific structure to the file system? See here.

If you want to pick where you install your applications, you might look into compiling things from source.

[mintmag]

Right, but why force it. Windows has directories like that too.

[lisati]

The short answer is that Linux does some things a bit differently to Windows, or, if you prefer, "Linux is not Windows."

A generalization you might encounter from time to time is "On a LINIX system, everything is a file; if something is not a file, it is a process." For an elaboration, you might want to read this article.

[QIII]

Since it is all open source, you are free to download any source you choose, alter it as you wish, change it to allow you to install wherever you want, compile it and go on your happy way.

If you want to install things willy nilly, nothing is holding you back.

[mintmag]

The short answer is that Linux does some things a bit differently to Windows, or, if you prefer, "Linux is not Windows."

A generalization you might encounter from time to time is "On a LINIX system, everything is a file; if something is not a file, it is a process." For an elaboration, you might want to read this article.

Thanks I will give that a read. What I would like though is a more layman's answer. Is it to do with the way it indexes or whatever it has in-place of a registry?

[lisati]

There is no direct equivalent to the Windows registry that I'm aware of. The Windows registry serves a number of purposes, including the saving of configuration information and system information. In Linux, /etc is commonly used to store configuration information, and /var is used for information about the state of the system. Extreme care is needed when editing the contents of both, as it is very easy to make changes that break your system.

[TheFu]

Some more ideas on this topic: https://serverfault.com/questions/23...home-directory

The "main drive is full" really isn't an issue. Unix has symbolic links which can redirect from /usr --> /some/other/hdd/directory/ if it becomes necessary. I've used this back when HDDs were 1G in total size. With larger disks these days, it really is hard to use more than 30G with applications and settings, which is a tiny disk (when compared to OTHER, popular, OSes) for today. It is the data that goes elsewhere and is usually trivial to control that other location. My daily use desktop is

Filesystem       Size  Used Avail Use% Mounted on
/dev/vda1         17G   13G  2.6G  84% /

which included /home/ too. Hardly a bloated install. This install has been moved forward from 8.04 days - so 8 yrs old. I'm careful to keep "data" on network drives (NFS).

Actually, much of the OS can be on NFS drives too. Don't see this very often anymore, but in the old days, when storage was expensive and smaller, we routinely shared /usr across all the systems on a network running the same architecture. Looking up the "Linux File System Hierarchy" will give the full details of which directories can be remote, which can be read-only and which must be local.

Regardless, symlinks are a powerful tool, when necessary.

[mintmag]

Some more ideas on this topic: https://serverfault.com/questions/23...home-directory

The "main drive is full" really isn't an issue. Unix has symbolic links which can redirect from /usr --> /some/other/hdd/directory/ if it becomes necessary. I've used this back when HDDs were 1G in total size. With larger disks these days, it really is hard to use more than 30G with applications and settings, which is a tiny disk (when compared to OTHER, popular, OSes) for today. It is the data that goes elsewhere and is usually trivial to control that other location. My daily use desktop is

Filesystem       Size  Used Avail Use% Mounted on
/dev/vda1         17G   13G  2.6G  84% /

which included /home/ too. Hardly a bloated install. This install has been moved forward from 8.04 days - so 8 yrs old. I'm careful to keep "data" on network drives (NFS).

Actually, much of the OS can be on NFS drives too. Don't see this very often anymore, but in the old days, when storage was expensive and smaller, we routinely shared /usr across all the systems on a network running the same architecture. Looking up the "Linux File System Hierarchy" will give the full details of which directories can be remote, which can be read-only and which must be local.

Regardless, symlinks are a powerful tool, when necessary.

Oh so you can use symlinks. I'm still not entirely sure what they are. I know that's what gets created when I try to make a shortcut. Can you tell me why Ubuntu uses symlinks instead of shortcuts. A typical shortcut would look something like

xdg-open /location/to/program

[ian-weisser]

Right, but why force it. Windows has directories like that too.

It's only forced if you insist on using Package Management.
Packages tell the installer (dpkg) where they should be installed.

You are, of course, free to edit the package to install wherever you like.
Warning: That's quite advanced, and can easily break your whole system if you edit the wrong package.

It's generally easier to not use the packages if you want that level of customization.
Instead, install using the (edited) makefile. A much older and more brittle, but much more configurable installation method.
Warning: Using the makefile method of installation adds some (human) admin responsibilities, since you are giving up the advantages of packages.
Warning: Using makefiles is an intermediate-level skill. It must be practiced and learned.


One of the ancient features of the Debian/Ubuntu is space savings through the use of shared files, sometimes including whole subsidiary applications, (not just dll-type binaries.
Shared files are assumed to be in a standard location, and consuming applications --including system applications-- may not verify that.
So if you move one of those shared files by editing it's package, be sure you place a symlink (shortcut) to the new location so using applications can find it.