Re: ARIN Policy on IP-based Web Hosting

[smd () clock org (Sean Doran)]

Hm, this is vaguely about the tension in how network-friendly
to make applications...

Jim Mercer writes:

| just think how crippled make(1) would be without extensions.

Hm, let's see, in NetBSD's make(1) regime, the current sys.mk has
the declarations below.  What stops you from using a different
suffix convention than <foo>".c" and friends?  I see no reason why
make(1) couldn't be extended to deal with arbitrary prefix/infix/suffix 
identifiers, or even something complicated like a set of regexps. 

COMPILE.c?=     ${CC} ${CFLAGS} ${CPPFLAGS} -c
LINK.c?=        ${CC} ${CFLAGS} ${CPPFLAGS} ${LDFLAGS}

CXX?=           c++
CXXFLAGS?=      ${CFLAGS}
COMPILE.cc?=    ${CXX} ${CXXFLAGS} ${CPPFLAGS} -c
LINK.cc?=       ${CXX} ${CXXFLAGS} ${CPPFLAGS} ${LDFLAGS}

OBJC?=          ${CC}
OBJCFLAGS?=     ${CFLAGS}
COMPILE.m?=     ${OBJC} ${OBJCFLAGS} ${CPPFLAGS} -c
LINK.m?=        ${OBJC} ${OBJCFLAGS} ${CPPFLAGS} ${LDFLAGS}

...

# C
.c:
        ${LINK.c} -o ${.TARGET} ${.IMPSRC} ${LDLIBS}
.c.o:
        ${COMPILE.c} ${.IMPSRC}
.c.a:
        ${COMPILE.c} ${.IMPSRC}
        ${AR} ${ARFLAGS} $@ $*.o
        rm -f $*.o
.c.ln:
        ${LINT} ${LINTFLAGS} ${CPPFLAGS:M-[IDU]*} -i ${.IMPSRC}

# C++
.cc .cpp .cxx .C:
        ${LINK.cc} -o ${.TARGET} ${.IMPSRC} ${LDLIBS}
.cc.o .cpp.o .cxx.o .C.o:
        ${COMPILE.cc} ${.IMPSRC}

etc.

Finally, compared to the equivalents in, for example, the Common LISP
universe, make(1) *IS* crippled, suffix-convention or not.

The assumption many network people have that "everything is an X",
for varous values of X (endianness, VAXishness, Microsoftishness, UNIXish)
has always been a real problem, and has led to interesting problems
(e.g., taking a file froma TENEX machine, changing directories on
a VMS server).   HTTP for its sins does abstract away some of the
worst user-visible problems (e.g. do you need to care what platform
the web server is running on?)

The major problem I have with ftp, from the perspective of someone
trying to build networks, is that most clients generally do not
do passive-mode ftp by default, despite many years of harranguing
going waaaaay back to Vadim Antonov's argument for that here.

Another plug: NetBSD's ftp(1) man page says:

     epsv4       Toggle the use of the extended EPSV and EPRT commands on IPv4
                 connections; first try EPSV / EPRT, and then PASV / PORT.
                 This is enabled by default.  [with fallback to active on fail -smd]

This is, in my opinion, Doing The Right Thing.

        Sean.