• Move .ini files from /sbbs/exec to /sbbs/ctrl

    From Tracker1@VERT/TRN to DOVE-Net.Synchronet_Programming on Saturday, September 10, 2022 14:41:13
    There are a handful of .ini files in the /sbbs/exec directory.

    Would it be possible to consider supporting moving these from /exec to
    /ctrl ?

    Mainly, in a containerized environment, I've been keeping the
    executables inside the container, but mounting all transient data
    (including /xtrn) from outside... but with these configuration files,
    it's a bit cumbersome.

    I've made an sbbs-init script that runs prior to sbbs/scfg in general
    use, that makes sure all the volume mount paths are symlinked under
    /sbbs before running... I *could* do similar for exec/*.ini, or for
    those specific files, could just copy them.

    I'm wanting to pre-configure dosemu(2) as much as reasonable to make setup/configuration a bit more straight forward... This is just
    throwing a small kink in that setup.
    --
    Michael J. Ryan - tracker1@roughneckbbs.com
    ---
    þ Synchronet þ Roughneck BBS - roughneckbbs.com
  • From Digital Man@VERT to Tracker1 on Saturday, September 10, 2022 19:44:49
    Re: Move .ini files from /sbbs/exec to /sbbs/ctrl
    By: Tracker1 to DOVE-Net.Synchronet_Programming on Sat Sep 10 2022 02:41 pm

    There are a handful of .ini files in the /sbbs/exec directory.

    Would it be possible to consider supporting moving these from /exec to
    /ctrl ?

    Possible, sure, but not preferable.

    Mainly, in a containerized environment, I've been keeping the
    executables inside the container, but mounting all transient data
    (including /xtrn) from outside... but with these configuration files,
    it's a bit cumbersome.

    I've made an sbbs-init script that runs prior to sbbs/scfg in general
    use, that makes sure all the volume mount paths are symlinked under
    /sbbs before running... I *could* do similar for exec/*.ini, or for
    those specific files, could just copy them.

    I'm wanting to pre-configure dosemu(2) as much as reasonable to make setup/configuration a bit more straight forward... This is just
    throwing a small kink in that setup.

    Sorry, but some of those (e.g. init-fidonet.ini) aren't intended to be sysop-modified in the first place, while others are used by programs that don't know anything about the Synchronet CTRL directory. The reasons are varied (why there are a few .ini files in exec), but there are reasons.
    --
    digital man (rob)

    Sling Blade quote #8:
    Karl Childers: I don't reckon I got no reason to kill nobody.
    Norco, CA WX: 73.1øF, 87.0% humidity, 3 mph SSE wind, 0.08 inches rain/24hrs ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Tracker1@VERT/TRN to Digital Man on Sunday, September 11, 2022 15:27:29
    On 9/10/22 19:44, Digital Man wrote:
    Would it be possible to consider supporting moving these from
    /exec to /ctrl ?

    Possible, sure, but not preferable.
    ...
    Sorry, but some of those (e.g. init-fidonet.ini) aren't intended to
    be sysop-modified in the first place, while others are used by
    programs that don't know anything about the Synchronet CTRL
    directory. The reasons are varied (why there are a few .ini files
    in exec), but there are reasons.

    So, it's effectively not possible to separate executable files from data/configuration for Synchronet... or to cleanly update/upgrade those executable files in a read-only fashion.
    --
    Michael J. Ryan - tracker1@roughneckbbs.com
    ---
    þ Synchronet þ Roughneck BBS - roughneckbbs.com
  • From Gamgee@VERT/PALANT to Tracker1 on Monday, September 12, 2022 07:30:00
    Tracker1 wrote to Digital Man <=-

    On 9/10/22 19:44, Digital Man wrote:
    Would it be possible to consider supporting moving these from
    /exec to /ctrl ?

    Possible, sure, but not preferable.
    ...
    Sorry, but some of those (e.g. init-fidonet.ini) aren't intended to
    be sysop-modified in the first place, while others are used by
    programs that don't know anything about the Synchronet CTRL
    directory. The reasons are varied (why there are a few .ini files
    in exec), but there are reasons.

    So, it's effectively not possible to separate executable files
    from data/configuration for Synchronet... or to cleanly
    update/upgrade those executable files in a read-only fashion.

    The second half of your statement above doesn't make much sense to me.
    How would you upgrade something that is "read-only" in the first place?
    I don't have any problems updating my ../exec directory.


    ... Gone crazy, be back later, please leave message.
    --- MultiMail/Linux v0.52
    þ Synchronet þ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
  • From Digital Man@VERT to Tracker1 on Monday, September 12, 2022 10:50:19
    Re: Re: Move .ini files from /sbbs/exec to /sbbs/ctrl
    By: Tracker1 to Digital Man on Sun Sep 11 2022 03:27 pm

    On 9/10/22 19:44, Digital Man wrote:
    Would it be possible to consider supporting moving these from
    /exec to /ctrl ?

    Possible, sure, but not preferable.
    ...
    Sorry, but some of those (e.g. init-fidonet.ini) aren't intended to
    be sysop-modified in the first place, while others are used by
    programs that don't know anything about the Synchronet CTRL
    directory. The reasons are varied (why there are a few .ini files
    in exec), but there are reasons.

    So, it's effectively not possible to separate executable files from data/configuration for Synchronet... or to cleanly update/upgrade those executable files in a read-only fashion.

    Oh, I think you can figure something out.
    --
    digital man (rob)

    This Is Spinal Tap quote #12:
    Nigel Tufnel: Well, I don't know - wh-wh-... what're the hours?
    Norco, CA WX: 77.7øF, 74.0% humidity, 0 mph ESE wind, 0.23 inches rain/24hrs ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Charles Blackburn@VERT/FBOBBS to Tracker1 on Monday, September 12, 2022 13:48:59
    Re: Re: Move .ini files from /sbbs/exec to /sbbs/ctrl
    By: Tracker1 to Digital Man on Sun Sep 11 2022 15:27:29

    i dont know about separation of the ini files.

    but everything on mine is on an NFS share on my NAS (which has 30Tb space compared to the 20G on the machine itself).

    so pretty much only thing that's stored on the bbs machine is the sbbs stuff directly. That RSyncs over the nas as a backup once a day.

    not sure if that helps with your docker stuff, but i wonder if there's a way you can just do something similar.

    regards
    Charles Blackburn
    SYSOP - The F.B.O BBS
    Aviation related fun @ bbs.thefbo.us IPV4 and IPV6
    DOVE-Net
    Coming soon: FSX-Net, FIDO-Net

    ---
    þ Synchronet þ The FBO BBS - bbs.thefbo.us - A place for aviation fun....
  • From Tracker1@VERT/TRN to Gamgee on Wednesday, September 21, 2022 22:09:00
    On 9/12/22 05:30, Gamgee wrote:
    So, it's effectively not possible to separate executable files
    from data/configuration for Synchronet... or to cleanly
    update/upgrade those executable files in a read-only fashion.

    The second half of your statement above doesn't make much sense
    to me. How would you upgrade something that is "read-only" in
    the first place? I don't have any problems updating my ../exec
    directory.

    Imagine an executable on a read-only CD... but the data is stored on a
    hard drive... to move to the next version, you shut down the program,
    and swap out the CD to one with the new version. You effectively do the
    same with a docker image. You just get the new image.

    /sbbs/exec - read-only image mount
    /sbbs/(data|ctrl|...) - read-write mount

    Generally my updates go...

    1. cd ~/sbbs
    2. docker pull bbsio/synchronet:nightly
    3. docker-compose up -d

    1. keeping ~/sbbs as my (outside docker) location.
    2. pull the latest nightly image from dockerhub
    3. detects the underlying image changed, (re)starts related instance(s)

    --------

    In practice it's /sbbs-data/(data|ctrl|...) that gets symlinked at
    runtime. I also save a version.txt file in exec/ that gets compared to
    ctrl/ at startup, so that it runs the js version update script if/when
    they don't match.

    But having data written to /sbbs/exec that part of it will fail when
    moving to a new version. I could move (if not already there)
    /sbbs/exec/*.ini to /sbbs-data/exec/*.ini, and then symlink back to
    exec, which is what I'll probably do... just kind of a pain.

    Most *nix services are pretty easy, as you can inject/mount the data
    directory and configuration separately from the executable and dependencies.
    --
    Michael J. Ryan - tracker1@roughneckbbs.com
    ---
    þ Synchronet þ Roughneck BBS - roughneckbbs.com
  • From Tracker1@VERT/TRN to Charles Blackburn on Wednesday, September 21, 2022 22:16:37
    On 9/12/22 10:48, Charles Blackburn wrote:

    i dont know about separation of the ini files.

    See my reply to Gamgee.

    but everything on mine is on an NFS share on my NAS (which has 30Tb
    space compared to the 20G on the machine itself).

    so pretty much only thing that's stored on the bbs machine is the sbbs
    stuff directly. That RSyncs over the nas as a backup once a day.

    not sure if that helps with your docker stuff, but i wonder if there's
    a way you can just do something similar.

    Yeah, I rsync from outside the bbs host to local and backup to my nas regularly. Main thing is a clean docker-style update path (again in the
    prior reply)

    docker pull bbsio/synchronet:nightly
    docker-compose up -d

    Which is relatively simple... same goes to reverting to a prior release,
    but slightly more complex... assuming something broke.

    kill services
    nuke directory
    restore from backup
    set docker-compose.yml to use a specific nightly (nightly-20220916)
    run docker=compose up

    I know it probably seems like overkill... but I have a regularly updated
    image I can pull from at any point, as well as clean backups... and installing/configuring a host means I just need to install docker as the single dependency.

    Takes less time to download the latest image than to build synchronet.
    --
    Michael J. Ryan - tracker1@roughneckbbs.com
    ---
    þ Synchronet þ Roughneck BBS - roughneckbbs.com
  • From Gamgee@VERT/PALANT to Tracker1 on Thursday, September 22, 2022 07:37:00
    Tracker1 wrote to Gamgee <=-

    On 9/12/22 05:30, Gamgee wrote:

    So, it's effectively not possible to separate executable files
    from data/configuration for Synchronet... or to cleanly
    update/upgrade those executable files in a read-only fashion.

    The second half of your statement above doesn't make much sense
    to me. How would you upgrade something that is "read-only" in
    the first place? I don't have any problems updating my ../exec
    directory.

    Imagine an executable on a read-only CD... but the data is stored
    on a hard drive... to move to the next version, you shut down the
    program, and swap out the CD to one with the new version. You
    effectively do the same with a docker image. You just get the
    new image.

    /sbbs/exec - read-only image mount
    /sbbs/(data|ctrl|...) - read-write mount

    Generally my updates go...

    1. cd ~/sbbs
    2. docker pull bbsio/synchronet:nightly
    3. docker-compose up -d

    1. keeping ~/sbbs as my (outside docker) location.
    2. pull the latest nightly image from dockerhub
    3. detects the underlying image changed, (re)starts related
    instance(s)

    --------

    In practice it's /sbbs-data/(data|ctrl|...) that gets symlinked
    at runtime. I also save a version.txt file in exec/ that gets
    compared to ctrl/ at startup, so that it runs the js version
    update script if/when they don't match.

    But having data written to /sbbs/exec that part of it will fail
    when moving to a new version. I could move (if not already there) /sbbs/exec/*.ini to /sbbs-data/exec/*.ini, and then symlink back
    to exec, which is what I'll probably do... just kind of a pain.

    Okay...... I don't believe you had mentioned anything about docker in
    this context up until now...., so perhaps you can understand my original confusion...?

    As for the rest of that above... I don't use or know anything about
    Docker, and can't imagine wanting to go through that much hassle for
    some "benefit" that it would gain me...

    I'll add this to my list of YARNTWTUD. (Yet another reason not to want
    to use Docker). :-)



    ... A woman drove me to drink, and I never had the courtesy to thank her.
    --- MultiMail/Linux v0.52
    þ Synchronet þ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
  • From Charles Blackburn@VERT/FBOBBS to Tracker1 on Thursday, September 22, 2022 07:39:19
    Re: Re: Move .ini files from /sbbs/exec to /sbbs/ctrl
    By: Tracker1 to Gamgee on Wed Sep 21 2022 22:09:00

    Imagine an executable on a read-only CD... but the data is stored on a hard drive... to move to the next version, you shut down the program,

    "Synchronet LIVE CD" LOL... pretty much how they work to be honest.

    But having data written to /sbbs/exec that part of it will fail when moving to a new version. I could move (if not already there) /sbbs/exec/*.ini to /sbbs-data/exec/*.ini, and then symlink back to
    exec, which is what I'll probably do... just kind of a pain.

    the only thing i cansee with that is if something changes with the INI files, like stuff added or deleted and then things like cnf files moving to ini files etc.

    for the most part it would work, but if something like that changes then that's going to break it and cause a lot of hassle.

    regards
    ---

    Charles Blackburn
    The F.B.O BBS 21:1/221 618:250/36
    bbs.thefbo.us IPV4/V6
    DOVE-Net FSX-Net MicroNET USENET
    ---
    þ Synchronet þ The FBO BBS - bbs.thefbo.us - A place for aviation fun....
  • From Tracker1@VERT/TRN to Gamgee on Friday, September 23, 2022 22:11:53
    On 9/22/22 05:37, Gamgee wrote:

    As for the rest of that above... I don't use or know anything about
    Docker, and can't imagine wanting to go through that much hassle for
    some "benefit" that it would gain me...

    I'll add this to my list of YARNTWTUD. (Yet another reason not to
    want to use Docker). :-)

    In practice, there are some benefits. Most unixy apps separate
    configuration (/etc), data (/var) and executables/scripts (/bin) ...

    Most docker-friendly applications will take a handful of environment
    variables for configuration, leaving only data to deal with. In this
    way, you can run a database server only mounting /data ... while
    literally everything else can be read-only file system.

    This means that security holes that would require disk write are largely mitigated. It also means you can upgrade to the new version, just by
    running against the new version image. No downloads, installing prerequisites, building anything... just *run*.
    --
    Michael J. Ryan - tracker1@roughneckbbs.com
    ---
    þ Synchronet þ Roughneck BBS - roughneckbbs.com
  • From Tracker1@VERT/TRN to Charles Blackburn on Friday, September 23, 2022 22:14:27
    On 9/22/22 04:39, Charles Blackburn wrote:
    Imagine an executable on a read-only CD... but the data is stored on a
    hard drive... to move to the next version, you shut down the program,

    "Synchronet LIVE CD" LOL... pretty much how they work to be honest.

    pretty much.

    But having data written to /sbbs/exec that part of it will fail when
    moving to a new version. I could move (if not already there)
    /sbbs/exec/*.ini to /sbbs-data/exec/*.ini, and then symlink back to
    exec, which is what I'll probably do... just kind of a pain.

    the only thing i cansee with that is if something changes with the INI files, like stuff added or deleted and then things like cnf files
    moving to ini files etc.

    Those cnf/ini files are in the /ctrl directory, not the /exec
    directory... what I'm referring to are some utilities/scripts that
    use/modify an ini file in /exec.

    for the most part it would work, but if something like that changes
    then that's going to break it and cause a lot of hassle.

    Main risk is a new script/app using something that isn't .ini inside the /sbbs/exec directory, which I *REALLY* hope nothing does... as it is,
    would be nice of everything was limited to ctrl and data.
    --
    Michael J. Ryan - tracker1@roughneckbbs.com
    ---
    þ Synchronet þ Roughneck BBS - roughneckbbs.com
  • From Gamgee@VERT/PALANT to Tracker1 on Saturday, September 24, 2022 07:23:00
    Tracker1 wrote to Gamgee <=-

    As for the rest of that above... I don't use or know anything about
    Docker, and can't imagine wanting to go through that much hassle for
    some "benefit" that it would gain me...

    I'll add this to my list of YARNTWTUD. (Yet another reason not to
    want to use Docker). :-)

    In practice, there are some benefits. Most unixy apps separate configuration (/etc), data (/var) and executables/scripts (/bin)
    ...

    Most docker-friendly applications will take a handful of
    environment variables for configuration, leaving only data to
    deal with. In this way, you can run a database server only
    mounting /data ... while literally everything else can be
    read-only file system.

    This means that security holes that would require disk write are
    largely mitigated. It also means you can upgrade to the new
    version, just by running against the new version image. No
    downloads, installing prerequisites, building anything... just
    *run*.

    I can see how that would work, and that it would be nice in some
    abstract way. It's just that.... I don't do anything like that, and
    honestly don't even know anybody who does things like that. So... in practice... it's a very limited scope audience who would care about
    something like that. Very.



    ... Backup not found: (A)bort (R)etry (P)anic
    --- MultiMail/Linux v0.52
    þ Synchronet þ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
  • From Charles Blackburn@VERT/FBOBBS to Tracker1 on Saturday, September 24, 2022 06:05:57
    Re: Re: Move .ini files from /sbbs/exec to /sbbs/ctrl
    By: Tracker1 to Charles Blackburn on Fri Sep 23 2022 22:14:27

    Those cnf/ini files are in the /ctrl directory, not the /exec directory... what I'm referring to are some utilities/scripts that use/modify an ini file in /exec.

    I have these in my exec directory and i think the only ones i have modified are dosemu and init-ticket. i would think to be honest that even just a symlink should work fine.

    sbbs@sbbs:~/exec$ ls *.ini
    dosemu.ini init-fidonet.ini init-tickit.ini kermit.ini sbbsexec.ini sutils.ini


    for the most part it would work, but if something like that changes
    then that's going to break it and cause a lot of hassle.
    Main risk is a new script/app using something that isn't .ini inside the /sbbs/exec directory, which I *REALLY* hope nothing
    does... as it is, would be nice of everything was limited to ctrl and data.

    totally... i dont know why they're split up with most being in one and a couple in the main directory.

    all my stuff i write, i either use the exec directory, or if i have something with a separate config directory then everything goes in there.

    regards
    ---

    Charles Blackburn
    The F.B.O BBS 21:1/221 618:250/36
    bbs.thefbo.us IPV4/V6
    DOVE-Net FSX-Net MicroNET USENET
    ---
    þ Synchronet þ The FBO BBS - bbs.thefbo.us - A place for aviation fun....
  • From Digital Man@VERT to Tracker1 on Saturday, September 24, 2022 12:30:19
    Re: Re: Move .ini files from /sbbs/exec to /sbbs/ctrl
    By: Tracker1 to Charles Blackburn on Fri Sep 23 2022 10:14 pm

    Those cnf/ini files are in the /ctrl directory, not the /exec
    directory... what I'm referring to are some utilities/scripts that use/modify an ini file in /exec.

    I don't know of any utilities/scripts that modify ini files in the exec dir.
    --
    digital man (rob)

    Rush quote #39:
    Sounds that build high like a mountain or notes that fall, gently, like rain Norco, CA WX: 89.9øF, 37.0% humidity, 8 mph ESE wind, 0.00 inches rain/24hrs ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Tracker1@VERT/TRN to Gamgee on Monday, September 26, 2022 16:47:56
    On 9/24/22 05:23, Gamgee wrote:
    Most docker-friendly applications will take a handful of
    environment variables for configuration, leaving only data to
    deal with. In this way, you can run a database server only
    mounting /data ... while literally everything else can be
    read-only file system.

    This means that security holes that would require disk write are
    largely mitigated. It also means you can upgrade to the new
    version, just by running against the new version image. No
    downloads, installing prerequisites, building anything... just
    *run*.

    I can see how that would work, and that it would be nice in some
    abstract way. It's just that.... I don't do anything like that,
    and honestly don't even know anybody who does things like that.
    So... in practice... it's a very limited scope audience who would
    care about something like that. Very.

    Not sure how limited it is in practice... look on job boards for
    Kubernetes and you'll see *MANY* using it. The core of almost
    everything I've done that past 4 years is deployed in
    Docker/Kubernetes... and there are distributed databases that thrive
    under that model (CockroachDB, Cassandra, etc). So YMMV of course.

    For example on LinkedIn jobs, Kubernetes has 83,244 active results for
    just the US.

    https://www.linkedin.com/jobs/search/?keywords=kubernetes
    --
    Michael J. Ryan - tracker1@roughneckbbs.com
    ---
    þ Synchronet þ Roughneck BBS - roughneckbbs.com
  • From Tracker1@VERT/TRN to Digital Man on Monday, September 26, 2022 16:50:00
    On 9/24/22 12:30, Digital Man wrote:
    Those cnf/ini files are in the /ctrl directory, not the /exec
    directory... what I'm referring to are some utilities/scripts that
    use/modify an ini file in /exec.

    I don't know of any utilities/scripts that modify ini files in the exec dir.

    Didn't you mention that some weren't meant to be user modified? I would presume *something* uses and potentially modifies them.
    --
    Michael J. Ryan - tracker1@roughneckbbs.com
    ---
    þ Synchronet þ Roughneck BBS - roughneckbbs.com
  • From Digital Man@VERT to Tracker1 on Monday, September 26, 2022 19:56:25
    Re: Re: Move .ini files from /sbbs/exec to /sbbs/ctrl
    By: Tracker1 to Digital Man on Mon Sep 26 2022 04:50 pm

    On 9/24/22 12:30, Digital Man wrote:
    Those cnf/ini files are in the /ctrl directory, not the /exec
    directory... what I'm referring to are some utilities/scripts that
    use/modify an ini file in /exec.

    I don't know of any utilities/scripts that modify ini files in the exec dir.

    Didn't you mention that some weren't meant to be user modified? I would presume *something* uses and potentially modifies them.

    Not normally.
    --
    digital man (rob)

    This Is Spinal Tap quote #3:
    How much more black could this be? and the answer is none. None more black. Norco, CA WX: 81.7øF, 40.0% humidity, 4 mph SSE wind, 0.00 inches rain/24hrs ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From MRO@VERT/BBSESINF to Tracker1 on Tuesday, September 27, 2022 06:37:14
    Re: Re: Move .ini files from /sbbs/exec to /sbbs/ctrl
    By: Tracker1 to Digital Man on Mon Sep 26 2022 04:50 pm


    Didn't you mention that some weren't meant to be user modified? I would presume *something* uses and potentially modifies them.

    only like one of them.
    the rest are okay.
    ---
    þ Synchronet þ ::: BBSES.info - free BBS services :::
  • From Gamgee@VERT/PALANT to Tracker1 on Tuesday, September 27, 2022 07:33:00
    Tracker1 wrote to Gamgee <=-

    Most docker-friendly applications will take a handful of
    environment variables for configuration, leaving only data to
    deal with. In this way, you can run a database server only
    mounting /data ... while literally everything else can be
    read-only file system.

    This means that security holes that would require disk write are
    largely mitigated. It also means you can upgrade to the new
    version, just by running against the new version image. No
    downloads, installing prerequisites, building anything... just
    *run*.

    I can see how that would work, and that it would be nice in some
    abstract way. It's just that.... I don't do anything like that,
    and honestly don't even know anybody who does things like that.
    So... in practice... it's a very limited scope audience who would
    care about something like that. Very.

    Not sure how limited it is in practice... look on job boards for Kubernetes and you'll see *MANY* using it. The core of almost
    everything I've done that past 4 years is deployed in
    Docker/Kubernetes... and there are distributed databases that
    thrive under that model (CockroachDB, Cassandra, etc). So YMMV
    of course.

    For example on LinkedIn jobs, Kubernetes has 83,244 active
    results for just the US.

    https://www.linkedin.com/jobs/search/?keywords=kubernetes

    Perhaps I should have clarified my statement better... Perhaps D/K is
    an important thing for those who work in IT for a living. I'll take
    your word for it. I guess my point is that that is still a small amount
    of the workforce overall. It's orders of magnitude smaller when you
    consider the BBS/hobbyist computer users who may be reading this... ;-)



    ... Computer Hacker wanted. Must have own axe.
    --- MultiMail/Linux v0.52
    þ Synchronet þ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
  • From Tracker1@VERT/TRN to Gamgee on Thursday, October 06, 2022 08:43:12
    On 9/27/22 05:33, Gamgee wrote:
    For example on LinkedIn jobs, Kubernetes has 83,244 active
    results for just the US.

    https://www.linkedin.com/jobs/search/?keywords=kubernetes

    Perhaps I should have clarified my statement better... Perhaps D/K
    is an important thing for those who work in IT for a living. I'll
    take your word for it. I guess my point is that that is still a small amount of the workforce overall. It's orders of magnitude smaller
    when you consider the BBS/hobbyist computer users who may be reading
    this... ;-)

    While it is a very small segment of an overall workforce... I think it's
    fair to assume that there would be a larger overlap of those who might
    want to run a hobby BBS that professionally work in IT than the general population.
    --
    Michael J. Ryan - tracker1@roughneckbbs.com
    ---
    þ Synchronet þ Roughneck BBS - roughneckbbs.com