Login
Newsletter
Werbung

Thema: Preloading mit Beispielen erklärt

29 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von Sturmkind am Mi, 3. November 2004 um 19:58 #
...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!

Grüße
Sturmkind

[
| Versenden | Drucken ]
  • 0
    Von kapeka am Mi, 3. November 2004 um 20:07 #
    Das ist bei Suse doch bereits der Fall, wenn ich mich nicht irre. Dort werden patch-rpms verwendet, die kleiner sind, als komplette Pakete.

    GFS

    [
    | Versenden | Drucken ]
    0
    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.
    [
    | Versenden | Drucken ]
    • 0
      Von KarlNapf am Do, 4. November 2004 um 08:01 #
      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.
      [
      | Versenden | Drucken ]
    0
    Von thomas001 am Mi, 3. November 2004 um 23:41 #
    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 ;)
    [
    | Versenden | Drucken ]
    • 0
      Von TRauMa am Do, 4. November 2004 um 13:40 #
      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.
      [
      | Versenden | Drucken ]
      • 0
        Von Sturmkind am Do, 4. November 2004 um 17:08 #
        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.

        Grüße
        Sturmkind

        [
        | Versenden | Drucken ]
0
Von anonymous am Mi, 3. November 2004 um 20:26 #
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...

[
| Versenden | Drucken ]
  • 0
    Von Anonymous am Mi, 3. November 2004 um 20:36 #
    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.

    [
    | Versenden | Drucken ]
    • 0
      Von Oliver am Mi, 3. November 2004 um 20:58 #
      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.

      Oli

      [
      | Versenden | Drucken ]
      • 0
        Von RvB am Mi, 3. November 2004 um 21:12 #
        > 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.

        [
        | Versenden | Drucken ]
        • 0
          Von Oliver am Mi, 3. November 2004 um 21:23 #
          > Naja, dafür gibt es ja Suspend und Resume

          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

          [
          | Versenden | Drucken ]
      0
      Von anonymous am Mi, 3. November 2004 um 23:03 #
      > 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.

      [
      | Versenden | Drucken ]
      • 0
        Von RvB am Do, 4. November 2004 um 05:26 #
        > ausserdem ist es ja eine art pre[..]fetching...

        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.

        [
        | Versenden | Drucken ]
        • 0
          Von fuffy am Do, 4. November 2004 um 08:17 #
          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.
          [
          | Versenden | Drucken ]
    0
    Von garbeam am Mi, 3. November 2004 um 20:41 #
    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.
    [
    | Versenden | Drucken ]
    • 0
      Von Johannes am Mi, 3. November 2004 um 22:20 #
      Könntest du bitte für mich kurz die Unterschiede von BSD-Style zu SysV-Style Init aufzeigen.
      Danke.
      [
      | Versenden | Drucken ]
      • 0
        Von troll am Mi, 3. November 2004 um 22:37 #
        sys-v-init; pro runlevel ein Verzeichnis mit symlinks
        bsd-like-init bei slack und co: sh-skripte, die einfach der Reihe nach abgearbeitet werden
        [
        | Versenden | Drucken ]
      0
      Von anonymous am Mi, 3. November 2004 um 23:09 #
      > 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...

      [
      | Versenden | Drucken ]
    0
    Von anonym am Do, 4. November 2004 um 00:36 #
    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.

    [
    | Versenden | Drucken ]
    • 0
      Von fuffy am Do, 4. November 2004 um 08:19 #
      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.
      [
      | Versenden | Drucken ]
    0
    Von fuffy am Do, 4. November 2004 um 08:15 #
    Auch Slackware 10 verwendet den Hotplug-Daemon.
    Ich hab meine Soundkarte nicht in der /etc/modprobe.conf eingetragen, dennoch werden die Module geladen. ;-)
    [
    | Versenden | Drucken ]
0
Von guufush am Mi, 3. November 2004 um 22:46 #
Terroristischer Angriff auf den Kernel.

Bitte löschen Sie /bin/laden.

[
| Versenden | Drucken ]
0
Von 2cent am So, 7. November 2004 um 22:08 #
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.
[
| Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung