Na über "beste" kann man sich immer streiten, aber ich persönlich bin mit Ubuntu sehr zufrieden. Die machen nen guten Job. Die und die Community mit ihren diversen Hilfen und Paketen ^^.
Wenigstens ist der Installer etwas verbessert worden. So crashed er nicht mehr, wenn man auf Reiser-Partitionen installieren will und Installationen auf logischen SCSI-Laufwerken sind nun auch möglich. Leider ist das Ding aber faktisch immer noch Beta!!! Hast du z.B. nicht gemerkt, dass deine Systemzeit bei der Live-CD stimmt, bei der installierten Version aber um zwei Stunden nicht? Wenn du bei der Installation evt. diesen Fehler ausbügeln willst und anstatt "Berlin" bei der Zeitzone das "leere" Feld wählst, crashed der Installaler wieder einmal ... probier es aus! Du kannst natürlich auch die Zeit im PC falsch einstellen, damit sie bei deinem "Besten" System stimmt ...
Also ich kenne bessere Distris ... ... da läuft z.B. der Installer der aktuellen Betaversion (!) von Kanotix wesentlich stabiler und ist auch in anderer Hinsicht weniger peinlich programmiert!
Die Einstellung, welche Zeit in dem BIOS gespeichert wird, unterscheidet sich zwischen Windows und Linux, bzw. die Interpretation.
Während Windows - wie ich finde unsinnigerweise - die lokale Zeit im BIOS schreibt und so z.B. bei Sommerzeit-Änderungen die Zeit dort verändern muss, ohne zu wissen, ob das schon ein anderes System gemacht hat! Daher schreiben Linux und alle anderen Systeme dort einfach UTC rein und rechnen die lokale Zeitzone drauf. Das ist viel praktischer bei z.B. Notebooks, die sich um die Welt bewegen...
Wenn Du Linux und Windows im Dual-Boot betreibst, kämpfen sie um die Uhrzeit, daher Deine 2 Stunden Unterschied. Eine Lösung gibt es dafür auch, irgendwo (Google) kannste konfigurieren, dass doch nicht UTC im BIOS gespeichert wird.
Danke für den Tipp, aber mir ist sehr wohl bewusst, dass es diese zweierlei Systeme gibt. Darum geht es nicht! Es geht darum, dass das "beste Linux", das ja anscheinend ohne jede Frimelei (!) läuft und für Umsteiger gedacht ist, eben in so einfachen Dingen nicht kompatibel zu Windows (sowie anderen Nicht-Unix-Betriebssystemen!) und nicht einmal kompatibel zur eigenen Live-CD ist. Andere Distries sind es und bei den professionelleren Distries kann ich das Zeitsystem sogar auswählen. Das ist das Problem!
Bei einer Reise kann ich Zeitzonen genauso ändern, wenn ich im (Nicht-Ubuntu-)Linux das zu Windows kompatible System verwende. Damit habe ich auch noch nie Ärger gehabt, dass z.B. die Zeit von versandten E-Mails nicht gestimmt hat. Übrigens - ist hier eigentlich nicht der Ort dafür - aber Windows kann man die automatische Sommerzeitumstellung u.a. schon bei der Installation abgewöhnen, es bietet diese Option ausdrücklich an ...
Hallo Ich habe da mal eine Frage:Ich finde keinen Treiber für meinen Brother MFC 3240C Drucker. Und wenn es einen geben sollte ? Wie installiere Ich unter Suse 10.0 einen Drucker ? Würde mich über eine Rückmail sehr freuen. Gruß Thomas aus München
> lediglich Sicherheitslücken und wichtige Fehler ich bin ehrlich gesagt ein wenig enttäuscht, von etlichen mitgelieferten Programmen gibt es inzwischen aktuallisierte Minorupdates, die viele Bekannte Fehler beseitigen, wiso werden diese nicht in die Distribution eingepflegt? Der Stabilität schadet das mit Sicherheit nicht, eher im Gegenteil. Wozu bringen die ganzen goßen Projekte (KDE, OOo, Gnome, etc.) überhaupt noch Minorupdates raus, wenn die Distributoren diese dann nicht einpflegen wollen? So ist dank der geregelten Updatezyklen immer Sichergestellt, dass Ubuntu nur mit frühen Releases daherkommt (z.B. Gnome 2.14.1 gegen aktuell 2.14.3), und der Anwender nie von Fehlerupdates profitieren kann. Das sollte nicht so sein, ich hatte mir erhofft, dass diese Version durch das LTS Programm mit der Zeit rocksolide wird, und das nicht nur in Bezug auf Sicherheit!
In irgendeinem Fachblatt für Computer-Analphabetismus erschien unlängst der Artikel "Ubuntu patched am schnellsten", gut dass ich nicht den Medien nicht alles glaube. Selbst Frickeldistros wie Zenwalk liefern schon lange gnome-2.14.3 ......
Von Chuck Norris am Do, 10. August 2006 um 14:15 #
Fachblatt für Computer-Analphabetismus Klingt nach einem Blatt, in dem du Herausgeber und einzigster Leser bist. Ein Troll mit wenigstens einem Fünkchen Ehre, hätte vorher nachgelesen welche Version in Ubuntu Dapper Drake schon länger enthalten ist. Na dreimal darfst du raten. Aber vielleicht beschränkt sich der Analphabetismus bei dir nicht nur auf Computer.
es gibt nur die 2.14.1 oder update auf 2.15.2 (letzeres ist allerdings beta-code). Wie Canonical mit soviel Geld soviel Frickelware ausliefert ist mir ein Rätsel. Immerhin bietet gnome (im Gegensatz zu KDE) ja immer stabile API und ausschliesslich Bugfixes.
sieh mal hier in die sourcen bevor du weiter solchen unsinn verbreitest, da gibt es 2.14.1 und dann 2.15.2 http://archive.ubuntu.com/ubuntu/pool/main/libg/libgnome/
Von Chuck Norris am Do, 10. August 2006 um 15:01 #
Dann schau mal hier zum Vergleich was auf dem GNOME ftp abliegt. http://ftp.gnome.org/pub/GNOME/platform/2.14/2.14.3/sources/ Na fällt da unserem IT-Profi etwas auf? Nein? Nun da du eine Leseschwäche hast (spätestens mit deiner letzten Antwort ist es amtlich), sag ich es dir. Nicht alle Pakete im 2.14.3 Release tragen auch diese Versionsnummer. Treffer - "IT-Profi" versenkt.
ja dann sieh aber auch mal die andere Pakete an z.b. libidl etc die sind nämlich echt von gestern libIDL wäre 0.8.7 ubuntu hat 0.8.6, libglade, ORbit etc alles was upgedated wurde ist in Ubuntu noch gleich alt.
Sie sprechen von KDE und sprechen stabile API's an. Auch Gnome. War bei Ubuntu dabei. Und unser Linux wurde oft, in diesem Fall Ubuntu, in diesem Fall von ein "reines" oberflächliches "overlay" für einen einen Betrag von sehr vielen Millionen - der Betrag war ausserordentlich hoch - weiterverkauft. Wie geht sowas? Kann man das etwas beleuchten? Besten Dank im voraus.
aha Chuck Norris versucht mit neuem Nick einen zweiten Anlauf, Tja Thema verfehlt denn Bugfixes sind auch wichtig, aber ich weiss, die Ubuntupaketierer nehmen sich die sourcen erstellen ein .patch-file und streichen die Bugfixes raus, damit nur noch die Sicherheitslücken gepatched werden. Macht ja auch Sinn, denn wer braucht schon Bugfixes
Das witzige bei Bugfixes ist, das sie nicht selten Bugs mitbringen. Böse Zungen behaupten deshalb, das es in Produktivumgebungen besser ist wenn nur die sicherheitskritischen Bugs gefixt werden.
> aha dem server ist es also egal wenn ihm der Speicher leckt, > sososo... Kann ja gar nie passiern, dass der voll läuft.
Nicht jeder Bugfix ist ein Memory Leak. Solche Bugfixes werden von den Distributionen ja auch gerne zurückportiert. Deshalb übernehmen sie aber lange noch nicht alle Änderungen, die ein Bugfix-Release mit sich bringt. Der OP hat Bezug genommen auf "Ubuntu patcht am schnellsten", wo es um Sicherheitslücken ging, und beschwert sich dann dass Gnome zwei Minor-Versionsnummern hinter dem aktuellen Stand hinterher ist. Das ist einfach zwei verschiedene Dinge.
Wenn ich einen Server im Produktivbetrieb habe, dann läuft er für meine Aufgabe angemessen und ich habe für eventuelle Probleme einen Workaround gemacht. Z.B bei einem Speicherleck einen restart per Cronjob in der Nacht von Sonntag auf Montag um 4:00, der ca 3sec dauert.
Wie gesagt, wenn ich das System produktiv einsetze, dann ist es für meinen Einsatzzweck geeignet und ich möchte nicht, das von der Distribution irgendwas anderes gepatcht wird als sicherheitskritische Fehler.
Sollte in einem Paket der Distribution ein Fehler existieren der ausschließt das ich dieses Paket für meinen bestimmten Zweck einsetze, dann baue ich mir SELBER ein Packet welches in einem Zustand ist der meinen Einsatzzweck besser entspricht und trage mich in der Mailingliste zu dem Programm ein, so das ich Sicherheitslücken zeitnah mitbekomme. Bei Debian-Derivaten geht das erstellen eigener Paketz super einfach mit den mitgelieferten Debiantools. Dafür nehme ich z.B fertige Versionen aus Unstable und portiere sie auf Stable zurück oder nehme selber das neue Upstreamrelease und integriere es supereinfach mit dem Tool uupdate. Bei Minor-Updates muß man dabei in 95% der Fälle keine Hand anlegen.
Jedenfalls ist es für einen Admin nicht zu vertreten wenn unnötige Patches in ein Produktivsystem laufen, das seinen Dienst für den gewünschten Einsatzzweck ohne Probleme erfüllt, nur damit irgendwo auf der Welt jemand befriedigt ist, weil die eingesetzten Pakete dann eine aktuelle Version haben und im Changelog ja steht das XXX Fehler behoben wurden.
1. Viele Distribuitionen portieren Bugfixes zurueck, d.h. dein KDE zeigt dann weiterin eine "alter" Versionsnummer an, allerdings hat der Distributor Bugfixes einer neueren offiziellen Version auf seine aeltere Version rueckportiert. Damit profitierst du also auch von den tollen neuen Fehlerupdates.
2. Deine Logik kann ich nicht nachvollziehen. Wenn der Distributor immer auf die neueste Version eines Projektes updated, dann wird das Ganze niemals "rock solid", denn mit jedem Update schleichen sich wieder neue Fehler ein, nicht nur bei dem Projekt selbst, sondern auch bei der distributionsspezifischen Anpassung und dem Paketbau. Diese Gefahr ist beim einfachen Rueckportieren von Fixes geringer.
Sorry das ist Unsinn, jede Distro sollte die gnomelibs immer bis auf den letzten Minor updaten, Bei gnome wäre das also 2.X.3 im konkreten Fall 2.14.3. In Gnome werden dort NUR Bugfixes eingepflegt (bei KDE ist das anders). "Rock Solid" sind also immer die "2.X.3" Versionen. Dabei können sich auch keine Fehler einschleichen, denn API, ABI und Strings sind in Minor-releases bekanntermassen eingefroren.
> In Gnome werden dort NUR Bugfixes > eingepflegt (bei KDE ist das anders).[...] > Dabei können sich auch keine Fehler > einschleichen, denn API, ABI und Strings > sind in Minor-releases bekanntermassen > eingefroren.
??? API, ABI und String-Freezes verhindern Fehler? Wohl kaum. Die haben wenig mit Fehlern zu tun, eher mit Binärkompatibilität und Koordinierung von Übersetzern.
Ein vermeintlicher Bugfix kann _immer_ für Regressions sorgen, je schlechter der Code desto wahrscheinlicher.
Übrigens sind minor-releases bei KDE in der Regel auch bugfix-releases, nur bei klar definierten (und als solche gekennzeichneten) Ausnahmen nicht. 3.4.1-3.5.2 waren z.b. reine bugfix-releases.
>API, ABI und String-Freezes verhindern Fehler? Nein Bugfixes verhindern Fehler, die Kompatibilität (wie oben beschrieben) garantiert, dir dass wen Paket A upgedated wird Paket B weiterhin läuft.
>Ein vermeintlicher Bugfix kann _immer_ für Regressions sorgen, je schlechter der Code >desto wahrscheinlicher. Sorry aber die gnome-bugfixes sind nicht "vermeintlich" sondern immer sehr gut getestet. Nenn mir doch nur ein Beispiel für ein nicht ausgereiftes Bugfixes in einer stabilen Gnomeserie der letzen zwei Jahre, dann reden wir weiter. Im Gegenteil viele Bugfixes sind durchaus wichtig für Stabilität und beheben z.b Memleaks oder Abstürze.
es werden kritische bugs gefixt, die zu abstützen und damit datenverlust führen können. http://release.debian.org/stable/3.1/3.1r2/ . und sorry aber ich mag leute nicht die jeden satz mit "sorry" beginnen lassen. hat was von arroganz und inkompetenz.
Wenn du das nicht gesagt hast, dann hast du dich zumindest sehr unklar ausgedrückt.
> (hört sich das jetzt kompetenter an wie "sorry" ?)
"als sorry", wenn wir uns denn hier auf diese Ebene hinunter bewegen wollen.
Dein Satz: "Dabei können sich auch keine Fehler einschleichen, denn API, ABI und Strings sind in Minor-releases bekanntermassen eingefroren."
Hast du nie gesagt? Mit den API/ABI/Strings wolltest du wohl auf Feature Freeze hinaus. Anders kann ich da keinen Zusammenhang zu Regressions zusammenreimen. Und ein Feature Freeze schützt vor nicht Regressions. Weder bei Gnome, bei KDE noch sonstwo.
Was Regressions sind hast du sowieso nicht verstanden, du reimst dir da was ganz falsch zusammen. Nein ich wollte damit nicht auf ein "Feature Freeze" hinaus sondern genau auf das was ich gesagt habe und das schützt dann nämlich auch vor Regressions. Lies dir doch einfach mal die Changelogs zu den Paketen durch die auf deinem Ubuntusystem nie landen werden.
kleiner, natürlich weiß ich was Regressions sind. Und API, ABI, und String freeze helfen da wenig. Wenn ich einen Bug in einer Methode fixe, kann ich dadurch in bisher funktionieren Teilen des Programms neue Bugs produzieren und damit Regressions verursachen, ohne die API oder irgendwelche Strings anfassen zu müssen. Strings haben mit Bugs seltenst irgendwas zu tun.
>Wenn ich einen Bug in einer Methode fixe, kann ich dadurch in bisher funktionieren Teilen des >Programms neue Bugs produzieren Das du kannst will ich dir ja nicht absprechen aber Gnome wird von PROFIS entwickelt (zum Glück) und nicht von dir.
Wer glaubt, dass er Regressionen in der Implementierung verhindern kann, wenn er die (statische) Schnittstelle (!) beibehält, hat entweder keine Ahnung oder leidet an Realitätsverlust und Selbstüberschätzung. Ein Profi ist er jedenfalls nicht. Du solltest lieber selbst Software entwickeln und deinen Gnome-Fanboyismus ablegen. Und aufhören, hier beleidigend rumzupöbeln anstatt sachlich zu diskutieren.
Ein Bugfix kann durchaus Fehler sichtbar machen, die es bisher schon gab und die verdeckt waren, sowas ist ganz natürlich.
Schliess z.B. ein Memleak und schon geht ein anderer Bug (Überschreiben von Speicher) nicht mehr harmlos ab.
Berechne ein Ergebnis mit der spezifizierten Präzision und schon schlägt ein anderer Bug (Test auf 0, was jetzt aber korrekterweise 0.0000000000001 ist, man hätte auf "sehr klein" testen müssen) fehl.
Kurzum: Bugfixes sind Entwicklung. Gerade in Libraries, die von vielen, Dir nicht bekannten Programmen genutzt werden, sind sie ein Problem, das auch zu handhaben ist, denn Du kennst die Qualität der Programme nicht.
Es hilft Dir ja Nichts, wenn in der Produktivumgebung das wichtigste Program einen Fehler aufgedeckt bekommt, aber sonst alle vielleicht stabiler sein würden.
Es gibt da einen Satz aus dem Sport, der passt auch beim Coden: "Never change a wining code." (Ändere niemals den erfolgreichen Code.)
Software ist oft eher evolutionär gearbeitet, Code ist nur so gut, wie er sein muss, und funktioniert nur in der aktuellen Umgebung.
Ob bei Gnome-Updates die Zeit zwischen solchen Fehlern hoch oder niedrig ist, kann ich Dir nicht sagen. Ich glaube auch nicht, das wir im Desktop-Bereich von relevanten Risiken sprechen. Wenn ein Arbeitsplatz durch ein Update beeinträchtigt würde, könnte er ja einfach von Backup (oder via Downgrade) wieder zum Laufen gebracht werden.
Stimmt, bestimmte Sachen funktionieren nicht mehr richtig, weil da keine aktuellen Versionen drin sind. Und wenn man sich dann manuell von der Homepage deb-Pakete installiert, dann kann man sich leicht das ganze System schreddern. Ich finde das apt/dep-System ziemlich peng. Im Vergleich zu Portage fehlt da einiges. Aber rpm soll ja noch schlimmer sein.
Von Da isser der Schmutzfink am Do, 10. August 2006 um 14:31 #
Der Vorteil von portage/gentoo ist ja, dass man sich selbst mit den Standardpaketen das System schrotten kann. (Sowieso alles ungetesteter Paket-Nippes) Und wenn nicht, dann kann man sich den *peng peng* Kopfschuss per ricer cflags setzen. ^^
Weißt Du, womit dieses Problem am allerwenigsten zu tun hat?
Mit der Frage, ob eine Distribution dpkg oder rpm als Low-Level-Paketmanager nutzt. Damit hat es nämlich _gar nichts_ zu tun.
Es ist nun mal so, dass die Distributoren nicht nur dem Wunsch der Nutzer nach der allerneuesten Software, sondern auch bestimmten Grundsätzen der Produktstabilität folgen müssen. Das hat nichts mit dem Paketmanager, sondern mit der grundsätzlichen Herangehensweise zu tun.
Es ist einfach so, dass neue Paketversionen neue Bugs einführen können und werden, weil Software nicht immer linear nach vorne entwickelt wird. Es gibt immer Regressions. Die Distributoren tragen dem Rechnung, indem sie die Paketversionen irgendwann einfrieren.
Manche Benutzer wollen das nicht akzeptieren und spielen sich dann irgendwelche semiprofessionellen Pakete von Drittquellen ein => Peng. Das liegt nicht am Paketmanager, und dieses ständige Zurückführen derartiger Probleme auf den Paketmanager wird durch Wiederholungen nicht richtiger.
Nö das Problem sind die DAU-Paketierer von Ubuntu die ständig mit den Compile-flags rumspielen. Wer natürlich so wenig Ahnung dem sollte man eine Kindersicherung vor den Compiler bauen. Ob Drittquellen seriös sind oder nicht hat damit auch nichts zu tun sondern lediglich kompatibel. Würden sich die Drittpaketierer mal auf eine gemeinsame ABI verständigen wäre das alles kein Problem. Leider wissen viele dieser Leute nichtmal was der Unterschied zwischen ABI und API ist, na ja ich sags ja Über-DAUs. Fedora schafft es für ihre Cores relativ stabil zu bleiben, was für Core 3 gebaut wurde läuft auch dort. Wenn die Ubuntu-Frickler natürlich immer die neuesten Compiler einsetzen dann wundert mich gar nix.
Von Kai F. Lahmann am Do, 10. August 2006 um 15:05 #
mehr noch, dieses ständig in irgendwelchen Linux-Kindergärten geforderte liefern der neuesten Programmversionen ist in so ziemlich jeder Hinsicht der größte vorstellbare Schwachsinn. Wenn der Kram auch nur ANSATZWEISE professionell taugen soll, darf sich nämlich im Funktionsumfang während der Lebensdauer der Distri nichts ändern. Leider sind aber viele OpenSource-Projekte unfähig, wirklich reine Bugfix-Releases bestehender Versionen herauszubringen, sondern meinen, in jedes Update auch immer ein paar neue Funktionen einzubauen - damit sind diese Updates dann eben für eine jede Distribution unbrauchbar. Die Arbeit, hier Bugfixes und neue Funktionen auseinanderzusortieren, machen sich entsprechend die wenigsten Distris und dann auch nur, wenn es um gravierende Bugs geht. So, und dann gibt es noch einen ganz besonderen Fall: den Kernel! Bei diesem kommt zu dem obigen Problem durch die hardwarenahe Programmierung noch ein Problem hinzu: manche Codepassagen sind endlose Ketten von Ausnahmen, weil sich irgendein Gerät unter irgendwelchen bestimmten Umständen in irgendeiner Hinsicht danebenbenimmt. Da diese Ausnahmen nur durch Try&Error zu ermitteln sind, läßt sich eben auch nie ausschließen, dass irgendein Kernel-Update zwar für einen Fall die Situation verbessert, sie aber für einen anderen Fall womöglich dramatisch verschlechtert. Aus genau diesem Grund hat der Kernel der meisten Distributionen mit dem Standard-Kernel nicht mehr viel zu tun. Ubuntu hatte da beispielsweise schon bis zum Release von 6.06 rund 1000 Patches drin!
Und genau das Problem habe ich mit dem aktuellen Kernel 2.6.15-26 auf meinem Notebook. Die Sounausgabe ruckelt da nur noch (via82xx). Mit dem 25er Kernel kein Problem.
Von Kai F. Lahmann am Do, 10. August 2006 um 19:10 #
Sound und ACPI scheinen da 2 besonders häufige Kandidaten zu sein, ja. Bug bei Ubuntu gemeldet (mit genauer Gerätebezeichnung)? Von alleine verschwinden die nicht.
Manche Benutzer wollen das nicht akzeptieren und spielen sich dann irgendwelche semiprofessionellen Pakete von Drittquellen ein => Peng. Das liegt nicht am Paketmanager...
Nein, natürlich nicht!
Es liegt daran, daß die Kontroll-Freaks aus der UNIX-Fraktion keine funktionierende Alternative zulassen wollen. Rafft es endlich: Ein Desktop sollte Spaß machen!
Wann haben wohl die meisten Leute etwas über die Twin-Tower in New York gelernt? Richtig: Als es dort die meiste Action gab. So funktioniert unser Gedächnis nunmal: Es braucht eine gewisse emotionale Beteiligung, damit es läuft.
Eine gewisser Grad von Aufmerksamkeit wird beispielsweise beim Erscheinen einer neuen Version erzeugt: Da ist was Neues! Man kann 'was ausprobieren! Das macht Spaß! Man kann sich mit Freunden darüber unterhalten!
Man denke nur mal an den Spaß als die Moorhuhnjagd ihre Runden durch deutsche Büros gemacht hat: Wäre das unter APT und Konsorten möglich gewesen? Nein!
Warum? Weil die Distributionen mit ihrem Kontroll-Modell nicht schnell genug gewesen wären. Keine Wunder, daß die Leute auf semi-professionelle Pakete zurückgreifen. Oder ihre Zeit verschwenden mit dem Kompilieren von Source-Code!
Und das alles nur wegen den Kontroll-Freaks: "Alles aus einem Repository, sonst wird das nichts!" Das ja wie bei Adolf.
Darum klappt's auch nicht mit Linux auf'm Desktop.
> Und das alles nur wegen den Kontroll-Freaks: "Alles aus > einem Repository, sonst wird das nichts!"
Du scheinst da etwas in den falschen Hals bekommen zu haben. Das ist keine Kontrolle, sondern Projektmanagement. Der Projektmanager entscheidet nun mal selbst, wofür er Support leistet und wofür nicht, weil er auch dafür verantwortlich ist. Verantwortung == Entscheidungsbefugnis.
Wer mit den Entscheidungen des Projektmanagements nicht einverstanden ist, hat immer die Möglichkeit, ihnen entweder einfach nicht zu folgen oder ein eigenes Projekt zu eröffnen. Dann soll er sich aber auch nicht darüber wundern, wenn die Benutzer sich bei ihm und nicht beim ursprünglichen Projektmanager über Regressions beschweren und mit Sprüchen ankommen, à la "das hat eine höhere Versionsnummer, also erwarte ich, dass es keinen einzigen Fehler hat, den es vorher nicht gab".
Oder jemand ist in seinen Verkaufsaussagen zu leichtfertig gewesen: "Jo, das Linux ist völlig desktop-fähig, auch im privaten Bereich! Wir sind da völlig sicher."
Glückwunsch: Du scheinst Godwins Gesetz erkannt zu haben. Nazivergleiche haben nun mal die Eigenschaft, vorhersagbar zu sein - Metavorhersehbarkeit nicht ausgeschlossen.
Gewisse Updates sind nötig. Das machen die Entwickler ja nicht aus Langeweile. Eine neuere Version ist nicht in erster Linie instabil, sondern beseitigt bestehende Probleme. Diese müssen ja gar nicht am Programm liegen, sondern einfach daran, daß da mal wieder von irgendwem ein Protokoll geändert wurde. Es geht da nicht um komplett neue Versionen, sondern um dem Schritt von 3.5.1 auf 3.5.2. Das sind ja gerade die Versionen, die Bugs beseitigen. Ich weiß ja nicht, ob alle Linuxentwickler unfähig sind, aber was man so liest, denken viele bei so einer Rebision nicht an eine Fehlerbeseitigung, sondern an neue Bugs. Und diese bereinigten Versionen werden bei Ubuntu stellenweise zu selten eingepflegt. Ich habe mir da bestimmte Versionen nicht aus Langeweile oder Versionitis installiert, sondern weil da ansonsten bestimmte Sachen nicht mehr gingen.
Und dabei fand ich das apt/deb-System einfach unbrauchbar. Ja ich weiß, darf man nicht laut sagen, davon schwärmen 90% der Linuxnutzer. Ein System, welches mir vorschreibt, daß ich nur die Versionen aus den offiziellen Repositories nutzen darf, kann so nicht sein. Und dann zu sagen, jeder Benutzer, der mit den offiziellen Vorgaben nicht zufrieden ist, hat eine Klatsche, kann auch nicht sein.
Wieso? Eine Distribution wird vor dem Release getestet und das Release erst dann gemacht, wenn sie für gut befunden wurde.
Updates können u.a. dazu führen, dass Software, die auf einem System mit installierten Updates kompiliert wurde, auf einem System ohne Updates nicht mehr läuft. So wäre es z.B. bei glibc- oder gcc-Updates. Bei anderen Paketen kann es andere Effekte geben, die nicht immer vorhersehbar sind. Es kommt halt immer darauf an, um was für Updates es geht.
> Ich weiß ja nicht, ob alle Linuxentwickler unfähig > sind, aber was man so liest, denken viele bei so > einer Rebision nicht an eine Fehlerbeseitigung, > sondern an neue Bugs.
Das liegt nicht daran, dass die Entwickler unfähig wären, sondern daran, dass in angeblich reinen Bugfix-Releases eben doch immer wieder Patches landen, die nicht nur Bugfixes sind. Manchmal werden neue Bugs auch erst bemerkt, nachdem das Paket in "ungewöhnlichen" Umgebungen getestet wurde. In so einem Fall dann nachlegen zu müssen, macht manchmal einen etwas unprofessionellen Eindruck.
> Ein System, welches mir vorschreibt, daß ich nur > die Versionen aus den offiziellen Repositories > nutzen darf, kann so nicht sein.
Das System schreibt überhaupt nichts vor, sondern verweigert im Zweifelsfalle einfach den Support, der eine freiwillige Dienstleistung ist, für die die Mehrheit der Benutzer niemals eine Gegenleistung in Form von Geld oder Codebeiträgen liefern. Und auch das nicht, um die Benutzer zu ärgern, sondern weil es anders einfach schwierig ist.
Zitat: Der Download der aktualisierten CD-Images ist von zahlreichen Mirror-Servern möglich. Es wurde offenbar kein separates Verzeichnis für die neue Version angelegt, so dass man vor dem Download prüfen sollte, ob der Mirror bereits über die aktuelle Version verfügt.
nein, nur sicherheitslücken werden geschlossen. im halbjährigen distributions update kommen dann solche upgrades rein. aber LTS wirds nur in größeren intervallen geben.
wenn ich sehe, dass man unter Kubuntu mittels KDE immer noch keine Disketten mounten und unmounten kann (Bug) bleibe ich lieber bei SuSE 10.1. Da werden gemeldete Bugs wenigstens gefixt.
Also ich hab mir hier mal hier die hochqualifizierten Beiträge durchgelesen !
Bitte - bevor Ihr euch gegenseitig mit unsinnigen Diskussionen heruntermacht fragt doch dann wenigstens mal einen wirklichen Entwickler bzw. Linux-Guru - erspart viel Zeit und Ärger
Wenigstens ist der Installer etwas verbessert worden. So crashed er nicht mehr, wenn man auf Reiser-Partitionen installieren will und Installationen auf logischen SCSI-Laufwerken sind nun auch möglich.
Leider ist das Ding aber faktisch immer noch Beta!!! Hast du z.B. nicht gemerkt, dass deine Systemzeit bei der Live-CD stimmt, bei der installierten Version aber um zwei Stunden nicht? Wenn du bei der Installation evt. diesen Fehler ausbügeln willst und anstatt "Berlin" bei der Zeitzone das "leere" Feld wählst, crashed der Installaler wieder einmal ... probier es aus!
Du kannst natürlich auch die Zeit im PC falsch einstellen, damit sie bei deinem "Besten" System stimmt ...
Also ich kenne bessere Distris ...
... da läuft z.B. der Installer der aktuellen Betaversion (!) von Kanotix wesentlich stabiler und ist auch in anderer Hinsicht weniger peinlich programmiert!
Während Windows - wie ich finde unsinnigerweise - die lokale Zeit im BIOS schreibt und so z.B. bei Sommerzeit-Änderungen die Zeit dort verändern muss, ohne zu wissen, ob das schon ein anderes System gemacht hat! Daher schreiben Linux und alle anderen Systeme dort einfach UTC rein und rechnen die lokale Zeitzone drauf. Das ist viel praktischer bei z.B. Notebooks, die sich um die Welt bewegen...
Wenn Du Linux und Windows im Dual-Boot betreibst, kämpfen sie um die Uhrzeit, daher Deine 2 Stunden Unterschied. Eine Lösung gibt es dafür auch, irgendwo (Google) kannste konfigurieren, dass doch nicht UTC im BIOS gespeichert wird.
Gruß, Kay
Es geht darum, dass das "beste Linux", das ja anscheinend ohne jede Frimelei (!) läuft und für Umsteiger gedacht ist, eben in so einfachen Dingen nicht kompatibel zu Windows (sowie anderen Nicht-Unix-Betriebssystemen!) und nicht einmal kompatibel zur eigenen Live-CD ist. Andere Distries sind es und bei den professionelleren Distries kann ich das Zeitsystem sogar auswählen.
Das ist das Problem!
Bei einer Reise kann ich Zeitzonen genauso ändern, wenn ich im (Nicht-Ubuntu-)Linux das zu Windows kompatible System verwende. Damit habe ich auch noch nie Ärger gehabt, dass z.B. die Zeit von versandten E-Mails nicht gestimmt hat.
Übrigens - ist hier eigentlich nicht der Ort dafür - aber Windows kann man die automatische Sommerzeitumstellung u.a. schon bei der Installation abgewöhnen, es bietet diese Option ausdrücklich an ...
Gruß Alefanz
Ich habe da mal eine Frage:Ich finde keinen Treiber für meinen Brother MFC 3240C Drucker. Und wenn es einen geben sollte ? Wie installiere Ich unter Suse 10.0 einen Drucker ?
Würde mich über eine Rückmail sehr freuen.
Gruß
Thomas aus München
ich bin ehrlich gesagt ein wenig enttäuscht, von etlichen mitgelieferten Programmen gibt es inzwischen aktuallisierte Minorupdates, die viele Bekannte Fehler beseitigen, wiso werden diese nicht in die Distribution eingepflegt? Der Stabilität schadet das mit Sicherheit nicht, eher im Gegenteil. Wozu bringen die ganzen goßen Projekte (KDE, OOo, Gnome, etc.) überhaupt noch Minorupdates raus, wenn die Distributoren diese dann nicht einpflegen wollen? So ist dank der geregelten Updatezyklen immer Sichergestellt, dass Ubuntu nur mit frühen Releases daherkommt (z.B. Gnome 2.14.1 gegen aktuell 2.14.3), und der Anwender nie von Fehlerupdates profitieren kann. Das sollte nicht so sein, ich hatte mir erhofft, dass diese Version durch das LTS Programm mit der Zeit rocksolide wird, und das nicht nur in Bezug auf Sicherheit!
Klingt nach einem Blatt, in dem du Herausgeber und einzigster Leser bist. Ein Troll mit wenigstens einem Fünkchen Ehre, hätte vorher nachgelesen welche Version in Ubuntu Dapper Drake schon länger enthalten ist. Na dreimal darfst du raten. Aber vielleicht beschränkt sich der Analphabetismus bei dir nicht nur auf Computer.
http://archive.ubuntu.com/ubuntu/pool/main/libg/libgnome/
Na fällt da unserem IT-Profi etwas auf? Nein? Nun da du eine Leseschwäche hast (spätestens mit deiner letzten Antwort ist es amtlich), sag ich es dir. Nicht alle Pakete im 2.14.3 Release tragen auch diese Versionsnummer.
Treffer - "IT-Profi" versenkt.
libIDL wäre 0.8.7 ubuntu hat 0.8.6, libglade, ORbit etc alles was upgedated wurde ist in Ubuntu noch gleich alt.
Most of GNOME 2.14.3 has been incorporated
siehe: https://wiki.ubuntu.com/DapperPointOneAnnouncement
War bei Ubuntu dabei. Und unser Linux wurde oft, in diesem Fall Ubuntu, in diesem Fall von ein "reines" oberflächliches "overlay" für einen
einen Betrag von sehr vielen Millionen - der Betrag war ausserordentlich hoch
- weiterverkauft. Wie geht sowas? Kann man das etwas
beleuchten? Besten Dank im voraus.
> schon lange gnome-2.14.3
Der Unterschied zwischen security advisories und bugfix-releases ist dir aber schon bekannt, oder?
Tja Thema verfehlt denn Bugfixes sind auch wichtig, aber ich weiss, die Ubuntupaketierer nehmen sich die sourcen erstellen ein .patch-file und streichen die Bugfixes raus, damit nur noch die Sicherheitslücken gepatched werden. Macht ja auch Sinn, denn wer braucht schon Bugfixes
> sososo... Kann ja gar nie passiern, dass der voll läuft.
Nicht jeder Bugfix ist ein Memory Leak. Solche Bugfixes werden von den Distributionen ja auch gerne zurückportiert. Deshalb übernehmen sie aber lange noch nicht alle Änderungen, die ein Bugfix-Release mit sich bringt.
Der OP hat Bezug genommen auf "Ubuntu patcht am schnellsten", wo es um Sicherheitslücken ging, und beschwert sich dann dass Gnome zwei Minor-Versionsnummern hinter dem aktuellen Stand hinterher ist.
Das ist einfach zwei verschiedene Dinge.
Wie gesagt, wenn ich das System produktiv einsetze, dann ist es für meinen Einsatzzweck geeignet und ich möchte nicht, das von der Distribution irgendwas anderes gepatcht wird als sicherheitskritische Fehler.
Sollte in einem Paket der Distribution ein Fehler existieren der ausschließt das ich dieses Paket für meinen bestimmten Zweck einsetze, dann baue ich mir SELBER ein Packet welches in einem Zustand ist der meinen Einsatzzweck besser entspricht und trage mich in der Mailingliste zu dem Programm ein, so das ich Sicherheitslücken zeitnah mitbekomme. Bei Debian-Derivaten geht das erstellen eigener Paketz super einfach mit den mitgelieferten Debiantools. Dafür nehme ich z.B fertige Versionen aus Unstable und portiere sie auf Stable zurück oder nehme selber das neue Upstreamrelease und integriere es supereinfach mit dem Tool uupdate. Bei Minor-Updates muß man dabei in 95% der Fälle keine Hand anlegen.
Jedenfalls ist es für einen Admin nicht zu vertreten wenn unnötige Patches in ein Produktivsystem laufen, das seinen Dienst für den gewünschten Einsatzzweck ohne Probleme erfüllt, nur damit irgendwo auf der Welt jemand befriedigt ist, weil die eingesetzten Pakete dann eine aktuelle Version haben und im Changelog ja steht das XXX Fehler behoben wurden.
Viele Grüße,
Mind
2. Deine Logik kann ich nicht nachvollziehen. Wenn der Distributor immer auf die neueste Version eines Projektes updated, dann wird das Ganze niemals "rock solid", denn mit jedem Update schleichen sich wieder neue Fehler ein, nicht nur bei dem Projekt selbst, sondern auch bei der distributionsspezifischen Anpassung und dem Paketbau. Diese Gefahr ist beim einfachen Rueckportieren von Fixes geringer.
> eingepflegt (bei KDE ist das anders).[...]
> Dabei können sich auch keine Fehler
> einschleichen, denn API, ABI und Strings
> sind in Minor-releases bekanntermassen
> eingefroren.
???
API, ABI und String-Freezes verhindern Fehler? Wohl kaum. Die haben wenig mit Fehlern zu tun, eher mit Binärkompatibilität und Koordinierung von Übersetzern.
Ein vermeintlicher Bugfix kann _immer_ für Regressions sorgen, je schlechter der Code desto wahrscheinlicher.
Übrigens sind minor-releases bei KDE in der Regel auch bugfix-releases, nur bei klar definierten (und als solche gekennzeichneten) Ausnahmen nicht. 3.4.1-3.5.2 waren z.b. reine bugfix-releases.
Nein Bugfixes verhindern Fehler, die Kompatibilität (wie oben beschrieben) garantiert, dir dass wen Paket A upgedated wird Paket B weiterhin läuft.
>Ein vermeintlicher Bugfix kann _immer_ für Regressions sorgen, je schlechter der Code >desto wahrscheinlicher.
Sorry aber die gnome-bugfixes sind nicht "vermeintlich" sondern immer sehr gut getestet. Nenn mir doch nur ein Beispiel für ein nicht ausgereiftes Bugfixes in einer stabilen Gnomeserie der letzen zwei Jahre, dann reden wir weiter. Im Gegenteil viele Bugfixes sind durchaus wichtig für Stabilität und beheben z.b Memleaks oder Abstürze.
und sorry aber ich mag leute nicht die jeden satz mit "sorry" beginnen lassen. hat was von arroganz und inkompetenz.
> wichtig für Stabilität und beheben z.b
> Memleaks oder Abstürze.
Das will ich gar nicht bestreiten. Mir ging es mehr um deinen logischen Schluss "API- und ABI-Stabilität und String-Freeze verhindern Regressions".
=> lern doch mal Deutsch du Anfänger!
(hört sich das jetzt kompetenter an wie "sorry" ?)
Wenn du das nicht gesagt hast, dann hast du dich zumindest sehr unklar ausgedrückt.
> (hört sich das jetzt kompetenter an wie "sorry" ?)
"als sorry", wenn wir uns denn hier auf diese Ebene hinunter bewegen wollen.
Dein Satz:
"Dabei können sich auch keine Fehler
einschleichen, denn API, ABI und Strings
sind in Minor-releases bekanntermassen
eingefroren."
Hast du nie gesagt?
Mit den API/ABI/Strings wolltest du wohl auf Feature Freeze hinaus.
Anders kann ich da keinen Zusammenhang zu Regressions zusammenreimen. Und ein Feature Freeze schützt vor nicht Regressions. Weder bei Gnome, bei KDE noch sonstwo.
Strings haben mit Bugs seltenst irgendwas zu tun.
... hi hi hi hi hi hi hi hi hi hi hi hi hi hi hi hi hi hi hi hi hi hi ...
Das du kannst will ich dir ja nicht absprechen aber Gnome wird von PROFIS entwickelt (zum Glück) und nicht von dir.
Du solltest lieber selbst Software entwickeln und deinen Gnome-Fanboyismus ablegen. Und aufhören, hier beleidigend rumzupöbeln anstatt sachlich zu diskutieren.
Schliess z.B. ein Memleak und schon geht ein anderer Bug (Überschreiben von Speicher) nicht mehr harmlos ab.
Berechne ein Ergebnis mit der spezifizierten Präzision und schon schlägt ein anderer Bug (Test auf 0, was jetzt aber korrekterweise 0.0000000000001 ist, man hätte auf "sehr klein" testen müssen) fehl.
Kurzum: Bugfixes sind Entwicklung. Gerade in Libraries, die von vielen, Dir nicht bekannten Programmen genutzt werden, sind sie ein Problem, das auch zu handhaben ist, denn Du kennst die Qualität der Programme nicht.
Es hilft Dir ja Nichts, wenn in der Produktivumgebung das wichtigste Program einen Fehler aufgedeckt bekommt, aber sonst alle vielleicht stabiler sein würden.
Es gibt da einen Satz aus dem Sport, der passt auch beim Coden: "Never change a wining code." (Ändere niemals den erfolgreichen Code.)
Software ist oft eher evolutionär gearbeitet, Code ist nur so gut, wie er sein muss, und funktioniert nur in der aktuellen Umgebung.
Ob bei Gnome-Updates die Zeit zwischen solchen Fehlern hoch oder niedrig ist, kann ich Dir nicht sagen. Ich glaube auch nicht, das wir im Desktop-Bereich von relevanten Risiken sprechen. Wenn ein Arbeitsplatz durch ein Update beeinträchtigt würde, könnte er ja einfach von Backup (oder via Downgrade) wieder zum Laufen gebracht werden.
Gruß, Kay
Weißt Du, womit dieses Problem am allerwenigsten zu tun hat?
Mit der Frage, ob eine Distribution dpkg oder rpm als Low-Level-Paketmanager nutzt. Damit hat es nämlich _gar nichts_ zu tun.
Es ist nun mal so, dass die Distributoren nicht nur dem Wunsch der Nutzer nach der allerneuesten Software, sondern auch bestimmten Grundsätzen der Produktstabilität folgen müssen. Das hat nichts mit dem Paketmanager, sondern mit der grundsätzlichen Herangehensweise zu tun.
Es ist einfach so, dass neue Paketversionen neue Bugs einführen können und werden, weil Software nicht immer linear nach vorne entwickelt wird. Es gibt immer Regressions. Die Distributoren tragen dem Rechnung, indem sie die Paketversionen irgendwann einfrieren.
Manche Benutzer wollen das nicht akzeptieren und spielen sich dann irgendwelche semiprofessionellen Pakete von Drittquellen ein => Peng. Das liegt nicht am Paketmanager, und dieses ständige Zurückführen derartiger Probleme auf den Paketmanager wird durch Wiederholungen nicht richtiger.
Ob Drittquellen seriös sind oder nicht hat damit auch nichts zu tun sondern lediglich kompatibel. Würden sich die Drittpaketierer mal auf eine gemeinsame ABI verständigen wäre das alles kein Problem. Leider wissen viele dieser Leute nichtmal was der Unterschied zwischen ABI und API ist, na ja ich sags ja Über-DAUs.
Fedora schafft es für ihre Cores relativ stabil zu bleiben, was für Core 3 gebaut wurde läuft auch dort. Wenn die Ubuntu-Frickler natürlich immer die neuesten Compiler einsetzen dann wundert mich gar nix.
So, und dann gibt es noch einen ganz besonderen Fall: den Kernel! Bei diesem kommt zu dem obigen Problem durch die hardwarenahe Programmierung noch ein Problem hinzu: manche Codepassagen sind endlose Ketten von Ausnahmen, weil sich irgendein Gerät unter irgendwelchen bestimmten Umständen in irgendeiner Hinsicht danebenbenimmt. Da diese Ausnahmen nur durch Try&Error zu ermitteln sind, läßt sich eben auch nie ausschließen, dass irgendein Kernel-Update zwar für einen Fall die Situation verbessert, sie aber für einen anderen Fall womöglich dramatisch verschlechtert. Aus genau diesem Grund hat der Kernel der meisten Distributionen mit dem Standard-Kernel nicht mehr viel zu tun. Ubuntu hatte da beispielsweise schon bis zum Release von 6.06 rund 1000 Patches drin!
Nein, natürlich nicht!
Es liegt daran, daß die Kontroll-Freaks aus der UNIX-Fraktion keine funktionierende Alternative zulassen wollen. Rafft es endlich: Ein Desktop sollte Spaß machen!
Wann haben wohl die meisten Leute etwas über die Twin-Tower in New York gelernt? Richtig: Als es dort die meiste Action gab. So funktioniert unser Gedächnis nunmal: Es braucht eine gewisse emotionale Beteiligung, damit es läuft.
Eine gewisser Grad von Aufmerksamkeit wird beispielsweise beim Erscheinen einer neuen Version erzeugt: Da ist was Neues! Man kann 'was ausprobieren! Das macht Spaß! Man kann sich mit Freunden darüber unterhalten!
Man denke nur mal an den Spaß als die Moorhuhnjagd ihre Runden durch deutsche Büros gemacht hat: Wäre das unter APT und Konsorten möglich gewesen? Nein!
Warum? Weil die Distributionen mit ihrem Kontroll-Modell nicht schnell genug gewesen wären. Keine Wunder, daß die Leute auf semi-professionelle Pakete zurückgreifen. Oder ihre Zeit verschwenden mit dem Kompilieren von Source-Code!
Und das alles nur wegen den Kontroll-Freaks: "Alles aus einem Repository, sonst wird das nichts!" Das ja wie bei Adolf.
Darum klappt's auch nicht mit Linux auf'm Desktop.
> einem Repository, sonst wird das nichts!"
Du scheinst da etwas in den falschen Hals bekommen zu haben. Das ist keine Kontrolle, sondern Projektmanagement. Der Projektmanager entscheidet nun mal selbst, wofür er Support leistet und wofür nicht, weil er auch dafür verantwortlich ist. Verantwortung == Entscheidungsbefugnis.
Wer mit den Entscheidungen des Projektmanagements nicht einverstanden ist, hat immer die Möglichkeit, ihnen entweder einfach nicht zu folgen oder ein eigenes Projekt zu eröffnen. Dann soll er sich aber auch nicht darüber wundern, wenn die Benutzer sich bei ihm und nicht beim ursprünglichen Projektmanager über Regressions beschweren und mit Sprüchen ankommen, à la "das hat eine höhere Versionsnummer, also erwarte ich, dass es keinen einzigen Fehler hat, den es vorher nicht gab".
> Das ja wie bei Adolf.
http://de.wikipedia.org/wiki/Godwins_Gesetz
> http://de.wikipedia.org/wiki/Godwins_Gesetz
Gähn. Wie vorhersagbar.
Glückwunsch: Du scheinst Godwins Gesetz erkannt zu haben. Nazivergleiche haben nun mal die Eigenschaft, vorhersagbar zu sein - Metavorhersehbarkeit nicht ausgeschlossen.
So locker wie Adolf? Nein danke ;-)
> Hier mal zum Mitsingen:
"Mitsingen" ist genau das richtige Stichwort, das konnte man bei Adolf auch wunderbar.
Manche Leute singen halt lieber was eigenes, gelle.
Und dabei fand ich das apt/deb-System einfach unbrauchbar. Ja ich weiß, darf man nicht laut sagen, davon schwärmen 90% der Linuxnutzer. Ein System, welches mir vorschreibt, daß ich nur die Versionen aus den offiziellen Repositories nutzen darf, kann so nicht sein. Und dann zu sagen, jeder Benutzer, der mit den offiziellen Vorgaben nicht zufrieden ist, hat eine Klatsche, kann auch nicht sein.
Wieso? Eine Distribution wird vor dem Release getestet und das Release erst dann gemacht, wenn sie für gut befunden wurde.
Updates können u.a. dazu führen, dass Software, die auf einem System mit installierten Updates kompiliert wurde, auf einem System ohne Updates nicht mehr läuft. So wäre es z.B. bei glibc- oder gcc-Updates. Bei anderen Paketen kann es andere Effekte geben, die nicht immer vorhersehbar sind. Es kommt halt immer darauf an, um was für Updates es geht.
> Ich weiß ja nicht, ob alle Linuxentwickler unfähig
> sind, aber was man so liest, denken viele bei so
> einer Rebision nicht an eine Fehlerbeseitigung,
> sondern an neue Bugs.
Das liegt nicht daran, dass die Entwickler unfähig wären, sondern daran, dass in angeblich reinen Bugfix-Releases eben doch immer wieder Patches landen, die nicht nur Bugfixes sind. Manchmal werden neue Bugs auch erst bemerkt, nachdem das Paket in "ungewöhnlichen" Umgebungen getestet wurde. In so einem Fall dann nachlegen zu müssen, macht manchmal einen etwas unprofessionellen Eindruck.
> Ein System, welches mir vorschreibt, daß ich nur
> die Versionen aus den offiziellen Repositories
> nutzen darf, kann so nicht sein.
Das System schreibt überhaupt nichts vor, sondern verweigert im Zweifelsfalle einfach den Support, der eine freiwillige Dienstleistung ist, für die die Mehrheit der Benutzer niemals eine Gegenleistung in Form von Geld oder Codebeiträgen liefern. Und auch das nicht, um die Benutzer zu ärgern, sondern weil es anders einfach schwierig ist.
Der Download der aktualisierten CD-Images ist von zahlreichen Mirror-Servern möglich. Es wurde offenbar kein separates Verzeichnis für die neue Version angelegt, so dass man vor dem Download prüfen sollte, ob der Mirror bereits über die aktuelle Version verfügt.
http://ubuntu.intergenia.de/releases/6.06.1/
____________________________^^^^^
zumindest ist das mein kentnisstand
gruß thoand
Bitte - bevor Ihr euch gegenseitig mit unsinnigen Diskussionen heruntermacht fragt doch dann wenigstens mal einen wirklichen Entwickler bzw. Linux-Guru - erspart viel Zeit und Ärger
lg
Beo