| |
CO2JA > BPQ 31.07.99 08:14l 25 Lines 1134 Bytes #-9941 (0) @ WW
BID : 32796_CO2JA
Read: GUEST
Subj: BPQ
Path: DB0AAB<DB0ZKA<DB0LX<DB0CZ<DB0LJ<DB0ACH<PI8JOP<PI8ZAA<PI8GCB<PI8HGL<
PE1NMB<EA7URC<WU3V<CO2JA
Sent: 990731/0315Z @:CO2JA.#HAV.CUB.NA #:32796 [Habana] XFBB7.00g26 $:32796_CO2
From: CO2JA@CO2JA.#HAV.CUB.NA
To : BPQ@WW
BPQ has been part of an era, and still does reasonably well, I know quite
a few still running it happily.
It was the glue that made possible to run many applications together, as long
as you had RAM available, I had six of them once perfectly configured. It has
been a nice piece of software.
It's worst problem is fixed parameters, which are hardly ever optimal, and was very easy to configure it as a "delay line" under light load, or as a massive
collision point under heavy load when set with snappy and too optimistic parameters. If John could devise a solution for it, not only for 32 bits, but also
for the old 16 bits stuff (maybe BPQ 4.09 ??) I believe it could still be a
good thing. By that I mean demand adjustable frack, maxframe, persist and
resptime. It doesn't seem to me it would be necessary to make other parameters
variable, even when I might be wrong on my appreciation.
I am aware some might not like my appreciation for BPQ. I switched to Linux
and I don't run it anymore, even when I have configured the Linux node as a
BPQ lookalike...
73 de Jose, CO2JA
Read previous mail | Read next mail
| |
