gibt es jetzt einen definitiven Termin. Bei Debian kann es eben dauern, aber das Warten lohnt sich. Ich bin als Laie sehr zufrieden mit Debian. Die Installation ist einfach und die Updates einzuspielen ist absolut simpel. Ich nutze Debian auf dem Desktop mit wachsender begeisterung. Von wegen vor allem eine Server-Distri. Bestimmt gut als Server, aber eben auch auf dem Desktop.
na ja man sieht schon den "Kampf" der Debianer diesen Monat mehr Bugs zu fixen als neue auftauchen. Habe schon damit gerechnet dass es bald soweit ist. http://bts.turmzimmer.net/graph-small.png
ACK! Ich nutze Linux seit etwa 2001, anfangs wechselnde Distris. Auch ich komme immer wieder auf Debian am Desktop zurück und bin damit mittlerweile fest im Sattel & voll zufrieden. Freu mich auf Squeeze, auch wenn ich's in ner Vm schon eine Weile beobachte.
Da stimme ich zu, allerdings werd ich nach gut eineinhalb Jahren Debian Stable wieder Richtung sidux/aptosid schwenken. Alte Programme und vor allem zu Zeiten von Lenny jedes Mal dieser Kampf mit Totem um den Internetstream der heute-show hinterlassen dann doch einen grausligen Beigeschmack.
Von M wie Meikel am Mi, 19. Januar 2011 um 18:46 #
> Bei Debian kann es eben dauern, aber das Warten lohnt sich.
Was lohnt sich denn? Veraltete Software schon beim Release, der Support ist mit RHEL oder SLES nicht vergleichbar, Paragraphenreiter statt Anwender-orientiert.
> Die Installation ist einfach und die Updates einzuspielen ist absolut simpel.
Das gilt für andere Disitributionen auch. Wobei mich mal interessieren würde, was alleine schon dank veralteter Treiber bei der Installation von lenny einfacher ist als bei einer anderen Distribution. Und mit Squeeze kommt dann noch der Spass mit "unfreier" Firmware dazu.
> Ich nutze Debian auf dem Desktop mit wachsender begeisterung.
Was ist z.B. an Iceweasel 3.0.6-3 so toll im Vergleich mit einem aktuellen Firefox 3.6.13 (z.B. in Ubuntu LTS)?
Von Neuer_ohne_Login am Mi, 19. Januar 2011 um 21:11 #
Hallo Du,
die Software in Debian stable funktioniert dafür aber auch, und braucht dann natürlich im Grunde keinen Support mehr. Was die Grundsatztreue angeht, so ist RHEL da nicht weniger gut als Debian. Wenn etwas rechtlich auch nur ein wenig zweifelhaft ist, dann ist es nicht dabei. Ob Mono, ob MP3, ob KDE damals, die waren immer die wirklich konsequenten.
Und veraltet? Mein Debian Testing (Squeeze) und auch Debian Lenny schlagen RHEL 5.x schon ziemlich lange in jeder Hinsicht. Was meinst, Du wann ein RHEL 7 kommen wird? Man kann Redhat alles vorwerfen, aber Versionitis, und aktuelle Software sicher nicht. Ich glaube, Du findest da Unterschiede, die es so in der Form nicht gibt.
Dann die Installation und Backports. Korrekt, für RHEL wird immer neue Hardware unterstützt, und Treiber werden eingepflegt, und das ist ein Riesenhindernis, wenn man Systeme liefern muss, die gleiche Software haben, einem aber immer die Hardware abhanden kommt, weil der PC-Zyklus so schnell tickt. Hier sehe ich das Existenzrecht von Redhat.
Zu Iceweasel 3.0.6 kann ich Dir Nichts sagen, ich habe hier auf Squeeze einen 3.5.16. Aber wenn ich wollte, würde ich "apt-get install iceweasel -t experimental" machen, und hätte dann 3.6.13. Ich weiß nicht, was ich verpasse. Also ich weiß es schon, aber nicht aus eigener Erfahrung. Aber ich glaube ohne leben zu können, und ich vertraue Debian, dass sie 3.6.x in Debian Testing so ca. im März haben werden, wenn es nicht zuviele Bugs hat.
Am besten kann ich das mit openOffice.org begründen. Neue Versionen davon sind immer toll, nur geht das irgendwas wichtiges nicht mehr. Ich warte lieber, bis keine Debian Debugs mehr den Einzug in Debian Testing verhindern, dann ist es sogar recht benutzbar. Das bedeutet natürlich, dass ich mal ein paar Monate mehr warte, aber es bedeutet auch immer, dass ich keine Regressionen oder nur wenige habe (als immer Debian Testing verfolgender).
Mit Debian Squeeze kommt ja dann auch Backports dazu. Wenn jemand das auch dem Desktop einsetzt, vermute ich mal, wird er seinen Iceweasel auch aktualisiert bekommen, ohne das Debian Testing "Risiko" einzugehen. Für Lenny bekommt man ja auch den 3.5.16 installiert, wenn man Backports aktiviert.
Und für mich ist natürlich Xfce 4.8 ein wichtiges Thema. Nur bei Debian finde ich da die Hoffnung, das auf einer stabilen Basis laufen lassen zu können.
Mein Desktop hat meist eine Uptime, die nur von neuen Kerneln unterbrochen wird. Will man wirklich rausfinden, ob das mit dem neuesten X-Server und so weiter, auch so wäre?
Also ich bin den Leuten, die Fedora einsetzen, total dankbar dafür, was sie leisten. Mir reicht es aus, wenn ich selbst Freie Software entwickele, und der Desktop dabei nicht stört. Wenn jetzt 3.5.x von Firefox so inakzeptabel Scheisse ist, dann weißt Du nur noch nicht, wie inakzeptabel 3.6.13 ist, weil Du halt 4.0 noch nicht gesehen hast.
Ich kann z.B. nicht erkennen, was jetzt an Xfce 4.6 unbenutzbar wäre, nur weil es 4.8 gibt. Und KDE 4.0 hat ja bekanntermassen nicht sofort 3.5 schlecht gemacht.
> Mein Debian Testing (Squeeze) und auch Debian Lenny schlagen RHEL 5.x schon ziemlich lange in jeder Hinsicht.
Das stimmt natürlich. Im Hinblick auf den Supportzeitraum hat er aber (leider) absolut recht. Debian Lenny wird nur noch bis Februar 2012 unterstützt, dann ist man gezwungen zu aktualisieren. Drei Jahre sind für eine Distribution, deren Benutzer nicht müde werden diese für den Unternehmenseinsatz zu propagieren, dann doch recht wenig.
> Will man wirklich rausfinden, ob das mit dem neuesten X-Server und so weiter, auch so wäre?
Warum nicht? Nur weil andere Distributionen aktuellere Software einsetzen, heißt das noch lange nicht, dass sie zwangsläufig instabiler sind.
> Ich kann z.B. nicht erkennen, was jetzt an Xfce 4.6 unbenutzbar wäre, nur weil es 4.8 gibt.
Unbenutzbar wird es dadurch natürlich nicht, nur wird der eine oder andere Benutzer solche Sachen wie funktionierendes DnD bei Anwendungsstartern und andere Nettigkeiten schon vermissen.
Von Neuer_ohne_Login am Do, 20. Januar 2011 um 00:06 #
Hallo Du,
Lenny wird doch jetzt erstmal zu "oldstable" und dann noch supported, bis _noch_ ein neues "stable" rauskommt, oder ist das nicht mehr so?!
Was den X-Server angeht, beliebst Du wohl zu scherzen. Neue X-Server brauchen in Debian regelmässig sehr sehr lange, bis sie auch nur annähernd fehlerarm sind. Ein neues Xorg einzusetzen ist dank der mangelhaften Tests Upstream praktisch die Garantie für schwerwiegende Bugs.
Stabil oberhalb eines gewissen Niveaus (die letzten 3% ?) kann ein System mit Xorg und Linux-Kernel m.E. nur sein, nachdem man es über viele Monate ausprobiert und verbessert hat.
Und neue Features sind nett. Ich bin total heiß auf Xfce 4.8. Aber im Paket mit einem neuen Xorg, würde ich es nicht wollen. Ich habe derzeit ein "Debian Testing", und verfolge aus "Debian Unstable" dann "python-pyside", "uwsusp", "wine" (Eve Online) und aus "Debian Experimental" den Kernel 2.6.36, wobei man sagen muss, dass ich den ersten Oops seit langem mit 2.6.35 hatte, also gebrannt bin, dann "python2.7", sehr wichtig für meine Entwicklungen, "g++-4.6" als Vorschau und "g++-4.5" für eine meiner Entwicklungen. Sobald es geht würde ich Xfce 4.8 probeweise dazu nehmen, und wenn es nicht so gut ist, wieder auf 4.6 downgraden.
Ich interessiere mich also schon für neue Software, aber deshalb muss ich keinen neuen X-Server haben.
> Lenny wird doch jetzt erstmal zu "oldstable" und dann noch supported, bis _noch_ ein neues "stable" rauskommt, oder ist das nicht mehr so?!
Ich zitiere mal Debian selbst :
The security team tries to support a stable distribution for about one year after the next stable distribution has been released, except when another stable distribution is released within this year. It is not possible to support three distributions; supporting two simultaneously is already difficult enough.
http://wiki.debian.org/DebianOldStable
Ein Jahr nach dem Erscheinen der neuen Stable-Version (Also Squeeze) ist Schluss mit der Unterstützung für Lenny. Sollte der Nachfolger von Squeeze noch vor Ablauf dieses Jahres erscheinen, dann ist dementsprechend früher Schluss mit der Unterstützung für Lenny.
> Ein neues Xorg einzusetzen ist dank der mangelhaften Tests Upstream praktisch die Garantie für schwerwiegende Bugs.
Das Problem sind weniger die Bugs, sondern eher das Erstellen der Pakete. Xorg besteht aus einer riesigen Anzahl von Paketen und das macht es dementsprechend schwer alle Probleme innerhalb der Pakete zu beseitigen. Dazu kommen noch die ABI bzw. API-Breaks in den neuen Versionen von Xorg.
> Stabil oberhalb eines gewissen Niveaus (die letzten 3% ?) kann ein System mit Xorg und Linux-Kernel m.E. nur sein, nachdem man es über viele Monate ausprobiert und verbessert hat.
Richtig stabil wird ein System erst, wenn es mit der Masse der Benutzer in Kontakt kommt. Selbst Debian bildet da keine Ausnahme. Wäre es anders, gäbe es nach der Veröffentlichung von Debian kein einziges Nicht-Sicherheitskritisches Update mehr.
Von Neuer_ohne_Login am Do, 20. Januar 2011 um 00:44 #
Das mit dem Support ist ein Problem. Wisst ihr, ob man von HP z.B. was Längeres bekommt? Die Ideen von Debian ist ja, dass kommerzieller Support von Vielen kommen kann, und Debian bietet wohl welchen.
Was aber bei Debian klappt, oder so habe ich den Eindruck, ist dass man über experimental, unstable, testing bis dann irgendwann stable einen Weg hat, die User vernünftig einzubinden.
Die riesige Zahl von Paketen von Xorg ist nicht das Problem, sondern dass jedes von ihnen, gegen irgendwelche Versionen von anderen Paketen entwickelt wurde, die auf irgendeine Weise ganz sicher nicht für alles zusammen verwendet werden können.
> Wisst ihr, ob man von HP z.B. was Längeres bekommt? Die Ideen von Debian ist ja, dass kommerzieller Support von Vielen kommen kann, und Debian bietet wohl welchen.
Ich glaube kaum, dass HP oder eine andere Firma sich die Mühe machen ein End-of-Life-Debian noch weiter mit eigenen Sicherheitsupdates zu versorgen. Da ist ein Upgrade auf eine neue Version einfacher zu bewerkstelligen.
Genau aus diesem Grund findet man Debian auch relativ selten in geschäftskritischen Umgebungen.
"Das Problem sind weniger die Bugs, sondern eher das Erstellen der Pakete."
Genau. Es fehlen ganz einfach die Xorg-Binaries für Normalnutzer (wenigstens für aktuellere glibc-Versionen sollte das doch möglich sein). So ist auch übrigens kein effektives, möglichst breites Testen durch Otto Normalnutzer vor einer neuen Xorg-Veröffentlichung möglich. Xorg brät so erst einmal ausschließlich im eigenen Bug-Saft vor sich hin.
"Mein Debian Testing (Squeeze) und auch Debian Lenny schlagen RHEL 5.x schon ziemlich lange in jeder Hinsicht."
In jeder Hinsicht? Dein Debian-Enthusiasmus in allen Ehren, aber Du übertreibst. RHEL 5.x ist zeit- und versionsmäßig auf dem Niveau von Debian Etch, mit einigen Backports und wenigen wirklich neuen Paketen (z.B. OpenOffice 3.1.1 und Firefox 3.6.13 für den Desktop). Im übrigen setzt Red Hat hier völlig andere Schwerpunkte als Debian. Unterschiede gibt es rein versionsmäßig nur dort, wo Etch seinerzeit aus internen Zwängen heraus eine aktuellere Version leider nicht in Stable integrieren konnte (z.B. musste damals glibc 2.3.x statt glibc 2.5.x verwendet werden).
Also, eine Distri, die problemlos läuft und auch noch riesige Auswahl hat, finde ich geradezu begeisternd anwenderorientiert.
Kernel, Lieblingsbrowser et al. kannst Du Dir nach Geschmack pürieren, mit Sahne verfeinern, und mit frischen Muskatstreuseln und Petersilie dekorieren.
Fedora und Ubuntu sehen ohne "Service Pack 2" ziemlich alt gegen Debian aus, was Qualität angeht.
Schön, mal wieder Zeit für überflüssige Debian-Fanboy-Postings zu haben.
Von Was für Fehler werden eigentli am Mi, 19. Januar 2011 um 12:08 #
Hallo,
kann mir einer sagen, um was für Fehler / welche Pakete bei deren Prüfungen un Korrekturen einbezogen werden ? Handelt es sich dabei immer um einen Grundstock an Paketen ? Also z. B. nur GNOME + vorinstallierte Pakete und diverse Serverapplikationen ? z. B. MySQL, Apache etc.
Die werden ja wahrscheinlich nicht alle Pakete aus den Repos testen. Könnte also sein, dass man div. KDE Applikationen nachinstalliert... z. B. Digikam... und man natürlich trotzdem von den in diesen Versionen enthaltenen Bugs betroffen ist...
Was soll dann Debian so stabil machen ? Wäre dankbar für eine kurze Erläuterung
> kann mir einer sagen, um was für Fehler / welche Pakete bei deren Prüfungen un Korrekturen einbezogen werden ?
Vereinfacht gesagt: Alle fehler, die als release kritisch eingestuft werden.
> Die werden ja wahrscheinlich nicht alle Pakete aus den Repos testen.
Wir haben diverse Tests (piuparts, autobuild, etc.) die wirklich auf alle Pakete angewendet werden, ja.
> Was soll dann Debian so stabil machen?
Ausführliche qualitäts Sicherung, klare Richtlinien und Schnittstellen (wie Pakete zu interagieren haben), und kein Zeitdruck durch festgesetzte Termine
Leider hat sich Debian durch die Verwendung der Kernelversion 2.6.32 inklusive des DRM-Stacks aus 2.6.33 und der gleichzeitigen Verwendung des Intel-Grafiktreibers in der Version 2.13 ein riesengroßes Problem eingefangen, dass die Entwickler nicht ohne weiteres lösen können.
Der verwendete DRM-Stack aus der Kernelversion 2.6.33 funktioniert im KMS-Modus nämlich mehr schlecht als recht auf allen Intel-Chips der 800er Baureihe. So wird auf dem Thinkpad meiner Mutter überhaupt kein Bild angezeigt. Da die Version 2.13 des Intel-Grafiktreibers verwendet wird, gibt es leider auch keine Möglichkeit mehr auf KMS zu verzichten, da der Treiber dieses zwingend voraussetzt.
Auf Debian kommen also exakt die gleichen Probleme zu, die schon Ubuntu 10.04 geplagt haben, nur das es unter Debian keine Möglichkeit mehr gibt auf KMS zu verzichten.
Debian Lenny wird doch noch weitergepflegt, danach kann man sich auch mal einen neuen Rechner kaufen - oder eben VESA nutzen, für das KSM Problem mit diesen Chips wird es jedenfalls wohl keine Lösung mehr geben.
Von Hansi Hinterherseher am Mi, 19. Januar 2011 um 14:36 #
Nun lass' doch mal die sprichwörtliche Kirche im Dorf. Nicht *mehr* funktionieren? Das wird schon wieder. Wenn Hardware irgendwo lange genutzt werden kann, dann ja wohl unter Linux. =)
Die Chips mögen alt sein, aber z.B. ein Notebook mit einem 855GM-Chipsatz ist immer noch gut genug um seine alltägliche Arbeit damit zu erledigen.
Mein ehemaliges Latitude D505 (Pentium-M 1,7GHz, 2GB RAM, 160GB HDD) ist trotz des Alters immer noch leistungsfähiger als jedes aktuelle Netbook auf Atom-Basis. Auch das alte Thinkpad meiner Mutter tut noch einwandfrei seinen Dienst. Alles ab einem 1GHz und 512MB RAM lässt sich auch heute noch problemlos einsetzen. Es müssen halt nur die Treiber mitspielen.
Ich kann jetzt nur von meiner eigenen Erfahrung mit dem Thinkpad (i830-Chipsatz) meiner Mutter sprechen :
Dort funktioniert Ubuntu 10.10 mit Kernelversion 2.6.37 und dem aktuellen Intel-Treiber in der Version 2.14 nahezu fehlerfrei. Das einzige Problem ist die fehlende Xv-Unterstützung (Xserver stürzt nach dem zweiten Zugriff auf die Extension ab) und die noch zu verbessernde 2D-Zeichengeschwindigkeit.
P.S. :
Ich hatte vor ein paar Wochen mal Debian Squeeze auf der Kiste installiert, da ich hoffte die Debian-Entwickler hätten den BlackScreen-Bug im Zusammenspiel mit KMS und dem i830 vielleicht beseitigt. Leider war dem nicht der Fall, weshalb ich wieder auf Ubuntu gewechselt habe.
Was ich nicht verstehe: Wie kann es sein, dass dieser genau gleiche Bug genauso "hart" in Debian Squeeze aufschlägt, so wie er schon vor knapp einem Jahr in Ubuntu 10.04 aufgeschlagen ist?
Dafür macht dieser Kernel Probleme z.B. mit GMA950, GMA3150 usw. "Black screen" Problem. Lösung? Keine. Zahllose seit den .37er RCs und bis dato kein wirklich funktionierender Fix.
Absolut "erschreckend": http://ikhaya.ubuntuusers.de/2010/04/29/ubuntu-weist-noch-probleme-mit-i845-i855-grafikkarten-auf/ plus die dort angegebenen Links.
Da Debian Squeeze die gleiche Kernelversion (Sogar die identische Kombination von Version 2.6.32+DRM2.6.33) wie Ubuntu 10.04 verwendet, treffen alle Aussagen zu dieser Ubuntu-Version 100% auf Debian zu.
Von Einfache Lösung am Mi, 19. Januar 2011 um 15:24 #
Lenny weiterverwenden, bis ein neuer Kernel oder Intel-Grafiktreiber nach Squeeze (oder in die Backports) kommt, der die Kombination DRM-Stacks aus 2.6.33 und Intel-Grafiktreibers in der Version 2.13 nicht mehr erfüllt. Danach auf Squeeze (+ evtl. Backports) upgraden.
Deine Mutter wird wahrscheinlich nicht sehnsüchtig auf Debian Squeeze warten, also sollte von Anfang bis Ende jeder glücklich sein: deine Mutter hat immer ein funktionierendes Thinkpad und du musst deiner Mutter nicht erklären, wieso kein Bild mehr angezeigt wird.
> der die Kombination DRM-Stacks aus 2.6.33 und Intel-Grafiktreibers in der Version 2.13 nicht mehr erfüllt.
Das müsste aber mindestens Kernelversion 2.6.36 in den Backports landen.
Im Grunde lassen sich ja die Probleme beseitigen indem man von Hand eine aktuellere Kernelversion einspielt bzw. selbst eine aktuellere Version per "make-kpkg" erzeugt. Nur muss man sich dann halt selbst um die Update kümmern.
Von Neuer_ohne_Login am Mi, 19. Januar 2011 um 22:55 #
Hallo Du,
es muß garnicht Backports oder selbst bauen sein. Ich habe hier 2.6.36 hauptsächlich wegen ext4. Es ist halt im "experimental" Repository, und lässt sich mit "apt-get install -t experimental" installieren. Die kriegen auch Aktualisierungen, und ein .37er ist da auch schon, nur würde da halt der "dkms" nicht mitmachen, weil linux-kbuild-2.6.37" noch nicht da ist.
Neulich hatte mir ein Asterisk-VOIP-Spezialist erzählt, daß gegenüber früher statt Debian (wg. schlanker Basis-Installation) RedHat favorisiert wird, wegen des Debian Kernels von anno dazumal mit nur 10ms Scheduler Takt.
Bei technisch "harten" Themen kann ich nicht nachvollziehen, warum die Leute nicht einfach einen anderen Kernel installieren, oder selbst kompilieren (oh Gott wie schlimm).
Bin seit geraumer Zeit voll mit Debian Squeeze zufrieden, auch für Produktion (der einzige Bug den ich hatte, war eine falsche SQLite-Abhängigkeit in einem Apache-SVN Modul).
3D geht dank entsprechender Firmware auch ohne Probleme. Watt soll die Heulerei? Debian rulez
> Bei technisch "harten" Themen kann ich nicht nachvollziehen, warum die Leute nicht einfach einen anderen Kernel installieren, oder selbst kompilieren (oh Gott wie schlimm).
Vielleicht deshalb, weil nicht jeder Lust hat wegen jedes kleinen Sicherheitsupdate den Compiler anzuwerfen?
Das hat nichts mit Debian zu tun, sondern ist ein Problem, welches mehr oder weniger häufig auftritt auch nach .32, z.B. in .37 und GMA3150 GPUs. Sie bekommen es halt nicht in den Griff ... deine Schlußfolgerungen sind also schlichtweg falsch.
xserver-xorg-video-intel (2:2.13.0-5) unstable; urgency=low . [ Julien Cristau ] * Drop the intel_pci_probe patch from -4 (closes: #606288). This relied on i915.ko getting loaded automatically, which doesn't happen if: - the kernel is built without CONFIG_DRM_I915_KMS and lacks modaliases, or - the user kept obsolete /etc/modprobe.d blacklists around. * Use the patch from upstream instead, which tries to load the kernel driver before testing for kms. . [ Cyril Brulebois ] * The “♫ we wish you a working driver ♫” release. * Build, test, and upload to unstable.
gibt es jetzt einen definitiven Termin. Bei Debian kann es eben dauern, aber das Warten lohnt sich. Ich bin als Laie sehr zufrieden mit Debian. Die Installation ist einfach und die Updates einzuspielen ist absolut simpel. Ich nutze Debian auf dem Desktop mit wachsender begeisterung. Von wegen vor allem eine Server-Distri. Bestimmt gut als Server, aber eben auch auf dem Desktop.
Der Termin war schon seit Oktober klar
Eine Release im Dezember - wie es manche Medien vermutet haben - war unrealistisch.
Aber bin auch froh, dass es bald soweit ist
na ja man sieht schon den "Kampf" der Debianer diesen Monat mehr Bugs zu fixen als neue auftauchen. Habe schon damit gerechnet dass es bald soweit ist.
http://bts.turmzimmer.net/graph-small.png
ACK! Ich nutze Linux seit etwa 2001, anfangs wechselnde Distris. Auch ich komme immer wieder auf Debian am Desktop zurück und bin damit mittlerweile fest im Sattel & voll zufrieden. Freu mich auf Squeeze, auch wenn ich's in ner Vm schon eine Weile beobachte.
pengux
Da stimme ich zu, allerdings werd ich nach gut eineinhalb Jahren Debian Stable wieder Richtung sidux/aptosid schwenken. Alte Programme und vor allem zu Zeiten von Lenny jedes Mal dieser Kampf mit Totem um den Internetstream der heute-show hinterlassen dann doch einen grausligen Beigeschmack.
Grueße
Ignatz
Die Heute-Show fehlerfrei sehen zu können, ist doch noch viel grauseliger.
> Bei Debian kann es eben dauern, aber das Warten lohnt sich.
Was lohnt sich denn? Veraltete Software schon beim Release, der Support ist mit RHEL oder SLES nicht vergleichbar, Paragraphenreiter statt Anwender-orientiert.
> Die Installation ist einfach und die Updates einzuspielen ist absolut simpel.
Das gilt für andere Disitributionen auch. Wobei mich mal interessieren würde, was alleine schon dank veralteter Treiber bei der Installation von lenny einfacher ist als bei einer anderen Distribution. Und mit Squeeze kommt dann noch der Spass mit "unfreier" Firmware dazu.
> Ich nutze Debian auf dem Desktop mit wachsender begeisterung.
Was ist z.B. an Iceweasel 3.0.6-3 so toll im Vergleich mit einem aktuellen Firefox 3.6.13 (z.B. in Ubuntu LTS)?
Hallo Du,
die Software in Debian stable funktioniert dafür aber auch, und braucht dann natürlich im Grunde keinen Support mehr. Was die Grundsatztreue angeht, so ist RHEL da nicht weniger gut als Debian. Wenn etwas rechtlich auch nur ein wenig zweifelhaft ist, dann ist es nicht dabei. Ob Mono, ob MP3, ob KDE damals, die waren immer die wirklich konsequenten.
Und veraltet? Mein Debian Testing (Squeeze) und auch Debian Lenny schlagen RHEL 5.x schon ziemlich lange in jeder Hinsicht. Was meinst, Du wann ein RHEL 7 kommen wird? Man kann Redhat alles vorwerfen, aber Versionitis, und aktuelle Software sicher nicht. Ich glaube, Du findest da Unterschiede, die es so in der Form nicht gibt.
Dann die Installation und Backports. Korrekt, für RHEL wird immer neue Hardware unterstützt, und Treiber werden eingepflegt, und das ist ein Riesenhindernis, wenn man Systeme liefern muss, die gleiche Software haben, einem aber immer die Hardware abhanden kommt, weil der PC-Zyklus so schnell tickt. Hier sehe ich das Existenzrecht von Redhat.
Zu Iceweasel 3.0.6 kann ich Dir Nichts sagen, ich habe hier auf Squeeze einen 3.5.16. Aber wenn ich wollte, würde ich "apt-get install iceweasel -t experimental" machen, und hätte dann 3.6.13. Ich weiß nicht, was ich verpasse. Also ich weiß es schon, aber nicht aus eigener Erfahrung. Aber ich glaube ohne leben zu können, und ich vertraue Debian, dass sie 3.6.x in Debian Testing so ca. im März haben werden, wenn es nicht zuviele Bugs hat.
Am besten kann ich das mit openOffice.org begründen. Neue Versionen davon sind immer toll, nur geht das irgendwas wichtiges nicht mehr. Ich warte lieber, bis keine Debian Debugs mehr den Einzug in Debian Testing verhindern, dann ist es sogar recht benutzbar. Das bedeutet natürlich, dass ich mal ein paar Monate mehr warte, aber es bedeutet auch immer, dass ich keine Regressionen oder nur wenige habe (als immer Debian Testing verfolgender).
Mit Debian Squeeze kommt ja dann auch Backports dazu. Wenn jemand das auch dem Desktop einsetzt, vermute ich mal, wird er seinen Iceweasel auch aktualisiert bekommen, ohne das Debian Testing "Risiko" einzugehen. Für Lenny bekommt man ja auch den 3.5.16 installiert, wenn man Backports aktiviert.
Und für mich ist natürlich Xfce 4.8 ein wichtiges Thema. Nur bei Debian finde ich da die Hoffnung, das auf einer stabilen Basis laufen lassen zu können.
Mein Desktop hat meist eine Uptime, die nur von neuen Kerneln unterbrochen wird. Will man wirklich rausfinden, ob das mit dem neuesten X-Server und so weiter, auch so wäre?
Also ich bin den Leuten, die Fedora einsetzen, total dankbar dafür, was sie leisten. Mir reicht es aus, wenn ich selbst Freie Software entwickele, und der Desktop dabei nicht stört. Wenn jetzt 3.5.x von Firefox so inakzeptabel Scheisse ist, dann weißt Du nur noch nicht, wie inakzeptabel 3.6.13 ist, weil Du halt 4.0 noch nicht gesehen hast.
Ich kann z.B. nicht erkennen, was jetzt an Xfce 4.6 unbenutzbar wäre, nur weil es 4.8 gibt. Und KDE 4.0 hat ja bekanntermassen nicht sofort 3.5 schlecht gemacht.
Gruss,
Kay
> Mein Debian Testing (Squeeze) und auch Debian Lenny schlagen RHEL 5.x schon ziemlich lange in jeder Hinsicht.
Das stimmt natürlich. Im Hinblick auf den Supportzeitraum hat er aber (leider) absolut recht. Debian Lenny wird nur noch bis Februar 2012 unterstützt, dann ist man gezwungen zu aktualisieren. Drei Jahre sind für eine Distribution, deren Benutzer nicht müde werden diese für den Unternehmenseinsatz zu propagieren, dann doch recht wenig.
> Will man wirklich rausfinden, ob das mit dem neuesten X-Server und so weiter, auch so wäre?
Warum nicht? Nur weil andere Distributionen aktuellere Software einsetzen, heißt das noch lange nicht, dass sie zwangsläufig instabiler sind.
> Ich kann z.B. nicht erkennen, was jetzt an Xfce 4.6 unbenutzbar wäre, nur weil es 4.8 gibt.
Unbenutzbar wird es dadurch natürlich nicht, nur wird der eine oder andere Benutzer solche Sachen wie funktionierendes DnD bei Anwendungsstartern und andere Nettigkeiten schon vermissen.
Hallo Du,
Lenny wird doch jetzt erstmal zu "oldstable" und dann noch supported, bis _noch_ ein neues "stable" rauskommt, oder ist das nicht mehr so?!
Was den X-Server angeht, beliebst Du wohl zu scherzen. Neue X-Server brauchen in Debian regelmässig sehr sehr lange, bis sie auch nur annähernd fehlerarm sind. Ein neues Xorg einzusetzen ist dank der mangelhaften Tests Upstream praktisch die Garantie für schwerwiegende Bugs.
Stabil oberhalb eines gewissen Niveaus (die letzten 3% ?) kann ein System mit Xorg und Linux-Kernel m.E. nur sein, nachdem man es über viele Monate ausprobiert und verbessert hat.
Und neue Features sind nett. Ich bin total heiß auf Xfce 4.8. Aber im Paket mit einem neuen Xorg, würde ich es nicht wollen. Ich habe derzeit ein "Debian Testing", und verfolge aus "Debian Unstable" dann "python-pyside", "uwsusp", "wine" (Eve Online) und aus "Debian Experimental" den Kernel 2.6.36, wobei man sagen muss, dass ich den ersten Oops seit langem mit 2.6.35 hatte, also gebrannt bin, dann "python2.7", sehr wichtig für meine Entwicklungen, "g++-4.6" als Vorschau und "g++-4.5" für eine meiner Entwicklungen. Sobald es geht würde ich Xfce 4.8 probeweise dazu nehmen, und wenn es nicht so gut ist, wieder auf 4.6 downgraden.
Ich interessiere mich also schon für neue Software, aber deshalb muss ich keinen neuen X-Server haben.
Gruss,
Kay
> Lenny wird doch jetzt erstmal zu "oldstable" und dann noch supported, bis _noch_ ein neues "stable" rauskommt, oder ist das nicht mehr so?!
Ich zitiere mal Debian selbst :
The security team tries to support a stable distribution for about one year after the next stable distribution has been released, except when another stable distribution is released within this year. It is not possible to support three distributions; supporting two simultaneously is already difficult enough.
http://wiki.debian.org/DebianOldStable
Ein Jahr nach dem Erscheinen der neuen Stable-Version (Also Squeeze) ist Schluss mit der Unterstützung für Lenny. Sollte der Nachfolger von Squeeze noch vor Ablauf dieses Jahres erscheinen, dann ist dementsprechend früher Schluss mit der Unterstützung für Lenny.
> Ein neues Xorg einzusetzen ist dank der mangelhaften Tests Upstream praktisch die Garantie für schwerwiegende Bugs.
Das Problem sind weniger die Bugs, sondern eher das Erstellen der Pakete. Xorg besteht aus einer riesigen Anzahl von Paketen und das macht es dementsprechend schwer alle Probleme innerhalb der Pakete zu beseitigen. Dazu kommen noch die ABI bzw. API-Breaks in den neuen Versionen von Xorg.
> Stabil oberhalb eines gewissen Niveaus (die letzten 3% ?) kann ein System mit Xorg und Linux-Kernel m.E. nur sein, nachdem man es über viele Monate ausprobiert und verbessert hat.
Richtig stabil wird ein System erst, wenn es mit der Masse der Benutzer in Kontakt kommt. Selbst Debian bildet da keine Ausnahme. Wäre es anders, gäbe es nach der Veröffentlichung von Debian kein einziges Nicht-Sicherheitskritisches Update mehr.
Das mit dem Support ist ein Problem. Wisst ihr, ob man von HP z.B. was Längeres bekommt? Die Ideen von Debian ist ja, dass kommerzieller Support von Vielen kommen kann, und Debian bietet wohl welchen.
Was aber bei Debian klappt, oder so habe ich den Eindruck, ist dass man über experimental, unstable, testing bis dann irgendwann stable einen Weg hat, die User vernünftig einzubinden.
Die riesige Zahl von Paketen von Xorg ist nicht das Problem, sondern dass jedes von ihnen, gegen irgendwelche Versionen von anderen Paketen entwickelt wurde, die auf irgendeine Weise ganz sicher nicht für alles zusammen verwendet werden können.
Gruss,
Kay
> Wisst ihr, ob man von HP z.B. was Längeres bekommt? Die Ideen von Debian ist ja, dass kommerzieller Support von Vielen kommen kann, und Debian bietet wohl welchen.
Ich glaube kaum, dass HP oder eine andere Firma sich die Mühe machen ein End-of-Life-Debian noch weiter mit eigenen Sicherheitsupdates zu versorgen. Da ist ein Upgrade auf eine neue Version einfacher zu bewerkstelligen.
Genau aus diesem Grund findet man Debian auch relativ selten in geschäftskritischen Umgebungen.
"Das Problem sind weniger die Bugs, sondern eher das Erstellen der Pakete."
Genau. Es fehlen ganz einfach die Xorg-Binaries für Normalnutzer (wenigstens für aktuellere glibc-Versionen sollte das doch möglich sein). So ist auch übrigens kein effektives, möglichst breites Testen durch Otto Normalnutzer vor einer neuen Xorg-Veröffentlichung möglich. Xorg brät so erst einmal ausschließlich im eigenen Bug-Saft vor sich hin.
"Mein Debian Testing (Squeeze) und auch Debian Lenny schlagen RHEL 5.x schon ziemlich lange in jeder Hinsicht."
In jeder Hinsicht?
Dein Debian-Enthusiasmus in allen Ehren, aber Du übertreibst.
RHEL 5.x ist zeit- und versionsmäßig auf dem Niveau von Debian Etch, mit einigen Backports und wenigen wirklich neuen Paketen (z.B. OpenOffice 3.1.1 und Firefox 3.6.13 für den Desktop).
Im übrigen setzt Red Hat hier völlig andere Schwerpunkte als Debian.
Unterschiede gibt es rein versionsmäßig nur dort, wo Etch seinerzeit aus internen Zwängen heraus eine aktuellere Version leider nicht in Stable integrieren konnte (z.B. musste damals glibc 2.3.x statt glibc 2.5.x verwendet werden).
Also, eine Distri, die problemlos läuft und auch noch riesige Auswahl hat, finde ich geradezu begeisternd anwenderorientiert.
Kernel, Lieblingsbrowser et al. kannst Du Dir nach Geschmack pürieren, mit Sahne verfeinern, und mit frischen Muskatstreuseln und Petersilie dekorieren.
Fedora und Ubuntu sehen ohne "Service Pack 2" ziemlich alt gegen Debian aus, was Qualität angeht.
Schön, mal wieder Zeit für überflüssige Debian-Fanboy-Postings zu haben.
"Was ist z.B. an Iceweasel 3.0.6-3 so toll im Vergleich mit einem aktuellen Firefox 3.6.13 (z.B. in Ubuntu LTS)? "
Nichts, absolut gar nichts.
Nicht einmal ein aktuelles Adblock-Plus läuft damit.
Schlicht falsch, Squeeze's Iceweasel ist ein halbwegs aktueller Firefox 3.5.16.
Ich installiere mir persönlich trotzdem den original Firefox, falls es Wayne interessiert.
Darum ging es in der Ausgangsfrage nicht, nur um den Vergleich, der ja bekanntlich Debian Lenny betrifft.
"Ich installiere mir persönlich trotzdem den original Firefox, falls es Wayne interessiert."
Vielleicht sollte man da einmal eine Umfrage machen. Nicht, dass man unter größten Mühen ein Firefox-Produkt patcht und so gut wie niemand benutzt es.
https://launchpad.net/~gnuzilla-team/+archive/ppa und gut is
@ M
dann nimm halt eine andere Distri.
genügend Auswahl ist doch vorhanden
Endlich kommen in testing wieder frischere Sachen rein.
Gruß
MichaelK
Hallo,
kann mir einer sagen, um was für Fehler / welche Pakete bei deren Prüfungen un Korrekturen einbezogen werden ?
Handelt es sich dabei immer um einen Grundstock an Paketen ? Also z. B. nur GNOME + vorinstallierte Pakete und
diverse Serverapplikationen ? z. B. MySQL, Apache etc.
Die werden ja wahrscheinlich nicht alle Pakete aus den Repos testen.
Könnte also sein, dass man div. KDE Applikationen nachinstalliert... z. B. Digikam... und man natürlich
trotzdem von den in diesen Versionen enthaltenen Bugs betroffen ist...
Was soll dann Debian so stabil machen ? Wäre dankbar für eine kurze Erläuterung
> kann mir einer sagen, um was für Fehler / welche Pakete bei deren Prüfungen un Korrekturen einbezogen werden ?
Vereinfacht gesagt: Alle fehler, die als release kritisch eingestuft werden.
> Die werden ja wahrscheinlich nicht alle Pakete aus den Repos testen.
Wir haben diverse Tests (piuparts, autobuild, etc.) die wirklich auf alle Pakete angewendet werden, ja.
> Was soll dann Debian so stabil machen?
Ausführliche qualitäts Sicherung, klare Richtlinien und Schnittstellen (wie Pakete zu interagieren haben), und kein Zeitdruck durch festgesetzte Termine
Debian Squeeze ist praktisch Ubuntu Lucid, nur wurden ein Jahr länger die Bugs gejagt und, soweit möglich, auch behoben.
Leider hat sich Debian durch die Verwendung der Kernelversion 2.6.32 inklusive des DRM-Stacks aus 2.6.33 und der gleichzeitigen Verwendung des Intel-Grafiktreibers in der Version 2.13 ein riesengroßes Problem eingefangen, dass die Entwickler nicht ohne weiteres lösen können.
Der verwendete DRM-Stack aus der Kernelversion 2.6.33 funktioniert im KMS-Modus nämlich mehr schlecht als recht auf allen Intel-Chips der 800er Baureihe. So wird auf dem Thinkpad meiner Mutter überhaupt kein Bild angezeigt. Da die Version 2.13 des Intel-Grafiktreibers verwendet wird, gibt es leider auch keine Möglichkeit mehr auf KMS zu verzichten, da der Treiber dieses zwingend voraussetzt.
Auf Debian kommen also exakt die gleichen Probleme zu, die schon Ubuntu 10.04 geplagt haben, nur das es unter Debian keine Möglichkeit mehr gibt auf KMS zu verzichten.
Debian Lenny wird doch noch weitergepflegt, danach kann man sich auch mal einen neuen Rechner kaufen - oder eben VESA nutzen, für das KSM Problem mit diesen Chips wird es jedenfalls wohl keine Lösung mehr geben.
danach kann man sich auch mal einen neuen Rechner kaufen
Tolle Problemlösung.
Der Einbau einer richtigen Grafikkarte würde auch weiter helfen.
Seine Mutter würde es ihm bestimmt danken.
"So wird auf dem Thinkpad meiner Mutter..."
...
Sch...ade.
Wer hätte früher auch gedacht, dass ausgerechnet einige Intel-Grafikchips eines Tages nicht mehr unter Linux funktionieren würden.
Nun lass' doch mal die sprichwörtliche Kirche im Dorf. Nicht *mehr* funktionieren? Das wird schon wieder. Wenn Hardware irgendwo lange genutzt werden kann, dann ja wohl unter Linux. =)
Naja, sie funktioniert schon, nur halt ohne Hardwarebeschleunigung, aber bei so alten Chips ist das eh nicht mehr der Rede wert.
Die Chips mögen alt sein, aber z.B. ein Notebook mit einem 855GM-Chipsatz ist immer noch gut genug um seine alltägliche Arbeit damit zu erledigen.
Mein ehemaliges Latitude D505 (Pentium-M 1,7GHz, 2GB RAM, 160GB HDD) ist trotz des Alters immer noch leistungsfähiger als jedes aktuelle Netbook auf Atom-Basis. Auch das alte Thinkpad meiner Mutter tut noch einwandfrei seinen Dienst. Alles ab einem 1GHz und 512MB RAM lässt sich auch heute noch problemlos einsetzen. Es müssen halt nur die Treiber mitspielen.
Die Hardware funktioniert schon noch. Im Grunde hat Debian nur die schlimmste Kombination aus Kernel und Grafiktreiber gewählt.
Die Kernelversion 2.6.37 zusammen mit der Grafiktreiberversion 2.14 macht kaum noch Probleme auf den alten Chips.
Hat sich da etwas geändert, oder besteht die Lösung immer noch darin auf sämtliche Hardwarebeschleunigung zu verzichten?
Ich kann jetzt nur von meiner eigenen Erfahrung mit dem Thinkpad (i830-Chipsatz) meiner Mutter sprechen :
Dort funktioniert Ubuntu 10.10 mit Kernelversion 2.6.37 und dem aktuellen Intel-Treiber in der Version 2.14 nahezu fehlerfrei. Das einzige Problem ist die fehlende Xv-Unterstützung (Xserver stürzt nach dem zweiten Zugriff auf die Extension ab) und die noch zu verbessernde 2D-Zeichengeschwindigkeit.
P.S. :
Ich hatte vor ein paar Wochen mal Debian Squeeze auf der Kiste installiert, da ich hoffte die Debian-Entwickler hätten den BlackScreen-Bug im Zusammenspiel mit KMS und dem i830 vielleicht beseitigt. Leider war dem nicht der Fall, weshalb ich wieder auf Ubuntu gewechselt habe.
Was ich nicht verstehe:
Wie kann es sein, dass dieser genau gleiche Bug genauso "hart" in Debian Squeeze aufschlägt, so wie er schon vor knapp einem Jahr in Ubuntu 10.04 aufgeschlagen ist?
Dafür macht dieser Kernel Probleme z.B. mit GMA950, GMA3150 usw. "Black screen" Problem. Lösung? Keine. Zahllose seit den .37er RCs und bis dato kein wirklich funktionierender Fix.
Seltsam. Ich habe eine GMA950 verbaut und diese funktioniert mit Kernelversion 2.6.37 einwandfrei.
oder eben VESA nutzen
In der heutigen Widescreen-Zeit auf Vesa verweisen...
als ob solche alten Rechner mit Widescreen Bildschirmen betrieben würden.
Absolut "erschreckend":
http://ikhaya.ubuntuusers.de/2010/04/29/ubuntu-weist-noch-probleme-mit-i845-i855-grafikkarten-auf/
plus die dort angegebenen Links.
Da Debian Squeeze die gleiche Kernelversion (Sogar die identische Kombination von Version 2.6.32+DRM2.6.33) wie Ubuntu 10.04 verwendet, treffen alle Aussagen zu dieser Ubuntu-Version 100% auf Debian zu.
Lenny weiterverwenden, bis ein neuer Kernel oder Intel-Grafiktreiber nach Squeeze (oder in die Backports) kommt, der die Kombination DRM-Stacks aus 2.6.33 und Intel-Grafiktreibers in der Version 2.13 nicht mehr erfüllt. Danach auf Squeeze (+ evtl. Backports) upgraden.
Deine Mutter wird wahrscheinlich nicht sehnsüchtig auf Debian Squeeze warten, also sollte von Anfang bis Ende jeder glücklich sein: deine Mutter hat immer ein funktionierendes Thinkpad und du musst deiner Mutter nicht erklären, wieso kein Bild mehr angezeigt wird.
> der die Kombination DRM-Stacks aus 2.6.33 und Intel-Grafiktreibers in der Version 2.13 nicht mehr erfüllt.
Das müsste aber mindestens Kernelversion 2.6.36 in den Backports landen.
Im Grunde lassen sich ja die Probleme beseitigen indem man von Hand eine aktuellere Kernelversion einspielt bzw. selbst eine aktuellere Version per "make-kpkg" erzeugt. Nur muss man sich dann halt selbst um die Update kümmern.
Hallo Du,
es muß garnicht Backports oder selbst bauen sein. Ich habe hier 2.6.36 hauptsächlich wegen ext4. Es ist halt im "experimental" Repository, und lässt sich mit "apt-get install -t experimental" installieren. Die kriegen auch Aktualisierungen, und ein .37er ist da auch schon, nur würde da halt der "dkms" nicht mitmachen, weil linux-kbuild-2.6.37" noch nicht da ist.
Gruss,
Kay
Jetzt habe ich praktisch Dich selbst zitiert.
;-)
Neulich hatte mir ein Asterisk-VOIP-Spezialist erzählt, daß gegenüber früher statt Debian (wg. schlanker Basis-Installation) RedHat favorisiert wird, wegen des Debian Kernels von anno dazumal mit nur 10ms Scheduler Takt.
Bei technisch "harten" Themen kann ich nicht nachvollziehen, warum die Leute nicht einfach einen anderen Kernel installieren, oder selbst kompilieren (oh Gott wie schlimm).
Bin seit geraumer Zeit voll mit Debian Squeeze zufrieden, auch für Produktion (der einzige Bug den ich hatte, war eine falsche SQLite-Abhängigkeit in einem Apache-SVN Modul).
3D geht dank entsprechender Firmware auch ohne Probleme.
Watt soll die Heulerei? Debian rulez
> Bei technisch "harten" Themen kann ich nicht nachvollziehen, warum die Leute nicht einfach einen anderen Kernel installieren, oder selbst kompilieren (oh Gott wie schlimm).
Vielleicht deshalb, weil nicht jeder Lust hat wegen jedes kleinen Sicherheitsupdate den Compiler anzuwerfen?
Das hat nichts mit Debian zu tun, sondern ist ein Problem, welches mehr oder weniger häufig auftritt auch nach .32, z.B. in .37 und GMA3150 GPUs. Sie bekommen es halt nicht in den Griff ... deine Schlußfolgerungen sind also schlichtweg falsch.
xserver-xorg-video-intel (2:2.13.0-5) unstable; urgency=low
.
[ Julien Cristau ]
* Drop the intel_pci_probe patch from -4 (closes: #606288). This relied on
i915.ko getting loaded automatically, which doesn't happen if:
- the kernel is built without CONFIG_DRM_I915_KMS and lacks modaliases, or
- the user kept obsolete /etc/modprobe.d blacklists around.
* Use the patch from upstream instead, which tries to load the kernel driver
before testing for kms.
.
[ Cyril Brulebois ]
* The “♫ we wish you a working driver ♫” release.
* Build, test, and upload to unstable.
http://packages.qa.debian.org/x/xserver-xorg-video-intel/news/20101224T193209Z.html
wie wechsle ich dann später von debian testing zu stable ?
Die Datei "/etc/apt/sources.list" öffnen und alle Vorkommnisse von "testing" gegen "stable" austauschen.
oder jetzt schon "squeeze" eintragen.