Reply
Thread Tools
Posts: 992 | Thanked: 995 times | Joined on Dec 2009 @ California
#81
Originally Posted by TiagoTiago View Post
And if we got a package manager, why it can't manage to keep a record of where things are installed?
You can, but you may need to switch to RPM-based Linux. YaST is much more responsible.
 
ZogG's Avatar
Posts: 1,389 | Thanked: 1,857 times | Joined on Feb 2010 @ Israel
#82
meh not RPM, just use gentoo and change ebuilds in any way u want, you can set any path and change almost everything there
 

The Following User Says Thank You to ZogG For This Useful Post:
Posts: 992 | Thanked: 995 times | Joined on Dec 2009 @ California
#83
Originally Posted by TiagoTiago View Post
If it can keep track of installation folders, what's the big deal with having the option of using custom installation folders?
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.
 
Posts: 207 | Thanked: 154 times | Joined on Nov 2009
#84
Originally Posted by TiagoTiago View Post
Why a centralized registry is worse than a bunch of files in a bunch of folders?
- 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)
 

The Following User Says Thank You to RFS-81 For This Useful Post:
Posts: 2,829 | Thanked: 1,459 times | Joined on Dec 2009 @ Finland
#85
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.
 
Posts: 1,522 | Thanked: 392 times | Joined on Jul 2010 @ São Paulo, Brazil
#86
Originally Posted by RFS-81 View Post
- registry is not portable (hard to clone configs to multiple computers)
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

Originally Posted by RFS-81 View Post
-
- all eggs in one basket
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

Originally Posted by RFS-81 View Post
-- accessing/modifying registry from shell scripts is *not* fun
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.
Originally Posted by RFS-81 View Post
-
- 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)
Isn't this similar if all configuration files are in the same folder?

Originally Posted by RFS-81 View Post
-
- 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
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)

Originally Posted by RFS-81 View Post
-
- with registry, you often cannot be sure whether stuff there is obsolete or not
With a bunch of configuration files pilled up, how can you with 100% certainty?
Originally Posted by RFS-81 View Post
-
- with rc files, you can move apps to different locations without messing up the configs
depending on the program and on the settings involved, same can be done under Windows and it's registry

Originally Posted by RFS-81 View Post
-
- with rc files, you can reinstall the whole operating system without losing user specific configs (taken /home is mounted as a separate filesystem)
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
 
Posts: 2,829 | Thanked: 1,459 times | Joined on Dec 2009 @ Finland
#87
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.
 
Posts: 992 | Thanked: 995 times | Joined on Dec 2009 @ California
#88
Originally Posted by TiagoTiago View Post
Linux gives the user power to make a mess in so many way....why the need for additional steps just to change the install folder name or location?
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.

Why a centralized registry is worse than a bunch of files in a bunch of folders?
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.

If the package manager keeps track of where things are installed, any program that would need to know if a given program is installed and where would just check the place where the package manager stores that information.
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.


dumping all executables on one folder, all configuration files on another folder etc makes quite a mess
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.
 
Posts: 1,522 | Thanked: 392 times | Joined on Jul 2010 @ São Paulo, Brazil
#89
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.
 
Posts: 1,746 | Thanked: 2,100 times | Joined on Sep 2009
#90
Originally Posted by TiagoTiago View Post
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
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.


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.
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.
 

The Following User Says Thank You to wmarone For This Useful Post:
Reply

Tags
nerd rage, whatthef?

Thread Tools

 
Forum Jump


All times are GMT. The time now is 05:19.