Re:bag of worms...
Not a legal Eagle but MHO: Encrypt-only routines, are typically OK. Encrypt/decrypt are Atom Bomb class material. We USers do not want you, natives to be able to have secrets from us, nor the ability to have any of our citizens exchange secrets with you non-US natives (unless you bribe us, that is). So, have a password, encrypt it, do not decrypt it, but send your encrypted/decryptable messages only in DES. We can crack that. If we can get away with it, we will fobid all commoners from encrypting (unless we have the key, that is), regardless of citizenship. Before you flame me too much, the above was a twisted-humor way to say that in my humble opinion, encrypt-only is OK, and, in the US, DES is OK and if you are a big computer copmpany with a powerful loby in DC, you can do what you please. Simon P.S. Yea, Teleport.com is still silly and my senmail is still crazy, Please ignore the below address and flame [EMAIL PROTECTED] He receives and answers mail :-) Simon Shapiro Bullet Technologies, Inc. [EMAIL PROTECTED] 13130 SW Haystack St. (503) 524-6631 Beaverton, OR 97005
Re: backup software in /bin or /usr/bin ?
If my memory serves me; /sbin was originally for statically linked executables which are indeed needed for system restoration (while shlibs are none). This IS where emergency stuff should be. Check UnixWare, /bin is symlinked to /usr/bin, I think... Simon P.S. Yea, Teleport.com is still silly and my senmail is still crazy, Please ignore the below address and flame [EMAIL PROTECTED] He receives and answers mail :-) Simon Shapiro Bullet Technologies, Inc. [EMAIL PROTECTED] 13130 SW Haystack St. (503) 524-6631 Beaverton, OR 97005
Re: Bug#1962: kernel needs sbpcd.h editing in some cases
To do a complete & correct kernel configuration for all possible systems requires either M$ or SCO. Even Novell could not do it :-). Once X is up, even minimally, and sources are installed, we can add a make xconfig to allow some flexibility. To do much more, I'll have to ask you-all for help or patience. I'll get to it some day. Really. Simon P.S. Yea, Teleport.com is still silly and my senmail is still crazy, Please ignore the below address and flame [EMAIL PROTECTED] He receives and answers mail :-) Simon Shapiro Bullet Technologies, Inc. [EMAIL PROTECTED] 13130 SW Haystack St. (503) 524-6631 Beaverton, OR 97005
Bug#1969: w3-el recommends things that don't exist
What happened to netpbm. I just picked a copy from GNU. Why isn't pbmplus free? Thanx, Simon P.S. Yea, Teleport.com is still silly and my senmail is still crazy, Please ignore the below address and flame [EMAIL PROTECTED] He receives and answers mail :-) Simon Shapiro Bullet Technologies, Inc. [EMAIL PROTECTED] 13130 SW Haystack St. (503) 524-6631 Beaverton, OR 97005
Re: symlink in /usr/include (fwd)
This is fine except that it will create a lot of /usr/include traffic. I try to track Linus and that means a kernel a week or so (I am deprived Linus! 1.3.45 is OLD :-). May I suggest a link in /usr/include to /usr/src/linux/include/linux. On my system, for example, /usr/src/linux is a link to /usr/src/Kernels/1.x.yy. When i get a new kernel (say 1.3.46), all I do is (cd /usr/src/Kernels/`.3.46/linux; rm /usr/src/linux; ln -s `pwd` /usr/src/linux). All this NOT as root (as would be needed in the case of tinkering with /usr/include). Of course I may be wrong, but Simon P.S. Please ignore the below address and flame [EMAIL PROTECTED] He receives and answers mail :-) Simon Shapiro Bullet Technologies, Inc. [EMAIL PROTECTED] 13130 SW Haystack St. (503) 524-6631 Beaverton, OR 97005
Re: symlink in /usr/include (fwd)
Thanx Bruce :-) I am and I care. It took me years to learn to accept symbolic links. Now that I am used to them and find them useful you want to take them away from me?! No, seriously, I reponded already to this and say; leave them alone. They cost very little, simple for the human to resolve, hurt nobody and help me. They are ugly architectually and some very bright people have demonstrated before that you can live without them, but they are practical and convinience, in this instance, at least. Simon P.S. Please ignore the below address and flame [EMAIL PROTECTED] He receives and answers mail :-) Simon Shapiro Bullet Technologies, Inc. [EMAIL PROTECTED] 13130 SW Haystack St. (503) 524-6631 Beaverton, OR 97005
Bug#2016: SysVinit, mount] SysVinit uses non-existant option for umount
Did you check that the umount (without the -n flag) actually works? Shutting it up can be a disaster on a large system. Simon P.S. Please ignore the below address and flame [EMAIL PROTECTED] He receives and answers mail :-) Simon Shapiro Bullet Technologies, Inc. [EMAIL PROTECTED] 13130 SW Haystack St. (503) 524-6631 Beaverton, OR 97005
Re: PCMCIA support in boot kernel?
Hi Bjoern, I have been entertaining this thought. Maybe as a followup to 1.3.47 (due out tonight or tomorrow). Last I checked it barfed on 1.3.xx kernels but maybe I am wrong. I also have no way to test it as my PCMCIA adaprtor is out of the system (no slots) and my only PCMCIA devices are a modem (collides with my serial ports) and a 130MB MiniScribe disk (no support I know of). I wrote UnixWare support for the MiniScribe but am too lazy to re-write it for Linux. Any takers? I'll integrate PCMCIA support (provides it compiles correctly) and please tell me you will test it... Simon P.S. Please ignore the below address and flame [EMAIL PROTECTED] He receives and answers mail :-) Simon Shapiro Bullet Technologies, Inc. [EMAIL PROTECTED] 13130 SW Haystack St. (503) 524-6631 Beaverton, OR 97005
Re: PCMCIA support in boot kernel?
I'll try to add PCMCIA support to the follow-up release of 1.3.47. 47 is already stable and I'd rather not de-stabilize it. It will be released tonight or tomorrow. Any volunteers to check it as I have no way to test it. Also, I have a PCMCIA 130 MB disk. I have written UnixWare drivers for it. Any Linux takers? Simon P.S. Please ignore the below address and flame [EMAIL PROTECTED] He receives and answers mail :-) Simon Shapiro Bullet Technologies, Inc. [EMAIL PROTECTED] 13130 SW Haystack St. (503) 524-6631 Beaverton, OR 97005
Bug#2032: Printer stuck until the COMPUTER'S Reset button is pushed!
Does anything at all print or does everything, unider Linux fail? How is the printer hooked up? Serial/Parallel/Ethernet? I know not much about the Deskjet, but should you not process the document through some fileter? On the Laserjet, if you try to just dump raw text into the pronter it will do something strange. Call on me if you need more help... Simon P.S. Please ignore the below address and flame [EMAIL PROTECTED] He receives and answers mail :-) Simon Shapiro Bullet Technologies, Inc. [EMAIL PROTECTED] 13130 SW Haystack St. (503) 524-6631 Beaverton, OR 97005
Re: coming soon
> Isn't it just as likely that /var/log will be on a mounted filesystem? > (In fact /var is a separate filesystem on mine.) Ditto here ( and /var/spool is separate too). To be sane/safe, assume that /sbin, /lib, and /etc are all that / has at boot time. Anything else can be mounted on some mut's system. Simon P.S. Please ignore the below address and flame [EMAIL PROTECTED] He receives and answers mail :-) Simon Shapiro Bullet Technologies, Inc. [EMAIL PROTECTED] 13130 SW Haystack St. (503) 524-6631 Beaverton, OR 97005
Re: Bug#2043: genksyms
>> The 1.3.47 kernel module support >>at least expects to find it in /sbin. I ran into thesame problem before. > No, genksysm should be in /usr/bin (and the man page should probably > not be in section 8) Another way of looking at this is to check if the executable in question is statically linked. If not, put it in /usr/ /sbin things should not depend on shared libraries in /usr/lib. Some do. Simon P.S. Please ignore the below address and flame [EMAIL PROTECTED] He receives and answers mail :-) Simon Shapiro Bullet Technologies, Inc. [EMAIL PROTECTED] 13130 SW Haystack St. (503) 524-6631 Beaverton, OR 97005
Re: Debian+umsdos (fwd)
And why do we want this brain dead file system (which even M$ does not use for its own 1980 eras OS's) to boot a Unix O/S with? Simon P.S. Please ignore the below address and flame [EMAIL PROTECTED] He receives and answers mail :-) Simon Shapiro Bullet Technologies, Inc. [EMAIL PROTECTED] 13130 SW Haystack St. (503) 524-6631 Beaverton, OR 97005
Re: Bug#2032: 2036. Printer stuck #3.
My grandma used to say that you catch many more flies with honey than vinegar. > ...some dumb "problem reports system" This is really an attitude/frustration problem. I know you must be frustrated as hack by now but; I sent you a detailed list of suggestions. Free of charge. I can see that several others did the same. We do not get paid for this effort, nor do you. Without friendly cooperation we will not get anywhere. Looks to me that your system problems get boiled down to a stubborn printer relationships (we are over the ``line printer'' issue. Right?). I repeat my offer to save you the time and patience reading a Unix introduction and explain to you the mechanics of what we are trying to accomplish here, but you have to be interested in that explanation first. I could try and guess what is wron with your system, why the printer gets stuck, etc. But you have to be willing to be helped. If your purpose is to bitch Linux/Debian out, then my time is better served elsewhere. Let my just point out to you that: A. The Debian project is underfunded about 1Billion:1 compared with M$. B. We produce upgrades and updates at the rate of 2-5 packages per day. About 100-200 times better than M$ could ever do. C. New O/S kernels are produced about 1-2/month, about 25 times faster than M$ could ever do. D. The response time to your problem was measured in minutes. You received help that is worth about $300 when purchsed from M$, over $1,000 in value. E. Unlike M$, no one owes you anything. just a friendly obligation of honor to help a fellow man in time of need. So, A glass of ice-water, a deep breath and call me at home tonight. I'll get you going. If I can. Simon (503).524.6631 or 579-4119 Simon P.S. Please ignore the below address and flame [EMAIL PROTECTED] He receives and answers mail :-) Simon Shapiro Bullet Technologies, Inc. [EMAIL PROTECTED] 13130 SW Haystack St. (503) 524-6631 Beaverton, OR 97005
Bug#2036: Printer stuck #2.
Please, do not be offended but an introductory book to Unix may help you here (to a degree). > 1. I didn't have lp installed since the installation parameter screen > for this said "line printer", not just "printer". ``Line printer'' is as valid in Linux as a ``tty'' device name. We do not have line printers, nor teletype machines for quite a while. We call any directly connected printer a line printer and any character oriented terminal a ``tty''. Just a name, you see. Enable your line printer. It's OK. > 2. I ran: insmod lp > the result: > Module:#pages: Used by: > lp 2 This is good. The kernel accepted the ``line printer'' module and allocated 8K of memory to it. Once this is successful, do NOT run any other mod utilities, mentioning the lp name again. I have it done at boot time and forget it from then. The only time it may be useful is if you want another device (not a printer) hooked up to the parallel port (this is where your printer is connected. Right?). > 3. lsmod >/dev/lp0 > returns: "bash: /dev/lp0: No such device" > and I was logged in as root, too. What you are trying to do here is to list all kernel loadable modules and send the output of this listing to the printer. Why? The printer does not work properly yet. Also, run ls -l /dev/lp*. See what it tells you. It should look something like: crw-rw 1 root daemon 6, 0 Apr 27 1995 /dev/lp0 crw-rw 1 root daemon 6, 1 Apr 27 1995 /dev/lp1 crw-rw 1 root daemon 6, 2 Apr 27 1995 /dev/lp2 If it does not, this means that you do not have `device entries'' for the line printer. Do this: cd /dev sh ./MAKEDEV lp if this barks, you can do /bin/mknod /dev/lp0 c 6 0 /bin/mknod /dev/lp1 c 6 1 /bin/mknod /dev/lp2 c 6 2 /bin/chown root.daemon /dev/lp* /bin/chmod 660 /dev/lp* Which is really the same thing. > 4. Additionally, I had forgotten to mention that the Print Screen button on this >key board works with MS-DOS, but NEVER with Debian yet. (A real pain for a > Linux novice trying to work around this bug by copying various help and data > screens down by HAND! Especially during installation.) You are right in your observation that this button does not work in Linux line M$-DOS does but wrong in your conclusions. There is a package (Debian or not) called gpm. You can get it from sunsite someplace, or tsx-11 or many others. What it does is enable the mouse to cut and paste on your ``tty'' screen. If you then use, say vi, for editing or any mail program, you can cut the text you want, start your editor, in insert mode, and paste the text you cut. You can even have the editor on one virtual console and the program on another. (You switch consoles by doing ctl-alt-f[1-7]. So 1st cosole is ctl-alt-F1, 2nd in ctl-alt-F2, etc. Try this in DOS :-). This allows you to not just print the screen to a (not yet functional printer :-) but even mail it to bozos like me. Directly. Linux in general, and Debian as well do not pretend to reduce a computer to a toaster level. Even toasters come with instructions and warnings. Did you try recently to program a VCR? What frustrates you is the unfamiliar teritory. Linux is really a Unix operating system, not a DOS extentions. As such it is geared towards multi-user, multi devices, great flexibility in configuration, etc. Not towards compatability with DOS. Rest assured that Linux (and Debian as a distribution/packaging method) is capable of printing on your printer. Just be patient and count your blessings you do not have to work/use an NT system. Try to get a M$ engineer to give you as much time as others and myself give you. (They charge you, ahead of time $150/hour and will NOT give you this level of service, either). If you need more help, please call on me. Even voice. I'll try to help. Simon P.S. Please ignore the below address and flame [EMAIL PROTECTED] He receives and answers mail :-) Simon Shapiro Bullet Technologies, Inc. [EMAIL PROTECTED] 13130 SW Haystack St. (503) 524-6631 Beaverton, OR 97005
Linux Kernel 1.3.47 Uploaded
Hi to all, I uploaded kernel 1.3.47 to ftp.debian.org in /debian/private/project/Incoming. In addition to the .changes, I should also mention the following: 1. Some of the compilation is different than what Bruce has done. Let me know where the smoke comes from. 2. I'd like to throw away the 387 emulation for the compiled kernel. Anyone knows why I should keep it there? I do not believe it to be necessary for the installation, but i have been wrong before. 3. There is no PCMCIA support. If someone will help me in Debianizing the package, I'll maintain it and distribute it with the kernel (same package or separate? - Polite opinions please). 4. Ditto for the MD package, 5. Ditto for kerneld 6. Ditto for userfs In few short weeks I'll be adding even more support for the Debian project. Stay tuned, 1.3.48 will be coming later this week or next week. Promises to fix the SCSi race conditions, etc. Date: 20 Dec 95 02:24 UT Source: kernel-source Binary: image includes source Version: 1.3.47-0 Description: image: Linux kernel binary image. includes: Linux kernel headers. source: Linux kernel source. This is patch level 47 of Linux kernel version 1.3. As this is my first relese of a Debian package, I am sure I could do better. For example, the diff file is messed up. Please let me know how I can improve it... Priority: Low Changes: Includes md (Linux RAID support) 0.32 kernel code. The utilities needed are not included here. If someone wants to help me package them, I'll maintain the package. I am using MD on a daily basis and it runs great! The apricot Ethernet driver is too buggy to even remotely compile. It is disabled. I contacted the author (?) but no answer yet. Any volunteers to fix it are welcome. The drivers/scsi/hosts.c is slightly different than Linus's. I moved eata_dma to the top of the list, followed by BusLogic. This way those of you who have these controllers (I have both in nomis) will have them take /dev/sda, etc. I encountered the following problems with this release: a. Under load the SCSI system will bark but it appears harmless. b. X looses the mouse (some buttons). Switch to VC 1 and back will get you the buttons. c. If you have all-SCSI disks but IDE CD-ROM, expect lilo to fail; It will appear normal but upon boot it will report error 0x00 and will refuse to boot anything. Work around? Build a kernel without any IDE support, put it on a floppy, boot rom it with mount=/dev/sda1, run lilo and all will be well. until the next kernel build/lilo. Any takers? Files: -rw-r--r-- 1 Source Source3627753 Dec 19 18:23 kernel-source-1.3.47-0.tar.gz -rw-r--r-- 1 Source Source 20 Dec 19 18:17 kernel-source-1.3.47-0.diff.gz -rw-r--r-- 1 root root 1403071 Dec 15 20:43 image-1.3.47-0.deb -rw-r--r-- 1 root root 470893 Dec 15 18:50 includes-1.3.47-0.deb -rw-r--r-- 1 root root 3603358 Dec 15 18:50 source-1.3.47-0.deb 185ebe3c08728e87852003549abf2deb kernel-source-1.3.47-0.tar.gz 7a83dd7ad504f27d539b938e7001f89a kernel-source-1.3.47-0.diff.gz ad485341f80fc5ba41283d0bb7781016 image-1.3.47-0.deb 9f532e8fd08cdf40bb6fe26add0acf86 includes-1.3.47-0.deb 04947c1aa85fd06303664db21333c406 source-1.3.47-0.deb Simon P.S. Please ignore the below address and flame [EMAIL PROTECTED] He receives and answers mail :-) Simon Shapiro Bullet Technologies, Inc. [EMAIL PROTECTED] 13130 SW Haystack St. (503) 524-6631 Beaverton, OR 97005
Re: Debian+umsdos (fwd)
OK! I submit. I was wrong. FAT is great for loading and booting floppies. I still maintain that it is a disaster for any serious OS as a storage medium. Even when we fake users and permissions. I am stubborn in a way :-) Simon P.S. Please ignore the below address and flame [EMAIL PROTECTED] He receives and answers mail :-) Simon Shapiro Bullet Technologies, Inc. [EMAIL PROTECTED] 13130 SW Haystack St. (503) 524-6631 Beaverton, OR 97005
Re: Linux Kernel 1.3.47 Uploaded
OK! 387 emulation is in. I received at least three convincing arguments. It just seems silly to have FPU code in things that do not actually need it. I use 486 and Pentiums, so I never paid any attention. Lesson learned, thank you all. Marry Christmas! Simon P.S. Please ignore the below address and flame [EMAIL PROTECTED] He receives and answers mail :-) Simon Shapiro Bullet Technologies, Inc. [EMAIL PROTECTED] 13130 SW Haystack St. (503) 524-6631 Beaverton, OR 97005
Re: Bug#2063: scsi driver sequence unreasonable
> The file drivers/scsi/hosts.c defines the sequence in which different SCSI > controller cards are identified. The AHA152X driver appears early in the list, > which is unreasonable if there is another, smarter, SCSI controller in the > system... since it will result in the 1510/1522/1522/etc card assuming the role > of the 0th SCSI channel. You are right, of course. I changed it in 1.3.47 and the DPT (has NOTHING to do with the AHA drivers) and the Buslogic are at the top. What other AHA-compatible do we have that should move? I a mopen for suggestions. Besides, with the nice support that Adaptec gives Linux users we should really re-locate the drivers to /dev/null anyway, but the Linux developer supporting these things IS a nice guy, so... Merry Christmas! Simon P.S. Please ignore the below address and flame [EMAIL PROTECTED] He receives and answers mail :-) Simon Shapiro Bullet Technologies, Inc. [EMAIL PROTECTED] 13130 SW Haystack St. (503) 524-6631 Beaverton, OR 97005
Bug#2065: single user isn't
Hi There, > This caused me considerable grief when one of the disks on my system was starting to fail, and I was desperately trying to extract a few critical files that had been updated since the last backup. The cycle was to boot, snag a few files before the disk warmed up and failed, then power down to let things cool off, then repeat. The insistence of the system on doing fsck's at every boot made this a much less productive process per unit time than it could/should have been. Re-booting from a floppy could have saved you some grief. A can of compressed air or highly purified alcohol in a spray bottle (and proper ventilation!) could have cooled the drive enough to do things a little quicker. An ice pack is something I used to use (Wrapped in some paper towels to absorm moisture). On your point, oc cource you are right! Single user mode should be as DO$ as we can get it. Simon P.S. Please ignore the below address and flame [EMAIL PROTECTED] He receives and answers mail :-) Simon Shapiro Bullet Technologies, Inc. [EMAIL PROTECTED] 13130 SW Haystack St. (503) 524-6631 Beaverton, OR 97005
Bug#2066: error opening terminal : linux
Hi, Can you (provides you still have thisproblem :-), try and identify which executable does that? (strace may help...) Simon P.S. Please ignore the below address and flame [EMAIL PROTECTED] He receives and answers mail :-) Simon Shapiro Bullet Technologies, Inc. [EMAIL PROTECTED] 13130 SW Haystack St. (503) 524-6631 Beaverton, OR 97005
Re: Bug#2063: scsi driver sequence unreasonable
Hi Jeff, > IMHO, the fewer changes between Debian's kernels and the upstream > ones, the better... You are right. I introduce almost no changes at all, except as I feel necessary or very beneficial. Even then, I restrict changes to common and available patches. Linus has a focus and a set of goals in releasing 1.3 patches, which I fully support (most of the time, anyway :-). We need to support a more ``bread & butter'' user community and this is where I may introduce few things. If they break anything, please let me know and I will fix them or back off the change. > I don't see why we should move any of them. They're arranged in the > order they are in for two reasons: 1) to prevent probing problems (i.e. > BusLogic must come before Adaptec 154x), and 2) to allow the more > popular and/or problematic cards to come first. I think many of us understand why the SCSi drivers are arranged as they are. The logic is correct but the listing order is not always so. The BusLogic case is a good example. In moving the eata_dma, for example, I followed a slightly differet logic (?): Since it is a unique driver, it really does not matter where in hosts.c it is defined. The reason to move it was that most users, when having a smart/expensive controller want to have it used for booting and for the root file system. I think the real solution lies elsewhere; I am developing a configuration tool which will allow us to choose the order of the devices without editing hosts.c. It may take some time to surface and you may beat me to it, but that's OK. > It doesn't really matter if a 152X gets detected before a high-power > whiz-bang SCSI-matic 2010 PCI adapter, because you can still put root > on any SCSI controller you like. You are right. My own machine had root on /dev/sde2 for the longest time. I moved it as many users, during first installation do not realize it. If it is very opjectionable, I could be convinced to move it back, but then i will have to ship an untested kernel. I hate to do that! > If there is a _really_ good reason to change the probe order, we should > discuss it on the kernel and scsi channels, and get it changed in the > upstream source. You are right. I am collecting opinions on what the order should be and once my office move is over, will start the action as you suggest it. > Adaptec provides free programming information on the 154X and 174X series, > as well as the AIC-6X60 chips (152X), so be nice... I'm not thrilled with > their policy on current products, but they're still excellent products. :) I think they have not made up their mind as to what they want to do when they grow up. An OEM chip vendor or a PC card vendor. They created so much noise and confision with so many incompatible cards and products. I have a 2940W in ``as new'' condition. Any offers? They are excellent cards :-) Happy new year P.S. Lets not turn it into a flaming war of my card is better than your card. Besides, thereis a company (in Colorado? Forgot their name) which makes a FCAL card. Does about 85 MB/Sec and can take up to 256 drives. Now try & beat that! Simon P.S. Please ignore the below address and flame [EMAIL PROTECTED] He receives and answers mail :-) Simon Shapiro Bullet Technologies, Inc. [EMAIL PROTECTED] 13130 SW Haystack St. (503) 524-6631 Beaverton, OR 97005
Re: Bug#2063: scsi driver sequence unreasonable
Hi Bdale, > I'm not going to get upset no matter what Simon decides to do, because I > suspect I'll be building custom kernels for most of my machines no matter > what, but I wanted to make sure that the "silliness" of the current approach > in my eyes got registered someewhere and fed back upstream. Agree. I need some feedback on this issue: How many people never compile their kernel and why? There are many good reasons to DO compile your own kernel and very few I know of not to. If needed, I am willing to attempt writing a short and simple description of the process and answer any questions that pop up. If it were up to me, the only use of the image package should be for creating boot floppies. Again, I could expand on it if interest warrants it. Happy New Year to you all! Simon P.S. Please ignore the below address and flame [EMAIL PROTECTED] He receives and answers mail :-) Simon Shapiro Bullet Technologies, Inc. [EMAIL PROTECTED] 13130 SW Haystack St. (503) 524-6631 Beaverton, OR 97005
Re: Unanswered problem reports by maintainer
> The US debian-bugs mirror seems to be fairing worse than normal... What?! A bug in the bug reporting system? A bug in a bug. :-) Still beats M$ bug reporting system. When they do not charge you to take the bug report ($150/hour, Visa/MC, in advance, please), they still respond just as slow. [ This is NOT to bash M$. Theirs is a fine and noble corporation. While Novell owned Unix, they did even worse. You could not even pay for such service! ] We are doing fine Ladies and Gentlemen! Happy New Year! Simon P.S. Please ignore the below address and flame [EMAIL PROTECTED] He receives and answers mail :-) Simon Shapiro Bullet Technologies, Inc. [EMAIL PROTECTED] 13130 SW Haystack St. (503) 524-6631 Beaverton, OR 97005
