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

[linrad] Re: Fedora 3



> I read the comments about about fedora.  Seemed to me that swapping
> distributions is a very round about way to change a crontab entry.
> Why not simply stop the anoying background task?
It is not easy under Fedora 3. Just stopping chron and anachron
will cause system crashes after a while. I have spent a lot of
time trying to figure out how to make chron/anachron not
launch updatedb but I was unable to do it. The big problem
with Fedora (like Windows) is that control information is stored
at several places and that the system decides that it knows better
than me so it will occasionally overwrite my changes and restore
the "important" system functions (like automatic launching of
updatedb)

Under oldfashioned distributions it is trivial to remove a
chrontab entry and get rid of the updatedb problem. With
Fedora 3, even with knowledge of how to get rid of updatedb
there is the Hal problem. Stopping Hal is trivial but I am
told it is not safe. I am adviced to add something in the
configure script to find out whether Hal is present and then
add a few lines in Linrad to tell Hal to stay quiet as long
as Linrad runs. I do not know how to do it. I will be happy
to include such a feature if someone else gives me the code
but until then I simply advice people to avoid Fedora 3.

> Linrad use "svgalib" for graphic.  This is a linus-only graphic
> library that writes directly to the graphics hardware.  The use
> of savgalib is likely the biggest reason linrad is not in more
> common use.  svgalib is mostly obsolite and only supports certain
> hardware cards.
>
> Yes, Solaris, Mac OSX and BSD all have advantages over Linux and
> well written software should not care which OS it is running under.
> People have talked about porting linrad but it would really be a
> re-implementation
Oooh! Linrad is just a non-programmers way of showing what is possible.
I do not think many amateurs who suffer from QRM are aware of the
implications of the new algorithms within Linrad. I do not think
anyone yet has used the full capabilities of the system to make
radio operating possible in locations where it would be quite
impossible with any other reseiver.

There will be many re-implementations in the future. The way Linrad
overcomes all the difficulties with bugs in various versions of
sound drivers and Linux distributions is gradually becoming obsolete
and many other complications that have historical roots can and
should be removed to make the essence of the Linrad package
easier to understand and use.

I am working on a re-implementation right now. The goal is to make
a multi-threaded package that will work at least under Linux/X11,
Linux/svgalib, Microsoft Windows and possibly Macintosch. Bob, N4HY
has promised to help in this but right now it is in an early stage
so I do not know what the implications might be.

I do not think X11 or Windows will be competitive at all on small
computers. Just getting X11 running on a normal PentiumI takes forever
because the limited memory available makes most of the activity
happen in the swap file on the hard disk.

73

Leif / SM5BSZ
>


#############################################################
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>

LINRADDARNIL
n