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.

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

Things that are shared, could go under their own subfolder insider a folder dedicated for shared things, no need to pile everything.

In messy situations where one program needs one version and the other program needs another version and the thing they need different versions wasn't designed to have more than one version in the system, with Windows we just use the order where things are looked for, first in the folder where the executable is, and then in %PATH% (there are probably some other steps in between and perhaps beyond, and i think each folder listed on %PATH% is checked in order, not sure if it's starting with the first or the last); i don't see why a similar approach couldn't work under Linux.

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

It fully agree with you - the biggest advantage of Unix was a capability to explore and modify of all system objects via a regular file system tools.

Unfortunately, it is near gone now...

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

it's jsut one or two steps more than looking for the right file to send


From what i remember, to read you called a system function specifying the path of the key, and to write it was the same, but you also specified the type of data and the contents.

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

But why? Why bother doing that when you have software with its own database designed to track things automatically?

The only reason this is necessary under windows is due to the total disconnect between software vendors who end up using the exact same names for their executables and libraries. As it stands, anything program specific is parted out into its own directory.

Because in Windows it is a disaster due to everything shoving .dll after .dll in System32 to the point that they had to create WinSxS to get around the DLL hell that pops up constantly.

Do you really think we are unfamiliar with the way things are done in Windows?

After digging up the right key and exporting it to a file. In *nix I just hop into /etc and SCP the file to the machine I want. And it works with no extra steps.

Right, whereas a plaintext config file in *nix needs little more than fopen() and fscanf() to parse the contents (and it works across multiple platforms!) You can always use more complicated libraries, but generally they aren't necessary.

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

Basically, you recreate a something like Unix file system tree in registry. Windows registry just separates two basic functions via link layer here - file place allocation and file search. For both some tree-like structure is needed.

There are advantage in this approach, yes, but it also has big disadvantages - consistency (because a new link layer) and accessibility - Unix approach gives you a way to use a generic file system search/list/modify tools but a separate registry approach has a lot of restrictions here.

Hm-m, that is a different story and I agree with you on word 'messy' here. I wrote about just plain example then only one version is installed and it was for case of search file via registry which could have different key locations for both versions.

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

What is the point of having thigns actually be just files in the filesystem if it's just a mess of things piled up in the same place? If there is a whole layer of software making that mess not be a mess, then whats the point of using the file system ?


The point is having things be organized, if there is need to always know where somthing is, don't hardcode a path, use a way that no matter where the things is, you know it (like an environment variable, or identifying the path for the thing somewhere, be it a registry, or a filesystem abstraction like symlinks that always have the same name, under a folder that is always the same etc). Hardcoding values that people might have some reason (even reasons you can't think off) to want to change, is a bad habit.




Regarding messing with the registry with Visual Basic, a quick google search led me to this: http://msdn.microsoft.com/en-us/libr...8VS.80%29.aspx ; i don't think that was the approach i used at the time, it involved a few more steps to have things set up, but either way, it's somthing quite simple, about as simple as messing with text files in arbitrary paths.

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

anyway i feel like really good trolling here, you don't like it (or don't get it) just don't use it. people here gave u a lot of options(LFS or gentoo or self compiling e.g.). btw there is project to make all programs executables without installing them at all so u can put them anywhere(google for it). and once again after first 1-2 pages i think it's trolling. don't feed the troll

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

that's the point, and if i come to visit you and i want to use your comp i wouldn't need to use find tools to get programs running and so on. that's why there is simple universal things that are made for everyone so it would be easy.

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

If someone comes visit me and asks to use my computer, i ask them what they want and either do it for them, or put it on the site they want before leaving the chair, or boot up my secondary machine.... ¬.¬

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

It is easy to do a mess with registry too. Registry just creates some order but this order has it's own problems.


Good point about order.

However, the hardcoded path problem does exist only in N900. The messy file location may be a problem too but I suspect you just don't know yet the reason why this file is put in that place.

And again - messy environment is easy to do with registry too. It is just M$ who maintain some order in Windows registry, without them it could be a bigger mess (I just remember the early days of Windows).

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

The default folders could follow a stadanrd organization algorithm (organization being the key word), but thought that would be an advancement, the focus in this thread, at least originally, was about not needing to obey the predefined install folder when desired.

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

I dont know what the problem is, you can simlink to almost every standard fs from the default location, that isnt enough for you?

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

