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

[Andreas]

Hallöchen!

Hatte mich dann gestern doch mal dazu durchgerungen, mir eine Linux-Distribution (SUSE 7.3) zuzulegen.
Und ich muß sagen, läuft hervorragend, soweit ich das bis jetzt beurteilen kann!
Problematisch war es jedenfalls nur mit den Partitionierungen, hatte mir erst schön eine 3. Partition dummerweise zwischen 2 anderen angelegt...
Jedenfalls war das die einzige blöde Erfahrung.
Alles in allem habe ich vom einlegen der DVD bis zu diesem Posting etwa 1 Stunde gebraucht!
Ich hatte vorher immer gehört, von wegen so superschwierig zu installieren.. 1 Woche versucht... bis auf meine Infrarot-Maus hat Linux eigentlich fast alles ohne Probleme erkannt(jedenfalls auf den ersten Blick).
Und ich hätte mir nie träumen lassen, was da alles an Software schon dabei ist!
Das einzige, ich hab das ja blöderweise von DVD installiert, nur glaube ich sind DVD-Laufwerke sehr viel langsamer als CD, denn ein vorheriger Anlauf(an Partition gescheitert) mit CD ging bestimmt 5 mal schneller als - was soll dann ein Medium wo 8 mal soviel draufpasst wie auf CD, das aber nur 20-30% der Lesegeschwindigkeit bietet! Die sollte doch dem entsprechend mitwachsen, oder war das evtl ein Problem mit meinem Computer?
Naja, ich probiere jetzt erstmal ein bisschen rum, kann aber allen nur empfehlen das auch mal zu probieren!
Eine Frage aber hätte ich noch, könnte ich theoretisch den aktuellen Kernel installieren? Oder lieber nicht?

Grüsse
  Andreas

[Sven Rautenberg]

Hallöchen!

Willkommen im Club! :)

Eine Frage aber hätte ich noch, könnte ich theoretisch den aktuellen Kernel installieren? Oder lieber nicht?

Das ist eine diffizile Frage, aufgrund von mindestens zwei Problemstellungen:

Erstens: Der neue Kernel konkret. Neue Versionen sind NICHT immer besser, man kann sich damit also durchaus ein stabiles System instabil machen, oder sonstwas. Das sollte einen etwas davon abhalten, sofort immer den ultraneuesten Kernel gleich drei Minuten nach seinem Erscheinen zu installieren. Andererseits kommen neue Kernel natürlich deswegen raus, weil Fehler behoben wurden, manchmal sogar sicherheitskritische Fehler. Man sollte also zumindest ein Ohr auf die Veröffentlichungen über neue Kernel haben.

Zweitens: Konkret für deine Distribution brauchst du vermutlich auch den passenden Kernel. Suse paßt die Kernel-Updates irgendwie an - keine Ahnung, was die machen, hat bislang auch nicht gestört, wenn ich einen offiziellen Kernel genommen habe, aber das ist ohne Gewähr. Suse (als Beispiel) gibt sowieso keinen kostenlosen Installationssupport, wenn du mit dem Kernel rumspielst und einen eigenen kompilierst.

Normalerweise funktionieren die mitgelieferten Kernel prima mit aller Hardware. Neukompilieren ist eigentlich nur noch dann erforderlich, wenn du einen langsamen Rechner mit speziellen Aufgaben ausstatten willst, und Performance rauskitzeln möchtest.

Mach es, wenn du meinst, ist nicht komplizierter als ein paar Befehle eingeben, vergiß das Update des Bootmanagers nicht (ganz wichtig, sonst startet Linux u.U. nicht mehr von Platte), starte neu und fertig. Die Kernel-Quellen haben ein Readme dabei, welches alles detailliert beschreibt. Ansonsten gibts bestimmt noch ein Kernel-HOWTO, welches ebenfalls ausführlich ist.

- Sven Rautenberg

[Stonie]

Hallo, Sven!

http://www.rtbg.de/gruss/

*GRINS* Das ist die ultimativste Grussbotschaft, die ich seit langem gesehen habe.

Danke und selbstverständlich

file Griese!

Stonie

[Christian Kruse]

Hoi,

Erstens: Der neue Kernel konkret. Neue Versionen sind NICHT immer
besser, man kann sich damit also durchaus ein stabiles System
instabil machen, oder sonstwas. Das sollte einen etwas davon
abhalten, sofort immer den ultraneuesten Kernel gleich drei
Minuten nach seinem Erscheinen zu installieren. Andererseits
kommen neue Kernel natürlich deswegen raus, weil Fehler behoben
wurden, manchmal sogar sicherheitskritische Fehler. Man sollte
also zumindest ein Ohr auf die Veröffentlichungen über neue Kernel
haben.

Jetzt habe ich ein Problem. Du sagst nichts falsches, aber du
vergisst das wichtigste ;-)

Beim Linux-Kernel gibt es ein ausgefeiltes Versions-System: es gibt
Developer-Versionen und User-Versionen. Die Developer-Versionen kann
man als Pre- oder Alpha-Versionen verstehen, fuer die besonders
mutigen. Sie sind mit einer ungraden Versions-Zahl gekennzeichnet.
Die User-Versionen sind debuggte Developer-Versionen, die im Grunde
gut durchgetestet sind und stabil laufen. Ich haette keine Bedenken,
einen solchen Kernel zu installieren; diese Kernel haben gerade
Versions-Zahlen.

Zweitens: Konkret für deine Distribution brauchst du vermutlich
auch den passenden Kernel. Suse paßt die Kernel-Updates irgendwie
an - keine Ahnung, was die machen, hat bislang auch nicht
gestört, wenn ich einen offiziellen Kernel genommen habe, aber
das ist ohne Gewähr. Suse (als Beispiel) gibt sowieso keinen
kostenlosen Installationssupport, wenn du mit dem Kernel
rumspielst und einen eigenen kompilierst.

Eigentlich ist das ziemlich problemlos, wenn man weiss, was man
macht:

root@erde> cd /usr/src
root@erde> mv linux-kernel-sourcen-verzeichnis kernel-src-old
root@erde> fetch url-to-sourcen
root@erde> tar -xzf linux-kernel-sourcen.tgz
root@erde> rm -f linux
root@erde> ln -s linux-kernel-sourcen linux
root@erde> cd linux
root@erde> make menuconfig
root@erde> make bzImage
root@erde> make modules modules_install
root@erde> mv /boot/vmlinuz /boot/vmlinuz.old
root@erde> cp arch/i386/boot/bzImage /boot/vmlinuz
root@erde> lilo
root@erde> reboot

Des wars eigentlich auch schon.

Normalerweise funktionieren die mitgelieferten Kernel prima mit
aller Hardware.

Mit herkoemmlicher Hardware. Wenn man was ausgefallenes hat, uU
schonmal nicht.

Neukompilieren ist eigentlich nur noch dann erforderlich, wenn du
einen langsamen Rechner mit speziellen Aufgaben ausstatten
willst, und Performance rauskitzeln möchtest.

Neukompilieren wuerde ich *immer* empfehlen. Wozu soll so ein riesen
aufgeblaehter Kernel gut sein?

Mach es, wenn du meinst, ist nicht komplizierter als ein paar
Befehle eingeben, vergiß das Update des Bootmanagers nicht (ganz
wichtig, sonst startet Linux u.U. nicht mehr von Platte), starte
neu und fertig. Die Kernel-Quellen haben ein Readme dabei,
welches alles detailliert beschreibt. Ansonsten gibts bestimmt
noch ein Kernel-HOWTO, welches ebenfalls ausführlich ist.

http://www.linuxdoc.org/

Gruesse,
 CK

[Andreas]

Hi!

root@erde> cd /usr/src
root@erde> mv linux-kernel-sourcen-verzeichnis kernel-src-old
root@erde> fetch url-to-sourcen
root@erde> tar -xzf linux-kernel-sourcen.tgz
root@erde> rm -f linux
root@erde> ln -s linux-kernel-sourcen linux
root@erde> cd linux
root@erde> make menuconfig
root@erde> make bzImage
root@erde> make modules modules_install
root@erde> mv /boot/vmlinuz /boot/vmlinuz.old
root@erde> cp arch/i386/boot/bzImage /boot/vmlinuz
root@erde> lilo
root@erde> reboot

mit anderen Worten - ich laß da lieber erstmal die Finger von ;-)

Ich habe da nämlich ein grundsätzlicheres Problem, schön und gut  mit Programmen die ich vergleichbar dem Windows Startmenü öffnen kann, aber jetzt habe ich über YaST2  noch Apache und MySQL instlliert, hat auch alles gemacht, mit Erfolgsmeldung - nur wie komme ich jetzt da dran?????
Also über das Menü finde ich beides nicht. Oder mit welchem Tool öffnet man solche Programme, bzw. editiert die config Dateien?
Es muß doch eine einfache Möglichkeit geben, wenigstens den Apache Server zu starten und zu stoppen!
In der Hilfe finde ich vieles zu Apache, aber nirgends steht wie und womit ich das öffne bzw. editiere!

Grüsse
  Andreas

[Sven Rautenberg]

Es muß doch eine einfache Möglichkeit geben, wenigstens den Apache Server zu starten und zu stoppen!
In der Hilfe finde ich vieles zu Apache, aber nirgends steht wie und womit ich das öffne bzw. editiere!

Wie ich sehe, ist es an der Zeit, daß du dir mal ein schlaues Buch über Linux kaufst. Ich befürchte, du hast noch nicht wirklich begriffen, wie die Dinge da laufen "unter der Haube". Und der K-Desktop ist auch solch eine Haube.

Aber das ist ja auch kein Wunder. Windows-geprägte Menschen sind von ebendiesem "OS" künstlich dummgehalten worden, was soll man da erwarten.

Ich kann unmöglich hier im Forum Linux erklären, das würde den Rahmen einfach sprengen, aber zur Handreichung mal ein paar Infos:

Wenn du Linux bootest, kommen jede Menge Statusmeldungen. Im späteren Teil kommen viele Meldungen mit "Starting xxx  -> done ". Dort sollten auch Apache und mySQL verzeichnet sein. Beim Starten scharf hingucken, um es zu entdecken!

Durch diesen Eintrag wird bekanntgegeben, daß Apache und mySQL laufen. Du mußt nichts mehr tun, der Server ist in diesem Moment funktionsfähig. Insbesondere mußt du dich nicht anmelden, denn der Server läuft auch ohne diese lästigen Shells wunderbar. Wenn du ein Netzwerk hast, solltest du einfach mal "http://ip_von_linux" ansurfen, oder auf dem Linuxrechner selbst "http://127.0.0.1", um dich mit der provisorischen Startseite zu verbinden.

Heruntergefahren wird Apache beim Neustart oder Ausschalten natürlich auch automatisch.

- Sven Rautenberg

[Andreas]

Hi Sven!

Wie ich sehe, ist es an der Zeit, daß du dir mal ein schlaues Buch über Linux kaufst.

Ja, kannst Du da was empfehlen?  Was ich auch verstehe;-)

Ich befürchte, du hast noch nicht wirklich begriffen, wie die Dinge da laufen "unter der Haube". Und der K-Desktop ist auch solch eine Haube.

Du bist gut, meinst Du ich hab während der Installation einfuch gaut aufgepasst, nebenbei die Doku Quergelesen und bisn jetzt der linux-Profi schlechthin? Ich gebe es zu - ich habe davon gar keine Ahnung, so wenig wie man auch nur haben kann!

Aber das ist ja auch kein Wunder. Windows-geprägte Menschen sind von ebendiesem "OS" künstlich dummgehalten worden, was soll man da erwarten.

Mag für Programmierer evtl zutreffen, aber selbst Webdesigner.. warum soll man sich mit anderen Dingen beschäftigen wenn das Betriebssystem auch ohne dieses Hintergrundwissen läuft??? Ein Betriebssystem kann sich außerdem nur durchsetzten, wenn das jeder Trottel bedienen kann, allen "Normalsterblichen" wird doch von Linux noch abgeraten! In einer Firma wo 100 Leute arbeiten braucht nicht jeder alle Grundlagen.. zu verstehen,  ist das Prinzip der Arbeitsteilung und ich finde das läßt sich wunderbar auf Computer übertragen!
Und mich interessiert das im Gegensatz zu den meisten Anderen wirklich wie das funktioniert, mir fehlt nur leider Hintergrundwissen - was ist ja bereit bin mir anzueignen, wollte gestern nur nicht irgendwas kaufen, da ich wenn ich das OS noch gar nicht kenne, auch gar nicht beurteilen kann, welches Buch sinnvoll sein könnte. Für Tipps hierzu wäre ich sehr dankbar!

Ich kann unmöglich hier im Forum Linux erklären, das würde den Rahmen einfach sprengen, aber zur Handreichung mal ein paar Infos:

Ich weiß, ich dachte nur Apache und MySQL hätten ein wenig damit zu tun, aber Du hast schon Recht, es fehlt mir an den Grundlagen!

Wenn du Linux bootest, kommen jede Menge Statusmeldungen. Im späteren Teil kommen viele Meldungen mit "Starting xxx  -> done ". Dort sollten auch Apache und mySQL verzeichnet sein. Beim Starten scharf hingucken, um es zu entdecken!

Werde drauf achten, ich habe nämlich noch nicht wieder gebootetm nur abgemeldet;-)

oder auf dem Linuxrechner selbst "http://127.0.0.1", um dich mit der provisorischen Startseite zu verbinden.

Genau das hatte ich als erstes versucht, auf meinem Windows Rechner verwende ich Apache ind MySQL schon "länger" erfolgreich!

Jedenfalls besten Dank für die Infos!

Grüsse
  Andreas

[Marko]

Hi Andreas,

ein kleiner Tip von Windows Umsteiger zu Windows Umsteiger: Solange man noch nicht ganz so fit mit der Komandozeile ist, kannst Du Apache und MySql auch einfach über den RUnlevel Editor in Yast2 starten, das ist sowas ähnliches wie der Dienstekontrollmanager unter Windows.

Gruss

Marko

[Andreas]

SUUUUPER!
 Sowas habe ich gesucht! Stehen wahrscheinlich so einigen Komandozeilenfreaks die Haare zu Berge, aber ich kann auf mySQL zugreifen! Wird da denn jetzt auch bei jedem Start automatisch gestartet?
