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

20010917: Input on software future, hardware upgrades (cont.)



>From: "Arthur A. Person" <address@hidden>
>Organization: Penn State
>Keywords: 200109131352.f8DDqZ110929 computing platforms

Art,

re: which window manager to use on Linux when running GEMPAK/GARP

>I run KDE and like the snappy Linux/P3 environment also.  Chiz had
>mentioned to me that there was a way to use less colors but I don't recall
>a reference on how to do it.  Can someone forward me specific settings to
>tweak or a reference on it?  I have a bunch of dual boot PC's now that
>have RH 7.1 but we can't use garp on them.  If I can make them work at
>all, that would at least alleviate part of the dilemma.

I will see if Chiz can provide details on how he configured KDE to use
less colors.

re: Cygwin
>I tried cygwin a few weeks ago looking for a free X server for Windows.
>I didn't try to build gempak/garp on cygwin, however.  Instead, I run garp
>from a client Unix system and only use the Windows PC as an X windows
>server display. I installed cygwin/Xfree86 on a Windows 2000 P3 but found
>garp had the same problem as on Linux... can't get enough colors.

OK, Don reminded me that he sent along a note to you some time ago that
he is not able to run GEMPAK/GARP in an 8-bit visual under XFree86/Cygwin
on Windows 2000.

>Other
>applications would run okay.  My guess was that, in 8-bit mode, Windows
>was taking up a lot of colors and cygwin/Xfree86 must share the color maps
>with Windows.

Don agrees.

>If there's a tweak that fixes this, please pass along the
>fix or a reference.

Not that I know of.

>Interestingly, when I run 3rd party X server software
>(X-Win32) it works fine.  I presume the X-Win32 software must use it's own
>color mapping scheme.

It must be using a private colormap.

>But X-Win32 is not freeware and I'd rather use an open solution.

I understand and agree.

re: running separate X server in 8-bit mode while another is running
in 24-bit mode.

>If this means you can only display one or the other application at any
>given time or that it's difficult to get from one application to another,
>I don't think that would work well in most environments.  If the two modes
>can be made to work somehow on the same desktop, that would be preferable.

As I understand things, you have to hotkey between the two X servers.
The displays are not both visible at the same time.  Again, this mode of
running was first brought to our attention by an existing GEMPAK user.

re: if not GARP what?  NMAP

>But it's not certain yet this will run in 24-bit mode, correct?

Again, the word is that NMAP has been accepted as a "baseline" application
for AWIPS.  This would seem to say that it would need to run in 24-bit
mode since AWIPS requires 24-bit mode.

>If we feel sure it will, could you speculate on a time frame?

We asked FSL what they thought about a timeframe for this, and after
noting that they had nothing to do with any GEMPAK/NMAP port effort, they
said that their understanding was that it should be available in the
build that is _supposed_ to be distributed in the December timeframe.

Let me be very clear that Unidata has no part in the software development
effort that would allow GEMPAK/NMAP to run under 24-bit graphics, so
any speculation that we might have on a timeframe should be taken with
bags of salt!

re: Unidata evaluation of FX-Linux
>I recall seeing FX-something running at one of the AMS conferences... this
>is a stripped down AWIPS kind of thing, correct?

FX-Net is a Java client that is probably what you are referring to.  FX-Net
makes requests for products from an FX-Net server.

FX-Linux, on the other hand, _is_ AWIPS.  FX-Linux is the port of AWIPS
to Linux.  Along with the display component, there is a separate set of
software (that may need to run on its own PC; this is one of the things
that we have to evaluate for ourselves) that decodes NOAAPORT data into
AWIPS formats.  One of the big problems we already know of is that the
NOAAPORT datastream that can be processed by the decode component of
FX-whatever is _NOT_ identical to what is flowing through the IDD right
now.  The FX-whatever decoders require the header information attached
to each NOAAPORT product that is being currently stripped off for IDD
transmission.  This is one of the gotchas that we have to evaluate for
our community.

In all, as far as the Unidata community is concerned, there are a number
of big questions related to FX-Linux.  That is the reason that we are
going to get a setup going here at the UPC so we can really understand
the issues.

>If it provides a similar
>look-and-feel to what the NWS uses, I think we would like it as an
>additional package that gives our students exposure to software similar to
>what they would find at the NWS.

FX-Linux is what the NWS will be using as soon as the Linux boxes get deployed
in the forecast offices.

>I guess the bottom line here is:  If I'm going to upgrade with PC's
>running Linux and Windows, I need to know that applications (gempak/garp)
>will work.  If they don't work now, that makes me uneasy committing to the
>upgrade, so I'm looking either for ways to make this work now or
>indications that something will work in the near future (6-9 months, say).

They, along with McIDAS, the LDM, netCDF, and all other Unidata software
offerings, worked nicely during our training workshop held in late July/early
August.

>Thanks for your help...

Again, I will ask Chiz if he has something written down about how he went
through the KDE setup to reduce colors so that GEMPAK/GARP/NMAP worked.
His setup is still in use on the RedHat 7.1 Linux box that is running in
his office.

Tom