[linux-l] PHP 4.3.x auf Redhat 7.1

[Steffen Dettmer]

* Christian Boulanger wrote on Mon, Dec 08, 2003 at 11:48 +0100:
> 1) Schönheit und Effizienz der Sprache
> 
> Hier ist wohl vieles einfach Geschmacksache. 

Das geht schon damit los, was man mit "schön" meint...

> Ich finde z.B.  JavaScript überhaupt nicht hässlich, im
> Gegenteil ist es meiner Meinung nach total unterschätzt, was
> Klarheit und schnelles Entwickeln von Lösungen angeht.

Ich finde bei Sprachen wichtig, daß sie den Entwickler
unterstützen, das richtige zu tun. Beispielsweise Namespaces
anbieten, Package-Namen sollten über Verzeichnisstrukturen
abbildbar sein (oder das als Pflicht), Bezeichner müssen lang
werden dürfen, Typen müssen mindestens etwas sicher sein. Um so
besser diese Sachen unterstützt werden, um so besser ist es für
größere Projekte geeignet, find ich. Dann ist mir wichtig, daß
die Sprache eine klare Struktur hat. Wenn man als Entwickler vor
dem Schreiben nicht genau weiß, was passiert, ist man am Arsch.
Ich hab den Eindruck, daß gerade bei Scriptsprachen gern mal
probiert wird. Genau wie die Jungs mit den High-Tech IDEs (Visual
Studio z.B.). Mal was schreiben und gucken, ob läuft. Ist
natürlich ne Katastrophe. Für kleine Sachen, so ein- zweitausend
Zeilen oder so, reicht das natürlich prima, die kann man ja noch
im Kopf behalten. Refactoring? Zweitausend Zeilen kann man
problemlos wegschmeissen, also auch kein Ding.

> Die Probleme mit der Sprache sind eher die von außen
> auferlegten Begrenzungen (die aber natürlich Sinn machen, wenn
> JavaScript nur im Browser läuft).

Gehört dann aber zu Punkt 2 unten, oder?

> Obwohl ich fast alles mit PHP mache, finde ich die Sprache
> hässlich (Variablen mit $ mag ich einfach nicht), 

mmm... Das ist mir eigentlich Wurst, ehrlich gesagt :) $ hat
auf jeden Fall Vorteile. Allerdings haben $-Variablen oft ein nur
rudimentäres Typkonzept (Perl, PHP, Shell).

> ungeschickt (z.B. die bisher fehlende Objektorientierung, PHP5
> soll ja besser sein) 

Ja, das wird aber auch nicht direkt kommuniziert. Ich dachte
immer, PHP(4) sei OO, aber das stimmt nicht. Es gibt Rudimente
davon. Damit darf man IMHO nicht arbeiten, weil es bekloppt ist,
wenn sich eine bestimmte OO Funktionalität nicht richtig verhält,
weil das kein Benutzer meiner Klasse erwarten würde. Er wird
meine Klasse falsch verwenden, ohne das der Compiler
dazwischenspringt, weil das Typkonzept ja nicht ausreicht. Ich
glaub, mit mehreren an einem PHP Projekt zu arbeiten, muß die
Hölle sein...

> und uneinheitlich (Man  muss dauernd nachschauen, welcher
> Parameter wo und wie der Befehl noch mal genau hieß).

Ja, fand ich auch so. Lieblos gestrickt. Einfach nur
klatsch-klatsch-hier-ran-da-ran. Immer einfach ranschrauben, was
neu ist, egal, ob das paßt oder nicht.

> Trotzdem ist sie gut, weil effizient und weil man in 10 Minuten
> etwas zum Laufen bringt.

LOL. 

Effizient? Was meinst Du damit? Laufzeitperformance? Ist
vermutlich nicht besser als Java oder Perl, obwohl oft mod_php
verwendet wird, was natürlich auch nur Mist ist, aber schneller.

In 10 Minuten etwas zum Laufen zu bringen ist aber in keiner
Sprache ein Problem, oder?

Aber sicherlich kann man in PHP besser hacken als in C. Aber C
ist ja eh eine häßliche Sprache.

> Auf eine kompilierte Sprache habe ich keine Lust, weil ich kein
> Vollzeit- (und noch nicht einmal Teilzeit-) programmierer bin, sondern
> in kurzer Zeit zu Lösungen kommen will.

Du meinst Sprachen, die vor der Laufzeit extra erst in etwas
anderes kompiliert werden müssen? Java und Perl sind ja auch
Compiler, bloß merkt man davon nix :)

> Programme in C sind nichts für ein breiteres Publikum 

Versteh ich nicht. Das Publikum merkt doch gar nicht, in welcher
Sprache das geschrieben wurde? Mal abgesehen davon, daß
inzwischen C++ breit verfügbar ist :-)

> und können von den wenigsten, die an Webapplikationen
> interessiert sind, installiert werden.

Na, da muß man ja auch nix installieren, weil der Compiler ja
plattform-passenden Code erzeugt.

> An Java reizt natürlich das "Cross Platform",

C/C++ ist IMHO auch "Cross Platform". Gut, man muß
neukompilieren, wie auch bei Java, aber der Code ist der gleich
(bzw. man bekommt es hin). Bei Java ist gar nicht so sehr "Cross
Platform", sondern mehr "Eigenplattform" finde ich, was z.B.
damit losgeht, daß man unter Unix Java nicht über /etc/
konfiguriert, sondern über weißichwas.properties und ich keine
Shell für die VM hab. Perl ist auch schön plattformunabhängig.
Eigentlich ist das meiste, was ich kenne plattformunabhängig,
bloß der MicroSoft-Kram (.NET, (D)COM, DAO und was es da gibt)
ist es nicht.

