World: r3wp

Max;  The Debian definition of "Free" is very very particular.  The 
DFSG allows for no strings attached.  The Mozilla team has placed 
copyrights on FireFox(tm) so, the Debian team wrestled with it and 
came up with Ice Weasel.  It's kinda dumb, but the DFSG is our friend. 
 If it comes from Debian Main, there are 'no strings attached'.

so is it gpl or even freerer?  like bsd/mit ?

GPL.  Extra Crispy GPL.  :)

hum GPL itself is more like a 50 ton capable steel  cable when compared 
to a string.

Other than Public Domain, I don't think there is a freer license. 
 Except for the fact you aren't free to restrict access to any stuff 
based on GPL...so freedom from / freedom to arises here.

mit/bsd are freer in the sense where they do not remove your liberties 
about how you distribute your code.

Yeah.  Agreed.

I may be wrong, but IIRC, Richard Stallman's original license had 
wording that you were not allowed to stop people from trying to 'steal' 
stuff based on the license.  :)

but an mit/bsd license derived product can *become* close source 
in time... whereas a GPL-derived product cannot... but there is nothing 
stopping the "original" copyright holder to release further versions 
closed source.

MySQL being a good example.

I don't know, I like the GPL, but it is definitely a 'headspace' 
issue.

so even GPL does not guaranty long-term "freeness" from the original 
author.

Nope.  Copyrights stay.  A good thing in my opinion. Again 'headspace'.

that's the thing about public domain  :-)  no more rights, as free 
as a rock on the moon.

(if you can get one ;-)

BSD is a respectable license.  But the GPL does not stop anyone from 
commercializing, it's just that you can't stop the next guy from 
giving the stuff away  for free.

Humans will get it figured out someday...spirit versus letter...

my take:   GPL protects against the big guys, BSD allows easy industry 
adoption.  What I realise with time is that original copyright owners 
usually get the credit (and the consultation) and forks rarely really 
live on, unless the original is not supported directly.

look at wireshark... a very good example.

in any case, licensing is never perfect, whatever the license !

Yep.

I want cheyenne to run up on start up.

I changed my /etc/rc3.d/S99local to call cheyenne.r but now although 
it starts up cheyenne.r, I now don't get to the Gui login for fedora 
...

do I need to return some value, or run cheyenne with some options 
?

i need help  . how I start   rebol cgi script  http://adam.hosting4clans.net/test.cgi
 - receives error : User Error: REBOL: Cannot connect to X server 
** Near: size-text self

hmm, you probably don't have x-windows installed/running? You try 
to use View stuff, which links to x-windows libraries ... but I know 
little about it ...

If you are trying to run a CGI, best to do it with Core, not View
Looks like your script *has* started, but fails.

Core not load image.png

Sunanda - yes, but he is evidently trying touse view related functionality

you can't use view as cgi unless x-windows is loaded

and it won't be normally ... most servers run at init 3

not at run level 5

Petr,  that's not always a good idea as View wants to install itself 
more thoroughly than Core

And may need elements that a server lacks.

Sunanda, there are command line options to not install aren't there?

yes, there are. But IIRC, in cgi-mode, you would be able to use some 
basic face command functionality, but I am not sure now ....

Graham, Ah, yes: maybe he lacks the -cs on the shebang

maybe that should be addressed somehow in the future? The question 
is, if it is easily solvable. OTOH even php has some imaging modules.

just use core to call imagemagick

view functionality for cgi = Command.

Graham, that sounds a bit strange, however, i would rather add a 
new start/stop script for cheyenne rather than put it in rc.local.

I'll give it a go ...

As per btiffin's suggestion, I added "&" at the end of the script 
name in my S99local file to background Cheyenne, and it is now working 
:)

Graham;  Complete aside...and very dependant on firewall setiings. 
 (I have a firewall/router so the local unix box is not double firewalled...yet) 
but this lets you run Cheyenne from user process.

#!/bin/bash
#

# This script is to be run from root to allow Cheyenne to be run 
as a user
#

# NOTE: dev is eth0, spike and chester are eth1 (eth0 for the firewire)

#       this script defaults to eth1, so no longer functions on dev
#
# redirect external incoming port 80 to 8080

iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth1 -j REDIRECT 
--to-port 8080

# redirect localhost port 80 to 8080

iptables -t nat -A OUTPUT -p tcp -d 127.0.0.1 --dport 80 -j REDIRECT 
--to-port 8080

why does one want to run cheyenne as user and not root ?

I cheyenne is hacked (or exposes a directory...) hackers own you.

oh ...

The standard is to run a secure(r) webserver as user  nobody

let me know when you finish it :)

A little more work, since root webservers never have to worry about 
read/write permissions but user level runs have to be a little more 
particular in permission settings.  Always a good practice anyway.