Da hätte ich nochmal die Frage, was Du für eine Vorgehensweise empfielst, wenn man Probleme beim hoch- und runterfahren hat!
Beim hochfahren gibt es ein Problem mit der Festplatte, die wäre "not Ready", dann kommt irgendwann "Kernel panic" und alles blinkt  und Ende:-)ich muß immer im Safe-mode starten, da gehts, nur hier muß ich jedesmal die Internet-Vebindung aktivieren...
Beim runterfahren auch so ähnlich, da ist irgenwann einfach schluss, obwohl er noch nicht fertig sein kann.

Wo bekomme ich am besten Hilfe bei solchen Problemen? Ich habe nämlich noch in 2 anderen Partitionan  Win2K auf NTFS formatierten Partitionen laufen. Das läuft aber ohne Probleme, die Probleme mit Linux traten aber erst auf, als ich Win einmal gestartert hatte.

Grüsse
 Andreas

[Christoph Zurnieden]

Hallo,

Sowas habe ich gesucht! Stehen wahrscheinlich so einigen Komandozeilenfreaks die Haare zu Berge, aber ich kann auf mySQL zugreifen! Wird da denn jetzt auch bei jedem Start automatisch gestartet?

Sollte eigentlich.

Da hätte ich nochmal die Frage, was Du für eine Vorgehensweise empfielst, wenn man Probleme beim hoch- und runterfahren hat!

Weder hoch- noch runterfahren ;-)

Beim hochfahren gibt es ein Problem mit der Festplatte, die wäre "not Ready", dann kommt irgendwann "Kernel panic" und alles blinkt  und Ende:-)ich muß immer im Safe-mode starten, da gehts, nur hier muß ich jedesmal die Internet-Vebindung aktivieren...

Bei Linux gibt es keinen "Safe-Mode". Was genau startet denn da?
Informationen gibt's aus dem Bootlog, bei SuSE IMHO /var/log/boot.msg
Ohne genaue Angaben wird es schwierig Dir zu helfen.

Beim runterfahren auch so ähnlich, da ist irgenwann einfach schluss, obwohl er noch nicht fertig sein kann.

Hört sich arg nach eine Dateisytemfehler an.

Wo bekomme ich am besten Hilfe bei solchen Problemen?

Wenn Du Deine SuSE ordnungsgemäß erworben hast, hast Du 6 Wochen Support.
Ansonsten schau in die Newsgroups, aber da können Dir andere bestimmt eher einen Tip geben.

Ich habe nämlich noch in 2 anderen Partitionan  Win2K auf NTFS formatierten Partitionen laufen. Das läuft aber ohne Probleme, die Probleme mit Linux traten aber erst auf, als ich Win einmal gestartert hatte.

So etwas tut man ja auch nicht!
Wahrscheinlich hat einer davon Deine Partitionstabelle "Repariert" oder irgendetwas in der Art. Es gibt ja nur Windows und sämtliche anderen Angaben müssen ergo Fehler sein. >;->

so short

Christoph Zurnieden

[Andreas]

Hi!
ja, ist bei Suse, ich weiß jetzt nicht wirklich ob das schon LILO ist, jedenfalls mußt ich das auf Diskette schreiben, und wenn die drin ist kann ich in einem Suse-Menü auswählen, ob Linux, Linux safe-mode, NT, oder Memory-Test gestartet werden soll.
Jetzt geht aber noch nichtmal mehr der Safe-Mode, zumindest kann ich KDE nicht starten, und hab nur noch die Komandozeile, wenn ich KDE eingebe, steht da immer was davon, dass das mit dem Display nicht funktioniert, und bricht ab. Nur mit der Komandozeile komme ich nicht wirklich besonders weit:-)
Nun ja, werde mal den suse Support bemühen, aber ich aber auf eine andere Frage bis jetzt nach 3 Tagen noch keine Rückmeldung erhalten. Mal schaun. Ich werd mir mal die genauen Fehler notieren, mal schaun.

Grüsse
  Andreas

[Christoph Zurnieden]

hallo,

ja, ist bei Suse, ich weiß jetzt nicht wirklich ob das schon LILO ist, jedenfalls mußt ich das auf Diskette schreiben, und wenn die drin ist kann ich in einem Suse-Menü auswählen, ob Linux, Linux safe-mode, NT, oder Memory-Test gestartet werden soll.

Ist wohl der Bootmanager.
Aber was Linux-Safe-mode sein soll ...
(Wofür ist denn der Memory Test? Bei den RAM Preisen? Aber stimmt, ziehen wieder mächtig an)

Jetzt geht aber noch nichtmal mehr der Safe-Mode, zumindest kann ich KDE nicht starten, und hab nur noch die Komandozeile, wenn ich KDE eingebe, steht da immer was davon, dass das mit dem Display nicht funktioniert, und bricht ab. Nur mit der Komandozeile komme ich nicht wirklich besonders weit:-)

Na gut, als Anfänger.
Aber laß Dir gesagt sein, daß Du auf der Kommandozeile genau das Gleiche wie mit KDE machen kannst.(Eigentlich sogar noch mehr)

Nun ja, werde mal den suse Support bemühen, aber ich aber auf eine andere Frage bis jetzt nach 3 Tagen noch keine Rückmeldung erhalten. Mal schaun. Ich werd mir mal die genauen Fehler notieren, mal schaun.

Ja, schnell sind sie nicht.
Aber schonmal versucht von MS Support zu bekommen? >;->

so short

Christoph Zurnieden

[Christoph Zurnieden]

Hallo Zusammen,

mit anderen Worten - ich laß da lieber erstmal die Finger von ;-)

Solange keine Probleme auftauchen:ja.
Wenn Du genügend Platz auf der Platte hast, installier einfach zweimal, dann kannst Du mit einem System experimentieren.

Ich habe da nämlich ein grundsätzlicheres Problem, schön und gut  mit Programmen die ich vergleichbar dem Windows Startmenü öffnen kann, aber jetzt habe ich über YaST2  noch Apache und MySQL instlliert, hat auch alles gemacht, mit Erfolgsmeldung - nur wie komme ich jetzt da dran?????

Apache:
Schau nach ob er läuft:
'ps auxwww | grep httpd'
Wenn nicht, starten (SuSE, aber bitte kontrollieren!):
'/sbin/init.d/apache start'
Dateien liegen meist in einem Verzeichnis namens 'htdocs'.

MySQL:
Schau nach ob es läuft:
' ps auxwww | grep mysql'
Beim Starten gibt es verschieden Methoden, einfach die Dokumentation durchlesen.

Also über das Menü finde ich beides nicht. Oder mit welchem Tool öffnet man solche Programme, bzw. editiert die config Dateien?

Starten mit der Shell, editieren mit Deinem Lieblingseditor.

Es muß doch eine einfache Möglichkeit geben, wenigstens den Apache Server zu starten und zu stoppen!

Starten
'/sbin/init.d/apache start`
Stoppen
'/sbin/init.d/apache stop'

In der Hilfe finde ich vieles zu Apache, aber nirgends steht wie und womit ich das öffne bzw. editiere!

Ja, das Problem kenn ich ;-)

so short

Christoph Zurnieden

[Andreas]

Hi Christoph!

Danke für die Tipps, werde erstmal neu booten evtl hat es sich dann erledigt, sonst versuche ich deine Tipps!

Grüsse
  Andreas

[Andreas]

ES HAT GELKAPPT!

Aber nur durch neu booten! *schäm*

Aber wenn ich phpmyadmin starte, bekommmt der erstmal keine Verbindung zur DB(can't connect to local....)
Jetzt habe ich mal deine Zeile in Shell eingegeben.
Als Antwort kam:

1530 0.0 0.2 1800 748 pts/1     S     18:21 0:00 grep mysql

Kannst Du damit was anfangen?

ich weiß nur gar nicht, was jetzt Suse Linux alles von alleine macht, und was ich noch machen muß! Also Apache ist schonmal da, und PHP auch.
Kann sein, dass ich in phpMyAdmin erstmal den User.. anlegen muß, aber ich gehe fast davon aus, dass auch bei MySQl erstmal noch keiner angelegt ist, in der config.inc.php von phpmyadmin steht lediglich localhost und root als user ohne pw. Bei Windows funktioniert das bei mir schon so. Aber anscheinend fehlt nochwas bei mySQL. Da stand auch was, bevor ich installiert habe, ich sollte irgendwas noch eingeben, nur leider weiß ich nicht mehr was;-)

Weißt Du wie ich da weiterkommen könnte?

Gibt es eigentlich die Möglichkeit Text in aoder aus Shell zu kopieren?

Grüsse
  Andreas

[Christoph Zurnieden]

Hallo,

Aber nur durch neu booten! *schäm*

Naja, ist bei privaten Rechnern meist einfacher, als sich mühselig durch irgendwelche 'killall -HUP programmname' zu quälen ;-)

Aber wenn ich phpmyadmin starte, bekommmt der erstmal keine Verbindung zur DB(can't connect to local....)
Jetzt habe ich mal deine Zeile in Shell eingegeben.
Als Antwort kam:

1530 0.0 0.2 1800 748 pts/1     S     18:21 0:00 grep mysql

Kannst Du damit was anfangen?

Ja. Das ist nur Dein Suchbefehl. Da sonst nichts anderes da steht, läuft MySQL überhaupt nicht. Da ich MySQL von Hand installiert habe, kann ich Dir da kaum helfen. Vielleicht ist da einer der Kollegen so nett?

ich weiß nur gar nicht, was jetzt Suse Linux alles von alleine macht, und was ich noch machen muß! Also Apache ist schonmal da, und PHP auch.

Ist doch schon mal was! ;-)

Kann sein, dass ich in phpMyAdmin erstmal den User.. anlegen muß, aber ich gehe fast davon aus, dass auch bei MySQl erstmal noch keiner angelegt ist, in der config.inc.php von phpmyadmin steht lediglich localhost und root als user ohne pw.

Das sind IMHO die Defaulteinstellungen. Aber ich benutze nur in den seltensten Fällen Hilfsmittel, da ich meist zu faul bin, die Bedienung zu erlernen ;-)

Bei Windows funktioniert das bei mir schon so.

Da geht es auch kaum anders (je nach Win Version)

Aber anscheinend fehlt nochwas bei mySQL. Da stand auch was, bevor ich installiert habe, ich sollte irgendwas noch eingeben, nur leider weiß ich nicht mehr was;-)

Oje! ;-)))
MySQL läuft (alles IMHO, da ich die Distributionsspezifischen Dinger nicht kenne) bei SuSE als User 'mysql' in der Gruppe 'mysql', schau mal nach, ob der existiert. Wenn ja, sollte eigentlich mehr oder weniger alles gerichtet sein, nur noch den mysqld starten (am besten mit dem Script 'safe_mysql' das irgendwo im Ordner von MySQL liegt). Der braucht dann noch ein paar Argumente, die muß Du Dir selber rausfummeln, da sie spezifisch sind ('man mysql').
Aber SuSE hat auch irgendwo eine große Startdateienconfigdateidingenskirchen, da steht das auch drin.
Vielleicht auch mit Yast1?

Weißt Du wie ich da weiterkommen könnte?

Ohne direkten Zugriff eher nicht. Der kostet allerdings 62,50 EUR/Std + MwSt ;-)
Solltest Du mit meinen Tips nicht weiterkommen ( das nehme ich einfach auch mal an ;-) melde Dich doch einfach per PM, dann gehen wir das mal in Ruhe durch.

Gibt es eigentlich die Möglichkeit Text in aoder aus Shell zu kopieren?

Ja.
Mit der Maus kopieren, mit der mittleren Maustaste einbauen (Alles nur unter X, in der Console braucht es für die Maus ein extra Programm, das aber wieder Ärger unter X machen kann)

so short

Christoph Zurnieden

PS: Die Maustasten müssen alle angegeben werden bei der X Configuration (Bei SuSE heißt das Dingen IMHO SAX o.ä.).
Auch das Scrollrad sind Tasten!
Wenn das Scrollrad auch einen Klick hat, ist eben der die mittlere Maustaste. Hoch/Runter sind dann die Tasten 4 u. 5, falls noch seitlich eine ist, ist das dann 6 (Fällt mir nur ein, weil die PC-Welt einer solchen die seitliche Taste nicht ans Laufen bekommen hat. Tja, zählen müsste man können! Aber wer ist schon die PC-Welt ,-)

[Christian Kruse]

Hoi,

Ja. Das ist nur Dein Suchbefehl. Da sonst nichts anderes da
steht, läuft MySQL überhaupt nicht. Da ich MySQL von Hand
installiert habe, kann ich Dir da kaum helfen. Vielleicht ist da
einer der Kollegen so nett?

Sischer, Sischer ;-)
Bei der Heulsuse muss in der /etc/rc.config der Parameter
'START_MYSQL' auf 'YES' gesetzt werden -- anscheinend sind sie zu
doof zu testen, ob ein Script das x-bit hat oder nicht.

Per Hand kann das DBMS ueber

/sbin/init.d/mysql start

gestartet werden -- oder eben wieder rebooten.

Bei Windows funktioniert das bei mir schon so.

Da geht es auch kaum anders (je nach Win Version)

Doch, es geht. Die MySQL-Userverwaltung ist voellig losgeloest von
der System-Userverwaltung.

Aber SuSE hat auch irgendwo eine große
Startdateienconfigdateidingenskirchen, da steht das auch drin.
Vielleicht auch mit Yast1?

Vielleicht auch einfach mal mit Hand? ;-)

Ohne direkten Zugriff eher nicht. Der kostet allerdings 62,50
EUR/Std + MwSt ;-)

Hehe ;-) das will ich auch verdienen.

Ja.
Mit der Maus kopieren,

Markieren meinst du glaube ich ;-)

mit der mittleren Maustaste einbauen (Alles nur unter X, in der
Console braucht es für die Maus ein extra Programm, das aber
wieder Ärger unter X machen kann)

Eigentlich nicht. Die Mouse-Daemonen fuer die Konsole arbeiten
eigentlich recht gut mit X11 zusammen.

(Fällt mir nur ein, weil die PC-Welt einer solchen die seitliche
Taste nicht ans Laufen bekommen hat. Tja, zählen müsste man
können!

*lol* Typisch

Aber wer ist schon die PC-Welt ,-)

Eine Zeitschrift, glaub ich ;-)

Gruesse,
 CK

[Christoph Zurnieden]

Hallo,

Ja. Das ist nur Dein Suchbefehl. Da sonst nichts anderes da
steht, läuft MySQL überhaupt nicht. Da ich MySQL von Hand
installiert habe, kann ich Dir da kaum helfen. Vielleicht ist da
einer der Kollegen so nett?

Bei Windows funktioniert das bei mir schon so.

Da geht es auch kaum anders (je nach Win Version)

