grendel@sumax.seattleu.edu (Grendel) (02/05/91)
Has anyone ported a decent BBS program to Minix lately or at all? Has anyone ported RFmail? ==================================================================== = Grendel, sysop of The Sacred Grove = +1 206 634 1980 = = Fred's Citadel v.036 = UUCP Address: pagan.UUCP = = Waffle v.1.63 = = = An Open Forum for Discussing Wicca, Paganism, and Magick = ====================================================================
mgallagh@uhasun.hartford.edu (Michael Gallagher) (02/08/91)
In article <ymXVw2w164w@halcyon.uucp>, halcyon!grendel@sumax.seattleu.edu (Grendel) had queried: : > Has anyone ported a decent BBS program to Minix lately or at all? Has > anyone ported RFmail? > Well, one of the reasons I'm looking to the purchase of Minix is putting it on a '386 system & running a Unix-BBS from it. However, a friend of mine mentioned that he recalls part of the 'licensing agreement' is not to use it for 'public access', i.e. you aren't supposed to use it for such, or offering shell access [although that -doesn't- mean giving copies of any of the sources/binaries], etc. Only 'in-house' use, etc. Can anyone tell me if any of that is true?? If MINIX is my OS, does this mean I can't run a BBS under it, or allow people shell-access? It's not like I'd even want to allow anyone to copy the source-files or binaries..... So far everything I've seen of MINIX has lead me towards it as an OS of choice for an ibm [sco xenix ain't bad either, but mucho $$$$]. I hope silly technicalities won't be a bother so hence I ask here. -mg
waltje@minixug.mugnet.org (Fred 'The Rebel' van Kempen) (02/11/91)
In article <471@ultrix.uhasun.hartford.edu>, mgallagh@uhasun.hartford.edu (Michael Gallagher) wrote: > mentioned that he recalls part of the 'licensing agreement' is not to > use it for 'public access', i.e. you aren't supposed to use it for such, or > offering shell access [although that -doesn't- mean giving copies of any > of the sources/binaries], etc. Only 'in-house' use, etc. > > Can anyone tell me if any of that is true?? If MINIX is my OS, does this > mean I can't run a BBS under it, or allow people shell-access? It's not > like I'd even want to allow anyone to copy the source-files or binaries..... You can use MINIX as a _real_ OS, if you want to do so. I myself am running a quite large number of MINIX machines here, four of which are (more or less) public access (i.e. the "minixug" machine). The _only_ think you should be careful with are the downloading capabilities. Prentice Hall does NOT allow you to make the system sources availble for public access. So, on your PA MINIX system, make sure to put the sources in a very protected sub-tree (e.g. on a separate partition), or not at all. Second, be very careful with the C compiler. That is the second (c) part of MINIX. I think PA MINIX systems do not need a C compiler, so you can just simply wipe it off, or install one of the freely distributable compilers we have for MINIX (bcc, c386, gcc). > So far everything I've seen of MINIX has lead me towards it as an OS of choice > for an ibm [sco xenix ain't bad either, but mucho $$$$]. I hope silly > technicalities won't be a bother so hence I ask here. The only thing is serial driver performance... I have two fast modems connected to this machine (one 1200-4800bps MNP5 and one Telebit Trailblazer) and the driver cannot hack it... To get reasonable performance, you should: 1. Install NS16550 UARTs with a 16-byte FIFO. That saves a lot of interrupts, and thus a lot of overhead. 2. Rewrite the serial driver to operate in "block" mode. Currently, the driver processes only one character per interrupt, which is a waste of time on FIFOs (an interrupt means that there could be a complete buffer ready!). So, when a RECV DATA RDY is being processed, the driver should: - accumulate all characters from the UART in a private buffer by reading the UARTs data register until the bit drops. - call a tty_blk_in() function that processes the entire block in one piece When a XMIT HOLD EMP is being processed, the serial driver should stuff characters into the UART until the UART signals that its FIFO is full. These mods will cause a much better transmission rate on high bit rates, since the FIFO buffer plus its software support minimizes the number of interrupts that have to be processed by the kernel... I do not have the time to implement this right now, but maybe someone else who understands the serial driver can do it? Fred.