[Astorek]

 Zitat (Member_ZERO: 20. Mai 2013 - 00:17)

Schieß den Geier, doch sind die Treiber noch immer Bestandteil des Kernels.

Die "guten" Treiber, ja. Aber neben der wohl größten proprietären Firmware-Sammlung, die ich je in einer Linux-Distro gesehen habe, patcht Ubuntu auch sehr viel am Kernel rum, um Code für Treiberunterstützung, der noch nicht den Qualitätsanforderungen um Linus Torvalds' Team entspricht, ebenfalls miteinzupflegen. Zugegeben, ob gerade Letzteres wirklich sinnvoll ist sei mal dahingestellt... Ich für meinen Teil habe es aber schon öfters erlebt, dass bestimmte Hardware ootb nur von Ubuntu unterstützt wurde...

[species]

Also auf meinem Netbook (Samsung NC10+) läuft Kubuntu, und zwar flüssig, sogar die 3D Effekte wie Desktopwürfel etc. lassen sich aktivieren.
Kubuntu läuft jedenfalls deutlich besser, als das vorinstallierte Win7 Starter.

Species

[Astorek]

 Zitat (species: 20. Mai 2013 - 11:42)

Also auf meinem Netbook (Samsung NC10+) läuft Kubuntu, und zwar flüssig, sogar die 3D Effekte wie Desktopwürfel etc. lassen sich aktivieren.
Kubuntu läuft jedenfalls deutlich besser, als das vorinstallierte Win7 Starter.

Species

Wenn er schon schreibt, dass bei ihm Ubuntu (Ohne "K") langsam läuft, wird bei ihm das noch ressourcenfressendere Kubuntu garantiert nicht flüssiger laufen^^...

[species]

 Zitat (Astorek: 20. Mai 2013 - 19:57)

Wenn er schon schreibt, dass bei ihm Ubuntu (Ohne "K") langsam läuft, wird bei ihm das noch ressourcenfressendere Kubuntu garantiert nicht flüssiger laufen^^...

Aha, und warum läuft bei mir wohl KDE und nicht Unity?
Weil K wohl doch nicht so Ressourcen-fressend ist wie U?

Wo nimmst du deine Weisheit überhaupt her?
Auf allen meinen Geräten läuft Kubuntu, sprich KDE, deutlich flüssiger und ressourcenschonender als dieser Unity oder Gnome3 Quark.

Außerdem hat KDE im Gegensatz zu Gnome3 und Unity ein Fallback zu 2D !

Species

Dieser Beitrag wurde von species bearbeitet: 21. Mai 2013 - 12:52

[Winfuturic]

Das Einfachste ist(um alle Fragen zur Lauffähigkeit und Treiberproblematik auf einen Schlag zu klären):
Nimm ne DVD/CD-RW oder auch einen Stick, falls kein DVD-Laufwerk und brenn Dir ne Live-Variante eines der vorgeschlagenen BS.
Wenn das Livesystem läuft, kannst Du sicher sein, das alle Treiber vorhanden sind.
Mein Vorschlag: Versuche es mal mit XUBUNTU, ist bei mir auf allen alten "Möhren" gelaufen und ist sehr resourcenschonend.

Viel Erfolg!

Dieser Beitrag wurde von Winfuturic bearbeitet: 22. Mai 2013 - 12:57

[ph030]

Auf meiner Testmaschine braucht KDE(4.10.3) +/- die selben Ressourcen wie XFCE(GNOME weit abgeschlagen), macht/bringt dafür aber immer noch mehr als XFCE. Zugegeben, dafür hab ich recht heftig an den Schräubchen gedreht - es geht also schon.

Mein normales Arbeitssystem braucht frisch nach dem Booten und mit allen per default geladenen Apps/Daemons knapp über 250mb. Natürlich kommen im Laufe des Tages jede Menge GB für Caches und richtige Arbeit hinzu, aber dafür ist der Speicher ja auch da, für Nutzwert und nicht für blingbling.