Doch, es geht. Die MySQL-Userverwaltung ist voellig losgeloest von
der System-Userverwaltung.

Die war da nicht gemeint, aber egal ;-)

Aber SuSE hat auch irgendwo eine große
Startdateienconfigdateidingenskirchen, da steht das auch drin.
Vielleicht auch mit Yast1?

Vielleicht auch einfach mal mit Hand? ;-)

Och nö, selbst ich mag auf einen richtigen Editor nicht mehr verzichten, die Arbeit mit cat und sed ist einfach zu aufwendig ;-)

Ohne direkten Zugriff eher nicht. Der kostet allerdings 62,50
EUR/Std + MwSt ;-)

Hehe ;-) das will ich auch verdienen.

Mußt' nur jemanden finden, der das zahlt ;-)
(Der Preis ist aber absichtlich so hoch um prohibitiv zu wirken. Bevor noch jemand kommt und mich wirklich bestellt, soll er sich das dreimal überlegen. Und für _den_ Preis komme ich dann gerne ;-)

Ja.
Mit der Maus kopieren,

Markieren meinst du glaube ich ;-)

Nein, unter X wird auf die Methode schon kopiert. Ein eigentliches "Textmarkieren" gibt es da nicht.
Das kann übrigens auch zur Falle werden ;-)

mit der mittleren Maustaste einbauen (Alles nur unter X, in der
Console braucht es für die Maus ein extra Programm, das aber
wieder Ärger unter X machen kann)

Eigentlich nicht. Die Mouse-Daemonen fuer die Konsole arbeiten
eigentlich recht gut mit X11 zusammen.

Schön wär's!
So oft, wie ich da schon Ärger mit gehabt habe ...

so short

Christoph Zurnieden

[Christian Kruse]

Hoi,

Die war da nicht gemeint, aber egal ;-)

Tja, dann hab ichs falsch verstanden, offensichtlich ;-)

Och nö, selbst ich mag auf einen richtigen Editor nicht mehr
verzichten, die Arbeit mit cat und sed ist einfach zu aufwendig ;-)

*g* 'mit Hand' muesste aber eigentlich 'mit vi' heissen -- immerhin war
vi der erste Editor fuer Unizes.

Mußt' nur jemanden finden, der das zahlt ;-)

Das ist ja das Problem ;-)

(Der Preis ist aber absichtlich so hoch um prohibitiv zu wirken.

*g* habs mir gedacht

Bevor noch jemand kommt und mich wirklich bestellt, soll er sich das
dreimal überlegen. Und für _den_ Preis komme ich dann gerne ;-)

Ich auch, btw ;-)

Markieren meinst du glaube ich ;-)

Nein, unter X wird auf die Methode schon kopiert.

Ja, aber der Vorgang selber heisst 'markieren'. Da lass ich nicht mit
mir handlen! ;-)

Ein eigentliches "Textmarkieren" gibt es da nicht.
Das kann übrigens auch zur Falle werden ;-)

Oh ja... *Geschichten erzaehlen koennte*

Schön wär's!
So oft, wie ich da schon Ärger mit gehabt habe ...

Ich noch keine ;-)

Gruesse,
 CK

[Michael Schröpl]

Hi Andreas,

Es muß doch eine einfache Möglichkeit geben, wenigstens den Apache
Server zu starten und zu stoppen!
In der Hilfe finde ich vieles zu Apache, aber nirgends steht wie
und womit ich das öffne bzw. editiere!

Der freundliche Tankwart empfiehlt die Apache-Dokumentation:
http://httpd.apache.org/docs/invoking.html#unix

Was mich an den diversen Methoden, Apache unter irgendwelchen *IXen zu betreiben, ziemlich stört, ist, daß jeder mit Gewalt seine eigene Verpackung drum herum baut. (Noch mehr stört mich, daß sämtliche Verpacker den Apache derartig verunstalten, daß man sich in seiner Konfiguration kaum noch zurecht findet und massenhaft Hauptspeicher verschwendet.)
In Deinem Falle hat Christoph Dir nicht das Skript genannt, mit dem _man_ den Apache startet, sondern das Skript, mit dem _Dein Linux_ während des _Bootvorgangs_ den Apache zu starten beschlossen hat. Das ist m. e. keineswegs dasselbe. Insbesondere wird dieses Skript den Apache ggf. in einer ganz kompliziert abgewandelten Form starten, weil es mindestens siebenundzwanzig zusätzliche Module einbindet und alles doppelt und dreifach in den Hauptspeicher ballert. (Um das im Detail zu begreifen, hilft einmal mehr nur - lesen, lesen, lesen.)

Deine Apache-Installation - wo immer diese sich auf Deiner Platte auch befinden mag - enthält u. a. ein Unterverzeichnis 'bin', in welchem auch das Programm 'httpd' liegt (das ist 'der Apache').
In diesem Verzeichnis befindet sich - normalerweise, falls es Dein Linux-Verpacker nicht ruiniert hat - ein shell-script mit dem Namen 'apachectl'. Dieses kann man von einer Kommandozeile aus aufrufen, und es unterstützt Operatoren wie 'start', 'stop', 'restart', 'graceful', 'configtest' usw. Erforderliche Pfadnamen sind bei der Apache-Installation in dieses Skript eingebrannt worden (u. a. muß es den Namen einer Datei kennen, in welcher der Apache seine Prozeßkennung ablegt, damit das Skript ihm per 'kill' Signale senden kann).
Das ist die Methode, mit der man nach Meinung der Apache Group einen Apache starten sollte - und weil dieses Skript nicht zum Betriebssystem, sondern eben zum Apache gehört, ist es _immer_ da, wenn man einen Apache hat.

Insbesondere wird es auch da sein, wenn Du Dir mal einen neuen Apache von httpd.apache.org holen und installieren willst.
Ich mag z. B. schnuckelige kleine Apaches mit ca. 400 kB httpd-binary und _ohne_ tonnenweise nachgeladenen shared Code, die trotzdem 'alles' können, was man so braucht ... selbst von der Apache-Standardauslieferung kann man bequem die Hälfte weglassen, wenn man das Programm selbst übersetzt. Bei Dir zum 'Spielen' ist es wahrscheinlich wurscht, aber wenn der Apache auf einem produktiven Server mit 256 Instanzen läuft, dann ist es schade um jedes überflüssige Kilobyte. Umgekehrt gibt es auch ein paar Erweiterungen, die in Standard-Apaches nicht drin sind und die man ggf. gerne haben will - dieser Apache, der Dir gerade mein Posting geliefert hat, spricht beispielsweise gzip-komprimiert mit Deinem Browser (falls letzterer dies bereits versteht).

Und das Übersetzen geht mit genau zwei shell-Befehlen:
1. 'configure' (mit vielen Parametern - da gibt man halt an, was man
   haben will und was nicht, siehe Dokumentation; ich habe mir das
   entsprechende Kommando in eine Datei abgespeichert) und
2. 'make install'
... und fertig. Ich denke, das kriegst Du hin.

Im Gegensatz zum UNIX-Kernel kannst Du zudem prima viele Apaches gleichzeitig nebeneinander laufen lassen - solange jeder auf seinen eigenen Port lauscht (_eine_ Zeile in der httpd.conf anpassen), stören die sich gegenseitig nicht. Experimentieren mit einer Kopie ist hier also völlig risikolos.

Viele Grüße
      Michael

[Christoph Zurnieden]

Hallo Zusammen,

Es muß doch eine einfache Möglichkeit geben, wenigstens den Apache
Server zu starten und zu stoppen!
In der Hilfe finde ich vieles zu Apache, aber nirgends steht wie
und womit ich das öffne bzw. editiere!

Der freundliche Tankwart empfiehlt die Apache-Dokumentation:
http://httpd.apache.org/docs/invoking.html#unix

Ich ging höflicherweise davon aus, daß er da schon geschaut hat.
Nein, gut, ich gebe es zu: mir fiel der Link nicht auf Anhieb ein ;-)

Was mich an den diversen Methoden, Apache unter irgendwelchen *IXen zu betreiben, ziemlich stört, ist, daß jeder mit Gewalt seine eigene Verpackung drum herum baut. (Noch mehr stört mich, daß sämtliche Verpacker den Apache derartig verunstalten, daß man sich in seiner Konfiguration kaum noch zurecht findet und massenhaft Hauptspeicher verschwendet.)

Da sprichst Du ein wahres Wort gelassen aus.
Da kann man noch nicht einmal irgendeine Distribution herausnehmen, von denen hat sich keiner mit Ruhm bekleckert.

In Deinem Falle hat Christoph Dir nicht das Skript genannt, mit dem _man_ den Apache startet, sondern das Skript, mit dem _Dein Linux_ während des _Bootvorgangs_ den Apache zu starten beschlossen hat. Das ist m. e. keineswegs dasselbe.

Ja, leider.

Insbesondere wird dieses Skript den Apache ggf. in einer ganz kompliziert abgewandelten Form starten, weil es mindestens siebenundzwanzig zusätzliche Module einbindet und alles doppelt und dreifach in den Hauptspeicher ballert.

Zumindest bei SuSE ist es nicht ganz so schlimm, aber immer noch schlimmer als die Polizei erlaubt.

Deine Apache-Installation - wo immer diese sich auf Deiner Platte auch befinden mag - enthält u. a. ein Unterverzeichnis 'bin', in welchem auch das Programm 'httpd' liegt (das ist 'der Apache').

Dummerweise gibt es das bei den SuSE's, die mir unter die (rm -rfv *) Finger gerieten gar nicht.

In diesem Verzeichnis befindet sich - normalerweise, falls es Dein Linux-Verpacker nicht ruiniert hat - ein shell-script mit dem Namen 'apachectl'. Dieses kann man von einer Kommandozeile aus aufrufen, und es unterstützt Operatoren wie 'start', 'stop', 'restart', 'graceful', 'configtest' usw. Erforderliche Pfadnamen sind bei der Apache-Installation in dieses Skript eingebrannt worden (u. a. muß es den Namen einer Datei kennen, in welcher der Apache seine Prozeßkennung ablegt, damit das Skript ihm per 'kill' Signale senden kann).

Dummerweise gibt es auch das nicht.

Das ist die Methode, mit der man nach Meinung der Apache Group einen Apache starten sollte - und weil dieses Skript nicht zum Betriebssystem, sondern eben zum Apache gehört, ist es _immer_ da, wenn man einen Apache hat.

Schön wär's ;-)

(IMHO! Kann sich geändert haben. Geändert! Nicht verbessert! >;->)

Insbesondere wird es auch da sein, wenn Du Dir mal einen neuen Apache von httpd.apache.org holen und installieren willst.

Naja, für ein wenig Scripte testen etwas übertrieben. Zumindest vermute ich, daß er das möchte.

Ich mag z. B. schnuckelige kleine Apaches mit ca. 400 kB httpd-binary und _ohne_ tonnenweise nachgeladenen shared Code, die trotzdem 'alles' können, was man so braucht ...

Mein lieber Mann, was hast Du denn da alles drin? Bei mir sind es 245kb. Könnte noch ein Strip versuchen, aha, nur noch 214 kb. ;-)

selbst von der Apache-Standardauslieferung kann man bequem die Hälfte weglassen, wenn man das Programm selbst übersetzt. Bei Dir zum 'Spielen' ist es wahrscheinlich wurscht, aber wenn der Apache auf einem produktiven Server mit 256 Instanzen läuft, dann ist es schade um jedes überflüssige Kilobyte.

Ist ja kein Wunder, wenn die Asiaten den RAM-Preis in die Höhe treiben ;-)

Und das Übersetzen geht mit genau zwei shell-Befehlen:

(wobei der Erste allerdings über 5 Zeilen geht ;-)

1. 'configure' (mit vielen Parametern - da gibt man halt an, was man
      haben will und was nicht, siehe Dokumentation; ich habe mir das
      entsprechende Kommando in eine Datei abgespeichert) und
2. 'make install'
   ... und fertig. Ich denke, das kriegst Du hin.

Hatte sich beim letzten Versuch beschwert. Zu alte GLibc. (Gibt es für den Schrott eigentlich keine Alternative?).

Außerdem wollte er um's Verrecken keinen SSL Support. Läuft jetzt über Proxy.
(Er sagt: ist eincompiliert; der Hexdump sieht auch danach aus, nur laufen will er einfach nicht)

Im Gegensatz zum UNIX-Kernel kannst Du zudem prima viele Apaches gleichzeitig nebeneinander laufen lassen - solange jeder auf seinen eigenen Port lauscht (_eine_ Zeile in der httpd.conf anpassen), stören die sich gegenseitig nicht. Experimentieren mit einer Kopie ist hier also völlig risikolos.

Macht aber trotzdem Spaß! ;-)))

so short

Christoph Zurnieden

[Michael Schröpl]

Hi Christoph,

Hallo Zusammen,

Oh - interessanter Vorname ... ;-)

Mein lieber Mann, was hast Du denn da alles drin?

http_core.c
  mod_log_config.c
  mod_mime.c
  mod_include.c
  mod_autoindex.c
  mod_dir.c
  mod_cgi.c
  mod_alias.c
  mod_access.c
  mod_gzip.c
-rwxr-xr-x   1 root     other     320360 Jan  9 15:23 httpd

Bei mir sind es 245kb.

Plattform, Compiler, CPU-Architektur? (Ich SunOS, nix Linux.)
Hast Du mehr als '-O2' verwendet?

Könnte noch ein Strip versuchen, aha, nur noch 214 kb. ;-)

Ich denke, das ist bei 'make install' schon dabei.
Bei mir bringt es nämlich nix mehr.

(wobei der Erste allerdings über 5 Zeilen geht ;-)

./configure --prefix=/usr/local/apache/1.3.22/                 \               --activate-module=src/modules/extra/mod_gzip.c     \               --disable-module=actions                           \               --disable-module=asis                              \               --disable-module=auth                              \               --disable-module=env                               \               --disable-module=imap                              \               --disable-module=negotiation                       \               --disable-module=setenvif                          \               --disable-module=status                            \               --disable-module=userdir                           \               --disable-rule=expat

Hatte sich beim letzten Versuch beschwert. Zu alte GLibc.
(Gibt es für den Schrott eigentlich keine Alternative?).

Mit dem SunOS-Compiler wäre es auch ein Trauerspiel.
(Zum Glück hat hier der Admin ein GCC-package installiert.)

Viele Grüße
      Michael

[Christian Kruse]

Hoi,

Mein lieber Mann, was hast Du denn da alles drin?

