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)