'Zaba' OH1ZAA wrote:
>
> Hi Roger!
>
> Thanks for your detailed commentary. It is hard to disagree with any
> of your comments, as it represents my general experience with Linux.
Hello Zaba,
I would not like to start a fight here, but I have been a very happy
Debian GNU/Linux user during the past 3 years. I do not miss windows at
all and I even think that changing to Linux is one of the best things I
have done in computers.
>
> If I would have spent as much time with Linux as with DOS/Windows for
> the last 20 years, then my views would be also quite a bit different.
> Leif cannot be blamed indeed, but I am afraid that he will run into
> another iteration loop with gcc 4.0.x just after he has adapted the
> Linrad code for smooth compiling under gcc 3.3.x ... Let us assume
> that gcc 4.0.x is still broken, and will 'make' the oldies soon..?
>
> The reason that I have taken an adventurous approach is: that I have
> multiple machines for experiments, and with the present routine it is
> possible to re-install a Knoppix system within one hour, including the
> svgalib and linrad software, all ready to go (but not really.... hi!).
I think that the problem is that one has to have in mind that Knoppix is
NOT a rock stable Linux. Knoppix is a Debian based mixture of testing
and stable. I think that the best thing is stick with a Debian stable
release. Now Debian sarge is working here like a charm.
We also are always playing with "experimental" svgalib versions and
because of that, stability is not as good as desired.
>
> Actually I am running Win2k and Win_XP with all kinds of browsers in
> parallel, even four versions of Opera. I know that it would be possible
> in Linux to have several versions of gcc on the hard disk, but during the
> update/upgrade process that I now, usually the previous version is replaced
> by the new one. I guess that svgalib and lir01-35 will compile and run fine
> even on most newer versions of Linux, when installed using an older gcc.
> But that is one of the many things to find out and learn. I have not even
> taken the trouble to really find out what is experimental and what is
> stable
> in Linux, so that certainly proves that my own approach is experimental!
Being experimenting with everything is a good way of learn, I have also
learned Llinux that way, but you have to be brave and if you live on
the bleeding edge problems arise easily.
I have several gcc versions, Debian Sarge comes with some of them. I
could change to Debian "testing" and get the new gcc compiler, but I
will not change to "testing" until the next realease is about to come
(expected at the end 2006). Having the last of the last of the last
version is not a good thing.
ea1abz@debian-remix:~$ dpkg -l | grep gcc
ii gcc 3.3.5-3 The GNU C compiler
ii gcc-2.95 2.95.4-22 The GNU C compiler
ii gcc-3.0 3.0.4-7 The GNU C compiler.
ii gcc-3.3 3.3.5-13 The GNU C compiler
ea1abz@debian-remix:~$
>
> Regarding parameter setup I do not run into jumbled screens, but into a
> very limited selection set of screen resolutions with low pixel values.
> After choosing one of these low pix values even the smallest font size
> selection is not accepted and there is no way to jump out of the loop.
> The interesting thing is that I have not been able to alter the H/V
> sync frequencies after a reboot, to find a new set of resolutions.
>
> Thanks again for the very informative remarks and philosophical
> pondering on the "necessity" of updating/upgrading with Linux!
>
> 73, "Zaba" OH1ZAA/2
>
>
> P.S. The setad.c -error does not occur indeed with an I/Q-system
>
>
>
> At 08:56 30.10.2005 -0500, W3SZ wrote:
>
>> 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
>
>
>
>
> #############################################################
> 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>
>
>
#############################################################
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>