http_core.c
  mod_log_config.c
  mod_mime.c
  mod_include.c
  mod_autoindex.c
  mod_dir.c
  mod_cgi.c
  mod_alias.c
  mod_access.c
  mod_gzip.c
-rwxr-xr-x   1 root     other     320360 Jan  9 15:23 httpd

mod_gzip hast du fest mit eincompiliert? Das blaeht natuerlich
die Binary ziemlich auf.

Könnte noch ein Strip versuchen, aha, nur noch 214 kb. ;-)

Ich denke, das ist bei 'make install' schon dabei.
Bei mir bringt es nämlich nix mehr.

Das muss nichts heissen. Manche Compiler brauchen kein 'strip' mehr,
sie trennen die Debug-Symbole schon von selbst heraus. Aber
ueberhaupt halte ich das fuer sehr unsinnig, zu strip-en: es wird
ja nicht die komplette Binary geladen, die Symbol-Tabellen (die man
mit strip entfernen kann) werden erstmal nicht mit geladen -- es
bringt also effektiv null.

[... configure-Aufruf ...]

Warum compilierst du mod_gzip fest mit ein?

Hatte sich beim letzten Versuch beschwert. Zu alte GLibc.
(Gibt es für den Schrott eigentlich keine Alternative?).

Natuerlich gibt es Alternativen zur glibc ;-) Die glibc ist
eigentlich sogar recht verrufen, sie sei unsauber programmiert, etc.
Ich kann dazu nicht viel sagen, ich weiss es nicht. Suche mal bei
http://groups.google.com/, da solltest du Infos darueber
finden.

Gruesse,
 CK

[Michael Schröpl]

Hi Christian,

mod_gzip hast du fest mit eincompiliert? Das blaeht natuerlich
die Binary ziemlich auf.

Da ich es aber in allen Virtual Hosts verwende, wäre es ohnehin in jedem
Apache-Prozeß geladen.
Ich sehe nicht, was ich durch dynamisches Nachladen sparen könnte.

Warum compilierst du mod_gzip fest mit ein?

• Einerseits, weil ich es eh überall brauche;
• andererseits, weil ich überhaupt alles eincompiliere
    (und dann kein mod_so mehr drin habe).
  Ich habe mal irgendwo gelesen, daß Code über die SO-Schnittstelle teilweise
  komplizierter adressiert werden muß und dadurch ca. 5-10% langsamer werden kann.

Viele Grüße
      Michael

[Christian Kruse]

Hoi Michael,

Ich habe mal irgendwo gelesen, daß Code über die SO-Schnittstelle
teilweise komplizierter adressiert werden muß und dadurch ca. 5-10%
langsamer werden kann.

Oh. das wusste ich noch gar nicht ;-) Danke fuer den Hinweis.

Gruesse,
 CK

[Michael Schröpl]

Hi Christian,

Ich habe mal irgendwo gelesen, daß Code über die SO-Schnittstelle
teilweise komplizierter adressiert werden muß und dadurch ca. 5-10%
langsamer werden kann.
Oh. das wusste ich noch gar nicht ;-) Danke fuer den Hinweis.

• The server is approximately 20% slower at startup time because of the
    symbol resolving overhead the Unix loader now has to do.
• The server is approximately 5% slower at execution time under some
    platforms because position independent code (PIC) sometimes needs
    complicated assembler tricks for relative addressing which are not
    necessarily as fast as absolute addressing.

Nicht, daß ich wüßte, auf welche Plattformen sich das bezieht ...

Die Quelle dazu: http://httpd.apache.org/docs/dso.html

Viele Grüße
      Michael

[Michael Schröpl]

Hi Christian,

mod_gzip hast du fest mit eincompiliert? Das blaeht natuerlich
die Binary ziemlich auf.

Ich habe es mal versuchsweise rausgenommen - das würde meinen httpd
von 319 auf 277 KB reduzieren.
Diese 42 KB halte ich aber aus - bei Komprimierungsraten bis zu 96%
während der Übertragung generierter HTML-Tabellen.

Viele Grüße
      Michael

[Christoph Zurnieden]

Hallo,

Mein lieber Mann, was hast Du denn da alles drin?

mod_gzip hast du fest mit eincompiliert? Das blaeht natuerlich
die Binary ziemlich auf.

Bestimmte Dinge sind fest eincompiliert einfach schneller.

Könnte noch ein Strip versuchen, aha, nur noch 214 kb. ;-)

Ich denke, das ist bei 'make install' schon dabei.
Bei mir bringt es nämlich nix mehr.

Das muss nichts heissen. Manche Compiler brauchen kein 'strip' mehr,
sie trennen die Debug-Symbole schon von selbst heraus.

Sind erst gar keine drin beim GCC, es sei denn, Du baust sie explizit ein.

Aber ueberhaupt halte ich das fuer sehr unsinnig, zu strip-en: es wird
ja nicht die komplette Binary geladen, die Symbol-Tabellen (die man
mit strip entfernen kann) werden erstmal nicht mit geladen -- es
bringt also effektiv null.

Man kann schon ein wenig mehr entfernen, als nur die Tabellen.
`man strip'

Hatte sich beim letzten Versuch beschwert. Zu alte GLibc.
(Gibt es für den Schrott eigentlich keine Alternative?).

Natuerlich gibt es Alternativen zur glibc ;-)

Links bitte, Links!

Die glibc ist
eigentlich sogar recht verrufen, sie sei unsauber programmiert, etc.

Unsauber vielleicht nicht gerade, aber sehr viele Merkwürdigkeiten enthält sie schon.

Ich kann dazu nicht viel sagen, ich weiss es nicht.

Schade.

Suche mal bei
http://groups.google.com/, da solltest du Infos darueber
finden.

Ja, _was_ mit der GLibC nicht stimmt, weiß ich. Ich dachte es gäbe gute Alternativen. (Wobei es mich nach kurzem Nachdenken eigentlich wundern müßte, davon noch nichts gehört zu haben ;-)
Es hilft also nur selbermachen, was? *sigh*

so short

Christoph Zurnieden

[Christian Kruse]

Hoi,

Bestimmte Dinge sind fest eincompiliert einfach schneller.

Ich wusste nicht, dass das bei Apache-Modulen so viel ausmachen kann.

Sind erst gar keine drin beim GCC, es sei denn, Du baust sie explizit
ein.

Das ist nicht bei allen Compilern so, afaik.

Man kann schon ein wenig mehr entfernen, als nur die Tabellen.
`man strip'

