lynx-dev
[Top][All Lists]
Advanced

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

LYNX-DEV On the feasibility of booting pure BSD and other stuff


From: Michael Sokolov
Subject: LYNX-DEV On the feasibility of booting pure BSD and other stuff
Date: Fri, 30 May 1997 17:48:14 -0400 (EDT)

   Bela Lubkin and some other people have said that I'd never be able get
the pure 4.4BSD to boot... Well, if you think so, read further. As I have
said before, since pure 4.4BSD doesn't ship pre-compiled for i386, I have
to first install some other system like FreeBSD and construct a cross-
compilation environment. Well, installing FreeBSD was such a pain in the
<bodypart> that I doubt that installing any other UNIX system can be
harder.
   While fighting the FreeBSD installation program, I have realized an
important point. I customarily make the distinction between (IMHO) Good
Unices and Bad Unices. Well, I used to call them West Coast Unices and East
Coast Unices. Now I realize that the difference is really not in the coast
but in the attitude taken by the developers of the UNIX system in question.
I now realize that there are two great schools of thought: fundamentalists
and deviationists. Fundamentalists believe in ONE SINGLE SYSTEM which comes
from a single author and is absolutely pure and coherent. Their only
criterion of quality is closeness to some ideal. Note that "pure" doesn't
mean "pure BSD": one can be just as fundamentalist about System V as one
can be about BSD. Deviationists, on the other hand, tweak a system in any
way they like without any feelings of patriotism.
   Robert Bonomi <address@hidden> writes:
>Even with BSD-derived systems, there are *GROSS*INCONSISTANCIES* as far as
>location of header files, and which headers certain symbols are defined
>in.
   Bela Lubkin <address@hidden> writes:
>Yeah, that's nice, except that it is PURE NONSENSE.  Lots of extant Unix
>systems are based on SVR3.x (AIX, HP-UX, A/UX, SCO OpenServer); one is
>based on OSF/1 (Digital UNIX); the largest family of all is genetically
>unrelated (Linux).  Even the SVR4-derived targets in Lynx's Makefile
>differ -- "svr4:", "unixware:" and "solaris2:" are all sufficiently
>incompatible to require their own entries.
   These are examples of deviationism. It's only because of the latter that
the header file headache proliferates. If there were a law making only one
UNIX system legal and banning the rest, software development would be two
orders of magnitude easier. All paths would be known by heart, as well as
all symbols, system calls, and workarounds for problems, if any.
   As for the autoconfigure script in Lynx, it's obviously directed toward
deviationists. The latter have wild variations in their setups which don't
follow a predefined pattern and thus require an autoconfigure script.
Fundamentalists, on the other hand, don't need that. In a fundamentalist
system, not a single line has changed in the past ten years. There are no
local system-to-system variations, since a fundamentalist follows the
system installation and administration guide line-by-line. Any
fundamentalist would be much more happy with a static Makefile than with an
autoconfigure script. With a static Makefile, a fundamentalist checks the
target for correctness and purity once, and if it passes the checks, he/she
is assured for the rest of his/her life that it will stay pure, since a
static target never changes. An autoconfigure script, on the other hand, is
always changing, and one can never be assured that it stays pure in the
next release.
   It has been said on this list that a serious problem with the static
Makefile is the division between the standard curses, ncurses, and slang,
and possible between old and new BIND. However, keeping the static Makefile
doesn't mean keeping all that stuff. As I have said before, the static
Makefile is for fundamentalists. The latter don't need this division, since
by definition a fundamentalist would never use ncurses, slang, new BIND, or
other deviationist elements. A person who wants these amenities is a
deviationist and should use the autoconfigure script.
   Moreover, the autoconfigure script is too unpredictable and
uncontrollable. Here is an example. Let's assume a certain function can be
performed in two ways on a single system. For instance, on my current
temporary FreeBSD system makefile includes can be done using both 4.4BSD
and System V/POSIX/GNU semantics. As I was told, the autoconfigure script
doesn't have political leanings. Not quite. When both are available, like
in this case, it chooses the System V/POSIX/GNU semantics, while I want the
4.4BSD one. At any rate, the autoconfigure script never gives the user a
choice, and always makes the choice by its own criteria which may not match
those of the user. A static Makefile, on the other hand, lets the user see
all available options and choose one according to his/her preferences and
political leanings. Yes, you can tweak the makefile produced by the script.
But that makefile is not optimized for tweaking, which makes the latter
operation much harder. The script produces not only a makefile, but also a
header file, and both are very cumbersome. Contrast this to the static
Makefile with verbose comments, clearly explained options, and guidelines.
   Bela Lubkin <address@hidden> writes:
>  1. HAVE YOU RUN the configure script (`./configure; make -f makefile
>     generic`) and tested the results?
>
>  2. If so, and if the results were unsatisfactory, exactly WHAT WAS
>     WRONG?
   Yes, I have looked at the files produced by the script and they looked
sort of right except for the political issues noted above. Let me repeat my
main point. The issue is not to make a satisfactory executable. Both ways
(the static Makefile and the autoconfigure script) do an equally great job
at that trivial operation. The real issue is to let users build executables
that not only run correctly, but also satisfy their political preferences.
All other things being equal, the static Makefile has this advantage, while
the autoconfigure script doesn't. This means that the static Makefile is
better and must be retained.
   Look at the issue this way. I have been told on this list that the
