electroteque wrote:
On 28/01/2005, at 11:56 PM, Jochem Maas wrote:
well if you have been working fine on MacOSX then I reckon thats a
good indication!
Well umm, its a standard setup really, i install all the libraries
needed for the extensions via fink, i compile php via source.
was not meant as a a dig - its merely that MacOSX is less used and therefore
per definition less tested, statistically you have more chance of finding
a (platform specific) bug there. at least that was my reasoning.
...and if you want to run redhat thats your problem ;-)
Not my decsision what would you suggest ? We need pretty standard stuff
for it to be supported. I dont work for a web company, i'm in an IT
department of a government Tv station or i wouldnt need to go through
all this hassle to get it.
what do you classify as std? (most gov orgs I know of think std ==
Microsoft).
redhat is shite, if you need professional support/indemnity/etc I would
recommend
Novell/SuSE. if you can go for a minimal setup like debian or gentoo (2 distros
that
I like) which take the 'less is more' approach and gives you control - rather
than
some redhat webserver 1500 miles away which thinks it knows better than you
whether
you want to upgrade to the latest version of xyz.
Yes PHP5 is stable enough to use IMHO, just don't rely on updates to
std packages always
working (like the redhat packages - which _ahem_ suck).
As before the systems guy will be doing it from source fk rpm's.
I pity the man - I have a friend who is _really_ ace at the sort of
thing and he used the word 'nightmare' (php5/apache2/firebird1.5 on a redhat
v3 enterprise server).
yum yum not. ()
(I have been writing a PHP5 framework since around 11-2003 and I
haven't been able to
get it to segfault since around May last year.)
Yeh right interested what your view is on "framework"
framework == 'bunch of code that I can reuse to form the basis of a site'
basically its a data-object setup specific to Firebird DB - basically
you design a DB (day or 2), write the objects (day or 2 again), boom
instant CMS - and then I spend countless hours doing the custom magic for a
given client.
There is a lot of work done on relating data entities and
on the generic/generated CMS interface. (3 types of relation: Reference, Vector,
Association - each is implements as a Field object - fields objects make up the
structure of data-object). Its pretty cool, but the stuff that really makes it
stand
out (IMHO) is the generic management/editing screens...e.g.
1. highlight rows (ala phpmyAdmin but better) and then edit all the highlighted
rows
(no use of checkboxes) with a single click
2. drag'n'drop columns (to change the order) with the ability to store the
changes
(the system is capable of storing custom view settings for each user)
Actually I have wanted to make the code open source - but its really a
quite a complex beast to setup i.e. I can't just give someone a file and say
run it, theres your demo. which means I need to write an install file, a help
file and make a test DBstructure for people to play with.... as soon as I have
time I will get my ass into gear, then you (and the rest of the world) will
be able to see if its any good.
...so it runs on Apache2 quite nicely - there is the fact that you
must use the prefork apache2
worker module, other than that there are no overwhelming problems (I
assume that there
are bugs that could crop up - but this is just going on the assumption
that bugless software
is only made on other planets :-) - at any rate I have pushed PHP5
quite far on Apache2
and nothing is breaking - e.g. many cyclic-object-references, which
was something that sometimes
caused segfaults in the 'early' days)
I think we could start a flame here, but I have been told the problem
isnt with php c code directly but the c libraries it hooks into that
instead thread safe ?
correct as far as I understand it. to paraphrase Rasmus (answering a post
on threading) 'your in uncharted territory, good luck'
I see you sneakily snipped off the misspelling of Rasmus' name ;-)
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