`man strip' sagt mir nichts darueber. Kannst du etwas genauer werden?

Hatte sich beim letzten Versuch beschwert. Zu alte GLibc.
(Gibt es für den Schrott eigentlich keine Alternative?).

Natuerlich gibt es Alternativen zur glibc ;-)

Links bitte, Links!

http://www.fefe.de/dietlibc/ (von Felix von Leitner)
http://www.uclibc.org/ (von Erik Anderson)

mal Googeln halt ;-)

Die glibc ist
eigentlich sogar recht verrufen, sie sei unsauber programmiert, etc.

Unsauber vielleicht nicht gerade, aber sehr viele Merkwürdigkeiten
enthält sie schon.

Welche Merkwuerdigkeiten? ;-) Ich weiss es selber nicht. Ich habe es mir
nur sagen lassen, FvL z. B. meinte, dass die glibc sehr unsauber sei.

Ja, _was_ mit der GLibC nicht stimmt, weiß ich. Ich dachte es gäbe gute
Alternativen. (Wobei es mich nach kurzem Nachdenken eigentlich wundern
müßte, davon noch nichts gehört zu haben ;-)

Hehe ;-)

Es hilft also nur selbermachen, was? *sigh*

Dazu habe ich zu wenig Ahnung von sowas. Da muss ich wohl erst das neue
Buch durchackern ;-) (Advanced Programming In The UNIX(TM) Environment)

Gruesse,
 CK

[Michael Schröpl]

Hi,

Man kann schon ein wenig mehr entfernen, als nur die Tabellen.
man strip' man strip' sagt mir nichts darueber. Kannst du etwas genauer werden?

OPTIONS
     The amount of information stripped from the  ELF object file
     can be controlled by using any of the following options:

-b        Same effect as the default behavior.  This  option
               is  obsolete  and  will  be  removed  in  the next
               release.

-l        Strip line number information only; do  not  strip
               the symbol table or debugging information.

-r        Same effect as the default behavior.  This  option
               is  obsolete  and  will  be  removed  in  the next
               release.

-V        Print, on standard error, the  version  number  of
               strip .

-x        Do not strip the symbol table; debugging and  line
               number information may be stripped.

"strip -l" und "strip -x" reduzieren die Größe des httpd-binaries in
meinem Fall nur marginal (beide bewirken nacheinander etwas);

"strip" ohne Parameter macht die Datei etwa 60 KB kleiner, unabhängig
von ihrer sonstigen Größe (das scheint dann genau die Symboltabelle
zu sein).

Ich bin bestimmt kein C-Experte; ich erinnere mich vage daran, daß
man die Symboltabelle aus Bibliotheken nicht entfernen darf, weil
der Linker sie ja noch braucht; aus gebundenen Programmen darf man
dagegen alles raus machen.
(Richtig geraten? Vor ca. 8 Jahren wußte ich das noch, damals durfte
ich einen automatischen Makefile-Generator basteln ... und dann kam
Perl ... seitdem habe ich keine Zeile C mehr geschrieben.)

Viele Grüße
      Michael

[Christoph Zurnieden]

Hallo,

Man kann schon ein wenig mehr entfernen, als nur die Tabellen.
man strip' man strip' sagt mir nichts darueber. Kannst du etwas genauer werden?

OPTIONS

[ 'n paar Optionen]

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

Ich bin bestimmt kein C-Experte; ich erinnere mich vage daran, daß
man die Symboltabelle aus Bibliotheken nicht entfernen darf, weil
der Linker sie ja noch braucht; aus gebundenen Programmen darf man
dagegen alles raus machen.
(Richtig geraten? Vor ca. 8 Jahren wußte ich das noch, damals durfte
ich einen automatischen Makefile-Generator basteln ... und dann kam
Perl ... seitdem habe ich keine Zeile C mehr geschrieben.)

Sie wird auch nicht ganz entfernt, sonder nur gekürzt. Inclusive Entfernung überflüssiger Objekte, Kommentare und ein paar Kleinigkeiten.
Bei statisch gelinkten Programmen kannst Du dann aber wirklich brutal werden und sogar die Funktionen aus der Libc entfernen, die Du nicht brauchst ;-)

so short

Christoph Zurnieden

[Michael Schröpl]

Hi Christoph,

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" ...

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 ... ich glaube, tiefer als "make install" will ich in die Materie doch nicht (mehr) eindringen.

Viele Grüße
      Michael

[Christoph Zurnieden]

Hi Christoph,

Hallo Zusammen,

Oh - interessanter Vorname ... ;-)

Ich spreche eigentlich seltenst jemanden persönlich an, ist schließlich ein Forum, gelle? ;-)

Mein lieber Mann, was hast Du denn da alles drin?

[...]

-rwxr-xr-x   1 root     other     320360 Jan  9 15:23 httpd

Bei mir sind es 245kb.

Plattform, Compiler, CPU-Architektur? (Ich SunOS, nix Linux.)

$ uname -a
$ Linux yals 2.2.7cz #1 Sat Oct 20 06:07:13 MEST 2001 i586 unknown

(vom ursprünglichen 2.2.7 ist nicht mehr allzuviel übrig ;-)

$ gcc --version
$ 2.95.2cz

Aber das liegt wahrscheinlich am meisten an der unterschiedlichen Austattung des Apachen, weniger an der Architektur. Ich habe mal ein Crosscompile auf 64Bit versucht, der Unterschied war marginal.

Hast Du mehr als '-O2' verwendet?

Ja. Könnte man also noch mehr in der Größe optimieren, falls heutzutage Speicher wirklich noch die große Rolle spielt.
Ich befürchte aber signifikante Geschwindigkeitseinbußen.

Hatte sich beim letzten Versuch beschwert. Zu alte GLibc.
(Gibt es für den Schrott eigentlich keine Alternative?).

Mit dem SunOS-Compiler wäre es auch ein Trauerspiel.
(Zum Glück hat hier der Admin ein GCC-package installiert.)

Naja, so das Gelbe vom Ei ist der auch nicht gerade ;-)

so short

Christoph Zurnieden

[Michael Schröpl]

Hi Christoph,

Ich spreche eigentlich seltenst jemanden persönlich an,

Ich schon. ("SelfHTML-Forum - da werden Sie geholfen.")

ist schließlich ein Forum, gelle? ;-)

<eg>Meinst Du, die Browserweichenbastler lesen hier noch mit?</eg>

Plattform, Compiler, CPU-Architektur? (Ich SunOS, nix Linux.)
$ Linux yals 2.2.7cz #1 Sat Oct 20 06:07:13 MEST 2001 i586 unknown
Aber das liegt wahrscheinlich am meisten an der unterschiedlichen
Austattung des Apachen, weniger an der Architektur. Ich habe mal
ein Crosscompile auf 64Bit versucht, der Unterschied war marginal.

Yep - ich habe mal meinen Apache auf irgend einer ollen Suse-Box, die
hier herum steht ("Linux 2.2.1" und "egcs 2.91.66", was immer das sein
mag), übersetzt - die Größe war fast identisch zur Sun-Version.
(Dort bewirkte das "strip" übrigens noch einiges, auf der Sun nicht.)

Hast Du mehr als '-O2' verwendet?
Ja.

Immerhin steht in der src/Configuration:
"# Optimization note:
 # Be careful when adding optimization flags (like -O3 or -O6) on the OPTIM
 # entry, especially when using some GCC variants. Experience showed that using
 # these for compiling Apache is risky. If you don't want to see Apache dumping
 # core regularly then at most use -O or -O2.
 #"
"regularly" - so, so ... da war mein 'Heldenmut' dann doch eher endlich,
wenn es um Produktionsmaschinen geht ... wie 'tapfer' bist Du denn? ;-)

Könnte man also noch mehr in der Größe optimieren, falls
heutzutage Speicher wirklich noch die große Rolle spielt.
Ich befürchte aber signifikante Geschwindigkeitseinbußen.

Ich hätte gedacht, mehr Optimierung (d. h. 'aggressiveres Raten') wäre
eher 'schlauer' und schneller?

Also auf der Linux-Box mal schnell -O6 angegeben und neu übersetzt -
und siehe da: Das Programm wird dabei größer! (Von 277 auf 302 KB.)
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.
Und dabei kann der Compiler halt auch falsch raten, wenn unsauberer Code
z. B. davon lebt, daß einzelne Anweisungen obskure Seiteneffekte haben ...

Mein gcc-Compiler auf Solaris scheint uuuralt zu sein ('gcc -v': 2.8.1,
März 1998 ???), bei dem passiert oberhalb von -O3 nichts mehr (ich habe
gerade alle Stufen durchprobiert).
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.

Ab -O3 scheinen mir also die aggressiven Optimierungen anzufangen, die
bereit sind, Geschwindigkeit für Speicher einzukaufen.
(Bei mir von 358 auf 393 KB binary und fünf Seiten Hauptspeicher mehr
belegt, gemessen jeweils zweimal: Direkt nach Apache-Start und nochmal
nach Anforderung zweier definierter Seiten, einer statischen und einer
SSI - wodurch die Speicherbelegung um ca. 20% zunimmt, obwohl alles fest
einkompiliert ist; das werden wohl dynamisch angeforderte Puffer sein
oder etwas was Ähnliches.)

Mit dem SunOS-Compiler wäre es auch ein Trauerspiel.
(Zum Glück hat hier der Admin ein GCC-package installiert.)
Naja, so das Gelbe vom Ei ist der auch nicht gerade ;-)

Was würdest Du mir empfehlen? (gcc 3.0.3, 2001-12-20 ... ?)

Viele Grüße
      Michael

[Christoph Zurnieden]

Hallo,

Ich spreche eigentlich seltenst jemanden persönlich an,

Ich schon. ("SelfHTML-Forum - da werden Sie geholfen.")

Ich habe jetzt nur "Hallo" genommen. So besser? ;-)

ist schließlich ein Forum, gelle? ;-)

<eg>Meinst Du, die Browserweichenbastler lesen hier noch mit?</eg>

Äh ...
Glaube kaum.;-)

BTW: Wenn Du _hier_ XML benutzt, dann doch bitte korrekt, ja? >;->

Plattform, Compiler, CPU-Architektur? (Ich SunOS, nix Linux.)
$ Linux yals 2.2.7cz #1 Sat Oct 20 06:07:13 MEST 2001 i586 unknown
Aber das liegt wahrscheinlich am meisten an der unterschiedlichen
Austattung des Apachen, weniger an der Architektur. Ich habe mal
ein Crosscompile auf 64Bit versucht, der Unterschied war marginal.

Yep - ich habe mal meinen Apache auf irgend einer ollen Suse-Box, die
hier herum steht ("Linux 2.2.1" und "egcs 2.91.66", was immer das sein
mag), übersetzt - die Größe war fast identisch zur Sun-Version.
(Dort bewirkte das "strip" übrigens noch einiges, auf der Sun nicht.)

Ja, ob 'strip' noch etwas entfernen kann, liegt viel am Compiler und am System.

Hast Du mehr als '-O2' verwendet?
Ja.

Immerhin steht in der src/Configuration:
"# Optimization note:

Be careful when adding optimization flags (like -O3 or -O6) on the OPTIM

entry, especially when using some GCC variants. Experience showed that using

these for compiling Apache is risky. If you don't want to see Apache dumping

core regularly then at most use -O or -O2.

#"
"regularly" - so, so ... da war mein 'Heldenmut' dann doch eher endlich,
wenn es um Produktionsmaschinen geht ... wie 'tapfer' bist Du denn? ;-)

Ja, man sollte schon wissen, auf was man sich einläßt ;-)

No risk, no fun!
No suicidal tendencies, no windows!

Aber die Probleme enstehen nur bei alten Versionen. Beim 2.95.2 ist das nicht mehr der Fall (Nur bei wirklich extrem obskuren Sachen, siehe ChangeLog zum 2.95.3)

Könnte man also noch mehr in der Größe optimieren, falls
heutzutage Speicher wirklich noch die große Rolle spielt.
Ich befürchte aber signifikante Geschwindigkeitseinbußen.

Ich hätte gedacht, mehr Optimierung (d. h. 'aggressiveres Raten') wäre
eher 'schlauer' und schneller?

Achso, ich dachte Du meintest Größenoptimierung (z.B. -Os beim GCC)

Also auf der Linux-Box mal schnell -O6 angegeben und neu übersetzt -
und siehe da: Das Programm wird dabei größer! (Von 277 auf 302 KB.)
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 ;-)

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! ;-)

Mein gcc-Compiler auf Solaris scheint uuuralt zu sein ('gcc -v': 2.8.1,
März 1998 ???), bei dem passiert oberhalb von -O3 nichts mehr (ich habe
gerade alle Stufen durchprobiert).

Ja, irgendwann haben die die Feineinteilung aufgegeben, nur der Pentiumoptimierte (pgcc) nutzt sie noch.

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?

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.

(Bei mir von 358 auf 393 KB binary und fünf Seiten Hauptspeicher mehr
belegt, gemessen jeweils zweimal: Direkt nach Apache-Start und nochmal
nach Anforderung zweier definierter Seiten, einer statischen und einer
SSI - wodurch die Speicherbelegung um ca. 20% zunimmt, obwohl alles fest
einkompiliert ist; das werden wohl dynamisch angeforderte Puffer sein
oder etwas was Ähnliches.)

Was das genau ist, läßt sich nur schwer herausfinden ohne Dump;-)

Mit dem SunOS-Compiler wäre es auch ein Trauerspiel.
(Zum Glück hat hier der Admin ein GCC-package installiert.)
Naja, so das Gelbe vom Ei ist der auch nicht gerade ;-)

Was würdest Du mir empfehlen? (gcc 3.0.3, 2001-12-20 ... ?)

Um Gotteswillen, nein!
Aber war wahrscheinlich auch nicht ernstgemeint, oder? ;-)

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 ;-)

Aber ich werde mir im Sommer mal anschauen, was sich da so alles getan hat. Vielleicht sogar mal einen ausprobieren.
Aber solange der Neue C99 nicht vollständig unterstützt, sehe ich keinen großen Sinn zum Wechsel.

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

so short

Christoph Zurnieden

[Michael Schröpl]

Hi Christoph,

<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? ;-)

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 ...)

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 ... ?

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.

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.

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?
(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 ...)

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.

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.

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.

Bei Apache jedenfalls würde ich generell die neueste tatsächlich ausgelieferte Version bevorzugen. 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 ...
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 ...

Viele Grüße
      Michael

[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

[Michael Schröpl]

Hi Christoph,

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

Ich glaube, Du hast hier noch keinen wirklich tief geschachtelten Thread gesehen ...

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 ;-)

Wenn ich '-O2' nicht explizit setze vor dem configure, dann wird httpd
aber viel größer ... ? Das muß man also offenbar 'aktiv wollen'.
(Nein, ich lese keine fremden Makefiles ...)

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 ;-)

Das ist recht so. Da merkt man wenigstens, ob die Apache Group pfuscht oder nicht. (Ich kann damit leben, $PATH notfalls auf einen alten Compiler setzen zu müssen.)

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.

Die Changelogs lese ich in der Tat (Apache ist das einzige Produkt, wo ich das regelmäßig tue).

Wenn ein Security Fix drin ist: updaten, ansonsten: warten.
Die hauen die Versionen relativ rasch raus.

Aber immerhin stoppen sie auch welche, wenn sie versagt haben. Von 1.3.13 und 1.3.18 sind immerhin 4 von 6 Versionen zurückgehalten worden. (Was andererseits irgendwie auch nicht unbedingt für das aktuelle Release-freezing-Verfahren spricht ... aber dafür sind wohl einfach keine Leute mehr da, die aktiven machen halt fast alle 2.0 .)

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.

Apache 1.3.x ist politisch gesehen offenbar sowas von tot, außer security fixes kommt da wohl kaum noch etwas signifikant Neues heraus.

Ich war schon ganz verblüfft, in 1.3.22 überhaupt ein wirklich neues Feature zu finden:

*) Enhancement of mod_auth to handle 'Require file-owner' and
     'Require file-group'.  This allows access if the authenticated
     username (from the appropriate AuthUserFile database) matches
     the username of the UID that owns the document (and equivalent
     checking for file GID and user's membership in AuthGroupFile).
     See the mod_auth documentation for examples.  (Not supported
     on Windows.)  [Ken Coar]

Für Mehrbenutzerbetrieb (Provider etc.) ist das sicher eine brauchbare Idee, die den Einsatz von .htaccess-Dateien sehr vereinfachen könnte.

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? ;-)

Bleibt die Konfigurationssprache von 2.0 strikt aufwärtskompatibel?
(Apache-Konfiguration ist integraler Bestandteil unserer Anwendungen.)

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

Nie gehört. Links, please? (Das könnte von allgemeinem Interesse sein - vermutlich einen eigenen Thread wert. Irgendwer kennt das bestimmt ...)

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?

Wenn sie jemand installiert hätte, sicher. ;-)
Ich habe nicht mal ein gzip drauf, welches die Endung ".gz" versteht, welche die üblichen Archive aus dem WWW haben ... meines hier will unbedingt ".z" am Ende, sonst tut es gerade mal überhaupt nix. :-(

Fein. Dann sollen die autoconf-Leute das mal verstehen und richtig
in den Makefiles verwenden ...
Die Autoconf Entwickler sind da aber nicht schuld dran.

Ich meinte: Dann sollen die autoconf-Leute, die sich mit so etwas ohnehin auskennen müssen, damit befassen - denen glaube ich dann, ich kann es nämlich bestimmt nicht besser.

ich glaube, tiefer als "make install" will ich in die Materie doch nicht (mehr) eindringen.
Ist auch viel besser für die Nerven! ;-)

Das ist gar nicht der Punkt - nur: Ich kann nicht alles machen, sonst verzettele ich mich nur noch. Irgendwo muß Schluß sein.
C als Sprache ist bei uns einfach ausgestorben, und für Perl brauche ich den ganzen make/compile/link-Komplex praktisch nicht mehr.

Viele Grüße
      Michael

[Christoph Zurnieden]

Hallo,

Weiß ja nicht, ob der noch lange genug drin bleibt, aber vielleicht findest Du ihn ja im Archiv ;-)

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

Ich glaube, Du hast hier noch keinen wirklich tief geschachtelten Thread gesehen ...

Oh, das habe ich.
Ich bin schon sehr lange hierbei und kann mich an Dinge entsinnen ... ;-)))

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 ;-)

Wenn ich '-O2' nicht explizit setze vor dem configure, dann wird httpd
aber viel größer ... ? Das muß man also offenbar 'aktiv wollen'.

???
Sehr merkwürdig. Müßte man sich einmal den Code genauer anschauen.

(Nein, ich lese keine fremden Makefiles ...)

Wieso fremd? Die hast Du doch selber in Auftrag gegeben ;-)

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 ;-)

Das ist recht so. Da merkt man wenigstens, ob die Apache Group pfuscht oder nicht. (Ich kann damit leben, $PATH notfalls auf einen alten Compiler setzen zu müssen.)

Zumindest der GCC kann verschiedene Namen tragen (das funktioniert komplett, alle abhängigen Teilprogramme und die Pfade dazu werden angepasst)
Ist ganz nett, wenn man verschiedene braucht/ausprobiert.

Wenn ein Security Fix drin ist: updaten, ansonsten: warten.
Die hauen die Versionen relativ rasch raus.

Aber immerhin stoppen sie auch welche, wenn sie versagt haben. Von 1.3.13 und 1.3.18 sind immerhin 4 von 6 Versionen zurückgehalten worden. (Was andererseits irgendwie auch nicht unbedingt für das aktuelle Release-freezing-Verfahren spricht ... aber dafür sind wohl einfach keine Leute mehr da, die aktiven machen halt fast alle 2.0 .)

"Release early and often!" ;-)

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.

Apache 1.3.x ist politisch gesehen offenbar sowas von tot, außer security fixes kommt da wohl kaum noch etwas signifikant Neues heraus.

Nun, reicht doch für's erste, oder?

Ich war schon ganz verblüfft, in 1.3.22 überhaupt ein wirklich neues Feature zu finden:

*) Enhancement of mod_auth to handle 'Require file-owner' and
     'Require file-group'.  This allows access if the authenticated
     username (from the appropriate AuthUserFile database) matches
     the username of the UID that owns the document (and equivalent
     checking for file GID and user's membership in AuthGroupFile).
     See the mod_auth documentation for examples.  (Not supported
     on Windows.)  [Ken Coar]

Für Mehrbenutzerbetrieb (Provider etc.) ist das sicher eine brauchbare Idee, die den Einsatz von .htaccess-Dateien sehr vereinfachen könnte.

Ach, die haben es tatsächlich geschafft? Ist ja waaaahnsinn! >;->
Gut, daß ich damit nicht direkt zu tun habe ;-)))

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? ;-)

Bleibt die Konfigurationssprache von 2.0 strikt aufwärtskompatibel?
(Apache-Konfiguration ist integraler Bestandteil unserer Anwendungen.)

Welche merkwürdige Anwendung außer einem Konfigurationseditor soll das sein?
Wenn sich da nichts leicht anpassen läßt, solltet ihr mal euren Programmierstil überprüfen! Schließlich bleiben die Funktionen so gut wie gleich, nur die Struktur mag sich ändern. Tja, und wer den Parser nicht strikt vom Rest trennt ... >;->

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

Nie gehört. Links, please? (Das könnte von allgemeinem Interesse sein - vermutlich einen eigenen Thread wert. Irgendwer kennt das bestimmt ...)

Der einzige, der wohl noch am Leben ist, ist TUX, schau einfach mal irgendwo bei RedHat nach, von denen stammt der.

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?

Wenn sie jemand installiert hätte, sicher. ;-)

Dann mach das doch!
Oder ist Dein ~ schon voll? ;-)

Ich habe nicht mal ein gzip drauf, welches die Endung ".gz" versteht, welche die üblichen Archive aus dem WWW haben ... meines hier will unbedingt ".z" am Ende, sonst tut es gerade mal überhaupt nix. :-(

Klamotten gibt es ... ;-)
Wieso gzip überhaupt noch Wert auf eine Endung legt wundert mich eigentlich jedesmal.

Fein. Dann sollen die autoconf-Leute das mal verstehen und richtig
in den Makefiles verwenden ...
Die Autoconf Entwickler sind da aber nicht schuld dran.

Ich meinte: Dann sollen die autoconf-Leute, die sich mit so etwas ohnehin auskennen müssen, damit befassen - denen glaube ich dann, ich kann es nämlich bestimmt nicht besser.

Mach doch mal ein 'info autoconf' und wühl Dich da durch. Dann weißt Du warum so vieles da nicht so ganz ... ähem ... perfekt läuft ;-)

ich glaube, tiefer als "make install" will ich in die Materie doch nicht (mehr) eindringen.
Ist auch viel besser für die Nerven! ;-)

Das ist gar nicht der Punkt - nur: Ich kann nicht alles machen, sonst verzettele ich mich nur noch. Irgendwo muß Schluß sein.

Das sollte _ich_ mir male unbedingt hinter die Ohren schreiben. Ich bin nämlich einer von denen, die nie Nein sagen können, und dann hinterher bis zum Hals in Arbeit stecken ;-)
Anfang letzten Jahres hat man mich noch zu einem Projekt eingeladen. Nur "mal eben" eine GUI basteln.
Ich sag natürlich zu (hatte aber wirklich Langeweile ;-)
Sollte dann wg Portabilität in TCL/Tk sein. Konnte ich bis dahin nicht, aber war mir ganz nett, wollte ich immer schon mal können ;-)
(BTW: TCL ist eine Sch...sprache! Perl/Tk ist dagegen wunderbar ;-)
Am Ende war es nicht nur das, sondern ich habe jetzt auch noch profunde Kenntisse in DTD, XML, XSL, XLST, XPath, XWasweißichnochalles, "Die Kunst der Parsererstellung in C mit Flex und Bison", Vertiefungen in PHP, Perl, Latex, CSS, Kryptographie und, und, und ...

Aber wer weiß wann man's braucht ;-)

C als Sprache ist bei uns einfach ausgestorben,

Wie kommt so was? Kann das keiner mehr?

und für Perl brauche ich den ganzen make/compile/link-Komplex praktisch nicht mehr.

Und gutes Perl ist kaum langsamer als Maschinencode, das ist wohl war.

so short

Christoph Zurnieden

PS:
Ein paar von den meinen Postings (so wie es aussieht, nur die Antworten an den Christian) haben den Forumscrash wohl nicht überlebt, habe ich aber auch erst jetzt gesehen. Meine Entschuldig hiermit in's Archiv, damit ich später drauf verweisen kann ;-)
CZ

[Michael Schröpl]

Hi Christoph

Weiß ja nicht, ob der noch lange genug drin bleibt,
aber vielleicht findest Du ihn ja im Archiv ;-)

Du solltest Dich mal schlau machen, wie das Forum archiviert.
(Jedes unserer Postings ist ein "touch" auf dem Thread ... ;-)

(Nein, ich lese keine fremden Makefiles ...)
Wieso fremd? Die hast Du doch selber in Auftrag gegeben ;-)

Aber nicht die Schablone dazu.

Zumindest der GCC kann verschiedene Namen tragen (das funktioniert
komplett, alle abhängigen Teilprogramme und die Pfade dazu werden
angepasst)

Ich weiß nur nicht, ob autoconf ihn dann noch findet, wenn er anders heißt als "cc" oder "gcc".

"Release early and often!" ;-)

klar, das Markenzeichen von Banana Software ("reift beim Kunden").

Bleibt die Konfigurationssprache von 2.0 strikt aufwärtskompatibel?
(Apache-Konfiguration ist integraler Bestandteil unserer Anwendungen.)
Welche merkwürdige Anwendung außer einem Konfigurationseditor soll das sein?

Ich weiß nicht, wie ich das in kurzen Worten sagen soll.

Ein Produkt installiert einen Apache mit und schreibt dabei dessen Konfiguration automatisch um.

Ein anderes bindet sich teilweise in den Apache ein (als Handler).

Also ganz grundlegende Dinge sollten sich vielleicht nicht unbedingt ändern.
Ich habe mal kurz über die Apache-2.0-Konfiguration drüber geschaut - es sieht so aus, als sollten meine Befürchtungen (an anderer Stelle hatte ich da Negativeres gelesen) unbegründet sein.

Ach, ich vergaß, Du betreibst ja Solaris.
Aber die normalen GNU-Utils sollten da eigentlich auch laufen?
Wenn sie jemand installiert hätte, sicher. ;-)
Dann mach das doch!

Das nützt mir nicht viel, wenn ich die auf meiner "Entwicklungsmaschine" drauf habe und überall sonst nicht. Die Produktionsmaschinen werden von anderen Leuten installiert.

Mach doch mal ein 'info autoconf' und wühl Dich da durch.

Ich _kann_ "nein" sagen. ;-)

C als Sprache ist bei uns einfach ausgestorben,
Wie kommt so was? Kann das keiner mehr?

Eigentlich ist auch Entwicklung ausgestorben - das ist eine längere Geschichte ...

Von dem Zeug, der in C geschrieben ist, habe ich jedenfalls keine Quelltexte - das sind alles installierte black-box-binaries. Aber Perl-Schalen drum herum bauen, _das_ darf ich ... so etwas wie den vor ein paar Tagen beschriebenen "plattformunabhängigen Self-Browser". Und komplette Teile ersetzen und neu schreiben, sofern ich eine 'Sollbruchstelle' gefunden habe, auch.

Viele Grüße
      Michael

[Christoph Zurnieden]

Hallo,

Weiß ja nicht, ob der noch lange genug drin bleibt,
aber vielleicht findest Du ihn ja im Archiv ;-)

Du solltest Dich mal schlau machen, wie das Forum archiviert.
(Jedes unserer Postings ist ein "touch" auf dem Thread ... ;-)

Ach, klappt es jetzt endlich? >;->
(Aber ich verfolge den Code auch nicht ... ähem ... sehr intensiv ;-)

(Nein, ich lese keine fremden Makefiles ...)
Wieso fremd? Die hast Du doch selber in Auftrag gegeben ;-)

Aber nicht die Schablone dazu.

Na gut ;-)

Zumindest der GCC kann verschiedene Namen tragen (das funktioniert
komplett, alle abhängigen Teilprogramme und die Pfade dazu werden
angepasst)

Ich weiß nur nicht, ob autoconf ihn dann noch findet, wenn er anders heißt als "cc" oder "gcc".

Der Compiler bei Autoconf steht meist unter der Shell-Variablen CC, das kann man beim Configure vorgeben. Ansonsten ist ein Alias schnell eingegeben.

"Release early and often!" ;-)

klar, das Markenzeichen von Banana Software ("reift beim Kunden").

Stammt von Eric S. Raymond das Zitat (Cathedral and Bazaar).
Der Unterschied besteht darin, daß OpenSource von dem Vorgehen profitiert (die Öffentlichkeit kann nur dann gut bei der Entwicklungsarbeit helfen, wenn der Stand der Dinge regelmäßig bekannt ist. Heutzutage - vor allem dank Sourceforge.net und Konsorten - kann man mittels CVS (oder einer der 1234 anderen Programme ;-) einen sehr aktuellen Status abfragen.
Bei ClosedSource geht das nicht, auch wenn es so erscheint, als würden sie es trotzdem machen ;-)

Bleibt die Konfigurationssprache von 2.0 strikt aufwärtskompatibel?
(Apache-Konfiguration ist integraler Bestandteil unserer Anwendungen.)
Welche merkwürdige Anwendung außer einem Konfigurationseditor soll das sein?

Ich weiß nicht, wie ich das in kurzen Worten sagen soll.

Ein Produkt installiert einen Apache mit und schreibt dabei dessen Konfiguration automatisch um.

Also ein Konfigurationseditor! >;->
Da es nur beim Installieren gebraucht wird, sollte es nicht viel Arbeit sein. Aber "lästig" ist es schon, klar.

Ein anderes bindet sich teilweise in den Apache ein (als Handler).

Das ist da natürlich unangenehm, läßt sich aber auch bei der Installation regeln.
Mit dem Code von Punkt 1 ;-)

Kleiner Tip: 'httpd -V'
*duck-wech*

Also ganz grundlegende Dinge sollten sich vielleicht nicht unbedingt ändern.
Ich habe mal kurz über die Apache-2.0-Konfiguration drüber geschaut - es sieht so aus, als sollten meine Befürchtungen (an anderer Stelle hatte ich da Negativeres gelesen) unbegründet sein.

Nunja, wer die Konfigurationssyntax umhaut, muß dann auch den neuen Parser schreiben ;-)))

Ach, ich vergaß, Du betreibst ja Solaris.
Aber die normalen GNU-Utils sollten da eigentlich auch laufen?
Wenn sie jemand installiert hätte, sicher. ;-)
Dann mach das doch!

Das nützt mir nicht viel, wenn ich die auf meiner "Entwicklungsmaschine" drauf habe und überall sonst nicht. Die Produktionsmaschinen werden von anderen Leuten installiert.

"Dann mach das doch!" war allgemein gehalten. Kann auch die Bestechung des Sysadmins sein.
Nein, kein Smiley dahinter, ich kenne das "Spiel" :-}

Mach doch mal ein 'info autoconf' und wühl Dich da durch.
Ich _kann_ "nein" sagen. ;-)

;-)

C als Sprache ist bei uns einfach ausgestorben,
Wie kommt so was? Kann das keiner mehr?

Eigentlich ist auch Entwicklung ausgestorben - das ist eine längere Geschichte ...

Von dem Zeug, der in C geschrieben ist, habe ich jedenfalls keine Quelltexte - das sind alles installierte black-box-binaries. Aber Perl-Schalen drum herum bauen, _das_ darf ich ... so etwas wie den vor ein paar Tagen beschriebenen "plattformunabhängigen Self-Browser". Und komplette Teile ersetzen und neu schreiben, sofern ich eine 'Sollbruchstelle' gefunden habe, auch.

Du möchtest mir durch die Blume erklären, daß Du auf Jobsuche bist? >;->

so short

Christoph Zurnieden

[Michael Schröpl]

Hi Christoph,

Von dem Zeug, der in C geschrieben ist, habe ich jedenfalls
keine Quelltexte - das sind alles installierte black-box-binaries.
Aber Perl-Schalen drum herum bauen, _das_ darf ich ... so etwas
wie den vor ein paar Tagen beschriebenen "plattformunabhängigen
Self-Browser". Und komplette Teile ersetzen und neu schreiben,
sofern ich eine 'Sollbruchstelle' gefunden habe, auch.
Du möchtest mir durch die Blume erklären, daß Du auf Jobsuche bist? >;->

nicht wirklich.

Ich kann immerhin ziemlich heftig selbst bestimmen, was ich gerade tun soll.
Das hat auch etwas für sich.

Viele Grüße
      Michael

[Christoph Zurnieden]

hallo Zusammen,

Erstens: Der neue Kernel konkret. Neue Versionen sind NICHT immer
besser, man kann sich damit also durchaus ein stabiles System
instabil machen, oder sonstwas. Das sollte einen etwas davon
abhalten, sofort immer den ultraneuesten Kernel gleich drei
Minuten nach seinem Erscheinen zu installieren. Andererseits
kommen neue Kernel natürlich deswegen raus, weil Fehler behoben
wurden, manchmal sogar sicherheitskritische Fehler. Man sollte
also zumindest ein Ohr auf die Veröffentlichungen über neue Kernel
haben.

Jetzt habe ich ein Problem. Du sagst nichts falsches, aber du
vergisst das wichtigste ;-)

Nein, eigentlich nicht.

Beim Linux-Kernel gibt es ein ausgefeiltes Versions-System: es gibt
Developer-Versionen und User-Versionen. Die Developer-Versionen kann
man als Pre- oder Alpha-Versionen verstehen, fuer die besonders
mutigen. Sie sind mit einer ungraden Versions-Zahl gekennzeichnet.

Kann mißverständlich sein:

stabil:   2.0.x, 2.2.x, 2.4.x ... 3.0.x
instabil: 2.1.x, 2.3.x, 2.5.x ... 3.1.x

Die User-Versionen sind debuggte Developer-Versionen, die im Grunde
gut durchgetestet sind und stabil laufen. Ich haette keine Bedenken,
einen solchen Kernel zu installieren; diese Kernel haben gerade
Versions-Zahlen.

Dazu noch folgendes, bei dem man mit ziemlich hoher Garantie kaum reinfallen kann. (Auch bei anderer Software ;-)

• nimm nie eine Version, die auf '0' endet.

• nimm immer die vorletzte Version und schau nach, was sich dagegen in der letzten Version geändert hat. Entweder brauchst Du das nicht, oder es gab ein Sicherheitsproblem. das wirklich die allerneueste Version erfordert. Halte Dich trotzdem an die Anweisung immer nur die vorletzte Version zu nehmen, warte also auf die nächste.

• wenn Du Dir die Software zusammenstellen kannst (wie den Linuxkernel) nimm wirklich nur genau das, was Du brauchst, nicht einen Deut mehr.

• lies die Dokumentation

• lies die Dokumentation

• lies die Dokumentation

• halte Dich auch daran

Zweitens: Konkret für deine Distribution brauchst du vermutlich
auch den passenden Kernel. Suse paßt die Kernel-Updates irgendwie
an - keine Ahnung, was die machen, hat bislang auch nicht
gestört, wenn ich einen offiziellen Kernel genommen habe, aber
das ist ohne Gewähr.

Große Versionsprünge (z.B. von 2.2.x auf 2.4.x) können in's Auge gehen
Eigentlich ist es sogar recht unwahrscheinlich, daß Du damit keine Probleme hast ;-)

Suse (als Beispiel) gibt sowieso keinen
kostenlosen Installationssupport, wenn du mit dem Kernel
rumspielst und einen eigenen kompilierst.

Eigentlich ist das ziemlich problemlos, wenn man weiss, was man
macht:

root@erde> cd /usr/src
root@erde> mv linux-kernel-sourcen-verzeichnis kernel-src-old

/usr/src/linux ist in allen mir bekannte Fällen ein schlichter Link auf eines der Kernelquellbäume. Bitte nichts mv'en wenn es nicht wirklich nötig ist.

root@erde> fetch url-to-sourcen

Nimm lieber "wget -c", das ist schneller und sicherer.

root@erde> tar -xzf linux-kernel-sourcen.tgz
root@erde> rm -f linux
root@erde> ln -s linux-kernel-sourcen linux
root@erde> cd linux
root@erde> make menuconfig

Alternativ, falls X-Window installiert ist auch ein ' make xconfig', das startet ein kleines aber sehr komfortables TCL/Tk Programm.

root@erde> make bzImage

Zuerst ein 'make zImage' versuchen, erst wenn das wirklich nicht mehr klappt bzImage, aber vorher würde ich kontrollieren, ob da nicht einiges besser als Modul kompiliert weredn könnte. Der große Kernel ist nicht zu empfehlen.

root@erde> make modules modules_install

Das funktioniert nicht unbedingt mit jedem 'make', besser nacheinander ausführen.

root@erde> mv /boot/vmlinuz /boot/vmlinuz.old

Lieber vorher kontrollieren, ob er da überhaupt sitzt!

root@erde> cp arch/i386/boot/bzImage /boot/vmlinuz
root@erde> lilo
root@erde> reboot

Wenn das einmal getan wurde, können bei nachträglichem Bauen von Modulen, diese ohne Reboot angedockt werden. (modprobe modul)

Normalerweise funktionieren die mitgelieferten Kernel prima mit
aller Hardware.

Mit herkoemmlicher Hardware. Wenn man was ausgefallenes hat, uU
schonmal nicht.

Wenn es etwas ausgefallenes ist, funktioniert es nirgendwo auf Anhieb ;-)

Neukompilieren ist eigentlich nur noch dann erforderlich, wenn du
einen langsamen Rechner mit speziellen Aufgaben ausstatten
willst, und Performance rauskitzeln möchtest.

Neukompilieren wuerde ich *immer* empfehlen. Wozu soll so ein riesen
aufgeblaehter Kernel gut sein?

Und warum baust Du dann einen? (bzImage)
Mittlerweile ist aber selbst bei den Distributionen alles ausgelagert, der Kernel gar nicht merh so riesig.
Ein sehr entscheidender Vorteil des Selberkompilierens ist aber der, daß der Kernel genau auf Deine Architektur abgestimmt wird. Bei SuSE z.B. waren die Kernel alle nur für den 386er. ein deutlicher Geschwindigkeitsgewinn ist da zu erwarten wo mindestens ein PentiumPro oder besser läuft.

Mach es, wenn du meinst, ist nicht komplizierter als ein paar
Befehle eingeben, vergiß das Update des Bootmanagers nicht (ganz
wichtig, sonst startet Linux u.U. nicht mehr von Platte), starte
neu und fertig. Die Kernel-Quellen haben ein Readme dabei,
welches alles detailliert beschreibt.

Detailiert?
Schön wär's ;-)
Unangenehmerweise ist immer genau für den Teil, bei dem ich eine zumindest kurze Notiz erwarte gar nichts bei und ich muß mich durch die Quellen wühlen.

Ansonsten gibts bestimmt
noch ein Kernel-HOWTO, welches ebenfalls ausführlich ist.

http://www.linuxdoc.org/

Das ist ein hervorragende Adresse! ;-)

so short

Christoph Zurnieden

[Christian Kruse]

Hoi,

Jetzt habe ich ein Problem. Du sagst nichts falsches, aber du
vergisst das wichtigste ;-)

Nein, eigentlich nicht.

Doch, eigentlich schon.

Beim Linux-Kernel gibt es ein ausgefeiltes Versions-System: es gibt
Developer-Versionen und User-Versionen. Die Developer-Versionen kann
man als Pre- oder Alpha-Versionen verstehen, fuer die besonders
mutigen. Sie sind mit einer ungraden Versions-Zahl gekennzeichnet.

Kann mißverständlich sein:

stabil:   2.0.x, 2.2.x, 2.4.x ... 3.0.x
instabil: 2.1.x, 2.3.x, 2.5.x ... 3.1.x

Richtig.

• lies die Dokumentation
• lies die Dokumentation
• lies die Dokumentation

Du hast was vergessen:

• lies die Dokumentation nochmal
• lies die Dokumentation nochmal
• lies die Dokumentation nochmal

Große Versionsprünge (z.B. von 2.2.x auf 2.4.x) können in's Auge gehen

Eigentlich nicht. Das Update von 2.0er auf den 2.4er Kernel ist absolut
problemlos verlaufen.

/usr/src/linux ist in allen mir bekannte Fällen ein schlichter Link auf
eines der Kernelquellbäume.

Und genau deshalb habe ich geschrieben 'mv linux-kernel-sources' und nicht
'mv linux'.

root@erde> fetch url-to-sourcen

Nimm lieber "wget -c", das ist schneller und sicherer.

Quatsch. Sicherer nur, wenn die Gefahr besteht, dass Download abbricht,
und schneller kein Stueck.

root@erde> tar -xzf linux-kernel-sourcen.tgz
root@erde> rm -f linux
root@erde> ln -s linux-kernel-sourcen linux
root@erde> cd linux
root@erde> make menuconfig

Alternativ, falls X-Window installiert ist auch ein 'make xconfig', das
startet ein kleines aber sehr komfortables TCL/Tk Programm.

s/kompfortabel/unuebersichtlich/

root@erde> make bzImage

Zuerst ein 'make zImage' versuchen, erst wenn das wirklich nicht mehr
klappt bzImage, aber vorher würde ich kontrollieren, ob da nicht
einiges besser als Modul kompiliert weredn könnte. Der große Kernel ist
nicht zu empfehlen.

Auch quatsch. Der Kernel wird dadurch nicht groesser, sondern es werden nur
Teile ausgelagert. Ach ja, ausserdem:

http://www.linuxdoc.org/HOWTO/Kernel-HOWTO-5.html:

In older kernels, you don't have the option to build a
         bzImage; it was simply a zImage. That option is at the
         moment still available, however, given the code size of
         newer kernels, it is now more or less mandatory to build
         a bzImage because the older methods can't handle a kernel
         that's just too large.

'more or less mandatory'...

Wenn du sagst 'ein grosser Kernel ist nicht zu empfehlen', dann stimme ich
dir zu. Man sollte so viel in Module packen, wie es geht.

root@erde> make modules modules_install

Das funktioniert nicht unbedingt mit jedem 'make', besser nacheinander
ausführen.

Quark. Wieso? der Error passiert auch, wenn man es gleichzeitig ausfuehrt.

root@erde> mv /boot/vmlinuz /boot/vmlinuz.old

Lieber vorher kontrollieren, ob er da überhaupt sitzt!

Der liegt bei SuSE-Standard-Installationen da.

root@erde> cp arch/i386/boot/bzImage /boot/vmlinuz
root@erde> lilo
root@erde> reboot

Wenn das einmal getan wurde, können bei nachträglichem Bauen von
Modulen, diese ohne Reboot angedockt werden. (modprobe modul)

Das allerdings nur als root.

Wenn es etwas ausgefallenes ist, funktioniert es nirgendwo auf Anhieb ;-)

Meine TV-Karte lief unter Unix nach einem Kernel-Compile auf Anhieb ;-)

Und warum baust Du dann einen? (bzImage)

bzImage ist kein grosser Kernel (s.o.)

Mittlerweile ist aber selbst bei den Distributionen alles ausgelagert,
der Kernel gar nicht merh so riesig.

Nun, einige (ueberfluessige) Teile koennen nicht als Modul eingebunden
werden.

Ein sehr entscheidender Vorteil des Selberkompilierens ist aber der,
daß der Kernel genau auf Deine Architektur abgestimmt wird. Bei SuSE
z.B. waren die Kernel alle nur für den 386er. ein deutlicher
Geschwindigkeitsgewinn ist da zu erwarten wo mindestens ein PentiumPro
oder besser läuft.

Auch bei einem 486er ist durchaus ein grosser Vorteil zu erwarten. Die
Prozessor-Architektur des 486ers unterscheidet sich wesentlich von der
des 386ers.

Gruesse,
 CK

[Christoph Zurnieden]

Hallo,

Jetzt habe ich ein Problem. Du sagst nichts falsches, aber du
vergisst das wichtigste ;-)
Nein, eigentlich nicht.
Doch, eigentlich schon.

;-)

• lies die Dokumentation
• lies die Dokumentation
• lies die Dokumentation

Du hast was vergessen:

• lies die Dokumentation nochmal
• lies die Dokumentation nochmal
• lies die Dokumentation nochmal

Oh ja!
Und zwar ohne irgendwelche Smileys!

Aber hier im Forum wäre nicht sehr viel los, wenn alle Selfhtml sorgfältig studiert hätten ;-)

Große Versionsprünge (z.B. von 2.2.x auf 2.4.x) können in's Auge gehen

Eigentlich nicht. Das Update von 2.0er auf den 2.4er Kernel ist absolut
problemlos verlaufen.

Sie können, müssen aber selbstverständlich nicht.
Aber man sollte es nicht vergessen und sich um ein Backup zumindest des alten Kernels kümmern. (Und natürlich um einen Eintrag im Bootmanager ;-)

/usr/src/linux ist in allen mir bekannte Fällen ein schlichter Link auf
eines der Kernelquellbäume.

Und genau deshalb habe ich geschrieben 'mv linux-kernel-sources' und nicht
'mv linux'.

Ich würde die da lassen, oder ganz entfernen, nicht umbenennen.
Aber das ist eigentlich auch Geschmacksache, oder eine Frage des Platzes.

root@erde> fetch url-to-sourcen

Nimm lieber "wget -c", das ist schneller und sicherer.

Quatsch. Sicherer nur, wenn die Gefahr besteht, dass Download abbricht,

Die besteht bei den Providern hier in D immer :-(

und schneller kein Stueck.

Bei mir ja, "but your milage may vary" ;-)
Es gibt auch für Linux mittlerweile einige "Downloadmanager" (Die meist nicht viel mehr machen, als in mehreren Instanzen zu ziehen) gibt es da irgendwelche Erfahrungen mit?

root@erde> tar -xzf linux-kernel-sourcen.tgz
root@erde> rm -f linux
root@erde> ln -s linux-kernel-sourcen linux
root@erde> cd linux
root@erde> make menuconfig

Alternativ, falls X-Window installiert ist auch ein 'make xconfig', das
startet ein kleines aber sehr komfortables TCL/Tk Programm.

s/kompfortabel/unuebersichtlich/

Für Leute, die von Windows wechseln, ist das günstiger. >;->
Obwohl ich zugeben muß, damit eigentlich nie gearbeitet zu haben, ich bin da mehr der direkte Mensch und nehme e3 ;-)

root@erde> make bzImage

Zuerst ein 'make zImage' versuchen, erst wenn das wirklich nicht mehr
klappt bzImage, aber vorher würde ich kontrollieren, ob da nicht
einiges besser als Modul kompiliert weredn könnte. Der große Kernel ist
nicht zu empfehlen.

Auch quatsch. Der Kernel wird dadurch nicht groesser, sondern es werden nur
Teile ausgelagert. Ach ja, ausserdem:

http://www.linuxdoc.org/HOWTO/Kernel-HOWTO-5.html:

In older kernels, you don't have the option to build a
         bzImage; it was simply a zImage. That option is at the
         moment still available, however, given the code size of
         newer kernels, it is now more or less mandatory to build
         a bzImage because the older methods can't handle a kernel
         that's just too large.

'more or less mandatory'...

Na gut, ich kenne die Gründe für die Einschränkung 'more-o-less', aber das war zugegebenermaßen etwas beckmesserisch von mir. ;-)

Wenn du sagst 'ein grosser Kernel ist nicht zu empfehlen', dann stimme ich
dir zu. Man sollte so viel in Module packen, wie es geht.

Wie es sinnvoll ist; manches ist fest einkompilert schneller. Aber wirklich nur äußerst marginal, da hast Du schon recht.

root@erde> make modules modules_install

Das funktioniert nicht unbedingt mit jedem 'make', besser nacheinander
ausführen.

Quark. Wieso?

Ältere 'make' machen das nicht mit, da muß es 'make modules && make modules_install' sein.

der Error passiert auch, wenn man es gleichzeitig ausfuehrt.

Ja, aber s.o.

root@erde> mv /boot/vmlinuz /boot/vmlinuz.old

Lieber vorher kontrollieren, ob er da überhaupt sitzt!

Der liegt bei SuSE-Standard-Installationen da.

Jetzt! Bei den Älteren nicht!

root@erde> cp arch/i386/boot/bzImage /boot/vmlinuz
root@erde> lilo
root@erde> reboot

Wenn das einmal getan wurde, können bei nachträglichem Bauen von
Modulen, diese ohne Reboot angedockt werden. (modprobe modul)

Das allerdings nur als root.

Läßt sich ändern, (Für die Paranoiden ;-), aber habe ich vergessen, stimmt.

Wenn es etwas ausgefallenes ist, funktioniert es nirgendwo auf Anhieb ;-)

Meine TV-Karte lief unter Unix nach einem Kernel-Compile auf Anhieb ;-)

Eine TV-Karte ist mittlerweile nichts ausgefallenes mehr ;-)

Mittlerweile ist aber selbst bei den Distributionen alles ausgelagert,
der Kernel gar nicht merh so riesig.

Nun, einige (ueberfluessige) Teile koennen nicht als Modul eingebunden
werden.

Ja, es gibt einige Workarounds z.B. für Mutterbrettchen, die sind meist alle drin (muß ja auch ;-), die können dann aber meist auch alle wieder raus.

Ein sehr entscheidender Vorteil des Selberkompilierens ist aber der,
daß der Kernel genau auf Deine Architektur abgestimmt wird. Bei SuSE
z.B. waren die Kernel alle nur für den 386er. ein deutlicher
Geschwindigkeitsgewinn ist da zu erwarten wo mindestens ein PentiumPro
oder besser läuft.

Auch bei einem 486er ist durchaus ein grosser Vorteil zu erwarten. Die
Prozessor-Architektur des 486ers unterscheidet sich wesentlich von der
des 386ers.

Ja, das ist korrekt, dummerweise ist das dem GAS aber egal :-(
(Das stimmt nicht ganz, aber für Otto Normaluser ist das nicht wichtig, der Effekt ist nicht sicht- höchstens meßbar)

so short

Christoph Zurnieden

[Christian Kruse]

hoi,

Oh ja!
Und zwar ohne irgendwelche Smileys!

*g*

Aber hier im Forum wäre nicht sehr viel los, wenn alle Selfhtml
sorgfältig studiert hätten ;-)

Vielleicht doch? ;-)

Sie können, müssen aber selbstverständlich nicht.

Oha. 'Kann, muss aber nicht'. Das trifft auf so ziemlich alles zu ;-)

Aber man sollte es nicht vergessen und sich um ein Backup zumindest des
alten Kernels kümmern. (Und natürlich um einen Eintrag im
Bootmanager ;-)

Ja, natuerlich. Das halte ich fuer selbstverstaendlich -- eben deshalb
mv ... vmlinuz.old

Bei mir ja, "but your milage may vary" ;-)

Ich wage zu behaupten, das ist Einbildung ;-)

Es gibt auch für Linux mittlerweile einige "Downloadmanager" (Die meist
nicht viel mehr machen, als in mehreren Instanzen zu ziehen) gibt es da
irgendwelche Erfahrungen mit?

Meinerseits nicht, nein.

Für Leute, die von Windows wechseln, ist das günstiger. >;->

Genau diesem Irrtum bin ich auch unterlegen, damals, als ich mit *nix
angefangen hab.

Ältere 'make' machen das nicht mit, da muß es 'make modules && make
modules_install' sein.

'aeltere make' muss dann aber wirklich sehr, sehr alt sein. Das ging schon
als ich damals 1993 auf Linux gewechselt bin.

Jetzt! Bei den Älteren nicht!

Der OP hat von YaST2 gesprochen -> neueres SuSE.

Eine TV-Karte ist mittlerweile nichts ausgefallenes mehr ;-)

Als ich sie bekommen habe, *war* sie noch ausgefallen.

Ja, es gibt einige Workarounds z.B. für Mutterbrettchen, die sind meist
alle drin (muß ja auch ;-), die können dann aber meist auch alle wieder
raus.

Nein, nicht nur. Z. B. grosse Teile des SCSI-Subsystems koennen nur
fest eincompiliert werden.

Ja, das ist korrekt, dummerweise ist das dem GAS aber egal :-(
(Das stimmt nicht ganz, aber für Otto Normaluser ist das nicht wichtig,
der Effekt ist nicht sicht- höchstens meßbar)

Das wage ich zu bestreiten. Ein 486er ist 2 bis 3x so schnell wie ein
386er (bei gleicher Taktfrequenz).

Gruesse,
 CK

[Christoph Zurnieden]

Hallo,

Aber hier im Forum wäre nicht sehr viel los, wenn alle Selfhtml
sorgfältig studiert hätten ;-)

Vielleicht doch? ;-)

Soll das eine Anspielung sein? ;-)

Sie können, müssen aber selbstverständlich nicht.

Oha. 'Kann, muss aber nicht'. Das trifft auf so ziemlich alles zu ;-)

Ja, von "nix passiert" bis "Rootfilesystem ruiniert".

Aber man sollte es nicht vergessen und sich um ein Backup zumindest des
alten Kernels kümmern. (Und natürlich um einen Eintrag im
Bootmanager ;-)

Ja, natuerlich. Das halte ich fuer selbstverstaendlich -- eben deshalb
mv ... vmlinuz.old

Sehr vorbildlich. Und der Eintrag im Bootmanager? ;-)

Bei mir ja, "but your milage may vary" ;-)

Ich wage zu behaupten, das ist Einbildung ;-)

Nein. 'time'. Aber 'fetch' ist bei mir uralt, 'wget' handoptimiert.

Für Leute, die von Windows wechseln, ist das günstiger. >;->

Genau diesem Irrtum bin ich auch unterlegen, damals, als ich mit *nix
angefangen hab.

Ich dachte, die Leute wären gewöhnt an völlig unübersichtliche, total unlogische, hauptsache-schön-bunte GUIs? ;-)

Ältere 'make' machen das nicht mit, da muß es 'make modules && make
modules_install' sein.

'aeltere make' muss dann aber wirklich sehr, sehr alt sein. Das ging schon
als ich damals 1993 auf Linux gewechselt bin.

Mein Gott fühl' ich mich auf einmal _alt_ ;-)

Jetzt! Bei den Älteren nicht!
Der OP hat von YaST2 gesprochen -> neueres SuSE.

Macht nix, gleicher Schrott. >;->

Eine TV-Karte ist mittlerweile nichts ausgefallenes mehr ;-)
Als ich sie bekommen habe, *war* sie noch ausgefallen.

Dann hast Du Glück gehabt.
Ich habe das nie. Da kaufe ich irgendeine Hardware, bei der ich extra vorher nachgeschaut habe, ob es dafür Linux-Unterstützung gibt und was ist? Genau diese Version eben nicht, weil sie in der Charge irgendein Bauteil ausgetauscht haben (wahrscheinlich weil's billiger war ;-).und lediglich an den Namen hinten noch einen Buchstaben in Obscura Light 0.1pt angehangen haben.

Ja, es gibt einige Workarounds z.B. für Mutterbrettchen, die sind meist
alle drin (muß ja auch ;-), die können dann aber meist auch alle wieder
raus.
Nein, nicht nur. Z. B. grosse Teile des SCSI-Subsystems koennen nur
fest eincompiliert werden.

Was, immer noch?
naja, würde ich wahrscheinlich auch selber fest verdrahten, je nach Anwendungszweck.

Ja, das ist korrekt, dummerweise ist das dem GAS aber egal :-(
(Das stimmt nicht ganz, aber für Otto Normaluser ist das nicht wichtig,
der Effekt ist nicht sicht- höchstens meßbar)

Das wage ich zu bestreiten. Ein 486er ist 2 bis 3x so schnell wie ein
386er (bei gleicher Taktfrequenz).

Ja, das liegt aber an der inneren Architektur, weniger an den 2(?) zusätzlichen Opcodes, die der GAS nur auf Nachfrage benutzt, da wenig sinnvoll.

so short

Christoph Zurnieden

PS: irgendwann werden wir wohl kräftig einen auf den Sack bekommen, weil nun wirklich _völlig_ OT ;-)

[Christian Kruse]

Hoi,

Soll das eine Anspielung sein? ;-)

Nee. Sollte eher heissen, dann haetten wir hier vielleicht
mal *interessante* Sachen.

Ja, von "nix passiert" bis "Rootfilesystem ruiniert".

Ich meinte eher, man kann auf so ziemlich *jede* Aktion diesen Spruch
anwenden ;-)

Sehr vorbildlich. Und der Eintrag im Bootmanager? ;-)

Der war mir zu umstaendlich. Ich hatte keine Lust, den vi nachzubilden ;-)

Nein. 'time'. Aber 'fetch' ist bei mir uralt, 'wget' handoptimiert.

Aha.

Ich dachte, die Leute wären gewöhnt an völlig unübersichtliche, total
unlogische, hauptsache-schön-bunte GUIs? ;-)

Damals gabs noch kein Win95 ;-)

Mein Gott fühl' ich mich auf einmal _alt_ ;-)

Wann *bist* du denn angefangen?

Macht nix, gleicher Schrott. >;->

Stimmt ;-)

Dann hast Du Glück gehabt.

Das bestreite ich nicht ;-)

Ich habe das nie. Da kaufe ich irgendeine Hardware, bei der ich extra
vorher nachgeschaut habe, ob es dafür Linux-Unterstützung gibt und was
ist? Genau diese Version eben nicht, weil sie in der Charge irgendein
Bauteil ausgetauscht haben (wahrscheinlich weil's billiger war ;-).
und lediglich an den Namen hinten noch einen Buchstaben in Obscura
Light 0.1pt angehangen haben.

Ich kaufe eigentlich ausschliesslich nach Preis. Unter Unix werd ichs wohl
irgendwie hinkriegen ;-)

Was, immer noch?

Jo ;-)

naja, würde ich wahrscheinlich auch selber fest verdrahten, je nach
Anwendungszweck.

Ich auch ;-) Aber sowas braucht man nicht in einem Nicht-SCSI-System.

Ja, das liegt aber an der inneren Architektur, weniger an den 2(?)
zusätzlichen Opcodes,

Ok, das stimmt.

PS: irgendwann werden wir wohl kräftig einen auf den Sack bekommen,
weil nun wirklich _völlig_ OT ;-)

Ach iwo. Das glaub ich nicht ;-)

Gruesse,
 CK

[Bio]

Sup!

Ich denke, die Kernel-Updates von SuSE reichen erstmal aus.
Man kann mit einem selbstgebastelten Kernel-Upgrade wenig verbessern, aber _alles_ kaputtmachen.
Never change a running system (es sei denn, es ist *wahnsinnig* wichtig und von absolut dringender, existenzieller Notwendigkeit).

Gruesse,

Bio

[Christian Kruse]

Hoi,

Man kann mit einem selbstgebastelten Kernel-Upgrade wenig
verbessern, aber _alles_ kaputtmachen.

Genau so kann man mit einem SuSE-Kernel-RPM-Update alles puttmachen.

Never change a running system (es sei denn, es ist *wahnsinnig*
wichtig und von absolut dringender, existenzieller Notwendigkeit).

Wieso? Man lernt nur durch lesen und ausprobieren.

Gruesse,
 CK

[Bio]

Sup!

Genau so kann man mit einem SuSE-Kernel-RPM-Update alles puttmachen.

Tja, das ist aber weniger wahrscheinlich. Ziemlich weniger.

Never change a running system (es sei denn, es ist *wahnsinnig*
wichtig und von absolut dringender, existenzieller Notwendigkeit).

Wieso? Man lernt nur durch lesen und ausprobieren.

Aber wenn man nicht mindestens noch ein laufendes System hat, dann lernt man vor allem, was es heisst, suizidgefaehrdet zu sein ;-)

Gruesse,

Bio

[-RB-]

Never change a running system (es sei denn, es ist *wahnsinnig*
wichtig und von absolut dringender, existenzieller Notwendigkeit).

Wieso? Man lernt nur durch lesen und ausprobieren.

hi
zitat:
"Wer etwas zerbricht um herauszufinden was sich darin befindet hat den weg der weisheit verlassen"
-rb-

[Christian Kruse]

Hoi,

http://learn.to/quote

"Wer etwas zerbricht um herauszufinden was sich darin befindet hat
den weg der weisheit verlassen"

Eigentlich 'Derjenige, der etwas zerbricht, um herauszufinden, was es
ist, hat den Pfad der Weisheit verlassen.' ((c) by Tolkien)

Ich sehe nur den Zusammenhang/Widerspruch nicht.

Gruesse,
 CK

[-RB-]

hallo

http://learn.to/quote

habe es mal zu den favorites hinzugefügt

Ich sehe nur den Zusammenhang/Widerspruch nicht.

Never change a running system  ->  lernen tut man nur durch lesen(kein wiederspruch) und ausprobieren(wiederspruch) wenn der grundsatz heist  'nicht einzugreifen' dann ist 'ich muss ja eingreifen um herauszufinden' der wieder spruch den ich mal einfachso in das selbe verhältnis gesetzt habe wie:

Eigentlich 'Derjenige, der etwas zerbricht, um herauszufinden, was es
ist, hat den Pfad der Weisheit verlassen.' ((c) by Tolkien)

und nunja, angesichts des trockenen forumthemenbereiches hatte ich mal gehofft das soetwas hier nicht gelesen wird, bzw das es nicht so intensiv gelesen wird das man sich an soetwas hätte erinnern können... deswegen wollte ich mir die mühe ersparen erst die genaue textstelle zu suchen...

nunja mission gescheitert...

-rb-

Gruesse,
CK

[Christian Kruse]

Hoi,

Ich sehe nur den Zusammenhang/Widerspruch nicht.

wenn der grundsatz heist  'nicht einzugreifen'

Tut er ja gar nicht. Er heisst 'nicht kaputtmachen'. Und wenn ich mir
eine Doku schnappe und lese, dann kann man ohne Probleme ohne etwas kaputt
zu machen etwas ausprobieren.

Ausprobieren heisst nicht immer 'rm -rf /' oder 'newfs /dev/hda1'

dann ist 'ich muss ja eingreifen um herauszufinden' der wieder
spruch den ich mal einfachso in das selbe verhältnis gesetzt habe wie:

s.o.

und nunja, angesichts des trockenen forumthemenbereiches hatte ich mal
gehofft das soetwas hier nicht gelesen wird, bzw das es nicht so
intensiv gelesen wird das man sich an soetwas hätte erinnern
können... deswegen wollte ich mir die mühe ersparen erst die genaue
textstelle zu suchen...

Ich glaube, du wuerdest dich wundern.

Gruesse,
 CK

[Ralf Rapude]

Hi,

Alles in allem habe ich vom einlegen der DVD bis zu diesem Posting etwa 1 Stunde gebraucht!
Ich hatte vorher immer gehört, von wegen so superschwierig zu installieren.. 1 Woche versucht... bis auf meine Infrarot-Maus hat Linux eigentlich fast alles ohne Probleme erkannt(jedenfalls auf den ersten Blick).

Suse 7.3 lauffähig zu kriegen ist in der Tat inzwischen kein Problem mehr
(meistens jedenfalls). Spaßig wirds allerdings beim Feintuning oder
im Netzwerk (Samba, Drucker,als DSL-Router usw.). Da geht dann die Fummelei
los, die einen unter Umständen eine Woche Arbeit kostet. Ich habe hier
ein Laptop, das Doubleboot mit Suse 7.3 und W2k läuft. Das ging relativ
schnell.
Aber die Soundkarte so zum laufen zu bringen, das X nicht bei jedem zweiten
Mal die Grätsche macht, bzw. JBuilder 5 auf dem Teil zu installieren, hat
mir den letzten Nerv geraubt und viele, viele Stunden Arbeit gekostet.

Jetzt gibt es bestimmt Leute, die das schneller hinbekommen hätten, aber die
Werbung von Suse finde ich doch ein Ideechen übertrieben.

Ist natürlich trotzdem prima, das das bei dir so schön durchgerutscht ist.
Aber wenn man sich ein bißchen in Linux reinfummeln will, denn hängt da imho
doch ein ziemlich fetter Rattenschwanz dran. Deshalb würde ich auch erstmal
mit etwas anderem beginnen, als gleich mal einen neuen Kernel zu kompilieren
und da rein zu schieben. Die Chance das das glatt über die Bühne geht, ist
meiner Ansicht nach nicht außerordentlich hoch und bringt dir wahrscheinlich
auch nicht wirklich irgendwelche nennenswerten Vorteile.

Wobei man natürlich in der Tat nur was lernt, wenn man sich auch an die
Sachen ran traut. Aber gleich am Kernel rumzumachen ist schon eher was
für fortgeschrittene, glaube ich.

Weiterhin viel Spaß wünscht
Ralf

[xwolf]

Hi,

unten wurde dir schon gut geholfen.
Nur eines wurde vergessen.
Offensichtlich hat deine (Heul)SuSe doch ein Fehler:  Deine "!"-Taste scheint
zu oft wiedergegeben zu werden :)

Bitte reparier das doch.

Ciao,
 Wolfgang

[Andreas]

Hallo allerseits!

Hätte ich ja nie gedacht was mein Thread für einen Rattenschwanz nach sich zeihen würde!
;-)

Scheint dass LINUX ein sehr beliebtes Thema ist!

Wo liegt nochmal der Forums-Rekord? Sind wohl noch knapp drunter, aber immerhin ;-)

Danke für Eure Hilfe!

Grüsse
  Andreas