>> Es ist bekannt, dass Linux mehr Hardware unterstützt als jedes andere >> Betriebssystem, und das überwiegend bereits im Standard-Lieferumfang. Ein Test >> ist damit überflüssig, und es wäre zu viel Aufwand für wenig Nutzen, eine >> repräsentative Auswahl von Hardware zu beschaffen.
Freuen wir uns auf einen objektiven Bericht ohne Vorurteile
Allerdings stimmt es. Immerhin haben viele Betriebssysteme keine/wenige eigene Treiber an Bord. Windows kennt nur sehr wenig Hardware von Haus aus, MacOS auch nur die der Macs. FreeBSD und co. sind zwar besser, aber immer noch weit hinter Linux.
Rechnet man die Treiber hinzu die es extern gibt, stimmts aber natürlich nicht.
Im Kernel sind ja auch noch treiber fuer wirklich antike sachen, die vielleicht noch in Museen benutzt werden, da ist es nicht verwunderlich wenn Linux wahrscheinlich wirklich der einzige Kernel der welt ist mit der groessten treiberauswahl
Tja, es stimmt. Aber es trifft die Sache nicht im Kern.
Windows-System haben nicht so viele Treiber im Kern, aber dafür alle vom Hersteller mitgeliefert oder im Download verfügbar.
Die Gesamtzahl der verfügbaren Treiber ist deswegen bei Linux geringer.
Altes Thema, altes Lied: Bei größerer Verbeitung von Linux, gäbe es mehr Treiber von Herstellern. Bei mehr Treibern von Herstellern, wäre die Verbreitung von Linux größer. Insofern: Hilfreich ist die Verbreitung durch ubuntu/canonical.
Und das kannst du auch belegen, oder ist das nur eine Theorie, die du dir überlegt hast?
Das hängt sicher auch davon ab, was man unter Windows versteht. Ist damit nur das Desktop OS gemeint? Oder auch Windows CE? Ganz zu schweigen von spezieller Server-Hardware.
Auf meinem Rechner läuft sämtliche Hardware out-of-the-box unter Linux. Allerdings unter dem parallel installierten Windows 7 gibt es weder Treiber für meine Audigy 4 noch für meine Logitech Webcam.
Von Idiotenpfleger am Fr, 22. Oktober 2010 um 06:25 #
hmm... immer das alte Lied... langsam wird es langweilig. Ich habe auch so ein Gegenbeispiel: Logitech Webcam und Bluetooth-Dongel. Beide kamen natürlich mit einer Windows-Treiber CD. Und? Die sind dem Recycling zum Opfer gefallen, weil unter Linux gilt: anstecken und funktioniert. Im Windows, das hier noch auf einer zweiten Platte herumdümpelt (natürlich das vielgepriesene Windows 7!!!) blinken die roten Ausrufezeichen in der Systemsteuerung...
Wenn man keinen Müll kauft, wie Lexmark-Drucker o.ä. hat man eh mehr Freude an seiner Hardware. Und sie läuft unter Linux. Obwohl o.g. Bluetooth Dongel auch nur ein Billigteil für 3 Geld Fuffzich war. Das hält aber Linux nicht davon ab, auch das zu unterstützen. Ich habe mittlerweile mehr Vertrauen in Linux, mit "wird schon laufen" als in Windows mit "na mal sehen ob mir die Treiber CD nicht noch 10 »megageile« Toolbars installiert und ob es nicht vielleicht was zerschießt"
Von da-real-lala am Fr, 22. Oktober 2010 um 17:26 #
>> Es ist bekannt, dass Linux mehr Hardware unterstützt als jedes andere >> Betriebssystem, und das überwiegend bereits im Standard-Lieferumfang. Ein Test >> ist damit überflüssig, und es wäre zu viel Aufwand für wenig Nutzen, eine >> repräsentative Auswahl von Hardware zu beschaffen.
Diese FUD-Aussage ist eigentlich sehr fahrlässig, da sie taktischerweise Linux eine Gefallen tun will indem man sagt "Tja, wir unterstützen 1 000 000 Hardwareteile, während ihr nur 5000 könnt." Nun ja, das mag vielleicht so sein, aber
1. ist darunter eine Menge von Hardware zu verstehen die eben nicht unter die Sparte moderne Desktophardware ist (mal ehrlich, Bladesysteme, Amateur-Radios und MIDI-Keyboards sind eben für den 0815 Desktopuser nicht von Belangen). Da sind MS und Apple (die noch mehr, weil sie ja das meißte eh selber zur Vefügung stelln) im Vorteil. Und das muss man als verantwortliche Person doch sagen. Sonst sind wir dann eh die gleiche FUD-Kacke wie MS und Apple wenn wir Menschen an der Nase herumführen. Meiner Erfahrung nach funzt brandneue Hardware meißt nicht so gut, sondern wird erst einen Kernel später gut unterstützt. Glücklicherweise wir solche Hardware immer seltener -- selbst Broadcom hat jetzt open source Treiber :). Wer etwas ältere Hardware hat (also, mind. 6 Monate - 1 Jahr alt) ist meißt gut bedient.
2. ist Untestützung eher relativ. Ich bin froh wenn es funtzt und habe zBsp. kein Problem damit, dass wenn mein WLAN nicht geht einfach Debian Testing zu nehmen oder nen Kernel zu kompilieren. Oder wenn halt meien Webcam auf dem Kopf steht einfach eine Verknüpfung zu machen die dann libv4l1 anstatt 2 benutzt. Der Desktopbenutzer der eben seinen Laptop einfach anmacht wie eine Mikrowelle will damit nicht überfordert werden.
Gerade deswegen sollten wir doch besser sein als diese Sesselpupser bei MS und Apple und Leuten einfach klar sagen - "Hey, Linux ist frei, meißt kostenlos und sehr stabil, aber bitte bedenke, dass Treiber hin und wieder Mühe machen, Du vielleicht Probleme damit haben wirst einen Projektor in weniger als 1 Minute einzustellen oder vielleicht mal Formatierungsprobleme mit deinen .doc Dokumenten haben wirst."
Unter Maverick Meerkat 10.10 versuche ich per GtkFileChooser (sei es unter Evince, Firefox, usw...) Dateien per Eingabe der URI (URL) zu öffnen. Besonders in Verbindung mit Favicon Picker 2 geht das nicht, da der GtkFileChooser keine URL's annimmt. Nach der Eingabe einer URL und der Bestätigung mit "Open" tut sich nix, da der GtkFileChooser hier wohl fehlerhaft ist.
Woher stammt eigentlich das, was Kubuntu seinen Nutzern als KDE4 anbietet, direkt von Upstream (also kde.org) oder direkt von Debian Testing/Sid?
Ich benutze noch KDE3 unter Debian Lenny und wenn ich den objektiven Bericht des Autors über diesen debianisierten KDE4 in Kubuntu so lese, dann graut es mir schon massiv vor dem kommenden Squeeze-KDE4.
Hm, die negativen Punkte von KDE4 bei Ubuntu (laut diesem Artikel): Okular stürzt ab, Symbole sind hässlich und Herunterfahren funktioniert nicht immer reibungslos. Unter Squeeze-KDE4 ist mir Okular noch nie abgestürzt und das Herunterfahren funktioniert auch perfekt. Bleiben noch die Symbole: Symbole sind immer geschmackssache und können auch geändert werden. Kurz: nach diesen Bericht braucht es dich gar nicht grausen
PS: Ubuntus 10.10-KDE ist eine neuere Version als in Squeeze vorhanden sein wird.
"Ubuntus 10.10-KDE ist eine neuere Version als in Squeeze vorhanden sein wird."
Testing (KDE 4.4) ist zur Zeit ja eingefroren, Debian Sid ist davon natürlich ebenfalls betroffen (KDE 4.4). Kubuntus 10.10-KDE4 ist - wie Du sagst - neuer als das, was Debian gerade eingefroren hat.
Kubuntu 10.10 hat doch seinen KDE4 hoffentlich nicht aus Debian Experimental genommen?
Die KDE-Pakete von Kubuntu haben ubuntu in der Versionsnummer und im Changelog sind ausschließlich Kubuntu-Einträge. Unter KDE 4.4.5 in Squeeze tritt der Fehler nicht auf.
Von neversfelde am Do, 21. Oktober 2010 um 18:28 #
Mergen bedeutet grob gesagt, dass wir die Debian und Kubuntu Pakete vergleichen und die Debian Änderungen einpflegen. Ist zum Anfang des Zyklus zum Beispiel 4.4 aktuell und auch in Debian, dann wird gemerged und wird im Laufe des Zyklus 4.5 veröffentlicht, dann aktualisieren wir. Natürlich gibt es auch eigene Bugfixes und Veränderungen, wobei wir die auf einem Minimum halten. Also bevor jemand meckert, wir geben alles was wir machen an Upstream oder falls erforderlich auch an Debian weiter.
Zur Zeit gibt es aber wohl nichts zum Mergen, weil die Kubuntu 10.10-Version neuer ist als diejenige in Debian Testing/Sid. Ihr mergt ja anscheinend nicht mit Debian Experimental (dort befindet sich eine Debian-KDE 4.5.x-Version).
Deinem letzten Satz entnehme ich, dass Debian normalerweise Eure Vorarbeit nicht übernimmt (?). Da ihr an Upstream zurückgebt, möchte ich Euch auch bitten, eine entsprechende Liste auf Eurer Webseite zu veröffentlichen, auf die man verweisen kann, wenn es wieder einmal darum geht, ob (K)Ubuntu etwas an Upstream zurückgibt oder nicht. Die momentan existierende Ubuntu-Liste über erfolgte Kontributionen ist in dieser Hinsicht ein Witz, da sie nicht wirklich gepflegt wird.
Unter https://wiki.ubuntu.com/Website/Content/UbuntuContributions findet man zu Kubuntus Beiträgen Folgendes: "System Settings, the KControl replacement, was maintained and pushed into KDE 4 by Kubuntu developers. printer-applet, part of KDE 4.1, was written by Jonathan Riddell guidance-power-manager, part of KDE extragear, was written by Kubuntu developers." Das ist natürlich schon Einiges.
Wenn man sich aber z.B. die Gnome-Sektion dieses Dokumentes anschaut, so muß man sich fragen, was diese Liste eigentlich soll. Auch wenn Ubuntu in Gestalt von Canonical nur 1% der Upstream-Gnome-Kontributionen abliefert, dann ist das keinesfalls "Null", was man auch aus den Diagrammen des Gnome-Zensus ersehen kann.
Ich gehe deshalb davon aus, dass diese Liste nicht vollständig ist.
Ich bin der Meinung, dass in diese Kontributionsliste wirklich alles hinein muß, was an Kontributionen durch (K,X,...)Ubuntu-Entwickler erfolgt ist und dass diese Information nicht die Community alleine leisten kann, wie einem dieser Wiki-Eintrag doch nahe legt. Ich hoffe, dass der Hinweis "This page is under development for Ubuntu website. Please add anything that would fit its purpose." bedeutet, dass diese Liste endlich dorthin wandert, wo sie auch gelesen und entdeckt werden kann, nämlich auf die Ubuntu-Hauptseite.
Eine weitere wichtige fehlende Information ist die Anzahl der Bugs, die von der Ubuntugemeinschaft über Ubuntu an die jeweiligen Upstreams gemeldet wurden.
Die ganzen Infos sind auch wichtig für "Ubuntu-Nicht-Fans", da der vernünftige Kommentator nicht wieder besseres Wissen Unwahrheiten verbreitet.
Geschmacksfrage. Bei der Schere als Symbol für die Zwischenablage habe ich mich aber auch schon gefragt, wer den Mist verzapft hat.
Meine letzte Evaluation (OpenSUSE 10.3 mit KDE 4.5.2) ist aber nicht deswegen negativ, sondern wegen der immer noch viel zu häufigen (teils reproduzierbaren) Abstürze. KDE 4: Optisch aufgebretzelt, immer noch Beta-Qualität -> Tonne.
Kann es sein, dass dein Einstellungsverzeichnis .kde4 von einer älteren KDE 4 Version stammt und du nun auf KDE 4.5 gewechselt bist. Ich hatte wegen falschen/veralteten Einstellungen schon öfter Probleme (KNetworkmanager wollte nicht mehr starten, verschiedenste Abstürze) und musste deshalb auch schon öfter dieses Verzeichnis löschen (Achtung wegen Passworter usw. !) KDE 4.5 läuft bei mir auf drei verschiedenen Maschinen völlig stabil, aber eben nur mit frischem .kde4 Verzeichnis.
Auf dem OpenSuse 11.3-Desktop gibt es etwas, was "Online-Hilfe" heißt. Darauf habe ich in der klassischen Desktopansicht genau einmal geklickt. Daraufhin begann Konqueror anscheinend unendlich viele Konquerorfenster zu öffnen, bei etwa 30 konnte ich rein optisch auf der Taskleiste nicht mehr mitzählen. Abmelden konnte ich mich aber noch.
Von Idiotenpfleger am Fr, 22. Oktober 2010 um 06:37 #
irgendwas muss aber bei der Kubuntu-Entwicklung immer wieder schieflaufen. Ich habe hier OpenSuse 11.3 am Laufen, erst mit dem in der Distri eh vorhandenen KDE 4.4.4 und nun mit KDE 4.5.2 aus dem OpenSuse Build Service. Und ich bin dermaßen begeistert, wie schnell, stabil und nett anzusehen diese KDE-Versionen sind! Früher hatte ich auch Kubuntu und fand speziell 9.04 ziemlich gut, aber was danach kam... unbeschreiblich. Sorry, aber wenn ich bei KDE arbeiten würde, würde ich Kubuntu verklagen, wegen Rufschädigung. Die Krönung für mich war 10.04 und 10.10 tue ich mir gar nicht erst an. Ich habe unter den von mir bisher verwendeten Linux-Systemen noch nie so viele Abstürze erlebt, wie unter Kubuntu 10.04 und nach dem, was man hier im Bericht liest, wird das unter 10.10 nicht anders sein. Okular war nämlich auch bei mir unter Kubuntu 10.04 das Sorgenkind Nr. 1.
Was solls, die Bugtracker auf Launchpad sind voll, genug zu tun... und für mich heißt es "Time to move on". OpenSuse FTW!
Von Idiotenpfleger am Sa, 23. Oktober 2010 um 03:43 #
YaST ist einfach genial. Viel Schneller als Synaptic: kurze Ladezeiten beim Auffrischen der Paketquellen, schnelle Suchfunktion, schnelle Installation, einfaches Hinzufügen von Paketquellen... und die Systemverwaltung mit YaST zeigt, wie professionell so etwas vonstatten gehen kann. Da können alle anderen Distris und Windows mal schön locker einpacken. (K)Ubuntu sowieso mit ihrem config-Dateien-Gebastel.
Und wo ich dabei bin: KPackagekit ist ja wohl der Witz in Tüten! Eine Softwareverwaltung, die selbst alle Nase lang abstürzt... ja, der vertraue ich die Installation von Paketen an.... ja sicher... damit das so schon zerfrickelte System noch instabiler wird, durch halb-installierte Pakete.
Yast ist schnell? Da habe ich aber andere Erfahrungen gemacht mit OpenSuSE (10.3 oder so). Wenn dir Synaptic zu langsam ist, dann verwende doch das reine apt-get update und apt-get dist-upgrade zum updaten. Für das Hinzufügen von Paketquellen kann man ja einfach die sources.list editieren. Und ein Editor starten und ein Update via apt-get ist meiner Meinung nach nicht zu langsam.
Von Idiotenpfleger am Sa, 23. Oktober 2010 um 08:56 #
nein, ich habe keine Lust auf das Frickeln in config-Dateien. Das ist der Punkt. Ein modernes Betriebssystem muss ohne das herumpfuschen in config-Dateien auskommen. Und in OpenSuse werde ich sicher nicht apt-get verwenden YaST ist schnell, ja, verdammt. Es ist schnell. Und es ist richtig gut. Genau wie das Gesamtsystem "Open Suse 11.3" verdammt gut ist und dieses Kubuntu mal locker in die Tasche steckt.
Tja... naja... 10.3 ist auch eine total moderne Version... die wird zwar nicht mal mehr mit Updates unterstützt, aber die kann man locker noch als Referenz heranziehen. Bei so etwas fehlen mir echt die Worte.
Mittlerweile musst Du apt-get aber mit Zypper vergleichen und dann Synaptic mit Yasts Paketverwaltung. Und in diesem Vergleich schneidet in punkto Schnelligkeit und Bedienungsfreundlichkeit das Duo Zypper/Yast sehr gut ab. Zypper ist als Kommandozeilenwerkzeug fast genauso exquisit wie apt-get. Für OpenSuse war das die beste Entwicklung seit langem, seit diesem ZMD-"Unfall" in SuSE 10.1, der erst mit dem Erscheinen von OpenSuse 11.0 vollständig überwunden gewesen ist.
Die von Dir beobachtete Langsamkeit kann daher rühren, dass OpenSuse kleine Delta-RPMs zur Aktualisierung verwendet, die nach dem Herunterladen sogleich mit applydeltarpm angewendet werden. Das fordert natürlich die CPU. Da Zypper/Yast zur Zeit noch das Schema "Delta-rpm herunterladen, Delta-RPM anwenden, gerade neu erhaltenes rpm-Paket installieren" benutzen, um danach mit dem Herunterladen des nächsten Delta-rpms fortzufahren, kann dieser Vorgang mitunter dauern. Die Tatsache, dass selbst bei vielen DSL-Breitbandzugängen eine rigide Traffic-Begrenzung vorherrscht (u.a. in Australien) lässt aber keine andere Wahl. Die betroffenen Nutzer sind z.B. bei OpenOffice-Updates für solche kleinen Delta-rpms überaus dankbar, weil sie in den beschriebenen Situationen wirklich Geld sparen. Es wird zur Zeit auch diskutiert, die Delta-rpms in Zukunft in einem Rutsch herunterzuladen, weil dies Nutzern von Schmalbandanschlüssen, die Minutenpreise zahlen müssen, noch mehr entgegen kommt.
Von da-real-lala am Fr, 22. Oktober 2010 um 17:38 #
Ich habe unter Squeeze KDE 4.3, sowie 4.4 benutzt und muss sagen, dass, obwohl es spübar langsamer als die 4.5 Reihe unter Arch ist (aber das kann ja auch zBsp an den neueren nvidia Proprietary Treibern oder dem neueren XOrg liegen), es doch sehr stabil lief. Was mich genervt hat: Die Systemsteuerung wollte mir nicht so recht erlauben als sudo mein KDM zu wählen (Ich musste als root einloggen, was KDM widerum verweigert, also hab' ich dann ohne DM eingeloggt...). Das anfängliche wählen eines Themas für GTK Programme nervt auch. Aber sonst alles klar. Ich habe auch nie ohne Desktopeffekte getestet, mag ja sein, dass das dann flüssiger läuft. Außerdem gibt es ja immer noch Trinity:
"Am Ende der Installation kam es bei mir in mindestens zwei Fällen zu einem Absturz des Installationsprogramms. (...) Das ist ein Fehler, der Canonical gemeldet werden sollte, sofern er noch nicht bekannt ist."
Ähm, definitiv sollte der Fehler gemeldet werden. Aber das kann auch nur die Person machen, bei der der Fehler aufgetreten ist. Daher bitte: Selber Fehler melden und damit freie Software verbessern. Danke
ganz meine Meinung...ich hatte unter KDE und bei der Installation keinerlei Probleme. einzig die von mir nachinstallierten Kontact2 Komponenten ärgern mich ein wenig, aber sind trotz beta-status gut nutzbar. Ach ja Kwin und intel-Grafik war noch ein Problem, was sich aber mit kurzer Forensuche auch lösen ließ.
Dem Stimme ich absolut zu. Ich frage mich wirklich, wass an diesem "Fach"-Artikel richtig "objektiv" sein soll.
Aber das mit den Treibern schießt den Vogel bei weitem ab. Viel Hardware funktioniert zwar, aber die Frage ist nur: "WIE sie funktioniert?!?!" Tendenziell funktioniert die Hardware grauenvoll mit den Standardtreibern. WLAN zu lahm - neu machen, Sound knackt - neu machen, 3D Beschleunigung zu langsam - treiber wechseln.
Mir ist bisher noch kein Desktop-System unter die Augen getreten wo man nicht den Treiber selbst neu kompilieren durfte oder Kernel backen musste.
Darum geht es doch gar nicht. Es geht darum, dass dem Autoren nicht der Hardwarepool zur Verfügung steht, den er bräuchte, um über die Hardwarekompatibilität Ubuntus eine vernünftige Aussage zu treffen.
Ganz schlimm wäre es, wenn der Autor zufällig auf einer Hardwareausstattung testen würde, die mit Ubuntu leider nicht zuverlässig funktioniert. Das Geschrei, dass dann hier ausbrechen würde, möchte man wohl jedem Menschen ersparen. Also testet man besser in einer virtuellen Maschine.
In früheren Prolinuxberichten zu SuSE 6.x oder Red Hat 7.x, die man im Archiv einsehen kann, sind solche Hardwareprobleme immer wieder aufgetreten. Nur: Nutzer mit anderen Hardwarekombinationen interessieren diese Spezifika nicht. Für sie wäre ein solcher "hardwareabhängiger" Bericht dann eher "wertlos".
Nur ein Beispiel: Ich habe hier eine alte Geforce4MX-Grafikkarte in einem Rechner, die mit Nouveau nur mit katastrophal verzerrtem Bildschirm läuft. Stell Dir einmal vor, man würde Ubuntu Maverick darauf testen. In den Ubuntuforen erhält man für gewöhnlich den nomodeset-Tipp, dann fährt Ubuntu wenigstens hoch und man kann dann den proprietären NVidia-Treiber installieren. Nur: Der neueste zweite Legacy-NVidia-Treiber, der für diese Geforce4MX-Karte verfügbar ist, läuft nicht mit der Xserver-Version 1.9 in Maverick. Also bleiben nur vesa und nv. Das wäre ein Bericht. Ein Ubuntu-in-die-Tonne-treten mit Ansage.
Ich habe eine Geforce 4 MX unter Maverick mit Nouveau im Einsatz. Der Bildschirm ist weder verzerrt, noch sonst wie schlechter als mit dem Nvidia Treiber.
3D, bzw GL läuft allerdings extrem bescheiden. Beispiel Dreamchess, so gut wie unbenutzbar.
Geforce4MX-Grafikkarten funktionieren zwar in der Regel mit Nouveau. Eine Geforce4MX440 onboard (NV18) liefert aber das von mir beschriebene Fehlerbild (dieser Chip wurde sehr oft mit NForce2-Chipsätzen ausgeliefert). Der Fehler tritt laut Ubuntu-Bugzilla und -Forenpostings auch mit Geforce4MX440-Nicht-Onboard-Karten auf.
Das Nouveauprojekt hat keinerlei Hardwareinformationen vom Hersteller der Grafikkarten, nur so kommt so etwas zustande, frei nach dem Motto, die Hardware, die das Nouveau-Projekt nie gesehen hat, muß nicht unbedingt mit Nouveau funktionieren.
Ich habe mittlerweile sämtliche NVidias verbannt, ich bin es leid. Der oben beschriebene Chip wird zum Glück abgeschaltet, sobald man eine zusätzliche Grafikkarte (hier ATI Radeon) in den eigentlich freien AGP-Slot steckt.
Anscheinend funktionieren dann die experimentellen Nouveau3D-Treiber nicht mit Deiner Grafikkarte? Google Earth z.B. läuft immerhin mit Nouveau-2D und Software-Mesa, langsam zwar, aber es läuft. An dem zur Zeit nicht vorhandenen NVidiatreiber für Geforce4MX-Karten unter Maverick sieht man auch, was das Hauptproblem proprietärer Grafikkartentreiber ist.
>> Mir ist bisher noch kein Desktop-System unter die Augen getreten wo man nicht den Treiber selbst neu kompilieren durfte oder Kernel backen musste.
Hä? Du hast bis jetzt auf jedem System den Kernel bzw. Treiber kompiliert? Wo hast du bitte den Quellcode von Windows/Mac OS her und wann kann man den von TPB herunterladen?
Eventuell meintest du statt Desktop-System Desktop-Linux oder Linux-System (...).
Ich habe Kubuntu zwar nie schlechtgeredet, aber hier die objektive Begründung:
- wie auch Xubuntu & Co. gibt es auch für Kubuntu weniger Entwickler und Tester, als für das Haupt-Ubuntu (8.04 ist nichtmal als LTS erschienen!) - es gibt einfach mehr Bugs, etwa im Paketmanager, zumindest war es bei 8.xx so, dass der Paketmanager wesentlich schlechter in der Usuability war und auch leichte GUI-Bugs da waren - Updating funktioniert noch schlechter als bei Haupt-Ubuntu, aus eben den beiden obigen Gründen
> wie auch Xubuntu & Co. gibt es auch für Kubuntu weniger Entwickler und Tester, als für das > Haupt-Ubuntu
Die brauchen das KDE ja auch nur von Debian übernehmen. Viel Entwickleraufwand ist da nicht nötig. Der Grundunterbau ist bei Ubuntu und kubuntu ja gleich.
> es gibt einfach mehr Bugs, etwa im Paketmanager,
In beiden Fällen benutze ich apt-get und wüsste nicht wo da ein Unterschied zwischen Ubuntu und kubuntu besteht
Von da-real-lala am Fr, 22. Oktober 2010 um 17:48 #
>In beiden Fällen benutze ich apt-get und wüsste nicht wo da ein Unterschied zwischen Ubuntu und kubuntu besteht.
Wäre doch aber schön wenn man einfach nur das Software Center auch unter Kubuntu als Standard nehmen würde. Außerdem, wer nicht weißt wie man output an der Konsole mit grep pipet (und das ist eben die Zielgruppe Ubuntus), wird nicht so glücklich über apt-get sein wenn er mal 50.000 libraries deinstallieren will.
Ich hatte hier eben kurz die Kubuntu 10.10-LiveCD am Laufen. KDE hat einen guten Eindruck gemacht, Rekonq ist sehr schnell und lässt sich im übrigen genauso wie Konqueror en detail konfigurieren. Das ging alles solange gut, bis ich Amarok öffnete und die von Amarok selbst mitgebrachte und angezeigte 40 Sekunden-Musikdatei abspielen wollte. Es gab sofort einen Xorg-Crash und außer einem schwarzen Bildschirm mit Monitor-LED-Geblinke ward nichts mehr gesehen. Irgendwie lustig. Das Soundsystem scheint eine große Schwäche Ubuntus zu sein. Wie das allerdings zu einem totalen Xorg-Crash führen kann, das wird wohl das Geheimnis Ubuntus bleiben.
Ich benutze kubuntu10.10 schon seit dem 10.10 als Festinstallation und konnte bisher keine Fehler dieser Art finden, auch nicht bei Amorak. Das Soundystem war bei Ubuntu und kubuntu schon immer eine schwachstelle. Aber bei kubuntu10.10 funktionierte es bei mir zu erstenmal sofort. Ubuntu10.10 hab ich jetzt nicht ausprobiert.
Ich habe das Soundproblem gerade noch einmal reproduziert. Der Kubuntu-Sound funktioniert, wie z.B. die Systemklänge. Es sind Amarok und auch Dragonplayer, die auf der Live-CD nicht funktionieren. Im Gegensatz zu Dragonplayer crasht aber Amarok leider und nimmt das ganze Kubuntu dabei mit. Jetzt stellt sich natürlich die Frage, ob das nach einer Festplatteninstallation nicht ganz genau so wäre. Kubuntu erinnert mich übrigens vom Aussehen und der Schnelligkeit her (ohne aktivierte Arbeitsflächeneffekte) nicht an Ubuntu, sondern eher an Slackware 13.1.
Vielleicht hast du einen Hardwareeffekt. Bei mir ist kubuntu-10.10 noch nie abgestürzt, Amorak eben so wenig. Dragonplayer verwende ich nicht, ich verwende vlc.
Debian Lenny und OpenSuse 11.1 funktionieren auf meinem System einbahnfrei. Dann teste ich eine Kubuntu-LiveCD, rufe dann nach bis dahin gelungenem Antesten Amarok auf, was zum Totalcrash der LiveCD-Session führt und dann kommst Du vorbei und erzählst irgendetwas von einem nicht vorhandenen Hardwaredefekt. Es gibt IMO nichts Schlimmeres als diese "Bei mir ist Kubuntu, Windows, MacOSX (...) ist mir noch niemals abgestürzt"-Fraktion.
Im Hinblick auf den Bericht des Autors gehen solche Äußerungen (nicht Deine, sondern andere, s.u.) sogar so weit, diesen indirekt der Lüge zu bezichtigen, nur weil ihm u.a. Okular beim Testen abgestürzt ist.
Wenn ich mir die Ubuntu-Bugzilla so ansehe, wundert mich ohnehin nichts mehr. Man braucht nur kurz dort hineinzuschauen, um zu sehen, wie gut alles funktioniert.
So, ich habe Kubuntu 10.10 auf meiner Festplatte installiert. Es ist der schnellste KDE 4, den ich je gesehen habe.
Zu den Fehlern, die ich mit der Live-CD beobachten konnte: 1. Amarok funktioniert und stürzt nicht ab, ganz im Gegensatz zu dem, was zuvor während meiner LiveCD-Sitzung passiert ist. Es handelt sich somit um ein Problem der LiveCD. 2. Dragonplayer spielt jetzt zwar immer noch keine wav-Dateien ab, wohl aber ogg-Dateien. Im Gegensatz zur LiveCD-Sitzung gibt er also Töne von sich. 3. Okular öffnet pdf-Dateien ohne abzustürzen. Glück gehabt.
So, jetzt bin ich einmal gespannt, was mir so alles an Fehlern beim ersten Antesten durch die Lappen gegangen ist. :-) Aber KDE 4.5 ist wirklich gut geworden. KDE 4.5 ist hier nicht mehr langsamer als das parallel installierte KDE 3.5.10 unter OpenSuse 11.1. Ich benutze im übrigen den freien Radeon-Treiber ohne aktivierte Arbeitsflächeneffekte.
Der beschriebene Amarokabsturz mit nachfolgendem Xorg-Crash ereignet sich, wenn ich die Live-CD benutze, Amarok aufrufe und auf den einzigen vorhandenen Musikeintrag klicke, um ihn abzuspielen (siehe obigen Kommentar).
Kleinere KDE4-Fehler treten zwar auch nach einer Festplatteninstallation auf
(nur ein paar Beispiele: a) nach einem ersten KDE4-Update blieb KDM etwa drei Minuten als Standbild stehen, bevor KDE4 den Desktop zeigte, nach einem Neustart war das Problem allerdings verschwunden; b) der Arbeitsflächenumschalter war ursprünglich nur in der Lage, einen fünften virtuellen Desktop so hinzuzufügen, dass immer nur der "alte" Anzeigeraum der ersten vier virtuellen Desktops benutzt wurde, wodurch sich beim Hinzufügen weiterer virtueller Desktops die entsprechenden quadratischen Symbole bis hin zur Unkenntlichkeit verkleinerten (das wurde mit einem Update behoben); c) der Mauszeiger lässt sich noch immer nicht auf das KDE-Klassik-Design umstellen),
die dadurch verursachten Probleme sind aber marginal.
Das, was mir an Kubuntu 10.10 sehr gut gefällt, ist das dezente Standard-Branding. Das KDE-Startsymbol in der linken unteren Ecke ist das gleiche wie in jedem Standard-KDE und nirgendwo auf dem Desktop taucht das Wörtchen "Kubuntu" auf (Standard-Wallpaper "Ethais"). Sehr sympathisch.
Der Artikel ist doch eher enttäuschend. Es ist ja bekannt, dass der Autor einen bestimmten Desktop bevorzugt. Was eigentlich kein Problem darstellt, aber dann sollte er seine persönliche Meinung (Stichwort Symbole bzw. den Arbeitsfluss hemmende Effekte - welche Effekte eigentlich?) in einem vermeintlich objektiven Bericht besser ausklammern bzw. entsprechend kennzeichnen oder den Bericht auf seine Präferenzen beschränken. Auch Schlussfolgerungen zu ziehen, ohne sie wenigstens einmal überprüft zu haben, sind eher grenzwertig (Stichwort Absturz Okular auf anderen Systemen - noch dazu, wo die Pakete für Kubuntu erstellt worden sind). Letztlich sind dann solche Bemerkungen wie "Platz auf dem Bildschirm verschwenden" bei KPackageKit aus Sicht des Autors nur noch konsequent. Dabei spielt es auch keine Rolle mehr, dass schon auf dem Screenshot vom Software-Center eine nahezu gleich große (aus meiner Sicht sogar größere) Verschwendung von Platz zu erkennen ist. Sorry, aber es gab schon bessere Artikel vom Autor.
hjb hat im Epilog geschrieben, dass es ein Erfahrungsbericht ist. Und jeder macht andere Erfahrungen, denn: Erfahrung sind grundsätzlich subjektiv. Sich also bei einem von vornherein als subjektiven Artikel über dessen Subjektivität zu beschweren erscheint mehr doch etwas gekünstelt.
Nun, ein Erfahrungsbericht kann dann ja kaum Schlussfolgerungen über andere Systeme enthalten, wenn er diese Erfahrung gar nicht gemacht hat, oder? Nein, entscheidend ist nicht, wie ich den Bericht nenne, sondern was er vermittelt. Und das ist weniger eine Erfahrung als eine rein subjektive Bewertung. Was allemal zulässig ist. Dann sollte es aber auch so an den entsprechenden Stellen deutlich gemacht werden.
Das ist unsinn. Ein Erfahrungsbericht mit etwas, das schon immer doof fand und dann auch wieder doof findet (KDE) ist kein Erfahrungsbericht, sondern ein Vorurteil, das sich bestätigt. Das ist bei Vorurteilen üblich. Erfahrungen führen zu Lerneffekten, das ist etwas anderes. Der Artikel ist schlecht und peinlich. So etwas sollte bei Pro-Linux nicht veröffentlicht werden. Haben die keine Redaktion mit ein bischen Anstand?
Von meine Meinung am Do, 21. Oktober 2010 um 20:16 #
Ich habe den Artikel nicht gelesen und weis eigentlich auch nicht worum es geht. Aber Anhand der Kommentare kann ich nur sagen, dass das keine objektive Beurteilung ist, sondern mehr die Meinung des Autors. Und ich meine, damit bin ich nicht alleine!
Ich habe weder den Artickel noch die anderen Beiträge gelesen und habe überhaupt kein Plan aber ich kann sagen, dass du dich nicht mit dem Theam auseinandergesetzt hast und dass das keine objektive Bewertung ist sondern mehr deine meinung
Die Meinung zum rekonq-0.6.1 des Autors teile ich nicht. Ich benutze rekonq schon eine ganze Weile, jetzt unter openSUSE-10.3. Java bzw. Javascript können abgeschaltet werden oder auch nur Javascript für das Öffnen von Fenstern. die Cookie-Verwaltung ist identisch mit der vom Konqueror. Der rekonq teilt sich die Lesezeichen und Lesezeichenleiste mit dem Konqueror und nutzt KWallet. Im System installierte Plugins funktionieren ohne Probleme. Ein konfigurierbarer Werbefilter ist auch vorhanden. Mir fehlt nix am rekonq.
Von meister seines fachs am Fr, 22. Oktober 2010 um 07:55 #
da macht man sich die lts pointrelease1 drauf und wartet dann einfach bis zur nächsten lts pointrelease1. und schon ist die katze im sack. zwischenzeitlich kann man sich die zeit mit den problemen der deppen vertreiben, die nicht warten können
Von Kubuntu-User am Fr, 22. Oktober 2010 um 11:17 #
Auf fünf Kubuntu-10.10-Systemen (zwei neu installiert, zwei von 10.04 upgedated) habe ich die geschilderten Probleme mit Okular und mit dem Herunterfahren nicht nachvollziehen können. Hier hätte der Autor entweder mehr probieren müssen (vielleicht auch mal auf echter Hardware?!), oder etwas zurückhaltendere Schlüsse aus seinen Erfahrungen ziehen sollen.
Teilweise ist der Artikel ja wirklich brauchbar, aber teilweise hat er eine einseitige Anti-KDE- (oder Anti-Kubuntu-)Tendenz, wie sie eher in Troll-Postings gehört.
>> Es ist bekannt, dass Linux mehr Hardware unterstützt als jedes andere
>> Betriebssystem, und das überwiegend bereits im Standard-Lieferumfang. Ein Test >> ist damit überflüssig, und es wäre zu viel Aufwand für wenig Nutzen, eine
>> repräsentative Auswahl von Hardware zu beschaffen.
Freuen wir uns auf einen objektiven Bericht ohne Vorurteile
Da musste ich auch erst schmunzeln.
Allerdings stimmt es. Immerhin haben viele Betriebssysteme keine/wenige eigene Treiber an Bord. Windows kennt nur sehr wenig Hardware von Haus aus, MacOS auch nur die der Macs.
FreeBSD und co. sind zwar besser, aber immer noch weit hinter Linux.
Rechnet man die Treiber hinzu die es extern gibt, stimmts aber natürlich nicht.
Im Kernel sind ja auch noch treiber fuer wirklich antike sachen, die vielleicht noch in Museen benutzt werden, da ist es nicht verwunderlich wenn Linux wahrscheinlich wirklich der einzige Kernel der welt ist mit der groessten treiberauswahl
Tja, es stimmt. Aber es trifft die Sache nicht im Kern.
Windows-System haben nicht so viele Treiber im Kern, aber dafür alle vom Hersteller mitgeliefert oder im Download verfügbar.
Die Gesamtzahl der verfügbaren Treiber ist deswegen bei Linux geringer.
Altes Thema, altes Lied: Bei größerer Verbeitung von Linux, gäbe es mehr Treiber von Herstellern. Bei mehr Treibern von Herstellern, wäre die Verbreitung von Linux größer.
Insofern: Hilfreich ist die Verbreitung durch ubuntu/canonical.
Und das kannst du auch belegen, oder ist das nur eine Theorie, die du dir überlegt hast?
Das hängt sicher auch davon ab, was man unter Windows versteht. Ist damit nur das Desktop OS gemeint? Oder auch Windows CE?
Ganz zu schweigen von spezieller Server-Hardware.
Auf meinem Rechner läuft sämtliche Hardware out-of-the-box unter Linux. Allerdings unter dem parallel installierten Windows 7 gibt es weder Treiber für meine Audigy 4 noch für meine Logitech Webcam.
hmm... immer das alte Lied... langsam wird es langweilig. Ich habe auch so ein Gegenbeispiel: Logitech Webcam und Bluetooth-Dongel. Beide kamen natürlich mit einer Windows-Treiber CD. Und? Die sind dem Recycling zum Opfer gefallen, weil unter Linux gilt: anstecken und funktioniert.
Im Windows, das hier noch auf einer zweiten Platte herumdümpelt (natürlich das vielgepriesene Windows 7!!!) blinken die roten Ausrufezeichen in der Systemsteuerung...
Wenn man keinen Müll kauft, wie Lexmark-Drucker o.ä. hat man eh mehr Freude an seiner Hardware. Und sie läuft unter Linux. Obwohl o.g. Bluetooth Dongel auch nur ein Billigteil für 3 Geld Fuffzich war. Das hält aber Linux nicht davon ab, auch das zu unterstützen.
Ich habe mittlerweile mehr Vertrauen in Linux, mit "wird schon laufen" als in Windows mit "na mal sehen ob mir die Treiber CD nicht noch 10 »megageile« Toolbars installiert und ob es nicht vielleicht was zerschießt"
>> Es ist bekannt, dass Linux mehr Hardware unterstützt als jedes andere
>> Betriebssystem, und das überwiegend bereits im Standard-Lieferumfang. Ein Test >> ist damit überflüssig, und es wäre zu viel Aufwand für wenig Nutzen, eine
>> repräsentative Auswahl von Hardware zu beschaffen.
Diese FUD-Aussage ist eigentlich sehr fahrlässig, da sie taktischerweise Linux eine Gefallen tun will indem man sagt "Tja, wir unterstützen 1 000 000 Hardwareteile, während ihr nur 5000 könnt." Nun ja, das mag vielleicht so sein, aber
1. ist darunter eine Menge von Hardware zu verstehen die eben nicht unter die Sparte moderne Desktophardware ist (mal ehrlich, Bladesysteme, Amateur-Radios und MIDI-Keyboards sind eben für den 0815 Desktopuser nicht von Belangen). Da sind MS und Apple (die noch mehr, weil sie ja das meißte eh selber zur Vefügung stelln) im Vorteil. Und das muss man als verantwortliche Person doch sagen. Sonst sind wir dann eh die gleiche FUD-Kacke wie MS und Apple wenn wir Menschen an der Nase herumführen. Meiner Erfahrung nach funzt brandneue Hardware meißt nicht so gut, sondern wird erst einen Kernel später gut unterstützt. Glücklicherweise wir solche Hardware immer seltener -- selbst Broadcom hat jetzt open source Treiber :). Wer etwas ältere Hardware hat (also, mind. 6 Monate - 1 Jahr alt) ist meißt gut bedient.
2. ist Untestützung eher relativ. Ich bin froh wenn es funtzt und habe zBsp. kein Problem damit, dass wenn mein WLAN nicht geht einfach Debian Testing zu nehmen oder nen Kernel zu kompilieren. Oder wenn halt meien Webcam auf dem Kopf steht einfach eine Verknüpfung zu machen die dann libv4l1 anstatt 2 benutzt. Der Desktopbenutzer der eben seinen Laptop einfach anmacht wie eine Mikrowelle will damit nicht überfordert werden.
Gerade deswegen sollten wir doch besser sein als diese Sesselpupser bei MS und Apple und Leuten einfach klar sagen - "Hey, Linux ist frei, meißt kostenlos und sehr stabil, aber bitte bedenke, dass Treiber hin und wieder Mühe machen, Du vielleicht Probleme damit haben wirst einen Projektor in weniger als 1 Minute einzustellen oder vielleicht mal Formatierungsprobleme mit deinen .doc Dokumenten haben wirst."
... leider voll verbuggt ...
Unter Maverick Meerkat 10.10 versuche ich per GtkFileChooser (sei es unter Evince, Firefox, usw...) Dateien per Eingabe der URI (URL) zu öffnen. Besonders in Verbindung mit Favicon Picker 2 geht das nicht, da der GtkFileChooser keine URL's annimmt. Nach der Eingabe einer URL und der Bestätigung mit "Open" tut sich nix, da der GtkFileChooser hier wohl fehlerhaft ist.
Woher stammt eigentlich das, was Kubuntu seinen Nutzern als KDE4 anbietet, direkt von Upstream (also kde.org) oder direkt von Debian Testing/Sid?
Ich benutze noch KDE3 unter Debian Lenny und wenn ich den objektiven Bericht des Autors über diesen debianisierten KDE4 in Kubuntu so lese, dann graut es mir schon massiv vor dem kommenden Squeeze-KDE4.
Hm, die negativen Punkte von KDE4 bei Ubuntu (laut diesem Artikel): Okular stürzt ab, Symbole sind hässlich und Herunterfahren funktioniert nicht immer reibungslos. Unter Squeeze-KDE4 ist mir Okular noch nie abgestürzt und das Herunterfahren funktioniert auch perfekt. Bleiben noch die Symbole: Symbole sind immer geschmackssache und können auch geändert werden. Kurz: nach diesen Bericht braucht es dich gar nicht grausen
PS: Ubuntus 10.10-KDE ist eine neuere Version als in Squeeze vorhanden sein wird.
"Ubuntus 10.10-KDE ist eine neuere Version als in Squeeze vorhanden sein wird."
Testing (KDE 4.4) ist zur Zeit ja eingefroren, Debian Sid ist davon natürlich ebenfalls betroffen (KDE 4.4).
Kubuntus 10.10-KDE4 ist - wie Du sagst - neuer als das, was Debian gerade eingefroren hat.
Kubuntu 10.10 hat doch seinen KDE4 hoffentlich nicht aus Debian Experimental genommen?
Die KDE-Pakete von Kubuntu haben ubuntu in der Versionsnummer und im Changelog sind ausschließlich Kubuntu-Einträge. Unter KDE 4.4.5 in Squeeze tritt der Fehler nicht auf.
Wir "mergen" die Paket zum Anfang des Zyklus und aktualisieren sie danach natürlich.
Und was heißt das auf Deutsch?
Kubuntus KDE 4.5.x in Maverick stammt anscheinend direkt von Upstream und wurde mit w a s "gemergt"?
Mergen bedeutet grob gesagt, dass wir die Debian und Kubuntu Pakete vergleichen und die Debian Änderungen einpflegen. Ist zum Anfang des Zyklus zum Beispiel 4.4 aktuell und auch in Debian, dann wird gemerged und wird im Laufe des Zyklus 4.5 veröffentlicht, dann aktualisieren wir. Natürlich gibt es auch eigene Bugfixes und Veränderungen, wobei wir die auf einem Minimum halten. Also bevor jemand meckert, wir geben alles was wir machen an Upstream oder falls erforderlich auch an Debian weiter.
Zur Zeit gibt es aber wohl nichts zum Mergen, weil die Kubuntu 10.10-Version neuer ist als diejenige in Debian Testing/Sid.
Ihr mergt ja anscheinend nicht mit Debian Experimental (dort befindet sich eine Debian-KDE 4.5.x-Version).
Deinem letzten Satz entnehme ich, dass Debian normalerweise Eure Vorarbeit nicht übernimmt (?).
Da ihr an Upstream zurückgebt, möchte ich Euch auch bitten, eine entsprechende Liste auf Eurer Webseite zu veröffentlichen, auf die man verweisen kann, wenn es wieder einmal darum geht, ob (K)Ubuntu etwas an Upstream zurückgibt oder nicht. Die momentan existierende Ubuntu-Liste über erfolgte Kontributionen ist in dieser Hinsicht ein Witz, da sie nicht wirklich gepflegt wird.
Unter
https://wiki.ubuntu.com/Website/Content/UbuntuContributions
findet man zu Kubuntus Beiträgen Folgendes:
"System Settings, the KControl replacement, was maintained and pushed into KDE 4 by Kubuntu developers.
printer-applet, part of KDE 4.1, was written by Jonathan Riddell
guidance-power-manager, part of KDE extragear, was written by Kubuntu developers."
Das ist natürlich schon Einiges.
Wenn man sich aber z.B. die Gnome-Sektion dieses Dokumentes anschaut, so muß man sich fragen, was diese Liste eigentlich soll. Auch wenn Ubuntu in Gestalt von Canonical nur 1% der Upstream-Gnome-Kontributionen abliefert, dann ist das keinesfalls "Null", was man auch aus den Diagrammen des Gnome-Zensus ersehen kann.
Ich gehe deshalb davon aus, dass diese Liste nicht vollständig ist.
Ich bin der Meinung, dass in diese Kontributionsliste wirklich alles hinein muß, was an Kontributionen durch (K,X,...)Ubuntu-Entwickler erfolgt ist und dass diese Information nicht die Community alleine leisten kann, wie einem dieser Wiki-Eintrag doch nahe legt. Ich hoffe, dass der Hinweis
"This page is under development for Ubuntu website. Please add anything that would fit its purpose."
bedeutet, dass diese Liste endlich dorthin wandert, wo sie auch gelesen und entdeckt werden kann, nämlich auf die Ubuntu-Hauptseite.
Eine weitere wichtige fehlende Information ist die Anzahl der Bugs, die von der Ubuntugemeinschaft über Ubuntu an die jeweiligen Upstreams gemeldet wurden.
Die ganzen Infos sind auch wichtig für "Ubuntu-Nicht-Fans", da der vernünftige Kommentator nicht wieder besseres Wissen Unwahrheiten verbreitet.
Es muß natürlich heißen "wider besseres Wissen".
Die restlichen Schreib- und Tippfehler dürft ihr behalten.
> Symbole sind hässlich
Geschmacksfrage. Bei der Schere als Symbol für die Zwischenablage habe ich mich aber auch schon gefragt, wer den Mist verzapft hat.
Meine letzte Evaluation (OpenSUSE 10.3 mit KDE 4.5.2) ist aber nicht deswegen negativ, sondern wegen der immer noch viel zu häufigen (teils reproduzierbaren) Abstürze. KDE 4: Optisch aufgebretzelt, immer noch Beta-Qualität -> Tonne.
s/10.3/11.3/
Kann es sein, dass dein Einstellungsverzeichnis .kde4 von einer älteren KDE 4 Version stammt und du nun auf KDE 4.5 gewechselt bist. Ich hatte wegen falschen/veralteten Einstellungen schon öfter Probleme (KNetworkmanager wollte nicht mehr starten, verschiedenste Abstürze) und musste deshalb auch schon öfter dieses Verzeichnis löschen (Achtung wegen Passworter usw. !)
KDE 4.5 läuft bei mir auf drei verschiedenen Maschinen völlig stabil, aber eben nur mit frischem .kde4 Verzeichnis.
Nein. Allesamt frische Installationen auf verschiedenen Modellen eines namhaften Herstellers.
Auf dem OpenSuse 11.3-Desktop gibt es etwas, was "Online-Hilfe" heißt. Darauf habe ich in der klassischen Desktopansicht genau einmal geklickt. Daraufhin begann Konqueror anscheinend unendlich viele Konquerorfenster zu öffnen, bei etwa 30 konnte ich rein optisch auf der Taskleiste nicht mehr mitzählen. Abmelden konnte ich mich aber noch.
irgendwas muss aber bei der Kubuntu-Entwicklung immer wieder schieflaufen. Ich habe hier OpenSuse 11.3 am Laufen, erst mit dem in der Distri eh vorhandenen KDE 4.4.4 und nun mit KDE 4.5.2 aus dem OpenSuse Build Service. Und ich bin dermaßen begeistert, wie schnell, stabil und nett anzusehen diese KDE-Versionen sind!
Früher hatte ich auch Kubuntu und fand speziell 9.04 ziemlich gut, aber was danach kam... unbeschreiblich. Sorry, aber wenn ich bei KDE arbeiten würde, würde ich Kubuntu verklagen, wegen Rufschädigung. Die Krönung für mich war 10.04 und 10.10 tue ich mir gar nicht erst an. Ich habe unter den von mir bisher verwendeten Linux-Systemen noch nie so viele Abstürze erlebt, wie unter Kubuntu 10.04 und nach dem, was man hier im Bericht liest, wird das unter 10.10 nicht anders sein. Okular war nämlich auch bei mir unter Kubuntu 10.04 das Sorgenkind Nr. 1.
Was solls, die Bugtracker auf Launchpad sind voll, genug zu tun... und für mich heißt es "Time to move on". OpenSuse FTW!
+1 für OpenSUSE 11.3 unter KDE (obwohl ich eher kein Fan von YaSTs Paketmanagement bin).
YaST ist einfach genial. Viel Schneller als Synaptic: kurze Ladezeiten beim Auffrischen der Paketquellen, schnelle Suchfunktion, schnelle Installation, einfaches Hinzufügen von Paketquellen... und die Systemverwaltung mit YaST zeigt, wie professionell so etwas vonstatten gehen kann. Da können alle anderen Distris und Windows mal schön locker einpacken. (K)Ubuntu sowieso mit ihrem config-Dateien-Gebastel.
Und wo ich dabei bin: KPackagekit ist ja wohl der Witz in Tüten! Eine Softwareverwaltung, die selbst alle Nase lang abstürzt... ja, der vertraue ich die Installation von Paketen an.... ja sicher... damit das so schon zerfrickelte System noch instabiler wird, durch halb-installierte Pakete.
Yast ist schnell? Da habe ich aber andere Erfahrungen gemacht mit OpenSuSE (10.3 oder so). Wenn dir Synaptic zu langsam ist, dann verwende doch das reine apt-get update und apt-get dist-upgrade zum updaten. Für das Hinzufügen von Paketquellen kann man ja einfach die sources.list editieren. Und ein Editor starten und ein Update via apt-get ist meiner Meinung nach nicht zu langsam.
nein, ich habe keine Lust auf das Frickeln in config-Dateien. Das ist der Punkt. Ein modernes Betriebssystem muss ohne das herumpfuschen in config-Dateien auskommen.
YaST ist schnell, ja, verdammt. Es ist schnell. Und es ist richtig gut. Genau wie das Gesamtsystem "Open Suse 11.3" verdammt gut ist und dieses Kubuntu mal locker in die Tasche steckt.
Und in OpenSuse werde ich sicher nicht apt-get verwenden
Tja... naja... 10.3 ist auch eine total moderne Version... die wird zwar nicht mal mehr mit Updates unterstützt, aber die kann man locker noch als Referenz heranziehen.
Bei so etwas fehlen mir echt die Worte.
Mittlerweile musst Du apt-get aber mit Zypper vergleichen und dann Synaptic mit Yasts Paketverwaltung.
Und in diesem Vergleich schneidet in punkto Schnelligkeit und Bedienungsfreundlichkeit das Duo Zypper/Yast sehr gut ab.
Zypper ist als Kommandozeilenwerkzeug fast genauso exquisit wie apt-get. Für OpenSuse war das die beste Entwicklung seit langem, seit diesem ZMD-"Unfall" in SuSE 10.1, der erst mit dem Erscheinen von OpenSuse 11.0 vollständig überwunden gewesen ist.
Wenn's in der Zwischenzeit schneller geworden ist, dann sag ich nichts mehr.
Die von Dir beobachtete Langsamkeit kann daher rühren, dass OpenSuse kleine Delta-RPMs zur Aktualisierung verwendet, die nach dem Herunterladen sogleich mit applydeltarpm angewendet werden.
Das fordert natürlich die CPU.
Da Zypper/Yast zur Zeit noch das Schema "Delta-rpm herunterladen, Delta-RPM anwenden, gerade neu erhaltenes rpm-Paket installieren" benutzen, um danach mit dem Herunterladen des nächsten Delta-rpms fortzufahren, kann dieser Vorgang mitunter dauern.
Die Tatsache, dass selbst bei vielen DSL-Breitbandzugängen eine rigide Traffic-Begrenzung vorherrscht (u.a. in Australien) lässt aber keine andere Wahl. Die betroffenen Nutzer sind z.B. bei OpenOffice-Updates für solche kleinen Delta-rpms überaus dankbar, weil sie in den beschriebenen Situationen wirklich Geld sparen.
Es wird zur Zeit auch diskutiert, die Delta-rpms in Zukunft in einem Rutsch herunterzuladen, weil dies Nutzern von Schmalbandanschlüssen, die Minutenpreise zahlen müssen, noch mehr entgegen kommt.
Ich habe unter Squeeze KDE 4.3, sowie 4.4 benutzt und muss sagen, dass, obwohl es spübar langsamer als die 4.5 Reihe unter Arch ist (aber das kann ja auch zBsp an den neueren nvidia Proprietary Treibern oder dem neueren XOrg liegen), es doch sehr stabil lief. Was mich genervt hat: Die Systemsteuerung wollte mir nicht so recht erlauben als sudo mein KDM zu wählen (Ich musste als root einloggen, was KDM widerum verweigert, also hab' ich dann ohne DM eingeloggt...). Das anfängliche wählen eines Themas für GTK Programme nervt auch. Aber sonst alles klar. Ich habe auch nie ohne Desktopeffekte getestet, mag ja sein, dass das dann flüssiger läuft. Außerdem gibt es ja immer noch Trinity:
http://trinity.pearsoncomputing.net/
"Am Ende der Installation kam es bei mir in mindestens zwei Fällen zu einem Absturz des Installationsprogramms. (...) Das ist ein Fehler, der Canonical gemeldet werden sollte, sofern er noch nicht bekannt ist."
Ähm, definitiv sollte der Fehler gemeldet werden. Aber das kann auch nur die Person machen, bei der der Fehler aufgetreten ist. Daher bitte: Selber Fehler melden und damit freie Software verbessern.
Danke
Sicher... dazu müsste ich es aber nochmal reproduzieren, und das dauert.
Zu viel persönliche Meinung und Dinge, die bei mir nicht auftreten. Die "Vermutungen" gehören da nicht rein.
ganz meine Meinung...ich hatte unter KDE und bei der Installation keinerlei Probleme. einzig die von mir nachinstallierten Kontact2 Komponenten ärgern mich ein wenig, aber sind trotz beta-status gut nutzbar.
Ach ja Kwin und intel-Grafik war noch ein Problem, was sich aber mit kurzer Forensuche auch lösen ließ.
Dem Stimme ich absolut zu. Ich frage mich wirklich, wass an diesem "Fach"-Artikel richtig "objektiv" sein soll.
Aber das mit den Treibern schießt den Vogel bei weitem ab. Viel Hardware funktioniert zwar, aber die Frage ist nur: "WIE sie funktioniert?!?!" Tendenziell funktioniert die Hardware grauenvoll mit den Standardtreibern. WLAN zu lahm - neu machen, Sound knackt - neu machen, 3D Beschleunigung zu langsam - treiber wechseln.
Mir ist bisher noch kein Desktop-System unter die Augen getreten wo man nicht den Treiber selbst neu kompilieren durfte oder Kernel backen musste.
Darum geht es doch gar nicht.
Es geht darum, dass dem Autoren nicht der Hardwarepool zur Verfügung steht, den er bräuchte, um über die Hardwarekompatibilität Ubuntus eine vernünftige Aussage zu treffen.
Ganz schlimm wäre es, wenn der Autor zufällig auf einer Hardwareausstattung testen würde, die mit Ubuntu leider nicht zuverlässig funktioniert.
Das Geschrei, dass dann hier ausbrechen würde, möchte man wohl jedem Menschen ersparen.
Also testet man besser in einer virtuellen Maschine.
In früheren Prolinuxberichten zu SuSE 6.x oder Red Hat 7.x, die man im Archiv einsehen kann, sind solche Hardwareprobleme immer wieder aufgetreten. Nur: Nutzer mit anderen Hardwarekombinationen interessieren diese Spezifika nicht. Für sie wäre ein solcher "hardwareabhängiger" Bericht dann eher "wertlos".
Nur ein Beispiel:
Ich habe hier eine alte Geforce4MX-Grafikkarte in einem Rechner, die mit Nouveau nur mit katastrophal verzerrtem Bildschirm läuft.
Stell Dir einmal vor, man würde Ubuntu Maverick darauf testen.
In den Ubuntuforen erhält man für gewöhnlich den nomodeset-Tipp, dann fährt Ubuntu wenigstens hoch und man kann dann den proprietären NVidia-Treiber installieren.
Nur: Der neueste zweite Legacy-NVidia-Treiber, der für diese Geforce4MX-Karte verfügbar ist, läuft nicht mit der Xserver-Version 1.9 in Maverick.
Also bleiben nur vesa und nv.
Das wäre ein Bericht.
Ein Ubuntu-in-die-Tonne-treten mit Ansage.
Ich habe eine Geforce 4 MX unter Maverick mit Nouveau im Einsatz. Der Bildschirm ist weder verzerrt, noch sonst wie schlechter als mit dem Nvidia Treiber.
3D, bzw GL läuft allerdings extrem bescheiden. Beispiel Dreamchess, so gut wie unbenutzbar.
Geforce4MX-Grafikkarten funktionieren zwar in der Regel mit Nouveau.
Eine Geforce4MX440 onboard (NV18) liefert aber das von mir beschriebene Fehlerbild (dieser Chip wurde sehr oft mit NForce2-Chipsätzen ausgeliefert). Der Fehler tritt laut Ubuntu-Bugzilla und -Forenpostings auch mit Geforce4MX440-Nicht-Onboard-Karten auf.
Das Nouveauprojekt hat keinerlei Hardwareinformationen vom Hersteller der Grafikkarten, nur so kommt so etwas zustande, frei nach dem Motto, die Hardware, die das Nouveau-Projekt nie gesehen hat, muß nicht unbedingt mit Nouveau funktionieren.
Ich habe mittlerweile sämtliche NVidias verbannt, ich bin es leid.
Der oben beschriebene Chip wird zum Glück abgeschaltet, sobald man eine zusätzliche Grafikkarte (hier ATI Radeon) in den eigentlich freien AGP-Slot steckt.
Anscheinend funktionieren dann die experimentellen Nouveau3D-Treiber nicht mit Deiner Grafikkarte?
Google Earth z.B. läuft immerhin mit Nouveau-2D und Software-Mesa, langsam zwar, aber es läuft.
An dem zur Zeit nicht vorhandenen NVidiatreiber für Geforce4MX-Karten unter Maverick sieht man auch, was das Hauptproblem proprietärer Grafikkartentreiber ist.
>> Mir ist bisher noch kein Desktop-System unter die Augen getreten wo man nicht den Treiber selbst neu kompilieren durfte oder Kernel backen musste.
Hä? Du hast bis jetzt auf jedem System den Kernel bzw. Treiber kompiliert? Wo hast du bitte den Quellcode von Windows/Mac OS her und wann kann man den von TPB herunterladen?
Eventuell meintest du statt Desktop-System Desktop-Linux oder Linux-System (...).
win2k gibts bei TBP aber nur in teilen
Kauft du exklusiv bei Broadcom ein?
kubuntu wird wieder schlecht geredet, ohne eine objektive Begründung zu bringen.
Ich habe Kubuntu zwar nie schlechtgeredet, aber hier die objektive Begründung:
- wie auch Xubuntu & Co. gibt es auch für Kubuntu weniger Entwickler und Tester, als für das Haupt-Ubuntu (8.04 ist nichtmal als LTS erschienen!)
- es gibt einfach mehr Bugs, etwa im Paketmanager, zumindest war es bei 8.xx so, dass der Paketmanager wesentlich schlechter in der Usuability war und auch leichte GUI-Bugs da waren
- Updating funktioniert noch schlechter als bei Haupt-Ubuntu, aus eben den beiden obigen Gründen
> wie auch Xubuntu & Co. gibt es auch für Kubuntu weniger Entwickler und Tester, als für das
> Haupt-Ubuntu
Die brauchen das KDE ja auch nur von Debian übernehmen. Viel Entwickleraufwand ist da nicht nötig. Der Grundunterbau ist bei Ubuntu und kubuntu ja gleich.
> es gibt einfach mehr Bugs, etwa im Paketmanager,
In beiden Fällen benutze ich apt-get und wüsste nicht wo da ein Unterschied zwischen Ubuntu und kubuntu besteht
> Updating funktioniert noch schlechter
Ist mir noch nicht aufgefallen
>In beiden Fällen benutze ich apt-get und wüsste nicht wo da ein Unterschied zwischen Ubuntu und kubuntu besteht.
Wäre doch aber schön wenn man einfach nur das Software Center auch unter Kubuntu als Standard nehmen würde. Außerdem, wer nicht weißt wie man output an der Konsole mit grep pipet (und das ist eben die Zielgruppe Ubuntus), wird nicht so glücklich über apt-get sein wenn er mal 50.000 libraries deinstallieren will.
Ich hatte hier eben kurz die Kubuntu 10.10-LiveCD am Laufen.
KDE hat einen guten Eindruck gemacht, Rekonq ist sehr schnell und lässt sich im übrigen genauso wie Konqueror en detail konfigurieren. Das ging alles solange gut, bis ich Amarok öffnete und die von Amarok selbst mitgebrachte und angezeigte 40 Sekunden-Musikdatei abspielen wollte.
Es gab sofort einen Xorg-Crash und außer einem schwarzen Bildschirm mit Monitor-LED-Geblinke ward nichts mehr gesehen.
Irgendwie lustig.
Das Soundsystem scheint eine große Schwäche Ubuntus zu sein. Wie das allerdings zu einem totalen Xorg-Crash führen kann, das wird wohl das Geheimnis Ubuntus bleiben.
Ich benutze kubuntu10.10 schon seit dem 10.10 als Festinstallation und konnte bisher keine Fehler dieser Art finden, auch nicht bei Amorak. Das Soundystem war bei Ubuntu und kubuntu schon immer eine schwachstelle. Aber bei kubuntu10.10 funktionierte es bei mir zu erstenmal sofort. Ubuntu10.10 hab ich jetzt nicht ausprobiert.
Ich habe das Soundproblem gerade noch einmal reproduziert.
Der Kubuntu-Sound funktioniert, wie z.B. die Systemklänge.
Es sind Amarok und auch Dragonplayer, die auf der Live-CD nicht funktionieren. Im Gegensatz zu Dragonplayer crasht aber Amarok leider und nimmt das ganze Kubuntu dabei mit.
Jetzt stellt sich natürlich die Frage, ob das nach einer Festplatteninstallation nicht ganz genau so wäre.
Kubuntu erinnert mich übrigens vom Aussehen und der Schnelligkeit her (ohne aktivierte Arbeitsflächeneffekte) nicht an Ubuntu, sondern eher an Slackware 13.1.
Vielleicht hast du einen Hardwareeffekt. Bei mir ist kubuntu-10.10 noch nie abgestürzt, Amorak eben so wenig. Dragonplayer verwende ich nicht, ich verwende vlc.
Debian Lenny und OpenSuse 11.1 funktionieren auf meinem System einbahnfrei.
Dann teste ich eine Kubuntu-LiveCD, rufe dann nach bis dahin gelungenem Antesten Amarok auf, was zum Totalcrash der LiveCD-Session führt und dann kommst Du vorbei und erzählst irgendetwas von einem nicht vorhandenen Hardwaredefekt.
Es gibt IMO nichts Schlimmeres als diese "Bei mir ist Kubuntu, Windows, MacOSX (...) ist mir noch niemals abgestürzt"-Fraktion.
Im Hinblick auf den Bericht des Autors gehen solche Äußerungen (nicht Deine, sondern andere, s.u.) sogar so weit, diesen indirekt der Lüge zu bezichtigen, nur weil ihm u.a. Okular beim Testen abgestürzt ist.
Wenn ich mir die Ubuntu-Bugzilla so ansehe, wundert mich ohnehin nichts mehr. Man braucht nur kurz dort hineinzuschauen, um zu sehen, wie gut alles funktioniert.
Bevor Du Kubuntu 10.10 nicht wirklich installierst, wirst Du auch den Grund für den Amarokfehler auf Deinem System kaum herausfinden können.
So, ich habe Kubuntu 10.10 auf meiner Festplatte installiert.
Es ist der schnellste KDE 4, den ich je gesehen habe.
Zu den Fehlern, die ich mit der Live-CD beobachten konnte:
1. Amarok funktioniert und stürzt nicht ab, ganz im Gegensatz zu dem, was zuvor während meiner LiveCD-Sitzung passiert ist. Es handelt sich somit um ein Problem der LiveCD.
2. Dragonplayer spielt jetzt zwar immer noch keine wav-Dateien ab, wohl aber ogg-Dateien. Im Gegensatz zur LiveCD-Sitzung gibt er also Töne von sich.
3. Okular öffnet pdf-Dateien ohne abzustürzen. Glück gehabt.
So, jetzt bin ich einmal gespannt, was mir so alles an Fehlern beim ersten Antesten durch die Lappen gegangen ist. :-)
Aber KDE 4.5 ist wirklich gut geworden. KDE 4.5 ist hier nicht mehr langsamer als das parallel installierte KDE 3.5.10 unter OpenSuse 11.1.
Ich benutze im übrigen den freien Radeon-Treiber ohne aktivierte Arbeitsflächeneffekte.
Kubuntu ist ganz sicher nicht fehlerfrei, aber anscheinend bist du hier der einzige der diese merkwürdigen Absturzprobleme hat;-)
Der beschriebene Amarokabsturz mit nachfolgendem Xorg-Crash ereignet sich, wenn ich die Live-CD benutze, Amarok aufrufe und auf den einzigen vorhandenen Musikeintrag klicke, um ihn abzuspielen (siehe obigen Kommentar).
Kleinere KDE4-Fehler treten zwar auch nach einer Festplatteninstallation auf
(nur ein paar Beispiele:
a) nach einem ersten KDE4-Update blieb KDM etwa drei Minuten als Standbild stehen, bevor KDE4 den Desktop zeigte, nach einem Neustart war das Problem allerdings verschwunden;
b) der Arbeitsflächenumschalter war ursprünglich nur in der Lage, einen fünften virtuellen Desktop so hinzuzufügen, dass immer nur der "alte" Anzeigeraum der ersten vier virtuellen Desktops benutzt wurde, wodurch sich beim Hinzufügen weiterer virtueller Desktops die entsprechenden quadratischen Symbole bis hin zur Unkenntlichkeit verkleinerten (das wurde mit einem Update behoben);
c) der Mauszeiger lässt sich noch immer nicht auf das KDE-Klassik-Design umstellen),
die dadurch verursachten Probleme sind aber marginal.
Das, was mir an Kubuntu 10.10 sehr gut gefällt, ist das dezente Standard-Branding. Das KDE-Startsymbol in der linken unteren Ecke ist das gleiche wie in jedem Standard-KDE und nirgendwo auf dem Desktop taucht das Wörtchen "Kubuntu" auf (Standard-Wallpaper "Ethais").
Sehr sympathisch.
objektive Begründung: weil es einfach schlecht ist.
Der Artikel ist doch eher enttäuschend. Es ist ja bekannt, dass der Autor einen bestimmten Desktop bevorzugt. Was eigentlich kein Problem darstellt, aber dann sollte er seine persönliche Meinung (Stichwort Symbole bzw. den Arbeitsfluss hemmende Effekte - welche Effekte eigentlich?) in einem vermeintlich objektiven Bericht besser ausklammern bzw. entsprechend kennzeichnen oder den Bericht auf seine Präferenzen beschränken. Auch Schlussfolgerungen zu ziehen, ohne sie wenigstens einmal überprüft zu haben, sind eher grenzwertig (Stichwort Absturz Okular auf anderen Systemen - noch dazu, wo die Pakete für Kubuntu erstellt worden sind). Letztlich sind dann solche Bemerkungen wie "Platz auf dem Bildschirm verschwenden" bei KPackageKit aus Sicht des Autors nur noch konsequent. Dabei spielt es auch keine Rolle mehr, dass schon auf dem Screenshot vom Software-Center eine nahezu gleich große (aus meiner Sicht sogar größere) Verschwendung von Platz zu erkennen ist. Sorry, aber es gab schon bessere Artikel vom Autor.
hjb hat im Epilog geschrieben, dass es ein Erfahrungsbericht ist. Und jeder macht andere Erfahrungen, denn: Erfahrung sind grundsätzlich subjektiv. Sich also bei einem von vornherein als subjektiven Artikel über dessen Subjektivität zu beschweren erscheint mehr doch etwas gekünstelt.
Sollte eigentlich:
Sich also bei einem von vornherein als subjektiven deklarierten Artikel über dessen Subjektivität zu beschweren erscheint mir doch etwas gekünstelt.
heißen.
Nun, ein Erfahrungsbericht kann dann ja kaum Schlussfolgerungen über andere Systeme enthalten, wenn er diese Erfahrung gar nicht gemacht hat, oder? Nein, entscheidend ist nicht, wie ich den Bericht nenne, sondern was er vermittelt. Und das ist weniger eine Erfahrung als eine rein subjektive Bewertung. Was allemal zulässig ist. Dann sollte es aber auch so an den entsprechenden Stellen deutlich gemacht werden.
Das ist unsinn. Ein Erfahrungsbericht mit etwas, das schon immer doof fand und dann auch wieder doof findet (KDE) ist kein Erfahrungsbericht, sondern ein Vorurteil, das sich bestätigt. Das ist bei Vorurteilen üblich. Erfahrungen führen zu Lerneffekten, das ist etwas anderes. Der Artikel ist schlecht und peinlich. So etwas sollte bei Pro-Linux nicht veröffentlicht werden. Haben die keine Redaktion mit ein bischen Anstand?
Das ist kein Vorurteil [1], weil er ja offensichtlich mit KDE arbeitet/gearbeitet hat. Ihm gefällt es eben einfach nicht.
[1] "Alltagssprachlich ist ein Vorurteil ein vorab wertendes Urteil, das eine Handlung leitet und in diesem Sinne endgültig ist." (Quelle: Wikipedia)
Ich habe den Artikel nicht gelesen und weis eigentlich auch nicht worum es geht. Aber Anhand der Kommentare kann ich nur sagen, dass das keine objektive Beurteilung ist, sondern mehr die Meinung des Autors.
Und ich meine, damit bin ich nicht alleine!
YMMD!
Ich habe weder den Artickel noch die anderen Beiträge gelesen und habe überhaupt kein Plan aber ich kann sagen, dass du dich nicht mit dem Theam auseinandergesetzt hast und dass das keine objektive Bewertung ist sondern mehr deine meinung
Die Meinung zum rekonq-0.6.1 des Autors teile ich nicht. Ich benutze rekonq schon eine ganze Weile, jetzt unter openSUSE-10.3. Java bzw. Javascript können abgeschaltet werden oder auch nur Javascript für das Öffnen von Fenstern. die Cookie-Verwaltung ist identisch mit der vom Konqueror. Der rekonq teilt sich die Lesezeichen und Lesezeichenleiste mit dem Konqueror und nutzt KWallet. Im System installierte Plugins funktionieren ohne Probleme. Ein konfigurierbarer Werbefilter ist auch vorhanden. Mir fehlt nix am rekonq.
Gruß Maik
da macht man sich die lts pointrelease1 drauf und wartet dann einfach bis zur nächsten lts pointrelease1.
und schon ist die katze im sack.
zwischenzeitlich kann man sich die zeit mit den problemen der deppen vertreiben, die nicht warten können
just my 2 cents
Auf fünf Kubuntu-10.10-Systemen (zwei neu installiert, zwei von 10.04 upgedated) habe ich die geschilderten Probleme mit Okular und mit dem Herunterfahren nicht nachvollziehen können. Hier hätte der Autor entweder mehr probieren müssen (vielleicht auch mal auf echter Hardware?!), oder etwas zurückhaltendere Schlüsse aus seinen Erfahrungen ziehen sollen.
Teilweise ist der Artikel ja wirklich brauchbar, aber teilweise hat er eine einseitige Anti-KDE- (oder Anti-Kubuntu-)Tendenz, wie sie eher in Troll-Postings gehört.
zwei neu installiert, zwei von 10.04 upgedated
sollte heißen:
zwei neu installiert, drei von 10.04 upgedated
Da fällt mir ein: Mal einen RAM Test gemacht?
Abstürze kommen auch ohne defektes RAM vor.
Hi!
Grüße,
hjb
Ist es nicht erschreckend?
"Sie" glauben Dir einfach nicht.