[Date Prev][Date Next][Thread Prev][Thread Next] - [Date Index][Thread Index][Author Index]

[semi-OT] Re: Software platforms / portability


This thread is quite off topic now.
However, there has been a considerable amount of misinformation which
needs to be corrected before closing it.
Gentlemen, please deal with the topic in a matter-of-fact way, spreading
information compiled from half-truths and emotions does not help anybody.
In fact exactly the opposite is the case. People converting from Windows/DOS
to GNU/Linux will be disappointed and go straight back from where they came from.

Linux is for sure the right choice if you are interested in getting work done as
opposed to gaming, watching movies and other multimedia (brainwashing?)
stuff. However, it is not easy to adjust to it. It takes time. After a while users will
notice that productivity increases extensively, due to higher overall stability and
better concept of operation.
The above is true for most common applications, i.e. office tasks etc. and some
special applications. Development is, in contrast to what was pointed out before,
one of them. Using toolkits such as QT, GTK or FLTK will allow you to write platform
independent, graphical applications which - if necessary - can also run on
legacy Windows systems. Coding is much easier because you usually have the
source code of every part of the system and other, comparable applications which
can be considered as examples of how to get things done. Support is much better
through various mailing lists and news groups. Development environments like
Kdevelop provide most of the features of commercial development environments
while retaining platform independence. IMNSHO there is no remaining reason to
stick with M$ products when developing amateur radio products - it will just
cost nerves, a lot of money and is a shame for the Ham radio community as
it proves that in spite of our education we are not able to restrain from hype
spread by the media and certain Company's propaganda departments.
Some developers argue, that writing software for one of the professional
operating systems (freeBSD or Linux that is) will shut most of the community
off from using their software. Even if this was true (which it is mostly not; see
above or take a look at Thomas Sailer's projects) I do not understand the
reasoning behind it. Clearly, it does not make any financial difference when
talking about free software. Becoming known and getting feedback? Well,
what is more interesting, 20 stupid questions per week like "Does it work with
my radio IC-1234, too?" or 2 critical implementation related comments from people
who know what they are talking about? The answer probably depends on some
psychological aspects, too, but I'm sure that #1 will not bring you much further as
far as inspiration and learning outcome is concerned.

So if you plan to develop that new piece of software you had been thinking
of for the last few months, please study the following websites before making
your choice of platform(s) and development tool(s). It will increase the steepness
of your learning curve, make more people happy and increase life span of the
fruits of your time investment.

Excellent Toolkit and free for GPL licensed programs under *NIX, but expensive
for M$-version and commercial applications. No difference in look&feel. Easy
integration into KDE desktop.

Another toolkit, technically inferior but free for every platform. Easy integration
into GNOME desktop.

Another generally free toolkit.

Now some other things:
> Speaking of writing drivers, it should be possible to run the
> Win98/Win2000[1] TCP/IP implementations on top of existing AX.25 packet TNCs
> by implementing an NDIS (network device interface specification) driver for
> the TNC. I've always wondered why none of us have thought to have done this
> [2]- it would then enable all existing apps to run on top of packet
> networks.

This has been done ages ago, and at least twice.
There was one driver which was called "ethax25" or something which did exactly that.
The more sophisticated approach was the TCP/IP NDIS coupler for flexnet which can
be downloaded right from the home page

http://www.afthd.tu-darmstadt.de/~flexnet .

The win32 version was - last time I checked - not yet downloadable.
The ax.25 protocol implementation is the same as in the RMNC version and
the IPAX-coupler supports advanced features such as VJ compression over
AX.25 and the "protocol booster" concept which helps eliminating TCP retransmits
over VC connections.
Summarizing all I have to admit that neither Linux nor any other free or commercial
OS has something comparable, in contrast to what was said earlier in this thread.
Especially the stock Linux Kernel AX.25 has many serious design flaws which lead
to unacceptable performance (mainly due to asynchronous (KISS-oriented) driver interface)
and instability (bad LAPB state machine and messed up code). Especially unsuitable
for low-speed (e.g. 1k2) and communication over unreliable (fading) channels such
as a satellite up/downlink.
I have been maintaining a mostly rewritten alternative stack for more than 1.5 years now
but could not get it into the mainstream kernel due to the code freeze for 2.4 .
Summarizing that I think that Linux is in very bad shape as far as packet radio is concerned
and kernel bloat is not necessarily a good thing. An experimental protocol stack such as
the AX.25 stack for packet radio or future protocol stacks for digital satellite communications
should *definitely* be implemented in user space like FlexNet32. Low latency
concerns can be resolved using the real time scheduler, a synchronous driver interface can
be implemented using RT_NETLINK and AF_* sockets and IP coupler can also be implemented
that way, employing a lightweight kernel module. As a bonus, code can be converted to fit
into different environments again.

So the question is not which OS to choose but how to achieve modularity and portability.
I hope I gave some ideas. As said before, we generally do not have enough resources to redesign
complete software systems and protocol stacks for different OS from scratch. Good planning and
the choice of libraries and GUI toolkits play a big role.

  -- Jens

Via the amsat-bb mailing list at AMSAT.ORG courtesy of AMSAT-NA.
To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org