Installers like Ubuntu's tend to lead in the direction of one big partition, but no, that's not a "Linux thing". Windows 95 may have killed the old MS-DOS "join" command, but in the *nix world, it is normal to spread portions of the filesystem across multiple partitions, drives, and network volumes.

For instance, I tend to break at least /boot, /var, /var/tmp, /tmp, /usr, /usr/local, /opt, /home, and swap away from root. For each I can select a filesystem type appropriate to the data it will hold, and I don't need to worry that, say, a log file suddenly growing massively large will take down my machine. Using a logical volume manager makes it easy to expand a given filesystem when more space is needed, and drives may be added as needed.

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

I would rather not have to jump thru hoops or wait till after the installation already happened in order to have a program be installed in different folders than the default; like i said early in this thread, similarly to how it is with most install process with Windows

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

I find it amusing that someone whose sum total experience with programming is with Visual Basic, is lecturing us on how bad the Linux file system layout is, and asking why can't it be more like Windows.

At least, that's where I see this as going. :confused:

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

I think someone (either me or some of you, or perhaps both) is getting things backwards here....

I always thought that using a single partition for the whole physical hard disk, was a Windows thing, and using lots of partitions was a Linux thing; but i could swear someone in this thread said the opposite was what was widely accepted as the norm.

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

But we have said many many times here that whole structure of modular linux is what it is. You are hitting your head to wall here :)

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

It was probably me and what I meant was that quite many people windows machines what I have used have had C/D/E etc. DRIVE letters and folder structure is bit like your bookshelf in library. When it comes Linux FS it´s something that at least to me I can't put in real physical world. It´s just totally something different.

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

That's assuming you know which keys a particular program is using. With *nix programs it's mostly obvious since config file is similarly to program name and mostly it's just 1 file or 1 directory.

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

lol, amusing take on the situation....


What i'm complaining about (and trying to understand why it could be considered better) are two things:

• Lack of choice of destination folders when installing programs thru normal means.
  
  and
  
  
• Dumping executables all in a single folder, config files all in another single folder etc, instead of developing the folder tree keeping things more organized.

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

No, he touches a serious issue. Just one example - the original Unix had only /bin, /dev, /etc and /usr, that's it. Then users asked the place to put their files which are common between them ---> /usr/bin and a couple of directories were created under /usr.

Later the same history cycle turned again at least twice with /usr/local and /usr/share. Finally we have /opt and the issue of structuring it is under way to us.

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

Yet again endlessly arguing about the same thing....

Places where the private libraries and resources are stored:
C:\Program Files\<appname> <=> /usr/lib/<appname> (arch dependent) ,/usr/share/<appname> (arch independent)
GNU makes an extra distintion here. Other than that, mostly the same.

Places where shared libraries are stored:
C:\Windows\System32 <=> /usr/lib
No difference.

Places where binaries that should be on PATH are installed:
Windows: C:\Windows\Sytem32 or create a private dir and add to %PATH%
GNU: /usr/bin or create a private dir and add to $PATH

What's the diference again? None. This is not an FHS issue.

What he wants is a package manager that asks where to symlink /usr/share/<appname> and/or /usr/lib/<appname> into, and we reviewed a lot of that stuff when discussing the /opt problem, didn't we?

The one I proposed is still on brainstorm...

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

With most Windows installers, i am not restricted to just under C:\Program Files\ , if i want i can install it straight on C:\ ,or i can go C:\Documents and Settings\username\potatoes\bananas\ , or i can install it on C:\random folder name\another random name\gibberish\ , or i can install it in a DVD-RAM disk, or in a pen-drive, or on a network shared path etc, and "appname" can be whatever i want, even nothing (which would mean the folder i put it in)

edit: and the launch shortcuts etc, and the program itself, as long as where it is installed is currently avaiable when i launch it (and in some cases while its running) etc, everything will work just as if it was installed in the default location (except in cases where dumb/lazy programmers hardcoded paths)

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

With most GNU/Linux software installers, i am not restricted to just under /usr/share/, if i want i can install it straight on / ,or i can go /home/javier/Xilinx/ISE , or i can install it on /opt/xilinx/ISE , or i can install it in a DVD-RAM disk, or in a pen-drive, or on a network mounted path etc, and "appname" can be whatever i want, even nothing (which would mean the folder i put it in)

In fact I'm typing /mnt/Opt/xilinx/ISE_DS/ into the Xilinx ISE installer as I was writing this post.

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

