Kein Frage, seit Kernel 2.4.13 swapt mein Rechner deutlich weniger. Ich fand es schon peinlich, wenn beim 2.4.9er Kernel nach ca. 30 min Inaktivität, alles auf das Swap-Device ausgelagert wurde, obwohl mit 512MB RAM ausreichend Reserven bestanden.
Von Fabian Wolf am Di, 30. Oktober 2001 um 03:46 #
Das kann ich bestätigen, ich hab auch noch ne ältere Maschine mit 128MB RAM im Einsatz und erst seit neueren Kernelversionen läuft alles richtig stabil. Welche Version des VM es auch immer ist, die da läuft, ich würd sie drin lassen. Ältere Kernels fingen immer kräftig an zu swappen und ich hatte auch des öfteren lock-ups deswegen. Wäre es nicht möglich sich bei der Kernelkonfiguration für eine VM seiner Wahl zu entscheiden. Ein bißchen mehr Code und hier und da ein paar 'ifdef's... müßte doch machbar sein.
Dort steht der Thread, welches das "optionale" beinhaltet. Es sind leider keine "paar" Zeilen sondern doch auch gleich tiefgreifende Systemkomponenten betroffen.
Mal davon abgesehen, daß ja alle Architekturen betroffen sind und jede hat hier unterschiedliche Speicherverwaltungs-Hardware. Auch steht ja in der Meldung schon, daß es schon heute mit den Treibern Probleme gibt.
Von Doki Nafaso am Di, 30. Oktober 2001 um 11:02 #
Dazu eine Info aus "Kernel Traffic":
#Michael T. Babcock asked how ugly it would be to make Rik van Riel's and Andrea Arcangeli's Virtual Memory subsystem code into a compile-time option, so folks could try each one out as they pleased. Alan Cox replied simply, "Too ugly for words." [..] Marcelo Tosatti replied, "[..] Way too much overhead. For 2.5 we'll probably be able to get people working together."#
Von bodo schulz am Di, 30. Oktober 2001 um 07:11 #
Ja, kann ich auch bestätigen. Selbst die aufgepatchten SuSE Kernels swappen was das das Zeug hält, ohne erkennbaren Grund. Schon deshalb versuche ich seit gestern den 2.4.13er hier zu kompilieren doch leider scheitere ich immer wieder, weil er das root Filesystem ( /dev/hda5 als ext2 ) nicht finden kann. :( Kurioserweise nutze ich die Kernelkonfig von SuSE ... und habe auch eine neue initrd erstellt ...
@Bodo : Kenelconfig im Suse??.Ist das ein Tool oder was?.Ich hatte 2.4.12 kompiliert,aber irgendwas geht da schief... Da dachte ich gleich,daß der Kernelconfig ein Tool ist.
ja, die offiziellen Kernel sind meistens viel zu komplex, da sie ja auf so gut wie jeder Maschiene laufen sollen. Schon mit geringen Kenntnissen des Rechners kann man dort ordentlich ausmisten (SCSI oder IDE raus, andere Soundkarten raus, andere Netzwerkkarten raus, PCMCIA raus usw.) Im Betrieb des Kernels wird das nicht so viel ausmachen, aber das kompilieren geht deutlich schneller ;)
@Bodo: Hast du mal nachgesehen, ob ext2 wirklich fest im Kernel drin ist? (Unter File Systems muss bei Second extended fs support ein <*> sein, kein <M>).
mache ich eigentlich generell immer. Allerdings hatte ich da auf einmal auch ziemlich viel Probleme. Hmm, wenn ich es so richtig bedenke ... seit dem 2.4.6er lief keine Kernelcompilierung bei mir ohne irgendwelche komplikationen, obwohl ich mich an die richtlinien (oder HowTo's) halte ... und ich kompiliere Kernel seit dem 2.0.1er ... :)
Von Carsten Maul am Di, 30. Oktober 2001 um 14:25 #
Normalerweise kompiliert man ein kernel so:
make dep clean bzlilo && make modules && make modules_install
bei Suse geht es so:
make dep clean bzlilo && make modules && make modules_install && mk_initrd
mk_initrd nicht vergessen. In der SuSE Kernelkonfiguration sind viele Dateisysteme als Module konfiguriert, diese werden dann mit Hilfe einer init Ramdisk nachgeladen, die natürlich erst durch das script
Naja, die Aufspaltung des Kernels ist de fakto da. Aber weder Alan noch Linus haben die Absicht, das dauerhaft aufrecht zu erhalten. Linus wird sich ja sowieso bald Kernel 2.5 zuwenden.
Hmm..allerdings, frag ich mich, ob der(/die) Kernel bei einer Aufspaltung nicht besser sind. SuSE hat ja auch nen eigenen Kernel und da fließen auch immer viele interessanten Features ein die auch nicht unbedingt in den offiziellen Linux-Kernel einfließen.
man sollte vielleicht darüber nachdenken, ob man den Kernel nicht lieber in ein CVS stellt. Desweiteren wäre es auch nicht schlecht, wenn man es den Entwickerln einfacher macht die Erweiterungen modularer in den Kernel einzubringen (JFS reinpatchen - kein Problem. Aber ext3 und XFS in den 2.4.13 zu bringen bedarf schon ein 'bisschen' Handarbeit).
Was macht ein CVS: Es verwaltet technisch Patches. Was braucht man für ein CVS: Einen Release-Koordinator, der entscheidet, was wann wie für welche Version reindarf.
Und was ist mit Linus. Sogesehen ist Linus (bzw. Alan) das CVS, nur dass beide halt mit etwas mehr Handarbeit arbeiten.
Was würde ein CVS für den Kernel bringen? Fast nichts. Zumindest würden sich Linus oder Alan nur einen sehr geringen Aufwand für die Verwaltung einsparen.
CVS hat den Nachteil, dass man die Patches nicht ueber Linus mehr gehen wuerden. Entweder nur Linus darf committen (dann bringt es nichts und du kannst genausogut die bestehenden CVS-Mirrors benutzen), oder du laesst Leute selbst committen, womit Linus die Kontrolle verlieren wuerde.
Deswegen wurde ja auch das BitMover-System erdacht, ein SCM-System bei dem Commits durch Filter aehnlich der jetzigen Struktur laufen muessen. Benutzt wird es derzeit zumindest jedoch noch nicht.
Ich kann auch nicht verstehen, was am ext3-patchen aufwändig sein soll. Das ist doch mit einem einzigen Befehl erledigt. Okay, man muss es dann noch auswählen... ;)
Von Christoph Hellwig am Di, 30. Oktober 2001 um 13:53 #
@ex-Anonymous:
ich habe die datei ja schon rumliegen :)
Ausfuerlichere Fassung liegt auf ftp.openlinux.org in /pub/people/hch/jfs/jfs.mk
Der Vorteil ist das du jfs damit einfach laden kannst ohne den kernel-tree anzufassen, zum Bleistift wenn du den Standard-Kernel deiner distribution nutzt.
Kernelpatchen - kein Problem! Aber hat mal jemand zwei,drei oder nochmehr Patches reingepatcht? Klar einer ist kein Problem! Bei bei mir (XFS,ext3) ist nunmal nix mehr mit bzcat xxxx.tar.bz2|patch -p1 ! Die Patches sind dann zwar drin, aber dann.... IBM ist da mit JFS schon ein Stück weiter. Die ändern den Kernel nur noch da, wo es unbedingt notwendig ist.
CVS bringt in der jetzigen Form natürlich nicht so viel, aber wäre der Kernelsource modularer, könnte man problemlos jede Version auschecken.
Verändert der XFS-Patch nicht aucht einiges am VM? Ich setze jedenfalls den 2.4.9-xfs ein, und habe von den beschriebenen Speicherverwaltungsproblemen noch nichts gemerkt. Kann durchaus sein, daß mit dem xfs-Patch einige Bugs behoben sind.
Bei mir liefen die jfs und xfs patches zusammen bei diversen Kernelversionen ohne Probleme. Ich brauchte nicht mal die aktuellen Patches. Das Zusammenspiel ist also kein Problem.
Jens sprach davon, daß es schwer wird zwei oder mehr Patches gleichzeitig reinzubringen. Er hat nie behauptet, daß JFS schwerer oder leichter einzubauen ist. Lest doch einfach mal genauer!
So wie Du es für JFS beschreibst, scheint mir XFS aber leichter zu behandeln zu sein
Sorry, aber wieso sollte sich der Kernel langfristig wirklich spalten?
Die Situation heute ist einfach so: Es gibt 2 VMs und keiner kann bisher eindeutig sagen, welche davon wirklich besser ist. Damit sind harte Fakten ala Perfomance gemeint und nicht etwa Bugs (die kann man immer bereinigen).
Und so ist es mit den VMs nunmal, ohne den praktischen Beweis, welches Konzept sinnvoller ist, geht es nunmal nicht.
mag sein das ich vom PRogrammieren überhaupt keine Ahnung habe, aber ein einfachen Code würde ich erstmal dem komplizierten, größeren Code vorziehen. Selbst wenn beide gleich wenig Bugs haben sollten. Wenn sich aber rausstellt das der eine kaum praxistauglich ist, hilft es natürlich nicht... Überlassen wir die Diskussion am Besten denjenigen die Ahnung haben. Bis jetzt haben die Ihren Job gutgemacht ;-) Ich hoffe Alan und Linus bleiben Freunde...
"aber ein einfachen Code würde ich erstmal dem komplizierten, größeren Code vorziehen"
Klar, den findest Du im 2.2'er ;-)
Beide sind inzwischen "praxistauglich" und zwar so sehr, wie es eine VM sein kann, die gerade ein paar Releases alt ist. Daher arbeiten die meisten ISPs noch mit dem 2.2'er Kernel. Mal davon abgesehen ist der 2.4'er halt noch lange nicht so ausgiebig getested wie der 2.2'er. Viele ISPs trauen dem IPTables usw. auch noch nicht.
Ergo: Die aktuelle Situation ist zwar ärgerlich, aber genau der Vorteil von OS: Es gibt nicht einen Patriarchen, der einfach festlegt, was besser sein soll, sondern der Code selbst kann es beweisen. Und für alle, denen das zu unsicher ist: 2.2'er Kernel!
Das stimmt eben nicht. Linux hat diesen Patriarchen, der (oft in einsamen und unverständlichen Entscheidungen) festlegt was das beste ist. Kein anderes Projekt in ähnlicher Grössenordnung, z.B.Apache, KDE, FreeBSD usw. leistet sich einen solchen Diktator (der auch deshalb Probleme bekommen wird, weil sich ein anderer als der bessere Projektleiter empfiehlt). Das Linux Kernel Projekt ist von seiner Organisation her leider sehr unreif. Wenn das so bleibt, halte ich Spaltungen mittel -und langfristig für unvermeidlich. Aber Spaltungen müssen ja nichts schlimmes sein, so lange es nicht zu viele werden.
es muß immer einen geben, der eine Entscheidung trifft. Ob dieser jenige nun durch ein Gremium bestimmt wird, ernannt wird oder einfach da ist, ist sekundär. Jedes OS-Projekt hat einen Release-Koordinator, der vor einem Release noch bestimmt, was rein darf und was nicht.
Mit Patriarch meine ich aber jemanden wie einen Boss, dessen Entscheidungen als Untergebener man nicht öffentlich anzweifeln kann, was wiederum zu langwierigen Fehlentscheidungen führt. Linus ist auch ein Entscheider, nur seine Entscheidungen werden öffentlich diskutiert und er will das auch so. Er will sich überzeugen lassen! Ein gutes Beispiel dafür ist zb die MIN/MAX-Thematik. Linus hat was entschieden, es wurde diskutiert und eine bessere Lösung vorgeschlagen, die ihn überzeugt hat. Ich kann mir nur schwer vorstellen, daß dies bei einem "Boss" auch so gelaufen wäre.
Ich finde auch das es die Aufspaltung eigentlich schon lange gibt. Viele sind schon lange von Linus' auf die Alan Cox Versionen umgestiegen, weil sie aktueller sind und weniger Probleme machen. Auf jedenfall surren die ac-kernels bei mir wie ein Bienchen, derweilen die "offiziellen" von Linus öfter mal Probleme machten.
>Auf jedenfall surren die ac-kernels bei mir wie > ein Bienchen, derweilen die "offiziellen" von Linus öfter mal Probleme machten.
Das kann man vom 2.4.13 allerdings auch behaupten: Endlich mal keine Probleme...
Er swapt nicht nur nicht unnötig, sondern geht auch sonst sparsam mit dem Ram um. Ich hab mich schon gewundert, aber das wieder mal neue Speichermanagement ist eine Erklärung dafür.
Eine Spaltung des Projekts wird es sicher nicht lange geben, bisher sind noch alle Streitigkeiten wieder beigelegt worden.
Von Oliver Siegmar am Di, 30. Oktober 2001 um 11:32 #
Da wurde doch erst vor kurzem ein Kernel-Performance-Test-Center (oder so ähnlich :-)) gegründet. Soll man doch dort einfach mal die beidem VM-Engines richtig durchtesten. Eine Aufspaltung des Kernels halte ich für eine Katastrophe (dann werden nämlich die Mutations-Vorwürfe tatsächlich an Nährstoff gewinnen). Ich persönlich bin von der neuen VM-Engine begeistert. Wo bei ich etwas eigenartig finde, dass der Kernel bei >=512 MB RAM scheinbar gar nicht mehr zu swappen beginnt...aber vielleicht ist die Kiste tatsächlich noch nicht genug ausgelastet. Trotzdem: Egal welche VM - lasst den Kernel "ganz" und bitte nur _EINEN_ Linux-Kernel!
Nun, ein halbes Gigabyte RAM *ist* nun mal eine ganze Menge! Es ist noch nicht sooo labge her, da lief Linux bei unter 8MB RAM mit 'ner 350MB-Platte. Dass lässt sich heutzutage alles *zusammen* im RAM halten...
Wenn die Bibliotheken erst mal im RAM sind, ist das meiste ja schon gegessen. Da sollten 512 MB wirklich weit reichen.
Aber das tun sie mit dem derzeitigen 2.4.12 definitiv nicht! Bei 512MB RAM reicht es, den Rechner 1-2 Stunden stehen zu lassen, (ohne X und ähnlichem Gedöhns) und der Swap von 512MB ist definitiv zu 100% in Benutzung! Dann ist der Kernel definitiv nicht für einen Server ausgelegt ... selbst für einen Client wird es da schon schwer vernünftig mit zu arbeiten. Wenn ich mir den guten alten 2.2.16er auf meinem Server anschaue ... der läuft so was von sauber ... und das mit 128MB und swappt kaum, wenn er mal gefordert wird ...
Nu je, das ist halt der Grund, weshalb es einen 2.4.13er gibt... Und so ganz persönlich halte ich die Kürze der Changelogs in den Pre-Patches zum 14er für ein gutes Zeichen. Auch wenn sich hinter "Alan Cox: Continued merging" allerhand verstecken kann... :-)
>Bei 512MB RAM reicht es, den Rechner 1-2 Stunden stehen zu lassen, (ohne X und ähnlichem Gedöhns) und der Swap von 512MB ist definitiv zu 100% in Benutzung! Cronjobs ?!
Nur keine Aufspaltung des Kernels. Mein Kernel 2.4.3 Mandrake swap nicht 128 MB sind zu wenig mit 256 MB keine Probleme. Zur Zeit 164 MB belegt swap 0.
Von Felix Huber am Di, 30. Oktober 2001 um 14:14 #
und hast du gründe für diese behauptung? kennst du das mosix projekt oder andere projekte von ihm (http://www.google.de/search?q= cache:jahbIuSiJNk:www.moelabs.com/html/myprojects.html+ moshe+ MyProjects&hl=de) ?
sicher nicht... wahrscheinlich bist du einfach nur der volltrottel.
Qualität des FreeBSD-Kernels: eigentlich sehr gut, ich kann nicht klagen. Von wegen "512 MB RAM und nach einer halben Stunde ist der Swap voll": ich hab hier 'n FreeBSD-Web- und Datenbankserver (Apache, MySQL, PostgreSQL), der rennt seit zwei Monaten und hat den Swap noch nicht mal angeknabbert
Also, ich habe FreeBSD seit 2 Jahren hier auch als Desktop laufen. Der FreeBSD Kernel hat ein sehr gutes und weithin anerkanntes VM-System das auch wirklich ausgereift ist. Du kannst die gleichen Applikationen wie unter Linux einsetzen. Der einzige nennenswerte Mangel für den Desktopeinsatz, der mir einfällt, ist die fehlende Unterstützung für 3d acceleration der NVIDIA Karten (andere, z.B.Matrox,ATI gehen aber). Ich jedenfalls kann mit Linux auf dem Desktop auch nicht mehr machen, als mit FreeBSD. Und in dem Fall bevorzuge ich FreeBSD deutlich ;-) Welche Hardware unterstützt wird, kannst du den HardwareNotes für das letzte Release (z.B. auf www.freebsd.org) entnehmen.
Das Buch kann ich nicht beurteilen, habs kürzlich mal in einer Buchhandlung durchgeblättert und hatte den Eindruck, dass es ganz brauchbar ist. Wenn du schon schon etwas Linux-Erfahrung hast reicht dir aber wahrscheinlich das Handbuch, das mit FreeBSD kommt.
Warum wird der Kernel eigentlich weiterhin in C entwickelt? Es gibt doch sicher Programmiersprachen die C überlegen sind und weniger Programmierfehler zulassen.
Weil man mit Basic, Java, Perl, Python, Ruby, Smalltalk, ... keine Betriebssystem schreiben kann.
Auf der LKML wurde schon einmal Diskutiert C++ für den Kernel einzusetzen was aber aus diversen Gründen (zumindest vorläufig) ad acta gelegt wurde. Näheres siehe in älteren Postings der LKML.
Unsinn! Solange noch kein Betriebssystem in Basic....usw. existiert heisst das noch nicht dass es nicht möglich wäre. Ausserdem, wer würde schon Perl,Basic und so verwenden. Ich denke eher an Common Lisp, Mercury, Haskell, Modula3,Eiffel usw...
Hast du schon einmal probiert, mit BASIC direkt auf Hardware zuzugreifen ? Ich meine jetzt weder irgendwelche PEEKs und POKEs noch direkte Zugriffe auf den seriellen oder parallelen Port um etwas zu steuern, sondern direkt auf die im Rechner installierte Hardware zuzugreifen um z.B. einen Betriebssystemtreiber zu programmieren.
Zumindest mit den mir bis jetzt bekannten BASIC Programmiersprachen ist es nicht möglich etwas derartiges mit BASIC zu programmieren. Mit Microsofts .NET kann dies sich ändern, da dort dann der Quellcoder einer .NET-Fähigen Programmiersprache erst nach CIL übersetzt wird und dann von CIL in eine vom Betriebsystem ausführbare Datei umgesetzt wird. Theoretisch ist es mit .NET möglich Hardwaretreiber mit jeder erdenklichen .NET-fähigen Programmiersprache zu schreiben solange die dort verfügbaren Programmierkonstrukte alle notwendigen Aktionen erlauben. Dann könnte man selbst mit Smalltalk, Eiffel und Fortran seine Treiber schreiben. Ob dies in Wirklichkeit auch so vielfältig möglich ist, wird sich zeigen sobald der erste .NET Server vom Microsoft erhältlich ist. In irgendeinem Newsticker stand in dieser Woche, dass Bill Gates selbst die .NET Entwickler zu Geduld auffordert da .NET Server erst 2004 verfügbar sein werden. Soviel zum Thema Programmierung mit nicht-C.
... mit dem Oberon-Zeugs hab ich mich wohl verraten. Ja ich studier an der denkwürdigen ETH. Aber ich schwöre mehr als ein paar Stunden hab ich an oberon nicht verbracht (ehrlich). Ich verschrieb mir eine Inter-Click-Dispenz
No Forks! Wie oben schon erwähnt wär' es ein Leckerbissen für M$, wenn es plötzlich zwei Kernel Reihen gäbe. Ich erinnere mich da an eine Werbekampagne... Ich finde Linus sollte sich auf die Entwicklerkernel konzentrieren, als Vordenker für die stable Reihen und Alan kümmert sich dann um diese. Dann würde nicht so viel Man-Power verloren gehen. Das wär effizienter. Und AC hat ja schon gezeigt, dass er mit Kerneln umgehen kann. Aber ich glaube die Vernunft wird siegen. Ein Fork ist bestimmt nicht im Sinne der Beiden. Das würd auch nur Verwirrung stiften bei vielen User, wenn man zwischen Linux-LT und Linux-AC unterscheiden müsste. Naja, es könnt auch einfach Cox heißen, das X ist ja schon da
Sagen wir, die eine Variante ist auf kleinen Maschinen deutlich überlegen, die andere auf dicken Servern (jetzt nur mal theoretisch). Es gibt kein Gesetz, daß es immer eine beste Lösung für alle Anwendungsfälle geben muß.
Sollte Linux sich der Windows-Lüge anschließen ("eine Lösung paßt überall, vom PDA bis zum Hochverfügbarkeitsserver")?
Oder sollte man (Variante zwei) in Kauf nehmen, daß ein abscheulicher Aufwand getrieben werden muß, um beide Varianten im selben Kernel als Optionen mitzuschleppen, selbst wenn dann etliche neue Erweiterungen beide Varianten berücksichtigen müssen?
Oder sollte man drittens in Kauf nehmen, daß Linus im 2.5er auf die eine Variante setzt, während Alan im 2.4er die andere weiterpflegt und den 2.6er gar nicht mehr mitmacht, bis eines Tages die ersten Treiber nur noch mit dem einen Kernelzweig laufen?
Ich mag mich für keine der Varianten entscheiden müssen (und bezweifle, daß das in diesem Fall nötig sein wird), aber es scheint mir eine nicht zu abwegige Grundsatzfrage zu sein, auf die man vorbereitet sein sollte.
Natürlich gibt es nicht die eierlegende Wollmilchsau.
Aber das ist nicht das Problem zwischen den VMs. Die eine ist von Anfang an komplex aufgebaut, um die schwierige Situation zu meistern, wenn der Speicher ausgegangen ist. Nachdem dies fertig ist, wird sie nun auf Performance getrimmt (Alan).
Die andere ist von Anfang an auf Performance getrimmt und nun wird sie auf die komplexe Situation weiterentwickelt, wenn der Speicher ausgegangen ist (Linus). Beiden geht es nicht um die Perfektion, sondern nur darum welcher Weg der sinnvollere ist. Alan gibt seinem Kernel mehr Zeit für Performance während Linus seinem mehr Zeit für die Komplexität gibt. Unterm Strich sagen beide: Der entscheidende Punkt ist die Performance und nicht welchen Prozeß die VM nun genau killt, wenn der Speicher aus ist. Zum Schluß wird die VM übrig bleiben, die im Schnitt 10% schneller ist und dabei kaum unterschiedliche Funktionalität aufweist.
...Ich kann hier bis jetzt keinen Streit erkennen, sondern lediglich eine Diskussion, die versucht, das Für und Wieder bzw. die Vor- und Nachteile der VM zu beleuchten. Und genau DAS ist es, was die echten Anhänger und Programmierer der Open-Source auszeichnet: Diskussion. Abwägen. Konstruktiv kritisieren. Nach Lösungen suchen.
Und nicht so ein polemischer Kommentar wie von Dir.
Sie haben doch schon Nachhilfe genommen und sogar was dabei gelernt. ;-) Man muss ihnen aber Zeit lassen . Das VM-system von FreeBSD ist jedenfalls auch nicht über Nacht entstanden. John Dyson hat es in durchaus mühsamer und langwieriger Arbeit getuned und Flaschenhälse beseitigt. Das Ergebnis ist ein exzellentes VM, das vor allem unter hoher Last seine Stärken ausspielen kann. Bei Linux scheint halt nicht jeder die Geduld aufzubringen, die es braucht um so etwas zu produzieren. Was mich allerdings etwas wundert ist, dass die Linux-Hacker trotz aller erdenklichen Möglichkeiten die ihnen die Grossindustrie zur Verfügung stellt (und die FreeBSD nie hatte) bisher nichts wirklich gutes in diesem Bereich zustande gebracht haben. Linux wird ja schliesslich auch nicht erst seit gestern entwickelt.
Gruß
Fabian
Dort steht der Thread, welches das "optionale" beinhaltet.
Es sind leider keine "paar" Zeilen sondern doch auch gleich tiefgreifende Systemkomponenten betroffen.
Mal davon abgesehen, daß ja alle Architekturen betroffen sind und jede hat hier unterschiedliche Speicherverwaltungs-Hardware.
Auch steht ja in der Meldung schon, daß es schon heute mit den Treibern Probleme gibt.
#Michael T. Babcock asked how ugly it would be to make Rik van Riel's and
Andrea Arcangeli's Virtual Memory subsystem code into a compile-time option,
so folks could try each one out as they pleased. Alan Cox replied simply,
"Too ugly for words."
[..]
Marcelo Tosatti replied, "[..] Way too much overhead. For 2.5 we'll probably be
able to get people working together."#
Ciao,
doki
Bitte klicken.
Das wäre der Geist von GNU und Linux. Gebt den User die Wahl beim kompilieren des Kernels!
BEN
Das wäre der Geist von GNU und Linux. Gebt den User die Wahl beim kompilieren des Kernels!
BEN
Selbst die aufgepatchten SuSE Kernels swappen was das das Zeug hält, ohne erkennbaren Grund.
Schon deshalb versuche ich seit gestern den 2.4.13er hier zu kompilieren doch leider scheitere ich immer wieder, weil er das root Filesystem ( /dev/hda5 als ext2 ) nicht finden kann. :(
Kurioserweise nutze ich die Kernelkonfig von SuSE ... und habe auch eine neue initrd erstellt ...
Naja, heut abend probier ich noch mal
Bodo
Da dachte ich gleich,daß der Kernelconfig ein Tool ist.
@Bodo: Vielleicht funktioniert wenn du den Kernel selbst konfigurierst, ist eh besser.
ja, die offiziellen Kernel sind meistens viel zu komplex, da sie ja auf so gut wie jeder Maschiene laufen sollen. Schon mit geringen Kenntnissen des Rechners kann man dort ordentlich ausmisten (SCSI oder IDE raus, andere Soundkarten raus, andere Netzwerkkarten raus, PCMCIA raus usw.) Im Betrieb des Kernels wird das nicht so viel ausmachen, aber das kompilieren geht deutlich schneller ;)
@Bodo: Hast du mal nachgesehen, ob ext2 wirklich fest im Kernel drin ist? (Unter File Systems muss bei Second extended fs support ein <*> sein, kein <M>).
cu iGEL
mache ich eigentlich generell immer.
Allerdings hatte ich da auf einmal auch ziemlich viel Probleme.
Hmm, wenn ich es so richtig bedenke ... seit dem 2.4.6er lief keine Kernelcompilierung bei mir ohne irgendwelche komplikationen, obwohl ich mich an die richtlinien (oder HowTo's) halte ... und ich kompiliere Kernel seit dem 2.0.1er ... :)
B.
*grins*
ein Spaßvogel, seht ein Spaßvogel ...
make dep clean bzlilo && make modules && make modules_install
bei Suse geht es so:
make dep clean bzlilo && make modules && make modules_install && mk_initrd
mk_initrd nicht vergessen. In der SuSE Kernelkonfiguration sind viele Dateisysteme als Module konfiguriert, diese werden dann mit Hilfe einer init Ramdisk nachgeladen, die natürlich erst durch das script
mk_initrd
für das neue Kernel erstellt werden muss.
Gruß
Carsten
man sollte vielleicht darüber nachdenken, ob man den Kernel nicht lieber in ein CVS stellt. Desweiteren wäre es auch nicht schlecht, wenn man es den Entwickerln einfacher macht die Erweiterungen modularer in den Kernel einzubringen (JFS reinpatchen - kein Problem. Aber ext3 und XFS in den 2.4.13 zu bringen bedarf schon ein 'bisschen' Handarbeit).
MfG
Jens
Jetzt benutze ich ersteinmal 2.4.13-ac4 + preempt+kernel-patch:
http://www.tech9.net/rml/linux/
Läuft gut und geschmeidig. Aber kein XFS.
Ist auch nur ein patch zum einspielen.
cd /usr/src/linux
cat ../xfs-patch | patch -p1
Wäre mal interessant, was bei JFS einfacher ist ?!
Was macht ein CVS:
Es verwaltet technisch Patches.
Was braucht man für ein CVS:
Einen Release-Koordinator, der entscheidet, was wann wie für welche Version reindarf.
Und was ist mit Linus.
Sogesehen ist Linus (bzw. Alan) das CVS, nur dass beide halt mit etwas mehr Handarbeit arbeiten.
Was würde ein CVS für den Kernel bringen?
Fast nichts. Zumindest würden sich Linus oder Alan nur einen sehr geringen Aufwand für die Verwaltung einsparen.
Deswegen wurde ja auch das BitMover-System erdacht, ein SCM-System bei dem Commits durch Filter aehnlich der jetzigen Struktur laufen muessen. Benutzt wird es derzeit zumindest jedoch noch nicht.
mach einfach ein verzeichnis jfs; dann patch -p1 < , fehler immer ignorieren.
und fs/jfs/Makefile mit folgendem ersetzten:
KTREE = /usr/src/linux
CFLAGS = -O2 -Wall -D__KERNEL__ -DMODULE -D_JFS_4K -I${KTREE}/include -I../../include
OBJS = jfs_debug.o jfs_dmap.o jfs_dtree.o jfs_extent.o jfs_uniupr.ojfs_txnmgr.o jfs_umount.o jfs_unicode.o jfs_xtree.o jfs_imap.o jfs_inode.o jfs_logmgr.o jfs_metapage.o jfs_mount.o file.o inode.o namei.o super.o symlink.o
all: jfs.o
jfs.o: ${OBJS}
ld -r -o $@ ${OBJS}
Ich kann auch nicht verstehen, was am ext3-patchen aufwändig sein soll. Das ist doch mit einem einzigen Befehl erledigt. Okay, man muss es dann noch auswählen... ;)
cu Johannes
Und, welches Sinn macht es, jfs außerhalb des Kernels zu übersetzen ?
ich habe die datei ja schon rumliegen :)
Ausfuerlichere Fassung liegt auf ftp.openlinux.org in /pub/people/hch/jfs/jfs.mk
Der Vorteil ist das du jfs damit einfach laden kannst ohne den kernel-tree anzufassen, zum Bleistift wenn du den Standard-Kernel deiner distribution nutzt.
Einfacher war testen nie :)
Christoph
Kernelpatchen - kein Problem! Aber hat mal jemand zwei,drei oder nochmehr Patches reingepatcht? Klar einer ist kein Problem! Bei bei mir (XFS,ext3) ist nunmal nix mehr mit bzcat xxxx.tar.bz2|patch -p1 ! Die Patches sind dann zwar drin, aber dann.... IBM ist da mit JFS schon ein Stück weiter. Die ändern den Kernel nur noch da, wo es unbedingt notwendig ist.
CVS bringt in der jetzigen Form natürlich nicht so viel, aber wäre der Kernelsource modularer, könnte man problemlos jede Version auschecken.
MfG
Jens
PS: Flamewar Rulz
Ich setze jedenfalls den 2.4.9-xfs ein, und habe von den beschriebenen Speicherverwaltungsproblemen noch nichts gemerkt. Kann durchaus sein, daß mit dem xfs-Patch einige Bugs behoben sind.
Jens sprach davon, daß es schwer wird zwei oder mehr Patches gleichzeitig reinzubringen.
Er hat nie behauptet, daß JFS schwerer oder leichter einzubauen ist.
Lest doch einfach mal genauer!
So wie Du es für JFS beschreibst, scheint mir XFS aber leichter zu behandeln zu sein
Sorry, aber wieso sollte sich der Kernel langfristig wirklich spalten?
Die Situation heute ist einfach so:
Es gibt 2 VMs und keiner kann bisher eindeutig sagen, welche davon wirklich besser ist. Damit sind harte Fakten ala Perfomance gemeint und nicht etwa Bugs (die kann man immer bereinigen).
Und so ist es mit den VMs nunmal, ohne den praktischen Beweis, welches Konzept sinnvoller ist, geht es nunmal nicht.
Selbst wenn beide gleich wenig Bugs haben sollten.
Wenn sich aber rausstellt das der eine kaum praxistauglich ist, hilft es natürlich nicht...
Überlassen wir die Diskussion am Besten denjenigen die Ahnung haben.
Bis jetzt haben die Ihren Job gutgemacht ;-)
Ich hoffe Alan und Linus bleiben Freunde...
Gruss Max
Klar, den findest Du im 2.2'er ;-)
Beide sind inzwischen "praxistauglich" und zwar so sehr, wie es eine VM sein kann, die gerade ein paar Releases alt ist.
Daher arbeiten die meisten ISPs noch mit dem 2.2'er Kernel.
Mal davon abgesehen ist der 2.4'er halt noch lange nicht so ausgiebig getested wie der 2.2'er.
Viele ISPs trauen dem IPTables usw. auch noch nicht.
Ergo: Die aktuelle Situation ist zwar ärgerlich, aber genau der Vorteil von OS: Es gibt nicht einen Patriarchen, der einfach festlegt, was besser sein soll, sondern der Code selbst kann es beweisen.
Und für alle, denen das zu unsicher ist: 2.2'er Kernel!
Kein anderes Projekt in ähnlicher Grössenordnung, z.B.Apache, KDE, FreeBSD usw. leistet sich einen solchen Diktator (der auch deshalb Probleme bekommen wird, weil sich ein anderer als der bessere Projektleiter empfiehlt). Das Linux Kernel Projekt ist von seiner Organisation her leider sehr unreif. Wenn das so bleibt, halte ich Spaltungen mittel -und langfristig für unvermeidlich. Aber Spaltungen müssen ja nichts schlimmes sein, so lange es nicht zu viele werden.
es muß immer einen geben, der eine Entscheidung trifft.
Ob dieser jenige nun durch ein Gremium bestimmt wird, ernannt wird oder einfach da ist, ist sekundär.
Jedes OS-Projekt hat einen Release-Koordinator, der vor einem Release noch bestimmt, was rein darf und was nicht.
Mit Patriarch meine ich aber jemanden wie einen Boss, dessen Entscheidungen als Untergebener man nicht öffentlich anzweifeln kann, was wiederum zu langwierigen Fehlentscheidungen führt.
Linus ist auch ein Entscheider, nur seine Entscheidungen werden öffentlich diskutiert und er will das auch so. Er will sich überzeugen lassen!
Ein gutes Beispiel dafür ist zb die MIN/MAX-Thematik. Linus hat was entschieden, es wurde diskutiert und eine bessere Lösung vorgeschlagen, die ihn überzeugt hat. Ich kann mir nur schwer vorstellen, daß dies bei einem "Boss" auch so gelaufen wäre.
>Auf jedenfall surren die ac-kernels bei mir wie
> ein Bienchen, derweilen die "offiziellen" von Linus öfter mal Probleme machten.
Das kann man vom 2.4.13 allerdings auch behaupten: Endlich mal keine Probleme...
Er swapt nicht nur nicht unnötig, sondern geht auch sonst sparsam mit dem Ram um. Ich hab mich schon gewundert, aber das wieder mal neue Speichermanagement ist eine Erklärung dafür.
Eine Spaltung des Projekts wird es sicher nicht lange geben, bisher sind noch alle Streitigkeiten wieder beigelegt worden.
Gruß,
/dev/null
ihr solltet auch moshes alten artikel lesen: http://www.byte.com/servinglinux/
was den fork angeht: nunja alan cox hat sich auch lange gegen reiserfs gestreubt - und der grund ist ja wohl kaum technisch zu erklären (suseredhat).
Ich persönlich bin von der neuen VM-Engine begeistert. Wo bei ich etwas eigenartig finde, dass der Kernel bei >=512 MB RAM scheinbar gar nicht mehr zu swappen beginnt...aber vielleicht ist die Kiste tatsächlich noch nicht genug ausgelastet.
Trotzdem: Egal welche VM - lasst den Kernel "ganz" und bitte nur _EINEN_ Linux-Kernel!
Wenn die Bibliotheken erst mal im RAM sind, ist das meiste ja schon gegessen. Da sollten 512 MB wirklich weit reichen.
Jochen
Aber das tun sie mit dem derzeitigen 2.4.12 definitiv nicht!
Bei 512MB RAM reicht es, den Rechner 1-2 Stunden stehen zu lassen, (ohne X und ähnlichem Gedöhns) und der Swap von 512MB ist definitiv zu 100% in Benutzung!
Dann ist der Kernel definitiv nicht für einen Server ausgelegt ... selbst für einen Client wird es da schon schwer vernünftig mit zu arbeiten.
Wenn ich mir den guten alten 2.2.16er auf meinem Server anschaue ... der läuft so was von sauber ... und das mit 128MB und swappt kaum, wenn er mal gefordert wird ...
B.
Jochen
Cronjobs ?!
hab ich was falsch gemacht..? Unser Webserver läuft jetzt seit 5 Tage mit 0 Swap... (kernel 2.4.12)
dito
ich hab' jetzt auch kein swap mehr
Mein Kernel 2.4.3 Mandrake swap nicht 128 MB sind zu wenig mit 256 MB keine Probleme.
Zur Zeit 164 MB belegt swap 0.
Ich kann das Swappen des 2.4.12 nicht bestätigen!
Ich habe 2.4.12-xfs 256 MB RAM 4 Std. uptime und die Sache sieht so aus:
2 eingeloggte User, X läuft, mehrere laufende Prozesse und kein einziges Byte vom Swap in Benutzung!
Liegts am XFS-Patch?
2.0.40pre, [...], 2.2.20pre, [...], 2.4.13ac, 2.4.14pre, 2.4.14pre-aa, 2.4.13-pre-vger, [2.5.x]
(RedHat-Tree), (SuSE-Tree), (Caldera-Tree)
Aber die branches werden staendig - mal in groesseren intervallen, mal in kleineren - gemerget.
Wenn mal in richtiger fork am entstehen war, dann war das der 2.1. vger tree.
Christoph
P.S. Moshe Bar ist ein _absoluter_ volltrottel der ueberall mitreden versucht ohne einen funken ahnung zu haben
sicher nicht... wahrscheinlich bist du einfach nur der volltrottel.
Seine Buecher / Artikel sind neben den mailinglist posting einer der Gruende warum ich so viel auf ihnen halte 8)
Vielleicht erwartet man als Hacker von docwritern einfach zuviel - andereseits sollten sie sich dann auch ausserhalb ihrer docs zurueckhalten..
Christoph
Mach Dich mal erst mal selber schlau, wer C.Hellwig ist und was er alles für den Kernel tut! Und dann meckern....*g*
cu Chris
RAS
Ich habe da ein Buch von C&L Verlag gesehen (FreeBSD), kennst du das. Kannst du das empfehelen?.
thx
RAS
Der FreeBSD Kernel hat ein sehr gutes und weithin anerkanntes VM-System das auch wirklich ausgereift ist. Du kannst die gleichen Applikationen wie unter Linux einsetzen. Der einzige nennenswerte Mangel für den Desktopeinsatz, der mir einfällt, ist die fehlende Unterstützung für 3d acceleration der NVIDIA Karten (andere, z.B.Matrox,ATI gehen aber).
Ich jedenfalls kann mit Linux auf dem
Desktop auch nicht mehr machen, als mit FreeBSD. Und in dem Fall bevorzuge ich FreeBSD deutlich ;-)
Welche Hardware unterstützt wird, kannst du den HardwareNotes für das letzte Release (z.B. auf www.freebsd.org) entnehmen.
Das Buch kann ich nicht beurteilen, habs kürzlich mal in einer Buchhandlung durchgeblättert und hatte den Eindruck, dass es ganz brauchbar ist. Wenn du schon schon etwas Linux-Erfahrung hast reicht dir aber wahrscheinlich das Handbuch, das mit FreeBSD kommt.
cya
Auf der LKML wurde schon einmal Diskutiert C++ für den Kernel einzusetzen was aber aus diversen Gründen (zumindest vorläufig) ad acta gelegt wurde. Näheres siehe in älteren Postings der LKML.
Hast du schon einmal probiert, mit BASIC direkt auf Hardware zuzugreifen ? Ich meine jetzt weder irgendwelche PEEKs und POKEs noch direkte Zugriffe auf den seriellen oder parallelen Port um etwas zu steuern, sondern direkt auf die im Rechner installierte Hardware zuzugreifen um z.B. einen Betriebssystemtreiber zu programmieren.
Zumindest mit den mir bis jetzt bekannten BASIC Programmiersprachen ist es nicht möglich etwas derartiges mit BASIC zu programmieren. Mit Microsofts .NET kann dies sich ändern, da dort dann der Quellcoder einer .NET-Fähigen Programmiersprache erst nach CIL übersetzt wird und dann von CIL in eine vom Betriebsystem ausführbare Datei umgesetzt wird. Theoretisch ist es mit .NET möglich Hardwaretreiber mit jeder erdenklichen .NET-fähigen Programmiersprache zu schreiben solange die dort verfügbaren Programmierkonstrukte alle notwendigen Aktionen erlauben. Dann könnte man selbst mit Smalltalk, Eiffel und Fortran seine Treiber schreiben. Ob dies in Wirklichkeit auch so vielfältig möglich ist, wird sich zeigen sobald der erste .NET Server vom Microsoft erhältlich ist. In irgendeinem Newsticker stand in dieser Woche, dass Bill Gates selbst die .NET Entwickler zu Geduld auffordert da .NET Server erst 2004 verfügbar sein werden. Soviel zum Thema Programmierung mit nicht-C.
War das OS vom Achimedes nicht in BASIC?
(man braucht assembler bzw. calls zu entsprechenden bibliotheken)
... mit dem Oberon-Zeugs hab ich mich wohl verraten. Ja ich studier an der denkwürdigen ETH. Aber ich schwöre mehr als ein paar Stunden hab ich an oberon nicht verbracht (ehrlich). Ich verschrieb mir eine Inter-Click-Dispenz
Wie oben schon erwähnt wär' es ein Leckerbissen für M$, wenn es plötzlich zwei Kernel Reihen gäbe. Ich erinnere mich da an eine Werbekampagne...
Ich finde Linus sollte sich auf die Entwicklerkernel konzentrieren, als Vordenker für die stable Reihen und Alan kümmert sich dann um diese. Dann würde nicht so viel Man-Power verloren gehen. Das wär effizienter. Und AC hat ja schon gezeigt, dass er mit Kerneln umgehen kann.
Aber ich glaube die Vernunft wird siegen.
Ein Fork ist bestimmt nicht im Sinne der Beiden. Das würd auch nur Verwirrung stiften bei vielen User, wenn man zwischen Linux-LT und Linux-AC unterscheiden müsste. Naja, es könnt auch einfach Cox heißen, das X ist ja schon da
Sagen wir, die eine Variante ist auf kleinen Maschinen deutlich überlegen, die andere auf dicken Servern (jetzt nur mal theoretisch). Es gibt kein Gesetz, daß es immer eine beste Lösung für alle Anwendungsfälle geben muß.
Sollte Linux sich der Windows-Lüge anschließen ("eine Lösung paßt überall, vom PDA bis zum Hochverfügbarkeitsserver")?
Oder sollte man (Variante zwei) in Kauf nehmen, daß ein abscheulicher Aufwand getrieben werden muß, um beide Varianten im selben Kernel als Optionen mitzuschleppen, selbst wenn dann etliche neue Erweiterungen beide Varianten berücksichtigen müssen?
Oder sollte man drittens in Kauf nehmen, daß Linus im 2.5er auf die eine Variante setzt, während Alan im 2.4er die andere weiterpflegt und den 2.6er gar nicht mehr mitmacht, bis eines Tages die ersten Treiber nur noch mit dem einen Kernelzweig laufen?
Ich mag mich für keine der Varianten entscheiden müssen (und bezweifle, daß das in diesem Fall nötig sein wird), aber es scheint mir eine nicht zu abwegige Grundsatzfrage zu sein, auf die man vorbereitet sein sollte.
Lohnt eine Diskussion?
Gruß, WinStop (Softwarephilosoph).
Aber das ist nicht das Problem zwischen den VMs.
Die eine ist von Anfang an komplex aufgebaut, um die schwierige Situation zu meistern, wenn der Speicher ausgegangen ist. Nachdem dies fertig ist, wird sie nun auf Performance getrimmt (Alan).
Die andere ist von Anfang an auf Performance getrimmt und nun wird sie auf die komplexe Situation weiterentwickelt, wenn der Speicher ausgegangen ist (Linus).
Beiden geht es nicht um die Perfektion, sondern nur darum welcher Weg der sinnvollere ist.
Alan gibt seinem Kernel mehr Zeit für Performance während Linus seinem mehr Zeit für die Komplexität gibt.
Unterm Strich sagen beide: Der entscheidende Punkt ist die Performance und nicht welchen Prozeß die VM nun genau killt, wenn der Speicher aus ist.
Zum Schluß wird die VM übrig bleiben, die im Schnitt 10% schneller ist und dabei kaum unterschiedliche Funktionalität aufweist.
Linux Kernel
und andererseits auf den
Coxnix Kernel
MS reibt sich schon die Hände, endlich Streit im Linux Lager.
...Ich kann hier bis jetzt keinen Streit erkennen, sondern lediglich eine Diskussion, die versucht, das Für und Wieder bzw. die Vor- und Nachteile der VM zu beleuchten.
Und genau DAS ist es, was die echten Anhänger und Programmierer der Open-Source auszeichnet: Diskussion. Abwägen. Konstruktiv kritisieren. Nach Lösungen suchen.
Und nicht so ein polemischer Kommentar wie von Dir.
Kein Gruß
J.
Eigentlich gehört der Kernel von einer kleinen Vollzeit-Crew komplett überarbeitet (siehe BSD)
Man muss ihnen aber Zeit lassen . Das VM-system von FreeBSD ist jedenfalls auch nicht über Nacht entstanden. John Dyson hat es in durchaus mühsamer und langwieriger Arbeit getuned und Flaschenhälse beseitigt.
Das Ergebnis ist ein exzellentes VM, das vor allem unter hoher Last seine Stärken ausspielen kann.
Bei Linux scheint halt nicht jeder die Geduld aufzubringen, die es braucht um so etwas zu produzieren.
Was mich allerdings etwas wundert ist, dass die Linux-Hacker trotz aller erdenklichen Möglichkeiten die ihnen die Grossindustrie zur Verfügung stellt (und die FreeBSD nie hatte) bisher nichts wirklich gutes in diesem Bereich zustande gebracht haben. Linux wird ja schliesslich auch nicht erst seit gestern entwickelt.
Resultat verletzter Eitelkeiten ist.
Da hat einer etwas geschrieben , das gut
ist , und dann kommt unverhofft ein Anderer,
der ' noch viel besser gemacht hat .
Der eine Schmollt nun , und die Anderen sind
z.Z. mit diser Situation recht Hilflos .