[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Fri, 27 Feb 2004 22:30:17 +0000 (UTC) 
Subject:Re: 15.53 - Windows Installer Available 
From:jeffb 
Volume-ID: 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brent,

[You wrote, regarding Inno Setup scripts]
>Yes.  My version is very simple (in fact, it may not
>do all the right things, as I'm not as familiar with
>Poplog as you).  I'm attaching the script for your
>amusement.  :-)
>

The attachment seems to have got lost. I'm sure that simple is good. I 
suspect that I have over-complicated mine.

[I wrote]
>>(I'm not sure if, by "smoother install for Debian",
 you mean you want to
>> use the same download to install the Windows and
 Debian downloads, or if
>> you just mean that you want a better-scripted Debian
>install?)

[You wrote]
>The latter.  Here are the problems I have with the
>current Linux tarballs:
>
>1.  They aren't built against current libraries, so
>you have to install old libraries like termcat and
>libc5.

There is a version of Poplog built against libc5. I believe Stephen 
Isard maintains it. I thought that most (if not all) of the current 
Linux versions of Poplog were built against newer versions of the C 
library?

Console-based VED was developed against termcap. I haven't looked into 
whether there is a simple, low-cost upgrade path to something more 
current. What does Linux use nowadays? Curses (question, not a comment)? 
I'm not really the best person to comment on the Linux or Unix versions. 
I haven't used either Termcap or Curses since 1987.

>2.  Poplog does not get installed in the right places
>according to the Linux File System Standard.  Ideally
>the man pages would go into the system manpage
>directory, Binaries would go in /usr/bin, etc.
>There's leeway in this, obviously, but it would make
>integrating with Emacs and other tools easier if
>things could be found in "expected" places.

I've always been in two minds about this. I like applications to go in 
one place, with nothing but links being installed in the "correct" 
locations. This makes the applications manageable as a unit and I can 
upgrade, temporarily disable and later re-enable, or completely remove 
the application with a few simple operations. Configuration and 
application management are clearly separated tasks from installation, 
and nothing sophisticated is needed to manage the installation. The 
downside is that every user usually has to run a setup script to gain 
"access" (i.e. set up paths and other environment variables) to the 
application. This is pretty much how software used to be distributed, in 
the olden days, on multi-user machines, when the idea of an application 
being able to write to files in system directories was considered 
risible. It still works for me, but is sadly very unfashionable. The 
current vogue appears to be to splat the current installation into as 
many places as possible with every imaginable type of file. Somehow, an 
image of a tomcat spraying to mark his territory crosses my mind at this 
point. Not that, as open source developers, we would dream of 
identifying with this image.

Not that I'm biased, you understand. We have this "Linux File System 
Standard" thing, and we have a responsibility to try and make it work. 
Standards are wonderful things. They are standards, after all, so they 
must be.

Let me find my other mind. EMACS. Very worthy cause. Must support the 
troops, and all that. Any compromises possible? I don't have too much of 
a problem with man-pages, and Poplog doesn't have too many. Can we put 
links to binaries, or does it have to be the binaries themselves? Users 
can build their own binaries and saved images, and Poplog has paths for 
handling this, so there's no reason other than ease of application 
management not to put the binaries in /usr/bin. If we go the whole hog, 
then presumably the init.p and vedinit.p and all the other system-wide 
initialisation scripts should go in /etc or /etc/poplog? At this stage, 
Poplog probably needs updating to look somewhere other than $popbin for 
start-up scripts. (Roger or Aaron will probably mail in to tell me that, 
actually Poplog has been able to do this since 1990, but nobody has ever 
taken advantage of the feature). We've also usurped the role of Poplog 
administrator, because s/he now needs root's access to /usr/bin, /etc, 
etc. (or do I mean /etc.)?

On Windows, we can register where the applications and libraries are to 
be found, so it isn't any longer necessary to disperse an application's 
files into the current installation, although, Microsoft, in their 
wisdom, have made path management a pig, and so, pretty much, everybody 
still does disperse their application upon installation. It makes a 
market for "Uninstall" applications, and markets are good, aren't they? 
Or was that in the 90s?

I'm open to persuasion, but as you may have guessed, somewhat sceptical. 
However, I don't own any of these versions, so, frankly, whatever a 
volunteer contributes that is widely accepted by the user community, is 
probably an acceptable solution.

>3.  GTK or QT would be preferable to Motif (this is a
>longer-term goal).

I agree, and there is a lot of support for the idea amongst the 
community, but less in the way of resources to bring it to fruition.

It would be nice to try and arrange some funding for somebody to spend a 
couple of months working solidly on this. I can put a small amount into 
the pot if anyone else wants to join in. Perhaps Jonathan, who has done 
some preparatory work on this, would be free to take it on?

It would be nice to build support for plug-in components, since this is 
how a lot of end-user software is built these days. Pop-11 would be a 
superb scripting language for this purpose, and the facility to drop 
into Prolog, Lisp, Scheme, ML, etc., as required, would add a lot of 
value. I still don't know what would be a good cross-platform component 
standard to support, although XUL is looking good.

>4.  A GNUstep binding might be a better use of time,
>since this would provide a Linux and a Mac OS
>X-compatible GUI toolset.

What about Windows? I know that the word is not popular, but I'd be 
reluctant to support any movement that chose to exclude any platform. 
One of my goals is also to try and preserve the value of what has been 
developed, (and hence, the value of the effort that has gone into the 
system), so I'd be very reluctant to see new effort put into something 
that is not supported across all platforms.

(You might point to my goals regarding COM+ support as a counter 
example, but I'm assuming that much of the work will be portable, at 
least to XPCOM, if not also some OSF/CORBA equivalent.)

[various musings]
>Good luck, either way.

Thanks.

Regards,
- -- 
Jeff

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1

iQA/AwUBQD/EVfHj+enJbeYqEQJRxACg+J/mB3UmJmX9Jch78uDdFEXfV4YAnimQ
5keT07vYoN4H8Vue+WhtqA9M
=0KVM
-----END PGP SIGNATURE-----