Habe auf einer Maschine bereits die Beta getestet, jetzt Update ich den Rest Allerdings sagen mir die Änderungen am Gnome 3.6 nicht so recht zu, 3.4 fand ich ja noch super, aber nun wirds auch mir langsam zu bunt ... habe mich allerdings schon so sehr an die "Arbeitsweise" gewöhnt, dass es jetzt wieder schwer wird zu wechseln.
Die haben Fedora 18 nicht wirklich als final released ? Da werden aber etliche User ein bitter böses Erwachen bekommen.
Das läuft momentan sowas von unrund und ist mit etlichen Fehlern behaftet. Ich selbst komme eigentlich mit dem bugreporten gar nicht mehr hinterher und habe auch langsam den Nerv dazu verloren, da immer wieder etwas neues kommt.
Na dann Mahlzeit. Wer nur des GNOME's willen updaten will, sollte besser bei Fedora 17 bleiben.
Anders betrachtet hat es sicherlich auch etwas gutes. Nun werden die Bugreports nur so reinströmen.
Jetzt ist Mitte Januar .... Ich erwarte, dass Fedora 18 erst März/April anfängt wirklich Spaß zu machen, wenn dann nach und nach etliches an Bugs gefixt wuden. Momentan rate ich jedem vor einem Upgrade oder Neuinstallation ab.
Lasst es! Wartet bis März/April oder nehmt erst eine virtuelle Maschine oder Testpartition.
Die haben das teil rausgehauen weil die nicht nochmal verschieben wollten. Ob die sich damit einen gefallen getan haben? Eher kaum! Die (Bug) Liste kann sich jedenfalls schon mal sehen lassen.
Du beziehst dich auf die Anaconda bugs. Ich beziehe mich hier auf generelle Funktionalität die einfach im gegenwärtigen Zustand (... und mit den Tools wie ich sie nutze) nur sehr eingeschränkt funktionieren.
- Evolution hängt sich mit "unknown processes" in der Statusleiste sehr oft auf. Das war mit Fedora 17 nicht der Fall. Sehr frustrierend. - Unmounten von einem externen XFS Dateisystem (Backup System) hat hier oftmals einen Kernel ooops ausgelöst (unterschiedliche Kernel). Seltenheitswert aber ärgerlich. - CUPS Ausdrucken von 1 physikalischen Seiten auf 3 Seiten DIN A4 und Drucker kann man nicht mehr ausschalten. Das wurde erst mit 1.5.4 bereits unter Fedora 17 eingeführt. Der Maintainer bekommt das nicht in den Griff und schiebt das auf das USB Subsystem von CUPS - Gestern bekam ich einen neuen 3.7er Kernel auf Fedora 18, der hat massive Probleme Prozesse zu spawnen - Zugriff mittels Nautilus auf mein iPhone. Der Thumbnailer hängt sich oft auf und Icons werden nicht richtig getumbnailed. Versuch mal ein iPhone mittels Auswurf auszuwerfen. Da kommt permanent ein schwarzer Dialog hoch, der mitteilt, dass das iPhone nicht ausgehängt werden kann, weil ein Prozess noch läuft (obwohl tot). Nimmst du das iPhone dann dennoch ab, stürzt Nautilus ab. Nimmst du das nicht ab, dann bekommste diesen Dialog permanent. - Switchen von X nach Console und back nach X stürzt Xorg ab (Radeon). - Oftmaliges Einloggen in Gnome-Shell zerhaut den Desktop. Font Elemente fehlen, Background wird in kleinen Würfeln angezeigt (memoryleak). Das kanns man nur fixen, wenn man externen Monitor mit dem Monitor tool ausschaltet und nochmals den Background (Wallpaper) selektiert. Dann aus und wieder einloggen. - gnome-shell stürzt hin und wieder ab - gnome-shell Seitenleiste nach dem Hochfahren immer sehr klein 16x16 Icons. Erst nachdem man etwas darauf selektiert hat und gestartet wurde, taucht die normale Größe auf. Das war unter Fedora 17 noch nicht. - Hin und wieder crashen irgendwelche Programme im Hintergrund. Meist Nautilus, Gnome-Shell. - Gnome-Network-Manager. Mobile Broadband einfach mal ausschalten, nachdem es eingeschaltet war. Man kann es nicht wieder einschalten. Du musst hier immer den USB Stick abklemmen und wieder drannklemmen, dann geht's. - Gnome-Terminal geht nun immer in maximum Modus nachdem man auf ein anderes Fenster geklickt hat (Bei mir sieht das wie folgt aus, von GNOME-Terminal auf z.b. Chrome oder LibreOffice. Das war mit Fedora 17 noch nicht.
Das hier ist nur eine kleinere Auswahl. Keine besondere Reihenfolge. Kaum hat man das Eine oder Andere davon gemeldet, tauchen schon wieder neue Probleme auf.
Mit Fedora 16 und 17 war ich im allgemeinen zufrieden, bis der Depp von CUPS anfing immer neue fehlerbehaftete Versionen hochzufahren. Das brachte mich dazu auf Fedora 18 zu wechseln, da sind aber die Probleme bedeutend größer.
Nochmals, ich will hier niemanden meine Ansicht von Fedora 18 aufzwingen. Das bleibt jedem selbst überlassen und ist auch eine subjektive Ansicht. Liegt teilweise vieleicht auch an der Hardware, den genutzten Treibern usw. Das mag bei dem Einen gut gehen, beim Anderen nicht. Ich akzeptiere auch die Ansicht, dass Fedora 18 bei denen gut läuft. Nur momentan ist das Nutzererlebnis auf meiner Seite eher mau.
Also wenn es derart übel zugeht, würde ich einen anderen Desktop probieren. Eventuell könnte man noch die Grafikkarte wechseln aber hinnehmen kann man so viele derartige Probleme nicht mehr.
1-2 aus der Liste würde schon noch gehen aber gerade Sachen, bei denen Daten verloren gehen können, dürfen maximal als absolute Ausnahme auftauchen....
Richtig! Nun! Fehler kommen überall vor. Das ist natürlich und sollten dann iterativ gefixt werden. Jedoch was wir hier haben ist kein Final taugliches Fedora. Daher halt auch meine Eingangskritik.
Diese Art von Fehlern sind eher einer Alpha bzw. Beta Version von Fedora zuzuordnen. Damit hätte man als Nutzer eine symbolische Linie, welche hinweist, dass das System instabil ist.
Aber eine finale Fedora 18 mit diesen Fehlern -> in der Art -> ist einfach größenwahnsinnig. Oder das Releaseteam wollte kein BER aus Fedora 18 machen.
Schau dir mal den KernelOOOPS unten an. Das geht nicht. Gegenüber Fedora 16 und 17 ist das hier bei Weitem ein Gefälle.
Also das CUPS fehlerhaft arbeitet kann ich nicht nachvollziehen (gerade mal getestet und einen Seite Ausgedruckt und alles funktioniert problemlos; evtl. Treiber/Geräteabhängig?) Mit den proprietären Treibern von nVidia funktioniert auch das switchen zwischen Konsole und Desktop absolut normal. Und 3.7.2-201.fc18.x86_64 macht hier auch keine deiner genannten Probleme.
Die anderen Gnome-Probleme kann ich jetzt nicht nachgehen, da ich Kde nutze.
Mach eine Bash im Terminal auf und spiel damit herum.
Midnightcommander, Sed, Grep, AWK usw.
Am Besten du öffnest nebenbei noch einige Anwendungen.
Bei mir trat das Phänomen auf, als ich mittels Freemind versuchte einige Mindmaps zu erstellen und dort etliche Nodes und Subnodes einfügte. Irgendwann teilte mir Bash dann mit, dass es keine Prozesse mehr aufmachen kann.
Ich konnte dann auch keine Anwendungen mehr aus Gnome-Shell starten, Das System war quasi am Anhalten und fuhr dann nach einiger Zeit wieder fort.
Erst als ich Freemind wieder dichtmachte (... und merke, damit auch Java wieder dichtmachte, ging es wieder.
Erst als ich mittels yum einen älteren Kernel installierte, war alles wieder ok.
Ich ordne das dem 201'er patch des 3.7'ers zu. Da hat wohl sicherlich jemand im Prozessmanager herumgeeiert. Das machte sich fatal hier auf dem System bemerkbar.
Jetzt mit dem alten Kernel läuft alles so wie bisher.
Hab jetzt einfach mal Qt5 compilen lassen mit make -j 30 (was mir genügend Prozesse in kurzer Zeit spawnt) und parallel einen grep auf eine ziemlich große Datei laufen lassen und alles läuft so wie es soll. (WebBrowser, Amarok und andere Anwendungen laufen auch im Hintergrund).
Ich kanns noch mit Freemind probieren aber ich glaube kaum das dann mein System hier zum genannten Fehler bringen wird.
Ausprobieren. Ich bekomme immer folgende Meldungen.
fork() == -1
In der Bash angezeigt. Was allerdings eine Theorie sein könnte ist, dass jedes Element in Freemind einen eigenen Prozess antriggert. Bei knapp 3000 Nodes könnte ein Limit der ausführbaren Prozesse angeregt werden.
Ich muss das hier weiter beobachten. Interessant nur, dass ich das Problem seit downgraden des Kernels nicht mehr habe.
Auch bekomme ich in der Gnome-Shell das auch mitgeteilt, dass keine Prozesse mehr aufgemacht werden können. Das Gleiche passiert auch wenn ich Apps einfach so starten will.
Probier halt einfach weiter. Solltest du dann doch das Problem bekommen, dann weißt zu zumindest, woran das liegt.
Doch doch! Google hat das Problem bereits bestätigt. Scheint nicht unbedingt ein Problem des betreffenden Kernels zu sein. Auch hier tauchte das mit dem alten Kernel auf. Hab gerade nochmals herumexperimentiert.
-bash: fork: retry: No child processes -bash: fork: retry: No child processes -bash: fork: retry: No child processes
getconf CHILD_MAX
Es sind also kurzweilig mehr als 1024 Prozesse aufgemacht worden.
Google mal nach "fork: retry: No child processes" mal schauen, was ulimit ausrichten kann. Wozu brauche ich dann ein Freemind, wenn es nach 1024 Prozessen schlapp macht.
Also wie schon geschrieben Freemind will einfach nicht dieses Verhalten reproduzieren. Ich hab aber auch absolut keinen Ahnung warum gerade bei dir das passiert. (Der Fehler deutet darauf hin, das Freemind mehrere Prozesse spawnt) Hast du evtl. direkt mal ein Beispiel für Freemind welches das Verhalten reproduzierbar macht? (Ich habe mehrere Nodes erstellt und dies dann wieder und wieder kopiert und aneinander gefügt).
Probier evtl. mal in einer VM F18 mit Freemind laufen zu lassen, wenn es auch dort das gleiche Verhalten zeigt, dann dürfte es auf jeden Fall ein Bug sein.
Und versuche damit mal zu arbeiten. Mein mindmap hat zuviele persnöliche Einträge, so dass ich das hier sicherlich nicht posten werde. Aber das ist wirklich Prozessbedingt.
Da das Problem akut ist, muss ich es ohnehin für mich persönlich hier auf dem System lösen.
Wirklich ärgerlich ist, dass in Fedora-Releases regelmäßig ganz grundlegende Funktionen zerschossen werden. In Fedora 18 betrifft es, wie schon in Fedora 16, mal wieder die GNOME Google Online Accounts. Seinerzeit konnten im Kalender keine Änderungen vorgenommen werden, dieses Mal funktioniert die two-step authentication nicht mehr. Solche Bugs mögen in einer Beta-Version vertsändlich sein, aber im Release gefährdet es schlichtweg, dass User die Distribution nutzen.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 16. Jan 2013 um 18:18.
Eventuell solltest du bei einer derart hohen Menge seltsamer und schwer zu reproduzierender Fehler mal deine Hardware überprüfen, oder deine Systempartition löschen und Fedora komplett neu installieren.
Danke für deine Tipps. Bei soviel Mutmaßungen, weiss ich leider nicht, wo ich anfangen soll. Wenn wir die Kausalkette weiter zurückverfolgen, könnten wir dies festhalten.
Wäre der Urknall nie passiert, die Evolution nie entstanden und Computer nie gebaut. Dann hätte ich all diese Probleme mit Fedora 18 nicht.
Spaß beiseite. Die Hardware als auch der Rest des Systems ist wunderbar. Vieleicht hattest du nur den Part überlesen, aus dem hervorgeht, dass das System erstklassig mit Fedora 16 und Fedora 17 funktioniert.
Könnte demnach sicherlich auch einfach nur ein aus der Eile herausgetriebenes Release mit Namen Fedora 18 handeln ? 2 Monate overtime kommt ja nicht von irgendwo.
Noch nie so einen Wust an Fehlermeldungen gesehen. Wie schon erwähnt, lässt es auf fehlerhafte Hardware u./o. eine vollkommen zerschossene Installation schliessen.
Warum auch immer ... (Meine wirklichen Vermutungen erspare ich dir/uns.)
Das ist ein Kernel oops.... Da braucht es keine zerschossene Installation um diesen auszulösen...
Bei RedHat hat wieder einer so viele ungetestete Zwischenpatches rückportiert ohne diese zu testen.
Egal wie auch immer ein System zerschossen ist. Eines sollte definitiv nicht passieren.... Das der Kernel oops'ed.
Das hier ist ein kernelseitiger Fehler und kein userland Fehler.
IdR springt der Kernel nach dem Bootloader in den 32 bit protected mode und läuft die ganze Zeit über im Ring 0 (Supervisor state), während die Userland Sachen im Ring 3 laufen.
Dem Kernel (Ring 0) ist es vollkommen wurscht, wie zerschossen dein System ansonsten (Ring 3) ist. Der Kernel sollte rock stable bleiben.
Wenn jedoch so eine Scheisse wie gvfsd und sellinux (Ring 3) den Kernel (Ring 0) zum Absturz bringen, na dann prost Mahlzeit.
Meine wirklichen Vermutungen erspare ich mir auch. Halt zuviel Alpha gefrickel. Es sollten halt nur Leute Dinge maintainen, die wirklich wissen, was sie da tun.
so ist Fedora, Bleeding Edge. Zwischen ganz brauchbaren sind dann die etwas böseren Ausgaben. Irgendwann muessen die eben ihre 18 drauf schreiben, sonnst kommt nie eine 19, ist ja nur eine Distro und kein Flughafen.
es ist wohl eher so das die weniger versierten User einer Distribution wie Fedora (rpm basiert) einen Bug melden wo keiner ist. Man kann ihnen eigentlich nur den Vorwurf machen, sich nhicht vorher über die Tücken dieser nicht für den produktiven Einsatz gedachten informiert zu haben.
Ich hab die FC18 seit der ersten offiziellen Alpha Version im Einsatz und bin mehr als zufrieden. Die Bugs die ich gemeldet habe, wurden gefixt, wo ist das Problem ?
Wenn die 18 wirklich die Basis für RHEL 7 ist, dann ist alles gut.
Von Acader (VIP) am Mi, 16. Januar 2013 um 05:50 #
Sicher eignet sich Fedora welches eine sehr gute Distribution ist für den Linux-Anfänger. danach stößt man aber an eine Grenzen wenn es um das produktive Arbeiten sich handelt.
Meine Empfehlung ist daher zu Ubuntu oder einer anderen debianischen Distribution zu greifen welche mit apt arbeiten und nicht mit dem langsamen yum. Hilfe gibt es unter anderem auch in den ubuntu-Wikis welche sehr gut sind.
Debianische Linuxdistributionen sind von der standartisierten LSB Laufzeitumgebung her sowie von der Stabilität sehr zu empfehlen. Aber jeder wie er will.
Also eigentlich ist RPM das std-format von LSB Zur stabilität...da können wohl wenige einem RHEL was vormachen, aber auf dem Desktop würde ich auch Debian od Ubuntu oder ArchLinux empfehlen..ganz einfach grössere softwareauswahl und auf dem Desktop der defakto standard (ausnahme arch). Aber die begründungen vom vorredner sind schlichtweg falsch.
Keine Ahnung, was Poetterkits sind, aber um die Software von Lennart wirst du wohl kaum herumkommen ^^ Software aufgrund eines Maintainers abzulehnen ist auch ein wenig seltsam... Technisch gesehen sind PulseAudio, Avahi und systemd einwandfrei, Kritiken kann man höchstens an a) Dem Konzept, was einem nicht zusagt, oder b) an der Umstellung von "alten" Technologien anbringen. Da viele der Projekte relativ invasive Änderungen mitbringen gibt es in der Übergangsphase natürlich Probleme, auf lange sicht bringen diese Projekte allerdings erhebliche Verbesserungen. So ist z.B. ein Nebeneffekt von systemd, dass ConsoleKit komplett obsolet geworden ist (kümmert sich jetzt logind drum), was die Stabilität verbessert und z.B. echtes Multiseating erlaubt. Auch einige andere nette Funktionen sind möglich. Klar, der Übergang nervt eventuell, da man sich umgewöhnen muss, aber diese Projekte sind langfristig gedacht.
Ich denke, dass diese Projekte eher kurzfristig und nur für Zwecke eines Linux Systems "gedacht" wurden. Mehr nicht. Die ganze Komplexität dieser Geschichte ist noch gar nicht abzusehen.
Von Traditionalist am Mi, 16. Januar 2013 um 15:57 #
Die Poetterkits und freedesktop.org widersprechen jeglicher Unix-Philospohie. Früher galt einfache Konfigurierbarkeit in einfachen Textdateien als oberstes Ziel. Es wäre besser, die Poetterkits als PSD (Poettering-Software-Distribution) unter die Leute zu bringen, oder gleich als LSD ...
Von TraditionGehoertAbgeschafft am Mi, 16. Januar 2013 um 18:29 #
Übrigens: Ich empfehle jedem das Unix-Hater-Handbook. Wenn du behauptest, Textkonfigurationen seien das Größte, solltest du erstmal den XServer einrichten.
> Gerade das ist doch ein wesentlicher > Bestandteil etwa von systemd.
Nein, hier ist die Kernaussage nicht verstanden worden. Es mag sein, dass man systemd Textdateien bearbeiten kann. Jedoch meint der ursprängliche Autor eher auch das System als solches.
systemd ist alles andere als "einfach". Im Gegenteil, systemd ist absolut komplex und nicht einfach zu verstehen. Es ist meiner Ansicht nach sogar wesentlich komplizierter als das Services System welches unter Windows läuft.
Schau dir mal das "sc" ähnliche Tool für systemd an und du kotzt voll ab. Das ist halt das, was hier wohl eher gemeint ist.
systemctl | cat
Gib das mal in deiner Console oder Bash ein, dann kotzt du schon.
Mit init war die Sache einfach und darauf zielt die Aussage des Erstschreibers auch ab.
init hat ganz easy rcS gestartet, je nach dem, welchen Runnlevel du mitgeteilt hattest hat es dann die jeweiligen Scripte im rc.x Verzeichnis ausgeführt.
Ganz easy, mehr nicht. rcS als eine art Startup-Sequence... Selbst das reichte schon aus, um ein Linux System vollständig zu booten. Man braucht demnach nicht einmal die Runnlevel.
Im Gegenteil: systemd ist sehr einfach bedienbar. Während es früher ein Pain war, einen neuen Service mit sysvinit zu erstellen, reicht heute mit systemd eine einfache deklarative Textdatei aus 2-5 Zeilen. Die alten init-Scripte waren ein extrem komplexes Wirrwar aus Spaghetti-Code und Race-Conditions.
> Ganz easy, mehr nicht. rcS als eine art Startup-Sequence
Die heutige Welt ist nicht mehr sequenziell. Ressourcen können jederzeit erscheinen und wieder verschwinden, Geräte rein- und rausgesteckt werden (Hotplugging).
Die Begrifflichkeit "startup-sequence" stammt noch aus alten Amiga Tagen. Natürlich kannst du in solch einem "einfachen" Textfile auch parallele Prozesse laufen lassen. rcS ist dazu natürlich auch in der Lage.
> Ressourcen können jederzeit erscheinen und > wieder verschwinden, Geräte rein- und > rausgesteckt werden (Hotplugging).
Richtig richtig. Nur ist das aber kein Anliegen eines systemd (... den ich immer noch als init betrachte).
Ein vernünftiges Hotplugging sollte Kernelseitig implementiert werden, sobald neue Hardware per Hotplug hinzuommt, sollte der Kernel die richtigen Treiber mit den richtigen Parametern laden. Wahlweise sollten Parameter über eine elegante GUI konfigurierbar sein (Lautstäre, DIN A4, usw....).
Das das alles nicht sonderlich richtig funktioniert mit systemd lernen wir ja mit einem externen WIFI Stick. Sobald Fedora hochfährt ist noch alles ok.... schaltet man dann aber das WIFI mittels dem GNOME-Network-Manager auf OFF dann wars das, man kann es nicht mehr einschalten und muss den Stick entfernen und neu einstecken.
Man glaubt zu wissen man gehe den richtigen Weg, nur ist dieser Weg leider nicht richtig. Das Problem ist zwar als solches erkannt worden, sollte aber auf anderer Ebene gelöst werden.
Aber was schreibe ich, in zwei Jahren spricht eh keiner mehr über das veraltete systemd, weil ein GNOME Entwickler wieder eine neue Lösung noch besser implementiert hat (... welche dann zwei Jahre später wieder als die Schlechte wahrgenommen wurde).
Auch mit GNOME 3 wollte man ja so viel richtig machen, nur schreien die Spatzen es gerade von den Dächern. So zerhaun wie GNOME 3 in der öffentlichkeit Wahrgenommen wird...
Die Begrifflichkeit "startup-sequence" stammt noch aus alten Amiga Tagen. Natürlich kannst du in solch einem "einfachen" Textfile auch parallele Prozesse laufen lassen. rcS ist dazu natürlich auch in der Lage.
Nur müssen nebenläufige Prozesse miteinander zur Synchronisation kommunizieren. Und "sleep" ist da eben keine brauchbare Lösung.
kein Anliegen eines systemd (... den ich immer noch als init betrachte)
Systemd ist ein Service-Manager. Als was du es betrachtest spielt für die Realität keine Rolle.
Ein vernünftiges Hotplugging sollte Kernelseitig implementiert werden, sobald neue Hardware per Hotplug hinzuommt, sollte der Kernel die richtigen Treiber mit den richtigen Parametern laden.
Neu hinzugekommene Harddisks müssen mit fsck geprüft werden, Filesysteme gemountet werden etc.
wieder eine neue Lösung noch besser implementiert hat (... welche dann zwei Jahre später wieder als die Schlechte wahrgenommen wurde).
Nennt sich Fortschritt. Es wird immer irgendwann etwas Besseres geben.
Werde extra eine Neuinstallation machen statt Update, um den neuen Installer mal gesehen zu haben.
Das kannst du auch in einer VM machen...
Habe auf einer Maschine bereits die Beta getestet, jetzt Update ich den Rest
Allerdings sagen mir die Änderungen am Gnome 3.6 nicht so recht zu, 3.4 fand ich ja noch super, aber nun wirds auch mir langsam zu bunt ... habe mich allerdings schon so sehr an die "Arbeitsweise" gewöhnt, dass es jetzt wieder schwer wird zu wechseln.
Wenn es zu ungewohnt ist, dann nimm halt was anderes. Fedora bietet ja alle Desktops.
Du hast mich falsch verstanden ... der Wechsel *von* Gnome *zu* etwas anderem würde mir schwer fallen.
Aso!
Um Gottes willen ????
Die haben Fedora 18 nicht wirklich als final released ? Da werden aber etliche User ein bitter böses Erwachen bekommen.
Das läuft momentan sowas von unrund und ist mit etlichen Fehlern behaftet. Ich selbst komme eigentlich mit dem bugreporten gar nicht mehr hinterher und habe auch langsam den Nerv dazu verloren, da immer wieder etwas neues kommt.
Na dann Mahlzeit. Wer nur des GNOME's willen updaten will, sollte besser bei Fedora 17 bleiben.
Anders betrachtet hat es sicherlich auch etwas gutes. Nun werden die Bugreports nur so reinströmen.
Jetzt ist Mitte Januar .... Ich erwarte, dass Fedora 18 erst März/April anfängt wirklich Spaß zu machen, wenn dann nach und nach etliches an Bugs gefixt wuden. Momentan rate ich jedem vor einem Upgrade oder Neuinstallation ab.
Lasst es! Wartet bis März/April oder nehmt erst eine virtuelle Maschine oder Testpartition.
Altes Backup von Fedora 17 aufheben.
Die haben das teil rausgehauen weil die nicht nochmal verschieben wollten. Ob die sich damit einen gefallen getan haben? Eher kaum! Die (Bug) Liste kann sich jedenfalls schon mal sehen lassen.
Du beziehst dich auf die Anaconda bugs. Ich beziehe mich hier auf generelle Funktionalität die einfach im gegenwärtigen Zustand (... und mit den Tools wie ich sie nutze) nur sehr eingeschränkt funktionieren.
Kannst Du kurz die 2-3 wichtigsten Probleme anreißen?
Ja
- Evolution hängt sich mit "unknown processes" in der Statusleiste sehr oft auf. Das war mit Fedora 17 nicht der Fall. Sehr frustrierend.
- Unmounten von einem externen XFS Dateisystem (Backup System) hat hier oftmals einen Kernel ooops ausgelöst (unterschiedliche Kernel). Seltenheitswert aber ärgerlich.
- CUPS Ausdrucken von 1 physikalischen Seiten auf 3 Seiten DIN A4 und Drucker kann man nicht mehr ausschalten. Das wurde erst mit 1.5.4 bereits unter Fedora 17 eingeführt. Der Maintainer bekommt das nicht in den Griff und schiebt das auf das USB Subsystem von CUPS
- Gestern bekam ich einen neuen 3.7er Kernel auf Fedora 18, der hat massive Probleme Prozesse zu spawnen
- Zugriff mittels Nautilus auf mein iPhone. Der Thumbnailer hängt sich oft auf und Icons werden nicht richtig getumbnailed. Versuch mal ein iPhone mittels Auswurf auszuwerfen. Da kommt permanent ein schwarzer Dialog hoch, der mitteilt, dass das iPhone nicht ausgehängt werden kann, weil ein Prozess noch läuft (obwohl tot). Nimmst du das iPhone dann dennoch ab, stürzt Nautilus ab. Nimmst du das nicht ab, dann bekommste diesen Dialog permanent.
- Switchen von X nach Console und back nach X stürzt Xorg ab (Radeon).
- Oftmaliges Einloggen in Gnome-Shell zerhaut den Desktop. Font Elemente fehlen, Background wird in kleinen Würfeln angezeigt (memoryleak).
Das kanns man nur fixen, wenn man externen Monitor mit dem Monitor tool ausschaltet und nochmals den Background (Wallpaper) selektiert. Dann aus und wieder einloggen.
- gnome-shell stürzt hin und wieder ab
- gnome-shell Seitenleiste nach dem Hochfahren immer sehr klein 16x16 Icons. Erst nachdem man etwas darauf selektiert hat und gestartet wurde, taucht die normale Größe auf. Das war unter Fedora 17 noch nicht.
- Hin und wieder crashen irgendwelche Programme im Hintergrund. Meist Nautilus, Gnome-Shell.
- Gnome-Network-Manager. Mobile Broadband einfach mal ausschalten, nachdem es eingeschaltet war. Man kann es nicht wieder einschalten. Du musst hier immer den USB Stick abklemmen und wieder drannklemmen, dann geht's.
- Gnome-Terminal geht nun immer in maximum Modus nachdem man auf ein anderes Fenster geklickt hat (Bei mir sieht das wie folgt aus, von GNOME-Terminal auf z.b. Chrome oder LibreOffice. Das war mit Fedora 17 noch nicht.
Das hier ist nur eine kleinere Auswahl. Keine besondere Reihenfolge. Kaum hat man das Eine oder Andere davon gemeldet, tauchen schon wieder neue Probleme auf.
Mit Fedora 16 und 17 war ich im allgemeinen zufrieden, bis der Depp von CUPS anfing immer neue fehlerbehaftete Versionen hochzufahren. Das brachte mich dazu auf Fedora 18 zu wechseln, da sind aber die Probleme bedeutend größer.
Nochmals, ich will hier niemanden meine Ansicht von Fedora 18 aufzwingen. Das bleibt jedem selbst überlassen und ist auch eine subjektive Ansicht. Liegt teilweise vieleicht auch an der Hardware, den genutzten Treibern usw. Das mag bei dem Einen gut gehen, beim Anderen nicht. Ich akzeptiere auch die Ansicht, dass Fedora 18 bei denen gut läuft. Nur momentan ist das Nutzererlebnis auf meiner Seite eher mau.
Also wenn es derart übel zugeht, würde ich einen anderen Desktop probieren. Eventuell könnte man noch die Grafikkarte wechseln aber hinnehmen kann man so viele derartige Probleme nicht mehr.
1-2 aus der Liste würde schon noch gehen aber gerade Sachen, bei denen Daten verloren gehen können, dürfen maximal als absolute Ausnahme auftauchen....
Richtig! Nun! Fehler kommen überall vor. Das ist natürlich und sollten dann iterativ gefixt werden. Jedoch was wir hier haben ist kein Final taugliches Fedora. Daher halt auch meine Eingangskritik.
Diese Art von Fehlern sind eher einer Alpha bzw. Beta Version von Fedora zuzuordnen. Damit hätte man als Nutzer eine symbolische Linie, welche hinweist, dass das System instabil ist.
Aber eine finale Fedora 18 mit diesen Fehlern -> in der Art -> ist einfach größenwahnsinnig. Oder das Releaseteam wollte kein BER aus Fedora 18 machen.
Schau dir mal den KernelOOOPS unten an. Das geht nicht. Gegenüber Fedora 16 und 17 ist das hier bei Weitem ein Gefälle.
Also das CUPS fehlerhaft arbeitet kann ich nicht nachvollziehen (gerade mal getestet und einen Seite Ausgedruckt und alles funktioniert problemlos; evtl. Treiber/Geräteabhängig?)
Mit den proprietären Treibern von nVidia funktioniert auch das switchen zwischen Konsole und Desktop absolut normal.
Und 3.7.2-201.fc18.x86_64 macht hier auch keine deiner genannten Probleme.
Die anderen Gnome-Probleme kann ich jetzt nicht nachgehen, da ich Kde nutze.
> 3.7.2-201.fc18.x86_64
Mach eine Bash im Terminal auf und spiel damit herum.
Midnightcommander, Sed, Grep, AWK usw.
Am Besten du öffnest nebenbei noch einige Anwendungen.
Bei mir trat das Phänomen auf, als ich mittels Freemind versuchte einige Mindmaps zu erstellen und dort etliche Nodes und Subnodes einfügte. Irgendwann teilte mir Bash dann mit, dass es keine Prozesse mehr aufmachen kann.
Ich konnte dann auch keine Anwendungen mehr aus Gnome-Shell starten, Das System war quasi am Anhalten und fuhr dann nach einiger Zeit wieder fort.
Erst als ich Freemind wieder dichtmachte (... und merke, damit auch Java wieder dichtmachte, ging es wieder.
Erst als ich mittels yum einen älteren Kernel installierte, war alles wieder ok.
Ich ordne das dem 201'er patch des 3.7'ers zu. Da hat wohl sicherlich jemand im Prozessmanager herumgeeiert. Das machte sich fatal hier auf dem System bemerkbar.
Jetzt mit dem alten Kernel läuft alles so wie bisher.
Hab jetzt einfach mal Qt5 compilen lassen mit make -j 30 (was mir genügend Prozesse in kurzer Zeit spawnt) und parallel einen grep auf eine ziemlich große Datei laufen lassen und alles läuft so wie es soll. (WebBrowser, Amarok und andere Anwendungen laufen auch im Hintergrund).
Ich kanns noch mit Freemind probieren aber ich glaube kaum das dann mein System hier zum genannten Fehler bringen wird.
Ausprobieren. Ich bekomme immer folgende Meldungen.
fork() == -1
In der Bash angezeigt. Was allerdings eine Theorie sein könnte ist, dass jedes Element in Freemind einen eigenen Prozess antriggert. Bei knapp 3000 Nodes könnte ein Limit der ausführbaren Prozesse angeregt werden.
Ich muss das hier weiter beobachten. Interessant nur, dass ich das Problem seit downgraden des Kernels nicht mehr habe.
Auch bekomme ich in der Gnome-Shell das auch mitgeteilt, dass keine Prozesse mehr aufgemacht werden können. Das Gleiche passiert auch wenn ich Apps einfach so starten will.
Probier halt einfach weiter. Solltest du dann doch das Problem bekommen, dann weißt zu zumindest, woran das liegt.
Edit:
Auch Freemind macht nichts weiter. (Nutzte jedoch die Java Runtime Env von Oracle)
Doch doch! Google hat das Problem bereits bestätigt. Scheint nicht unbedingt ein Problem des betreffenden Kernels zu sein. Auch hier tauchte das mit dem alten Kernel auf. Hab gerade nochmals herumexperimentiert.
-bash: fork: retry: No child processes
-bash: fork: retry: No child processes
-bash: fork: retry: No child processes
getconf CHILD_MAX
Es sind also kurzweilig mehr als 1024 Prozesse aufgemacht worden.
Google mal nach "fork: retry: No child processes" mal schauen, was ulimit ausrichten kann. Wozu brauche ich dann ein Freemind, wenn es nach 1024 Prozessen schlapp macht.
Also wie schon geschrieben Freemind will einfach nicht dieses Verhalten reproduzieren. Ich hab aber auch absolut keinen Ahnung warum gerade bei dir das passiert. (Der Fehler deutet darauf hin, das Freemind mehrere Prozesse spawnt)
Hast du evtl. direkt mal ein Beispiel für Freemind welches das Verhalten reproduzierbar macht? (Ich habe mehrere Nodes erstellt und dies dann wieder und wieder kopiert und aneinander gefügt).
Probier evtl. mal in einer VM F18 mit Freemind laufen zu lassen, wenn es auch dort das gleiche Verhalten zeigt, dann dürfte es auf jeden Fall ein Bug sein.
Gib in einer bash mal folgendes aus Spaß ein
ulimit -u 0
oder
ulimit -u 5
Und versuche damit mal zu arbeiten. Mein mindmap hat zuviele persnöliche Einträge, so dass ich das hier sicherlich nicht posten werde. Aber das ist wirklich Prozessbedingt.
Da das Problem akut ist, muss ich es ohnehin für mich persönlich hier auf dem System lösen.
So, neue Erkenntnisse:
Die Fedora Maintainer haben die maximalen user Processe auf 1024 limitiert.
ulimit - u 4096, ist das maximale was man als User setzen kann. Mehr geht nicht.
Erst als ich als root ein ulimit -u 8192 und höher setzte und als root dann java aufrief, lief alles wie es sollte.
while [ 1 ] ; do sleep 2 ; ps uH p `pidof java` | wc -l ; done
einfach das o.g. script in der bash laufen lassen. Es zeigt an, wieviele tatsächlichen Threads java gerade aufmachen möchte.
Entweder ist das Java Programm buggy, oder Fedora ist für Java Entwickler ungeeignet.
Wirklich ärgerlich ist, dass in Fedora-Releases regelmäßig ganz grundlegende Funktionen zerschossen werden. In Fedora 18 betrifft es, wie schon in Fedora 16, mal wieder die GNOME Google Online Accounts. Seinerzeit konnten im Kalender keine Änderungen vorgenommen werden, dieses Mal funktioniert die two-step authentication nicht mehr.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 16. Jan 2013 um 18:18.Solche Bugs mögen in einer Beta-Version vertsändlich sein, aber im Release gefährdet es schlichtweg, dass User die Distribution nutzen.
Wenn so ein Fehler dein ganzes Backup trasht (also gvfsd), dann Mahlzeit. Aufgetreten am 14.01.2013 Fedora 18
VFS: Busy inodes after unmount of fuse. Self-destruct in 5 seconds. Have a nice day...
BUG: unable to handle kernel NULL pointer dereference at 00000034
IP: [ ] _raw_spin_lock+0xd/0x30
*pde = 00000000
Oops: 0002 [#1] SMP
Modules linked in: xfs dm_crypt fuse ebtable_nat xt_CHECKSUM ipt_MASQUERADE ....
Pid: 17180, comm: gvfsd-trash Not tainted 3.x.x-x.fc18.i686 #1 LENOVO xxxxxxx/xxxxxxx
EIP: 0060:[ ] EFLAGS: 00010286 CPU: 1
EIP is at _raw_spin_lock+0xd/0x30
EAX: 00000034 EBX: efd85a50 ECX: 00000003 EDX: 00000100
ESI: efd85a54 EDI: efd2c000 EBP: eff8bf10 ESP: eff8bf10
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
CR0: 80050033 CR2: 00000034 CR3: 2f7bb000 CR4: 000007d0
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400
Process gvfsd-trash (pid: 17180, ti=eff8a000 task=eff01920 task.ti=eff8a000)
Stack:
eff8bf28 c06211fd 00000000 efd2c000 efd2c09c f876c560 eff8bf30 c061d0d4
eff8bf3c c055daaf efd2c000 eff8bf48 c055db70 efd2c000 eff8bf5c c055dc72
efd2c000 efd2c054 efc11c00 eff8bf74 c055e261 ef55b540 f3d0a5a0 ef55b540
Call Trace:
[ ] selinux_inode_free_security+0x2d/0x70
[ ] security_inode_free+0x14/0x20
[ ] __destroy_inode+0x1f/0xc0
[ ] destroy_inode+0x20/0x50
[ ] evict+0xd2/0x150
[ ] iput+0xc1/0x140
[ ] fsnotify_destroy_mark+0x117/0x120
[ ] sys_inotify_rm_watch+0x5a/0x90
[ ] sysenter_do_call+0x12/0x28
Code: ff ff ff ff 89 e5 ba 01 00 00 00 e8 ee fe ff ff 5d c3 90 90 90 90 90 90 ....
EIP: [ ] _raw_spin_lock+0xd/0x30 SS:ESP 0068:eff8bf10
CR2: 0000000000000034
---[ end trace 8079874ae18c4783 ]---
Eventuell solltest du bei einer derart hohen Menge seltsamer und schwer zu reproduzierender Fehler mal deine Hardware überprüfen, oder deine Systempartition löschen und Fedora komplett neu installieren.
Danke für deine Tipps. Bei soviel Mutmaßungen, weiss ich leider nicht, wo ich anfangen soll. Wenn wir die Kausalkette weiter zurückverfolgen, könnten wir dies festhalten.
Wäre der Urknall nie passiert, die Evolution nie entstanden und Computer nie gebaut. Dann hätte ich all diese Probleme mit Fedora 18 nicht.
Spaß beiseite. Die Hardware als auch der Rest des Systems ist wunderbar. Vieleicht hattest du nur den Part überlesen, aus dem hervorgeht, dass das System erstklassig mit Fedora 16 und Fedora 17 funktioniert.
Könnte demnach sicherlich auch einfach nur ein aus der Eile herausgetriebenes Release mit Namen Fedora 18 handeln ? 2 Monate overtime kommt ja nicht von irgendwo.
Noch nie so einen Wust an Fehlermeldungen gesehen. Wie schon erwähnt, lässt es auf fehlerhafte Hardware u./o. eine vollkommen zerschossene Installation schliessen.
Warum auch immer ... (Meine wirklichen Vermutungen erspare ich dir/uns.)
Das ist ein Kernel oops.... Da braucht es keine zerschossene Installation um diesen auszulösen...
Bei RedHat hat wieder einer so viele ungetestete Zwischenpatches rückportiert ohne diese zu testen.
Egal wie auch immer ein System zerschossen ist. Eines sollte definitiv nicht passieren.... Das der Kernel oops'ed.
Das hier ist ein kernelseitiger Fehler und kein userland Fehler.
IdR springt der Kernel nach dem Bootloader in den 32 bit protected mode und läuft die ganze Zeit über im Ring 0 (Supervisor state), während die Userland Sachen im Ring 3 laufen.
Dem Kernel (Ring 0) ist es vollkommen wurscht, wie zerschossen dein System ansonsten (Ring 3) ist. Der Kernel sollte rock stable bleiben.
Wenn jedoch so eine Scheisse wie gvfsd und sellinux (Ring 3) den Kernel (Ring 0) zum Absturz bringen, na dann prost Mahlzeit.
Meine wirklichen Vermutungen erspare ich mir auch. Halt zuviel Alpha gefrickel. Es sollten halt nur Leute Dinge maintainen, die wirklich wissen, was sie da tun.
so ist Fedora, Bleeding Edge. Zwischen ganz brauchbaren sind dann die etwas böseren Ausgaben. Irgendwann muessen die eben ihre 18 drauf schreiben, sonnst kommt nie eine 19, ist ja nur eine Distro und kein Flughafen.
So ist es.
Ganz nebenbei ist mir aufgefallen, dass Fedora 18 sehr resourcenhungrig ist.
Ich habe von 4 GB nur noch 1.2 GB zum Nutzen. Das ist doch totaler Quatsch.
4 GB physikalischer Speicher. Linux ist ein upper half Kernel also 2 GB (ok sind 1 GB) für Kernel und 3 GB für Endnutzer.
Wenn ich Fedora 18 nur als RESCUE mode ausführe, dann bin ich bei satte 2.2 GB (nach dem RESCUE boot)
Wenn ich Fedora 18 normal ins Desktop boote dann nur noch 1.2 GB
Wo sind die 1.8 GB hin ? Soviel Schrott wird doch nicht geladen, welches 1.8 GB nur beim Booten verheizt ?
18 läuft problemlos seit der Beta bei mir - vielleicht liegt's wieder mal an einem PEBCAK.
Kann ich nur bestätigen mit der Beta ...
Du beziehst dich auf die Funktionalität bei dir. Ich beziehe mich auf die Funktionalität bei mir und anderen.
Ja, stimmt! Ich beziehe mich auf die Funktionalität bei mir u. bei anderen,
Na dann... Viel Erfolg!
Danke!
Hab ich schon.
Hallo Mr. PEBCAK
Heute erhielt ich 78 Bugzilla Redhat Mails (aktuell ist es ca. 11:10).
Soviele Mails habe ich noch nie an einem Tag erhalten und der Tag ist noch nicht einmal zu Ende.
Da scheinen ja eine ganze Reihe von PEBCAK's zu geben. Nur gut, dass bei dir alles stabil und seriös läuft.
es ist wohl eher so das die weniger versierten User einer Distribution wie Fedora (rpm basiert) einen Bug melden wo keiner ist. Man kann ihnen eigentlich nur den Vorwurf machen, sich nhicht vorher über die Tücken dieser nicht für den produktiven Einsatz gedachten informiert zu haben.
Jaaaa natürlich.
Ich wollte nochmals den besonderen Wert des eingeklammerten (rpm basiert) hervorheben.
http://de.wikipedia.org/wiki/Paketverwaltung
Zitat:aus der Wikipedia: "Debian Package Manager + Advanced Packaging Tool (APT) – für deb- oder RPM-basierte Linux-Distributionen"
SCHACH UND MATT!
Also ich habe keinen Qualitätsgefälle von Fedora 17 zu F18 festgestellt. Etwas Bleeding Edge, klar, aber auch nicht mehr als F17 seinerzeit war.
Hi,
was ist denn das für ein sinnloser Kommentar ???
Ich hab die FC18 seit der ersten offiziellen Alpha Version im Einsatz und bin mehr als zufrieden. Die Bugs die ich gemeldet habe, wurden gefixt, wo ist das Problem ?
Wenn die 18 wirklich die Basis für RHEL 7 ist, dann ist alles gut.
Schönen Abend
Oh, na da kann sich der User "verdammt" mal auf etwas gefaßt machen ...
Sicher eignet sich Fedora welches eine sehr gute Distribution ist für den Linux-Anfänger. danach stößt man aber an eine Grenzen wenn es um das produktive Arbeiten sich handelt.
Meine Empfehlung ist daher zu Ubuntu oder einer anderen debianischen Distribution zu greifen welche mit apt arbeiten und nicht mit dem langsamen yum. Hilfe gibt es unter anderem auch in den ubuntu-Wikis welche sehr gut sind.
Acader
Warum unbedingt "debianisch", wie wärs mit openSuse+Zypper?
Debianische Linuxdistributionen sind von der standartisierten LSB Laufzeitumgebung her sowie von der Stabilität sehr zu empfehlen. Aber jeder wie er will.
Soll heissen, RPM basiert ist weniger LSB konform und generell weniger stabil als DEB basiert? Hmmmmm.
Also eigentlich ist RPM das std-format von LSB
Zur stabilität...da können wohl wenige einem RHEL was vormachen, aber auf dem Desktop würde ich auch Debian od Ubuntu oder ArchLinux empfehlen..ganz einfach grössere softwareauswahl und auf dem Desktop der defakto standard (ausnahme arch). Aber die begründungen vom vorredner sind schlichtweg falsch.
Zudem ist die LSB tauglichste distri Suse, und die ist genaugenommen Slac basiert bzw RPM basiert.
Also bei mir läuft fedora schon länger und ja ich kann es auch produktiv einsetzen.
Gibt's noch Distros ohne Poetterkits?
Keine Ahnung, was Poetterkits sind, aber um die Software von Lennart wirst du wohl kaum herumkommen ^^
Software aufgrund eines Maintainers abzulehnen ist auch ein wenig seltsam... Technisch gesehen sind PulseAudio, Avahi und systemd einwandfrei, Kritiken kann man höchstens an a) Dem Konzept, was einem nicht zusagt, oder b) an der Umstellung von "alten" Technologien anbringen.
Da viele der Projekte relativ invasive Änderungen mitbringen gibt es in der Übergangsphase natürlich Probleme, auf lange sicht bringen diese Projekte allerdings erhebliche Verbesserungen. So ist z.B. ein Nebeneffekt von systemd, dass ConsoleKit komplett obsolet geworden ist (kümmert sich jetzt logind drum), was die Stabilität verbessert und z.B. echtes Multiseating erlaubt. Auch einige andere nette Funktionen sind möglich.
Klar, der Übergang nervt eventuell, da man sich umgewöhnen muss, aber diese Projekte sind langfristig gedacht.
> aber diese Projekte sind langfristig gedacht
Du meinst mit "gedacht" auch an BSD ?
Ich denke, dass diese Projekte eher kurzfristig und nur für Zwecke eines Linux Systems "gedacht" wurden. Mehr nicht. Die ganze Komplexität dieser Geschichte ist noch gar nicht abzusehen.
Die Poetterkits und freedesktop.org widersprechen jeglicher Unix-Philospohie. Früher galt einfache Konfigurierbarkeit in einfachen Textdateien als oberstes Ziel. Es wäre besser, die Poetterkits als PSD (Poettering-Software-Distribution) unter die Leute zu bringen, oder gleich als LSD ...
Die Unix-Philosophie funktioniert heute nicht mehr. Wen außer ein paar Retards interessiert das also!
Übrigens: Ich empfehle jedem das Unix-Hater-Handbook.
Wenn du behauptest, Textkonfigurationen seien das Größte, solltest du erstmal den XServer einrichten.
Danke für die Erinnerung, das UHH liegt schon länger in meinem Ordner zu lesender E-Books.
> solltest du erstmal den XServer einrichten.
BTDTGTTS.
[x] BLFS.
Tja, dann weißt du ja eigentlich schon, dass Textdateien ziemlich tedious sind.
TUI und GUI sind schon schöner...
Gerade das ist doch ein wesentlicher Bestandteil etwa von systemd.
> Gerade das ist doch ein wesentlicher
> Bestandteil etwa von systemd.
Nein, hier ist die Kernaussage nicht verstanden worden. Es mag sein, dass man systemd Textdateien bearbeiten kann. Jedoch meint der ursprängliche Autor eher auch das System als solches.
systemd ist alles andere als "einfach". Im Gegenteil, systemd ist absolut komplex und nicht einfach zu verstehen. Es ist meiner Ansicht nach sogar wesentlich komplizierter als das Services System welches unter Windows läuft.
Schau dir mal das "sc" ähnliche Tool für systemd an und du kotzt voll ab. Das ist halt das, was hier wohl eher gemeint ist.
systemctl | cat
Gib das mal in deiner Console oder Bash ein, dann kotzt du schon.
Mit init war die Sache einfach und darauf zielt die Aussage des Erstschreibers auch ab.
init hat ganz easy rcS gestartet, je nach dem, welchen Runnlevel du mitgeteilt hattest hat es dann die jeweiligen Scripte im rc.x Verzeichnis ausgeführt.
Ganz easy, mehr nicht. rcS als eine art Startup-Sequence... Selbst das reichte schon aus, um ein Linux System vollständig zu booten. Man braucht demnach nicht einmal die Runnlevel.
Ein kack init Tool und fertig.
Im Gegenteil: systemd ist sehr einfach bedienbar. Während es früher ein Pain war, einen neuen Service mit sysvinit zu erstellen, reicht heute mit systemd eine einfache deklarative Textdatei aus 2-5 Zeilen. Die alten init-Scripte waren ein extrem komplexes Wirrwar aus Spaghetti-Code und Race-Conditions.
> Ganz easy, mehr nicht. rcS als eine art Startup-Sequence
Die heutige Welt ist nicht mehr sequenziell. Ressourcen können jederzeit erscheinen und wieder verschwinden, Geräte rein- und rausgesteckt werden (Hotplugging).
> Die heutige Welt ist nicht mehr sequenziell.
Die Begrifflichkeit "startup-sequence" stammt noch aus alten Amiga Tagen. Natürlich kannst du in solch einem "einfachen" Textfile auch parallele Prozesse laufen lassen. rcS ist dazu natürlich auch in der Lage.
> Ressourcen können jederzeit erscheinen und
> wieder verschwinden, Geräte rein- und
> rausgesteckt werden (Hotplugging).
Richtig richtig. Nur ist das aber kein Anliegen eines systemd (... den ich immer noch als init betrachte).
Ein vernünftiges Hotplugging sollte Kernelseitig implementiert werden, sobald neue Hardware per Hotplug hinzuommt, sollte der Kernel die richtigen Treiber mit den richtigen Parametern laden. Wahlweise sollten Parameter über eine elegante GUI konfigurierbar sein (Lautstäre, DIN A4, usw....).
Das das alles nicht sonderlich richtig funktioniert mit systemd lernen wir ja mit einem externen WIFI Stick. Sobald Fedora hochfährt ist noch alles ok.... schaltet man dann aber das WIFI mittels dem GNOME-Network-Manager auf OFF dann wars das, man kann es nicht mehr einschalten und muss den Stick entfernen und neu einstecken.
Man glaubt zu wissen man gehe den richtigen Weg, nur ist dieser Weg leider nicht richtig. Das Problem ist zwar als solches erkannt worden, sollte aber auf anderer Ebene gelöst werden.
Aber was schreibe ich, in zwei Jahren spricht eh keiner mehr über das veraltete systemd, weil ein GNOME Entwickler wieder eine neue Lösung noch besser implementiert hat (... welche dann zwei Jahre später wieder als die Schlechte wahrgenommen wurde).
Siehe ähnliches Verhalten mit:
- gnome-config
- bonobo-config
- GConf
- DConf
-
Auch mit GNOME 3 wollte man ja so viel richtig machen, nur schreien die Spatzen es gerade von den Dächern. So zerhaun wie GNOME 3 in der öffentlichkeit Wahrgenommen wird...
Nur müssen nebenläufige Prozesse miteinander zur Synchronisation kommunizieren. Und "sleep" ist da eben keine brauchbare Lösung.
Systemd ist ein Service-Manager. Als was du es betrachtest spielt für die Realität keine Rolle.
Neu hinzugekommene Harddisks müssen mit fsck geprüft werden, Filesysteme gemountet werden etc.
Nennt sich Fortschritt. Es wird immer irgendwann etwas Besseres geben.
systemctl --no-pager | cat
Den Anwenderfall als default, den Programmierfall optional, das machen mittlerweile viele Linux-Tools so, allen voran Linus Torvalds' Git.
Anscheinend bin ich nicht der einzige, der Lennartware ablehnt:
https://bbs.archlinux.de/viewtopic.php?id=21924
Google findet zu "Lennartware" noch weitere interessante Seiten.
Um auf meine ursprüngliche Frage zurück zu kommen. Gibt es noch Linux-Distros, die frei von Poetterkits/Lennartware sind?
Auch sehr lesenswert:
Lennart-freies Linux: Was brauchts?
Ist Django 1.5 auch enthalten?
Wie kann man sich nur mit Fedora beschäftigen.