A valid question in two parts -

  What benefit, if any, is there to running Pov under unix or one of it's
incarnations ?


  What drawbacks are there, if any, to running Pov under unix or one of it's
incarnations ?

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote:
:   What benefit, if any, is there to running Pov under unix or one of it's
: incarnations ?

  Unix is better than windows as an _operating system_ (which doesn't mean
it's a better GUI). That is, it's more stable, it manages memory and
swap better, it manages processes and threads better, etc. It may run
povray faster, but the main advantage is that if you have to do other
things at the same time (like running a server), they will run much more
smoothly.

:   What drawbacks are there, if any, to running Pov under unix or one of it's
incarnations ?

  You have to learn how to use unix, and that's a lot more difficult than
learning to use windows (even if you are going to use only a window
manager). There's also a lack of win95-only utility programs (well,
they might work in a windows emulator...).

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Nieminen Mika wrote:

> Ken <tyl### [at] pacbellnet> wrote:
> :   What benefit, if any, is there to running Pov under unix or one of it's
> : incarnations ?
>
>   Unix is better than windows as an _operating system_ (which doesn't mean
> it's a better GUI). That is, it's more stable, it manages memory and
> swap better, it manages processes and threads better, etc. It may run
> povray faster, but the main advantage is that if you have to do other
> things at the same time (like running a server), they will run much more
> smoothly.
>
> :   What drawbacks are there, if any, to running Pov under unix or one of it's
incarnations ?
>
>   You have to learn how to use unix, and that's a lot more difficult than
> learning to use windows (even if you are going to use only a window
> manager). There's also a lack of win95-only utility programs (well,
> they might work in a windows emulator...).

Well to address the pro and con a little more, I can respond directly to the last
comment.

There is a major lack of Win95 utils on Linux. But then again, there is a major lack
of Linux
apps on Win95.

Once you start to get the hang of things like the Gimp, Emacs, The Gimp, etc., Linux
can be lots
o' fun. Also, there is a huge assortment of opensource utilities on Linux. Also,
piping output
from one stage of your work to another, including all sorts of nice post-processing
can be quite
easy, especially with a real command shell like bash, tsch, etc.

Take a peek at http://freshmeat.net/ sometime just to get a feel for some of the
utility progs
that are being worked on.

On the other hand, if there are some nice Win95 only tools that you use a lot, and
actually
can't find replacements for under Linux, it could be a major con.

Post a reply to this message

Ken wrote:

>   What benefit, if any, is there to running Pov under unix or one of it's
> incarnations ?

1) If you want to play with the source, you don't have to pay hundreds
of dollars for the development tools.  Free compilers, debuggers, etc.
are all more readily available for Unix than they are for most other
platforms.

2) While you're at it, a lot of those tools (and similar tools, such as
scripting languages) work well for generating scene description
language.

3) Better scripting languages for automating ray-tracing.

4) It's generally been faster (though POV-Ray 3.1 for Windows will run
faster on Intel Pentium II's on account of MSVC++ having superior
Pentium II-specific optimizations than gcc).

5) Better support for clusters (PVMPOV).
 
>   What drawbacks are there, if any, to running Pov under unix or one of it's
incarnations ?

1) Shortage of modeling utilities (this is the big one right now).

2) Lack of a GUI front end (most useful for novice users).

3) Most of the advantages above are only useful to advanced users.  

There have been various unofficial GUI front-ends that do nothing more
than figure out what command line you want to run and run that (though
none are current so far as I know), and there are various versions of an
emacs mode that offers many of the benefits of the integrated editor
from the Windows version.  At this point I don't anticipate an official
Unix GUI interface, integrated editor, or emacs mode any time soon. 
People who really need GUI front ends aren't typically using Unix. 
Maybe in a few years it will be necessary.  It probably wouldn't have an
integrated editor, though it might be made to open files in a
user-defined editor.  The last thing Unix needs is another text editor.

In summary, novice users, especially those unfamiliar with Unix, are
probably best off not using the Unix version and should instead use the
version that runs on the platform with which they have the most
experience.  Experienced users, especially those familiar with Unix,
will find that it offers some unique benefits.

-- 
Mark Gordon
mtg### [at] povrayorg

Post a reply to this message

Mark Gordon wrote:

