<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.12.3">
</HEAD>
<BODY>
I can't help it Bob, Bill, Steven, and others - I need to toss in on the platform variation.<BR>
And I'll re-title it.<BR>
<BR>
On Thu, 2007-04-19 at 14:11 -0700, Bob Nielsen wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">When I was running the TUS JNOS 1.11f gateway several years ago I had </FONT>
<FONT COLOR="#000000">to reboot DOS quite often (memory usage issues, IIRC). I switched it </FONT>
<FONT COLOR="#000000">to Linux and everything was much more stable.</FONT>
</PRE>
</BLOCKQUOTE>
Part of what is going on here is advancement in O/S. The nos developers did yeoman duty with DOS.<BR>
NOS became unix before unix hit the streets - multi-user / multi tasking / but in an application, not O/S.<BR>
<BR>
Example?<BR>
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.<BR>
Getty-prime would attach to a TNC like a phone modem and wait to be "called" - we could name it "netty".<BR>
After handshaking and logging in, control would flow to a fork of "bash" - called "nash"?<BR>
The sysop functionality would be a daemon "hamrad" to support broadcast activity and the like, plus allow control to pass in from netty.<BR>
Mail? - it is already built into the system as a command / nothin to do?<BR>
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.<BR>
Configuration stuff would naturally be put into /etc/hamstuff/ directory structure.<BR>
<BR>
My point is *not* that we should implement this - it is that we have something of a parallel universe going on here.<BR>
Remember "Star Trek"? They had their other universe too.<BR>
So Steven observes the effects of this parallelism - difficulty in adoption / some compromise / a new vocabulary.<BR>
And others observe some of the benefits.<BR>
Now in 2k, DOS remains usable but is passing into obscurity.<BR>
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.
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Actually a node application for Linux with JNOS-like functions (more </FONT>
<FONT COLOR="#000000">so than AWZnode, etc.) using kernel AX.25 and networking wouldn't be </FONT>
<FONT COLOR="#000000">a bad idea.</FONT>
</PRE>
</BLOCKQUOTE>
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?<BR>
<BR>
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?<BR>
<BR>
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?<BR>
<BR>
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?
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">73,</FONT>
<FONT COLOR="#000000">Bob, N7XY</FONT>
</PRE>
</BLOCKQUOTE>
So why do I wax philosophic?<BR>
<BR>
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:<BR>
<BLOCKQUOTE>
FIRST my choice to adopt it for my use (it's deeper than feature set)<BR>
SECOND my choice of how to install it into my world<BR>
THIRD my interaction with the community of like-minded users<BR>
</BLOCKQUOTE>
The wiki *might* have the potential to de-boggle the mind...<BR>
<BR>
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..<BR>
<BR>
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.<BR>
<BR>
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.<BR>
<BR>
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.<BR>
<BR>
In the mean time - thanks to this community for the ideas that have changed hands. And yes - the conflict too.<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<BR>
73<BR>
de [George (Skip) VerDuin] K8RRA k
</TD>
</TR>
</TABLE>
</BODY>
</HTML>