HI Zaba,
Thanks for the interesting note. You are much more adventurous than I am.
;)
I have just a few observations which are triggered by your note about your
troubles [with which I greatly sympathize] and my recent 'fun' engendered
by the latest svgalib update to 1.9.23:
As a trial-and-error pupil regarding Linux I regularly run into
severe problems while updating or changing packages. The last
properly running version has been built as a HD-install with a
Knoppix 4.0.2-EN, svgalib 1.9.23 and lir01-34. The latest version
lir01-35 also works, but exhibits (here) some fuzzy setup issues.
I am of the opinion that upgrading/updating operating systems in general
is fraught with problems. Linux is 'worse' than most in this regard, as
it is non-commercial and we are exposed to 'new' versions before they have
been fully vetted / tested. If it were a commercial product, more testing
would occur before the vendor would let the new versions see the light of
day. We are all 'beta testers' or worse. No commercial venture would
survive if its updates were as problematic as those of Linux. Of course,
no commercial venture would make such raw and buggy updates available to
its customers. I am speaking here of the Linux operating system and its
utilities, NOT of Linrad. I have NO complaints there. Leif has spent
incredible amounts of time working on Linrad for us. He has spent a huge
amount of time because changes in the Linux base have caused problems with
Linrad code that previously worked very well. He is a victim of Linux as
much as we are, although I know that he would never agree to defining the
issue that way ;)
The solution is to use only a stable version of the operating system such
as 'Sarge' in Debian, and to avoid the temptation to experiment. One may
say 'but what fun is that?'. One could say that we can't really complain
if we are using the experimental versions of the software. Even all of
the 1.9.x versions of svgalib are officially 'experimental'. I know that
you know this Zaba, but some list readers may not. The problem as you
know is that in many cases, the 'official' and 'stable' Linux releases
don't contain the device drivers to work with even moderately new
hardware. So one is 'forced' to use the experimental versions.
What I say also goes also for all of the Linux utilities that we
use...svgalib, gcc, and all of their components.
Subsequently (on a couple of PC's) I used the Finnish version of
Knoppix 4.0.2 which had been modified with all possible upgrades
and already included gcc 4.0.2 .... It could not compile either
svgalib or lir01-34/lir01-35. After update/upgrade (gcc 4.0.3)
the situation was unchanged and it reported the preprocessor's
failed sanity check.
I am using nothing newer than gcc 3.3.5 to my knowledge, and have not
encountered these problems. I have no reason to upgrade gcc from that
version. In fact, your experience shows that I have a reason NOT to
upgrade/update ;)
This seems to be an endless problem with new upcoming issues.
This calls again for a dedicated machine with a freeze on the
Knoppix_version side as soon as Linrad is up and running.
See above. This is called 'Open Source'. Microsoft has a very big and
valid point when they make their marketing comments regarding problems
with Linux that are in this vein.
Regarding lir01-35 I ran into problems with the video resolution
(in the working system [with gcc 3.3.6]). I noticed the option
for more specific horizontal and vertical monitor deflection
frequencies. After a couple of guessed sync parameters I ended up
with a very limited selection of resolutions, finally resulting
in choices below 400 pixels. For some reason I did not manage
to re-enter new values and make changes through S or T parameter
routines, ultimately resulting in a jammed Linrad and reboot...
There is an issue with svgalib-1.9.23 as I noted. It turns out that with
1.9.23 Matan has 'advanced' to using lrmi-0.9 from lrmi-0.6 and this does
not handle VESA driver properly. I had to go back to lrmi-0.6 and
recompile svgalib. Matan told me to:
--
Try copying lrmi.c and lrmi.h from svgalib-1.9.21, and changing
LRMI_regs to vm86_regs in vga.h
--
and I did that and now svgalib 'works' again, although in Linrad the text
is no longer erased from the screen as one goes from one menu page to the
next. The jumble of text therefore shown on the screen makes it
impossible to set up Linrad unless you remember what the screens say,
including the choices presented, as you can't read the text. Fortunately,
I have been using Linrad long enough that all of this is very deeply
ingrained even in my very poor memory ;)
The unwanted text also transfers to the receive window, messing up the
waterfall and the spectrum. More Linux progress as we go from svgalib
1.9.21 to 1.9.23 ;)
See above ;)
Thus Linrad still works with the Abit IC-7 and onboard ICH-5 audio
with lir01-34, but not with any newer distros including gcc 4.0.x
Also there is still the "should never happen" error with setad.c
when choosing the 1 RX-channel option (under lir01-34/lir01-35).
Hmmm. I am able to use linrad-01.34 and linrad-01.35 with 1 channel I/Q
with no problem. Is that what you are doing, or are you using 1 channel
non-IQ receiver option, Zaba?
Wonder if we will see all this trouble under the upcoming 'Linrad'
for Windows multi-threaded version. Maybe I'm just dreaming....
As you know, Zaba, it is NOT Linrad trouble, and it is beyond Leif's
control. This is because it is LINUX trouble, and no one can fix it as it
is due to the Open Source, 'anyone can contribute' [well not really but
you know what I mean] nature of Linux. You can avoid it to a great extent
by using only stable versions of the programs and Linux OS, but then you
have the problem that the device drivers in those old versions are usually
very much out of date and won't work with even moderately new hardware.
RIGHT NOW we are in a very good position in this regard with Debian, as
Sarge as only relatively recently moved from 'testing' to 'stable', and so
it is stable but has most of the even-very-recent device drivers in it.
But as we get further out from the date of its being 'locked down', there
will be more and more new hardware that won't have device drivers in Sarge.
I remain ANYTHING but a Linux fan for all of the reasons you note, Zaba.
I put up with Linux ONLY because Leif has written the best SDR / software
receiver program in the world, and right now, it runs only on Linux.
Nothing else would convince me to put up with Linux. I have enough else
that I need to do and like to do that I don't need the 'hobby' of making
Linux work to fill up my free time ;)
It is my belief that with the Windows version, once it is debugged, we
won't have these problems, because it will be run on a stable and
relatively unchanging OS platform with stable drivers.
Those are just my thoughts. I know that others strongly disagree. Those
that disagree tend to be much more computer saavy than I, and much
smarter, and they tend to like playing with software, so that these
problems don't take them so long to solve, and they actually enjoy the
process. At this point, I just want to use my radio [LINRAD]. :)
73,
Roger
W3SZ
--
Roger Rehr
W3SZ
http://www.qsl.net/w3sz