we are connected ! ! ! ! ! ! ! ! ! ! ! ! ! !

[Christoph Zurnieden]

Hallo,

<eg>Meinst Du, die Browserweichenbastler lesen hier noch mit?</eg>
BTW: Wenn Du _hier_ XML benutzt, dann doch bitte korrekt, ja? >;->

?!!? Korrekt gemäß welcher DTD? ;-)

---snip---

<!ELEMENT eg (#PCDATA)* >

---snap---

;-)

Und das wundert mich noch nicht mal: Ich kann mir gut vorstellen, daß
irgend eine Optimierungsstufe z. B. Schleifen aufrollt oder sonstige
Turnübungen veranstaltet, um Tempo zu gewinnen.
Ja, genau das. 'man gcc' gibt über die Einzelheiten Auskunft.
Aber laß Dir gesagt sein: Du möchtest es nicht wirklich _so_ genau wissen ;-)

Full ACK. (Früher, als ich noch C-Programme schreiben mußte, hätte ich das wissen wollen. Andererseits: Wenn ich schon mal jemanden an der Leitung habe, der sich damit auskennt ...)

Da der Thread eh gleich rausrollt: gerne weiter per PM.

Und dabei kann der Compiler halt auch falsch raten, wenn unsauberer Code
z. B. davon lebt, daß einzelne Anweisungen obskure Seiteneffekte haben ...
Ist das nicht wie beim HTML? Wenn man da irgendwelche Merkwürdigkeiten eines
speziellen Browsers nutzt ...
Aber auch bei C gibt es einen Standard, sogar eine ISO! ;-)

Ich hätte jetzt mal ganz naiv angenommen, daß synmtaktisch korrekte ISO-C-Programme so etwas ähnliches sind wie valide HTML-Dokumente ... ?

Äh ... nein ;-)

Ein syntaktisch korrekter C-Code compiliert normalerweise überall.
Ein syntaktisch korrekter HTML Code sieht aber überall anders aus.

Am speichersparendsten bei meinem Compiler ist übrigens -O2 ;-), damit
wird das binary am kleinsten und es wird auch am wenigsten Hauptspeicher
vom laufenden Programm belegt.
Noch kleiner als -Os?

Das habe ich nicht ausprobiert.
Wenn ich Compiler-Optimierungen will, dann solche, die auf Geschwindigkeit gehen. Speicher sparen kann ich ja per Hand, etwa durch weggelassene Module.

Ich kenne mich auch nur deshalb damit aus, weil ich mal so etwas wie "Postoffice on a disk" machen wollte. D.h. alles für den Mailverkehr auf ein 1,7MB formatierte Diskette: OS, MUA, MTA, GnuPG, SSL. Habe es aber um's Verrecken nicht geschafft. Die Kryptographie ist einfach zu groß.
Schade eigentlich.

Ab -O3 scheinen mir also die aggressiven Optimierungen anzufangen, die
bereit sind, Geschwindigkeit für Speicher einzukaufen.
Eigentlich schon früher, kommt aber auf den Code an.

Ich dachte das, weil es erklären würde, wieso Apache selbst -O2 für sicher hält.

-O2 ist so die Standardeinstellung. Wenn es damit nicht funktioniert, hat der Coder Mist gebaut ;-)

Was würdest Du mir empfehlen? (gcc 3.0.3, 2001-12-20 ... ?)
Um Gotteswillen, nein!
Aber war wahrscheinlich auch nicht ernstgemeint, oder? ;-)

Für meinen Intranet-Spielzeug-Server, wieso nicht?

Zum Ausprobieren? Immer! ;-)

(Gesagt, getan: GCC 3.0.3 installiert, Apache neu übersetzt mit -O9, und immerhin läuft er noch ... jetzt warten wir mal auf die core dumps ...)

Normalerweise ist auch beim GCC 3.x bei -O3 Schluß. Zumindest meiner ignoriert höhere einfach kommentarlos und setzt den Standard (bei mir -O2, in der Config einzustellen)
Aber das Problem beim neuen GCC ist, daß vieles nicht mehr compiliert, wenn der Coder einige der (leider üblichen) schmutzigen Tricks benutzt hatte. Der Neue ist etwas genauer ;-)

Gut beim compilieren selbstegeschriebenen Codes ist die Benutzung von "gcc -O2 -pedantic" oder sogar mit '-ansi' hintendran. Da wird er bei Unsauberkeiten kniepig ;-)
Und ANSI-Compliant ist sowieso immer gut ;-)))

Würde einen der letzten aus der 2er Reihe empfehlen. Ich bin mit dem
2.95.2 ganz zufrieden. Habe mir von der Nachfolgeversion nur das
Changelog besorgt und den einen Bug gefixt, der mich störte.
Wer weiß, was die ganzen anderen Bugfixe so alles angerichtet haben ;-)

