[Radiance-dev] Re: Radiance in Debian

[Bernd Zeimetz]

> Installing a package with more than 100 executables in everybodys
> /usr/bin/ is one of the most unpleasant things you can do in this
> context. 

It's not the first and not the last package which brings a lot of
binaries. The only difference is that other large packages try to make
it obvious where a binary belongs to, for example by adding an
appropriate prefix. Which is something I wish for all coming additions
to radiance - please choose an appropriate name, for example rad-foo
instead of foo.

> The standards offer the alternative of /usr/lib/<package>
> exactly for this case.

Right, for programs which are usually not executed by the normal user.
Splitting them doesn't sound like an easy task on the first look, but it
should be possible. But this would also include that all tools know
about the extra path without messing with $PATH.

> Adding two extra paths in an user's
> environment is a trivial exercise. Remember that your target
> audience are Linux users, who do this all the time.

Oh? I haven't touched $PATH for years now, and I wouldn't know any
reason why I should do so. Binaries which are supposed to be executed by
a user go into /usr/bin (or /usr/local/bin, if they're not installed by
a package). To cite the FHS:
/usr/lib includes object files, libraries, and internal binaries that
are NOT intended to be executed directly by users or shell scripts.

And I'm not going to violate that because somebody prefers to hide
Radiance to make it even harder to use than necessary.

> Those people who would fail, just because they don't know how
> to edit their ~/.profile or ~/.cshrc, will not be able to do
> anything useful with Radiance anyway.

Bad enough, this sounds more like something to fix in Radiance. But yes,
I guess people who're able to write a makefile should be able to set
something like RAYPATH somewhere in their environment.

> Don't make life miserable
> for the knowledgeable users because of them.

If you're knowledgeable AND set extra PATHs anyway, it shouldn't be a
problem to set your PATH to a directory where compatibility links are
located (you should even be able to use sed!). Also this is exactly the
damn opinion why a LOT of open source tools are not usable for beginners
- they're only used by 'knowledgeable' people, why the hell should we
make things simple non people with less knowledge? Why add
documentations at all (this does NOT go against radiance - I'm amazed by
the detailed documentation, thanks Greg!)? And so on. If you prefer that
open source software stays something which is usable for knowledgeable
people only, please go and hide in your cave, take the source and
compile it to /yes/I/am/TEH/BRAIN/and/I/have/to/prove/it - you're free
to do so.

> Renaming genbox, with all the contreived workarounds that have
> been proposed, would only solve *our* problem *for now*. But
> because we'd occupy such a large portion of the namespace in
> /usr/bin/, installing there would inevitably cause more problems
> for other package authors in the future. The problems it would
> cause for Radiance users right now have already been mentioned.

A name clash may happen always. For most tools from radiance I don't see
a high chance that this will happen, although there're a few with very
short names which are prone to such problems obviously. But as Debian is
the largest (or one of the largest) distributions, and we had only two
name clashes, I don't see a big problem here. If you'd install _all_
packages (including those in non-free, and packages you can't install at
the same time, and including unofficial repositories like
debian-multimedia), you'd have
0 bzed at hal:~$ apt-file search /usr/bin | wc -l
39033
files in /usr/bin. Feel free to create theories about the probability of
another name clash while looking at the time it took to get those 39033
files into /usr/bin.


> (back into my cave again)

Good idea.


If you prefer to have a growing community Radiance must be attractive
for new users, and as easy to use as possible. With the given examples
and what is shipped in the radiance-materials package a not too dumb
student should be able to create something based on that, which
is/should (imho) at least be enough for an instructional curse.

Something I also thought about was to create a webpage which allows
people to upload photos of materials and the MacBeth chart, so at least
a big enough material base would exist for people (like students/....)
who're interested in learning to use radiance, and who like to have a
nice rendering at the end, but who don't need exact results at the end.
Unfortunately I doubt I have time for that soon.


Best regards,

Bernd

-- 
Bernd Zeimetz
<bernd at bzed.de>                         <http://bzed.de/>