Re: ARIN Policy on IP-based Web Hosting
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.
On Thu, 31 Aug 2000, Sean Doran wrote:
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.
It's gets worse. At least as far as I can tell, the built in command line ftp that comes with Win 2000 doesn't support passive mode at all. That's quite frustrating. Of course I accept the answer, don't use Windoze, but unfortunately the corporate types don't. Brandon Ross 404-522-5400 EVP Engineering, NetRail http://www.netrail.net AIM: BrandonNR ICQ: 2269442 Read RFC 2644!
participants (2)
-
Brandon Ross
-
smd@clock.org