> aber die Lernkurve ist mir einfach zu groß.

Ich denke, C ist viel schneller zu lernen, als z.B. Perl. Aber
mit C kann man erstmal "weniger machen" finde ich. Für
Webanwendungen, die ja meist Textverarbeitung machen, weil man
eben kein XSLT verwendet, finde ich C ziemlich ungeeignet, klar.

Wenn Du Spaß dran hättest, bunte LEDs anzusteuern, würdest Du
vermutlich C vorziehen, weil das hier einfacher ist, als z.B.
Perl :)

PHP ist eine doofe Sprache, die sinnlos viel zusammengewürfelte
Bibliotheken anbietet, die wohl so ziemlich 1:1 den C-APIs
entsprechen (was für PHP nicht immer passen kann :)).

> 2) Sicherheit
> 
> Hier würde ich gerne mehr von Systemadministratoren hören, was
> ihre Erfahrung mit PHP ist und warum viele so große Sorgen
> deswegen haben. 

Das erste ist mod_php: alle PHP Scripte laufen als "www-user",
also unter dem des Servers. Damit die sich nicht untereinander
stören können, setzt PHP irgendein Sicherheitskonz... nee,
Konzept nicht, Sicherheitsgematsche ein. Das ist auf highlevel
Ebene drangeklatsch und funktioniert demnach nicht. Es gab so
viele Details, wo ein Parameter eben nicht geprüft wurde etc.
Dann kann man Sicherheitsseinstellungen nicht etwa pro Script
sondern nur global einstellen, und da hört's für mich dann ganz
auf.

Dann linkt PHP stets etwa geben "/usr/lib/lib*.so", was dazu
führt, das ein sicherheitsempfindlicher Bug in irgendeiner dieser
Libs fast zwangsläufig dazu führt, das man den über PHP ausnutzen
kann. PHP Scripte sind zudem selten sicher, was durch diverse
Konzeptfehler wie z.B. automatisch Variablen aus dem CGI
Envrionment holen, anstatt ein Object dafür zu definieren, am
besten globale natürlich. Dann so Sachen wie automatisches
SQL-Escaping. Ich hab immer gesagt: wenn man in (C/C++) ODBC
Anwendungen was Escapen oder quoten muß, macht man schon was
falsch. Und warum? Weil man dann nämlich SQL Statements mit
String-Funktionen baut, was man aber nicht machen darf. Man hat
schön "?" Platzhalter zu verwenden und die Parameter Typgerecht
einzufügen. Dann quotet der Driver, und der weiß, wie er das
machen muß! Ich frag mich auch ernsthaft, woher das PHP wissen
will, wie *meine* Datenbank denn nun quotet. Vielleicht ist "."
bei mir ein extrem wichtiges Sonderzeichen!

Schlimm wird auch dieses Embedded-PHP-Zeug. Auch sehr beliebt,
hackt man schnell was: <html> <? my_table_function(); ?> </html>
oder so ähnlich. Ist natürlich geil, wenn das so ausartet, daß
noch viel HTML Code so drin steht. Und dann - in Spalte 19 der
dritten Tabelle - passiert ein schwerwiegender Fehler bei einer
Datenbankabfrage! Kommt dann noch gültiger HTML Code bei raus?
Ist garantiert, daß die Zugangsdaten der Datenbank nicht an den
Browser gesendet werden? 

Klar, so programmiert man nicht, aber guckt mal nach draußen, es
wird so gemacht, wer weiß, warum. Schätze mal, gedankenlosigkeit,
oder weil das für ne private Telefonnummerndatenbank ausreicht.
(klar, wenn man so ein 1000-2000 Zeilen-Teil baut, ist das recht
egal, und wenn's für privat ist, darf auch das passwort im
browser stehen, weil man es ja eh kennt :)).

> Es ist immer ein Ärgernis, wenn der Provider PHP nur im "Safe
> mode" laufen lässt, weil dann die Hälfte aller Webapplikationen
> nicht funktionieren.  

Warum funktionieren die nicht? Ich hab diesen safe mode nie
verstanden. Ich mußte den für Kunden auch abschalten. Na, wer PHP
oder mySQL verwendet, hat automatisch jede Garantie verloren ;)
Ich hab anfangs mal geguckt, was da so war, da waren ganz
komische Dinger. Ich glaub, oft waren das Bugs, also ist der safe
mode vielleicht gar nicht so schlecht (dafür die Scripte ;)). 

> Aber es wird wahrscheinlich gute Gründe dafür geben.

Vermutlich bleibt es so heißt genug. Jedenfalls für'n provider
doof, wenn Kunde A die Scripte von Kunde B verändert und in
dessen Datenbank rumpfuscht oder so... 

Das Problem ist ja, daß mod_php die Unix-Rechtestruktur
aushebelt, und das PHP lieblos wieder was drangehäkelt hat. Ich
bezweifle, das das ne gute Idee war - aus Designgesichtspunkten
halte ich das für schlicht falsch. 

Ähnliches gilt natürlich für mod_perl oder embedded Perl.

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.