[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linrad] Re: gcc 4.0.x / lir01-35 ; Re: [linrad] Re: Linrad on a Debian System ??

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 comercial 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]. :)



Roger Rehr

This message is sent to you because you are subscribed to
 the mailing list <linrad@xxxxxxxxxxxxxxxxxxxxx>.
To unsubscribe, E-mail to: <linrad-off@xxxxxxxxxxxxxxxxxxxxx>
To switch to the DIGEST mode, E-mail to <linrad-digest@xxxxxxxxxxxxxxxxxxxxx>
To switch to the INDEX mode, E-mail to <linrad-index@xxxxxxxxxxxxxxxxxxxxx>
Send administrative queries to  <linrad-request@xxxxxxxxxxxxxxxxxxxxx>