Re: "Install here" : why Linux doesn't do it?
 

You can, but you may need to switch to RPM-based Linux. YaST is much more responsible.

Re: "Install here" : why Linux doesn't do it?
 

meh not RPM, just use gentoo and change ebuilds in any way u want, you can set any path and change almost everything there

Re: "Install here" : why Linux doesn't do it?
 

Because you usually should compile package to change folders - the binaries have an explicit file path names.

Of course, a good package would have it run-time controllable, for exam - via having a file in /etc/default but package manager has no way to recognize and manage it.

Re: "Install here" : why Linux doesn't do it?
 

- registry is not portable (hard to clone configs to multiple computers)
- all eggs in one basket
- accessing/modifying registry from shell scripts is *not* fun
- it's easy to mess up *anything* when making a mistake with registry (with rc files you only mess up the one particular app/function)
- if you mess up settings of an app (or want to return the "factory settings"), just delete the rc file and start over - nothing else is affected
- with registry, you often cannot be sure whether stuff there is obsolete or not
- with rc files, you can move apps to different locations without messing up the configs
- with rc files, you can reinstall the whole operating system without losing user specific configs (taken /home is mounted as a separate filesystem)

Re: "Install here" : why Linux doesn't do it?
 

FYI
If executable is installed in bin or sbin you can tab-complete it from anywhere in CLI if you remember at least couple of first letters of executable/prog name.

Re: "Install here" : why Linux doesn't do it?
 

Just export a .reg file for the keys in question, transfer that file however you want, and on the destination import it (usually simply by double-clicking and clicking yes on a "are you sure" dialog

I'll give you that, being a single file under a single file table etc does increase the odds that if one thing goes wrong everything does

haven't had much experience with that, i did once, quite some time ago, play with a Visual Basic program that read and wrote to the registry, wasn't a big deal.
Isn't this similar if all configuration files are in the same folder?

many programs treat the registry like that too, you delete the keys for the program and it just recreates them with default values (not all of them do it, but then, many programs that use their own configuration files also fail if you delete the files, but of course not all of them)

With a bunch of configuration files pilled up, how can you with 100% certainty?
depending on the program and on the settings involved, same can be done under Windows and it's registry

that is indeed a disadvantage with a monolithic settings storage; though with what you describe, it wouldn't be much help if the reason that made the reinstall necessary was some messed up user config




@slender:That gets messy if you got lots of programs that start similarly; no need to have everything on PATH

Re: "Install here" : why Linux doesn't do it?
 

Hmm. Messy? But double tabulator lists all apps in nice list?

.edit
E.g. Start xterm, root, type maemo <tap tabulator twice>, You get nice list of commands.

Re: "Install here" : why Linux doesn't do it?
 

Because there is no a centralized authority who decides where the package files should reside. And if you use package A and it wants to use some piece of package B you should have a well defined path to parts of package B. So, package B places become nailed.

It is not worse - it is more restrictive and less reliable. Besides that the package manager creators didn't try to solve all problems in one step.

What is an "information"? There are a lot of problems here. One, as an example - you want to run application 'tar' but there are at least two versions of that. Right now you just use 'tar' and kernel exec can find an installed version in 'PATH' but in case of centralized DB of packages your software should have business with checking all that versions.

Of course, a centralized DB of packages may be more sophisticated and includes this kind of search but this example is just an entry to hell. There are, for additional example, a common DBs which can be handled a LOT of software like common configuration files in multiple packages (yes, 'gconf' gets some handling of it but... however...)

Finally, you can return back to files tree as a location place... Today it is a problem with a limited space in N900 but it is a problem only for N900.


Sure. But it is a requirement if configuration files are common between multiple packages - there is no another reliable way to do it. Any kind of 'registery' or link-DB which could point a package to a right configuration file is actually a way to hell - any link system MUST be checked and the consistency problem is huge. BTW, it is a most annoying problem with Windows.

Re: "Install here" : why Linux doesn't do it?
 

What if you only have one program starting with letter whatever, but this game you installed got 20 helper executables that also begin like that, to the point you gotta actually spell out the whole name of the program you wanna run, while the helpers under normal usage, you should never need to run yourself at all?

Only things you routinely need to call from any folder, or that programs need to call without knowing the full path, should go into PATH, everything else just gets in the way.


And you can use path completion for each step when spelling out a full path yourself, not really so much additional work.

Re: "Install here" : why Linux doesn't do it?
 

Which is a disaster, since you need to go through the step of exporting it to a file.

I suggest that instead of complaining that Linux isn't Windows, you learn how Linux (indeed, most *nix platforms) do things instead, and try to understand why they are done that way.


Certainly more complex than opening and reading/writing from a text file. And the registry isn't human readable without using the registry editor or first exporting to a .reg file.

Linux is not Windows. It is really that simple.