kwm <[EMAIL PROTECTED]> writes:
> I'm saying also that there are now programs that are being
> developed under Linux, for Linux, even though they have
> been ported to other platforms. Sure, it isn't Linux
> specific, per se, however, if it is being developed on
> Linux, for a primary Linux audience, then it needs a
> Linux book?
Well, probably not. Take an example: I don't know what the GIMP was
developed on (Linux? It would have been almost as easy to develop
different parts in parallel under different versions of UNIX. I've
done development work under linux for programs that were intended to
run under Solaris -- it's usually not a big deal). Even if you wrote
a book that only covered the GIMP, and even if you only meant it as a
Linux book, it wouldn't make any significant difference what operating
system (well, UNIX OS, I mean) I happen to run it under, it would be
just as useful. Short of site specific differences, there's really no
significant difference between running, building, or installing the
GIMP under Solaris or Linux (very different flavors on the inside)
that wouldn't be dwarfed by site-specific ideosyncracies.
My setup at work (Solaris) is probably far more similar to my setup at
home (Linux) than my set up at home is to your Linux box. Until you
start worrying about things like how you install X, how you get your
sound device to work, how you install the actual operating system, the
differences between flavors of UNIX is usually cosmetic. Relegating
them to an appendix for unusual cases where the version matters is
quite appropriate and usually sufficient.
RPM is of course one of those things that are a special case -- you
don't use RPMs for any other operating systems (as far as I know). In
cases where this is true, it does have to be a linux book, but most
graphics programs, musical programs (I'm guessing, I don't mess with
sound) and so forth are pretty darned platform independent.
If you wanted to write a GIMP user's manual for linux, that's fine,
but you'd really be limiting your market unnecessarily. (^:
> > As I see it, there's also a middle ground covering topics such as
> > "Graphic Design with Linux", "Musical Composition with Linux", "Web
> > Authoring with Linux", "Rendering with Linux", "Writing, Editing, and
> > Publishing with Linux" that cover a specific subset of apps (with
> > perhaps a section about configuring the appropriate part of the OS to
> > make it a truly Linux book). That's what I was trying to get at with
> > the "Artist's Linux Handbook" example. I think this is also what
> > you're looking for, and I think it wouldn't be a bad idea at all. Not
> > to mention that this would help people to realize that it was possible
> > to do all of these things under Linux. (^:
>
> Take a look at LINUX Multimedia Guide. It is a general overview.
> The books you are suggesting are good ideas! The Multimedia Guide
> suffers from trying to cover EVERYTHING. Each mention of a program,
> or of a group of similar programs could use several chapters in
> a book (for small programs), or a full book for larger programs.
I haven't seen the Multimedia Guide, actually. It's not the sort of
book I could really use, as I don't do anything but graphics and I've
already built my current server to do nice 24 bit X. Not to mention
that the Metro-X that comes with Red Hat (which was my baseline
install) is spiffy and amazingly painless to install (I was very
impressed after what I had to go through to get X working on my older
machines).
> Part of the problem, as I see it, is that there are so many neat
> little programs out there, that overlap, and do the same sort of
> things. They get lost in the crowd. The energy is dissipated.
> If an astute author decided to do a book on, say, composing music
> with Linux, should he try to cover every music program available,
> or would it be better to test them all, and decide on doing a
> couple of the better ones in-depth, and giving an honorable
> mention to the rest of them? Not to slight any program... however,
> at some point, the wheat needs to be separated from the chaff...
> <grin>
>
> We certainly don't want to discourage any freeware authors from
> writing apps for Linux. However, with literally hundreds of
> programs out there for Linux, how do you know which ones
> are worthy of the time to install and learn them? Some
> people enjoy tinkering with new little programs all the time.
> Others would like to cut to the quick and use this fantastic
> OS to actually produce something. How nice it would be to
> have at hand, a book that would concentrate on those apps
> that have already been tested and proven (preferably by
> expert in the field) and are then documented, in-depth.
Maybe the subjects for books I suggested are a little broad and could
use futher pruning, but what I'd do is pick a few important apps and
go into depth. Say that you did a book about publishing under linux,
I'd cover something like:
(1) Getting printing to work under linux
(2) Emacs: how to compile, install, and how to use it -- including tying
in how to print stuff from it
(3) TeX/LaTex: how to compile, install, and use them -- tying in how to
use them and automate things from Emacs and get your stuff to the
printer
(A) (maybe) an appendix on setting up ghostscript for non-postscript
printers, a fairly common and useful thing.
Stuff for doing figures, illustrations, other editors, etc., would get
honorable mentions. (^:
On reflection, that's probably not a great topic (most of those things
have been covered in depth in other places), but tying it all together
could be really useful thing and might make for a useful reference for
somebody who just wants to jump in. It would also break things up
nicely for collaborative efforts.
doubt
--
Douglas Triggs -- Sysadmin, Toolsmith, and Certified Crazy Person
[EMAIL PROTECTED], [[EMAIL PROTECTED]] http://www.lensflare.com/~doubt
