TIP: Click on subject to list as thread! ANSI
echo: elist
to: NICK ANDRE
from: DAN CROSS
date: 2020-01-31 15:49:00
subject: Re: processing..

On 30 Jan 2020 at 09:14p, Nick Andre pondered and said...
 
 NA> On 30 Jan 20  19:56:00, August Abolins said the following to Nick Andre:
 NA> 
 NA> AA> MAKENL for DOS is this the only reliable option?  I thought it could b
 NA> AA> built/compiled for the other OSes.
 NA> 
 NA> It can, but the way it runs and returns the first-matching segment
 NA> operates differently than it does on Linux. Thats not the fault of
 NA> MakeNL but really the difference between DOS and Linux when it comes to
 NA> how files are treated.

Pardon?  What, precisely, do you mean by "the difference between DOS and
Linux when it comes to how files are treated"?

DOS is exceptionally primitive, more a program loader than an operating
system.  It's "file system" is minimal, but even so, when it comes to
programs written to consume data from files, process that data, and possibly
write the results back into files, the fundamentals aren't all that
different.  DOS, like Unix, doesn't impose a particular structure on the
file, but rather, it's just a bag of bytes.

Of course, Unix (and thus by extension Linux) adopts conventions for things
like line feeds and so forth that are different than DOS, and DOS nominally
ascribes meaning to a file's extension (Unix doesn't care whether a file
has an extension or not, let alone what it is or how it's represented).

In this case, if "MakeNL" behaves different under DOS than under Linux, that
really has nothing to do with the operating system but everything to do with
the program, which was clearly written in such a way that it behaves
differently depending on the execution environment.

 NA> Its not the only problem... Linux is just not designed to run Fido
 NA> stuff. The software available is just hokey-pokey in my opinion, needs
 NA> all kinds of work to get going and scripting together. On MS-DOS you
 NA> have far more options.

I don't understand this statement.  MS-DOS obviously wasn't designed to run
Fidonet software, either; I really doubt it was on the engineers' minds, as
DOS predates Fidonet by several years.

Perhaps a more accurate statement is that Fidonet software clearly wasn't
designed to support Unix-style systems.  Indeed, in that world, Fidonet was
largely superfluous when you had technically superior systems like USENET
and even UUCP.  Perhaps this is what you see a paucity of Fidonet software
for Unix and Linux systems: there wasn't a need for software to support
amateur hobbyist networks.  You have far more options on DOS because that's
what the hobbyists used before and during the Fidonet heyday.  As Linux
became generally available, so did commodity Internet access and most of
the programming talent that could have produced more robust software for
Fidonet on Linux and Unix migrated away, instead.  The result is that the
software did not get developed since there was neither demand nor skill left
to do the work.

To suggest that this is the fault of the Linux filesystem is strange.

 NA> So on a Linux system, you need to have all kinds of scripting and
 NA> trickery to run ZC1. On MS-DOS you really do not. I have two batch files
 NA> that run everything and call "standard" DOS Fido software such as
 NA> Allfix, Gus and some others. DOS is by far the easiest platform to write
 NA> Fido stuff for.

DOS is by far the platform with the most existing Fidonet-related software.
Too bad that system is so fragile: a single errant pointer access can put
the entire computer into an inconsistent state requiring a reboot to repair.

But it doesn't sound like you are so much writing new things as using existing
software, perhaps with some light automation.  If it works for you, then
great.  But that hardly means that one couldn't build a robust environment
under a Unix-like system given sufficient technical know-how.

--- Mystic BBS v1.12 A44 2020/01/29 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)

SOURCE: echomail via QWK@docsplace.org

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.