autoconfigure script is a work in progress. Assuming that the next full
release of Lynx isn't coming any soon, it will continue to be a work in
progress for a long time. Therefore, the static Makefile will be needed for
the same long time. Or, from another perspective, if you are deprecating
the Makefile, you shouldn't care what targets it contains. All other things
being equal, my proposed 4.4BSD target is better than the current (IMHO)
broken BSDI target, and therefore you should make the change.
   Having gained some experience with my current temporary FreeBSD system,
I have learned that my 4.4BSD target works not only with pure 4.4BSD and
BSDI, but also with FreeBSD. Also, in my very first posting, I have
included an uuencoded Makefile. In that file, lines ended with CRLFs rather
than with NLs. With these two considerations, I'm resubmitting a revised
version of my 4.4BSD target.
   Here it is:
   
4.4BSD:
        @echo "You must first compile the WWW library in WWW/Library"
        cd WWW/Library/4.4BSD; $(MAKE) LYFLAGS="$(SITE_LYDEFS)"
        cd src; $(MAKE) all CC="cc" MCFLAGS="-O -DUNIX -DNO_CUSERID \
                -DNO_KEYPAD -I../$(WWWINC) $(SITE_DEFS)" \
                LIBS="-lcurses -ltermcap \
                $(WAISLIB) $(SOCKSLIB) $(SITE_LIBS)" \
                WWWLIB="../WWW/Library/4.4BSD/libwww.a"
   
   I think the best place to put this is right before the current FreeBSD
targets. Yes, I only have 4.4BSD, no 4.4BSD-ncurses or 4.4BSD-slang, since
I don't know anything about ncurses or slang. For this reason, the old
(broken) BSDI targets would have to be kept for a while. Alternatively,
given my arguments above, the ncurses and slang targets may not be
necessary at all.
   Also the comments in the all: target should be adjusted. Find the
following fragment in the main Makefile:
   
        @echo "bsdi       -- BSD Interactive"
        @echo "bsdi-ncurses -- BSD/OS(v2.0 or later) using ncurses(v1.9.4 or 
later) package."
        @echo "bsdi-slang -- BSD/OS(v2.0 or later) using the slang package."
   
   and replace it with:
   
        @echo "4.4BSD     -- pure 4.4BSD or close (tested on BSDI v2.1 and 
FreeBSD v2.2)"
        @echo "bsdi       -- Broken, use 4.4BSD instead"
        @echo "bsdi-ncurses -- Broken, but no alternative for now (contrib 
welcome)"
        @echo "bsdi-slang -- Broken, but no alternative for now (contrib 
welcome)"
   
   Also a new subdirectory should be created under WWW/Library. Call it
4.4BSD and put a Makefile in there. I have enclosed the correct Makefile at
the end of this message. I have uuencoded it to make sure it doesn't get
altered by the E-mail system (this time lines end with NLs). To extract it,
save this message into a file and run uudecode on that file. You will get a
file named Makefile.
   Also I'm currently investigating another BSD issue that will eventually
(actually soon) lead to an improvement in BSD support (for details, see my
next posting about curses). I will probably be able to find some options
for Lynx that will improve its support for BSD curses, but will be settable
only through the static Makefile.
   
   Sincerely,
   Michael Sokolov
   Phone: 216-646-1864
   ARPA Internet SMTP mail: address@hidden
   
   Enclosure: uuencoded Makefile:

begin 644 Makefile
M(address@hidden<@=6YD97(@-"XT0E-$"B,*"B,@1F]R(%<S(&1I<W1R:6)U
M=&EO;BP@;6%C:&EN92!T>7!E(&9O<B!S=6)D:7)E8W1O<FEE<PI75U=?34%#
M2"`](#0N-$)31`H*(R!4:&address@hidden)4R!R97!O<VET;W)Y)W,@;F%M92!F;W(@
M=&AE(&UA8VAI;address@hidden@87)E(&]N"D%325-?34%#2"`](&AA<F1W87)E+S0N
M-$)31`H*"D-&3$%'4R`K/2`M1$1%0E5'"DQ&3$%'4R`]"@HC($1I<F5C=&]R
M>2!F;W(@:6YS=&%L;&5D(&)I;F%R>3H*0DE.1$E2(address@hidden<B]L;V-A;"]B
M:6X*"B,@5VAE<F4@:7,@=&AE(%<S(&]B:F5C="!L:6)R87)Y('1O(&)E(&EN
M<W1A;&QE9"`H;F]T(&YO<FUA;&QY(&1O;F4I/PI,24)$25(@/2`D*%=75RDO
M3&EB<F%R>2]);7!L96UE;G1A=&EO;B\D*%=75U]-04-(*0H*(U]?7U]?7U]?
M7U]?7U]?7U]?($]+(&EF(&YO<FUA;"!7,R!D:7-T<FEB=71I;VX*(R!7:&5R
M92!I<R!T:&address@hidden('-O=7)C92!R;V]T/PI75U<@/address@hidden(address@hidden
M<F4@<VAO=6QD('1E;7!O<F%R>2`H;V)J96-T*2!F:6QE<R!G;S\*5U1-4"`]
M("XN+RXN"@HN:6YC;'5D92`B)"A75U<I+TQI8G)A<GDO26UP;&5M96YT871I
3;VXO0V]M;6]N36%K969I;&4B"BA7
`
end
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;

reply via email to

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