Irgendwie fehlt debian IMHO noch eine Distibutionsebene zwischen stable und testing. So etwas wie "stable-desktop". Das Grundsystem ist stabil, aber Applikationen sollten ruhig in aktuellen Versionen hineinfließen, vor allem, wenn nach 3 Wochen keine größeren Bugs bekannt sind. Bspw. halte ich KDE3.5.6 nicht für weniger stabil als 3.5.5, weswegen dann die neuere Version in stable-desktop einfließen könnte. Oder auch, wenn sich xorg 7.2 im kommenden testing oder in sid bewährt, oder openoffice 2.2, etc. diese Dinge dann auch direkt in stable-desktop einfließen.
Man hätte also das stable wie bisher, mit stable-desktop einen häufiger aktualisierten stable-Zweig. Größere Umbauten erfolgen nachwievor in experimental und sid. Getestet werden sie 2-3 Wochen in testing und kommen dann in das Zwischen-stable rein. Damit müsste doch auch ein echtes stable-Release dann schneller erfolgen können, bspw. alle 6 oder 12 Monate.
Aber ich gebe zu: Ich habe von den internen, organisatorischen und technischen Dingen beim Debian-Release-Zusammenbau keine Ahnung, fände es halt nur schön, wenn ein recht stabiles debian auch in aktuell existierte, das aber näher am Original ist, als bspw. Ubuntu.
Darüber hab ich mir auch schon gedanken gemacht, und ich meinte gelesen zu haben, dass debian sowas plant, die distri zu splitten (wobei nichts entschieden ist).
wobei ich hier vor- und nachteile sehe. einerseits will ich ne stabile distribution (so wie es nun ist) welche halt nicht unbedingt die aktuellste software enthält und nur bugfixes reinfliessen, andererseits will man im desktop-linux vielleicht etwas aktuellere software mit aktuellen features.
jedenfalls sollte der releasezylus im desktopbereich beschleunigt werden. ich somit eine server/desktop splitting begrüssen. wobei server auch xorg, kde enthalten kann, jedoch nur security updates, so wie es heute existiert. was aber wiederum ein mehraufwand für die maintainer bedeuten würde.
einerseits will ich ne stabile distribution (so wie es nun ist) welche halt nicht unbedingt die aktuellste software enthält und nur bugfixes reinfliessen, andererseits will man im desktop-linux vielleicht etwas aktuellere software mit aktuellen features.
Mit einem Blick auf die BSDs -> man splittet in Base und "Userland", danach implementiert man das Ports-System und überlässt es dem User selbst, ob er gerne den neuesten FF, OO etc. haben will oder nicht.
An sich eine gute Idee, die Frage ist nur, wie das umzusetzen ist.
zwei Probleme: 1. Es reicht nicht, die Software einfach zu aktualisieren. Es muss auch das Upgrade von einer zur nächsten Version gewährleistet sein. Nur was passiert, wenn ich von Version 1.0 eines Softwarepaketes direkt auf 1.3 Upgrade und nicht über 1.2 gehe. Wenn Applikation X aktualisiere, warum nicht auch Y. Und um die aktuelle Software nutzen zu können, braucht ich in vielen Fällen eine aktuellere Kernelversion. Letztendlich landet man dann doch bei SID bzw. Testing. Genau, was du dir wünscht, wird ja mit Testing geboten.
2. Externe Anbieter, ich meine nicht vorrangig propreritärer Software, könnten sich im Prinzip auf nichts mehr verlassen, alles wäre im Wandel. Support ausgeschlossen.
Sicher gibt es noch eine ganze Reihe anderer Schwierigkeiten.
Die Lösung hieß bei Debian: Security-Updates auch für Testing. So kann man als experimentierfreudiger Benutzer Testing verwenden, muss aber nicht darum bangen, dass entscheidende Updates in SID hängen, weil irgendwelche Querabhängigkeiten nicht erfüllt sind. Es gibt ja viele Projekte die eine Lösung schaffen wollten (Sidux, Kanotix, Ubuntu usw.). In bestimmten Bereichen ist ihnen das sicher auch gelungen. Den Schmu (Lucky#Slevin) hat von denen wohl keiner gefunden.
Was das Debianprojekt hier geleistet hat ist schon wirklich beachtlich. Software mit akzeptablen Programmversionsstand und die gewohnte Stabilität. Wo bekommt man ein so komplexes umfangreiches Softwareangebot, das aufeinander abgestimmt ist. Selbst wenn man bereit ist dafür zu bezahlen.
> Letztendlich landet man dann doch bei SID bzw. Testing. Genau, was du dir wünscht, wird ja mit Testing geboten.
Aber die Systempflege ist dort einfach unmenschlich. Für Geeks bestimmt kein Problem, aber für Leute die mal hier und da was neues brauchen, wegen bekannten Fehlern, ist diese Form unbrauchbar und abschreckend.
> Was das Debianprojekt hier geleistet hat ist schon wirklich beachtlich. Software mit akzeptablen Programmversionsstand und die gewohnte Stabilität.
Bei Linux gibt es über 18.000 Softwarepakete, von denen die meisten > 10.000 für Entwickler (dev-Biblotheken und Programme) sind. Ein akzeptabler Programmversionsstand hört aber schon dann auf, wenn ein einziges Programm, auf der betreffenden Distri nicht mehr läuft. Jetzt versuch mal einem Normalsterblichen zu erzählen er müsse nur wegen ein paar Programmen sein ganzes System upgraden (Geschätzte Zeit: ca. 1 Stunde). Der kommt dir dann schnell mit dem Satz: Never chang a running System! Sowas nenne ich Eigentor.
Was mich an Linux einfach stört sind die zig Abhängigkeiten. 10 Programme haben 100 Abhängigkeiten. Wenn du jetzt ein Programm und 6 Abhängigkeiten aktualisierst, dann musst du damit rechnen das 9 Programme nicht mehr starten oder Fehler erzeugen.
Wir leben Heute in einer Welt in denen 1TB Speicher und 2-3GHz Prozessoren keine seltenheit mehr sind, aber Linux soll immer noch mit einem Pentium 100 laufen und weniger als 30MB Speicherplatz verbrauchen. Da wundert es mich nicht, das die Hersteller auf diese Kundschaft keine Lust hat.
> Aber die Systempflege ist dort einfach unmenschlich. Für Geeks bestimmt kein Problem, aber für Leute die mal hier und da was neues brauchen, wegen bekannten Fehlern, ist diese Form unbrauchbar und abschreckend.
Da muss ich dir zustimmen! :)
> Bei Linux gibt es über 18.000 Softwarepakete, von denen die meisten > 10.000 für Entwickler (dev-Biblotheken und Programme) sind. Ein akzeptabler Programmversionsstand hört aber schon dann auf, wenn ein einziges Programm, auf der betreffenden Distri nicht mehr läuft. Jetzt versuch mal einem Normalsterblichen zu erzählen er müsse nur wegen ein paar Programmen sein ganzes System upgraden (Geschätzte Zeit: ca. 1 Stunde). Der kommt dir dann schnell mit dem Satz: Never chang a running System! Sowas nenne ich Eigentor.
Ack! Wobei man nicht gleich upgraden muss, wenn ein Paket fehlt. Man könnte es sich auch selber bauen, aber auch dies ist unter Debian eher abschreckend als entgegenkommend.
> Was mich an Linux einfach stört sind die zig Abhängigkeiten. 10 Programme haben 100 Abhängigkeiten. Wenn du jetzt ein Programm und 6 Abhängigkeiten aktualisierst, dann musst du damit rechnen das 9 Programme nicht mehr starten oder Fehler erzeugen.
SEHR übertrieben!! Und meist sieht man VIELE Abhängigkeiten auch nur bei Debian und dessen Derivaten, da fast jedes Paket in *-lib *-data *-dev usw. usf. gesplittet wird. (ob damit jmd geholfen ist bleibt mal offen) Auch dass andere Programme den Geist aufgeben wenn geupdatet wird ist ich sag mal falsch Oder aber du hast Debian benutzt und leider diese schlechten Erfahrungen damit machen müssen, kann hier leider keine Debianerfahrungen teilen. Es ist auf jeden Fall übertreieben worden. ;)
> Wir leben Heute in einer Welt in denen 1TB Speicher und 2-3GHz Prozessoren keine seltenheit mehr sind, aber Linux soll immer noch mit einem Pentium 100 laufen und weniger als 30MB Speicherplatz verbrauchen. Da wundert es mich nicht, das die Hersteller auf diese Kundschaft keine Lust hat.
Dass solche Maschinen noch ein aktuelles OS laufen lassen können ist doch subba! Solange man keine negativen Effekte dadurhc erleidet sehe ich hier mal gar kein Problem. Du selbst erläuterst schließlich auch keines.
> (ob damit jmd geholfen ist bleibt mal offen) Mir zum Beispiel, ich binde mein Sourcepackage an libc-dev und werde, wenn das auf eine neuere Version zeigen sollte, automatisch durch einen einfachen Rebuild ein Paket mit neuen Abhängigkeiten erhalten.
Also als systemler ist für mich Debian absolut top. Klar existieren die oben erwähnten Probleme, aber was ist dann die Alternative? Wieder zu den RPM basierenden Distros, die diese bescheuerten dependency probleme haben, die sie dann nicht mal selber lösen, bzw. die repositories die es neu auch für RPM gibt sind einfach ein Witz, verglichen was apt-get bringt. Für mich fiel die Wahl auf Debian, weil es einfach ein Traum ist, software zu managen und das macht man eh dauernd, Programme installieren, evaluieren und wieder entfernen... Bei allen anderen Distro ist das einfach sehr sehr schwierig.. Ubuntu basiert ja auch das gleiche und als Desktop Distro ist es viel besser geeignet und macht mal folgenden Test: Leere Kiste, Distro installieren. Ziel: Video-Film schauen, Xvid.. (vlc bietet sich an)
Wie schnell geht das?
20 min... Ubuntu installieren (oder Kubuntu, je nach Lust und Laune), Ubuntu booten, apt-get install vlc und woiiinnnggg Video schauen....
Nun soll mir mal jemand erklären, wo das schneller geht? Und Knoppix gilt nicht, da es ja auch Debian basierend ist.
Über kurz oder lang sehe ich eine starke Verbreitung der dpkg basierenden Distros, weil es meiner Meinung einfach das beste package format ist, so wie es implementiert ist und dank apt-get ist software distribution und management einfach ein Traum. Das ist allen anderen Systemen Jahre vorraus. Ich manage noch VMware ESX systeme (die ja auch quasi Linux basierend sind)... da ladet man die Patches noch brav als RPM runtern... Die kämen nie auf die Idee, das repository mässig zu tun... so was von bescheuert.
Und alles sitzen auf RPM rum und bestehen drauf... RedHat würde auch gut dran tun, das zu beerdigen.
Wieder zu den RPM basierenden Distros, die diese bescheuerten dependency probleme haben, die sie dann nicht mal selber lösen, bzw. die repositories die es neu auch für RPM gibt sind einfach ein Witz, verglichen was apt-get bringt. Geht das auch genauer? So neu ist das übrigens nicht, Mandriva (bzw. Mandrakelinux) verwendet schon seit Ewigkeiten urpmi.
20 min... Ubuntu installieren (oder Kubuntu, je nach Lust und Laune), Ubuntu booten, apt-get install vlc Nö, vlc ist nicht in main. Außerdem: ein "rug install vlc", "smart install vlc", "urpmi vlc", "yast -i vlc" oder "yum install vlc" tuts genauso.
Ich manage noch VMware ESX systeme (die ja auch quasi Linux basierend sind)... da ladet man die Patches noch brav als RPM runtern... Die kämen nie auf die Idee, das repository mässig zu tun... so was von bescheuert. Was kann RPM dafür? Die offiziellen DEB-Pakete für OpenOffice.org gibts übrigens nur als Tarball zum Download.
Hm, bei Linux (dem Kernel) kenne ich nur ein Softwarepaket, nämlich das Tarball von kernel.org:-) Aber du meinst sicher Debian/GNU Linux.
Was mich an Linux einfach stört sind die zig Abhängigkeiten. 10 Programme haben 100 Abhängigkeiten. Wenn du jetzt ein Programm und 6 Abhängigkeiten aktualisierst, dann musst du damit rechnen das 9 Programme nicht mehr starten oder Fehler erzeugen.
All diese Probleme habe ich zu Hause nicht. Nicht jede Distribution benutzt Abhängigkeiten.
>Was mich an Linux einfach stört sind die zig Abhängigkeiten. Was mich an deiner Aussage stört: Du hast keine Ahnung von Betriebssystemen, oder? Und über Linux hast du dich per Hörensagen informiert.?
Für besseres Verstehen: Jedes Programm benötigt eine gewisse Umgebung, in der es laufen kann. Ist diese nicht vorhanden, läuft das Programm nicht. Beim XP-SP2 wurden an vielen Stellen derart gravierende Änderungen gemacht, dass manche Programme nicht mehr funktionierten. Das nennt sich "Abhängigkeiten". Die sind immer vorhanden und haben nichts mit Linux zu tun.
Aktuelles Beispiel: Aufgrund von Konflikten kann ich momentan zwar Eclipse nutzen, sobald ich aber Azureus installieren wollte, würde mir "apt" Eclipse komplett löschen. Wegen Abhängigkeiten. Die einfachste Lösung wäre ein vorkompiliertes Eclipse nach /opt zu schieben. Da sind die Libraries schon mitgeliefert und beides funktioniert perfekt.
Die vielen Abhängigkeiten sind dazu da, dass eben nicht jede Applikation tausend libraries (und das gilt auch für dlls) mitliefert/mitliefern muss.
Aber nochmal: Das hat NULL, GAR NIX, NADA mit Linux zu tun. Und noch viel weniger mit Debian, da die solchen Problemen recht oft mit der Benennung der Pakete aus dem Weg gehen. Da funktioniert das dann ganz ordentlich, dass 2 verschiedene Versionen einer Bibliothek nebeneinander leben.
Sollten nach einem Update in stable tatsächlich "9 Programme nicht mehr starten oder Fehler erzeugen", dann wäre das in meiner Erinnerung das erste Mal.
> ...sobald ich aber Azureus installieren wollte, würde mir "apt" Eclipse komplett löschen. Wegen Abhängigkeiten. > ...dass manche Programme nicht mehr funktionierten. Das nennt sich "Abhängigkeiten". Die sind immer vorhanden und haben nichts mit Linux zu tun.
Aha, dann sind also Abhängigkeiten was anderes als Abhängigkeiten - interessant
> Aber nochmal: Das hat NULL, GAR NIX, NADA mit Linux zu tun.
Komisch, wieso nervt mich dann das Paketsystem, das es immer erst Abhängigkeiten auflösen muss? Frechheit!
> Komisch, wieso nervt mich dann das Paketsystem, das es immer erst Abhängigkeiten auflösen muss? Frechheit!
Warum stoeren dich die Abhaengigkeiten, wenn sie automatisch aufgeloest werden? Die Alternative waeren statisches Linken fuer alle Anwendungen (unmoeglich) oder eine unkontrollierte DLL hell.
Apt schützt mit diesen Abhängigkeiten die Systemstabilität. Stable ist einfach rock solid, da kann man nichts rütteln dran. Wenn es zulassen würde, dass man irgendwelches Zeugs installiert, das Konflikte erzeugt, dann wäre es vorbei mit stable. Da soll man testing oder SID brauchen... Habe mit Sarge nun über die Jahre fast seit es stable geworden ist auf dem Laptop jeden Tag beruflich gearbeitet und schlägt Windox XP in stabilität und performance ein paar mal rundherum. Bin absolut häppy.. Ich türftle auch gerne rum, installiere mal neue Software zum ausprobieren, aber man muss sich eben an der Nase nehmen: Wenn es nicht im Repository drin ist, nur im unstabileren Release ist, dann soll man die Finger davon lassen, weil man danach nur wieder flucht, wenn das System auf einem mal nicht mehr richtig geht. Ein produktives System ist langweihlig und teilweise etwas altbacken, das hat mit bugfixing zu tun, neue Features bringen neue Bugs und hauen die Stabilität runter. Für das installiert man ne VMware maschine und lässt es darauf tuckern. Es sei denn, Stabilität ist einem schnuppe, man arbeitet darauf nicht professionell, dann her mit SID.. perfekt... Also ich habe mich seit ich mit Debian mit Sarge angefangen habe sehr über die massiv professionelle Qualität des Distros gewundert. Ein Traum, absolut. Low maintenance. Für mich das beste Linux Distro überhaupt, und habe früher lange auf RedHat, SuSE und Fedora gearbeitet.
Ihm ging es vermutlich darum, dass man Abhängigkeiten auch statisch auflösen kann, was man bei vieler kommerzieller Software (hauptsächlich Windows) auch tut.
Generell sehe ich hier aber eher Linux im Vorteil, wenn man sich mal den Sinn der LSB vor Augen hält, denn hier gibt es einen Standard, der distributionsübergreifend zahlreiche dynamische Bibliotheken an definierter Stelle in definierter Version vorgibt.
Was mich an Linux einfach stört sind die zig Abhängigkeiten. 10 Programme haben 100 Abhängigkeiten.
Das stört mich ganz und gar nicht. Die meisten (eigentlich fast alle) GNU/Linux-Distris sind eben nur unfähig diese Abhängigkeiten aufzulösen. Warum? Halbherziges Paketmanagement!
Danke für ein geniales, richtungsweisendes Packetmanagment und die Zusammenstellung eines großen Berges an toller Software, macht weiter so! Es macht Spass euer System zu nutzen.
Ich würde mir gerne mal Debian anschauen, evtl. sogar nutzen auf meinem Rechner. Es ist nicht einmal die sogenannte "Versioneritis" die mich davon abhält Debian(-stable) zu nutzen, aber wenn ich sehe dass Gnome 2.14 enthalten ist, dann frage ich mich wo die ganzen Ressourcen der so vielen Debianentwickler einfließt. Hassen die Gnome? Kann ich mir nicht vorstellen ehrlich gesagt, schließlich ist nach einer Defaultinstallation Gnome die grafische Oberfläche die man zu Gesicht bekommt. Aber woran haperts denn dann? Ich kann mir auch nicht vorstellen, dass Gnome 2.14 stabiler sei als 2.16 oder 2.18. Eher umgekehrt, ich sehe da mehr Probleme auftauchen mit 2.14 als wenn etwas aktuelleres verwendet werden würde. Das Gesamtbild schaut einfach so altbacken aus. Zum Glück kann sich jeder seine Distri selber ausscuchen, aber Debian ist für mich immer noch das unangetastete Nischending, welches nur zu Serverzwecken ngeeignet sein kann, und in keinster Weise Desktopansprüchen entgegenkommt. (imo!)
Ganz einfach: Wenn du die neueste Version nimmst kannst du nicht sicher sein welche Probleme es gibt, Debian legt die zu nutzende Version aber schon früh fest und sorgt dafür das diese dann aber auch unter Garantie funktioniert, in allen erlaubten Kombinationen.
Wenn du das nicht willst kannst du ja Ubuntu nutzen, da hast du dann die selbe Basis aber mit neueren Paketen. Das ist ja das gute an Debian, es ist nicht nur eine gute Distrie, nein es ist auch eine sehr gute Metadistrie als Basis für andere Projekte.
> Ganz einfach: Wenn du die neueste Version nimmst kannst du nicht sicher sein welche Probleme es gibt, > Debian legt die zu nutzende Version aber schon früh fest und sorgt dafür das diese dann aber auch > unter Garantie funktioniert, in allen erlaubten Kombinationen.
Das ist die Wunschvorstellung, in der Praxis sieht das ganz anders aus. Wie man an dem für Desktop Verhältnisse instabilen und recht unbrauchbaren Debian Sarge mit Gnome 2.8 sehen konnte. Hier wäre jede Gnome Version größer oder gleich 2.10 sinnvoller gewesen als Gnome 2.8 und Gnome 2.10 gab es zum Releasezeitpunkt von Debian Sarge definitiv schon einige Monate.
Natürlich kann eine neue Version neue Probleme aufwerfen, aber es werden auch viele alte Probleme gelöst, die in dem alten Debian Paket ungelöst bleiben. Zumindest ist das meine Erfahrung mit Debian Sarge und insb. der verwendeten Gnome 2.8 Version.
Gerade die sich in schneller Entwicklung befindeten Desktop Anwendungen sind unter Debian ein Problem, da viele dieser < 1.0 Versionen noch hier und da Bugs haben oder wichtige, für eine sinnvolle Nutzung, unabdingbare Features fehlen welche erst nach und nach von den Entwicklern der Anwendung behoben(Bugs) oder eingebaut (Features) werden, aber genau diese Verbesserungen schaffen es nie in Debian, da Debian ein ganz anderes Konzept verfolgt. Wenn man Glück hat, dann findet man lediglich ein nicht supportetes Paket in den Backports, sofern die Anwendung bekannt genug ist, aber da das nicht supported ist, kann man es auch gleich selber von der Projektseite downloaden und compilieren. Desweiteren gibt es bei den Backports auch meist nur neue Versionen der verschiedenen Desktop Environments, anstatt die eigentlich wichtigen Nutzanwendungen zum Arbeiten, welche viel wichtiger in den Backports wären.
Um es also auf den Punkt zu bringen, Debian ist keine rund um sorglos Lösung.
Was soll denn an dem Sarge GNOME so schlimm gewesen sein? Den Etch GNOME find ich eher noch ziemlich fehlerhaft, sodass das Upgrade darauf für mich eher einen Rückschritt darstellt.
gnome zu warten ist einfach ein Alptraum. Eine Bazillion Pakete, die nicht nur mit den genau richtigen configure-flags übersetzt werden müssen und deren Reihenfolge genaustens eingehalten werden muß, nein, auch eine Menge redundanter code, der sich in dutzenden Bibliotheken versteckt.
Da ist es mehr als nur verständlich, daß die Debianentwickler a) eine weile beschäftigt sind irgendein gnome release zu stabilisieren und b) wenn sie es denn soweit haben, nicht von heute auf morgen auf die neuste Version wechseln können.
Beschwer dich nicht bei Debian, beschwer dich bei gnome.
Wobei, schau dir mal so Sachen wie OpenOffice oder den Firefox an.
In experimental war eine Zeit lang ein recht großer Anteil an "Gnome 2.16"-Paketen, leider nur für ADM64 (glaub ich) kompiliert.
Die für meinen Pentium M zu kompilieren war aber bei keinem einzigen Paket ein Problem und ich hatte nach geschätzten 30 Minuten ein nahezu vollständiges 2.16.
Momentan gibt's ja sogar schon einige 2.18er Pakete in experimental und die laufen hier total rund.
> Die für meinen Pentium M zu kompilieren war aber bei keinem einzigen Paket ein Problem und > ich hatte nach geschätzten 30 Minuten ein nahezu vollständiges 2.16. > > Momentan gibt's ja sogar schon einige 2.18er Pakete in experimental und die laufen hier total > rund.
Deine Erfahrung in allen Ehren, aber du willst doch nicht ernsthaft deine Erfahrung mit einer einzelnen Installation auf einer einzelnen Rechnerarchitektur bei Benutzung von nur wenigen ausgewählten (da für dich nützlichen) Softwarepaketen mit den Release-Anforderungen von Debian vergleichen, oder?
Das ist lustig, ich nutze Gentoo und hatte noch nie Probleme, auf ein neueres GNOME umzusteigen, während das Riesen-KDE-libs-compile regelmäßig vom OOM-Killer beseitigt wird. Ich habe diese Beschwerden über die "tausenden" Gnome-Libs schon oft gehört, kann sie aber wirklich nicht nachvollziehen. Wenn man GARNOME nutzt, muss man übrigens auch bei Bin-Distries nicht viel machen.
Das Versionsproblem gibt es nicht nur auf dem Desktop. Im Webhosting haben wir die selben Probleme. Irgendwann wurden die Kisten mit Debian aufgesetzt und nun hängt man fest mit alter MySQL und PHP Installation. Entweder kompiliert man nachher soviel selbst, das kein Debian mehr über bleibt, oder man installiert Backports und freut sich über viele schöne Versionskonflikte, ein dpkg das die Arbeit verweigert weil ein installiertes Paket kaputt ist oder diverse andere Probleme, die nicht auftreten würden, wenn man gleich was anderes genommen hätte, das den Ansprüchen eher gerecht wird. Aktuelle Server setze ich nur noch mit Gentoo auf, da stimmt die Aktualiatät und das kompilieren übernimmt ein zentraler Rechner auf dem die Updates dann auch gleich getestet werden. Danach gehts dann per Script auf die Produktions-Server. Sicher, das kompilieren würde man sich gerne sparen, aber es ist verschmerzbar.
Ist bei anderen auch nicht besser. Upgrade mal ein opensuse, gerade PHP (4 vs. 5) ist ein echtes Problem, was mich dazu genötigt hat, entweder opensuse 10.2 komplett zu lassen, Webserver samt PHP aus dem Quellcode zu übersetzen oder die Software zu patchen, die mit PHP5 nicht lief. Letzteres hat dann geholfen, glücklicherweise. Das Problem ist schrottige Anwendungssoftware, die nicht einfach mal so herübergenommen werden kann, bzw. Anwendungssoftware, die "einfach Pech hat" wie in meinem Falle, als es mit PHP5 eine Klasse neu dazu gab, deren Name in der Anwendung bereits benutzt wurde. Probleme treten bei Upgrades immer auf, und immerhin Sarge hatte sogar noch PHP3-Pakete.
> Im Webhosting haben wir die selben Probleme. [...]
Debian wählt man üblicherweise, weil man eine stabile Basis für einen Rechner haben möchte, der dann für einen längeren Zeitraum beinahe wartungsfrei läuft und läuft und läuft. Die stabile Basis schließt stabile, sich also nicht ständig ändernde Softwareversionen ein, um eben nicht in unregelmäßigen Abständen Konfigurationsdateien anpassen und Inkompatibilitäten beheben zu müssen.
Speziell bei Servern sind starre Versionsnummern üblicherweise kein Problem, da Server normalerweise einmal geplant und dann für lange Zeit in genau der geplanten Konstellation laufen. Und das möglichst ohne Ausfälle z.B. hervorgerufen durch Inkompatibilitäten neuerer Softwareversionen.
Die Aktualität deiner neuen Distribution hat einen Preis, nämlich den damit verbundenen höheren Wartungsaufwand was wiederrum ein höheres Ausfallrisiko bedingt. Gerade bei Produktivsystemen möchte man darauf aber in der Regel verzichten.
Aber natürlich gibt es für jede Regel irgendwo eine Ausnahme. Nur Ausnahmen bilden deshalb nicht die Regel.
ich bin kein Coder und kein Paketmaintainer, daher mal 'ne blöde Frage:
Gibt es gewichtige Gründe (außer Plattenplatz- Ersparnis), warum bei Debian die Pakete so fein geschnitten sind? Software, die in Slackware auf ein gutes Dutzend Pakete aufgeteilt ist (z.B. KDE), ist in Debian auf mehrere Dutzend Pakete gesplittet (oder noch mehr? - kann gerade nicht nachsehen).
Damit steigt doch sicherlich auch die Komplexität beim Paketbau und die Wahrscheinlichkeit von Inkonsistenzen.
Vor allem: über die automatische Abhängigkeitsauflösung sind die meisten Pakete doch eh' miteinander verbandelt, und man kann eh' kaum etwas abwählen.
Plattenplatz, komplexität, sehr einfach es zu splitten.
Bei dem Splitpkg schreibst du für jedes subpkg eine beschreibung(dadurch leichter zu finden, wenn man nach kmail sucht, und nicht nach kde pim), und ein command was es installiert, hier z.B. cd kmail;make install --prefix debian/kmail oder so ähnlich.
Dann noch ein Metapaket (kde), was alle pakete installiert, und nach belieben metapakete die eine auswahl installieren (kubuntu-desktop z.B.)
Es geht tatsächlich darum mit sowenig Daten wie nötig ein Programm/Lib zu installieren.
Es geht aber auch darum, soviel aus einem Programm auszulagern wie möglich um bei einem Fehler in einer Datei nicht mehrer Programme mit updaten zu müssen, sie diese fest einkompliert haben.
Für einen Programmierer ist das auch paktisch, da er auf getestete und fertig installierbare Dateien (Bibliotheken, Einstellungen) zurückgreifen kann, ohne ein ganz anderes Progamm in die Abhängigkeitsliste aufnehmen zu müssen, oder die betreffenenden Daten selber übernehmen.
Je feiner die Granualtion ist um so leicher wird es ein System zu erweitern ohne Daten doppelt installieren und sich um deren Aktualität kümmern zu müssen.
Sicher kann das zu Problem mit rekusiven Abhängigkeiten und sehr komplexen Anhängigkeitsbäumen kommen, aber das System später sicher zu halten wird sehr viel leichter.
Häufig werden von einem Programm nur einige "Fremddateien" von anderen Programmen/Bibliotheken gebraucht. Es wäre auch ein Sicherheitsrisiko, alle Programm- und Bibliotheks-gruppen mit zu installieren.
Stimme zu, habe nur selbst meine negativen erfahrungen damit gemacht.
Wollte meinen Drucker zum laufen bekommen, und starte den Konfigurationsdialog. Der ist irgendwie mit dpkg verbandelt, ich wähle meinen Drucker aus und sage, ich bin lokal damit verbunden (USB). Was passiert: Ein bisschen was wird installiert, aber Drucker funktioniert keiner.
Erst als ich im kpackage das richtige Treiberpaket händisch (!) nachinstalliert habe hat der Drucker funktioniert.
Was auch passiert ist: Irgendwann hat KDE einfach aufgehört zu starten (nach einem unsauberen shutdown). Ich habe dann einen neuen User angelegt, und dort hat KDE einwandfrei funktioniert, nur unter dem original User war KDE nicht mehr zum Laufen zu bekommen. Sowas ist mir unter Mandriva NIE passiert, und da gabs auch den einen oder anderen unsanften Shutdown. Vielleicht liegts ja an diesen seltsamen socket files die KDE überall hinstreut, und dass ich da nicht alle gefunden und eliminiert habe.
Debian ist mein Ziel seit ca. 2 Jahren, aber offensichtlich bin ich zu sehr DAU um damit zurechtzukommen.
Eine Desktopversion, die nicht nur die absolut unbedingt notwendigen Pakete installiert, sondern auch welche die ich als "highly recommended" bezeichnen würde wäre schon fein.
Bezüglich KDE bei unsanftem Shutdown, das kann leider passieren, wenn dadurch das Filesystem oder der Inhalt einer Datei beschädigt wird. Sofern du ein gutes Journaling-Dateisystem verwendest wie z.B. ext3, kannst du zumindest ersteres ausschließen. Letzteres (Datei wird mit Müll gefüllt) decken die meisten Journaling-Dateisysteme nicht oder nur teilweise ab oder die Funktion ist aus Performancegründen standardmäßig deaktiviert. Das Problem ist Distributionsunabhängig, hat also nicht speziell mit Debian zu tun. Es geht hald 100 mal gut und beim 101. Mal nicht...
KDE legt seine Konfiguration im .kde-Verzeichnis deines Homeverzeichnisses ab. Du kannst z.B. das Verzeichnis umbenennen um das komplette KDE auf Defaulteinstellungen zurückzusetzen. Praktikabler ist es aber wohl, nach den zum Zeitpunkt des unsanften Shutdown geöffneten Dateien zu suchen (z.B. mit find anhand der Zugriffzeit) und diese dann genauer unter die Lupe zu nehmen. Und bei beschädigtem/seltsamen Inhalt zu löschen oder den defekten Teil zu entfernen.
> Sicher kann das zu Problem mit rekusiven Abhängigkeiten und sehr komplexen Anhängigkeitsbäumen kommen, aber .......
Ja, deshalb fragte ich. Beim Spielen mit einer auf Debian testing beruhenden Disto und mit Kubuntu 7.04 hatte ich solche Effekte. Die sind für 'nen DAU besonders frustrierend, weil der Paketmanager bzw. die drübergestülpte GUI unmittelbar bei Auftreten eines solchen Fehlers mit 'ner kryptschen Fehlermeldung aussteigt und sich weigert, das System zu aktualisieren.
Na ja, fairerweise muß man zugeben, daß Beta-Versionen nun mal nicht in DAU- Hände gehören.
Debian hat echt einen Riesen-Schritt nach vorne gemacht. Das erste Debian wo ich keinen eigenen Kernel mehr kompilieren musste. Auch wurde zahlreiche Hardware bei mir jetzt automatisch erkannt z.B. Soundkarte, Netzwerkkarte. Sogar der IPOD wurde automatisch beim Einstecken gemounted! Ähnlich der Scanner: Anschließen, Einschalten, geht!
Nur die X-Server-Konfiguration war komplett daneben (Etch Stand Mitte Februar). Grafikkarte und Maus falsch erkannt. Konnte ich aber relativ schnell von Hand beheben.
Kompliment an Debian, die Installation/Konfiguration scheint jetzt deutlich einfacher!
> Nur die X-Server-Konfiguration war komplett daneben (Etch Stand Mitte Februar). Grafikkarte und Maus falsch erkannt. Konnte ich aber relativ schnell von Hand beheben.
Und, hast du einen Fehlerbericht geschrieben? Ist für die Entwickler vielleicht nicht ganz uninteressant, wenn die Hardwareerkennung bei gewissen Gerätekombinationen nicht vernünftig funktioniert! Von alleine werden solche Probleme nicht behoben...
> Nur die X-Server-Konfiguration war komplett daneben (Etch Stand Mitte Februar). Grafikkarte und Maus falsch erkannt. Konnte ich aber relativ schnell von Hand beheben.
Also da kann ich nur zustimmen, aber das hat mit Debian nicht zu tun, leider gibt es nach Jahren und Jahren immer noch keinen brauchbaren Xorg configurator.. Unglaublich sowas... Das Ding erkennt alles automatisch, oder wenn nicht, oder man macht eine Änderung, will die 3d Bescheunigung aktivieren, dann geht man durch die Hölle, der verdammte X server startet nicht mehr... Ich denke, das ist der super killer bei allen die im Moment Ubuntu ausprobieren, weil es da genau gleich ist. Die Wahrheit ist, dass wir noch Jahre von etwas entfernt sind, das Windows schon bei W98 unterstützt hat und nämlich, dass der Xserver in jedem Fall mal startet, einfach mit 640 x 400, weil das JEDE GraKa mittlerweihle packt. Aber nein, man hört so bescheuerte Kommentare wie "no core pointer" Aha, keine Mouse dran? Kann es sein, dass die offene Tür der Passagierkabine den ganzen Öltanker stoppt?
Ich habe mich schon sehr gewundert, wie wunderbar z.B. Ubuntu die Xconfig beim Installieren erkennt, aber man das nachher nie mehr so schön automatisch hinbringt. Viele Konfiguratoren bei Linux funktionieren nur beim Installieren des Systems, so z.B. bei Software RAID, LVM und diversem anderen... habe nie verstanden, warum das so ist.
Die Wahrheit ist, dass wir noch Jahre von etwas entfernt sind, das Windows schon bei W98 unterstützt hat und nämlich, dass der Xserver in jedem Fall mal startet, einfach mit 640 x 400, weil das JEDE GraKa mittlerweihle packt.
>>Die Wahrheit ist, dass wir noch Jahre von etwas entfernt sind, das Windows schon bei W98 unterstützt hat und nämlich, dass der Xserver in jedem Fall mal startet, einfach mit 640 x 400, weil das JEDE GraKa mittlerweihle packt.
>Und was soll das bringen?
Was das bringen soll? Liegt das nicht auf der Hand? Nur weil ich Debian oder Ubuntu bevorzuge, heisst das nicht, dass ich ein command line fetischist bin wie manche. Wenn ich eine Zeile der xconfig zerschiesse, dann startet der xserver nicht mehr (er probiert ja die konfig nicht mal rasch aus, bevor er was ändert, nett). Ich bin dann draussen, kein GUI, alle tools die schnell was konfigurieren können sind weg, kein synaptics, keine gui network config. Das nervt dann schon, dass dass man draussen ist, nicth mal in einen normalen Browser reinkommt, wo man im Internet nach hilfe fragen kann. Man braucht eine zweite Maschine... Ist dann nicht so cool, wenn man nur eine hat. Und nein, Lynx ist indiskutabel! Und DAS geht bei 640 x 480....
Also da kann ich nur zustimmen, aber das hat mit Debian nicht zu tun, leider gibt es nach Jahren und Jahren immer noch keinen brauchbaren Xorg configurator.. Unglaublich sowas... Den gibt es, aber den soll man überhaupt nicht brauchen müssen. Genau daran wird und wurde seit einiger Zeit gearbeitet. Die xorg.conf bei Fedora besteht nur noch aus ein paar Zeilen. Der Rest wird automatisch erkannt. Das Ziel ist, dass die xorg.conf komplett überflüssig wird.
>Den gibt es, aber den soll man überhaupt nicht brauchen müssen.
Wo? Da wäre ich SEHR dran interessiert. Und das mit dem nicht brauchen müssen, den höre ich auch immer wieder. Leider wird es auch in den nächsten 10 Jahren noch Dinge zu konfigurieren geben, wie z.B. ist es mit dual-head? Graphik beschleunigung? Und leider sind wir auch beim neusten VGA HW interface noch weit davon entfernt, dass der Monitor sich klar mit dem OS verständigen kann, WAS er ist und welche Auflösungen er unterstützt. Nicht mal Windows checkt das... Wenn man ein System zum LAN gamen zu einem Kollegen nimmt, 1600 x 1200 drauf hat, mit 85 herz, dann checkt windows das nicht, dass der 1280 x 1024 LCD da einfach keinen Wank macht, weil es zu blöde ist, etwas anderes als 60hz darzustellen. Das kann es aber dem OS nicht sagen... aber verstehe schon, ist extrem aufwendig.. solch eine Information wäre ja wohl 471 Gigabytes von daten die der Monitor dem OS melden müsste *grins*
Leider wird es auch in den nächsten 10 Jahren noch Dinge zu konfigurieren geben, wie z.B. ist es mit dual-head? Warum soll das in die xorg.conf? Ich will doch nicht den X-Server neu starten, nur weil ich nen Beamer angeschlossen habe. Genau hier soll XRandR 2.0 Abhilfe schaffen.
Graphik beschleunigung? Was ist damit? Gibt es irgendeinen triftigen Grund, dri nicht einfach standardmäßig zu laden?
Und leider sind wir auch beim neusten VGA HW interface noch weit davon entfernt, dass der Monitor sich klar mit dem OS verständigen kann, WAS er ist und welche Auflösungen er unterstützt. Ich habe noch keinen Monitor der letzten Jahre gesehen, mit dem das nicht klappt.
Wenn man ein System zum LAN gamen zu einem Kollegen nimmt, 1600 x 1200 drauf hat, mit 85 herz, dann checkt windows das nicht, dass der 1280 x 1024 LCD da einfach keinen Wank macht, weil es zu blöde ist, etwas anderes als 60hz darzustellen. Ich kenne nur das genaue Gegenteil, nämlich dass sich Gamer darüber aufregen, dass, wenn ein Spiel die Auflösung wechselt, die Bildwiederholrate standardmäßig auf 60 Hz gesenkt wird. Und damit hat kein TFT-Monitor ein Problem, zumal 60 Hz VESA-Standard sind. Du hättest ja nicht mal ein Bild beim Bootvorgang, wenn der Monitor keine 60 Hz versteht.
Aber selbst wenn das, was du erzählst, so stimmt (ist überhaupt Plug + Play Monitor als Bildschirm eingetragen und nicht irgendwas festes?), so zeigt das eben, dass statische Konfiguration unsinnig ist. X.Org mit XRandR 2.0 soll bei jedem Start des X-Servers eine neue automatische Erkennung des Monitors durchführen und auch im laufenden Betrieb z.B. bei Notebooks auf einen externen Monitor reagieren.
Danke Debian, Danke Ian Murdock Danke Deut.... nein, aber trotzdem es kann nicht oft genug gesagt werden Debian GNU/Linux ist das wundervollste Linux OS auf der Welt - meiner Meinung!
Ich verwende nun Debian seit Version 2.1(slink) Das sind schon einge Jahre (7-8 Jahre) und ich wurde nur selten enttäuscht! Ich wechselte auch zeitweise zu Ubuntu dapper drake bis 6.10 und es lief auch gut aber ein dist-upgrade von 6.7 auf 6.10 hat mir mein System "zerschossen" das ist mir unter Debian noch nicht passiert und deswegen für mich Grund genug wieder zu wechseln und mit Etch bin ich sehr zufrieden das habe ich auf gut 10 total verschiedenen Systemen mit unterschiedlichen Konfigurationen installiert und es läuft :)
Ich wechselte auch zeitweise zu Ubuntu dapper drake bis 6.10 und es lief auch gut aber ein dist-upgrade von 6.7 auf 6.10 hat mir mein System "zerschossen".....
Und das trotz der Tatsache, dass Ubuntu auch dieses (Zitat von diversen Debian-Aposteln) "geniale Debian-Paketmanagement benutzt, das ja viiieeel besser als bei allen RPM basierten Distributionen ist" benutzt ???? ;-)
>Und das trotz der Tatsache, dass Ubuntu auch dieses (Zitat von diversen Debian-Aposteln) "geniale Debian-Paketmanagement benutzt, das ja viiieeel besser als bei allen RPM basierten Distributionen ist" benutzt ????
Ja, genau. Das hat nämlich nichts mit dem zu tun. Mal ein RedHat auf einen neuen Releas upgegradet? Das kann dich auch bei RPM wüst verhauten, sogar noch schlimmer, da RPM noch irgendwie halbbacken ist (wem es mal die Database zerhauen hat, der weiss was ich meine und das passiert, im Vergleich zu DPGK, wo es mir nach vielen Jahren, einem desktop und vielen Servern die dauernd laufen noch nie passiert ist, was unglaublich ist) Wenn du einen Upgrade machst, gibt es diese Chance, weil es ein Wunder ist, dass das überhaupt gehen kann. Denk mal, was das für ein Wunder wäre, wenn Windows das könnte, direkt vom Internet.. und dann nachher noch funktioniert... schon mal w98 auf XP upgegradet? und mal ne Weihle damit gearbeitet? Ist ne convenience Sache, aber nicht wirklich brauchbar.
schon mal w98 auf XP upgegradet? Das würde bei Debian vermutlich gar nicht funktionieren. Oder hat schon mal jemand erfolgreich slink direkt auf sarge aktualisiert?
Das sag' ich ja auch immer, dass RPM und DEB sich prinzipiell nichts nehmen. Gegenteiliges wird ja nur (wie ich geschrieben hatte) von den Debian-Aposteln behauptet....
Ich hab vor kurzem selbst ein Ubuntu Desktop System um zwei Versionen aktuallisiert (auf die aktuelle Beta), es war erschreckend Problemlos. Vor allem das einfache Upgrade über den UpdateManager war nett.
Abhaengigkeiten stoeren mich bisweilen nur weil ich keinen staendingen Internetanschluss habe. Ist aber immerhin besser als Windows wo Programme unkontrolliert 10x die selbe DLL auf die Festplatte kopieren.
Debian ist fuer mich das stabilste System das ich je hatte und macht mit 2 DVDs die fehlende Internetleitung wieder wett. So aktuell brauch ich die Programme nun auch wieder nicht. Ubuntu hat so einige bugs wie zBsp. mit KDE,aber das wird von Version zu Version besser werden.
RPM sux und fuer Gentoo muss man sich regelrecht freinehmen so oft wie es sich aendert und so lahm wie das compilet.
Von DistributionsNutte am Mi, 4. April 2007 um 11:49 #
und mit Etch bin ich sehr zufrieden
Full Ack, das kann ich nur bestätigen, ich hatte sie schon alle und Debian ist die einzige Distribution, die seit 3 Jahren auf meinem Desktop mehr als nur zufriedenstellend läuft. RedHat von 5.2 - 9.0 und es wurde schlimmer, Fedora überlebte neben SuSe genau zwei Stunden inklusive Installation. Gentoo habe ich nach drei Stunden Compilerorgie abgebrochen (ich scheiß auf 1/1000 Sekunde beim Start). Slackware durfte mein altes Thinkpad 600e beglücken, dies ist die einzige Distribution der ich noch neben dem Debian-Gott huldige. Und wenn ich die Linux-Schlampe "Maria" betrüge, dann nur mit FreeBSD und NetBSD. Alles andere für den Rest ;-)
Daher vollsten RESPEKT für die Debian-Fraktion und DANKE für eure Mühe und euer Blut .... Gott wird es euch danken, nicht mit Jungfrauen, sondern mit erfahrenen Biestern ;-)
Man hätte also das stable wie bisher, mit stable-desktop einen häufiger aktualisierten stable-Zweig. Größere Umbauten erfolgen nachwievor in experimental und sid. Getestet werden sie 2-3 Wochen in testing und kommen dann in das Zwischen-stable rein. Damit müsste doch auch ein echtes stable-Release dann schneller erfolgen können, bspw. alle 6 oder 12 Monate.
Aber ich gebe zu: Ich habe von den internen, organisatorischen und technischen Dingen beim Debian-Release-Zusammenbau keine Ahnung, fände es halt nur schön, wenn ein recht stabiles debian auch in aktuell existierte, das aber näher am Original ist, als bspw. Ubuntu.
wobei ich hier vor- und nachteile sehe. einerseits will ich ne stabile distribution (so wie es nun ist) welche halt nicht unbedingt die aktuellste software enthält und nur bugfixes reinfliessen, andererseits will man im desktop-linux vielleicht etwas aktuellere software mit aktuellen features.
jedenfalls sollte der releasezylus im desktopbereich beschleunigt werden. ich somit eine server/desktop splitting begrüssen. wobei server auch xorg, kde enthalten kann, jedoch nur security updates, so wie es heute existiert. was aber wiederum ein mehraufwand für die maintainer bedeuten würde.
Mit einem Blick auf die BSDs -> man splittet in Base und "Userland", danach implementiert man das Ports-System und überlässt es dem User selbst, ob er gerne den neuesten FF, OO etc. haben will oder nicht.
Einfach mal eins anschauen
lg
Erik
zwei Probleme:
1. Es reicht nicht, die Software einfach zu aktualisieren. Es muss auch das Upgrade von einer zur nächsten Version gewährleistet sein. Nur was passiert, wenn ich von Version 1.0 eines Softwarepaketes direkt auf 1.3 Upgrade und nicht über 1.2 gehe. Wenn Applikation X aktualisiere, warum nicht auch Y. Und um die aktuelle Software nutzen zu können, braucht ich in vielen Fällen eine aktuellere Kernelversion. Letztendlich landet man dann doch bei SID bzw. Testing. Genau, was du dir wünscht, wird ja mit Testing geboten.
2. Externe Anbieter, ich meine nicht vorrangig propreritärer Software, könnten sich im Prinzip auf nichts mehr verlassen, alles wäre im Wandel. Support ausgeschlossen.
Sicher gibt es noch eine ganze Reihe anderer Schwierigkeiten.
Die Lösung hieß bei Debian: Security-Updates auch für Testing. So kann man als experimentierfreudiger Benutzer Testing verwenden, muss aber nicht darum bangen, dass entscheidende Updates in SID hängen, weil irgendwelche Querabhängigkeiten nicht erfüllt sind. Es gibt ja viele Projekte die eine Lösung schaffen wollten (Sidux, Kanotix, Ubuntu usw.). In bestimmten Bereichen ist ihnen das sicher auch gelungen. Den Schmu (Lucky#Slevin) hat von denen wohl keiner gefunden.
Was das Debianprojekt hier geleistet hat ist schon wirklich beachtlich. Software mit akzeptablen Programmversionsstand und die gewohnte Stabilität. Wo bekommt man ein so komplexes umfangreiches Softwareangebot, das aufeinander abgestimmt ist.
Selbst wenn man bereit ist dafür zu bezahlen.
Dankeschön.
Aber die Systempflege ist dort einfach unmenschlich. Für Geeks bestimmt kein Problem, aber für Leute die mal hier und da was neues brauchen, wegen bekannten Fehlern, ist diese Form unbrauchbar und abschreckend.
> Was das Debianprojekt hier geleistet hat ist schon wirklich beachtlich. Software mit akzeptablen Programmversionsstand und die gewohnte Stabilität.
Bei Linux gibt es über 18.000 Softwarepakete, von denen die meisten > 10.000 für Entwickler (dev-Biblotheken und Programme) sind. Ein akzeptabler Programmversionsstand hört aber schon dann auf, wenn ein einziges Programm, auf der betreffenden Distri nicht mehr läuft. Jetzt versuch mal einem Normalsterblichen zu erzählen er müsse nur wegen ein paar Programmen sein ganzes System upgraden (Geschätzte Zeit: ca. 1 Stunde). Der kommt dir dann schnell mit dem Satz: Never chang a running System! Sowas nenne ich Eigentor.
Was mich an Linux einfach stört sind die zig Abhängigkeiten. 10 Programme haben 100 Abhängigkeiten. Wenn du jetzt ein Programm und 6 Abhängigkeiten aktualisierst, dann musst du damit rechnen das 9 Programme nicht mehr starten oder Fehler erzeugen.
Wir leben Heute in einer Welt in denen 1TB Speicher und 2-3GHz Prozessoren keine seltenheit mehr sind, aber Linux soll immer noch mit einem Pentium 100 laufen und weniger als 30MB Speicherplatz verbrauchen. Da wundert es mich nicht, das die Hersteller auf diese Kundschaft keine Lust hat.
Da muss ich dir zustimmen! :)
> Bei Linux gibt es über 18.000 Softwarepakete, von denen die meisten > 10.000 für Entwickler (dev-Biblotheken und Programme) sind. Ein akzeptabler Programmversionsstand hört aber schon dann auf, wenn ein einziges Programm, auf der betreffenden Distri nicht mehr läuft. Jetzt versuch mal einem Normalsterblichen zu erzählen er müsse nur wegen ein paar Programmen sein ganzes System upgraden (Geschätzte Zeit: ca. 1 Stunde). Der kommt dir dann schnell mit dem Satz: Never chang a running System! Sowas nenne ich Eigentor.
Ack! Wobei man nicht gleich upgraden muss, wenn ein Paket fehlt. Man könnte es sich auch selber bauen, aber auch dies ist unter Debian eher abschreckend als entgegenkommend.
> Was mich an Linux einfach stört sind die zig Abhängigkeiten. 10 Programme haben 100 Abhängigkeiten. Wenn du jetzt ein Programm und 6 Abhängigkeiten aktualisierst, dann musst du damit rechnen das 9 Programme nicht mehr starten oder Fehler erzeugen.
SEHR übertrieben!! Und meist sieht man VIELE Abhängigkeiten auch nur bei Debian und dessen Derivaten, da fast jedes Paket in *-lib *-data *-dev usw. usf. gesplittet wird. (ob damit jmd geholfen ist bleibt mal offen)
Oder aber du hast Debian benutzt und leider diese schlechten Erfahrungen damit machen müssen, kann hier leider keine Debianerfahrungen teilen. Es ist auf jeden Fall übertreieben worden. ;)
Auch dass andere Programme den Geist aufgeben wenn geupdatet wird ist ich sag mal falsch
> Wir leben Heute in einer Welt in denen 1TB Speicher und 2-3GHz Prozessoren keine seltenheit mehr sind, aber Linux soll immer noch mit einem Pentium 100 laufen und weniger als 30MB Speicherplatz verbrauchen. Da wundert es mich nicht, das die Hersteller auf diese Kundschaft keine Lust hat.
Dass solche Maschinen noch ein aktuelles OS laufen lassen können ist doch subba!
Solange man keine negativen Effekte dadurhc erleidet sehe ich hier mal gar kein Problem. Du selbst erläuterst schließlich auch keines. 
Mir zum Beispiel, ich binde mein Sourcepackage an libc-dev und werde, wenn das auf eine neuere Version zeigen sollte, automatisch durch einen einfachen Rebuild ein Paket mit neuen Abhängigkeiten erhalten.
lg
Erik
Für mich fiel die Wahl auf Debian, weil es einfach ein Traum ist, software zu managen und das macht man eh dauernd, Programme installieren, evaluieren und wieder entfernen... Bei allen anderen Distro ist das einfach sehr sehr schwierig..
Ubuntu basiert ja auch das gleiche und als Desktop Distro ist es viel besser geeignet und macht mal folgenden Test:
Leere Kiste, Distro installieren. Ziel: Video-Film schauen, Xvid.. (vlc bietet sich an)
Wie schnell geht das?
20 min... Ubuntu installieren (oder Kubuntu, je nach Lust und Laune),
Ubuntu booten, apt-get install vlc
und woiiinnnggg
Video schauen....
Nun soll mir mal jemand erklären, wo das schneller geht? Und Knoppix gilt nicht, da es ja auch Debian basierend ist.
Über kurz oder lang sehe ich eine starke Verbreitung der dpkg basierenden Distros, weil es meiner Meinung einfach das beste package format ist, so wie es implementiert ist und dank apt-get ist software distribution und management einfach ein Traum. Das ist allen anderen Systemen Jahre vorraus.
Ich manage noch VMware ESX systeme (die ja auch quasi Linux basierend sind)... da ladet man die Patches noch brav als RPM runtern... Die kämen nie auf die Idee, das repository mässig zu tun... so was von bescheuert.
Und alles sitzen auf RPM rum und bestehen drauf... RedHat würde auch gut dran tun, das zu beerdigen.
Geht das auch genauer? So neu ist das übrigens nicht, Mandriva (bzw. Mandrakelinux) verwendet schon seit Ewigkeiten urpmi.
20 min... Ubuntu installieren (oder Kubuntu, je nach Lust und Laune), Ubuntu booten, apt-get install vlc
Nö, vlc ist nicht in main. Außerdem: ein "rug install vlc", "smart install vlc", "urpmi vlc", "yast -i vlc" oder "yum install vlc" tuts genauso.
Ich manage noch VMware ESX systeme (die ja auch quasi Linux basierend sind)... da ladet man die Patches noch brav als RPM runtern... Die kämen nie auf die Idee, das repository mässig zu tun... so was von bescheuert.
Was kann RPM dafür? Die offiziellen DEB-Pakete für OpenOffice.org gibts übrigens nur als Tarball zum Download.
Hm, bei Linux (dem Kernel) kenne ich nur ein Softwarepaket, nämlich das Tarball von kernel.org:-) Aber du meinst sicher Debian/GNU Linux.
Was mich an Linux einfach stört sind die zig Abhängigkeiten. 10 Programme haben 100 Abhängigkeiten. Wenn du jetzt ein Programm und 6 Abhängigkeiten aktualisierst, dann musst du damit rechnen das 9 Programme nicht mehr starten oder Fehler erzeugen.
All diese Probleme habe ich zu Hause nicht. Nicht jede Distribution benutzt Abhängigkeiten.
Wenn man keine Ahnung hat, einfach mal....
Was mich an deiner Aussage stört: Du hast keine Ahnung von Betriebssystemen, oder? Und über Linux hast du dich per Hörensagen informiert.?
Für besseres Verstehen: Jedes Programm benötigt eine gewisse Umgebung, in der es laufen kann. Ist diese nicht vorhanden, läuft das Programm nicht. Beim XP-SP2 wurden an vielen Stellen derart gravierende Änderungen gemacht, dass manche Programme nicht mehr funktionierten. Das nennt sich "Abhängigkeiten". Die sind immer vorhanden und haben nichts mit Linux zu tun.
Aktuelles Beispiel: Aufgrund von Konflikten kann ich momentan zwar Eclipse nutzen, sobald ich aber Azureus installieren wollte, würde mir "apt" Eclipse komplett löschen. Wegen Abhängigkeiten. Die einfachste Lösung wäre ein vorkompiliertes Eclipse nach /opt zu schieben. Da sind die Libraries schon mitgeliefert und beides funktioniert perfekt.
Die vielen Abhängigkeiten sind dazu da, dass eben nicht jede Applikation tausend libraries (und das gilt auch für dlls) mitliefert/mitliefern muss.
Aber nochmal: Das hat NULL, GAR NIX, NADA mit Linux zu tun. Und noch viel weniger mit Debian, da die solchen Problemen recht oft mit der Benennung der Pakete aus dem Weg gehen. Da funktioniert das dann ganz ordentlich, dass 2 verschiedene Versionen einer Bibliothek nebeneinander leben.
Sollten nach einem Update in stable tatsächlich "9 Programme nicht mehr starten oder Fehler erzeugen", dann wäre das in meiner Erinnerung das erste Mal.
> ...dass manche Programme nicht mehr funktionierten. Das nennt sich "Abhängigkeiten". Die sind immer vorhanden und haben nichts mit Linux zu tun.
Aha, dann sind also Abhängigkeiten was anderes als Abhängigkeiten - interessant
> Aber nochmal: Das hat NULL, GAR NIX, NADA mit Linux zu tun.
Komisch, wieso nervt mich dann das Paketsystem, das es immer erst Abhängigkeiten auflösen muss? Frechheit!
Warum stoeren dich die Abhaengigkeiten, wenn sie automatisch aufgeloest werden?
Die Alternative waeren statisches Linken fuer alle Anwendungen (unmoeglich) oder eine unkontrollierte DLL hell.
Stable ist einfach rock solid, da kann man nichts rütteln dran. Wenn es zulassen würde, dass man irgendwelches Zeugs installiert, das Konflikte erzeugt, dann wäre es vorbei mit stable. Da soll man testing oder SID brauchen...
Habe mit Sarge nun über die Jahre fast seit es stable geworden ist auf dem Laptop jeden Tag beruflich gearbeitet und schlägt Windox XP in stabilität und performance ein paar mal rundherum. Bin absolut häppy.. Ich türftle auch gerne rum, installiere mal neue Software zum ausprobieren, aber man muss sich eben an der Nase nehmen: Wenn es nicht im Repository drin ist, nur im unstabileren Release ist, dann soll man die Finger davon lassen, weil man danach nur wieder flucht, wenn das System auf einem mal nicht mehr richtig geht. Ein produktives System ist langweihlig und teilweise etwas altbacken, das hat mit bugfixing zu tun, neue Features bringen neue Bugs und hauen die Stabilität runter.
Für das installiert man ne VMware maschine und lässt es darauf tuckern.
Es sei denn, Stabilität ist einem schnuppe, man arbeitet darauf nicht professionell, dann her mit SID.. perfekt...
Also ich habe mich seit ich mit Debian mit Sarge angefangen habe sehr über die massiv professionelle Qualität des Distros gewundert. Ein Traum, absolut. Low maintenance. Für mich das beste Linux Distro überhaupt, und habe früher lange auf RedHat, SuSE und Fedora gearbeitet.
Generell sehe ich hier aber eher Linux im Vorteil, wenn man sich mal den Sinn der LSB vor Augen hält, denn hier gibt es einen Standard, der distributionsübergreifend zahlreiche dynamische Bibliotheken an definierter Stelle in definierter Version vorgibt.
lg
Erik
Das stört mich ganz und gar nicht. Die meisten (eigentlich fast alle) GNU/Linux-Distris sind eben nur unfähig diese Abhängigkeiten aufzulösen. Warum? Halbherziges Paketmanagement!
stabil aber alle 6 monate neues Release ... wer will kann LTS nehmen.
Kluge Köpfe denken schon darüber nach: http://kitenet.net/~joey/code/debian/cut.html
xD
sry xD
MfG
Marcus
*SCNR*
Wahlweise auch einen BSD-Kernel ...
Das Gesamtbild schaut einfach so altbacken aus. Zum Glück kann sich jeder seine Distri selber ausscuchen, aber Debian ist für mich immer noch das unangetastete Nischending, welches nur zu Serverzwecken ngeeignet sein kann, und in keinster Weise Desktopansprüchen entgegenkommt. (imo!)
Wenn du das nicht willst kannst du ja Ubuntu nutzen, da hast du dann die selbe Basis aber mit neueren Paketen. Das ist ja das gute an Debian, es ist nicht nur eine gute Distrie, nein es ist auch eine sehr gute Metadistrie als Basis für andere Projekte.
> Debian legt die zu nutzende Version aber schon früh fest und sorgt dafür das diese dann aber auch
> unter Garantie funktioniert, in allen erlaubten Kombinationen.
Das ist die Wunschvorstellung, in der Praxis sieht das ganz anders aus.
Wie man an dem für Desktop Verhältnisse instabilen und recht unbrauchbaren Debian Sarge mit Gnome 2.8 sehen konnte.
Hier wäre jede Gnome Version größer oder gleich 2.10 sinnvoller gewesen als Gnome 2.8 und Gnome 2.10 gab es zum Releasezeitpunkt von Debian Sarge definitiv schon einige Monate.
Natürlich kann eine neue Version neue Probleme aufwerfen, aber es werden auch viele alte Probleme gelöst, die in dem alten Debian Paket ungelöst bleiben.
Zumindest ist das meine Erfahrung mit Debian Sarge und insb. der verwendeten Gnome 2.8 Version.
Gerade die sich in schneller Entwicklung befindeten Desktop Anwendungen sind unter Debian ein Problem,
da viele dieser < 1.0 Versionen noch hier und da Bugs haben oder wichtige, für eine sinnvolle Nutzung, unabdingbare Features fehlen welche erst nach und nach von den Entwicklern der Anwendung behoben(Bugs) oder eingebaut (Features) werden, aber genau diese Verbesserungen schaffen es nie in Debian, da Debian ein ganz anderes Konzept verfolgt.
Wenn man Glück hat, dann findet man lediglich ein nicht supportetes Paket in den Backports, sofern die Anwendung bekannt genug ist, aber da das nicht supported ist, kann man es auch gleich selber von der Projektseite downloaden und compilieren.
Desweiteren gibt es bei den Backports auch meist nur neue Versionen der verschiedenen Desktop Environments, anstatt die eigentlich wichtigen Nutzanwendungen zum Arbeiten, welche viel wichtiger in den Backports wären.
Um es also auf den Punkt zu bringen, Debian ist keine rund um sorglos Lösung.
Man muß auch neue Ziele setzen.
Den Etch GNOME find ich eher noch ziemlich fehlerhaft, sodass das Upgrade darauf für mich eher einen Rückschritt darstellt.
Da ist es mehr als nur verständlich, daß die Debianentwickler a) eine weile beschäftigt sind irgendein gnome release zu stabilisieren und b) wenn sie es denn soweit haben, nicht von heute auf morgen auf die neuste Version wechseln können.
Beschwer dich nicht bei Debian, beschwer dich bei gnome.
In experimental war eine Zeit lang ein recht großer Anteil an "Gnome 2.16"-Paketen, leider nur für ADM64 (glaub ich) kompiliert.
Die für meinen Pentium M zu kompilieren war aber bei keinem einzigen Paket ein Problem und ich hatte nach geschätzten 30 Minuten ein nahezu vollständiges 2.16.
Momentan gibt's ja sogar schon einige 2.18er Pakete in experimental und die laufen hier total rund.
> ich hatte nach geschätzten 30 Minuten ein nahezu vollständiges 2.16.
>
> Momentan gibt's ja sogar schon einige 2.18er Pakete in experimental und die laufen hier total
> rund.
Deine Erfahrung in allen Ehren, aber du willst doch nicht ernsthaft deine Erfahrung mit einer einzelnen Installation auf einer einzelnen Rechnerarchitektur bei Benutzung von nur wenigen ausgewählten (da für dich nützlichen) Softwarepaketen mit den Release-Anforderungen von Debian vergleichen, oder?
lg
Erik
Debian wählt man üblicherweise, weil man eine stabile Basis für einen Rechner haben möchte, der dann für einen längeren Zeitraum beinahe wartungsfrei läuft und läuft und läuft. Die stabile Basis schließt stabile, sich also nicht ständig ändernde Softwareversionen ein, um eben nicht in unregelmäßigen Abständen Konfigurationsdateien anpassen und Inkompatibilitäten beheben zu müssen.
Speziell bei Servern sind starre Versionsnummern üblicherweise kein Problem, da Server normalerweise einmal geplant und dann für lange Zeit in genau der geplanten Konstellation laufen. Und das möglichst ohne Ausfälle z.B. hervorgerufen durch Inkompatibilitäten neuerer Softwareversionen.
Die Aktualität deiner neuen Distribution hat einen Preis, nämlich den damit verbundenen höheren Wartungsaufwand was wiederrum ein höheres Ausfallrisiko bedingt. Gerade bei Produktivsystemen möchte man darauf aber in der Regel verzichten.
Aber natürlich gibt es für jede Regel irgendwo eine Ausnahme. Nur Ausnahmen bilden deshalb nicht die Regel.
aber naechste woche release?
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=416404
ich bin kein Coder und kein Paketmaintainer, daher mal 'ne blöde Frage:
Gibt es gewichtige Gründe (außer Plattenplatz- Ersparnis), warum bei Debian die Pakete so fein geschnitten sind? Software, die in Slackware auf ein gutes Dutzend Pakete aufgeteilt ist (z.B. KDE), ist in Debian auf mehrere Dutzend Pakete gesplittet (oder noch mehr? - kann gerade nicht nachsehen).
Damit steigt doch sicherlich auch die Komplexität beim Paketbau und die Wahrscheinlichkeit von Inkonsistenzen.
Vor allem: über die automatische Abhängigkeitsauflösung sind die meisten Pakete doch eh' miteinander verbandelt, und man kann eh' kaum etwas abwählen.
Wo ist der Sinn ?
Bei dem Splitpkg schreibst du für jedes subpkg eine beschreibung(dadurch leichter zu finden, wenn man nach kmail sucht, und nicht nach kde pim), und ein command was es installiert, hier z.B. cd kmail;make install --prefix debian/kmail oder so ähnlich.
Dann noch ein Metapaket (kde), was alle pakete installiert, und nach belieben metapakete die eine auswahl installieren (kubuntu-desktop z.B.)
Es geht aber auch darum, soviel aus einem Programm auszulagern wie möglich um bei einem Fehler in einer Datei nicht mehrer Programme mit updaten zu müssen, sie diese fest einkompliert haben.
Für einen Programmierer ist das auch paktisch, da er auf getestete und fertig installierbare Dateien (Bibliotheken, Einstellungen) zurückgreifen kann, ohne ein ganz anderes Progamm in die Abhängigkeitsliste aufnehmen zu müssen, oder die betreffenenden Daten selber übernehmen.
Je feiner die Granualtion ist um so leicher wird es ein System zu erweitern ohne Daten doppelt installieren und sich um deren Aktualität kümmern zu müssen.
Sicher kann das zu Problem mit rekusiven Abhängigkeiten und sehr komplexen Anhängigkeitsbäumen kommen, aber das System später sicher zu halten wird sehr viel leichter.
Häufig werden von einem Programm nur einige "Fremddateien" von anderen Programmen/Bibliotheken gebraucht. Es wäre auch ein Sicherheitsrisiko, alle Programm- und Bibliotheks-gruppen mit zu installieren.
Wollte meinen Drucker zum laufen bekommen, und starte den Konfigurationsdialog. Der ist irgendwie mit dpkg verbandelt, ich wähle meinen Drucker aus und sage, ich bin lokal damit verbunden (USB). Was passiert: Ein bisschen was wird installiert, aber Drucker funktioniert keiner.
Erst als ich im kpackage das richtige Treiberpaket händisch (!) nachinstalliert habe hat der Drucker funktioniert.
Was auch passiert ist: Irgendwann hat KDE einfach aufgehört zu starten (nach einem unsauberen shutdown). Ich habe dann einen neuen User angelegt, und dort hat KDE einwandfrei funktioniert, nur unter dem original User war KDE nicht mehr zum Laufen zu bekommen. Sowas ist mir unter Mandriva NIE passiert, und da gabs auch den einen oder anderen unsanften Shutdown. Vielleicht liegts ja an diesen seltsamen socket files die KDE überall hinstreut, und dass ich da nicht alle gefunden und eliminiert habe.
Debian ist mein Ziel seit ca. 2 Jahren, aber offensichtlich bin ich zu sehr DAU um damit zurechtzukommen.
Eine Desktopversion, die nicht nur die absolut unbedingt notwendigen Pakete installiert, sondern auch welche die ich als "highly recommended" bezeichnen würde wäre schon fein.
Heute verwende ich ein Debian unstable und kann damit sogar produktiv sein *g*.
KDE legt seine Konfiguration im .kde-Verzeichnis deines Homeverzeichnisses ab. Du kannst z.B. das Verzeichnis umbenennen um das komplette KDE auf Defaulteinstellungen zurückzusetzen. Praktikabler ist es aber wohl, nach den zum Zeitpunkt des unsanften Shutdown geöffneten Dateien zu suchen (z.B. mit find anhand der Zugriffzeit) und diese dann genauer unter die Lupe zu nehmen. Und bei beschädigtem/seltsamen Inhalt zu löschen oder den defekten Teil zu entfernen.
danke für die Erläuterungen.
> Sicher kann das zu Problem mit rekusiven Abhängigkeiten und sehr komplexen Anhängigkeitsbäumen kommen, aber .......
Ja, deshalb fragte ich. Beim Spielen mit einer auf Debian testing beruhenden Disto und mit Kubuntu 7.04 hatte ich solche Effekte. Die sind für 'nen DAU besonders frustrierend, weil der Paketmanager bzw. die drübergestülpte GUI unmittelbar bei Auftreten eines solchen Fehlers mit 'ner kryptschen Fehlermeldung aussteigt und sich weigert, das System zu aktualisieren.
Na ja, fairerweise muß man zugeben, daß Beta-Versionen nun mal nicht in DAU- Hände gehören.
keinen eigenen Kernel mehr kompilieren musste. Auch wurde zahlreiche Hardware bei mir jetzt automatisch erkannt z.B. Soundkarte, Netzwerkkarte. Sogar der IPOD wurde automatisch beim Einstecken gemounted! Ähnlich der Scanner: Anschließen, Einschalten, geht!
Nur die X-Server-Konfiguration war komplett daneben (Etch Stand Mitte Februar). Grafikkarte und Maus falsch erkannt. Konnte ich aber relativ schnell von Hand beheben.
Kompliment an Debian, die Installation/Konfiguration scheint jetzt deutlich einfacher!
Und, hast du einen Fehlerbericht geschrieben? Ist für die Entwickler vielleicht nicht ganz uninteressant, wenn die Hardwareerkennung bei gewissen Gerätekombinationen nicht vernünftig funktioniert! Von alleine werden solche Probleme nicht behoben...
Also da kann ich nur zustimmen, aber das hat mit Debian nicht zu tun, leider gibt es nach Jahren und Jahren immer noch keinen brauchbaren Xorg configurator.. Unglaublich sowas...
Das Ding erkennt alles automatisch, oder wenn nicht, oder man macht eine Änderung, will die 3d Bescheunigung aktivieren, dann geht man durch die Hölle, der verdammte X server startet nicht mehr... Ich denke, das ist der super killer bei allen die im Moment Ubuntu ausprobieren, weil es da genau gleich ist.
Die Wahrheit ist, dass wir noch Jahre von etwas entfernt sind, das Windows schon bei W98 unterstützt hat und nämlich, dass der Xserver in jedem Fall mal startet, einfach mit 640 x 400, weil das JEDE GraKa mittlerweihle packt.
Aber nein, man hört so bescheuerte Kommentare wie "no core pointer"
Aha, keine Mouse dran? Kann es sein, dass die offene Tür der Passagierkabine den ganzen Öltanker stoppt?
Ich habe mich schon sehr gewundert, wie wunderbar z.B. Ubuntu die Xconfig beim Installieren erkennt, aber man das nachher nie mehr so schön automatisch hinbringt. Viele Konfiguratoren bei Linux funktionieren nur beim Installieren des Systems, so z.B. bei Software RAID, LVM und diversem anderen... habe nie verstanden, warum das so ist.
Und was soll das bringen?
>Und was soll das bringen?
Was das bringen soll? Liegt das nicht auf der Hand? Nur weil ich Debian oder Ubuntu bevorzuge, heisst das nicht, dass ich ein command line fetischist bin wie manche. Wenn ich eine Zeile der xconfig zerschiesse, dann startet der xserver nicht mehr (er probiert ja die konfig nicht mal rasch aus, bevor er was ändert, nett). Ich bin dann draussen, kein GUI, alle tools die schnell was konfigurieren können sind weg, kein synaptics, keine gui network config.
Das nervt dann schon, dass dass man draussen ist, nicth mal in einen normalen Browser reinkommt, wo man im Internet nach hilfe fragen kann. Man braucht eine zweite Maschine... Ist dann nicht so cool, wenn man nur eine hat. Und nein, Lynx ist indiskutabel!
Und DAS geht bei 640 x 480....
Den gibt es, aber den soll man überhaupt nicht brauchen müssen. Genau daran wird und wurde seit einiger Zeit gearbeitet. Die xorg.conf bei Fedora besteht nur noch aus ein paar Zeilen. Der Rest wird automatisch erkannt. Das Ziel ist, dass die xorg.conf komplett überflüssig wird.
Wo? Da wäre ich SEHR dran interessiert.
*grins*
Und das mit dem nicht brauchen müssen, den höre ich auch immer wieder. Leider wird es auch in den nächsten 10 Jahren noch Dinge zu konfigurieren geben, wie z.B. ist es mit dual-head? Graphik beschleunigung?
Und leider sind wir auch beim neusten VGA HW interface noch weit davon entfernt, dass der Monitor sich klar mit dem OS verständigen kann, WAS er ist und welche Auflösungen er unterstützt. Nicht mal Windows checkt das... Wenn man ein System zum LAN gamen zu einem Kollegen nimmt, 1600 x 1200 drauf hat, mit 85 herz, dann checkt windows das nicht, dass der 1280 x 1024 LCD da einfach keinen Wank macht, weil es zu blöde ist, etwas anderes als 60hz darzustellen.
Das kann es aber dem OS nicht sagen... aber verstehe schon, ist extrem aufwendig.. solch eine Information wäre ja wohl 471 Gigabytes von daten die der Monitor dem OS melden müsste
xorgcfg
Leider wird es auch in den nächsten 10 Jahren noch Dinge zu konfigurieren geben, wie z.B. ist es mit dual-head?
Warum soll das in die xorg.conf? Ich will doch nicht den X-Server neu starten, nur weil ich nen Beamer angeschlossen habe. Genau hier soll XRandR 2.0 Abhilfe schaffen.
Graphik beschleunigung?
Was ist damit? Gibt es irgendeinen triftigen Grund, dri nicht einfach standardmäßig zu laden?
Und leider sind wir auch beim neusten VGA HW interface noch weit davon entfernt, dass der Monitor sich klar mit dem OS verständigen kann, WAS er ist und welche Auflösungen er unterstützt.
Ich habe noch keinen Monitor der letzten Jahre gesehen, mit dem das nicht klappt.
Wenn man ein System zum LAN gamen zu einem Kollegen nimmt, 1600 x 1200 drauf hat, mit 85 herz, dann checkt windows das nicht, dass der 1280 x 1024 LCD da einfach keinen Wank macht, weil es zu blöde ist, etwas anderes als 60hz darzustellen.
Ich kenne nur das genaue Gegenteil, nämlich dass sich Gamer darüber aufregen, dass, wenn ein Spiel die Auflösung wechselt, die Bildwiederholrate standardmäßig auf 60 Hz gesenkt wird. Und damit hat kein TFT-Monitor ein Problem, zumal 60 Hz VESA-Standard sind. Du hättest ja nicht mal ein Bild beim Bootvorgang, wenn der Monitor keine 60 Hz versteht.
Aber selbst wenn das, was du erzählst, so stimmt (ist überhaupt Plug + Play Monitor als Bildschirm eingetragen und nicht irgendwas festes?), so zeigt das eben, dass statische Konfiguration unsinnig ist. X.Org mit XRandR 2.0 soll bei jedem Start des X-Servers eine neue automatische Erkennung des Monitors durchführen und auch im laufenden Betrieb z.B. bei Notebooks auf einen externen Monitor reagieren.
ist das wundervollste Linux OS auf der Welt - meiner Meinung!
Ich verwende nun Debian seit Version 2.1(slink) Das sind schon einge Jahre (7-8 Jahre) und ich wurde nur selten enttäuscht!
und mit Etch bin ich sehr zufrieden das habe ich auf gut 10 total verschiedenen Systemen
Ich wechselte auch zeitweise zu Ubuntu dapper drake bis 6.10 und es lief auch gut aber ein dist-upgrade
von 6.7 auf 6.10 hat mir mein System "zerschossen" das ist mir unter Debian noch nicht passiert und deswegen für mich Grund
genug wieder zu wechseln
mit unterschiedlichen Konfigurationen installiert und es läuft :)
Danke
Ich wechselte auch zeitweise zu Ubuntu dapper drake bis 6.10 und es lief auch gut aber ein dist-upgrade von 6.7 auf 6.10 hat mir mein System "zerschossen".....
Und das trotz der Tatsache, dass Ubuntu auch dieses (Zitat von diversen Debian-Aposteln) "geniale Debian-Paketmanagement benutzt, das ja viiieeel besser als bei allen RPM basierten Distributionen ist" benutzt ???? ;-)
Gruß
Heiko
Wenn man einem Müllprogramm super Daten füttert kommt hinten auch Müll heraus.
Nur wenn man einem genialen Programm super Daten füttert, kommt hinten was geniales raus.
Elementare Bool'sche Algebra, würde ich sagen
Ja, genau. Das hat nämlich nichts mit dem zu tun. Mal ein RedHat auf einen neuen Releas upgegradet? Das kann dich auch bei RPM wüst verhauten, sogar noch schlimmer, da RPM noch irgendwie halbbacken ist (wem es mal die Database zerhauen hat, der weiss was ich meine und das passiert, im Vergleich zu DPGK, wo es mir nach vielen Jahren, einem desktop und vielen Servern die dauernd laufen noch nie passiert ist, was unglaublich ist)
Wenn du einen Upgrade machst, gibt es diese Chance, weil es ein Wunder ist, dass das überhaupt gehen kann. Denk mal, was das für ein Wunder wäre, wenn Windows das könnte, direkt vom Internet.. und dann nachher noch funktioniert... schon mal w98 auf XP upgegradet? und mal ne Weihle damit gearbeitet?
Ist ne convenience Sache, aber nicht wirklich brauchbar.
Das würde bei Debian vermutlich gar nicht funktionieren. Oder hat schon mal jemand erfolgreich slink direkt auf sarge aktualisiert?
Gruß
Heiko
Vor allem das einfache Upgrade über den UpdateManager war nett.
habe. Ist aber immerhin besser als Windows wo Programme unkontrolliert 10x die selbe DLL
auf die Festplatte kopieren.
Debian ist fuer mich das stabilste System das ich je hatte und macht mit 2 DVDs die fehlende
Internetleitung wieder wett. So aktuell brauch ich die Programme nun auch wieder nicht.
Ubuntu hat so einige bugs wie zBsp. mit KDE,aber das wird von Version zu Version besser
werden.
RPM sux und fuer Gentoo muss man sich regelrecht freinehmen so oft wie es sich aendert
und so lahm wie das compilet.
Full Ack, das kann ich nur bestätigen, ich hatte sie schon alle und Debian ist die einzige Distribution,
die seit 3 Jahren auf meinem Desktop mehr als nur zufriedenstellend läuft.
RedHat von 5.2 - 9.0 und es wurde schlimmer, Fedora überlebte neben SuSe genau zwei Stunden inklusive Installation.
Gentoo habe ich nach drei Stunden Compilerorgie abgebrochen (ich scheiß auf 1/1000 Sekunde beim Start).
Slackware durfte mein altes Thinkpad 600e beglücken, dies ist die einzige Distribution der ich noch neben dem
Debian-Gott huldige.
Und wenn ich die Linux-Schlampe "Maria" betrüge, dann nur mit FreeBSD und NetBSD.
Alles andere für den Rest ;-)
Daher vollsten RESPEKT für die Debian-Fraktion und DANKE für eure Mühe und euer Blut .... Gott wird es euch danken,
nicht mit Jungfrauen, sondern mit erfahrenen Biestern ;-)
mfg eure Lebensprostituierte.