![]() |
Editor, I was greatly disappointed by AEleen Frisch's article in the July 2002 issue of Linux Magazine entitled "Administering a Fax Service" about HylaFAX. My first disappointment was in the fact that the author did not contact, interview, consult, or inform a single HylaFAX developer regarding the article or its publication. Consequently the article is plagued with errors, misinformed statements, and incorrect conclusions. Firstly, it appears that the author used or inspected HylaFAX version 4.1beta2 or earlier in writing the article. This version is at least three years old. There have been several code releases since then, including countless enhancements. Newer versions are widely solicited by HylaFAX.org, to which website the author even refers in the article and has me wondering if they even bothered to visit. Secondly, it appears that the author used or inspected HylaFAX on a BSD system, which seems a bit ironic considering the publication the article appears in. Even though the BSD and Linux HylaFAX installations are similar, it wouldn't surprise me to learn that some newbie got confused because of the differences of which the author did not take notice. If the author didn't use a BSD system, then they used a version highly modified from the default installation. So, considering that the article is written about a severely antiquated version of the software installed in a manner different than most readers would have, these are the errors, misinformed statements, and incorrect conclusions which I see: * The author states that RedHat ships HylaFAX with its distribution. This is incorrect. To my knowledge, RedHat, one of the few distributions that does not, has never shipped HylaFAX as part of its distribution. * The author makes repeated references to paths which are not HylaFAX defaults and which can usually vary greatly depending on how the package was installed. * The current default spool directory for HylaFAX is /var/spool/hylafax, not /var/spool/fax. The author makes repeated references to the old spool directory. * In figure one, the author gives a sendfax command example which will communicate with localhost rather than dalton.ahania.com as implied, will use the default pagesize because "na_let" is a typo for "na-let", and will omit the from and regarding coverpage information specified on the command line. * The author correctly indicates that faxgetty need not be used for send-only configurations, but this is actually the less-preferred method of establishing a send-only environment. * The author uses "fax" as the inittab id value when on many systems the id value is limited to a two-character sequence. * Although "/dev/ttyS0" would work as an argument to faxgetty, the proper way is to omit the "/dev/" prefix. This is clearly documented in the manpages and website. * The author states that "there is no utility to maintain or clean up the per-job log files", which is incorrect. Apparently they missed the faxcron utility. * The author implies that hfaxd only handles faxing from remote hosts. In truth, hfaxd handles fax job submission from all hosts, local or remote. * The author lists the document types which HylaFAX is capable of faxing by default, but omits PDF. * The author states that "HylaFAX does not have an automated method of routing faxes to recipients". This is untrue as HylaFAX is quite capable of routing incoming faxes based on CID, TSI, DID, and device. Then the author goes on to confuse the reader with a hacked-up routing method based on "the incoming phone number" which transforms into the "originating phone number" by creating an etc/users file which would go unused unless the reader were to deliberately alter bin/faxrcvd to use an etc/users file. * The author states that it "isn't usually a practical scheme" for HylaFAX to "be a central fax server that accepts fax jobs from other hosts". If this is true, then there are countless numbers of businesses and individuals who are happily and productively doing the impractical with programs and services like TPC.INT, Cypheus, WHFC, Respond, and RelayFax (which HylaFAX client programs the author didn't even bother to mention). All in all, I'm glad for the publicity which the article brings to HylaFAX. However, I feel that the author would have done better to merely condense the information available in the HylaFAX HOW-TO (http://www.hylafax.org/howto) if they didn't have the time or interest to properly research and investigate the package. Thanks, Lee Howard HylaFAX developer ____________________ HylaFAX(tm) Users Mailing List _______________________ To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi On UNIX: mail -s unsubscribe hylafax-users-request@hylafax.org < /dev/null