On Wed, 06 Jun 2001, Guillermo S. Romero / Familia Romero wrote: > quinet@xxxxxxxxxx (2001-06-06 at 1724.41 +0200): >> Here is a suggestion. I doubt that I will implement it, but maybe >> David can do it since he wants to improve the installation process. >> Keep the current dialog as it is (telling the user to adjust the value >> as needed), but try to change the default value of 32M on the systems >> in which the available memory is easy to guess. This means that the >> users of other systems will still have to change the tile cache size >> from the default of 32M, but at least those who are using one of the >> common configurations (e.g., Linux 2.2 or 2.4 on a single-user >> machine) will get a more sensible value by default. > > There is not sensible size. Start some apps, and Gimp suffer, close > those apps, and Gimp is not using all RAM. Users could try to guess > how much RAM free they have when they work with Gimp. IIRC in MacOS > users have to decide how RAM was shared (old MacOS, not last version). > Calc default, OK, but make sure the user knows it could be really > wrong.
As I said, the user will still have to adjust the value in order to get the best results. So the dialog should still be there and should still tell to change the default value to something that is most appropriate to their system. But in some cases, the initial value proposed to the user could be a bit better than 32M.
On a system that has 512M of RAM, proposing an initial value of 32M to the user can give a bad impression of the Gimp if the users click "Next" without changing the default value because they want to test the Gimp quickly. Proposing an initial value of >400M is more likely to give good results than 32M. Of course this initial value may not be ideal (maybe the user is always running some applications that take half of the available memory). The initial guess will never be perfect but at least it has a chance to be a bit better than 32M in most cases.
>> /tmp. I think that the only way to check that automatically is to run >> "df" and parse its output. This is not very elegant, but I cannot >> think of a better solution. > > In some cases, IIRC, /tmp is RAM.
I do not remember any systems that have /tmp as RAM, but some of them (e.g., default Solaris installations) have /tmp as swap. In any case, this is a local resource so this is usually better than a remote (NFS) file system. The choice between local resources should still be based on the available space.
>> Here is how it could be done: run "df $TMPDIR", "df /tmp" and "df >> $HOME". Ignore the result if "df" fails or if the second line of the >> output does not start with "/dev/" (which indicates that the directory >> is mounted from another host). If there is anything left, then use >> the directory that has the largest value in the "available" column. >> If there is nothing left, then use the old default value. The user >> will still be able to edit it anyway. > > df? It will vary if the user have installed today, or has been using > the machine a lot and is just about to do a clean up. Also, size is > not the only important thing, speed too (think two disks, not local > and remote).
Again, the user will still have to make the choice. The user knows better than the program how the different file systems are or will be used (the future usage is rather hard to guess for the program...) If we had plenty of spare time, we could also integrate a benchmarking program that compares the access speed of different drives and tries to choose the optimal configuration. But I was not suggesting a way to find the best solution automatically; I simply want to avoid the worst case (using a remote $HOME when /tmp is local and has plenty of free space) whenever possible. This is the same reasoning as for the default tile cache size.
> The dialog should point that non obvious details: use a place where > you can get more free space if you want, and in a disk that is fast. > And where to change them.
Yes, we could suggest to use a place where some space can be freed easily. On the other hand, the current text already gives some hints about how to choose the filesytem (local, with enough space available) and maybe some users would not read it if it is too long.
-Raphael
