| |
ZL3AI > APRDIG 21.09.06 02:11l 270 Lines 14593 Bytes #999 (0) @ WW
BID : 8785-ZL3AI
Read: GUEST
Subj: [APRSSIG] Vol 27 #18, 1/4
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0NOS<DB0BI<DB0FBB<DB0IUZ<DB0GOS<DB0RES<
LZ4NY<IZ0AWG<IW2OAZ<ZL2BAU
Sent: 060921/0004Z @:ZL2BAU.#87.NZL.OC #:5508 [Waimate] $:8785-ZL3AI
From: ZL3AI@ZL2BAU.#87.NZL.OC
To : APRDIG@WW
Today's Topics:
1. Rant - Cross platform portability (Jim Lux)
2. Re: Rant - Cross platform portability (Gregg Wonderly)
3. Re: Rant - Cross platform portability (Brian Riley)
4. Re: Rant - Cross platform portability (Tyler Allison)
5. Re: Rant - Cross platform portability (Gregg Wonderly)
6. Re: Rant - Cross platform portability (Steve Huston)
7. Re: Rant - Cross platform portability (Rich Mulvey)
8. APRS Link (Robert Bruninga)
9. RE: APRS spec designating nodes (Robert Bruninga)
10. Re: Rant - Cross platform portability (Gregg Wonderly)
11. Re: Rant - Cross platform portability (Brian Riley)
12. Re: Rant - Cross platform portability (Rich Mulvey)
13. Re: APRS Link (John Habbinga)
14. Re: Should Have Read RatShack-Sony GPS RX (Curt, WE7U)
15. RE: APRS Link (Herb Gerhardt)
----------------------------------------------------------------------
Message: 1
Date: Sun, 17 Sep 2006 14:31:22 -0700
From: Jim Lux <jimlux_at_earthlink.net>
Subject: [aprssig] Rant - Cross platform portability
Gregg makes some comments about the availability of software for a variety
of environments, and that triggers some comments about software
development, not necessarily directed at Gregg personally, but at a general
misunderstanding of how and why software gets developed.
The primary thing to remember is that software development is not free.
The developer has to get paid somehow, either in psychic satisfaction or in
cold hard cash. (love or money, as the saying goes) If it's the latter,
it's easy.. he who pays the piper calls the tune. The piper payers have
varying motivations, which will drive what tune they call, be it platform
independence, or Windows for all.
It's the former form of payment, psychic satisfaction, that's a bit more
problematic. The satisfaction often derives from "scratching an itch", and
that itch might not include learning a new toolchain or providing platform
independence. The challenge, if you're funding it from altruism, is in
finding someone for who "the itch" is, simultaneously, the desire for
platform independence AND whatever function you want to perform. Except
for the most trivial of needs, this is a tough hurdle to surmount.
Remember, if it were easy to do, it would have already been done, so the
going in assumption is that the functions you want are non-trivial and will
require some non-trivial amount of work to get them done.
About which more, later.
Gregg Wonderly wrote, in response to some posts about Airmail, a
Winlink interface program:
>I've argued with them about making the choice to write windows only
>software. In this day and age, there is absolutely no reason to do that.
>There are many different common GUI libraries for the C language that make
>multi OS programming possible. There is also Java, which makes it
>extremely trivial to write "runs everywhere" software, with zero porting
>work. I created a project at http://openlink.dev.java.net where I started
>by recreating the airmail UI. It's still pretty bare, because I just have
>too many other things going on. But, anyone who can do the work of filling
>in the actions, can take the GUI that I've created and go at it.
>
>It should be possible to create a very viable PSK implementation in Java.
>However, right now, all the DSP work seems to be focused on windows or
>C/x86-asm environments. That is such a shame to see all that work not
>supporting the whole amatuer radio service.
---
While the sentiments expressed by Gregg are wonderful, there's a fairly big
gap in the ability to do "write once, run everywhere" software, except for
the most trivial of applications. Web browsers are about the closest thing
that you see, and you'll note that there are numerous incompatibilities,
even with fairly simple HTML. There are also "market realities" to
consider, some of which I touched on initially.
But to take in specifics:
>"I've argued with them about making the choice to write windows only
>software. In this day and age, there is absolutely no reason to do that."
-- Sure there is..some very good reasons, especially if your developers are
doing it for free. Windows development tools (Visual Studio) make it very
easy and quick to generate Windows applications that run perfectly well on
Windows platforms, especially if you need tight integration to some Windows
specific functionality (e.g. Windows Media Player). There are very, very
few people who get *paid* to develop amateur radio software, so the
population of programmers doing such work is likely to get paid to develop
to meet some other needs (i.e. cranking out mods to that payroll system at
work, etc.), and, because of the dominance of Windows, the odds are that
programmer is programming for windows. If I spend my 10 hours a day
toiling at work in the Windows development environment, when I turn to my
unpaid amateur radio efforts, I might naturally select to work in the
environment within which life is easiest. If you're paying the developers,
then you'd pick whatever gives you the most bang for the buck, and that's
"Windows everywhere".
Yes, there are cross platform tools, but they are *different* than the
Windows tools I'm familiar with. So now, to generate that wonderful amateur
radio software, I have to not only invest the time in the actual
programming, but I have to learn a new toolchain and all of it's
peculiarities. This is nontrivial, especially since many of the alternate
toolchains come from the Free/Open Source Software environment, many
adherents of which equate the use of MSWin in any form with a sin on a par
with burning a orphanage to the ground. Many of the alternate toolchains
seem to go out of their way to either implement interfaces and conceptual
models that are "different than Windoze, because we all *know* windoze sux"
or, alternately, "Make Windows look like Linux". This is fine if you are a
Linux developer who wants to get something working in the Windows
environment, but is truly a pain if you are a Windows developer. Oddly,
the Linux crowd has not come up with packages to "make Linux look like
Windows", probably because it would be reviled as "giving aid and comfort
to the enemy". Since the programmer population follows the installed base,
guess which conceptual model your would-be amateur radio programmer is more
familiar with?
----
>"There are many different common GUI libraries for the C language that make
>multi OS programming possible."
Possible, but not easy. Use that common library and you might give up some
really useful features of the Windows GDI. Sure, if you want to work in
text mode, almost anything works, but most users demand more flash than
that. Likewise, if you're willing to take the performance hit to work in
X-Windows or OpenGL, you can use that. Many of these libraries also have a
different user interaction model than Windows (because, perhaps, they come
from a different environment: Unix, Mac, etc.). Then, you have a problem
that the users (who ultimately will determine the success of your product)
tend to be Windows users (based on statistics of what OS is running on most
computers), and the X, Y, or Z model of user interaction is different than
the Windows model, so you've basically pushed the learning curve problem
from the few software developers to the many users. On purely economic
terms, this is bound to fail.
---
>"There is also Java, which makes it extremely trivial to write "runs
>everywhere" software, with zero porting work. I created a project at
>http://openlink.dev.java.net where I started by recreating the airmail UI.
>It's still pretty bare, because I just have too many other things going on.
>But, anyone who can do the work of filling in the actions, can take the GUI
>that I've created and go at it."
Java makes portability trivial only for trivial applications. "Zero
porting work" is a pipe dream for most applications. There are several JREs
out there, and they're not all compatible with each other, as much as Sun
would wish it were not so. Java does make it easier, but at some non-zero
cost for processing resources. Java also requires learning a new language
which is very different from traditional C. As you yourself say, "I
started by recreating... pretty bare, because I have too many other things
going on"... The same is true for everyone else. Getting the initial
framework in and working IS trivial. Getting all the grotty little details
is not. It's a lot of time consuming work. People write amateur radio
software as a labor of love, and that love tends to fizzle when it's
tedious and boring.
Your best bet for a Java implementation would be to find someone who
develops Java stuff for a living (therefore they are facile in that
environment) and who is also motivated to take on a large development task
for the benefit of Amateur Radio.
---
>"It should be possible to create a very viable PSK implementation in Java.
>However, right now, all the DSP work seems to be focused on windows or
>C/x86-asm environments. That is such a shame to see all that work not
>supporting the whole amatuer radio service."
Java is not known for high performance computing applications. Sure, there
are Java compilers out there, but they don't generate code with the
performance of straight C, FORTRAN, or ASM code. DSP developers are always
trying to eke out the last percent of performance (because, in their day
job, they're cursed with trying to get 10 pounds of processing into a 5
pound CPU speed sack), so, at least for production purposes, they tend to
gravitate towards languages which get them "close to the hardware" with a
minimum of abstraction. Many DSP applications are latency sensitive, and
things like asynchronous garbage collection just cause fits and starts for
a developer. Sure, with modern computers, you can just "overpower" the
problem by making sure there's plenty of spare CPU cycles, so you don't
care what else is going on. However, the folks developing your DSP
algorithms most likely come from an environment where this is not the case,
and again, you're in the situation where the people with the domain
specific knowledge prefer to work in an environment that is not, for
instance, Java.
As a practical matter, there's a fair amount of DSP code being written
these days in tools like Matlab/Simulink, which can then generate C, which
can then be compiled for your target. I don't know how many different
targets are available, and how compatible they are among platforms.
Probably not very.
---
And, contrary to Gregg's assertion, all that work (albeit for C/x86 asm)
DOES support the whole Amateur Service... Much of the software developed
for amateur uses is Open Source.. yes, the design documentation may be a
bit sketchy, and the code not commented as well as one might want.
However, it's there to look at, and if an ambitious amateur wishes to
implement the function in a different target environment, they've got a big
leg-up on doing it from scratch.
It all comes down to development resources. Software development isn't
free. The developer has to get paid, either in psychic satisfaction or in
cold hard cash. If you have a pile of cash, you can have the developer
develop for whatever environment you wish, be it some proprietary closed
one (Windows) or some cross platform portable nirvana. If you don't have
cash, you can rely on persuasion and appeals to altruism, although, as has
oft been pointed out: persuasion doesn't pay the rent. With sufficient
resources, one can even overcome the inevitable limitations imposed by the
increased abstraction inherent in cross platform portable solutions.
Consider this question: "How much would *you* be willing to pay for cross
platform compatibility?"
Gregg said he'd like it, but isn't willing to pay very much: "because I
just have too many other things going on". Clearly, he's not willing to
spend a lot of money or time to get there. He's willing to express an
opinion, and cast out a hope that through the kindness of strangers, he can
get what he'd like. That's great, because it's what amateur radio is based
on. Many hams have contributed mightily to the fund of common knowledge,
to the betterment of all of us (the fact that it's also part of why you get
to play with that valuable RF spectrum for free, and relatively unfettered
by regulatory oversight, is also in there too). But, wishes won't get the
job done.
Let's say that it would take a programmer, skilled in Java, about 2000
hours (one work year) to build a workable PSK31 application, including
learning the DSP stuff. (or alternately, to get a DSP person to learn Java
and figure out how to do it in a somewhat DSP peculiar environment) That's
only about $250K, if you bought their time retail. You could probably find
someone willing to do it for half that, on the side, if you're willing to
wait a couple years for it (hey, they have their full time day job to pay
the rent).
How many of you would be willing to fork out a proportionate share of that
$120K, for something that will be delivered in 2 years, that might not
actually do what YOU want it to do. Think there's a 1000 people willing to
send in a check, tomorrow, for $120? Nope.. don't think so.
But that's essentially what Gregg (and many others like him) are really
asking... "Please, spend lots of YOUR time, so *I* can get what *I* think
would be a boon to society". I, like Gregg, think cross platform
interoperability would be wonderful. However, I'm not willing to invest
ANY time in achieving it. I've got enough development problems for ham
radio applications in the environments I know to occupy ALL of my spare
time (and then some). I'm willing to design my own stuff so that it's, at
least, not "cross platform hostile", but, when push comes to shove, and I
need to use some sort of funky Windows specific feature to get what *I*
want to get done, done, I'm going to do it, because my "itch" isn't
universal acceptance, but getting my problem solved.
Now, if someone has a bunch o'spare cash lying around (it happens... Paul
Allen has enough cash lying around to build a arrayed radio telescope
costing 10s of million dollars, without a heck of a lot of financial return
to be expected, just out of curiosity.), they're free to fund someone (or
someone(s)) to develop all sorts of cool ham radio oriented software that's
platform independent and high performance, etc. And, we'll all benefit
from that person's altruism.
Cynically,
Jim, W6RMK
------------------------------
Read previous mail | Read next mail
| |
