glut (no-menu) interface

[fyawitz]

I'm really impressed with Celestia and I hope you continue to develop it!
I'm running a slightly old Linux system and I only was able to build Celestia with the glut interface, so I only have keyboard controls. It seems that a few things are missing from the keys that are available, in particular there seems to be no way to open a script using the keyboard. Also, the suggestion in the documentation that the way to modify Celestia's functioning is to edit the .cfg or .cel files in the installation directory isn't really appropriate to a Unix system or any system with any security. I'm considering hacking the source a bit to add the keys and perhaps a command-line option to start a script or use a different config file, but if the authors are willing to do these simple things I suppose it would be preferable.
Thanks again for a great program

Ephraim

[selden]

It is expected that Celestia will be installed in the user's directory, not in a system directory, so all configuration and catalog files are editable. Celestia requires no special privileges. It is designed to have all of its addons in its own directory tree and is not designed to be a multiuser program. As you'll discover, Celestia is tiny compared to the size of the Addons you'll be installing, and you'll wind up with several different versions of Celestia installed simultaneously anyhow.

There already is a command line option to run a script at startup, although it isn't very mnemonic:

Code: Select all

./celestia --url script.celx


"--url" works with either a script filename or a url.

[andersa]

It is expected that Celestia will be installed in the user's directory, not in a system directory, so all configuration and catalog files are editable.

I feel rather old reading this, as I began using Unix when personal computers were still mostly regarded as toys in comparison (1982). To me, a decent operating system is multiuser from the ground up, and application software in general should not require being installed with all files writeable (I do system administration for a living).

I haven't tried installing Celestia under Unix myself so I don't know if I'd really object to anything, but the inability of the software to distinguish between "system" and "user" files easily scores a minus point with me. Preparing a computer lab for 30 students who are expected to run the same package simultaneously quickly turns into a headache when you discover that the system starts by copying 1 GB of static data files to the user's home directory with a 100 MB quota on the file server (that was a lot of disk ten years ago).

Celestia requires no special privileges. It is designed to have all of its addons in its own directory tree and is not designed to be a multiuser program.

A multiuser program is one where multiple users interact with each other, not just any program installed on a multiuser system. Celestia of course isn't a multiuser program, but neither is cat(1) or emacs(1); nor do they require any special privileges. Yet they are installed in system directories on any Unix system (unless you are personally involved in developing them, of course).

Or you could even say that the need for users to modify installation files is a special privilege that Celestia requires. It's the user's home directory that is special here, not the system directories.

As you'll discover, Celestia is tiny compared to the size of the Addons you'll be installing, and you'll wind up with several different versions of Celestia installed simultaneously anyhow.

It's not the size of the executable binaries that matters most, but the mess of dealing with unnecessary copies of everything. Having several different versions of the software installed is not a problem; we do that in system directories if required by the users. Having 1,000 users installing the very same versions in their own home directories is a bad idea though.

I don't regard the educational environment I'm used to as universal, and I'm not asking Celestia developers to start sorting these issues out now, as it's hardly a top priority. However, the ability to install any software package just once for your entire network rather than once per user is not a bug, but a pretty basic feature.

[t00fri]

It is expected that Celestia will be installed in the user's directory, not in a system directory, so all configuration and catalog files are editable.

I feel rather old reading this, as I began using Unix when personal computers were still mostly regarded as toys in comparison (1982). To me, a decent operating system is multiuser from the ground up, and application software in general should not require being installed with all files writeable (I do system administration for a living).

Don't worry, I started even earlier with UNIX . Let me note that Celestia is completely configurable by means of the ./configure scripting package under UNIX/Linux. It conforms entirely to modern standards in this respect. Linux distributors make widely use of this fact...

Also under Linux, making ample use of symbolic links avoids largely to deposit multiple copies an the HD...

Bye Fridger

[andersa]

Also under Linux, making ample use of symbolic links avoids largely to deposit multiple copies an the HD...

