...das bei den verschiedenen Distributionen mit dem jeweiligen Updatemechanismus endlich Patches und nicht immer ganze gepatchte Pakete installiert werden können? Das wäre vor allen für Leute die keine Breitbandanbindung besitzen ein großer Zugewinn!
Schade nur das das nicht bei allen Distributionen so ist. Den allein das würde mich nicht im Leben dazu bringen SuSE zu nutzen. Ich bleibe bei Debian & Ubuntu.
Von Carsten Michels am Mi, 3. November 2004 um 22:41 #
Ich weiß nicht wie das genau heißt. Aber bei dem neuen Suse 9.2 ist bei dem Online Update jetzt die Möglichkeit das ganze mit der Option "Delta" zu machen. Das würde Traffic sparen, aber eine höhere CPU Last hervorufen.
Das heißt, dass nur die Differenzen (deltas) zwischen der alten und der neuen Version übertragen werden. Die muss Dein Rechner dann natürlich in die vorhandenen Dateien einbauen, was mehr CPU Zeit benötigt als die Dateien einfach zu ersetzen.
naja man kann eigentlich davon ausgehen das sich ein binary komplett aendert,wenn sich der quellcode aendert,da ja meistens nicht nur code von funktionen sondern auch deklarationen geaendert werden,was dann das ganze programm betrifft. ohne breitband is pc doch eh sinnlos
Ich hoffe doch mal stark, dass die Binaries deiner Distri mittels "strip" der meisten Definitionen beraubt wurden, damit das file kleiner wird. Außerdem reden wir hier ja von Sicherheitsupdates, und das wäre bei Debian Stable zB oft nur eine Einzeilenpatch.
Genau das meinte ich. Oft sind es nur einige wenige Zeilen, manchmal nur einige Zeichen (!) und trotzdem muß man z. T. ganze Pakete mit mehreren Megabyte runterladen. Zum Thema das Rechner (ich sage mal nicht PC) ohne Breitband sinnlos sind muß ich einfach mal sagen das wohl viele Breitband hätten so es verfügbar ist. Allerdings vergessen viele die bereichts einen Breitbandanschluß haben das es eben entgegen der Aussagen der Telekom flächenmäßig gesehen eben noch sehr viele weise Flecken in der DSL-Landkarte gibt. Von Kabelanschlüssen will ich gar nicht erst anfangen.
Wie sieht es mit der Bootzeit aus? Wären da nicht udev und hotplugging, könnte ein Standard-Linux innerhalb von 25-30 sek. booten (siehe Slack 10 ohne udev/hotplugging)
Da gibts/gabs doch mal einen kernelbasierende Ansatz der allerdings verworfen wurde, weil es eigentlich in den Userspace gehört...
Was dein Posting mit der Bootdauer mit der Meldung über Bibliotheks Preloading zu tun hat erschliest sich mir noch nicht ganz.
Wie lange ein Linuxsystem zum Booten braucht ist doch zweitrangig. Linux ist stabil genug, dass man den Rechner auch längere Zeit durchlaufen lassen kann. Und wen die Stromaufnahme über Nacht stört, der kann ja den Suspend Modus (Suspend-to-Disk? oder Suspend-to-RAM?) und PowerManagement verwenden. Sofern notwendig kannst du damit dein Linuxsystem innerhalb von Sekdundenbruchteilen wieder aus dem Schlaf aufwecken.
Wie lange ein Linuxsystem zum Booten braucht ist doch zweitrangig. Linux ist stabil genug, dass man den Rechner auch längere Zeit durchlaufen lassen kann.
Ja, für den Server schon - für den Desktop nicht unbedingt. Ich verwende GNU/Linux auch für den produktiven Einsatz auf meinem Desktop. Da ich meistens die Kiste gleich einschalte, sobald ich nach Hause komme und dann erstmal andere Dinge erledige, ist mir die Dauer des Bootvorgangs prinzipiell egal. Doch teilweise muss man einfach mal schnell an den PC, da wäre ein schnellerer Bootvorgang nicht schlecht. Für Laptops dürfte das auch interessant sein, die sind auch nicht nicht nonstop eingeschaltet.
> Da ich meistens die Kiste gleich einschalte, sobald ich nach Hause komme
Bekanntes Szenario. 5:00 aufstehen, Kiste an und Zähneputzen bis der Bootvorgang abgeschlossen ist...
> Für Laptops dürfte das auch interessant sein, die sind auch nicht nicht nonstop eingeschaltet.
Naja, dafür gibt es ja Suspend und Resume. Ich hab das Glück, dass mein 10 Jahre alter Laptop das in der Hardware beherrscht und ich deshalb nicht auf SWSusp setzen muss, worüber man ja nicht allzuviele Positivberichte liest.
Danke, daran hab ich noch garnicht gedacht. Mein Mainbord unterstüzt sogar Supend to Disk (Ist ausm Jahre 2000), ich muß nur gestehen, ich habs noch nie ausprobiert. Eigentlich müßte ich mich mal ran wagen.
> Was dein Posting mit der Bootdauer mit der Meldung über Bibliotheks Preloading
beim systemstart werden meiner Vermutung nach auch libs gestartet. ausserdem ist es ja eine art preloading/-fetching...
> der kann ja den Suspend Modus
wenn er denn sauber funktioniert, dann würd ich NIE mehr über die bootzeit von Linux meckern
> Sekdundenbruchteilen
auch nur s2ram, aber das funktioniert ja leider noch weniger zuverlässig mit vielen mainboards als s2disk. wen man die schuld zuweisen soll weiss ich nicht (kernel- oder bios-hacker), aber es sollte bald eine zuverlässige lösung existieren. mehr wünschen wir uns nicht.
Nein. Die Libs werden ganz normal erst beim Programmstart geladen. Du solltest mal die Beispiele lesen, da wird deutlich, was es ist: ein Mechanismus, um andere Libs zu überladen.
Man kann Libs auch in den Speicher vorladen. Eigentlich handelt es sich dabei nur um ein Lesen der Dateien, so dass sie sich im Cache befinden und später beim Programmstart nicht erst von der Festplatte geladen werden müssen. Fedora Core nennt das entsprechende Init-Skript readahead. Windows macht mit "Prefetch" nichts anderes.
Eine CRUX Installation auf meinem Rechner bootet in weniger als 10s. Das Preloading hat aber nichts mit der Bootzeit zu tun. Bei Slack, Crux und Co. liegt's primär am BSD-style init (SysV init ist extrem langsam im Vergleich zu BSD-style init). Es geht übrigens noch schneller mit depinit.
> Eine CRUX Installation auf meinem Rechner bootet in weniger als 10s
ab welchem zeitpunkt misst Du? ich mein jetzt den ersten festplattenzugriff bis zum (grafischen) login-screen. also wirklich optimiert (udev, hotplugging raus) und trotzdem mit benötigten netzwerk daemons (postfix, portmapper), usb-storage und dvb-treibern waren knapp über 30 sek. bei slack-10 das höchste der gefühle (2.4ghz, 160er samsung). dvb-treiber sollten vor X gestartet werden (wegen overlay), genauso usb wegen maus und so. könnt höchstens noch das netz nach xdm/gdm/kdm starten.
oder hast du ein raid0 mit 3-x gestripten platten? naja, aber dann würd der controller ne ewigkeit zum initialisieren benötigen...
udev ist hier in unter einer Sekunde gestartet. Diese verzögerung die du bemerkst liegt mit sicherheit nicht an udev, sondern an einem verfetteten und miesen init System.
sysvinit startet ne ganze menge shell scripte und alle nach einander. Da kannste dir ausrechnen wieviel Zeit hier allein für das starten verschwendet wird. Slackware verwendet meines wissens ein BSD Init system was weitaus weniger fett ist.
Ich selbst nutze minit (http://www.fefe.de/minit/) und habe trotz udev und aktiviertem hotplug ein System das schnell da ist.
Slackware verwendet ein BSD-like SysV-Init. ;-) Schau einfach in die /etc/inittab. Dort findest du die Runlevel 0 bis 6, wie bei jeder SysV-Init Distro.
Auch Slackware 10 verwendet den Hotplug-Daemon. Ich hab meine Soundkarte nicht in der /etc/modprobe.conf eingetragen, dennoch werden die Module geladen.
Preloading scheint mir unabhängig von den möglichen Vorteilen auch einige interessante Angriffsflächen zu bieten. Als simples Beispiel sei eine Software angedacht, welche in der guten Erwartung entwickelt wurde auf eine vertrauenswürdige Bibliothek, z.B. zum verschlüsseln von sensiblen Daten (OpenSSL) oder zur Authentifizierung (PAM), zuzugreifen. Würde sich nun eine andere Bibliothek zwischenschalten lassen, sollten die Möglichkeiten unbemerkt sensitive Informationen zu erlangen doch gewaltig wachsen können. Auch würde mich interessieren, ob die Bibliothek dann im selben Kontext ausgeführt wird wie das Programm, worst-case root, und man damit Schadfunktionen einschleusen könnte? Wie stets freue ich mich über jede Anregung zu der Thematik.
Grüße
Sturmkind
GFS
Grüße
Sturmkind
Grüße
Sturmkind
Da gibts/gabs doch mal einen kernelbasierende Ansatz der allerdings verworfen wurde, weil es eigentlich in den Userspace gehört...
Wie lange ein Linuxsystem zum Booten braucht ist doch zweitrangig. Linux ist stabil genug, dass man den Rechner auch längere Zeit durchlaufen lassen kann. Und wen die Stromaufnahme über Nacht stört, der kann ja den Suspend Modus (Suspend-to-Disk? oder Suspend-to-RAM?) und PowerManagement verwenden. Sofern notwendig kannst du damit dein Linuxsystem innerhalb von Sekdundenbruchteilen wieder aus dem Schlaf aufwecken.
Ja, für den Server schon - für den Desktop nicht unbedingt. Ich verwende GNU/Linux auch für den produktiven Einsatz auf meinem Desktop. Da ich meistens die Kiste gleich einschalte, sobald ich nach Hause komme und dann erstmal andere Dinge erledige, ist mir die Dauer des Bootvorgangs prinzipiell egal. Doch teilweise muss man einfach mal schnell an den PC, da wäre ein schnellerer Bootvorgang nicht schlecht. Für Laptops dürfte das auch interessant sein, die sind auch nicht nicht nonstop eingeschaltet.
Oli
Bekanntes Szenario. 5:00 aufstehen, Kiste an und Zähneputzen bis der Bootvorgang abgeschlossen ist...
> Für Laptops dürfte das auch interessant sein, die sind auch nicht nicht nonstop eingeschaltet.
Naja, dafür gibt es ja Suspend und Resume. Ich hab das Glück, dass mein 10 Jahre alter Laptop das in der Hardware beherrscht und ich deshalb nicht auf SWSusp setzen muss, worüber man ja nicht allzuviele Positivberichte liest.
Danke, daran hab ich noch garnicht gedacht. Mein Mainbord unterstüzt
sogar Supend to Disk (Ist ausm Jahre 2000), ich muß nur gestehen, ich
habs noch nie ausprobiert. Eigentlich müßte ich mich mal ran wagen.
Oli
beim systemstart werden meiner Vermutung nach auch libs gestartet. ausserdem ist es ja eine art preloading/-fetching...
> der kann ja den Suspend Modus
wenn er denn sauber funktioniert, dann würd ich NIE mehr über die bootzeit von Linux meckern
> Sekdundenbruchteilen
auch nur s2ram, aber das funktioniert ja leider noch weniger zuverlässig mit vielen mainboards als s2disk. wen man die schuld zuweisen soll weiss ich nicht (kernel- oder bios-hacker), aber es sollte bald eine zuverlässige lösung existieren. mehr wünschen wir uns nicht.
Nein. Die Libs werden ganz normal erst beim Programmstart geladen. Du solltest mal die Beispiele lesen, da wird deutlich, was es ist: ein Mechanismus, um andere Libs zu überladen.
Du verwechselst es vermutlich mit Prelinking.
Fedora Core nennt das entsprechende Init-Skript readahead. Windows macht mit "Prefetch" nichts anderes.
Danke.
bsd-like-init bei slack und co: sh-skripte, die einfach der Reihe nach abgearbeitet werden
ab welchem zeitpunkt misst Du? ich mein jetzt den ersten festplattenzugriff bis zum (grafischen) login-screen. also wirklich optimiert (udev, hotplugging raus) und trotzdem mit benötigten netzwerk daemons (postfix, portmapper), usb-storage und dvb-treibern waren knapp über 30 sek. bei slack-10 das höchste der gefühle (2.4ghz, 160er samsung). dvb-treiber sollten vor X gestartet werden (wegen overlay), genauso usb wegen maus und so. könnt höchstens noch das netz nach xdm/gdm/kdm starten.
oder hast du ein raid0 mit 3-x gestripten platten? naja, aber dann würd der controller ne ewigkeit zum initialisieren benötigen...
sysvinit startet ne ganze menge shell scripte und alle nach einander. Da kannste dir ausrechnen wieviel Zeit hier allein für das starten verschwendet wird. Slackware verwendet meines wissens ein BSD Init system was weitaus weniger fett ist.
Ich selbst nutze minit (http://www.fefe.de/minit/) und habe trotz udev und aktiviertem hotplug ein System das schnell da ist.
Schau einfach in die /etc/inittab. Dort findest du die Runlevel 0 bis 6, wie bei jeder SysV-Init Distro.
Ich hab meine Soundkarte nicht in der /etc/modprobe.conf eingetragen, dennoch werden die Module geladen.
Bitte löschen Sie /bin/laden.
*lach*
Als simples Beispiel sei eine Software angedacht, welche in der guten Erwartung entwickelt wurde auf eine vertrauenswürdige Bibliothek, z.B. zum verschlüsseln von sensiblen Daten (OpenSSL) oder zur Authentifizierung (PAM), zuzugreifen.
Würde sich nun eine andere Bibliothek zwischenschalten lassen, sollten die Möglichkeiten unbemerkt sensitive Informationen zu erlangen doch gewaltig wachsen können. Auch würde mich interessieren, ob die Bibliothek dann im selben Kontext ausgeführt wird wie das Programm, worst-case root, und man damit Schadfunktionen einschleusen könnte?
Wie stets freue ich mich über jede Anregung zu der Thematik.