LJ Archive CD

Letters to the Editor


Owning the Code

I am considering porting an application I have been using and developing since 1984 to Linux, for commercial distribution.

I e-mailed rms@gnu.ai.mit.edu and asked if, in their opinion. I could own my program copyrights if I wrote in C using the gcc that comes with Linux. They said I could practically own my program, except the gpl for libc requires that I make arrangements for my user to recompile my program for use with another version of gpl. I guess this makes it so that I would have to distribute the source code. Not something I would be willing to do (I have to feed my kids).

Do you concur, that it is basically impossible for me to wholly own a program that I might write for Linux? How do the commercial applications sellers who advertise in your magazine avoid that requirement?

Your consideration is appreciated. Thank you.

p.s. For Linux to get REALLY popular, I would think that the writers of the libc and other items would allow free development rights...maybe this is why there are so few popular apps for Linux.
johng@frugal.com

Not a Problem with gcc

While rms is always on the side of “source code should be free”, this is a non-problem with programs compiled with gcc. All you have to do is dynamically link your program (the default for Linux) and you are fine. No requirement for source to be included. See the article on Software Licenses in this issue for the details.

Using Progress at SSC?

On page 25 [of the June 1996 issue of LJ] you write “here at SSC we use the Progress database (now running on Linux) and....” But Progress doesn't run on Linux, Progress Software says and will never run!!! So what do you use? Postgres95, some other tools???

More generally I think it's time to have some article about database tools available for Linux (LJ already did it, but for DB clones only). Now that we have Postgres95, MiniSQL, Yard-SQL, Empress, the choice is hard.
—Vladimir Novikov
vnovikov@starnet.fr

Yes! Progress at SSC

We are using the SCO Unix version of Progress. There is an article on this in the Linux Means Business column in this very issue.

As to your comments about an article on databases for Linux, I think this is a good idea. I will have it added to the “we want an article on ...” list.

A Hex on X?

My friends and I have all found that XF86 is hard to configure. If one doesn't have a well-supported video card, it is confusing because X wants to know silly things like clock cycles, vertical refresh rate, sync frequency, etc. Why does it need to know these things? These specifications are not widely available, and there is no singular authority (this all being free and sensible) to contact to find them, save the original designers. My question is this: is there a non-destructive probing program anywhere?

We ran xf86config several times. First, it asks us about our mouse, which was pretty simple. Then it asks us what video card we have, so we look at the list, but we don't know the type so it ends up being generic. Then it asks for the monitor type. It says that if the sync rates that it will use to probe are wrong (too high) it can fry your monitor. When it probes, it says that the system might hang, and if it does, reboot and don't try again. It hung and we didn't try again.

When we got to this point again, we passed it and it showed me some video modes that might work, and we accepted them and saved it in the configfile. I ran it and it goes through lines of weird stuff, at which point the monitor starts squealing uncontrollably. I hit Ctrl+Alt+Backspace to exit. However, when it goes back to text mode, the text is all fuzzy and not synced, so I shut down ad reboot. We don't think this is a hardware problem. We have a generic video card, generic monitor, no phone number for the vendor, no manual, etc. We have used graphical programs before; most games, svgalib, and even MS-Windows ran the first time through. Granted, if we had an accelerated video card, we couldn't use the features with these apps, but at least it worked. With X, we could probably use these features, but we don't feel that it is an even trade-off of added functionality for those with accelerated hardware, and the loss of functionality for those with generic hardware. We think that the developers should concentrate on making the configuration of X easier, and, if possible, more universal and cohesive for all types of hardware.

Thank you for your time.

Sincerely,
Ethan Wellman Albuquerque, NM

X Un-hexed

While I don't want to justify the current situation or discourage development, I do want to explain why configuration tends to be non-trivial. First, you should always be able to get the VGA X server running. It should come up with any video board and monitor and there should be no potential for frying your monitor.

The problems come about when you are looking for more capabilities: either higher performance or higher resolution. While video cards tend to come with drivers for MS-Windows and such, they do not come with Linux drivers (yet). This means that you have to do the research work.

Monitors that support standard VESA timings can use one of these standard configurations from the X config files. The reason for being able to specify clock frequencies, sync frequencies and such is so that you can tune your configuration for the maximum capabilities of the monitor. For example, a monitor that works with generic 1024x768 resolution might be capable of something more like 1100x900.

Hang in there and, if necessary, settle for less than the ultimate for your hardware. As Linux grows and Linux vendors grow, X configuration will continue to get easier.

LJ Archive CD