Login
Newsletter
Werbung

Thema: Torvalds: Linux ist fett und aufgebläht

87 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von Albert am Di, 22. September 2009 um 14:05 #
Torvalds hat schon Recht. Man könnte doch den Kernel so bauen,daß zumindest gar keine Treiber drauf sind. Erst während der Installation von Distro X "sieht der Kernel" welche Treiber benötigt werden. Falls dann später noch etwas hinzukommt (Drucker z.b.) dann sieht die Distro : Ah, neue Hardware, also neuen Treiber auf Abfrage automatisch(aus einer Datenbank z.b.) installieren. Dann wäre der kernel um einiges schlanker.
Ob das aber möglich ist???
Albert
  • 0
    Von Pipe am Di, 22. September 2009 um 14:17 #
    Techn. ist das sicher möglich. Für Maschinen die kein Internet können auch aus dem Repo oder von CD.

    Das wird den Speed aber nicht erhöhen. Es ist ja nicht so, das die Treiber das Speedproblem erzeugen. Geladen sind ja nur die man auch braucht.

    Das Kernproblem sind sicher die vielen Funktionen. Hier wäre zu entscheiden welche den Speed tatsächlich beeinflußen und welche davon wirklich gebraucht werden. Sowas könnte man über eine Reporting-Funktion mit anschließendem Upload auf einen Zentral-Server machen. Danach könnte man entscheiden welche tatsächlich raus können.

    Grüße.

    • 0
      Von Albert am Di, 22. September 2009 um 14:24 #
      Stimmt. Man könnte ja den Kernel abzweigen. Einer mit "Vollfunktion", der andere "halbvoll" :)
      aber mich stört es bis jetzt gar nicht. Warum auch? Die Festplatten werden immer grösser, CPU immer schneller. Also kommt es gar nicht drauf an,ob kernel 50 MB oder 80 MB gross ist...
      Aber es gibt eben Leuter,die haben ältere Rechner und das macht sich schon bemerkbar...

      Alberrt

      • 0
        Von as am Di, 22. September 2009 um 14:35 #
        >Aber es gibt eben Leuter,die haben ältere Rechner und das macht sich schon bemerkbar...

        Oder Leute, die Rechenleistung JETZT brauchen, und nicht erst auf die nächste CPU Generation warten können.

        • 0
          Von gustl am Di, 22. September 2009 um 17:28 #
          Dazu mal eine Überlegung:

          Die Aufgabe des Kernels ist es im wesentlichen, die Hardware-Ressourcen unter verschiedenen Prozessen zu verteilen, und sich selbst möglichst wenig Rechenleistung zu genehmigen.

          Wenn man so auf das Kommando "top" schaut, dann sieht man, dass das System (also im wesentlichen der Kernel) 0.4% der Rechenleistung braucht (Quad-Core Intel 2.8 GHz). Auf einen Single-Core 500 MHz (10 Jahre alt) runtergebrochen würde das heißen, dass der Kernel dort 10% verbrauchen würde. Keine Ahnung, ob man das einfach so umrechnen kann, oder ob ein langsamerer Computer einfach weniger Operationen pro Sekunde BRAUCHT, weil ja auch weniger Task-switches, weniger Scheduler-Entscheidungen usw. berechnet werden müssen.

          Jedenfalls finde ich 2% von 0.4% ist wenig genug. Wenn man das Ding auf einem Telefon laufen lassen kann, dann sollte man das eigentlich als Zeichen nehmen, dass es gar nicht so schlecht ist wie es vielleicht aussieht.

          • 0
            Von energyman am Di, 22. September 2009 um 17:50 #
            nein, so kannst du das nicht vergleichen. Ein SMP System verlangt einfach viel mehr 'Kernelarbeit' als eine kleine Einzel-CPU mit wenig Ram.
          0
          Von Zupp am Fr, 25. September 2009 um 19:09 #
          Naja, aber man kann sich ja auch einen Kernel selber kompilieren. Auch wenn mittlerweile alle Distributoren per Default tausend Sachen im Kernel aktivieren, die jeweils nur von 0,0001% der User benötigt werden und der Rest als Modul kompiliert wird...es ist noch immer möglich "eigene" Kernel zusammenzustellen und es ist auch dank Arbeit von Seiten der Distributoren auch nicht wirklich aufwändig.

          Würde mich daher auch mal interessieren, *wie* der Kernel von Intel gebenchmarked wurde...

        0
        Von tempa am Di, 22. September 2009 um 15:27 #
        Wozu einen neuen Kernel, wenn die Hardware alt ist?
        Wenn der alte Kernel flotter ist, dann halt den alten behalten. Gibt genug Distis welche die alten Kernel weiter mit Sicherheitsaktualisierungen versorgen.
        0
        Von Eismeister am Di, 22. September 2009 um 22:01 #
        Man kann sich doch selber nen Kernel bauen. Das ist ganz einfach. Kernel Sourcen deiner distri installieren, stock .config kopieren, make oldconfig, make menuconfig, dann alles raus, was nicht in lsmod auftaucht, und nicht an dynamischen Schnittstellen (USB/Firewire/PCcard etc hängt). Und alles, was nicht rein gehört ist dann auch nicht drinne.
    0
    Von knopwob am Di, 22. September 2009 um 14:18 #
    Ist das nicht das Prinzip der Module? Man kann doch beim kompilieren des Kernels auswaehlen, welche Teile direkt in den Kernel integriert werden und welche als Module kompiliert werden, die dann spaeter dynamisch in den kernel geladen werden koennen.
    0
    Von Torsten am Di, 22. September 2009 um 14:18 #
    Dies ist schon heute der Regelfall: Durch Treiber die als Kernelmodule kompiliert und bei Bedarf nachgeladen werden. Selbst Treiber die für den Systemstart erforderlich sind, müssen nicht zwangsläufig integriert sein, da sie in die Inital Ramdisk integriert werden können, die der Bootloader an den Kernel übergibt. Falls erforderlich kann man auch selbst einen um nicht benötigte Funktionen bereinigten Kernel kompilieren.
    0
    Von JayJay am Di, 22. September 2009 um 14:20 #
    Ein weiterer Gedanke währe so einer Art Programm zu machen oder eine Routine bei der Installation einer Distro, oder einfach ne GUI die die gesamte hardware ermitteln kann, und dem entsprechend einen kernel baut. Eine zusätzliche abfrage des Einstatzgebiets des Rechners währe noch angebracht damit auch die nötigen Features hineinkompiliert werden können.

    Ob das dann auch umsetzbar ist müsste man die Kernelhacker fragen. Wie dem auch sei, solch eine Anpassung würde wahrscheinlich für mehr geschwindigkeit sorgen.

    Ein anderes Konzept, währe eine separate treiberinstallation alá Windows. Nur müsste das dann vom Hardwarehersteller übernohmen werden, wie das heute ist wissen ja alle Linux benutzer.

    • 0
      Von nick name am Di, 22. September 2009 um 14:36 #
      > Ein weiterer Gedanke währe so einer Art Programm zu machen oder eine Routine bei der Installation einer Distro, oder einfach ne GUI die die gesamte hardware ermitteln kann, und dem entsprechend einen kernel baut.

      Das wäre so und auch so wünschenswert. Mal abgesehen davon, das es kaum eine Disto mit Vanilla-Kernel gibt. (Oder irre ich da?)

      > Eine zusätzliche abfrage des Einstatzgebiets des Rechners währe noch angebracht damit auch die nötigen Features hineinkompiliert werden können.

      Und bei euen Geräten müss ich ihn da wieder selbst bauen und Zeit operfn? Im Falle eines HW-Tausch ist das schlecht.

      > Ein anderes Konzept, währe eine separate treiberinstallation alá Windows. Nur müsste das dann vom Hardwarehersteller übernohmen werden, wie das heute ist wissen ja alle Linux benutzer.

      Dann muss aber auch die ganze API für alle Module vorgehalten werden?.
      Anders: Wodurch genau entstehen die Performanzverluste?

      • 0
        Von JayJay am Di, 22. September 2009 um 14:55 #
        >Anders: Wodurch genau entstehen die Performanzverluste?<

        Ich würd ma behaupten durch verschiedene Routinen und Treiber von den manche nicht mal gebrauch werden, die jedoch im Hintergrund laufen. Wurde aber schon im dem eigentlichem Artickel gesagt.

        >Mal abgesehen davon, das es kaum eine Disto mit Vanilla-Kernel gibt. (Oder irre ich da?)<

        Wenn ich mich nicht irre, hat zumindest debian ne möglichkeit die Kernelsource als paket zu laden und dann kannst du damit anstellen was du willst. Es sei den, das was die da anbieten kein Vanila ist.

        • 0
          Von Seika am Di, 22. September 2009 um 15:07 #
          > Anders: Wodurch genau entstehen die Performanzverluste?
          >> Ich würd ma behaupten durch verschiedene Routinen und Treiber von den manche nicht mal gebrauch werden, die jedoch im Hintergrund laufen. Wurde aber schon im dem eigentlichem Artickel gesagt.
          Kann ich mir ehrlich gesagt überhaupt nicht vorstellen. Du kriegst keinen Treiber upstream der, obwohl nicht nötig, irgendeine Task oder so startet. Ich glaube nicht, dass die Treiber unmittelbar das Problem sind. Wenn ein Treiber ob einkompiliert oder als Modul gebaut nicht benötigt wird, weil die Hardware nicht vorhanden ist, wird der Treiber selbst nicht verwendet. Er wird entweder geladen oder nie wieder aufgerufen.

          Der Performanzverlust kann nur von zentralen Komponenten des Kernels herrühren (Scheduler, Slab-Allocator, ...).

          0
          Von Alan Smithee am Di, 22. September 2009 um 15:07 #
          > Wenn ich mich nicht irre, hat zumindest debian ne möglichkeit die Kernelsource als paket zu laden und dann kannst du damit anstellen was du willst. Es sei den, das was die da anbieten kein Vanila ist.

          vanilla = kein kernel patch
          das hat weniger mit den features zu tun die du aktivierst.

        0
        Von peter am Di, 22. September 2009 um 15:10 #
        > Das wäre so und auch so wünschenswert. Mal abgesehen davon, das es kaum eine Disto mit Vanilla-Kernel gibt. (Oder irre ich da?)

        Slackware

        0
        Von blub am Di, 22. September 2009 um 16:16 #
        Slackware verwendet Vanilla-Kernel.
        0
        Von xB am Di, 22. September 2009 um 17:08 #
        Benutzt fedora nicht den vanilla kernel?
    0
    Von FK am Di, 22. September 2009 um 14:56 #
    Die größe der sourcen ist doch nicht das problem, abs nun 10 oder 100mb sind - was solls. Auch die größe des physikalischen kernels ist relativ latte, btw. meine aktueller 2.6.31 ist keine 3MB groß... dazu noch 10 module oder so die bei selten verwendeter hardware nachgeladen werden.

    Das was die geschwindigkeit beeinflußt sind div abstraktionsschichten die bei vielen funktionen abgearbeitet werden, es geht die länge des codepfades der für eine funktion ausgeführt wird, nciht die größe des eigentlich kernels.

    Deswegen bringen deine vorschläge auch nicht viel, es würde sich mit dem angepassten kernel nichts an der anzahl der abzuarbeitenden befehle zum ausführen einer funktion ändern. Und weil das wirklich eine schwer zu knackende nuss ist, fällt dem guten linus auch erstmal nichts dazu ein.

    • 0
      Von FK am Di, 22. September 2009 um 14:58 #
      habs leider nciht quergelesen
      ...es geht um die länge des...
      0
      Von Perry3D am Di, 22. September 2009 um 15:19 #
      Der selben Ansicht bin ich auch.
      Allerdings würde mich wirklich interessieren, welche Tests da durchgeführt wurden. Phoronix bringt doch bei jedem Kernelrelease einen Vergleich. Und soweit ich mich erinnern kann, ist der aktuelle Kernel je nach Anwendungsgebiet schneller oder langsamer.
      • 0
        Von Frank am Di, 22. September 2009 um 15:38 #
        Phoronix ist zum Vergleichen schlecht geeignet. Entweder macht man einen ordentlichen Feldtest und liefert eine Definition der Umgebung mit, oder man führt ein sauberes Profiling durch. Bis jetzt hab ich von denen nur bunte Diagramme gesehen, deren Fazit hauptsächlich auf Daten aus time(1) beruhen. Das kann ich auch selber eintippen; ohne "Suite".
      0
      Von Philipp am Di, 22. September 2009 um 15:30 #
    0
    Von R. Duttine am Mi, 23. September 2009 um 10:49 #
    Eine ideale Idee, um den Linux - Kernel schlank u. schnell zu gestalten. !!!!!!!!!!!!!! Ich hoffe, die Idee wird aufgenommen .
    Man schleppt Tausend Funktionen u. Treiber mit, die man gar nicht braucht. Linux könnte auch schneller sein

    R. D.

