Steve Stroh N8GNJ <steve.n8gnj@...>
toggle quoted messageShow quoted text
I think you make my point rather eloquently, when you conflate RAID
storage and an Amateur Radio network. In my experience, if you're
talking about RAID storage, such usage trends more towards the 1%...
as opposed to the 99% of ordinary Amateur Radio users that I expect to
buy the UDRX and want, and use, the apps that will be include in/on
the UDRX. Not to mention the novel (to me) concept of "... security of
the network path itself" in relation to an Amateur Radio network given
the restrictions on using encryption on Amateur Radio frequencies
(that literally anyone can monitor) and resulting distinct LACK of
I have the benefit of having met the developer of the RF portion of
the UDRX, and as a result have every confidence that users like you
that want to bypass the built in apps and use the UDRX purely as an RF
modem, yeah, "it IS in there".
The amateur radio networks that I've seen that will benefit enormously
from the UDRX typically have really basic computers and limited
software and capabilities (such as EOCs with Winlink software talking
to 1200 baud TNCs). With the built-in apps, incorporating the UDRX
into such Amateur Radio networks will be easy - just use a web browser
on the existing PC.
But perhaps we're comparing apples and oranges - as far as I'm aware,
the UDRX is designed for, will be manufactured for, and operated on
Amateur Radio frequencies, by licensed Amateur Radio operators... 99%
of whom probably won't be using RAID storage on their Amateur Radio
I think Northwest Digital Radio IS listening - to ALL the potential
customers for the UDRX.
On Thu, Mar 13, 2014 at 10:44 AM, Michael E Fox - N6MEF <n6mef@...> wrote:
You missed the point.
My point is that all this time spent on defining applications could and should be spent on defining management/configuration screens, status screens, logging, etc. for the primary purpose of this box. This would include screens for OS (disk usage, memory usage, etc.), radio (power level, SWR, etc.), signal levels (including historical), modulation schemes (selection, status, ...), link status, error rates, and bridging function (STP, forwarding status, MAC cache, etc.). If all that stuff is not "IN there" and done well, then the primary function, the ONE thing that we need this box for -- RF bridging -- is not achieved (at least not in a manageable/deployable way). (Just look at a $95 Ubiquity 802.11 radio for an idea of some of the stuff that's needed to actually operate RF bridges in real world networks. Everything else, all your apps, can be done elsewhere/anywhere (and already are). I don't really care if they get added, but we can add linux packages ourselves. What we can't do is develop the management/config/status/troubleshooting screens. That's gotta be done by the folks building the unit. In my opinion, any time not focused on that is time that should be refocused.
And not to put too fine a point on it, but for those of us who do intend to purchase multiple radios and incorporate them into real networks, the user applications will be (or already are) on their own machines with RAID storage, plenty of memory, etc., with their own security. Subjecting a network device to user logins compromises the security of the network path itself. And creating a single point of failure by mixing an application server and a network device would be a real junior level move. To use your percentages, 99% of network design/management folks would never do that. The other 1% are probably unemployed. If you want to play around that way, or use it as an end-user station, that's up to you - it's a free country, and, after all, it's a hobby. But your assertion that only 1% would keep user apps and network function separate is just ridiculous and indicates you've never really run a substantial network.
I've said my piece. The developers can choose to listen or not. I hope they do.