[nos-bbs] Platform restriction maybe not

[(Skip) K8RRA]

I can't help it Bob, Bill, Steven, and others - I need to toss in on the
platform variation.
And I'll re-title it.

On Thu, 2007-04-19 at 14:11 -0700, Bob Nielsen wrote:

> When I was running the TUS JNOS 1.11f gateway several years ago I had  
> to reboot DOS quite often (memory usage issues, IIRC).  I switched it  
> to Linux and everything was much more stable.

Part of what is going on here is advancement in O/S.  The nos developers
did yeoman duty with DOS.
NOS became unix before unix hit the streets - multi-user / multi
tasking / but in an application, not O/S.

Example?
If you are familiar with getty, and nos did not exist today, you as a
developer of this application from scratch might consider forking getty.
Getty-prime would attach to a TNC like a phone modem and wait to be
"called" - we could name it "netty".
After handshaking and logging in, control would flow to a fork of "bash"
- called "nash"?
The sysop functionality would be a daemon "hamrad" to support broadcast
activity and the like, plus allow control to pass in from netty.
Mail? - it is already built into the system as a command / nothin to do?
The point here is that the O/S provides more underlying services than
DOS, Hamlib or no Hamlib, and with them you achieve similar application
services.
Configuration stuff would naturally be put into /etc/hamstuff/ directory
structure.

My point is *not* that we should implement this - it is that we have
something of a parallel universe going on here.
Remember "Star Trek"?  They had their other universe too.
So Steven observes the effects of this parallelism - difficulty in
adoption / some compromise / a new vocabulary.
And others observe some of the benefits.
Now in 2k, DOS remains usable but is passing into obscurity.
It's a valid choice to pick what is familiar to you - until what is
familiar to you no longer works for reasons out of your control.

> 
> Actually a node application for Linux with JNOS-like functions (more  
> so than AWZnode, etc.) using kernel AX.25 and networking wouldn't be  
> a bad idea.

So Bob presents another of the alternatives in architecture.  And when
you (Bob?) as a developer consider the difficulty in maintaining a
multi-platform application you end up making your choices - whatever
they might be.  Mind boggling?

And Bill correctly introduces the "virtual" concept.  Has anyone got
multiple jnos running on one host?  Why not - other than lack of need?
And virtualization is a moving target too.  With the new "zen?" the
hardware is virtual and multiple O/S run on one hardware without
emulation.  Thus wine and zen become another toss-up.  Has anyone tried
DOS & jnos on top of zen yet?  Mind boggling?

I for one (we?) am happy for the application, the swiss-army-knife of
packet radio, and the multi-platform fit on various computers.  I expect
the platform choice to expand as it has in the past, as long as
developers have interest in the basic "goodness" of nos.  And of course
there are alternatives (wl2k?) that offer the challenge decisions like
"interface to" or "adopt".  Mind boggling?

And there will be change in underlying technology.  Examples - Maiko's
prototype of TCP/IP-over-the-air, and TAPR potential changes to AX.25.
Mind boggling?

> 
> 73,
> Bob, N7XY

So why do I wax philosophic?

I'm now engaged, as some have seen, in wiki creation.  My objective
began as an exploration of jnos facility, and it has morphed into
collecting and integrating the "body of experience" with jnos (nos?).
By the time I reach a personal "finish", I expect the wiki will serve me
as an application document including features like search engine and a
wealth of variation in application.  Philosophy is important to me up
front.  How jnos (nos?) became what it is today effects:

        FIRST  my choice to adopt it for my use (it's deeper than
        feature set)
        SECOND  my choice of how to install it into my world
        THIRD  my interaction with the community of like-minded users

The wiki *might* have the potential to de-boggle the mind...

And I'd like to share the wiki with this community.  OK - Steven, Bill,
Bob, and many others have no need for it today.  Most users have already
collected what works for themselves by the time jnos works well enough.
My hope though is; for example if and when Steven chooses to dabble in
jnos-on-Linux he will find the wiki useful at that time.  And maybe for
him it never will - that's very much OK.  For the new user, and the guy
who wants to make a change, I hope he finds it as useful as I have.  For
the non-user - I hope the wiki reads easily enough that he will give
jnos some consideration and not be disappointed in the reality of jnos
sysop..

I have no interest in promoting one platform over another, experiences
from any platform is useful.  Remember the gum-shoe: "All I want is the
facts ma'am"?  I am for example participating on the fringes of a group
with many DOS installs.  I hope to include enough configuration data
that this group will have another resource available from which to pull
material for newbies to the group.  I'd like to see more users as
successful (or more successful) than myself.  To make that happen, all
platforms need equal treatment.

I do however have the interest in validating wiki material.  This
interest is where the "restriction maybe" thread evolved from on this
reflector.  There is some small obscure detail that permits the
configuration on his LAN but defeats it on my LAN.  It is my opinion
that the detail is worth discovering and documenting on the wiki so
others do not repeat my frustrating experience.  Like Monopoly - proceed
directly to "go" and collect $200 / if you read the wiki after
describing the feature is done.

At this point I'll commit making wiki available 24/7 to anyone who has
interest.  As long as there is a community with interest, I'll do what I
can to keep it useful.  When I'm done I'll pass it on to someone else
with capability.  Of course I welcome material of others to make the
wiki better, as Steven has already done.  SO - have at it if you want
to.  The wiki will remain a work-in-progress.

In the mean time - thanks to this community for the ideas that have
changed hands.  And yes - the conflict too.

73
de [George (Skip) VerDuin] K8RRA k
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/nos-bbs_lists.tapr.org/attachments/20070420/f9a953c6/attachment.html>