I know, but I regard that as a kludge to simulate a full software installation in the user's directory, when the software is clearly not aware of the system/user file distinction. I have used it myself when building binaries from read-only source trees, and eventually the make(1) process will fail anyway when trying to rewrite some tiny text file. I doubt make(1) was intended to deal with all that horrible abuse it has suffered over the years.

Any program that allows configuration by the user should at least be aware of the distinction, and know where to look for files. If it can merge site-wide configuration settings with user settings, that's an added bonus point. A popular way of achieving this in Unix is the application "somethingPATH" variable. When using the X Window System, X11 resources provide another mechanism, but I haven't played with those knobs for several years now and I'm not familiar with current fashion trends.

Back in the 1980's, I recall helping one of our commercial software providers port his MSDOS-born cross-assembler to our TOPS-20 timesharing system. Instant lesson #1 in the multiuser environment: When opening an object library file for linking, use read-only rather than read/write access! So that's why old PCs tended to mangle random system files the users could swear they had never even heard of, long before those machines were hooked up to virus.net..?

[fyawitz]

Thank you to Anders Anderson for saying much of what I wanted to say. I felt it would be ingrateful to the generous authors of the program to begin my membership in this forum with a tirade about how Celestia doesn't fit with the 'Unix philosophy' (not that Anders wrote a tirade). Thanks again for the beautiful program, and I am considering trying to work on its development.

./celestia --url script.celx
[/code]This doesn't work for me. All I get is "invalid option". I can't see where this option would come from since the code in glutmain.cpp only looks for one command-line option, "-v".

"--url" works with either a script filename or a url.[/quote]

[selden]

Sorry: I had the mistaken impression that the command line options were the same for all of the compilation environments

[fyawitz]

I should be embarrassed. The --url option is in the winmain file but not in glutmain. Maybe I'll just copy it over there.

[Harry]

I agree with the OP: Celestia doesn't work like a Unix programs should, i.e. read the configuration file from the user's home directory (and fall back to the system-wide config file if not found). This may be a non-issue for people compiling & installing Celestia themselves, but it can be a problem if Celestia comes preinstalled. You really shouldn't need root just to install Addons.

However just reading celestia.cfg from the home directory isn't a good solution, as all paths still have to be changed. Maybe it would help if you could specify the working directory for Celestia as a command-line option?

Harald

[andersa]

This may be a non-issue for people compiling & installing Celestia themselves, but it can be a problem if Celestia comes preinstalled. You really shouldn't need root just to install Addons.

Would Fridger's suggested workaround (tweaking installation parameters by means of ./configure) solve the problem? If so, someone affected by the problem could work those parameters out and provide the rest of us with a list of things to do. When this fix is deemed ok by Unix users, the developers could incorporate it into a subsequent release.

And I agree completely that this isn't a support request aimed at anybody in particular; the developers deserve every token of appreciation they can get for contributing their time and effort free of charge. As a relative newcomer in this forum myself, I don't even know who the contributors are, though I can probably find out if I look.

I became interested in astronomy already as a kid, and I was underwhelmed by the ridiculously small amount of astronomy education I received in school (maybe we spent at most one week out of nine years studying the solar system, and that was it). We didn't have any computers either. I don't know how the schools use their computer labs today, nor whether they teach astronomy, but Celestia sure looks like a very good educational tool. It would be a pity if schools rejected it merely for being impossible to install in their multiuser environments, where you can't expect users spending even five minutes each making their own installations; it has to run instantly or class is essentially over. Now, maybe very few schools rely on Unix anyway, but we sure don't want Celestia to be a limiting factor in their choice of operating system. Software should remove limits on what you can do, not add them.

[Christophe]

Just to clear things up, Celestia does work in a multi-user environment, it just doesn't provide full configurability at the user level. This is especially annoying with the GLUT version since it doesn't provide configuration context other than that provided by the celestia.cfg file.

This is probably why this hasn't been fixed yet, there aren't that many users using the GLUT version.