• processing..

    From August Abolins@2:221/1.58 to Nick Andre on Thu Jan 30 19:56:00 2020
    Hello Nick!

    ** 30.01.20 - 17:16, Nick Andre wrote to Vince Coen:

    I am convinced, with factual evidence, that ZC1 processing cannot operate
    on any other platform than DOS.

    Maybe veering off topic.. but,

    MAKENL for DOS is this the only reliable option? I thought it could be built/compiled for the other OSes.




    ../|ug

    --- OpenXP 5.0.43
    * Origin: /|ug's Point, Ont. CANADA (2:221/1.58)
  • From Nick Andre@1:229/426 to August Abolins on Thu Jan 30 21:14:01 2020
    On 30 Jan 20 19:56:00, August Abolins said the following to Nick Andre:

    MAKENL for DOS is this the only reliable option? I thought it could be built/compiled for the other OSes.

    It can, but the way it runs and returns the first-matching segment operates differently than it does on Linux. Thats not the fault of MakeNL but really the difference between DOS and Linux when it comes to how files are treated.

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

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

    One way to look at it is, do I want to babysit Fido ZC1 stuff? Or do I really want it to "just work" and be completely hands-off, automated. Where I can go away for a weekend and not worry a nodelist will not compile properly.

    The other way to look at it, is if I get hit by a bus tomorrow, and my daughter has to salvage the remains of my Fido system - It can all be easily zipped up and emailed to whomever and at least be understood because MS-DOS is the bare-minimum of technical competence.

    Two batch files run all of ZC1 here.

    Nick

    --- Renegade vY2Ka2
    * Origin: Joey, do you like movies about gladiators? (1:229/426)
  • From Dan Cross@3:770/100 to Nick Andre on Fri Jan 31 16:02:10 2020
    On 30 Jan 2020 at 09:14p, Nick Andre pondered and said...

    On 30 Jan 20 19:56:00, August Abolins said the following to Nick Andre:

    MAKENL for DOS is this the only reliable option? I thought it could b built/compiled for the other OSes.

    It can, but the way it runs and returns the first-matching segment operates differently than it does on Linux. Thats not the fault of
    MakeNL but really the difference between DOS and Linux when it comes to 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.

    Its not the only problem... Linux is just not designed to run Fido
    stuff. The software available is just hokey-pokey in my opinion, needs
    all kinds of work to get going and scripting together. On MS-DOS you
    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.

    So on a Linux system, you need to have all kinds of scripting and
    trickery to run ZC1. On MS-DOS you really do not. I have two batch files that run everything and call "standard" DOS Fido software such as
    Allfix, Gus and some others. DOS is by far the easiest platform to write 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)
  • From Nick Andre@1:229/426 to Dan Cross on Fri Jan 31 01:25:49 2020
    On 31 Jan 20 16:02:10, Dan Cross said the following to Nick Andre:

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

    In a call by MakeNL to return the first matching file matching a wildcard, the result can be different under Linux than it is in DOS.

    Perhaps a more accurate statement is that Fidonet software clearly wasn't designed to support Unix-style systems. Indeed, in that world, Fidonet was

    There is significantly more tried-and-tested-true Fidonet software written for DOS and Windows than there is for Linux. When I say Fidonet software on
    Linux is hokey-pokey, I mean it. The options on Linux are slim or appear
    just cumbersome, half-assed or as per below:

    great. But that hardly means that one couldn't build a robust environment under a Unix-like system given sufficient technical know-how.

    Yes, very true. If someone wants to take on the challenge of building a Fido hub or nodelist-production system on Linux, who am I to criticise.

    But I'll try. 8-)

    For many years until July 2018, sometimes Zone 1 RC segments would process correctly, sometimes not. The story we were always told was BBBS this, BBBS that, Linux this, Linux that. This is not a crackpot opinion, this is fact.

    The second is that for many years, my BBS software did not include the MSGID/REPLY kludge. Just like TBBS/Flame and many other BBS programs of the 80's and 90's did not carry that kludge set. And for the 90's and actually well into the 2000's, nobody made any stink about it. Until some tosser program called Hpt came out which did not correctly handle messages without the kludge set. Then I had Linux Sysops nail me to the cross over something that was never an issue but suddenly "is" an issue.... because Linux.

    The third is for two solid decades I've dealt with Linux Sysops who proclaim DOS sucks, Windows sucks. As passionate and intelligent as they were, they just could seem to never be able to get things "right" on Linux with their BBS or system. Always posting test messages, always discussing configuration, always experimenting, tinkering. Rarely getting things to "just work".

    Usually they ended up vanishing off the face of the earth months down the road... but I'm still here since '94 on largely the same DOS setup and as mentioned, Windows for multi-tasking.

    At work I manage several Linux VPS's that work perfectly fine with excellent uptime. I do have a strong IT background. Linux has its purpose. Just not for running a Fido ZC system in my opinion... and not for an Elist system.

    Nick

    --- Renegade vY2Ka2
    * Origin: Joey, do you like movies about gladiators? (1:229/426)
  • From Dan Cross@3:770/100 to Nick Andre on Sat Feb 1 03:18:52 2020
    On 31 Jan 2020 at 01:25a, Nick Andre pondered and said...

    On 31 Jan 20 16:02:10, Dan Cross said the following to Nick Andre:

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

    In a call by MakeNL to return the first matching file matching a
    wildcard, the result can be different under Linux than it is in DOS.

    Aha. So it has to do with the sort ordering of glob patterns in
    the shell. Perhaps you could give an example? But in any event,
    that's an artifact of how a given shell handles glob expansion,
    not "how files are treated" in Linux. In particular, the OS doesn't
    really care what order files are added to a directory, but when
    you use a glob pattern for wildcard expansion that's handled by the
    program that's doing the expanding (i.e., a shell, but it could be
    anything). The operating system doesn't care.

    Perhaps a more accurate statement is that Fidonet software clearly was designed to support Unix-style systems. Indeed, in that world, Fidone

    There is significantly more tried-and-tested-true Fidonet software
    written for DOS and Windows than there is for Linux. When I say Fidonet software on Linux is hokey-pokey, I mean it. The options on Linux are
    slim or appear just cumbersome, half-assed or as per below:

    Yes, this is largely repeating what I told you.

    However, this is not an indictment of Linux, but rather a simple
    notation of the fact that there's been no incentive to produce high
    quality Fidonet software for Linux.

    great. But that hardly means that one couldn't build a robust environ under a Unix-like system given sufficient technical know-how.

    Yes, very true. If someone wants to take on the challenge of building a Fido hub or nodelist-production system on Linux, who am I to criticise.

    It seems to me that a number of people are running FTN hubs on what you
    calls call "othernets" under Linux, and it seems to work just fine. The Raspberry Pi seems to be a popular platform for this: it's cheap, they
    are easy to come by, they run Linux natively, they have plenty of processing power for low-demand applications like BBSes, and there are a number of
    popular BBS packages that run on them that have this sort of functionality built in.

    Would you mind sharing your two batch files somewhere? I'd kind of like
    to know what is involved, if only for my own curiosity.

    But I'll try. 8-)

    For many years until July 2018, sometimes Zone 1 RC segments would
    process correctly, sometimes not. The story we were always told was BBBS this, BBBS that, Linux this, Linux that. This is not a crackpot opinion, this is fact.

    So, there were bugs in a BBS program that ran under Linux? I'm
    sorry, but the fault for that falls squarely on the shoulders of
    the program's author, not the operating system.

    The second is that for many years, my BBS software did not include the MSGID/REPLY kludge. Just like TBBS/Flame and many other BBS programs of the 80's and 90's did not carry that kludge set. And for the 90's and actually well into the 2000's, nobody made any stink about it. Until
    some tosser program called Hpt came out which did not correctly handle messages without the kludge set. Then I had Linux Sysops nail me to the cross over something that was never an issue but suddenly "is" an issue.... because Linux.

    Your conclusion does not follow from your statements. The problem
    here is not Linux, it is `hpt`.

    In many ways, an operating system like Windows, Linux, etc, is like
    a tool. Perhaps a hammer. It may be the case that the hammer itself
    is misshapen or worn out, and can no longer drive nails correctly;
    in this case, the hammer should be replaced. That can certainly
    happen (cue the old saw that says, "this is my favorite hammer! I've
    had it for years and replaced the head 4 times and the handle twice!").

    However, it may be the case that the hammer is perfectly fine, but
    the person driving the nail lacks the proper technique. In this
    case, the problem isn't the hammer but rather the user.

    A litmus test is whether someone else can take the hammer and drive
    a nail correctly.

    To bring it back to operating systems, a significant portion of the
    Internet's core infrastructure runs on the Linux kernel or another
    Unix variant these days: DNS servers, infrastructure for major
    providers, some of the biggest services out there (Google, Facebook,
    Amazon, Netflix, etc). Most of the world's smart phones are running
    Linux or iOS (which is based on Unix). Every supercomputer on the
    Top 500 list runs Linux.

    For the vast majority of people, this stuff "just works." You get your
    weather report in the morning (generated by a FORTRAN program running
    on a supercomputer running Linux). You check your email, look up
    information online, buy stuff, etc.

    Clearly the people who have put together the modern infrastructure we
    all depend on have figured out how to do it.

    By contrast, a handful of hobbyists running Fidonet sites can't seem
    to get it right.

    No, neither Linux or any other Unix variant is at fault here. It's
    because competent programmers aren't interested in Fidonet (unless
    they're just doing it as a hobby out of a sense of nostalgia) and
    they're not writing the programs. Those that are left are using
    decades-old programs written by people who are largely uninvolved now.

    The third is for two solid decades I've dealt with Linux Sysops who proclaim DOS sucks, Windows sucks. As passionate and intelligent as they were, they just could seem to never be able to get things "right" on
    Linux with their BBS or system. Always posting test messages, always discussing configuration, always experimenting, tinkering. Rarely
    getting things to "just work".

    So, because people who are interested in experimenting with technology
    are using Linux, Linux somehow sucks?

    To turn your argument on it's head, perhaps a different interpretation
    is that people who are interested in experimenting are drawn to Linux
    and Unix because it's much more open and one can do more with it.

    I think what you're ignoring is the number of people running BBSes and FTN-style programs under Linux who you _don't_ hear from because their
    stuff "just works" and they don't make a fuss about it. Also, most of
    the buggy DOS-based software people used in the 80s and 90s has been
    abandoned and critical bugs (Y2K, for example) were not fixed, so use
    of the buggy stuff has dropped off dramatically. The result is a sort
    of natural-selection where people who continue the legacy software are necessarily using the best-of-breed software or what is still nominally maintained. In other words, only the highest quality software from that
    era has survived to 2020.

    Both Synchronet and Mystic BBS, for example, run on the aforementioned Raspberry Pi out of the box; both seem remarkably solid, but the authors
    of both are still involved. I wonder what percentage of BBSes on
    Fidonet are now running on a Raspberry Pi under Linux....

    Usually they ended up vanishing off the face of the earth months down the road... but I'm still here since '94 on largely the same DOS setup and
    as mentioned, Windows for multi-tasking.

    Consider that perhaps those people leave because Fidonet is not the
    place for experiments and innovation, let alone development of new
    software.

    At work I manage several Linux VPS's that work perfectly fine with excellent uptime. I do have a strong IT background. Linux has its
    purpose. Just not for running a Fido ZC system in my opinion... and not for an Elist system.

    Well, that's your opinion and you are, of course, entitled to it. I
    am not convinced by your argument that forms the basis for your opinion,
    but I also don't need to be convinced.

    As it happens, I almost kind of agree with you: My "BBS" is actually
    just a Unix system that I give out accounts on. It's got a special
    shell that provides a menu-y kind of interface, but otherwise, users
    are just normal Unix user accounts. I'm mildly interested in connecting
    to message networks because that's where most of the activity is, so I
    looked at some of the available packages for doing such things. I, too,
    am somewhat saddened by the existing solutions.

    However, I don't blame the OS for that. It's that the programs are unmaintained or poorly written to begin with that's at fault. Again,
    I think we can trace this to the overall decline of Fidonet and BBSes
    in general, and the loss of talent and motivation to fix the software
    or write new software.

    --- Mystic BBS v1.12 A44 2020/01/29 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From August Abolins@2:221/360 to Nick Andre on Fri Jan 31 18:53:56 2020
    On 30/01/2020 9:14 p.m., Nick Andre : August Abolins wrote:

    MAKENL for DOS is this the only reliable option? I thought it
    could be built/compiled for the other OSes.

    It can, but the way it runs and returns the first-matching
    segment operates differently than it does on Linux. Thats not
    the fault of MakeNL but really the difference between DOS and
    Linux when it comes to how files are treated.

    Yes.. even viewing text files generated in a unix environment can
    display differently in a DOS environment because of the way end of lines
    are designated. Could that be a problem when passing around the
    DOS-created NL segments to unix-based systems?

    Dan Cross made a fine point about glob expansions. DOS/Win and unix environments just do things differently.

    IMHO, and from my programming experience, I have found the unix
    environment to be quite more versatile in many ways. Even just switching
    to a different shell would yield new (good) wonders.


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

    Whether unix or DOS, I see that the ELIST processing ought be
    accomplished successfully in either unix or DOS.


    --
    Quoted with Reformator/Quoter. Info = https://tinyurl.com/sxnhuxc

    ---
    * Origin: nntp://rbb.fidonet.fi - Lake Ylo - Finland (2:221/360.0)
  • From Dan Cross@3:770/100 to August Abolins on Sat Feb 1 07:23:52 2020
    On 31 Jan 2020 at 06:53p, August Abolins pondered and said...

    Yes.. even viewing text files generated in a unix environment can
    display differently in a DOS environment because of the way end of lines are designated. Could that be a problem when passing around the DOS-created NL segments to unix-based systems?

    Unix imposes no particular requirement on files with respect to line
    endings. The "standard" of a single newline character terminating a
    line is a convention; it doesn't need to be followed.

    Indeed, Unix doesn't care what is a file. As far as the operating
    system is concerned, it's just a collection of bytes.

    One could easily write a program that would process segments of text
    using any line ending one cares to employ, whether '\n', '\r', '\r\n'
    or '\n\r'. Getting this right is a Simple Matter of Programming(TM).

    Now, that said, the convention used on Unix makes sense: lines are a
    logical thing, their physical presentation on an output device like
    a terminal or graphical display is independent of their representation
    in the filesystem. DOS conflates these things by using '\r\n' as a
    line-end convention.

    Dan Cross made a fine point about glob expansions. DOS/Win and unix environments just do things differently.

    Thank you!

    --- Mystic BBS v1.12 A44 2020/01/29 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Nick Andre@1:229/426 to Dan Cross on Fri Jan 31 14:31:05 2020
    On 01 Feb 20 03:18:52, Dan Cross said the following to Nick Andre:

    To turn your argument on it's head, perhaps a different interpretation
    is that people who are interested in experimenting are drawn to Linux
    and Unix because it's much more open and one can do more with it.

    Sorry, no disrespect, I do enjoy conversing with you - but I refuse to nitpick/quote-rant. Thats not my style of replies and anyone who writes replies to me in such a way just looks like trying to "win" some arguement... theres nothing to turn on its head, because I'm not arguing.

    BBS'ing on Linux never really bothers me, Mystic and Synchronet bring newcomers to the hobby. Its the operation of Fido and FTN stuff on Linux that I have seen for over two decades being hit-or-miss. Largely a miss, and having Linux shoved down my throat for two decades by a few of the most insufferable zealots imaginable. So I do have a right to this opinion after all this time.

    "Insufferable zealots" being the most polite way to describe them. It takes a special kind of insufferable zealot to whine at me about MSGID/REPLY because the *lack* of that kludge causes problems for that person's Linux tosser.

    When I start a friendly conversation or reply to someone, and that person replies with "Your DOS software is shit" or experiments with their system in a way that affects the operation of the network; my disdain for Fido-on-Linux I really believe is valid and logical especially after all this time.

    Nick

    --- Renegade vY2Ka2
    * Origin: Joey, do you like movies about gladiators? (1:229/426)
  • From Nick Andre@1:229/426 to August Abolins on Fri Jan 31 14:32:48 2020
    On 31 Jan 20 18:53:56, August Abolins said the following to Nick Andre:

    Whether unix or DOS, I see that the ELIST processing ought be
    accomplished successfully in either unix or DOS.

    In my reply to Dan, I logically explained the formation of my opinion about why I believe Linux is just not suitable for a ZC operation.

    Again - I look at things in a way that DOS is the lowest-common-denominator.

    Nick

    --- Renegade vY2Ka2
    * Origin: Joey, do you like movies about gladiators? (1:229/426)
  • From Alan Ianson@1:153/757 to August Abolins on Fri Jan 31 12:06:24 2020
    Hello August,

    It can, but the way it runs and returns the first-matching
    segment operates differently than it does on Linux. Thats not
    the fault of MakeNL but really the difference between DOS and
    Linux when it comes to how files are treated.

    Yes.. even viewing text files generated in a unix environment can
    display differently in a DOS environment because of the way end of
    lines are designated. Could that be a problem when passing around the DOS-created NL segments to unix-based systems?

    No, my makenl is a linux application. It creates my segment with CR/LF line endings so reading it should be no problem regardless of the OS in use when it makes it's way upsteam.

    Dan Cross made a fine point about glob expansions. DOS/Win and unix environments just do things differently.

    Being an NC I don't need to read incoming files and process them. I simply create a fresh segment for net 153 and send it on it's way to my RC. I've been doing that for a year or so and have had no issue. My RC is running Windows if I'm not mistaken.

    I'm sure hope that makenl can import segments and process them as needed. I see
    no reason why it wouldn't/couldn't do that regardless of the OS.

    IMHO, and from my programming experience, I have found the unix environment to be quite more versatile in many ways. Even just
    switching to a different shell would yield new (good) wonders.

    I'm no programmer myself but in the case of makenl, it is very old software. It
    has it's roots in Ben Bakers original work although it may be quite different today. It is available for DOS, OS/2, Windows and Linux. The source is also available so I build my own (only because the authors and maintainers of the software make that easy to do). It has a simple task to do to create the nodelist from the given input and it can do that on pretty much all the OSs in use today, probably can work on a Mac also although I don't know if anyone uses
    it on a mac.

    I think makenl can be made to work on any OS you need it too.. :)

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Dan Cross@3:770/100 to Nick Andre on Sat Feb 1 14:17:43 2020
    On 31 Jan 2020 at 02:31p, Nick Andre pondered and said...

    On 01 Feb 20 03:18:52, Dan Cross said the following to Nick Andre:

    To turn your argument on it's head, perhaps a different interpretation is that people who are interested in experimenting are drawn to Linux and Unix because it's much more open and one can do more with it.

    Sorry, no disrespect, I do enjoy conversing with you - but I refuse to nitpick/quote-rant. Thats not my style of replies and anyone who writes replies to me in such a way just looks like trying to "win" some arguement... theres nothing to turn on its head, because I'm not arguing.

    Eh? Sorry if you misinterpreted it, but I meant "argument" in the
    academic sense, as in that's your position, not that you are in the
    fact of arguing.

    BBS'ing on Linux never really bothers me, Mystic and Synchronet bring newcomers to the hobby. Its the operation of Fido and FTN stuff on Linux that I have seen for over two decades being hit-or-miss. Largely a miss, and having Linux shoved down my throat for two decades by a few of the most insufferable zealots imaginable. So I do have a right to this
    opinion after all this time.

    As I stated earlier, of course you have the right to have your own
    opinion. However, I do not believe that opinion is based on objective
    fact.

    It seems some obnoxious jerks drank the Linux koolaid and were, well,
    obnoxious about it. However, it does not follow from that that Linux
    is bad software, or incapable of supporting high-quality Fidonet
    software.

    However, a position of, "people suggesting -- nay, DEMANDING -- that
    I use Linux and shouting that my preferred solution sucked in
    comparison are jerks, therefore Linux sucks for this application" is
    not a position rooted in objective fact. In particular, nowhere was
    the actual quality, or lack thereof, of the operating system examined.

    "Insufferable zealots" being the most polite way to describe them. It takes a special kind of insufferable zealot to whine at me about MSGID/REPLY because the *lack* of that kludge causes problems for that person's Linux tosser.

    Ok.

    When I start a friendly conversation or reply to someone, and that
    person replies with "Your DOS software is shit" or experiments with
    their system in a way that affects the operation of the network; my disdain for Fido-on-Linux I really believe is valid and logical
    especially after all this time.

    Except it isn't, really. Your disdain is really for zealots or
    careless operators. That's not the operating system's fault.

    --- Mystic BBS v1.12 A44 2020/01/29 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Nick Andre@1:229/426 to Dan Cross on Fri Jan 31 20:29:36 2020
    On 01 Feb 20 14:17:43, Dan Cross said the following to Nick Andre:

    It seems some obnoxious jerks drank the Linux koolaid and were, well, obnoxious about it. However, it does not follow from that that Linux
    is bad software, or incapable of supporting high-quality Fidonet
    software.

    8-) If we were discussing this at the local dive bar, I would happily buy you a round of cheap Canadian horse-piss beer. "Obnoxiousness" is Fido 101.

    If Linux itself was shit, I wouldn't have several instances of it running in a data centre.

    I'm not stupid, I know Linux is technically capable of good Fidonet software.

    Since I do not believe we conversed before, I suppose I could save a lot of verbal ballet by explaining that when I blame something specifically, it should be taken at face-value. Its no different than someone who drives a Ford, then the car breaks down at inconvenient times. "Ford sucks, what a piece of shit". Maybe a bad example but its that sort of frustration.

    Except in my case, the frustration stems from two decades of Linux zealots and being told that Linux is oh-so-perfect and DOS/Windows outright sucks. As I'm having that shoved down my throat, I watch as my DOS mailer (which I am the author of) happily tosses the Linux kool-aid across the entire network.

    Notice I never said "Linux sucks". I just said its not appropriate for the ZC role in Fidonet. Until I am shown a technically-sound solution, I stand by my statement and am more than happy to be proven wrong at any time.

    If you want to continue the "blame the zealots, not the OS", thats fine but this is getting silly; you are obviously very intelligent to understand my overall point.

    Nick

    --- Renegade vY2Ka2
    * Origin: Joey, do you like movies about gladiators? (1:229/426)
  • From mark lewis@1:3634/12 to Nick Andre on Fri Jan 31 20:57:43 2020
    Re: Re: processing..
    By: Nick Andre to Dan Cross on Fri Jan 31 2020 14:31:05


    "Insufferable zealots" being the most polite way to describe them.
    It takes a special kind of insufferable zealot to whine at me
    about MSGID/REPLY because the *lack* of that kludge causes
    problems for that person's Linux tosser.

    the funny thing is that that same tosser would have the same problems if it is compiled for DOS, macOS, or OS/2... seems to me that the tosser dev(s) has made
    assumptions that are not always true and thus the tosser has this particular defect...


    )\/(ark
    --- SBBSecho 3.10-Linux
    * Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)
  • From Nick Andre@1:229/426 to Mark Lewis on Fri Jan 31 21:26:27 2020
    On 31 Jan 20 20:57:43, Mark Lewis said the following to Nick Andre:

    the funny thing is that that same tosser would have the same problems if it compiled for DOS, macOS, or OS/2... seems to me that the tosser dev(s) has
    assumptions that are not always true and thus the tosser has this particul defect...

    It was a pointless thing to try to argue with Ross being my direct Hub at
    that time running that tosser - this was prior to the whole Fidoweb debacle and switching feeds at the time would of been a royal pain. He still would of whined about it along with Blackhole Bob Seaborn and Michiel IPV6-der-Vlist.

    I also noticed that jack shit was being done to stop Synchronet at the time from adding its own kludges to my non-kludged messages that passed through and ended up being retossed. Missing kludges bad but quarterly-dumps of duplicate messages across the entire network from Synchronet systems were shrugged off.

    I caved in and added the kludges; I didn't feel like dragging it on and be known as the "kludge guy" especially while working on a popular mailer.

    But I am the only Renegade system in the world that has these stupid kludges.

    Nick

    --- Renegade vY2Ka2
    * Origin: Joey, do you like movies about gladiators? (1:229/426)