[Astorek]

 Zitat (species: 21. Mai 2013 - 12:39)

Aha, und warum läuft bei mir wohl KDE und nicht Unity?
Weil K wohl doch nicht so Ressourcen-fressend ist wie U?

Wo nimmst du deine Weisheit überhaupt her?
Auf allen meinen Geräten läuft Kubuntu, sprich KDE, deutlich flüssiger und ressourcenschonender als dieser Unity oder Gnome3 Quark.

Tatsächlich? Ich gebe zu, dass meine Erfahrungen von Unity/KDE schon etwas länger her sind, aber dass die das mittlerweile so in den Griff bekommen haben, hätte ich nicht gedacht. Danke für die Berichtigung^^.

@ph030: Hast du zufällig Anleitungen o.Ä. zur Hand, mit dem man KDE derart ressourcenfreundlich "stutzen" kann? Selbst unter Arch krieg ichs nicht hin, dass KDE maximal 200 MB frisst (was ich bei Xfce problemlos schaffe)^^...

[ph030]

 Zitat (Astorek: 22. Mai 2013 - 20:27)

@ph030: Hast du zufällig Anleitungen o.Ä. zur Hand, mit dem man KDE derart ressourcenfreundlich "stutzen" kann? Selbst unter Arch krieg ichs nicht hin, dass KDE maximal 200 MB frisst (was ich bei Xfce problemlos schaffe)^^...

Fix und fertig Anleitung hab ich nich, aber so ein paar Hinweise:
Erstmal kommt's natürlich drauf an, was man selbst unter KDE versteht, also die ganze KDE SC oder nur ein Subset davon. Der ganze Semantic Desktop-Mist kommt bei mir raus, also Nepomuk&Strigi(obwohl letzteres ja eh rausfliegt oder schon ist IIRC). Wenn man Akonadi nutzt, dann mit SQLite oder Postgre; hab's selbst nur mit SQLite probiert und keine wirklichen Probleme gefunden. Alle Backgroundservices auf on-demand(udev, autofs und inotify helfen, ist aber teilweise Frickelarbeit). Simple Themes, fancy Icons verbrauchen viel Speicher. 3D aus/minimieren. Apps tauschen, KMail z.B. ist imho immer noch BBR, wenn IMAP reicht ist Trojita ganz gut. Den ganzen modernen Mist wie udisks, upower, *kit rausschmeissen wo's geht, etc.

Das ganze ist halt für den Einsteiger nicht wirklich zu machen, da braucht's einige Erfahrung, zum Teil wissen wie's früher mal war und aber immer noch geht, und gelegentlich auch das ein oder andere Script.

Ich kann halt, wie wohl hinlänglich bekannt sein sollte, mit den ganzen DEs nichts anfangen, die sind mir alle zu kompliziert und komplex, als dass ich da den Überblick behalten könnte und das trotz über einer Dekade Linux. Irgendwo verreckt immer mal was und ich find's leichter, wenn ich mehr standalone Programme hab, das ist viel leichter zu debuggen als zu schauen ob Kmail jetzt nicht mehr mit Akonadi kann oder ob Akonadi mit MySQL nicht kann oder ob hier ne ACL in Polkit falsch ist oder ob SELinux verrücktspielt oder ob ein Kernelmodul abgefreckt ist oder... Ich bleib dabei, es gibt kein System was für alle funktioniert, auch wenn MS das trotzt W8 immer noch behauptet. Ein System gehört von Grund auf aufgebaut und auf den User/die Bedürfnisse zugeschnitten. Bei Linux hat man die Möglichkeit, aber leider sind die Umsteiger fälschlich oft verwöhnt und entsprechend faul.

Sry, konkretere Tips kann ich nicht geben, ausser ev. wirklich mal selbst KDE komplett von Hand zu bauen und alle ./configure Ausgaben bzw. Makefiles zu lesen.