Where are those installers and why pretty much all programs i've found to install on the N900 don't use them?

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

that cant be helped

You have that kind of "culture" in every os.

i've been there too.

In windows, i really HATE how programs decides the names and the pathes of the variables inside the windows registry. I really want to change the names, or at least, to let the programs to change the registry keys names and pathes in the installation procedure, and i feel exactly like you, it cant be done. i only must accept it

in linux, i have the same situation: packages decides the pathes, and that cant be changed.

in the linux way, the world doesnt ends there: everything has a workaround.

For me, the solution has been to use GENTOO, another linux distribution that lets you to install your programs where you want them.

Not everyone needs it, thats why the linux distribution method works, and everyone in peace.

Maybe you could try it too.

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

Is there GENTOO for the N900? Does it have any downsides when compared to Maemo5?

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

@tiagotiago. Nop, gentoo is not ready to be installed into n900.

n900 has an specially modified linux distribution that is called maemo.

Some people are trying to port several linux distributions to the n900, afaik no one is trying to do it with gentoo yet.

i can't blame them: its like trying to install windows xp in the new notebooks designed for windows 7, its not an easy task.

What we what is a maemo powered device, this operating system has A LOT of predefined configurations, a lot of them are really questionable, but that is what we have

Something that changes the operating system behaviour can be called as "hack de device".

almost everything is possible, because is a gnu/linux powered device, that doesnt mean that everyone can do it. it can be hard

There is where the fun begins!

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

Now that's a good question.

On the N900*, you don't generally use installers, but use what's called a "package manager". A package manager's mission is, by definition, to allow installation of new software (and removal) requiring the least amount of effort from the user.

Why? Because traditionally, the amount of extra applications a user installed on a pristine GNU/Linux environment is so large that having to answer a single question for each of them quickly becomes unmanageable, as the first distributors and LFS users quickly discovered. So they devised a way to install new software with the user just selecting the new 37,000 packages of software he wanted to install and not having to answer any other single question (or just the most important ones).

Long time ago someone decided not only to make Maemo a Debian-forked distro but also to make the preferred third party software distribution method Debian packages (whoever made this decision could as well have decided that they want a "installer" based method!!).
I'm sure one of the reasons for going with a package manager is that they did agree with the mission of a package manager: that is, to make it easy to install software -- no questions asked.

Now, I personally agree with this decision, because nearly every time a installer asks me a question I leave the default setting as is and move on. This does include the "path for private sources/binaries" question.

Note the use of the "nearly" keyword in the above paragraph. This is because on the Nokia Internet Tablets, the root file system has been generally smallish. Since the root file system is the place where the "path for private sources/binaries" defauls to, one could easily find himself filling such a small space.

Such a user would need to devise alternative ways of installing software, or configuring the package manager appropiately, or even use the poor man's solution (but still quite effective!!) of symlink /usr/share/<appname> to /some/place/I/want/. (Note: explaining symlinks is outside the scope of this post).

What happened then? Well, as the "path for private stuff" question rose in importance, it started to make _less_ sense for package managers to NOT ask it. And -- behold! They started ASKING for it!

Get a N810 and try to install OpenTTD. It will ask you wheter to install to the internal card or to the external SD card.


On the N900, "the makers" realized in what I can only call one quite embarrasing moment that its rootfs was plainly too small for normal usage. So they devised a plan, not unlike what N8x0 packagers used to do with large packages, where certain packages would install into the internal card (aka /opt) instead of the smallish rootfs. This process is what is called "optification".

With such a setup, again it stopped making sense for package managers to ask where to install software, because the default place was again good enough for a majority of users. So, the OpenTTD package for the N900 doesn't ask you where to install it.


To sum it up,
- Where are the installers?
Guidelines for the N900 suggest not to use them but use packages for ease of use.
- Why does my package manager not ask for a path when installing a package?
Because a majority of people thinks such a question is useless, as the default is OK for them.
- Does this mean I'm forced to install to the default location?
No; see this very thread or the discussions we used to have about optification a year ago for information.


*Note that the N900 specially has quite a lot of extraneous limitations. Namely, "installing apps to an SD card" would be quite impossible usually because no one asked N900 developers to ensure our applications would be installable into a Windows filesystem a.k.a. FAT (and not a real filesystem with support for POSIX elements and attributtes).

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

Many windows installers got a command line option for "unattended mode"..... *pouts*