The Boston Diaries

Wednesday, April 12, 2000

The Bogus Paper Trail

Just had a conversation with Mark over documentation, or rather, the lack of documentation in our industry.

I thought companies didn't document their products (say, a hardware device for a computer) for one of two lame reasons:

“It'll give our competition an insight into how we did things and therefore they'll steal our R&D from underneath us.”
Their hardware is so crappy they don't want anyone to know just how bad it really is.

But the primary reason, so according to Mark, is that the companies are afraid of releasing the documentation because most of it is incomplete, inaccurate or just doesn't exist to begin with.

And forget trying to get documentation from programmers or engineers—they'll either quit and go elsewhere (where they don't have to document) or what they write will be so horrible that no one actually uses it (which is pretty much status quo from what I understand).

Or, even if the company can release the documentation, it does no good because chances are good that they used products from other companies that don't document what they did, or don't release documentation, or don't release documentation without a thick layer of NDAs to CYA.

So the next time you get that chip from Intel for your next hardware project? Just toss the documentation—it's totally bogus anyway.

Just don't ask about the next bridge you drive over.

invoices

I finally got around to printing an invoice for Atlantic Internet. It's a rather involved process printing out an invoice, but it's not the software that's the problem.

It's the hardware. Or rather, the lack of space for said hardware.

I use an old MS-DOS box for printing of invoices. Nothing difficult, just copy over a template file (which is nothing more than a text file), fill in the columns using a text editor, save then print to a dot matrix printer. The problem is I have no space left for the system so it's been sitting in my bedroom on the floor, waiting for the time I get around to putting it somewhere.

But I needed to print this invoice and the Computer Room is full. Well, not as full as it was, but now that it's orgranized I'd like to keep it that way.

I could hook the printer up to the Linux box, but Unix and peripherals don't mix. Or rather, don't mix well. I don't have an exotic printer. It's dot-matrix. Schlep ASCII out the parallel port and it'll print. But Unix weenies have to make something simple overly complex with half a dozen configuration files (none of which are similar, and don't even get me started on adding a modem to Unix).

Well, that and I never bothered to install the printer subsystem on Linux since I don't use the printer all that often. Last time I dug it out it was early February (when it and the MS-DOS computer were in the Computer Room).

So I quickly set up the computer in the bedroom, printed out the one page I needed, and broke everything down again.

Now I just need to submit the invoice.

So you wanna add a modem to Linux?

Friends that know me know that I tend to get very frustrated when things I think should be simple, or at least straight forward, aren't. This is especially noticible with respect to computers.

And it's one of the reasons I haven't bother to set up printer support under Linux (or Unix in general). Unix weenies chant “Simple. Simple. Simple,” but what they do is “Complex. Complex. Incomprehensible.” I'll take the case of modems under Linux, since I have more than my share of experience with what normally should be rather simple and painless.

Situation: Hook two Linux systems together via modem. Mark and I have done this several times over the years and every time it takes several hours to get it working. The first time it took like 16 hours, but that's because we wasted 12 hours on a core-dumping uugetty (that we didn't know was dumping core).

Plug modem into computer. Even if it's an internal modem and you have to open the system and shove a card in, this is the simple step. But because of the PC hardware you have to make sure you don't have IRQ conflicts, but let's assume you don't. Plug the modem in.
Figure out which port the modem is plugged into. Again, this should be simple and in fact, these two steps are the same reguardless if you are using MS-DOS, Windows, or Linux.
Now figure out if you need to use /dev/cua* or /dev/ttyS*, but it depends upon the Linux kernel you are using. One if for dialing in, one for dialing out, but in a pinch I think you can use either as long as you don't try to have one program answering the phone and another one trying to make an outgoing call.

For you see, while both /dev/cua* and /dev/ttyS* use the same driver, they have slightly different semantics when opening them up for use and I can never rember what those semantics are (but hey, this is Linux, I can check the source code) or which device is for dialing in or dialing out.

But the newer Linux kernels (starting with 2.0? 2.2?) have removed that annoying aspect, thus annoying a bunch of package maintainers who content that Linux was doing the Right Thing and this new way of doing things is the Wrong Way.

See what I mean? And we haven't even gotten the computer and modem talking yet!
Select which getty program you'll be using. mingetty is only used for virtual terminals, but that still leaves:
- mgetty
- uugetty
- getty
- agetty
- mgetty
Don't worry, they're all equally bad. We always ended up using uugetty.
Figure out what configuration file it wants. Usually you think the man page would tell you, but I've found that it's best to grep through the executable for potential configuration file names.
Write the configuration file. Since we're using Hayes compatible modems, the following configuration file for uugetty seems to work:
```
TIMEOUT=60
INIT="" \d+++\dAT\r OK\r\n ATZ\r
WAITFOR=RING
CONNECT="" ATA\r CONNECT\s\A
DELAY=1
```
The INIT and CONNECT lines are commonly called “chat scripts.” The format is a series of pairs, one string for what to expect as input, the next what to send for output. Notice that if something unexpected comes up you can't do anything about it. Or maybe you can. Best to check the source code.
Next, add an entry to /etc/inittab for uugetty. What I have is:
```
S1:2345:respawn:/sbin/uugetty ttyS1 F57600
```
The first paramter to uugetty is what device entry to use, minus the /dev part. The second is an entry out of /etc/gettydefs—don't edit this file! For a modem you pretty much want a fixed-baud modem entry, one that is faster than your modem supports since most modems these days can do on the fly compression.
Next, you need to configure the PPP daemon. Under Linux the file you want to edit is /etc/ppp/options. There are a slew of options to configure and through plug-n-pray, Mark and I got the following working:
```
-pap
-chap
crtscts
deflate 15,15
bsdcomp 15,15
netmask 255.255.255.240		#replace with your netmask
10.0.0.3:10.0.0.18	#replace with local IP, remote IP
modem
passive
-am
ipcp-accept-local
ipcp-accept-remote
mru	552
mtu	552
asyncmap 0
```
You also need to configure /etc/ppp/ip-up.local with the appropriate routing information. This is a shell script, not a configuration file. Through experimentation, I've found that the shell script has the following parameters:
1. interface name
2. tty device
3. speed
4. local IP address
5. remote IP address
6. extra param—not sure what it's for
So in this file, I add some commands to get the routing done:
```
/sbin/route add -net 208.26.72.16 netmask 255.255.255.240 dw $4
/sbin/route del $5
```
You don't need the route for the one IP address so it can be removed safely.
Add a user to the passwd file who has a shell of /usr/sbin/pppd so the other side can log in and establish a PPP connection.

And you're done.

Oh, I forgot to mention, that's only for one half the connection—the one that is accepting incoming calls. Doing the other side is similar but I think I got my point across—this is insane.

Now, for a printer …/p>

Wednesday, April 12, 2000

The Bogus Paper Trail

invoices

So you wanna add a modem to Linux?

Obligatory Picture

Obligatory Contact Info

Obligatory Feeds

Obligatory Links

Obligatory Miscellaneous

Obligatory AI Disclaimer