> There have been various unofficial GUI front-ends that do nothing more
> than figure out what command line you want to run and run that (though
> none are current so far as I know), and there are various versions of an
> emacs mode that offers many of the benefits of the integrated editor
> from the Windows version.  At this point I don't anticipate an official
> Unix GUI interface, integrated editor, or emacs mode any time soon.
> People who really need GUI front ends aren't typically using Unix.
> Maybe in a few years it will be necessary.  It probably wouldn't have an
> integrated editor, though it might be made to open files in a
> user-defined editor.  The last thing Unix needs is another text editor.

After looking around for a bit, I have found at least one current
front-end under active development.

-- 
Mark Gordon
mtg### [at] povrayorg

Post a reply to this message

Nieminen Mika <war### [at] cctutfi> wrote:
> swap better, it manages processes and threads better, etc. It may run
> povray faster, but the main advantage is that if you have to do other

It (i.e. Linux/FreeBSD/other x86 unixes) does run POV faster than any
Microsoft OS would on the same hardware.

>   You have to learn how to use unix, and that's a lot more difficult than
> learning to use windows (even if you are going to use only a window
> manager). There's also a lack of win95-only utility programs (well,
> they might work in a windows emulator...).

Check out KDE at www.kde.org. Many of the simple utilities you're used to
in Windows are present in KDE.

-- Chris

Post a reply to this message

Chris Cason <cas### [at] netplexaussieorg> wrote:
: It (i.e. Linux/FreeBSD/other x86 unixes) does run POV faster than any
: Microsoft OS would on the same hardware.

  I wonder how is this done. Unless unix overclocks the cpu without telling
you... :)

  Yes, I believe it can run povray a little faster, but deducing from your
tone of voice, it seems that it can run it a lot faster.
  I have never tried povray with windos and unix in the same computer, so
I can't tell.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Nieminen Mika <war### [at] cctutfi> wrote:

>  I wonder how is this done. Unless unix overclocks the cpu without telling
>you... :)

It's quite obvious, if you think about it. Any application on a modern OS must
share the CPU with - at the very least - the OS, if not other applications. In
addition, the application will typically depend on the OS for various services.

The more efficient the OS is in keeping out of the application's way, and the
more efficiently coded the services it offers are, the more time the
application has to do its work.

Windows 95/98 are woeful in that respect - they still have chunks of 16-bit
code in them, which causes a contect switch every time they're called from
32-bit mode.

Windows NT - while a true 32/64-bit OS - still has more overhead than modern
unixes.

So, a good Unix such as FreeBSD or Linux will typically run (compiler
optimisations not considered) the same code on the same hardware faster than
Windows.

-- Chris

Post a reply to this message

Greetings !

  I wish to thank everyone who took the time to answer my questions and
truly appreciate the thoughful replies I recieved.


Regards,

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

Chris C wrote:

> Nieminen Mika <war### [at] cctutfi> wrote:
>
> >  I wonder how is this done. Unless unix overclocks the cpu without telling
> >you... :)
>
> It's quite obvious, if you think about it. Any application on a modern OS must
> share the CPU with - at the very least - the OS, if not other applications. In
> addition, the application will typically depend on the OS for various services.
>
> The more efficient the OS is in keeping out of the application's way, and the
> more efficiently coded the services it offers are, the more time the
> application has to do its work.
>
> Windows 95/98 are woeful in that respect - they still have chunks of 16-bit
> code in them, which causes a contect switch every time they're called from
> 32-bit mode.
>
> Windows NT - while a true 32/64-bit OS - still has more overhead than modern
> unixes.
>
> So, a good Unix such as FreeBSD or Linux will typically run (compiler
> optimisations not considered) the same code on the same hardware faster than
> Windows.
>
> -- Chris

And another factor is how memory and drive space are handled. NTFS was originally
hyped as not ever needing defragmentation. NT5 is going to include a third-party
developed defragmenter. Hmmm. Convey anything about their file system design?

Also, the swapping in NT is horrible. Well, OK maybe not that bad, but it can be a
factor. Especially with a program like PovRay.

And Win9X is another big problem. Any 16-bit process executing will block all
32-bit processes until it complets. In windows multimedia development, I've had
simple test cases where a timer callback for MIDI playing could get a 2100ms
latency! 2.1 seconds of non-callback just because I happened to be accessing
ethernet at the time. Ouch!

Post a reply to this message