discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Debian and SimplyGNUstep


From: oberhage
Subject: Re: Debian and SimplyGNUstep
Date: 10 Oct 2003 13:38:14 GMT
User-agent: tin/1.4.6-20020816 ("Aerials") (UNIX) (AIX/5-1)

Martin Herbert Dietze <address@hidden> wrote:
: Chad Hardin <address@hidden> wrote:

:> The filesystem layout is designed to be very logical and easy for the 
:> average user to understand.  That is a really great feature of GNUstep 
:> (from the users perspective), which would be a shame to remove.

: I don't think this argument still holds in times of packet
: managers. Yes, on my OS/2 box I still have to keep the file
: system tidy by installing applications in their own
: subdirectories etc., but I don't find this more logical and 
: easy, it just blows up the list of environment variables.

I do think, that a lot of people (here) think only in terms of 'single
machines'. But it is a real blessing, when you use a central application
server (e.g. via nfs) when you're capable to install applications there
as a whole and separated from each other. And just things (in it), that
belong to it. This requires the 'wrapping' into single directories. These
can then be combined under a 'subject' tree, should you like and need it
With just ten applications you wouldn't subdivide /Local/Apps (or /LocalApps)
any further, but with fifty or more you may want to group them somehow
(like /Local/Apps/Viewers (or /LocalApps/Viewers) and so on).
With OPENSTEP specifiying /Local/Apps (or actually /LocalApps, there) is
just sufficient for all of these to be found. More conveniously, as
/LocalApps is the standard place for that, you don't even have to specify
it!

Thus /usr/bin and the like is neither the ideal place (local to machines)
nor the way to do it. 'Predefined' paths have to be altered/augmented by
adding several(!) new ones. The charm with OPENSTEP was - and can be
with GNUstep - that you specify a single (may be additional) directory,
and all applications can be found - and more importantly, their services
and 'file-type'-handling is automatigically added to the Workspace-Manager.
Same holds true when you remove something. This is all dynamicalluy and
utomagically learned at next login or after 'some time' determined by the
Workspace-Manager, without the need to alter a single environment-variable or
profile, but the one describing unusual or additonal paths (called
"ApplicationPaths" in the "GLOBAL" domain for OPENSTEP).

Being able to shut that mechanism down for certain paths is also a good
idea, by the way - think what happens when you're linked to a world wide
repository as with AFS or DCE/DFS. You probably don't want all of these
searched, it might be (too) many :-).

This all works for a single machine just as well, of course.

: [...]
: I second the OP's point. It should be possible to integrate
: GNUstep more smoothly into an ordinary Unix directory tree. 

For this I would second the idea of making symlinks in '/' to
appropriate places. Where there are directories already
(like /usr/local/GNUSTEP for /Local) you can link to them, where there
aren't, you/we can add this to GNUSTEP_ROOT, such that there is
e.g. Net(work) within /usr/lib/GNUSTEP (for Debian) and so link
/Net(worK) to that - apart from /System, where this applies naturally.

The /Net-hierachie is not superflous, by the way, but a blessing as
soon as more than 'single machines' are involved (see above), but
"clusters" of client machines. It would be the 'standard place' to add
applications and libraries etc. to, which come from a central repository
- without the need to add an 'unusual path'.

/Local should be for that single machine you're working on, only.
Why? Well maybe you have (just) one machine with a scanner: Why put the
scanning application on every machine or the network-server? It just
confuses people.

Even the point with the .hidden-file having to reside in the '/'
directory is not totally true. Although it is the most elegant place
for the 'appearance' of the machine to a user, it would be sufficient
to place a 'global .hidden-file' into the users' home-directory (maybe
under GNUstep), that influences what is shown to him by default and
what not. OPENSTEP knows about a (so called) "expert setting" that
decides if you see 'all files' (e.g. starting with a '.' or '/tmp' etc.)
and that you can set (or unset) personally - per user.


The last point: Debian (and I'm just talking 'woody' here), in contrast
to what another person posted previously,  has a very well developed
concept to allow 'display managers' to enter window-sessions like 'kde',
'gnome' or 'wmaker' (well, the latter just parlty a session :-). This works
for (at least) 'kdm' and (my preferred) 'wdm' and is automatically adjusted
by and to the installed (.deb) environments (e.g. window-managers).
Since starting with 'woody' there is even an 'environment/session' concept,
not just a 'window manager' one, it would be very easy to develop and add
a "GNUstep" one - just as "gnome-session" can be separated from (just)
sawfish - gnomes' preferred window manager with Debian.

Thus for me, all the awkwardness of the FHS can be easily overcome or
hidden/cached - and yes, I personally hat the clobbering of single
directories like /usr/bin etc., especially when it comes to not so obvious
things as application- and fileicons and the like - or think of bundles/
services under OpenStep, but that is just my personal view.

Thanks and greetings,
 Ruediger Oberhage
-- 
H.-R. Oberhage
Mail: Univ. Duisburg-Essen              E-Mail: address@hidden
      Fachbereich 7 (Physik)                   address@hidden
      Standort Essen, S05 V07 E88
      Universitaetsstrasse 5            Phone:  (+49) 201 / 183-2493
      45141 Essen, Germany              FAX:    (+49) 201 / 183-4578


reply via email to

[Prev in Thread] Current Thread [Next in Thread]