Hallo Liste,
beim Versuch, KOffice f�r KDE 3 auf meinem LFS-System zu �ber- setzen bekomme ich einen "internal compiler error", ebenso bei kdenetwork. Da auf meinem System ein relativ alter egcs (2.91) l�uft, hab ich den GCC 3.0.3 konfiguriert und �bersetzt. Nun findet aber das configure-script zu KOffice trotz korrekt ge- setzter Pfade das qt nicht mehr, bzw. es meint, qt nicht zu finden. Ich vermute jetzt mal, dass die (noch mit dem egcs �bersetzte) Version von qt nicht mit dem GCC 3.0.3 gelinkt werden kann. Muss ich jetzt alles (qt,kdelibs,kdebase,kdemulti- media....) nochmal mit dem GCC 3.0.3 kompilieren oder kann ich das Problem m�glicherweise durch Einsatz eines etwas �lteren GCC (2.95??) beseitigen? Wenn ich das richtig gesehen habe, wird die libstdc++ mit dem GCC mitgeliefert, kommt die In- kompatiblit�t evtl. von daher?
Viele Gr��e,
Matthias
On Sat, 06 Apr 2002 02:30:01 +0000, Matthias Petermann wrote:
beim Versuch, KOffice für KDE 3 auf meinem LFS-System zu über-
LFS?
setzen bekomme ich einen "internal compiler error", ebenso bei
Sollte nicht passieren. Ist also ein Compiler-Bug.
kdenetwork. Da auf meinem System ein relativ alter egcs (2.91) läuft, hab ich den GCC 3.0.3 konfiguriert und übersetzt. Nun findet aber das configure-script zu KOffice trotz korrekt ge- setzter Pfade das qt nicht mehr, bzw. es meint, qt nicht zu finden. Ich vermute jetzt mal, dass die (noch mit dem egcs übersetzte) Version von qt nicht mit dem GCC 3.0.3 gelinkt werden kann.
Von gcc2 nach gcc3 hat sich das C++-ABI verändert. Du musst dich also bei Programmen und Libs für einen Compiler der gleichen Generation entschieden. Jemand (joseph?) sagte mir kürzlich, daß es von 3.0 nach 3.1 nochmal ändern wird. Ich würde deshalb jetz nicht mit gcc-3.0 anfangen. 3.1 soll schon Mitte April kommen.
Am besten du baust dir mal einen frischen gcc-2.95.3 und nimmst den. Das geht halbwegs schnell, wenn man ihn nur für c und c++ baut.
Reinhard
Hallo Reinhard,
vielen Dank f�r Deinen Hinweis. Ich hab's jetzt mit dem GCC 2.95.4 von Heiko's Debian-Sourcen-CDs probiert; und siehe da - qt kann wieder gelinkt werden. LFS steht �brigens f�r "Linux From Scratch". Das ist ein Linux- System, das (abgesehen von ein paar Basis-Binarys) komplett aus den Sourcen "hochgezogen" wird. Es gibt dazu ein Projekt (www.linuxfromscratch.org) und ein Online-Buch. F�r mich war der Lerneffekt der wichtigste Beweggrund, mittlerweile w�rde ich aber keine andere Distri mehr haben wollen ;-)
Viele Gr��e && sch�nes Wochenende,
Matthias
On Sat, 06 Apr 2002 03:35:16 +0000, Matthias Petermann wrote: Hallo Matthias!
LFS steht übrigens für "Linux From Scratch". Das ist ein Linux-
Ahh, tnx.
System, das (abgesehen von ein paar Basis-Binarys) komplett aus den Sourcen "hochgezogen" wird. Es gibt dazu ein Projekt (www.linuxfromscratch.org) und ein Online-Buch. Für mich war der Lerneffekt der wichtigste Beweggrund, mittlerweile würde ich aber keine andere Distri mehr haben wollen ;-)
Find ich gut sowas. Ich habe auch mehrere Jahre alles selbst gebaut. Irgendwann überstieg dann der nötige Aufwand den damit verbundenen Lerneffekt und ich bin auf eine richtige Distribution umgestiegen.
BTW: Mittlerweile sind die Distributionen so komplex, daß man eher ein eigenes System hochgezogen hat bevor man die 1000 distributionsspezifischen Tools kapiert hat :-)
Reinhard
Hallo Reinhard,
On Sat, Apr 06, 2002 at 06:17:28PM +0200, Reinhard Foerster wrote:
Irgendwann ?berstieg dann der n?tige Aufwand den damit verbundenen Lerneffekt und ich bin auf eine richtige Distribution umgestiegen.
Dazu habe ich die Paketverwaltung von Slackware in das System "transplantiert". Es stehen mir jederzeit alle selbstgebauten LFS-Pakete auf Platte/CD-R zur Verf�gung, die mit minimalem Auf- wand auch auf einem nackiges System installiert werden k�nnen. Ein sch�ner (textorientierter :-) Installer dazu ist in Arbeit.
Mittlerweile sind die Distributionen so komplex, da? man eher ein eigenes System hochgezogen hat bevor man die 1000 distributionsspezifischen Tools kapiert hat :-)
Gut m�glich. Immerhin kann man sich (z.B.) in SuSE's YaST ganz sch�n verfangen, wenn man eine Einstellung sucht, die man sonst ganz elegant �ber die Kommandozeile administriert hat. Aber das haben scheinbar alle "meistverbreiteten" Distributionen so an sich.
Matthias
Am Samstag, dem 06. April 2002 um 03:35:16, schrieb Matthias Petermann:
Für mich war der Lerneffekt der wichtigste Beweggrund, mittlerweile würde ich aber keine andere Distri mehr haben wollen ;-)
Dein ursprüngliches Problem zeigt aber auch klar die Grenzen einer solchen 'Distribution'. Für ein Bastelsystem und zum Lernen ist das sicher okay aber für richtiges Arbeiten lieber dann doch eine 'ordentliche' Distribution.
Torsten
Hallo Torsten,
On Sun, Apr 07, 2002 at 11:48:12AM +0200, Torsten Werner wrote:
Dein urspr?ngliches Problem zeigt aber auch klar die Grenzen einer solchen 'Distribution'. F?r ein Bastelsystem und zum Lernen ist das sicher okay aber f?r richtiges Arbeiten lieber dann doch eine 'ordentliche' Distribution.
was verstehst Du dabei unter "richtigem Arbeiten"?
Matthias
Am Sonntag, dem 07. April 2002 um 13:09:24, schrieb Matthias Petermann:
was verstehst Du dabei unter "richtigem Arbeiten"?
Sein Geld verdienen, Rechner für x Mitarbeiter und xx Studenten einfach am laufen halten ohne Kinderkramfehler, die ich nicht habe, wenn ich mich auf eine gut gepflegte Binärdistribution (mit wohlbekannten Zusätzen) verlasse. Wenn ich ein Problem habe, weiss ich, dass es ein Bug-Tracking-System und Maintainer gibt. Auch baue ich mir fast nichts von den Quelltexten selber, wozu auch? Der allergrößte Teil der Debian-Binärpakete dürfte von Autobuildern gebaut werden und das scheint gut zu klappen - kein Grund, selber noch Hand anzulegen.
Torsten
Hi,
* Torsten Werner [04/07/02 15:02:36 CEST] wrote:
Auch baue ich mir fast nichts von den Quelltexten selber, wozu auch?
Es gibt eine Menge Optionen, die du ./configure mitgeben kannst. Von zusaetzlichen Patches fuer bestimmte Tools rede ich gar nicht erst.
Der allergrößte Teil der Debian-Binärpakete dürfte von Autobuildern gebaut werden und das scheint gut zu klappen - kein Grund, selber noch Hand anzulegen.
... wenn du mit den Optionen zufrieden bist, mit denen es gebaut wurde: ja. Ein klassisches Beispiel sind Mutt-Cocktails, wo - zumindest ich - mit keinen vorkompilierten Sachen zufrieden bin.
Weiterer Pluspunkt: zumindest ich habe weniger Probleme mit irgendwelchen Abhaengigkeiten, wenn ich mir den Source besorge und dann ein ./configure den Rest suchen lasse.
Cheers, Rocco.
Am Sonntag, dem 07. April 2002 um 21:16:20, schrieb Rocco Rutte:
ja. Ein klassisches Beispiel sind Mutt-Cocktails, wo - zumindest ich - mit keinen vorkompilierten Sachen zufrieden bin.
Was konkret fehlt dir? Wenn es wirklich kriegsentscheident ist, wird der mutt-Maintainer sich deinen Argumenten nicht verschließen.
Weiterer Pluspunkt: zumindest ich habe weniger Probleme mit irgendwelchen Abhaengigkeiten, wenn ich mir den Source besorge und dann ein ./configure den Rest suchen lasse.
Bitte, gerade du hast Probleme mit den Abhängigkeiten oder wie emulierst du die Build-Dependencies in Debian? Wenn es die Autobuilder schaffen, die Pakete richtig zu kompilieren, dann sehe ich keinen Weg, wie es denn noch 'richtiger' gehen kann.
Torsten
Hi,
* Torsten Werner [04/07/02 23:18:03 CEST] wrote:
Am Sonntag, dem 07. April 2002 um 21:16:20, schrieb Rocco Rutte:
ja. Ein klassisches Beispiel sind Mutt-Cocktails, wo - zumindest ich - mit keinen vorkompilierten Sachen zufrieden bin.
Was konkret fehlt dir? Wenn es wirklich kriegsentscheident ist, wird der mutt-Maintainer sich deinen Argumenten nicht verschließen.
Es ist nicht kriegsentscheidend. Das ist ja der Punkt. Spaetestens, wenn ich den Code selbst modifiziere und die Aenderungen so trivial sind, dass die Veroeffentlichung eines Patches nicht lohnt.
Ich baue Mutt mal mit POP und mal ohne, mal mit NFS-Fix und mal ohne, mal mit NNTP-Patch und mal ohne... Ich habe das nur als Beispiel ge- nommen, weil ich da recht sinnvolle Optionen fuer 'configure' habe, die die Bereitstellung eines extra-Paketes nicht wert sind.
Weiterer Pluspunkt: zumindest ich habe weniger Probleme mit irgendwelchen Abhaengigkeiten, wenn ich mir den Source besorge und dann ein ./configure den Rest suchen lasse.
Bitte, gerade du hast Probleme mit den Abhängigkeiten oder wie emulierst du die Build-Dependencies in Debian?
Ich stehe wohl gerade auf dem Schlauch. Ich verstehe die Frage wirklich nicht.
Wenn es die Autobuilder schaffen, die Pakete richtig zu kompilieren, dann sehe ich keinen Weg, wie es denn noch 'richtiger' gehen kann.
Es mag ja sein, dass die richtig gebaut werden. Manchmal, aber nicht immer, moechte ich configure aber andere Optionen mitgeben.
Cheers, Rocco.
Hallo Rocco,
On Sun, Apr 07, 2002 at 09:16:20PM +0200, Rocco Rutte wrote:
- Torsten Werner [04/07/02 15:02:36 CEST] wrote:
Auch baue ich mir fast nichts von den Quelltexten selber, wozu auch?
Es gibt eine Menge Optionen, die du ./configure mitgeben kannst. Von zusaetzlichen Patches fuer bestimmte Tools rede ich gar nicht erst.
Ein weiterer Grund k�nnten div. Optimierungen sein. Ein Neu- �bersetzen der Glibc brachte bei mir 15% Geschwindigkeits- steigerung beim Gesamtsystem, da die Originale wohl noch f�r 386'er gebaut werden.
Weiterer Pluspunkt: zumindest ich habe weniger Probleme mit irgendwelchen Abhaengigkeiten, wenn ich mir den Source besorge und dann ein ./configure den Rest suchen lasse.
Naja, das geht so lange gut, wie Du keine Pakete wieder entfernen willst. Und auch so gibt's da jede Menge Unordnung. Abh�nigkeiten kann man als Fluch oder Segen sehen - �berwiegen d�rfte dabei Ersteres. Ich bin froh, dass ich meinem Installer wenigstens schon beibringen konnte, beim L�schen eines zuvor gebauten Paketes die Dateien am Leben zu lassen, die evtl. auch in anderen Paketen ent- halten und f�r deren Funktion notwendig sind. Richtige Abh�ngig- keiten w�ren nat�rlich noch besser, aber dann ist es wohl sinn- voller, auf .deb oder .rpm umzustellen, wei� nicht ob sowas so leicht zu implementieren ist.
Matthias
Am Sonntag, dem 07. April 2002 um 22:03:37, schrieb Matthias Petermann:
Ein weiterer Grund könnten div. Optimierungen sein. Ein Neu- übersetzen der Glibc brachte bei mir 15% Geschwindigkeits- steigerung beim Gesamtsystem, da die Originale wohl noch für 386'er gebaut werden.
Woran hast du denn die 15 % gemessen? Bootdauer? Startzeit von irgendeinem Programm? Kernel kompilieren? Ich kann mir trotzdem nicht vorstellen, den Aufwand zu treiben, *alles* selber zu kompilieren, nur damit ein paar Sachen 15 % schneller laufen
Ich bin froh, dass ich meinem Installer wenigstens schon beibringen konnte, beim Löschen eines zuvor gebauten Paketes die Dateien am Leben zu lassen, die evtl. auch in anderen Paketen enthalten und für deren Funktion notwendig sind.
Diesselbe Datei in mehreren Paketen? Das wäre ein release critical bug in Debian und ein Grund die betreffenden Pakete gar nicht freizugeben...
Naja, jeder hat andere Vorstellungen von einem funktionstüchtigem System.
Torsten
Hallo Torsten!
On Sun, Apr 07, 2002 at 11:24:42PM +0200, Torsten Werner wrote:
Woran hast du denn die 15 % gemessen? Bootdauer? Startzeit von irgendeinem Programm? Kernel kompilieren? Ich kann mir trotzdem nicht vorstellen, den Aufwand zu treiben, *alles* selber zu kompilieren, nur damit ein paar Sachen 15 % schneller laufen
Mit der Bootdauer nat�rlich nicht. Aber mit Dingen, die naturgem�� viele Aufrufe an die glibc richtigen. Tats�chlich hab ich den Unterschied beim Kompilieren gemessen - reproduzierbar. Was vorher also 100 Sekunden gedauert hat, dauert jetzt nur noch 85. Das Allgemeinverhalten von grafischen Anwendungen hat sich zum Positiven ge�ndert; Men�s bauen sich fl�ssiger auf etc. Aber das mag mein rein subjektiver Eindruck sein.
Ich bin froh, dass ich meinem Installer wenigstens schon beibringen konnte, beim L?schen eines zuvor gebauten Paketes die Dateien am Leben zu lassen, die evtl. auch in anderen Paketen enthalten und f?r deren Funktion notwendig sind.
Diesselbe Datei in mehreren Paketen? Das w?re ein release critical bug in Debian und ein Grund die betreffenden Pakete gar nicht freizugeben...
Ok, das war von mir etwas ungl�cklich formuliert. Das Problem tritt haupts�chlich auf, wenn verschiedene Versionen von einem Paket auf das System aufgespielt werden. Dabei gibt es selbstverst�ndlich Dopplungen bei den Dateien. Allgemein ist mein Verfahren trotzdem kritisch, gebe ich ja zu.
Matthias
Hi,
* Matthias Petermann [04/08/02 00:03:37 CEST] wrote:
On Sun, Apr 07, 2002 at 09:16:20PM +0200, Rocco Rutte wrote:
Weiterer Pluspunkt: zumindest ich habe weniger Probleme mit irgendwelchen Abhaengigkeiten, wenn ich mir den Source besorge und dann ein ./configure den Rest suchen lasse.
Naja, das geht so lange gut, wie Du keine Pakete wieder entfernen willst.
Auch da gibt es verschiedene Methoden. Z.B. eine Installation nach /tmp und dann eine Dateiliste erstellen, o.ae. Macht aber viel mehr Arbeit, die es manchmal aber auch wert ist. Oder aber, sofern Sachen nicht fuer das ganze System zur Verfuegung stehen sollen, einfach irgendwo in ein extra Verzeichnis unter $HOME und mit rm -rf entfernen. Oder 'stow'. Oder oder oder ...
Richtige Abhängig- keiten wären natürlich noch besser, aber dann ist es wohl sinn- voller, auf .deb oder .rpm umzustellen, weiß nicht ob sowas so leicht zu implementieren ist.
Wenn es leicht zu implementieren waere, gaebe es das sicher schon. Die, die sich um Paket-Management-Tools kuemmern, sind sicher nicht auf den Kopf gefallen. Und solange diese Tools alle die 'Pruegel-Methode' unter- stuetzen, laesst sich da per Hand auch noch 'ne Menge machen (fuer Binaerpaket-Installationen).
Cheers, Rocco.
Hallo Torsten!
On Sun, Apr 07, 2002 at 03:02:36PM +0200, Torsten Werner wrote:
Sein Geld verdienen, Rechner f?r x Mitarbeiter und xx Studenten einfach am laufen halten ohne Kinderkramfehler, die ich nicht habe, wenn ich mich auf eine gut gepflegte Bin?rdistribution (mit wohlbekannten Zus?tzen) verlasse. Wenn ich ein Problem habe, weiss ich, dass es ein Bug-Tracking-System und Maintainer gibt. Auch baue ich mir fast nichts von den Quelltexten selber, wozu auch? Der allergr??te Teil der Debian-Bin?rpakete d?rfte von Autobuildern gebaut werden und das scheint gut zu klappen - kein Grund, selber noch Hand anzulegen.
...ich h�tte wissen sollen, dass ich mich mit einem Debian-Maintainer anlege ;-) Nein, ganz im Ernst. Nat�rlich hast Du Recht, dass f�r den produktiven Einsatz ein halbwegs geregelter "Support" von Seiten der Distributoren, Maintainer, etc. von Vorteil ist. Dieser wird haupt- s�chlich darin bestehen, dass man sich als Admin nicht mit jedem Paket bis ins letzte Detail auszukennen braucht, da sich das distri- butionseigene Paket-Management um die n�tigen �nderungen im System k�mmert - bei Updates oder Bugfixes zum Beispiel. Der Vorteil w�chst mit steigendem Umfang der Distribution. Allerdings sehe ich in einem ordentlich gepflegtem LFS nicht unbedingt einen Abbruch in der Pro- duktivit�t. Sobald ein stabiler Grundstock vorhanden ist (Kernel, GNU-Tools, Compiler), halten sich die Probleme in Grenzen; und "Kinder- kramfehler" wie mein urspr�ngliches GCC/libstdc++ -Problem passieren in der Regel nur einmal. Was mich pers�nlich an LFS so fasziniert: ich kann ganz gezielt ent- scheiden, was ich in meinem System haben will, und auf was ich lieber verzichte. Nat�rlich kann man das auch bei Debian via dselect/apt, aber dabei muss ich trotzdem die komplette Distribution (6CDs??) besitzen; auch wenn ich Spiele und irgendwelche Spezialanwendungen, die vielleicht 2% der User nutzen, nicht unbedingt zur Grundausstattung eines Betriebssystem z�hlen w�rde. Alles was ich brauche, passt derzeit auf etwas mehr als eine halbe CD-R, und ich bin nicht gerade anspruchs- los, was die Ausstattung meines Systems betrifft. BTW: Gibt es eigentlich von Debian eine Art Minimaldistribution? Irgend- wo habe ich schon einmal gelesen, dass auch Debian seine Pakete nach Priorit�ten sortiert und entsprechend denen auf verschiedene CDs verteilt. W�rde ich evtl. auch mit einer einzigen CD auskommen?
Matthias
Am Sonntag, dem 07. April 2002 um 21:46:49, schrieb Matthias Petermann:
BTW: Gibt es eigentlich von Debian eine Art Minimaldistribution?
knoppix? Aber so minimal ist die gar nicht.
Irgend- wo habe ich schon einmal gelesen, dass auch Debian seine Pakete nach Prioritäten sortiert und entsprechend denen auf verschiedene CDs verteilt. Würde ich evtl. auch mit einer einzigen CD auskommen?
Hmm, im Prinzip schon, wenn du eine Liste der Pakete lieferst, die auf der ersten CD drauf sein sollen.
BTW, deine komische Silbentrennung macht eine einfache Reformatierung deiner Mail unmöglich.
Torsten
On Sun, Apr 07, 2002 at 11:28:09PM +0200, Torsten Werner wrote:
BTW: Gibt es eigentlich von Debian eine Art Minimaldistribution?
knoppix? Aber so minimal ist die gar nicht.
So wie ich das mitbekommen habe, beschr�nkt sich die Minimalisierung bei Knoppix auf das Weglassen von selten benutzen Dokumentationen und Tools, die der typische KDE-User nicht zu brauchen hat. Trotzdem findet sich dort allerhand Spielkram, der, wie ich finde, in einem Betriebssystem fehl am Platz ist.
Hmm, im Prinzip schon, wenn du eine Liste der Pakete lieferst, die auf der ersten CD drauf sein sollen.
Wie flexibel ist der Debian-Installer in dieser Hinsicht? Wie ich in der Liste verfolgen konnte, gibt es auch bei Debian eine Art base.tgz, wo erst einmal ein Grundsystem auf der Maschine zum Leben erweckt wird. Ist in diesem Grundsystem bereits dpkg/dselect/apt enthalten, und - braucht dann nur noch ein Pfad / eine CD mit den Debian-Paketen bereitgestellt werden, um eine funktionierende und halbwegs vorkonfigurierte Umgebung zu erhalten?
BTW, deine komische Silbentrennung macht eine einfache Reformatierung deiner Mail unm?glich.
Schlechte Angewohnheit von mir. Ich gelobe Besserung :-)
Viele Gr��e,
Matthias
Oh je, was für ein Thread... Ich antworte mal in kompakter Form:
Am Montag, dem 08. April 2002 um 00:25:19, schrieb Rocco Rutte:
Es mag ja sein, dass die richtig gebaut werden. Manchmal, aber nicht immer, moechte ich configure aber andere Optionen mitgeben.
Es ging mir nur darum, dass ich es nicht für sinnvoll halte, alles selber zu bauen. Ich habe hier über 1000 Pakete installiert, alles zu bauen wäre anstrengend und fehlerträchtig. Es spricht aber natürlich nichts dagegen, sich die 10 Lieblingspakete selbst zu bauen.
Am Montag, dem 08. April 2002 um 00:40:23, schrieb Matthias Petermann:
Was vorher also 100 Sekunden gedauert hat, dauert jetzt nur noch 85.
Wenn man das meiste als Binärpaket installiert, ist der 15%-Gewinn beim kompilieren nicht so wichtig, oder?
Das Problem tritt hauptsächlich auf, wenn verschiedene Versionen von einem Paket auf das System aufgespielt werden. Dabei gibt es selbstverständlich Dopplungen bei den Dateien.
Mehrere Versionen desselben Paketes ohne in verschiedene Verzeichnisse zu installieren? Aua! Naja, rpm macht wohl solchen Quatsch auch mit. :)
Am Sonntag, dem 07. April 2002 um 23:30:54, schrieb Rocco Rutte:
Auch da gibt es verschiedene Methoden. Z.B. eine Installation nach /tmp und dann eine Dateiliste erstellen, o.ae.
So ähnlich arbeite ich auch *manchmal*: nach /tmp installieren, mit tar zusammenpacken und mit alien nach *.deb konvertieren. Das vereint die Vorteile der 'Quick und Dirty' Lösung mit einem funktionierenden Paketmanager.
Am Montag, dem 08. April 2002 um 00:52:15, schrieb Matthias Petermann:
Wie flexibel ist der Debian-Installer in dieser Hinsicht?
Man kann beim Erstellen der CDROMs angeben, welche Pakete nach Möglichkeit auf der ersten CD landen sollen.
Wie ich in der Liste verfolgen konnte, gibt es auch bei Debian eine Art base.tgz, wo erst einmal ein Grundsystem auf der Maschine zum Leben erweckt wird. Ist in diesem Grundsystem bereits dpkg/dselect/apt enthalten, und - braucht dann nur noch ein Pfad / eine CD mit den Debian-Paketen bereitgestellt werden, um eine funktionierende und halbwegs vorkonfigurierte Umgebung zu erhalten?
Ja das Grundsystem ist in dieser Hinsicht vollständig. Essentielle Pakete wie libc6, apt und dpkg lassen sich auch gar nicht gewaltfrei entfernen.
Torsten
Hallo Torsten,
On Mon, Apr 08, 2002 at 09:16:36AM +0200, Torsten Werner wrote:
Wenn man das meiste als Bin?rpaket installiert, ist der 15%-Gewinn beim kompilieren nicht so wichtig, oder?
Naja, aber wenn dann in der produktiven Phase ein Programm zum Audio- postprocessing 85 minuten anstelle von 100 ben�tigt, dann ist das doch schon ein Vorteil (die Werte sind jetzt gesch�tzt). Ich fahre eine ganze Menge solcher Anwendungen, u.a. auch um Videofilme zu komprimieren, da macht sich der Unterschied wirklich bemerkbar. Die glibc ist nun mal der "Dreh- und Angelpunkt" des Systems.
Man kann beim Erstellen der CDROMs angeben, welche Pakete nach M?glichkeit auf der ersten CD landen sollen.
_Wo_ kann ich das angeben? Gibt es einen automatischen ISO-Builder, dem ich meine W�nsche verklickern kann?
Ja das Grundsystem ist in dieser Hinsicht vollst?ndig. Essentielle Pakete wie libc6, apt und dpkg lassen sich auch gar nicht gewaltfrei entfernen.
Dann ist das f�r mich schon eine �berlegung wert. Ich habe heute allerdings schon mit jemand gesprochen, der mit den Abh�ngigkeiten der Debian-Pakete ab und zu mal �rger hatte, als er versuchte, die Anzahl der Pakete auf das n�tige zu beschr�nken. Wenn es o.g. ISO- Builder geben sollte - ist das auch in der Lage, die Abh�ngigkeiten so zu regeln, dass die Pakete auf einer Single-CD-Distri von keinen weiteren - auf zus�tzlichen Datentr�gern bereitzustellenden - Paketen abh�ngen?
Matthias
Tag,
On Tuesday, 9. April 2002 00:21, Matthias Petermann wrote:
Dann ist das für mich schon eine Überlegung wert. Ich habe heute allerdings schon mit jemand gesprochen, der mit den Abhängigkeiten der Debian-Pakete ab und zu mal Ärger hatte, als er versuchte, die Anzahl der Pakete auf das nötige zu beschränken. Wenn es o.g. ISO- Builder geben sollte - ist das auch in der Lage, die Abhängigkeiten so zu regeln, dass die Pakete auf einer Single-CD-Distri von keinen weiteren - auf zusätzlichen Datenträgern bereitzustellenden - Paketen abhängen?
Sicher. Wozu sollte auch z.B. eine Bash von KDE abhängen (auch wenn term ohne xterm(-Derivat) keinen Spaß macht).
Ich habe mir z.B. soeben ein woody nach /chroot installiert, das ist etwa 80 MB groß, und schon ziemlich "bloated", weil z.B. telnet oder at oder ppp* oder pcmcia oder iptables nicht von jedem gebraucht werden.
Die Frage ist immer, was "nötig" ist, und wer dann die Pakete auf die einzelnen CD's verteilt. Technisch gesehen ist das auf alle Fälle machbar, wenn er ein Minimalist ist kann er sich ja die Paketliste von Hand zusammenstellen und anhand dessen dann die CD bauen :)
Josef Spillner
On 08.04.02 Josef Spillner (dr_maux@users.sourceforge.net) wrote:
Moin,
Ich habe mir z.B. soeben ein woody nach /chroot installiert, das ist etwa 80 MB groß, und schon ziemlich "bloated", weil z.B. telnet oder at oder ppp* oder pcmcia oder iptables nicht von jedem gebraucht werden.
Bei potato wurde man immer darauf hingewiesen, daß man nicht auf einem Laptop sitzt und wurde also gefragt, ob man pcmcia entfernen möchte. telnet, at können bei mir schmerzfrei entfernt werden, bei ppp beschwert sich nur pppconfig und wvdial, und iptables habe ich gar nicht. Ist das bei woody anders? Das base.tgz bei potato sind IIRC 15 MB. Das ist IMHO für heutige Verhältnisse nicht bloated. Danach wird man in dselect geschickt, aber man muß ja die vorgeschlagenen Pakete nicht installieren.
H.
Tag,
On Tuesday, 9. April 2002 21:39, Hilmar Preusse wrote:
Bei potato wurde man immer darauf hingewiesen, daß man nicht auf einem Laptop sitzt und wurde also gefragt, ob man pcmcia entfernen möchte. telnet, at können bei mir schmerzfrei entfernt werden, bei ppp beschwert sich nur pppconfig und wvdial, und iptables habe ich gar nicht. Ist das bei woody anders?
Probier mal den Einzeiler hier: for i in slink potato woody; do echo -n $i:; /usr/sbin/debootstrap --print-debs $i | wc -w; done
Da kommt bei mir raus: slink: 69 potato: 81 woody: 101
(Und Shell-Freunde können mir jetzt sagen, wie ich dort eine ordentliche Spaltenformatierung hinbekomme...)
Das liegt daran, daß vermutlich immer mehr Pakete als "required" angegeben werden. Diese kann man aber unter /usr/lib/debootstrap/scripts/* editieren.
Ich meinte ja nur, daß das hier die Obergrenze eines Minimalsystems darstellt. Natürlich ist das wieder nur halb wahr, denn auf so einem System hab ich ähnlich viel Spielraum wie auf meinem Zweitsystem, welches seit gestern ein /gnu/boot/hurd ist. Aber wenn man z.B. ein chroot nur benötigt, um Debian-Pakete für veraltete-in-spe Distributionen wie woody herzustellen, kommt man selbst mit den ganzen Build-Tools und SGML und Python und ... noch unter 300 MB hin. (Bei mir sind's mehr, weil ich texi2html nicht kannte (dennoch einen Bug gefunden und gefixt habe), und ein 89 MB großes Dependency-Monster namens tetex-bin installiert hab.)
Und dselect ist ja bekanntermaßen in Rente gegangen, einige nutzen aptitude als Nachfolger. Ich warte darauf, daß apt-i18n endlich apt ersetzt :)
Josef Spillner
On 18.04.02 Josef Spillner (dr_maux@users.sourceforge.net) wrote:
Moin,
Probier mal den Einzeiler hier: for i in slink potato woody; do echo -n $i:; /usr/sbin/debootstrap --print-debs $i | wc -w; done
Da kommt bei mir raus: slink: 69 potato: 81 woody: 101
drachi:[hille] >for i in slink potato woody; do echo -n $i:; /usr/sbin/debootstrap --print-debs $i | wc -w; done slink:bash: /usr/sbin/debootstrap: No such file or directory bash: --print-debs: command not found 0 potato:bash: /usr/sbin/debootstrap: No such file or directory bash: --print-debs: command not found 0 woody:bash: /usr/sbin/debootstrap: No such file or directory bash: --print-debs: command not found 0
Hmmm. Was will mir das sagen? Ist das die Anzahl der Pakete die essential sind oder deren Platzbedarf? Im letzteren Fall kann sich ja Debian langsam an W$95 messen, was wohl auch mind. 100MB fraß.
Das liegt daran, daß vermutlich immer mehr Pakete als "required" angegeben werden. Diese kann man aber unter /usr/lib/debootstrap/scripts/* editieren.
drachi:[hille] >ll -d /usr/lib/deb* drwxr-xr-x 3 root root 4096 Jun 14 2001 /usr/lib/debian-test/ drwxr-xr-x 4 root root 4096 Oct 22 2000 /usr/lib/debiandoc-sgml/
Ich meinte ja nur, daß das hier die Obergrenze eines Minimalsystems darstellt. Natürlich ist das wieder nur halb wahr, denn auf so einem System hab ich ähnlich viel Spielraum wie auf meinem Zweitsystem, welches seit gestern ein /gnu/boot/hurd ist.
drachi:[hille] >/sbin/fdisk -l|grep BSD /dev/hda1 1 51 409626 a5 BSD/386 /dev/hda16 710 784 602406 a5 BSD/386
Dumm nur, daß die hda16 von Linux-fdisk angelegt wurde und von BSD gar nicht genutzt werden kann. Werde ich die also wohl doch wieder zur primären Partition erklären müssen und hoffen, daß der Teufel dann damit umgehen kann.
Aber wenn man z.B. ein chroot nur benötigt, um Debian-Pakete für veraltete-in-spe Distributionen wie woody herzustellen, kommt man selbst mit den ganzen Build-Tools und SGML und Python und ... noch unter 300 MB hin.
Na bitte. Mach mir das mal unter SuSE vor.
Ich warte darauf, daß apt-i18n endlich apt ersetzt :)
Warum?
H.
On Mon, 08 Apr 2002 22:21:32 +0000, Matthias Petermann wrote:
Naja, aber wenn dann in der produktiven Phase ein Programm zum Audio- postprocessing 85 minuten anstelle von 100 benötigt, dann ist das doch schon ein Vorteil (die Werte sind jetzt geschätzt). Ich fahre eine ganze Menge solcher Anwendungen, u.a. auch um Videofilme zu komprimieren, da macht sich der Unterschied wirklich bemerkbar. Die glibc ist nun mal der "Dreh- und Angelpunkt" des Systems.
Die libc ist wichtig. Bei den von dir genannten Anwendungen spielt sie allerdings keine Rolle. Ein Kompressionsprogramm wird 99,x% der CPU-Zeit im Kompressionsalgorithmus verbringen. Eine schnellere libc bringt da nix. Eine kleinere würde eventuell etwas bringen (wegen caches) Es würde also reichen, nur das Kompressionsprogramm besser zu optimieren.
Außerdem: Optimierung und Nutzung von fertigen Paketen widersprechen sich nicht. Nimm doch die source-rpms oder source-debs und schreib dort deine Compilerflags mit rein. Dann hast du trotz deiner Optimierung alle Vorteile des Pakets.
Reinhard
Man kann beim Erstellen der CDROMs angeben, welche Pakete nach M?glichkeit auf der ersten CD landen sollen.
_Wo_ kann ich das angeben? Gibt es einen automatischen ISO-Builder, dem ich meine Wünsche verklickern kann?
Ja das Grundsystem ist in dieser Hinsicht vollst?ndig. Essentielle Pakete wie libc6, apt und dpkg lassen sich auch gar nicht gewaltfrei entfernen.
Dann ist das für mich schon eine Überlegung wert. Ich habe heute allerdings schon mit jemand gesprochen, der mit den Abhängigkeiten der Debian-Pakete ab und zu mal Ärger hatte, als er versuchte, die Anzahl der Pakete auf das nötige zu beschränken. Wenn es o.g. ISO- Builder geben sollte - ist das auch in der Lage, die Abhängigkeiten so zu regeln, dass die Pakete auf einer Single-CD-Distri von keinen weiteren - auf zusätzlichen Datenträgern bereitzustellenden - Paketen abhängen?
Matthias
-- "You can't shoot down the moon... ...some things never change" (EJ/BT'85)
Lug-dd maillist - Lug-dd@schlittermann.de http://mailman.schlittermann.de/mailman/listinfo/lug-dd
Hallo Reinhard,
On Tue, Apr 09, 2002 at 06:28:24PM +0200, Reinhard Foerster wrote:
Die libc ist wichtig. Bei den von dir genannten Anwendungen spielt sie allerdings keine Rolle. Ein Kompressionsprogramm wird 99,x% der CPU-Zeit im Kompressionsalgorithmus verbringen. Eine schnellere libc bringt da nix. Eine kleinere w?rde eventuell etwas bringen (wegen caches) Es w?rde also reichen, nur das Kompressionsprogramm besser zu optimieren.
Aber ein Kompressionsprogramm - wenn es nicht gerade in Assembler geschrieben wurde - macht doch trotzdem dauernd Gebrauch von Bibliotheksfunktionen, oder? Ich hab mir die Sourcen z.B. von der mpeglib noch nicht angeschaut und w�rde da sicher auch erst mal gar nichts damit anzufangen wissen. Bringen solche Programme auch immer gleich ihre eigenen Math.-Libs mit?
Au?erdem: Optimierung und Nutzung von fertigen Paketen widersprechen sich nicht. Nimm doch die source-rpms oder source-debs und schreib dort deine Compilerflags mit rein. Dann hast du trotz deiner Optimierung alle Vorteile des Pakets.
Ich �berlege schon eine Weile, vielleicht Debian seine 4. Chance zu geben. Erfahrungen damit habe ich schon etwas, seit Hamm habe ich jede "offizielle" Version ausprobiert und auch eine Weile verwendet. Seit Potato �rgert mich der Umfang (9 CDs!) und daher mein Wechsel zu Slackware, dass als Basis f�r mein jetziges LFS diente. �berlebt hat allerdings nicht mal /etc/rc.d - das ist jetzt alles neu geschrieben. Das hat nichts mit Minimalismus zu tun, aber f�r mich ist eines der Hauptkriterien der Umfang. Ich habe zu Hause kein schnelles Netz, aus dem ich mir mal schnell mal ein paar Pakete runtersaugen kann, und auch keinen DVD-Rekorder, mit dem ich mir die Jongliererei mit 10 CDs ersparen k�nnte. Eine oder maximal zwei CDs w�ren optimal. Ich schau mir mal den Autobuilder genauer an, den mir Torsten empfohlen hat. Vom Ansatz her w�rde ich auf jeden Fall ein paketorientiertes System wie Debian vorziehen!
Viele Gr��e,
Matthias
On Tue, Apr 09, 2002 at 07:29:24PM +0000, Matthias Petermann wrote:
Aber ein Kompressionsprogramm - wenn es nicht gerade in Assembler geschrieben wurde - macht doch trotzdem dauernd Gebrauch von Bibliotheksfunktionen, oder?
Nein. Im inneren Loop (also da, wo die eigentlich Arbeit getan wird), werden sicher kaum libc Aufrufe vorkommen. Alles nur Mathe...
Ich hab mir die Sourcen z.B. von der mpeglib noch nicht angeschaut und würde da sicher auch erst mal gar nichts damit anzufangen wissen. Bringen solche Programme auch immer gleich ihre eigenen Math.-Libs mit?
Jein. Entweder nutzen sie für einschlägige Berechnungen (z.B. Fourier- oder Cosinustransformationen) ferige Bibiliotheken oder sie implementieren das selber. Wenn die Programme hochoptimiert sind, dann eher letzteres.
Gruß, Eric
Hi,
* Torsten Werner [04/08/02 09:16:36 CEST] wrote:
Es spricht aber natürlich nichts dagegen, sich die 10 Lieblingspakete selbst zu bauen.
Unter Linux baue ich auch nur eine handvoll. Ich moechte ja schliesslich noch mit dem Rechner arbeiten. ;-)
Gibt es eigentlich eine Art Tuning-Howto fuer Debian? Irgendwas stimmt hier nicht; der schlaeft bald ein.
Cheers, Rocco.
Am Montag, dem 08. April 2002 um 22:21:32, schrieb Matthias Petermann:
Naja, aber wenn dann in der produktiven Phase ein Programm zum Audio- postprocessing 85 minuten anstelle von 100 benötigt, dann ist das doch schon ein Vorteil (die Werte sind jetzt geschätzt).
Bei solchen Sachen ist es auch schon wieder egal, ob es nachts oder am Wochenende 15 Minuten länger dauert. Ich gucke dann sowieso nicht zu. Was anderes wäre es bei Realtime-Videokompression, hier ist selberbauen (inklusive MMX-Kram) sicher nicht falsch.
Gibt es einen automatischen ISO-Builder, dem ich meine Wünsche verklickern kann?
http://packages.debian.org/testing/admin/debian-cd.html
Wenn es o.g. ISO- Builder geben sollte - ist das auch in der Lage, die Abhängigkeiten so zu regeln, dass die Pakete auf einer Single-CD-Distri von keinen weiteren - auf zusätzlichen Datenträgern bereitzustellenden - Paketen abhängen?
Das habe ich noch nicht ausprobiert.
Am Montag, dem 08. April 2002 um 23:28:21, schrieb Josef Spillner:
Ich habe mir z.B. soeben ein woody nach /chroot installiert, das ist etwa 80 MB groß, und schon ziemlich "bloated", weil z.B. telnet oder at oder ppp* oder pcmcia oder iptables nicht von jedem gebraucht werden.
ppp und pcmcia werden zur Installation übers Netz gebraucht, sind also durchaus sinnvoll. 80 MB ist aber wirklich dick, ist da build-essential schon dabei?
Am Dienstag, dem 09. April 2002 um 01:44:10, schrieb Rocco Rutte:
Gibt es eigentlich eine Art Tuning-Howto fuer Debian? Irgendwas stimmt hier nicht; der schlaeft bald ein.
Wer schläft ein? Ein etwas exaktere Fehlerbeschreibung wäre schon nützlich.
Torsten
Hi,
* Torsten Werner [04/09/02 10:31:49 CEST] wrote:
Am Dienstag, dem 09. April 2002 um 01:44:10, schrieb Rocco Rutte:
Gibt es eigentlich eine Art Tuning-Howto fuer Debian? Irgendwas stimmt hier nicht; der schlaeft bald ein.
Wer schläft ein?
Niemand, zumindest nicht woertlich im Sinne von 'stehenbleiben' oder 'einfrieren'.
Ein etwas exaktere Fehlerbeschreibung wäre schon nützlich.
Es geht nichts schief. Es geht nur alles etwas sehr langsam, Mutt 1.5 bspw. braucht eine halbe Stunde zum Compilieren ;-( Ich suche nur eine Checkliste, die ein paar Punkte listet, wo ich suchen kann, um vielleicht noch etwas mehr (bzw. ueberhaupt) Leistung herauszuholen.
Cheers, Rocco.
On Tue Apr 09, 2002 at 16:11:39 +0200, Rocco Rutte wrote:
Es geht nichts schief. Es geht nur alles etwas sehr langsam, Mutt 1.5 bspw. braucht eine halbe Stunde zum Compilieren ;-( Ich suche nur eine
Was ist das fuer ein Rechner? Bei mir (700er CPU) baut das (ohne Patches) in 55 Sekunden...
Adam
Hi,
* Adam Lackorzynski [04/09/02 17:54:45 CEST] wrote:
On Tue Apr 09, 2002 at 16:11:39 +0200, Rocco Rutte wrote:
Es geht nichts schief. Es geht nur alles etwas sehr langsam, Mutt 1.5 bspw. braucht eine halbe Stunde zum Compilieren ;-( Ich suche nur eine
Was ist das fuer ein Rechner?
Intel Pentium 90, 48 MB EDO RAM. 2x ~520 MB Platte. Debian 3.0.
Bei mir (700er CPU) baut das (ohne Patches) in 55 Sekunden...
Auspacken, patchen, diff, compilieren, installieren: $bigbox (Duron 800) in 62 Sekunden, auf dem P90: ~32 Minuten.
Das die Unterschiede gross sein koennen, ist mir ja klar. Aber Faktor 30?
Cheers, Rocco.
On Tue Apr 09, 2002 at 18:24:53 +0200, Rocco Rutte wrote:
- Adam Lackorzynski [04/09/02 17:54:45 CEST] wrote:
Intel Pentium 90, 48 MB EDO RAM. 2x ~520 MB Platte. Debian 3.0.
Bei mir (700er CPU) baut das (ohne Patches) in 55 Sekunden...
Auspacken, patchen, diff, compilieren, installieren: $bigbox (Duron 800) in 62 Sekunden, auf dem P90: ~32 Minuten.
Reines Kompilieren auf P1 133, 64MB: 6:22 min, also IMHO sind 30min auch mit Auspacken, patch und configure zu viel...
Adam
Am Dienstag, dem 09. April 2002 um 21:42:31, schrieb Adam Lackorzynski:
On Tue Apr 09, 2002 at 18:24:53 +0200, Rocco Rutte wrote:
Intel Pentium 90, 48 MB EDO RAM. 2x ~520 MB Platte. Debian 3.0.
Auspacken, patchen, diff, compilieren, installieren: $bigbox (Duron 800) in 62 Sekunden, auf dem P90: ~32 Minuten.
Reines Kompilieren auf P1 133, 64MB: 6:22 min, also IMHO sind 30min auch mit Auspacken, patch und configure zu viel...
Wenn es schlechte Platten sind (und 520 MB klingt danach), dann ist es nicht mehr so ungewöhnlich. Mein altes P1 100 SCSI-System war auch lange den beliebten ~200 MHz IDE-Krücken überlegen.
Torsten
On Tue Apr 09, 2002 at 23:05:05 +0200, Torsten Werner wrote:
Am Dienstag, dem 09. April 2002 um 21:42:31, schrieb Adam Lackorzynski:
On Tue Apr 09, 2002 at 18:24:53 +0200, Rocco Rutte wrote:
Intel Pentium 90, 48 MB EDO RAM. 2x ~520 MB Platte. Debian 3.0.
Auspacken, patchen, diff, compilieren, installieren: $bigbox (Duron 800) in 62 Sekunden, auf dem P90: ~32 Minuten.
Reines Kompilieren auf P1 133, 64MB: 6:22 min, also IMHO sind 30min auch mit Auspacken, patch und configure zu viel...
Wenn es schlechte Platten sind (und 520 MB klingt danach), dann ist es nicht mehr so ungewöhnlich. Mein altes P1 100 SCSI-System war auch lange den beliebten ~200 MHz IDE-Krücken überlegen.
Hmm, ok, bei mir:
ide0: BM-DMA at 0xe800-0xe807, BIOS settings: hda:pio, hdb:pio hdb: ST52520A, ATA DISK drive hdb: 5009760 sectors (2565 MB) w/112KiB Cache, CHS=621/128/63, DMA
using_dma = 1 (on)
Adam
On Tue, Apr 09, 2002 at 06:24:53PM +0200, Rocco Rutte wrote:
- Adam Lackorzynski [04/09/02 17:54:45 CEST] wrote:
On Tue Apr 09, 2002 at 16:11:39 +0200, Rocco Rutte wrote:
Es geht nichts schief. Es geht nur alles etwas sehr langsam, Mutt 1.5 bspw. braucht eine halbe Stunde zum Compilieren ;-( Ich suche nur eine
Was ist das fuer ein Rechner?
Intel Pentium 90, 48 MB EDO RAM. 2x ~520 MB Platte. Debian 3.0.
Auspacken, patchen, diff, compilieren, installieren: $bigbox (Duron 800) in 62 Sekunden, auf dem P90: ~32 Minuten.
<INSBLAUEGERATEN> Speicher zu knapp oder Platten sehr langsam. </>
Gruß, Eric
Hi,
* Eric Schaefer [04/09/02 22:55:25 CEST] wrote:
On Tue, Apr 09, 2002 at 06:24:53PM +0200, Rocco Rutte wrote:
[ Mutt ...]
Auspacken, patchen, diff, compilieren, installieren: $bigbox (Duron 800) in 62 Sekunden, auf dem P90: ~32 Minuten.
<INSBLAUEGERATEN> Speicher zu knapp oder Platten sehr langsam. </>
s/oder/und wahrscheinlich/
Ram: 48 MB EDO, Platten: Quantum Maverick 540A, Maxtor 7540 AV.
Cheers, Rocco.
Am Dienstag, dem 09. April 2002 um 23:45:34, schrieb Rocco Rutte:
Ram: 48 MB EDO, Platten: Quantum Maverick 540A, Maxtor 7540 AV.
Tipp: die Platten jeweils mit h2bench testen (heise.de) und vorzugsweise die schnellere benutzen; bei gleich schnellen Platten Filesystem und swap auf verschiedenen Platten einrichten.
Torsten
Am Mittwoch, dem 10. April 2002 um 09:27:03, schrieb Torsten Werner:
Tipp:
Noch was: die schnellere Platte einzeln am Bus betreiben, die langsamere zusammen mit dem CDROM-Laufwerk als Sklave am anderen Bus; mit hdparm tunen; Speichereinstellungen im BIOS überprüfen.
Torsten
Hi,
* Torsten Werner [04/10/02 09:47:57 CEST] wrote:
Am Mittwoch, dem 10. April 2002 um 09:27:03, schrieb Torsten Werner:
Tipp:
Danke.
Noch was: die schnellere Platte einzeln am Bus betreiben, die langsamere zusammen mit dem CDROM-Laufwerk als Sklave am anderen Bus; mit hdparm tunen; Speichereinstellungen im BIOS überprüfen.
Naja, der zweite IDE-BUS arbeitet nur Montags bei Windstille nach 18.00 Uhr. Soll heissen: Nicht zuverlaessig genug, um daran eine Festplatte zu haengen.
Aber danke fuer die Tipps.
Cheers, Rocco.
Hallo Rocco,
On Tue, Apr 09, 2002 at 04:11:39PM +0200, Rocco Rutte wrote:
Es geht nichts schief. Es geht nur alles etwas sehr langsam, Mutt 1.5 bspw. braucht eine halbe Stunde zum Compilieren ;-( Ich suche nur eine Checkliste, die ein paar Punkte listet, wo ich suchen kann, um vielleicht noch etwas mehr (bzw. ueberhaupt) Leistung herauszuholen.
Obwohl es hier dazu sehr gespaltene Ansichten gibt, bin ich der Meinung, dass sich der Einsatz einer Pentium-optimierten glibc durchaus positiv auf das Gesamtverhalten des Systemes auswirken kann. Eine Checkliste ist mir leider nicht bekannt, aber vielleicht hat ja jemand anderes noch einen Hinweis dazu.
Viele Gr��e,
Matthias
Am 09. April 2002 schrieb Torsten Werner:
Am Montag, dem 08. April 2002 um 22:21:32, schrieb Matthias Petermann:
Naja, aber wenn dann in der produktiven Phase ein Programm zum Audio- postprocessing 85 minuten anstelle von 100 benötigt, dann ist das doch schon ein Vorteil (die Werte sind jetzt geschätzt).
Bei solchen Sachen ist es auch schon wieder egal, ob es nachts oder am Wochenende 15 Minuten länger dauert. Ich gucke dann sowieso nicht zu.
Es ging ja auch nicht darum, ob du "fingertrommelnd" auf das Ende des Prozesses wartest, sondern allgemein um eine Zeitersparnis, Da finde ich 15 von 100 min (15%) sehr gut.
Selbst wenn kein Geschwindigkeitszuwachs messbar wäre, würde mir mein subjektiver Eindruck, dass alles ein bischen schneller geht, schon reichen, diese Optimierung zu machen. Schließlich ist im täglichen Umgang mit dem Rechner die Arbeitsgeschwindigkeit immer subjektiv, außer man hat ein permanenten Benchmark laufen. (Kann man da überhaupt noch arbeiten? ;-) )
Ein subjektiv schnelles System habend, Erik
lug-dd@mailman.schlittermann.de
-
Adam Lackorzynski -
Eric Schaefer -
Erik Schanze -
Hilmar Preusse -
Josef Spillner -
Matthias Petermann -
Reinhard Foerster -
Rocco Rutte -
Torsten Werner