Ich weiß dass Alpha heißt Testversion mit fehlenden features, aber um die Wahrheit zu sagen hat man ja noch gar nichts gemacht außer updaten der Pakete von einzelnen Projekten und von Debian.
Versteht mich nicht Falsch, ich benutze selber Ubuntu weil ich persönlich wenig Zeit habe und eine schnelle Lösung brauche, aber ich finde das Ubuntu's Entwicklungsmodell die Distribution selber einschränkt.
Das einzige was sich von Version zu Version ändert sind die einzelnen Pakete, viel zu wenig eigene Initiative. Das liegt halt daran dass sie diesen einschränkenden Releasezyklus haben. Das hat man super gesehen bei dem Benachrichtigungssystem, es gab halt viel zu wenig Zeit um das ganze Ausgiebig zu testen und Feedback einzubauen.
Das ist alles für das eigene Wohl von Ubuntu, man braucht halt mindestens eins bis 1.5 Jahre um was ordentlich neues zu entwickeln. Sechs Monate sind zu wenig.
Mit dem Releasezyklus komm ich klar Aber dass Dinge implementiert werden, die noch gar nicht ausgiebig getestet wurden und beim User dann nach der Installation Probleme auftreten, die gar nicht sein müssten, finde ich ziemlich bescheiden. Und wenn ich einen Zyklus überspringen will, heisst das noch lange nicht, dass das Upgrade dann noch sauber funktioniert.
Finde die Entwicklungsgeschwindigkeit eigentlich ok. Nur das was eingebracht wird, sollte auch getestet sein und stabil laufen. So macht es einfach keinen Spass. Hab jetzt mit Jaunty auch wieder Probs, die ich unter Intrepid nicht hatte. Und das nervt ziemlich. Und ich hatte noch nichtmal ein Upgrade, sondern eine Neuinstallation gemacht.
Aber bei den anderen Distris sieht's ja nicht anders aus.
Aus diesem Grund hab ich von SuSE zu Kubuntu gewechselt. Da waren u viele kleine lästige Fehler. In jeder Version ein Bock geschossen... Kubuntu war perfekt... aber im Moment schaue ich wieder nach links und rechts...
der Wert von Ubuntu ist historisch der, dass sie Debian häufiger stabilisieren als Debian es tut. Dass Ubuntu dann nur punktuell und nicht nachhaltig Verbesserungen hat, sondern eher damit punktet, Software zu früh zu releasen, ist eine logische Folgerung.
Sprich, was erwartest Du, dass Ubuntu genauso oft wie Debian released? Dann wäre es gleich vollkommen unsinnig.
Eine Idee wäre es doch die Distribution strikt in zwei Repositorien zu teilen. Einmal die Applications, OpenOffice, Firefox, und z.B. die Programme von Gnome, und zweitens das System, der Kernel, die Benutzeroberfläche und die Technologien die unter der Haube arbeiten.
Da ja der Beitrag einer Distribution von Ubuntu sowieso nur den Systembereich betreffen, der auch sowas wie ein Benachrichtigungssystem beinhaltet, kann Ubuntu sich zeit nehmen Veränderungen mit einem Zyklus von einem Jahr z.b. zu entwickeln, während Sie zur gleichen Zeit die Applikationen halb-jährlich oder rolling-release mäßig rausgeben.
Das Problem ist sowas spricht halt gegen die Konventionen der Distributionen, aber es würde mir persönlich gefallen. Ich hatte mal ne Zeit lang Arch drauf. Ich habe es gemocht das Applikationen immer auf dem Aktuellsten Stand waren, aber das System war viel zu instabil.
Arch hatte ich auch ein halbes Jahr. Gefällt mir eigentlich super. Ist mir sehr sympathisch :-) Aber ich will dann doch lieber ein System, wo man nicht von Grund auf alles einrichten muss, sondern eins, wo nach der Installation das wesentliche läuft und manche Dinge schon gut aufeinander abgestimmt sind..
Bin mit Ubuntu ja auch im Grunde sehr zufrieden. Aber ab dem nächsten Release warte ich definitiv 2 Monate, bevor ich es installiere.
mein Problem mit Arch war das mein OpenOffice.org nicht nur Abgestürzt ist sondern mein ganzes System mitgenommen hat.
Suspend und Hibernate haben nicht funktioniert.
Das sind die Stärken von Ubuntu, aber viel zu wenig Innovation von Cannonical. Die haben ja die große Masse aber Sie tuen viel zu wenig. Ich sage das nur für das Wohl von Ubuntu selbst. Denn wenn die so weiter machen kann es sein dass die Ihre Uniqueness verlieren und dann nicht mehr soviel Einfluss haben.
Eine Distri, die einen recht konservativen, einfach gestrickten Unterbau mit akuteller Anwendungs- Software kombiniert, ist Slackware.
Weil mir genau dieser Ansatz gefällt, nutze ich Slackware seit 5 oder 6 Jahren, und trotz einiger kurzer Ausflüge zu Arch, Frugalware, Ubuntu, Debian und sogar Pardus ist Slackware immer mein Primärsystem geblieben.
Grundsätzlich würde es ja reichen, wenn für einige Programme eine stabile und eine Testversion als Package verfügbar wäre. Beispiel KDE: Ich war mit 3.5 sehr zu frieden. KDE 4 ist immernoch unausgegohren. Warum also nicht beide zur Verfügung stellen?
> Das einzige was sich von Version zu Version ändert sind die einzelnen Pakete, viel zu wenig eigene Initiative.
Das liegt wohl eher daran dass Canonical (~200), allein von der Anzahl der Mitarbeiter, im Vergleich zu RedHat (~3000) oder Novell (~4000), ein kleines Unternehmen ist.
> Das ist alles für das eigene Wohl von Ubuntu, man braucht halt mindestens > eins bis 1.5 Jahre um was ordentlich neues zu entwickeln. Sechs Monate > sind zu wenig.
Das hat nichts mit Release-Zyklen zu tun. Fixe Release-Zyklen sind zur Zeit "modern" (ist nicht abwertend gemeint), und eines der Grundkonzepte von Agilen Softwareentwicklungs-Prozessen. Auch große etablierte Firmen (wie z.B. Siemens) arbeiten nach solchen Prozessen.
Was du anscheinend falsch verstanden hast ist, dass ein Feature nicht in einem Zyklus begonnen und abgeschlossen werden muss. Arbeitet man an einem Feature welches nicht 6 Monaten fertig wird, dann kommt dieses einfach nicht mit ins Release, stattdessen kommt es erst in nächste, übernächste, ... Release.
Kommt es trotzdem dazu dass unfertige Features in ein Release kommen, dann ist das kein Fehler des Entwicklungsprozesses (denn dieser zwingt keinen das Features zu einem bestimmten Zeitpunkt veröffentlicht werden), sondern ein Fehler der Qualitätssicherung (Fehler wurden vor dem Release nicht erkannt) oder des Managements (welche bewusst was unfertiges veröffentlichen um z.B. mit Features werben zu können). Diese Probleme können aber auch bei allen anderen Entwicklungsprozessen auftreten.
Das mit den kurzen Zyklen versteh ich schon. Das einzige Problem ist das wir bei jedem Release das ganze System updaten muss. Man kann auch neue Features hinzufügen ohne zu riskieren das System zu stabilisieren. Somit hast du natürlich recht das man auch mit kurzen Zyklen Innovation reinbringen kann.
Ich glaub Ubuntu tut auch zu wenig im Kommerziellen Bereich, was eigentlich Schade ist, denn so gibt es keine Einkommensquelle.
Du hast immer den Gegensatz, dass Du entweder kurze Releasezyklen wie in Ubuntu oder Fedora hast, bei denen Du zwar immer releative aktuelle Software bekommst mit dem Nachteil, dass man ständig sein System updaten muss. Wenn Du das nicht willst, muss Du halt bereit sein nicht die allerneuste Programmversionen zu haben, wie bei Debian oder RHEL/CentOS. Dafür hast Du aber ein System, dass man mehrere Jahre ohne ein Distributationsupdate laufen lassen kannst.
Wie Du siehst, Du kannst nicht alles haben: Immer die neuste Softwareversionnen und dazu eine Distributation, die man über jahre nicht updaten muss.
Das hängt aber auch davon ab, ob die LTS-Version tatsächlich "stabil" und damit zu gebrauchen ist. In dieser Hinsicht war Pulseaudio in Ubuntu 8.04 LTS IMHO ein großer Fehler. "Stable" ist anders.
Aber ich will ja genau das dieser Gegensatz nich akzeptiert. Warum kann es bei Linux nicht so sein wie bei, verzeiht mir, windows. Ich hate seit dem Kauf von meinem Laptop noch nie ein Update wo plötzlich vieles nicht mehr funktionierte, sogar nicht bei SP3, trotzdem hab ich immernoch die aktuellste Software, obwohl der Nachfolger von XP schon raus ist.
Wollt ihr mir sagen das wir das mit OpenSource nicht schaffen können?
Ich finde so ein Schritt bring auch viele andere Vorteile mit sich. Ich will ja nicht das alle Distributionen so sind, aber eine unter den ganzen kann ja nicht schaden.
Du meinst die Trennung von System und Userland. Machen das die BSD's nicht so? Und vielleicht auch noch die Jungs von Gentoo, die kompillern das Basissystem doch auch nicht so häufig wie die Benutzerprogramme.
Von Stephan Leitner am Fr, 15. Mai 2009 um 06:29 #
Das kannst Du ja machen, so wie bei Windows. Du lädtst Dir den allerneuesten Firefox oder das allerneueste Openoffice, etc. runter und installierst es. Dann hast Du dasselbe wie bei Windows. Der Vorteil von Distributionen, dass alles aufeinander abgestimmt ist, ist dann halt futsch, aber wie gesagt, bei Windows ist das auch nicht anders.
Ich selber nehme lieber die abgestimmte Version aus der Distri, auch wenn das dann eine etwas ältere ist (bei mir z.B. OO2.4 von Debian Lenny).
Als WinXP herauskam, wurde auch Red Hat 7.2 für Privatnutzer veröffentlicht, mit Kernel 2.4.7, KDE 2.2.1, Gnome 1.4, XFree86 4.1 und Netscape 4.78. http://www.pro-linux.de/berichte/redhat72-vi.html Und das soll man nun etwa volle 8 Jahre unterstützen? So etwas gibt es aber tatsächlich.
Im Serverbereich geht das nämlich, mit RHEL 2.1 aka CentOS 2.1 hat RedHat das durchgezogen. RHEL 2.1 kam im Mai 2002 heraus, eine Version auf dem Stand von RedHat 7.2/7.3), der Support läuft jetzt nach 7 Jahren diesen Mai 2009 aus. Für RHEL bräuchtest Du ein kostenpflichtiges Abo (das kannst Du im übrigen für jede RHEL-Version benutzen, Du wärst nicht auf die 2.1 beschränkt gewesen, Du hättest während Deiner Abo-Zeit auch einfach zu RHEL 3, 4 oder 5 wechseln können), mit CentOS 2.1 hättest Du das bisher umsonst haben können. Und: Mit CentOS 3 bis 5 stehen Dir diese Möglichkeiten auch offen. Zusätzliche, für Desktopnutzer "erforderliche" Software gibt es z.B. hier: http://dag.wieers.com/rpm/.
Du siehst also: Dein Wunsch nach sehr langem Support ist grundsätzlich machbar. Wenn Du nichts bezahlen möchtest, dann bleibt nur CentOS, nur hier wird die gesamte Softwareausstattung über eine so lange Zeit auch gefixt und teilweise aktualisiert, dank veröffentlichter RHEL-Sourcen, die jedem zur Verfügung stehen.
Eine weitere Möglichkeit ist Slackware. So ist Slackware 8.1 von Mitte 2002 bis jetzt nicht vollständig aus dem Support genommen. Allerdings fehlen hier u.a. Updates für GUIs wie Gnome 1.4 und KDE 2 sowie die damaligen Webbrowser. Man muß hier als Nutzer also "mitarbeiten". Wichtige Updates wie dieses hier (bind): http://www.slackware.com/security/viewer.php? l=slackware-security&y=2009&m=slackware-security.540362 kommen aber immer noch. Der Slackware-Support umfasst auch Grafikbibliotheken wie die libpng: http://www.slackware.com/security/viewer.php? l=slackware-security&y=2009&m=slackware-security.523051
Du siehst also, dass Deine obige Aussage: "Ich will ja nicht das alle Distributionen so sind, aber eine unter den ganzen kann ja nicht schaden." offenbar von teilweise falschen Voraussetzungen ausgegangen ist.
Wenn OpenOffice 3 für Suse 7.3 oder Windows 98 nicht mehr zur Verfügung steht, dann ist das halt so. Das Gleiche mit Firefox 3 und Seamonkey 2, GTK1-Versionen sind bald Geschichte und beide Browser laufen auch nicht unter Windows 98, Suse 7.3 oder - ohne "Klimmzüge" - unter Debian Etch. WinXP wird deshalb unterstützt, weil es - als Erfolg eines Monopols - weltweit in riesigen Stückzahlen verbreitet ist. Das wird aber nicht immer so sein. Falls jemand noch Windows 2000 benutzt, so erhält derjenige da gerade einen Vorgeschmack von dem, was eines Tages auch WinXP blühen wird.
Dann noch eines: Die wirklich grundlegenden Programme vieler alter Linuxe lassen sich noch immer aktualisieren, allerdings muß man das selbst machen und es kann sich schon zu schlimmster Mühsal entwickeln, vor allem im Hinblick auf die verlorene Zeit. Kernel 2.4 lässt sich zur Zeit noch immer aktualisieren, auch XFree86. Wer mit Fvwm, Windowmaker oder Icewm zurande kommt, hat weniger Probleme beim Updaten. Sehr oft steht einem allerdings unter Linux eine oft viel zu alte System-Glibc im Weg. Nicht jeder Anbieter von freier Linux-Software denkt auch heute noch an alte libc5- und glibc2-Systeme: http://ftp.xfree86.org/pub/XFree86/4.8.0/binaries/ In diesem Fall mußt Du auch nichts kompilieren, die Binaries werden einfach nur installiert und funktionieren tatsächlich.
ich glaube viele leute missverstehen die realesepolitik von canoncial. die versionen zwischen ubuntu lts sind eigentlich dafür gedacht neuerungen sowie pakete, features, etc. einzuführen und diese entsprechend bis zur nächsten lts version zu vervollständigen bzw. stabil auszuliefern. als "wirkliches" realese imho kann man eigentlich nur die lts versionen ansehen. die versionen von ubuntu mit dem stable zweig von debian zu vergleichen finde also nicht ganz richtig.
Deine Beschreibung der Canoncial Releasepolitik ist eher ein Wunschdenken als die Realität. In Wirklichkeit sind auch die LTS Release am Anfang instabil. Der einzige Unterschied von LTS und nicht LTS sind der Zeitraum in der die Release support erhalten.
Dieses Zitat aus iX 4 April 2009 spricht für sich: Das ändert freilich nichts daran, dass manche Softwareversionen schon heute alt wirken und das Debian-Projekt diese nun über Jahre warten muss: Kernel 2.6.26, Gnome 2.22/2.20, KDE 3.5.9 et cetera (siehe Kasten Eckdaten). Ein Fall für sich ist dabei Gnome: Die Entscheidung für Version 2.22 resultiert aus dem Feature Freeze im Juli 2008. Aber damit nicht genug: Wegen technischer Schwierigkeiten haben die Debian-Entwickler bei einigen Kernkomponenten sogar auf Gnome 2.20 zurückgegriffen (dies betrifft beispielsweise Nautilus oder den Display-Manager GDM).
Bevor nun jemand die mangelnde Aktualität kritisiert, lohnt ein Blick zur Konkurrenz: Unter Ubuntu 8.04 LTS, das ebenfalls auf Gnome 2.22 basiert, ist es bis heute unmöglich, Samba- oder Windows-Shares fehlerfrei mit Nautilus in das Dateisystem einzubinden (Ubuntu Bug 216104, Schuld ist der GVS-Umbau in Gnome 2.22). Ein derart offensichtlicher, seit neun Monaten nicht behobener Fehler ist natürlich einigermaßen peinlich für Canonical, das ja speziell die LTS-Versionen (Long Time Support) für den Unternehmenseinsatz anpreist. Der konservative Debian-Weg wirkt da überzeugender, auch wenn sich damit in Testberichten oft kein Lorbeer gewinnen lässt. Noch eleganter wäre nur der Einsatz von Gnome 2.24, in dem der Fehler längst behoben ist.
Hallo, genauso peinlich ist es das Debian4 noch Jahre nach veröffentlichung Bugs mit sich rumschleppte, die bereits in der RC-Phase offensichtlich waren.
u.a.: Kaffeine stürtzt sporadisch ab, wenn man ogg-audio-files vor und zurückspult, und dann auf wiederholung stehend das lied wieder von vorne beginnt. ich kapiere hier nicht das der Maintainer nicht sein eigenes Programm 1-2 Stunden testet, dann waer das aufgefallen.
u.a.: lighttpd mit mysql-unterstuetzung: die mysql-connection wird nach einem timeout abgebrochen. dafuer existierten bereits zur RC-Phase Patches. Ich selbst habe diesen in den Debian-Quellcode eingespielt, getestet, und nach erfolgreicher Fehlerbehebung kontakt zum Debian-Maintainer aufgenommen. Erst Wochen spaeter erhielt ich eine Antwort, mit einer bestätigung des Bugs. Der darauffolgende Patch des pakets behob einen andern Bug, so das ich wieder das Paket erneut manuell Patchen musste...
Ich sehe damit nicht das Debian eine erheblich bessere Patch-Politik faehrt wie Ubuntu. "Generell" ist die Politik aktuelle Software zu verwenden "imho" sinnvoller als auf angeblich "Stabile" Systeme zu setzen. Natuerlich gibt es auch da Ausnamen: KDE ist imho erst seit 4.2.x halbwegs stable einsetzbar
Trotzdem: Dieser Ubuntu-Bug 216104 in einem LTS-Release und die Tatsache, dass er anscheinend seit Ewigkeiten nicht gefixt wird, ist ganz großer Mist. Unter https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/216104 findet sich dazu ein Kommentar eines Nutzers (Michael Kofler), der das Problem sehr treffend beschreibt:
"It is fixed in Jaunty *and* in Intrepid, but not in Hardy
basically, it is fixed since Gnome 2.24
the problem is: Hardy is LTS and is promoted for enterprise and business use; this is a serious flaw for inexperienced desktop users; therefore, it should be fixed also in Hardy (backport the Nautilus fix or whatever); if Hardy were not LTS, this bug could have been closed a half year ago"
Meine Meinung: Dieser Bug muß gefixt werden. Die non-LTS-Nachfolger von Hardy, Intrepid und Jaunty, funktionieren in dieser Hinsicht schließlich.
"Generell" ist die Politik aktuelle Software zu verwenden "imho" sinnvoller als auf angeblich "Stabile" Systeme zu setzen.
Definiere "generell". Und "imho" solltest Du nicht in Anführungsstriche setzen, Du willst ja vermutlich Deine bescheidene Meinung zum Ausdruck bringen ;-)
Im Serverbereich möchte man vielleicht nicht ständig die neueste Software einspielen müssen, die ggf. "Kleinigkeiten" ändert und einem damit das halbe System auf die Füße fallen läßt. Und auch im Desktop-Bereich bin ich jüngst von Debian Testing zu Stable gewechselt, weil ich die ständigen Update-Orgien satt hatte. Ich brauche nicht die aktuellste Software. Sie muß funktionieren. Und das tut das, was ich einsetze.
Ich verstehe zwar, warum Du das Heise-Zitat bringst.
Das altbewährte Zitationsschema, zuerst Aufstellung einer (wissenschaftlichen) These, dann Zitieren zum Nach- bzw. Beweis, fehlt hier schließlich weitgehend. Und bloße "Nachdrucke" von Passagen aus Heise-Magazinen sind ja eigentlich nicht autorisiert.
Sind solche Zitate denn ein juristisches Problem für Prolinux? Wie ist denn hier die rechtliche Lage? Kann im Worst Case Scenario der Forenbetreiber in Regreß genommen werden oder "nur" der Poster?
> Das altbewährte Zitationsschema, zuerst Aufstellung einer (wissenschaftlichen) These, dann Zitieren zum Nach- bzw. Beweis, fehlt hier schließlich weitgehend
Kannst du lesen?! Ich habe eindeutig geschrieben, wo ich das Zitat hergenommen habe und sogar einen direkten Link zum veröffentlichten Artikel angegeben. Was fehlt dir noch?
> Kann im Worst Case Scenario der Forenbetreiber in Regreß genommen werden oder "nur" der Poster?
Heise hat schon Foren wegen solcher ausschweifenden Zitate abmahnen lassen. Bitte einfach googeln: "heise mahnt ab" o.ä. Wie die aktuelle Rechtsprechung und das aktuelle Verhalten des Heise-Verlages dazu aussehen, weiß ich zwar nicht ganz genau. Aber diskussionswürdig ist dieses Thema schon. Also nichts mit heißer Pfanne ...
die lts versionen sind auch ein witz. für den user, der sich nicht weiter damit beschäftigen möchte, sind diese schon nach einem jahr eine katastrophe (ok, vll ein bisschen übertrieben), zb pidgin und icq, openoffice. ich finde die release-zyklen allgemein für zu antiquiert. meiner meinung nach sollte die lts version jährlich herauskommen und die halbjahres releases sollten nur als testversionen alle 3-4 monate kommen wobei die letzte version vor dem jahresrelease eine reine bugsquashing veröffentlichung sein soll. ich weiss, das sit nicht der weisheit letzter schluss, aber auf jeden fall besser als jetzt.
btw, ich finde auch das patchen alter versionen anstatt einfach das programm zu aktualisieren ein unding. es mag historisch gersehen sinn machen, aber bei den doch recht schnellen softwarereleasezyklen heutzutage verschwinden viele bugs "von selbst". und viele neue features gibt es meistens auch nicht.
btw, ich finde auch das patchen alter versionen anstatt einfach das programm zu aktualisieren ein unding.
Entschuldige bitte, aber das liegt daran, daß Du nicht verstehst, warum man das macht.
Neue Software-Versionen ändern mitunter Dinge, die für Anwender systemkritisch sind in dem Sinne, daß sie sich auf ein bestimmtes Verhalten "verlassen" - z.B. im Zusammenspiel mit anderen Anwendungen. Solche Änderungen sind dann unerwünscht.
Deswegen gibt es im kommerziellen Bereich z.B. RedHat, wo dann eben im Falle von Bugs gepatched wird. Die Kunden wollen dann keine neue Version, die sich ggf. in manchen Bereichen anders verhält, als gewohnt und gewollt.
Ich kann absolut nicht nachvollziehen, wieso Ubuntu jetzt schon auf GCC v4.4 umgestiegen ist. Speziell diese Version ist voller Fehler und einige Programme kompilieren nicht mehr richtig, weil GCC irgendwo mittendrin abstuerzt... Im IRC wurden meine Anfragen ignoriert sowie auch die meisten Beschwerden der anderen Teilnahmer. Schade eigentlich um das sonst so gute Programm. Hoffentlich gibt es bald eine ernstzunehmende Alternative.
Ja, das stimmt! Wir haben massive Probleme mit einigen Paketen, die nicht mehr richtig vom System kompiliert werden. Allerdings kann eine frühe Integration des neuen Compilers auch helfen, Fehler frühzeitig zu finden. Insgesamt bin ich dafür, jedes Feature so schnell wie möglich in die Alpha-Versionen zu bringen, wenn absehbar ist, dass dieses mit dem Release fertig ist. So ist der Testzeitraum einfach länger und man hat mehr Zeit, Bugs zu beheben. P.S: Den aktuellen Status des Karmic-Buildprozesses ist auf dieser Seite öffentlich einsehbar: http://qa.ubuntuwire.com/ftbfs/
Ein Mass-Rebuild kann da manchmal Wunder bewirken, da die Maintainer, deren Pakete Probleme mit einen neueren Compiler haben, dann auf die Füße getreten wird.
Wenn das Compilieren unter gcc-4.4 fehlschlägt, dann muss dies kein Fehler des Compilers sein. Unter C++ wird der Unterschied zwischen const char * und char * bei den Prototype der Stringfunktionen strikter gehandhabt, als in den Vorgängerversionen.
Als weiterer Tipp möchte ich erwähnen, dass Fedora 11, welches Ende dieses Monats erscheinen soll, auf gcc-4.4 basiert. Da alle Pakete mit gcc-4.4 übersetzt wurden, sollten für die Problemfälle entsprechende Patches existieren.
Ich selbst konnte mich nur an ein Problem mit gcc#4.4 erinnern, was durch einen Compilerbug ausgeläst wurde. Dieses Problem ist aber in der jetzigen Compilerversion gefixt.
Hm, hier auf Arch ist der GCC 4.4 auch schon drin und alles funktioniert bis auf pdftk mit dem gcj. Es ist schon immer wieder erstaunlich wie unterschiedlich das sein kann.
Frage: Hast Du pdftk auf iText-2.1.5 portiert. Das ist unbedingt notwendig, da die iText-Bibliothek, welche mit pdftk mitgeliefert wird, nicht als frei betrachtet werden kann.
Im Fedora-Projekt haben wir pdftk so aufbereitet, dass pdftk gegen iText-2.1.5 gelinkt wird. Dabei gab es ein Problem beim Optimieren des Codes, was aber nun gefixt ist.
die Alpha1 kommt noch mit mksquashfs daher, was v3 Squashfs Images erzeugt, der 2.6.30 Kernel kann jedoch nur v4 Squashfs lesen. Dann fehlen noch für Schreiboverlay sowohl unionfs als auf aufs. Demzufolge kann man für die Alpha1 keine LiveCD erstellen,
Versteht mich nicht Falsch, ich benutze selber Ubuntu weil ich persönlich wenig Zeit habe und eine schnelle Lösung brauche, aber ich finde das Ubuntu's Entwicklungsmodell die Distribution selber einschränkt.
Das einzige was sich von Version zu Version ändert sind die einzelnen Pakete, viel zu wenig eigene Initiative. Das liegt halt daran dass sie diesen einschränkenden Releasezyklus haben. Das hat man super gesehen bei dem Benachrichtigungssystem, es gab halt viel zu wenig Zeit um das ganze Ausgiebig zu testen und Feedback einzubauen.
Das ist alles für das eigene Wohl von Ubuntu, man braucht halt mindestens eins bis 1.5 Jahre um was ordentlich neues zu entwickeln. Sechs Monate sind zu wenig.
Mit der Hoffnung das es nur besser wird.
Finde die Entwicklungsgeschwindigkeit eigentlich ok. Nur das was eingebracht wird, sollte auch getestet sein und stabil laufen. So macht es einfach keinen Spass. Hab jetzt mit Jaunty auch wieder Probs, die ich unter Intrepid nicht hatte. Und das nervt ziemlich. Und ich hatte noch nichtmal ein Upgrade, sondern eine Neuinstallation gemacht.
Aber bei den anderen Distris sieht's ja nicht anders aus.
Oktarius
der Wert von Ubuntu ist historisch der, dass sie Debian häufiger stabilisieren als Debian es tut. Dass Ubuntu dann nur punktuell und nicht nachhaltig Verbesserungen hat, sondern eher damit punktet, Software zu früh zu releasen, ist eine logische Folgerung.
Sprich, was erwartest Du, dass Ubuntu genauso oft wie Debian released? Dann wäre es gleich vollkommen unsinnig.
Gruss,
Kay
Eine Idee wäre es doch die Distribution strikt in zwei Repositorien zu teilen. Einmal die Applications, OpenOffice, Firefox, und z.B. die Programme von Gnome, und zweitens das System, der Kernel, die Benutzeroberfläche und die Technologien die unter der Haube arbeiten.
Da ja der Beitrag einer Distribution von Ubuntu sowieso nur den Systembereich betreffen, der auch sowas wie ein Benachrichtigungssystem beinhaltet, kann Ubuntu sich zeit nehmen Veränderungen mit einem Zyklus von einem Jahr z.b. zu entwickeln, während Sie zur gleichen Zeit die Applikationen halb-jährlich oder rolling-release mäßig rausgeben.
Das Problem ist sowas spricht halt gegen die Konventionen der Distributionen, aber es würde mir persönlich gefallen. Ich hatte mal ne Zeit lang Arch drauf. Ich habe es gemocht das Applikationen immer auf dem Aktuellsten Stand waren, aber das System war viel zu instabil.
mfg
Aber ich will dann doch lieber ein System, wo man nicht von Grund auf alles einrichten muss,
sondern eins, wo nach der Installation das wesentliche läuft und manche Dinge schon gut
aufeinander abgestimmt sind..
Bin mit Ubuntu ja auch im Grunde sehr zufrieden. Aber ab dem nächsten Release warte ich definitiv
2 Monate, bevor ich es installiere.
Suspend und Hibernate haben nicht funktioniert.
Das sind die Stärken von Ubuntu, aber viel zu wenig Innovation von Cannonical. Die haben ja die große Masse aber Sie tuen viel zu wenig. Ich sage das nur für das Wohl von Ubuntu selbst. Denn wenn die so weiter machen kann es sein dass die Ihre Uniqueness verlieren und dann nicht mehr soviel Einfluss haben.
Weil mir genau dieser Ansatz gefällt, nutze ich Slackware seit 5 oder 6 Jahren, und trotz einiger kurzer Ausflüge zu Arch, Frugalware, Ubuntu, Debian und sogar Pardus ist Slackware immer mein Primärsystem geblieben.
Das liegt wohl eher daran dass Canonical (~200), allein von der Anzahl der Mitarbeiter, im Vergleich zu RedHat (~3000) oder Novell (~4000), ein kleines Unternehmen ist.
> Das ist alles für das eigene Wohl von Ubuntu, man braucht halt mindestens
> eins bis 1.5 Jahre um was ordentlich neues zu entwickeln. Sechs Monate
> sind zu wenig.
Das hat nichts mit Release-Zyklen zu tun. Fixe Release-Zyklen sind zur Zeit "modern" (ist nicht abwertend gemeint), und eines der Grundkonzepte von Agilen Softwareentwicklungs-Prozessen. Auch große etablierte Firmen (wie z.B. Siemens) arbeiten nach solchen Prozessen.
Was du anscheinend falsch verstanden hast ist, dass ein Feature nicht in einem Zyklus begonnen und abgeschlossen werden muss. Arbeitet man an einem Feature welches nicht 6 Monaten fertig wird, dann kommt dieses einfach nicht mit ins Release, stattdessen kommt es erst in nächste, übernächste, ... Release.
Kommt es trotzdem dazu dass unfertige Features in ein Release kommen, dann ist das kein Fehler des Entwicklungsprozesses (denn dieser zwingt keinen das Features zu einem bestimmten Zeitpunkt veröffentlicht werden), sondern ein Fehler der Qualitätssicherung (Fehler wurden vor dem Release nicht erkannt) oder des Managements (welche bewusst was unfertiges veröffentlichen um z.B. mit Features werben zu können). Diese Probleme können aber auch bei allen anderen Entwicklungsprozessen auftreten.
Das mit den kurzen Zyklen versteh ich schon. Das einzige Problem ist das wir bei jedem Release das ganze System updaten muss. Man kann auch neue Features hinzufügen ohne zu riskieren das System zu stabilisieren. Somit hast du natürlich recht das man auch mit kurzen Zyklen Innovation reinbringen kann.
Ich glaub Ubuntu tut auch zu wenig im Kommerziellen Bereich, was eigentlich Schade ist, denn so gibt es keine Einkommensquelle.
Wie Du siehst, Du kannst nicht alles haben: Immer die neuste Softwareversionnen und dazu eine Distributation, die man über jahre nicht updaten muss.
In dieser Hinsicht war Pulseaudio in Ubuntu 8.04 LTS IMHO ein großer Fehler.
"Stable" ist anders.
Wollt ihr mir sagen das wir das mit OpenSource nicht schaffen können?
Ich finde so ein Schritt bring auch viele andere Vorteile mit sich. Ich will ja nicht das alle Distributionen so sind, aber eine unter den ganzen kann ja nicht schaden.
Machen das die BSD's nicht so?
Und vielleicht auch noch die Jungs von Gentoo, die kompillern das Basissystem doch auch nicht so häufig wie die Benutzerprogramme.
Ich selber nehme lieber die abgestimmte Version aus der Distri, auch wenn das dann eine etwas ältere ist (bei mir z.B. OO2.4 von Debian Lenny).
lg,
Stephan
http://www.pro-linux.de/berichte/redhat72-vi.html
Und das soll man nun etwa volle 8 Jahre unterstützen?
So etwas gibt es aber tatsächlich.
Im Serverbereich geht das nämlich, mit RHEL 2.1 aka CentOS 2.1 hat RedHat das durchgezogen. RHEL 2.1 kam im Mai 2002 heraus, eine Version auf dem Stand von RedHat 7.2/7.3), der Support läuft jetzt nach 7 Jahren diesen Mai 2009 aus. Für RHEL bräuchtest Du ein kostenpflichtiges Abo (das kannst Du im übrigen für jede RHEL-Version benutzen, Du wärst nicht auf die 2.1 beschränkt gewesen, Du hättest während Deiner Abo-Zeit auch einfach zu RHEL 3, 4 oder 5 wechseln können), mit CentOS 2.1 hättest Du das bisher umsonst haben können. Und: Mit CentOS 3 bis 5 stehen Dir diese Möglichkeiten auch offen. Zusätzliche, für Desktopnutzer "erforderliche" Software gibt es z.B. hier: http://dag.wieers.com/rpm/.
Du siehst also: Dein Wunsch nach sehr langem Support ist grundsätzlich machbar. Wenn Du nichts bezahlen möchtest, dann bleibt nur CentOS, nur hier wird die gesamte Softwareausstattung über eine so lange Zeit auch gefixt und teilweise aktualisiert, dank veröffentlichter RHEL-Sourcen, die jedem zur Verfügung stehen.
Eine weitere Möglichkeit ist Slackware. So ist Slackware 8.1 von Mitte 2002 bis jetzt nicht vollständig aus dem Support genommen. Allerdings fehlen hier u.a. Updates für GUIs wie Gnome 1.4 und KDE 2 sowie die damaligen Webbrowser. Man muß hier als Nutzer also "mitarbeiten". Wichtige Updates wie dieses hier (bind):
http://www.slackware.com/security/viewer.php?
l=slackware-security&y=2009&m=slackware-security.540362
kommen aber immer noch.
Der Slackware-Support umfasst auch Grafikbibliotheken wie die libpng:
http://www.slackware.com/security/viewer.php?
l=slackware-security&y=2009&m=slackware-security.523051
Du siehst also, dass Deine obige Aussage:
"Ich will ja nicht das alle Distributionen so sind, aber eine unter den ganzen kann ja nicht schaden."
offenbar von teilweise falschen Voraussetzungen ausgegangen ist.
Das Gleiche mit Firefox 3 und Seamonkey 2, GTK1-Versionen sind bald Geschichte und beide Browser laufen auch nicht unter Windows 98, Suse 7.3 oder - ohne "Klimmzüge" - unter Debian Etch.
WinXP wird deshalb unterstützt, weil es - als Erfolg eines Monopols - weltweit in riesigen Stückzahlen verbreitet ist.
Das wird aber nicht immer so sein.
Falls jemand noch Windows 2000 benutzt, so erhält derjenige da gerade einen Vorgeschmack von dem, was eines Tages auch WinXP blühen wird.
Dann noch eines: Die wirklich grundlegenden Programme vieler alter Linuxe lassen sich noch immer aktualisieren, allerdings muß man das selbst machen und es kann sich schon zu schlimmster Mühsal entwickeln, vor allem im Hinblick auf die verlorene Zeit.
Kernel 2.4 lässt sich zur Zeit noch immer aktualisieren, auch XFree86. Wer mit Fvwm, Windowmaker oder Icewm zurande kommt, hat weniger Probleme beim Updaten.
Sehr oft steht einem allerdings unter Linux eine oft viel zu alte System-Glibc im Weg.
Nicht jeder Anbieter von freier Linux-Software denkt auch heute noch an alte libc5- und glibc2-Systeme:
http://ftp.xfree86.org/pub/XFree86/4.8.0/binaries/
In diesem Fall mußt Du auch nichts kompilieren, die Binaries werden einfach nur installiert und funktionieren tatsächlich.
wenn man nicht upgraded wir man über kurz oder lang vor einem unbrauchbaren System hocken..
habe hier zB ein altes RH und ein etwas jüngeres Mandrake und beide sind gut zum offline reinschauen..
Der Omega13.
die versionen zwischen ubuntu lts sind eigentlich dafür gedacht neuerungen sowie pakete, features, etc. einzuführen und diese entsprechend bis zur nächsten lts version zu vervollständigen bzw. stabil auszuliefern. als "wirkliches" realese imho kann man eigentlich nur die lts versionen ansehen.
die versionen von ubuntu mit dem stable zweig von debian zu vergleichen finde also nicht ganz richtig.
Der einzige Unterschied von LTS und nicht LTS sind der Zeitraum in der die Release support erhalten.
Das ändert freilich nichts daran, dass manche Softwareversionen schon heute alt wirken und das Debian-Projekt diese nun über Jahre warten muss: Kernel 2.6.26, Gnome 2.22/2.20, KDE 3.5.9 et cetera (siehe Kasten Eckdaten). Ein Fall für sich ist dabei Gnome: Die Entscheidung für Version 2.22 resultiert aus dem Feature Freeze im Juli 2008. Aber damit nicht genug: Wegen technischer Schwierigkeiten haben die Debian-Entwickler bei einigen Kernkomponenten sogar auf Gnome 2.20 zurückgegriffen (dies betrifft beispielsweise Nautilus oder den Display-Manager GDM).
Bevor nun jemand die mangelnde Aktualität kritisiert, lohnt ein Blick zur Konkurrenz: Unter Ubuntu 8.04 LTS, das ebenfalls auf Gnome 2.22 basiert, ist es bis heute unmöglich, Samba- oder Windows-Shares fehlerfrei mit Nautilus in das Dateisystem einzubinden (Ubuntu Bug 216104, Schuld ist der GVS-Umbau in Gnome 2.22). Ein derart offensichtlicher, seit neun Monaten nicht behobener Fehler ist natürlich einigermaßen peinlich für Canonical, das ja speziell die LTS-Versionen (Long Time Support) für den Unternehmenseinsatz anpreist. Der konservative Debian-Weg wirkt da überzeugender, auch wenn sich damit in Testberichten oft kein Lorbeer gewinnen lässt. Noch eleganter wäre nur der Einsatz von Gnome 2.24, in dem der Fehler längst behoben ist.
Quelle: http://www.heise.de/ix/artikel/2009/04/072/
genauso peinlich ist es das Debian4 noch Jahre nach veröffentlichung Bugs mit sich rumschleppte, die bereits in der RC-Phase offensichtlich waren.
u.a.: Kaffeine stürtzt sporadisch ab, wenn man ogg-audio-files vor und zurückspult, und dann auf wiederholung stehend das lied wieder von vorne beginnt. ich kapiere hier nicht das der Maintainer nicht sein eigenes Programm 1-2 Stunden testet, dann waer das aufgefallen.
u.a.: lighttpd mit mysql-unterstuetzung: die mysql-connection wird nach einem timeout abgebrochen. dafuer existierten bereits zur RC-Phase Patches. Ich selbst habe diesen in den Debian-Quellcode eingespielt, getestet, und nach erfolgreicher Fehlerbehebung kontakt zum Debian-Maintainer aufgenommen. Erst Wochen spaeter erhielt ich eine Antwort, mit einer bestätigung des Bugs. Der darauffolgende Patch des pakets behob einen andern Bug, so das ich wieder das Paket erneut manuell Patchen musste...
Ich sehe damit nicht das Debian eine erheblich bessere Patch-Politik faehrt wie Ubuntu. "Generell" ist die Politik aktuelle Software zu verwenden "imho" sinnvoller als auf angeblich "Stabile" Systeme zu setzen. Natuerlich gibt es auch da Ausnamen: KDE ist imho erst seit 4.2.x halbwegs stable einsetzbar
Gruss,
Andre
Unter https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/216104 findet sich dazu ein Kommentar eines Nutzers (Michael Kofler), der das Problem sehr treffend beschreibt:
"It is fixed in Jaunty *and* in Intrepid, but not in Hardy
basically, it is fixed since Gnome 2.24
the problem is: Hardy is LTS and is promoted for enterprise and business use; this is a serious flaw for inexperienced desktop users; therefore, it should be fixed also in Hardy (backport the Nautilus fix or whatever); if Hardy were not LTS, this bug could have been closed a half year ago"
Meine Meinung: Dieser Bug muß gefixt werden. Die non-LTS-Nachfolger von Hardy, Intrepid und Jaunty, funktionieren in dieser Hinsicht schließlich.
Definiere "generell". Und "imho" solltest Du nicht in Anführungsstriche setzen, Du willst ja vermutlich Deine bescheidene Meinung zum Ausdruck bringen ;-)
Im Serverbereich möchte man vielleicht nicht ständig die neueste Software einspielen müssen, die ggf. "Kleinigkeiten" ändert und einem damit das halbe System auf die Füße fallen läßt.
Und auch im Desktop-Bereich bin ich jüngst von Debian Testing zu Stable gewechselt, weil ich die ständigen Update-Orgien satt hatte. Ich brauche nicht die aktuellste Software. Sie muß funktionieren. Und das tut das, was ich einsetze.
Das altbewährte Zitationsschema, zuerst Aufstellung einer (wissenschaftlichen) These, dann Zitieren zum Nach- bzw. Beweis, fehlt hier schließlich weitgehend. Und bloße "Nachdrucke" von Passagen aus Heise-Magazinen sind ja eigentlich nicht autorisiert.
Sind solche Zitate denn ein juristisches Problem für Prolinux?
Wie ist denn hier die rechtliche Lage?
Kann im Worst Case Scenario der Forenbetreiber in Regreß genommen werden oder "nur" der Poster?
Kannst du lesen?! Ich habe eindeutig geschrieben, wo ich das Zitat hergenommen habe und sogar einen direkten Link zum veröffentlichten Artikel angegeben. Was fehlt dir noch?
> Kann im Worst Case Scenario der Forenbetreiber in Regreß genommen werden oder "nur" der Poster?
Hast du die Pfanne heiß...?
Bitte einfach googeln:
"heise mahnt ab" o.ä.
Wie die aktuelle Rechtsprechung und das aktuelle Verhalten des Heise-Verlages dazu aussehen, weiß ich zwar nicht ganz genau. Aber diskussionswürdig ist dieses Thema schon.
Also nichts mit heißer Pfanne ...
für den user, der sich nicht weiter damit beschäftigen möchte, sind diese schon nach einem jahr eine katastrophe (ok, vll ein bisschen übertrieben), zb pidgin und icq, openoffice.
ich finde die release-zyklen allgemein für zu antiquiert.
meiner meinung nach sollte die lts version jährlich herauskommen und die halbjahres releases sollten nur als testversionen alle 3-4 monate kommen wobei die letzte version vor dem jahresrelease eine reine bugsquashing veröffentlichung sein soll.
ich weiss, das sit nicht der weisheit letzter schluss, aber auf jeden fall besser als jetzt.
es mag historisch gersehen sinn machen, aber bei den doch recht schnellen softwarereleasezyklen heutzutage verschwinden viele bugs "von selbst". und viele neue features gibt es meistens auch nicht.
Entschuldige bitte, aber das liegt daran, daß Du nicht verstehst, warum man das macht.
Neue Software-Versionen ändern mitunter Dinge, die für Anwender systemkritisch sind in dem Sinne, daß sie sich auf ein bestimmtes Verhalten "verlassen" - z.B. im Zusammenspiel mit anderen Anwendungen. Solche Änderungen sind dann unerwünscht.
Deswegen gibt es im kommerziellen Bereich z.B. RedHat, wo dann eben im Falle von Bugs gepatched wird. Die Kunden wollen dann keine neue Version, die sich ggf. in manchen Bereichen anders verhält, als gewohnt und gewollt.
Hier ist ein interessanter Blog, der die Entwicklung begleitet: Drück mich
Allerdings kann eine frühe Integration des neuen Compilers auch helfen, Fehler frühzeitig zu finden. Insgesamt bin ich dafür, jedes Feature so schnell wie möglich in die Alpha-Versionen zu bringen, wenn absehbar ist, dass dieses mit dem Release fertig ist. So ist der Testzeitraum einfach länger und man hat mehr Zeit, Bugs zu beheben.
P.S: Den aktuellen Status des Karmic-Buildprozesses ist auf dieser Seite öffentlich einsehbar: http://qa.ubuntuwire.com/ftbfs/
Ein Mass-Rebuild kann da manchmal Wunder bewirken, da die Maintainer, deren
Pakete Probleme mit einen neueren Compiler haben, dann auf die Füße getreten
wird.
Als weiterer Tipp möchte ich erwähnen, dass Fedora 11, welches Ende dieses Monats erscheinen soll, auf gcc-4.4 basiert.
Da alle Pakete mit gcc-4.4 übersetzt wurden, sollten für die Problemfälle entsprechende Patches existieren.
Ich selbst konnte mich nur an ein Problem mit gcc#4.4 erinnern, was durch einen Compilerbug ausgeläst wurde. Dieses
Problem ist aber in der jetzigen Compilerversion gefixt.
Es ist schon immer wieder erstaunlich wie unterschiedlich das sein kann.
Im Fedora-Projekt haben wir pdftk so aufbereitet, dass pdftk gegen iText-2.1.5 gelinkt wird. Dabei gab es ein Problem beim Optimieren des Codes, was aber nun gefixt ist.
mfg: Jochen Schmitt
(nur dass das mal wo dokumentiert ist)
die Alpha1 kommt noch mit mksquashfs daher, was v3 Squashfs Images erzeugt, der 2.6.30 Kernel kann jedoch nur v4 Squashfs lesen.
Dann fehlen noch für Schreiboverlay sowohl unionfs als auf aufs.
Demzufolge kann man für die Alpha1 keine LiveCD erstellen,
Roland