0
Von as am Di, 22. September 2009 um 14:39 #
>Ja, das ist ein Problem! Eine Lösung hatte er in dieser Runde nicht anzubieten.

Tut mir leid, aber das ist dürftig. Es ist an der Zeit wieder Visionen zu entwickeln. Der Linux Kernel überlebt sich ansonsten selbst!

  • 0
    Von zyniker am Di, 22. September 2009 um 14:46 #
    Und? Hast schon eine Lösung parat? Eine Vision ist das Ziel, eine Lösung ist der Weg zum Ziel. Eine Vision kann man in Sekundenbruchteilen erdenken/haben, der Weg dorthin kann Jahre dauern oder gar völlig unmöglich sein.
    Vision: alle Menschen haben sich lieb, darum gibt es keinen Krieg mehr.
    Weg: ähhhhhhh
    • 0
      Von Michael am Di, 22. September 2009 um 16:09 #
      > Und? Hast schon eine Lösung parat?

      Ein Microkernel wäre eine Lösung. Treiber laufen dann im Userspace und man hat keine Probleme mehr.

      • 0
        Von blub am Di, 22. September 2009 um 16:19 #
        Milrokernel ist mehr, als mur Treiber im Userspace. Und der Kommunikationsoverhead zwischen den Kerneldiensten, die aus dem Mikrokernel ausgelagert sind, fuehrt sicher nicht zu einer besseren Performance.
        0
        Von spaetz am Di, 22. September 2009 um 16:20 #
        >> Und? Hast schon eine Lösung parat?

        > Ein Microkernel wäre eine Lösung. Treiber laufen dann im Userspace und man hat keine Probleme mehr.

        Und das löst das Problem der Abstraktionschichten und wachsender Codegrösse wie? Du hast halt einen Haufen User daemons laufen, statt eines Kernelprozesses, so what?

        0
        Von bob am Di, 22. September 2009 um 18:06 #
        Linux ist bereits wesentlich mehr `micro' als früher und wird mehr und mehr `micro' werden, so weit das zu einem beliebigen künftigen Zeitpunkt technisch sinnvoll ist. Der Hype um jene Kernelkonzepte die im akademischen Sinn als `echt micro' gelten ist bzw. war in erster Linie ... ein Hype.

        Dass Linux heute als Kernel (für GNU und andere) benutzt werden kann ist unter anderem dem Umstand zu verdanken, dass es früher nicht `micro' genug war um für Akademiker als schick durchzugehen. Zum Glück. MINIX war `echt micro' und MINIX war unbrauchbar für die `real world' (genauso wie HURD, nebenbei gesagt), der Entstehungsgrund für Linux. Um dessen `microness' würde ich mir nicht unbedingt große Sorgen machen - die ist absolut auf der Höhe der Zeit und wandelt sich weiter, mit der Zeit.

        Was die Geschwindigkeitseinbußen angeht, zeigt die Nachricht meiner Meinung nach vor allem eines, nämlich dass das Frühwarnsystem der Community erwartungsgemäß funktioniert. In der proprietären Welt gibt es diverse Software-Hersteller die Jahre lang hinter verschlossenen Türen an einer neuen Betriebsystemversion herumentwickeln um den Anwender pünktlich zum Release mit der ernüchternden Tatsache vertraut zu machen, dass die Performance im Vergleich zum Vorgänger unterirdisch ist :)

        • 0
          Von Neuer am Di, 22. September 2009 um 19:23 #
          Hallo,

          was Minix angehst, so tust Du dem ganzen Unrecht. Es sollte gar nicht wirklich gut einsetzbar sein, sondern vor allem leicht zu verändern. Der Prof. Tannenbaum hatte es zu speziell dem Zweck entwickelt und Patches mit Verbesserungen, die es aber komplexer machen, regelmäßig abgelehnt.

          Dass Linux ihm als zu fett gilt, liegt nicht an den vielen Treibern. Die sind ja nur Module und werden bei Bedarf nachgeladen, sonst nicht. Das klappt ganz gut. Was es fett macht, sind eher die 4 Arten von RAID, die sich darin verewigt haben, und jeweils andere APIs und anderen Code haben. Oder fnotify, inotify und wie auch immer die Vereinigung jetzt heisst. Oder /proc, /sys und debugfs, oder jetzt auch devfs2, etc.

          Es gibt Unmengen an Interfaces, die kaum mehr jemand braucht, die Last erzeugen, weil Implementierungen sie bedienen können müssen, und Code fressen. Ich hoffe dass Linus versuchen will, auf ein Linux 3.0 zu kommen, dass inkompatibel ist, und alles unnötige an Altlasten wegwirft.

          Gruss,
          Kay

          • 0
            Von Jo:rg Zweier am Di, 22. September 2009 um 21:58 #
            ++

            Dem kann ich mich nur anschließen. So langsam müssen die Kernelentwickler wirklich dazu übergehen, ihre APIs zu "standardisieren", sodass es auch die Anwendungsentwickler leichter haben und sich auf die wesentlichen Dinge konzentrieren können.

      0
      Von as am Mi, 23. September 2009 um 09:26 #
      >Hast schon eine Lösung parat?

      Komm hoer auf mit der Polemik. Wie viele Andere sehe ich die Symptome. Die tatsächlichen Ursachen kann und muss ich nicht analysieren, solange ich nicht an der Kernelentwicklung beteiligt bin. Eine Lösung kann ich deshalb ebenfalls nicht bieten, da ich die Ursachen nicht kenne.

      Bevor du dich jetzt beschwerst, dass ich dann halt mitmachen soll, also am Kernel ..... Auch ohne Teilhabe darf ich warnen! Ebenso wie viele Bürger bzgl. des Einsatzes der BW in Afghanistan kritisieren ohne vor Ort zu sein!

0
Von asdf am Di, 22. September 2009 um 14:41 #
Hab ich da auch die Performance-Probleme?
  • 0
    Von dark_star am Di, 22. September 2009 um 14:52 #
    So wie es aussieht schon, denn es geht ja weniger drum, ob jetzt ein Modul geladen ist oder nicht, sondern um die Basisarchitektur. Viele Optionen beeinflusssen div. Subsysteme und muessen beachtet werde. So hab ichs zumindest verstanden.

    Auch wenn man den Kernel um nicht benutzte Module abspeckt, wird der verbleibende, absolut notwendige Rest wohl immer groesser und damit auch ein wenig langsamer. Aber natuerlich verbraucht der Kernel nur einen kleinen Teil der Rechenzeit. Das System selber wird deshalb nicht gleich um den genannten Faktor langsamer.

    0
    Von Odol am Di, 22. September 2009 um 15:41 #
    Ja
    • 0
      Von Christopher Roy Bratusek am Di, 22. September 2009 um 17:30 #
      Nicht zwingend. Diverse Einstellungen lassen sich ja optimieren. Zwar wird er dann nicht mehr so schnell wie der 2.6.0, aber immerhin mehr als ein 08/15-Kernel der gleichen Version. Performance patches gibt's ja auch noch, beim selbstkompilierten Kernel kann man die ja hinzufügen.
    0
    Von romantic gorilla am Di, 22. September 2009 um 20:51 #
    > Hab ich da auch die Performance-Probleme?

    wieso "performance-probleme"? die aussage war doch nur, dass der kernel allmählich langsamer wird. ob sich das _spürbar_ auf die performance des systems auswirkt, ist ne andere frage.

0
Von the_Noob am Di, 22. September 2009 um 14:53 #

Ich kann es nicht genau benennen, aber ich denke, seit die "Grossen" angefangen haben, für Linux zu entwickeln, wurde der Kernel aufgebläht.
Alle Unix-artigen Systeme - angefangen von Hurd über Net/Open-BSD bis hin zu Sachen wie L4 -, die noch von "Hackern" entwickelt werden, sind
im grossen und ganzen leichtgewichtig und auch gut performant.
Sobald aber grosse Firmen anfangen, die Richtung in der Entwicklung anzugeben, wie sie es eben machen bei Linux, wird es sehr schnell unübersichtlich,
aufgebläht und ähnlich schwer und fett.
Zwar nicht ganz passend aber doch als Bild gut nutzbar wäre der Vergleich von grossen Firmen entwickelten Distributionen (Suse,Redhat,ja selbst Ubuntu) - die schon bei der Basisinstallation
mehrere hundert MB bis zu paar GB installieren mit allerlei Diensten und GUIs etc., die man später mühsam ausschalten muss - und von Hackern gemachten Distros(Damnsmalllinux, Slackware, Archlinux), die
man schon auf kleinste Datenträger bekommt.
  • 0
    Von Kernel am Di, 22. September 2009 um 15:04 #
    Also der Vergleich hinkt ja gewaltig.

    Hurd = Microkernel
    L4 = Microkernel

    Somit schon ein komplett anderes Konzept.

    BSD, Solaris, etc.. ist zwar auch ein Monolith kommt aber kaum an die HW Unterstüzung von Linux ran.


    GNU/Linux ist auch in Benchmarks einiges performanter als OpenSolaris, *BSD oder OS X. Siehe phoronox.com Benchmarks.

    0
    Von dark_star am Di, 22. September 2009 um 15:12 #
    Zitat: "aber die Stabilität sei sehr gut, Fehler würden schnell beseitigt und das Entwicklungsmodell funktioniere besser als je zuvor."

    Wenn die 'Kommerziellen' auch dafuer verantwortlich sind, kanns schon hinkommen. Immer mehr Features, immer mehr Plattformen, immer hoehere Entwicklungsgeschwindigkeit - dass das ohne jegliche Einbussen geht, ist wohl kaum moeglich.

    Aber ists wirklich so ein grosses Problem? Es gibt ja noch BSD&Co, die diesen Entwicklungsdruck seitens der kommerziellen Anwender nicht so massiv abbekommen.

0
Von Anton am Di, 22. September 2009 um 15:06 #
scnr ;-)
  • 0
    Von dalton am Di, 22. September 2009 um 15:17 #
    danke :)
    • 0
      Von TherealPartykracher am Di, 22. September 2009 um 15:38 #
      Weiß jemand wieviel Kilo der Mann auf den Rippen hat? Alternativ BMI?
      • 0
        Von fetter-linuxnerd am Di, 22. September 2009 um 15:50 #
        endlich, dann passt sich der linuxkernel, vom aussehen her also den linuxnutzern an :P

        das wäre auch eine erklärung dafür, wieso nach all den vielen releases, für mich persönlich, noch immer 2.6.24 am "schnellsten" rennt.

        gabs da nicht mal nen test drüber, das seit 2.6.24 irgendwas irrsinnige performanceverluste verursacht?

        beispiel: ich betreibe mein system nur mithilfe von live cds.

        knoppix mit 2.6.24 ist superflüssig. sidux mit 2.6.27 jedoch, spielt videos schon nicht mehr so flüssig ab UND die hd performance fühlt sich irgendwie langsamer an.

        dasselbe gilt für 2.6.30 sidux.

        bis auf weiteres, bleibe ich also auf 2.6.24

        • 0
          Von lalala am Di, 22. September 2009 um 16:23 #
          Ist doch schon arm dass man alte versionen benutzen muss weil die neueren so beschissen programmiert wurden dass selbst fluessiges video abspielen unmoeglich ist
          • 0
            Von fetter-linuxnerd am Di, 22. September 2009 um 16:30 #
            es ist eher so, dass die videos mit 2.6.27 und 2.6.30 zwar abgespielt werden, es jedoch immer wieder zu kleinen mikrorucklern kommt und sich imemr wieder ein paar asynchronitäten einschleichen. das geht so weit, das die videos, die ich mit 2.6.27+2.6.30 lade, auch auf 2.6.24 so abgespielt werden. dürfte also die dateien irgendwie "ändern".

            dateien, die ich mit 2.6.24 lade laufen immer flüssig.

            auch geht das schreiben auf der hd mit 2.6.24 um einiges schneller.

            • 0
              Von kartoffel200 am Mi, 23. September 2009 um 16:36 #
              Aha du bist wohl ein kleiner Experte... Videos, man die werden soooo was vom Kernel beschleunigt....
              Seit der ATi Mach64 oder der RAGE hat jede verfickte Graka extra MPEG fähigkeiten. Muss also der kleine "experte" weg von Chips und Cola und sich nen Treiber basteln der die Graka mit dem nötigen Scheiß vollnöhlt.
              Deshalb ziehen HD Videos, auch beim richtigen Codec, bei fehlender Grakaunterstützung ordentlich CPU Leistung.

              Ob der Kernel 2.6.24 oder 2.6.30 schneller ist oder nicht kann der normale Dekstopanwender eh nicht rausfinden, da der Xorg im Regelfall von Distri zu Distri neuer wird.

            0
            Von irgendwer am Di, 22. September 2009 um 16:32 #
            Das hat wohl weniger mit dem Kernel zu tun als viel mehr damit, dass wahrscheinlich seine Grafikkarte schlicht von Knoppix besser unterstützt/erkannt wird.
            Grafikperformance macht meines Wissens zwischen den Kerneln keinen großen Unterschied. Dahingegen macht es einen riesen Unterschied, ob nun xorgs vesa-Treiber, die freien nv/radeon-Treiber oder gar die proprietären nvidia/fglrx-Treiber zum Zuge kommen.
            (oder bei Intel z.B. welche Treiberversion mit welchem Beschleunigermodus: xaa, exa oder gar uxa)

            So merken wird man den Unterschied von 2.6.2x und folgenden wohl eher weniger. Es sei denn, es kommen unterschiedliche Scheduler, Memory Management, etc. zum Einsatz. Das ist es aber nicht, worum es hier ging.

            • 0
              Von Ragas am Di, 22. September 2009 um 22:04 #
              ... versuch mal den i915 mit nem 2.6.29er kernel und mit nem 2.6.31er kernel. möglichst mit aktiviertem kms .... es ist der unterschied zwischen himmel und hölle.
              • 0
                Von irgendwer am Do, 24. September 2009 um 13:52 #
                Na das sind ja dann eben auch unterschiedliche Treiberschnittstellen. Und wenn der Grafikkartentreiber ein anderer ist (bzw. in einer anderen Konfiguration läuft), dann macht das natürlich einen fühlbaren Unterschied in der gui.
                Intel mit uxa und gem ist nunmal schneller als mit xaa... und in der Umstellungsphase ist vieles einfach nur ein Graus...
            0
            Von lilili am Di, 22. September 2009 um 23:06 #
            So muss man das? Ich habe die fette SuSI auf meinem Notebook mit 512 MB RAM und 1,6 Ghz mit KDE 4.3.1 und bei mir laufen die Videos absolut flüssig.
          0
          Von --- am Di, 22. September 2009 um 18:35 #
          Es gibt einen mutmaßlichen I/O-Bug in Kernel seit etwa 2.6.15/2.6.18, der im schlimmsten Falle auch noch so "starke" Systeme mit 100% auslastet.
          An Xorg wird zur Zeit allerdings auch sehr viel verändert. Je nach Grafikkarte befindet sich u.U. sogar die zugehörige Kernel-Firmware mittlerweile in non-free.
          Welche Grafikkarte werkelt denn in Deinem Rechner?
          • 0
            Von Jo:rg Zweier am Di, 22. September 2009 um 22:05 #
            Ist der Bug bereits in .31 behoben?
            • 0
              Von --- am Mi, 23. September 2009 um 06:05 #
              Nein, nicht wirklich.

              Laut dem letzten Posting in

              http://bugzilla.kernel.org/show_bug.cgi?id=12309

              will ein Tester mit Kernel 2.6.31 eine geringe Verbesserung bemerkt haben:
              "There is an improvement in desktop responsiveness with kernel 2.6.31 and the as scheduler compared to the cfq scheduler. It does not solve the problem, but it makes it more sufferable."

              Das Hauptproblem ist, dass es keine stabile Kernel-2.6-Reihe von kernel.org gibt (die also jetzt noch supportet wird), die diesen Bug nicht hat.
              Ich persönlich setze - falls die Hardware es erlaubt - Kernel 2.4 ein, wo es nur möglich ist.

              Auf dem Desktop ist der Bug nicht so wichtig. Von Win9x-Zeiten her weiß man ja wohl noch, wo im Notfall der Reset-Knopf zu finden ist. Tritt der Bug ein, so kriecht das System dahin, siehe hierzu z.B. Kommentar 325 unter obigem Link.

              Falls Deine Hardware geeignet sein sollte, so lasse z.B. Slackware 11.0 mit Kernel 2.4 gegen ein neuestes Linux mit Kernel 2.6 antreten und lass deinen Rechner einmal so richtig arbeiten (mitunter reichen schon große Kopieraktionen im Rahmen des Versuchs von "Multitasking"; oder kompilier einen Kernel und arbeite gleichzeitig mit einem anderen Programmen weiter; usw.). Du wirst schnell feststellen, welches System "responsiver" ist.

              Kernel 2.6-Systeme verhalten sich unter annähernder Vollast, wenn denn der I/O-Bug zuschlägt, wie damals Win95 beim Formatieren einer Diskette.
              Siehe hierzu Kommentar 323 unter obigem Link:
              "The irony is that it feels like Windows 95 while a floppy was formated. You know, the whole pseudo multi tasking on top of Dos - everything was really choppy. (...) If I encode a DVD with ogmrip/mencoder h264 and 16 threads (16 threads get the highest cpu usage from my quad core which is still under 80% per core) Gnome feels like a formatting Win 95."

              • 0
                Von betroffener am Mi, 23. September 2009 um 08:26 #
                Auf dem Desktop ist der Bug nicht so wichtig. Von Win9x-Zeiten her weiß man ja wohl noch, wo im Notfall der Reset-Knopf zu finden ist. Tritt der Bug ein, so kriecht das System dahin, siehe hierzu z.B. Kommentar 325 unter obigem Link.
                Doch er ist GERADE auf Desktopsystemen nervig. Kopiere einfach mal ein paar Videos, ISOs, Backup,... von/zu USB-Platten und mach nebenbei was anderes, schon bist du betroffen. Mich nervt der Bug jeden Tag und kotzt mich immer mehr an. Normalerweise sind Bugs unter Linux schnell erkannt und gefixt aber hier wissen die Entwickler nicht mal wo das Problem ist.
                • 0
                  Von Michael Lehmeier am Mi, 23. September 2009 um 09:21 #
                  Wenn das dieser Bug ist, in den ich häufig reinlaufe, dann kann ich bestätigen, dass er nervig ist ohne Ende.

                  Wenn ich versuche, ein 16 GB Backup auf eine verschlüsselte SATA-Compact-Flash Karte oder USB-Stick zu machen ist die Wahrscheinlichkeit groß, dass der Computer sich so aufhängt, dass nur noch ein Reset hilft.
                  Nur in kleinen Häppchen mit sync dazwischen geht das gut. Das sehe ich nicht als "nicht so wichtig" an.

            0
            Von Ignatz am Mo, 26. Oktober 2009 um 22:08 #
            > Es gibt einen mutmaßlichen I/O-Bug in Kernel seit etwa 2.6.15/2.6.18, der im schlimmsten Falle auch
            > noch so "starke" Systeme mit 100% auslastet.

            Könnte man zum Stresstesten ausnutzen...

    0
    Von Jo:rg Zweier am Di, 22. September 2009 um 22:02 #
    --

    Niveauloser geht es wirklich nicht mehr?!

0
Von ff am Di, 22. September 2009 um 19:19 #
Nicht nur der Kernel, auch der Firefox ist fett und aufgebläht.
0
Von D3xter am Di, 22. September 2009 um 19:20 #
Gabs da nicht mal den "Kernel-Bug" seit ca 2.6.17/18 mit dem IO-Scheduler, der zu viel CPU braucht?
0
Von me am Di, 22. September 2009 um 19:22 #
Was ein linux System träge erscheinen lässt ist der xserver der einfach zu alt, zu fett, zu ufgebläht und einfach unpassend für solch ein modernes PC System ist.
Mir persönlich kam ne Linux Konsole und dessen Befehle immer mehr als schnell genug vor. Nur an der GUI hängts leider noch
  • 0
    Von Brendo am Mi, 23. September 2009 um 10:36 #
    X ist nicht das Problem. Verwende doch mal einfach weder KDE noch Gnome, und Du wirst feststellen, dass das System auch richtig schnell sein kann.
    • 0
      Von me am Mi, 23. September 2009 um 18:04 #
      und als xfce auf arch linux auch träger als mein xp war, ahb ichs aufgegeben
      linux ist durchdacht, linux ist schnell, aber der xserver ist einfdach müll...
0
Von lutschi am Di, 22. September 2009 um 20:46 #
fett.
Linux hat nur schwere Knochen!
0
Von ja, name am Mi, 23. September 2009 um 08:07 #
ok, ich komme aus der gentoo-ecke... wenn ich einen kernel backe dann ist eh nur treiberunterstützung für die hardware des jeweiligen rechners einkompiliert. wenn möglich lasse ich gar keine module zu.
wenn linus meint das sei ihm zu fett dann interessiert mich ehrlich wo er die speckröllchen sieht.
0
Von Apfelmann am Mi, 23. September 2009 um 19:21 #
Vielleicht wäre eine sinvolle Lösung den Kernel zu splitten.
Somit das man zum beispiel 3 Bereiche abdeckt.
Home/Office
Server
Embedded
Somit könnte man überflüssige funcionen umgehen die einfach das ganze nur unnötig an die leistung kratzen.
  • 0
    Von kartoffel200 am Do, 24. September 2009 um 11:12 #
    Wäre fatal weil sich da evlt sich alles auseinander entwickelt und keine Binärkompatiblität mehr wäre.
Pro-Linux
Traut euch!
Neue Nachrichten
Werbung