Irgend so einen 2.95 hat unser Admin auch herum liegen und installiert den wohl auf die Produktionsmaschinen. Mir soll's recht sein. Außer Open Source damit zu installieren mache ich nichts in C.

Ja, tut er nichts falsches mit.

Beim Compiler ist da wie beim Kernel. Nimm Dir nur einen Neuen,
wenn Du ihn wirklich unbedingt brauchst. ;-)

Das höre ich in der Tat öfters.
Andererseits: Ich kann nicht so recht glauben, daß die Leute, die Patches machen, damit im Schnitt (!) die Sache schlechter machen. Klar, es kann ab und zu mal ein Patch daneben gehen, aber es würde mich wirklich wundern, wenn Patches mehr Schaden als Nutzen anrichten.

Diese Regel gilt ja auch für Produktionsmaschinen. Ausprobieren kann man die Dinger immer. Deshalb ist auf gutgewarteten Produktionsmaschinen immer etwas ältliche Software drauf, extrem selten (z.B. bei Sicherheitsproblemen) das da mal das Neueste drauf wäre.

Deshalb habe ich m. E. zwei Möglichkeiten:
a) ich analysiere und teste jeden einzelnen Patch und nehme diejenigen, die ich wirklich will, oder
b) ich habe die Zeit dafür nicht und halte neuere Versionen im Schnitt für besser als alte.

Naja, ist ein wenig Schwarzweis gehalten. Ich glaube die beste Lösung liegt wie immer irgendwo in der Mitte ;-)

Ich z.B. tendiere mehr zur Analyse, aber schaue mir nicht die Patches im Einzelnen an, sondern nur in's ChangeLog; wenn ich da etwas interessantes gefunden habe schau ich mal in den Code, ansonsten schau ich, was im nächsten Freshmeat Newsletter so drin ist ;-)

Bei Apache jedenfalls würde ich generell die neueste tatsächlich ausgelieferte Version bevorzugen.

Nimm lieber die vorletzte und schau in's Changelog der letzten. Wenn ein Security Fix drin ist: updaten, ansonsten: warten. Die hauen die Versionen relativ rasch raus.

Ich habe über 1.3.14 und 1.3.17 viel Böses gelesen, aber damit selbst nie Probleme gehabt; sobald 1.3.22 draußen war, habe ich ihn lokal eingesetzt und wir nehmen ihn auch schon für produktive Systeme. Im Prinzip ist doch jede Version seit 1.3.10 (Fancy Indexing) nur ein (Security-) Patch, mit minimalen Funktions-Erweiterungen ...

Keine Ahnung, ich habe es nicht verfolgt. Aber die Jungs sollten sich endlich mal angewöhnen (und nicht nur die) die Security-Patches _getrennt_ von den Feature-Patches herauszubringen. Das ist sonst ein hen n' egg Problem.

Was die Version 2.0 angeht, so warte ich auf "mehr als Beta" - dann werde ich das Teil hier sofort lokal installieren. Irgendwer muß ja testen, ob unsere Anwendungen darauf noch laufen ...

Warum sollten sie nicht? ;-)

Was ist eigentlich mit den beiden Kernel-http-servern? Irgendwelche Erfahrungen?

Ich häng den anderen hier mal eben dran, ja?

Benutze ich ein anderes strip (2.9.1)? Die Manpage hier hat 200 Zeilen und entsprechend einiges mehr an Optionen.

/apache (root/TKschwarz) which strip
/usr/ccs/bin/strip
/apache (root/TKschwarz) strip -V
strip: Software Generation Utilities (SGU) Solaris-ELF (4.0)

Soviel zur babylonischen Sprachverwirrung, oder "UNIX != UNIX" ...

Ach, ich vergaß, Du betreibst ja Solaris.
Aber die normalen GNU-Utils sollten da eigentlich auch laufen?

Bei statisch gelinkten Programmen kannst Du dann aber wirklich brutal
werden und sogar die Funktionen aus der Libc entfernen, die Du nicht
brauchst ;-)

Fein. Dann sollen die autoconf-Leute das mal verstehen und richtig in den Makefiles verwenden ...

Die Autoconf Entwickler sind da aber nicht schuld dran.
Naja, zumindest nicht direkt, hätten sie das System mal etwas besser gebaut, wäre es nicht so eine Quälerei das Dingen zu bedienen.
*from scratch* klappt das ja ganz gut, aber wehe, Du versuchst mal ein älteres Projekt zu ändern. Da bekommst Du graue Haare!
Am Montag habe ich einem Kollegen versprochen ihm für sein Projekt mal den Autoconf Driss zu machen, zumindest mal den Anfang. Ist nicht viel Zeug, sind aber mehrere einzelne Binaries mit ein paar Abhängigkeiten und einigen Sonderfällen. Aber eigentlich harmlos.
Naja, nun ist es Freitag :-}

ich glaube, tiefer als "make install" will ich in die Materie doch nicht (mehr) eindringen.

Ist auch viel besser für die Nerven! ;-)

so short

Christoph Zurnieden