Moin, Am Donnerstag, den 03.02.2005, 08:44 +0100 schrieb Eduard Bloch: > Joerg Rossdeutscher schrieb am Samstag, den 29. Januar 2005:
> Du redest M�ll. Bitte moduliere deinen Umgangston. Nur weil ich mit Versionsnummern in woody nicht gl�cklich bin, sind meine Aussagen l�ngst kein "M�ll". Danke. > Die meisten dieser Dinger sind zur Compilerzeit > festgelegte Features (z.B. kein LZW, weil damals noch Patente drauf > existierten). Es steht dir frei, Dinge deinem Belieben nach zu > rekompilieren. Woraufhin das beim Update wieder �berschrieben wird. Ganz zu schweigen von Sicherheitsl�cken in Dependencies, die du dann selbst beheben mu�t. > > Mit dem "veralten" ist das so eine Sache. Derzeit ist das alles relativ > > egal und Debian die tollste Distri der Welt, denn Debian hat exim4.34, > > und der Rest der Welt hat auch exim4.34. Supi! > > > > In 18 Monaten hat Debian exim4.34-5, und der Rest der Welt hat exim99.9 > > mit Spoilern, drei Hupen, Minibar und Raketenantrieb. Da liegt die Idee > > Du redest wieder M�ll. Wenn du das superneuste haben willst, dann > verwende Debian Unstable. Die Paar anderen Volks-Distris (die deine > "Welt" ausmachen) machen auch nichts anderes, als superdollneue > Versionen irgendwie zu verpacken. Was meine "Welt" ausmacht, das weisst du gar nicht, und "Volks-Distris" kenne ich auch nicht. Bei ernsthafter Arbeit mit einem Server wirst du sicherlich mal �ber so etwas gestolpert sein: http://shorewall.net/ : End of support life for Shorewall 1.4 -- Upgrading to Shorewall 2.2 Oder: http://exim.org/ All versions of exim previous to version 4.x are now considered obsolete and everyone is strongly recommended to upgrade to a current release. Gerade heute, ich finde den Link leider nicht wieder, bin ich �ber die Aussage eines Exim-Entwicklers gestolpert, da� auch sicherheitskritische Probleme in exim3 nicht mehr gefixt w�rden: Er k�nne sich kaum noch an den Kram erinnern. Wenn du weiter suchst, wirst du zum Beispiel Aussagen von Debian-Maintainern finden, da� selbst sicherheitskritische Fixes in Mozilla und Samba nicht mehr vern�nftig re-portierbar seien, weil einige Komponenten mit alten Versionen nichts mehr gemein h�tten. Mit "Superneu" hat das gar nichts zu tun. Entgegen anderer Behauptungen tut der alte Kram eben nicht mehr sicher und stabil seinen Dienst. Siehe oben. W�re das so einfach, w�rde ich mit Freuden Kernel 2.0 aufspielen. Das war das Thema Sicherheit. Ganz zu schweigen von Features. Oh Gott! Das F-Wort! Er hat "Features" gesagt! Ich f�r meinen Teil sehe �berhaupt keinen Sinn, keine Stabilit�t und keine Ergonomie darin, auf der Suche nach einer Probleml�sung f�r meinen exim quer durchs Netz zu stolpern, immer und immer und immer wieder L�sungen f�r exim VIER zu finden, die in DREI nicht laufen. Wo ist da die Vernunft? Warum soll ich mir das antun? Und deswegen neu kompilieren, ohne security-Unterst�tzung? Oder durch Backports, ebenfalls ohne Security? Soll das sinnvoller, praktischer, besser sein? Mir geht das Web als L�sungsquelle verloren. > Dir scheint nicht bewusst zu sein, dass ausser Debian Stable auch andere > Systeme f�r den gleichen Benutzerkreis existieren. Und man orientiert > sich da auch nicht an das Release-Datum vom n�chsten > Linux <hohe.nummer.x.y.z> HOME | "Professional". Was willst du mir sagen? > > nahe, bereits jetzt kein Sarge auf die Kiste zu tun, wenn man in 3 > > Monaten doch wieder so unzufrieden damit sein wird, dass man in 6 > > Monaten migriert. Dann doch lieber gleich - warum erst leiden und dann > > doch operieren? > > AUA. Versionskrankheit, meistens heilbar. Oder man steigt auf den > Unstable-Zweig um. Auf Servern? Ich glaub, es hackt... im wahrsten Sinne des Wortes... > > Einen Releasezyklus unter 12 Monaten sehe ich wirklich kritisch. Der > > Rest der Welt ist nun mal schnelllebiger, und die neuen Features gehen > > verloren. > > Und du redest schon wieder M�ll. Um ein Paar neue Features zu bekommen, > willst du das ganze System upgraden. Tolle L�sung (in einer > Produktiv-Umgebung). "Ein paar Features"? "Ein paar Features" w�re exim4.2 oder Mozilla 1.5. Oder so. Wir reden hier von Software aus 2001. Da hatten wir noch'n Kaiser. (http://www.gnome.org/press/releases/) F�r den Desktop w�rs mir egal. Da nutze ich eh sid. Auf dem Server kommt das nicht in die T�te. > > Das Problematischste daran ist, dass man sozusagen zur "Insel" wird. Man > > hat eine Idee, was man realisieren will, man ergoogelt sich irgendwelche > > shorewall- oder exim-Einstellungen im Netz und stellt dann fest, da� sie > > "nicht tut". Weil man eine Version f�hrt, die beim Upstream schon in > > Kisten vernagelt im Keller steht. > > Kommt auf den Upstream an. Es gibt Software-Autoren, die fluchen, weil > Debian-User sich �ber Bugs in ihren _stabilen_ Versionen (die nat�rlich > nur ein Paar Monate alt sind, und das st�ndig). Dummerweise redet man da > von _ihren_ Bugs die in der von _ihnen_ freigegebener Software > existieren. Sowas versucht man schnell unter den Teppich zu kehren oder > mit neuen Features zu blenden, nur funktioniert dieser Schweinezyklus > nicht mit Debian Stable u.ae. Ich entwickle selbst eine sehr kleine Software. Siehe Signatur. Das Projekt existiert seit etwa 8 Jahren. Nehmen wir Gnome. Das Gnome in Woody ist laut der Website vom April 2001. Zu diesem Zeitpunkt war "meine" Software ein Visual-Basic-Programm unter Windows, und ich beschloss, Billys Krempel in die Tonne zu treten und mir Linux anzugucken. Heute ist "meine" Software ein freies Projekt auf Sourceforge. Der Basic-Code ist migriert nach perl. Anstelle einer langen Textdatei mit Daten wird mysql als Datenbank genutzt. Windows-interne Grafikroutinen sind durch ImageMagick ersetzt, und die grafische Bedienung erfolgt �ber den Apache in php anstelle einer "normalen" Applikation. Es gibt ein "configure", ein Makefile - eben alles, wie es sein sollte. Manchmal bekomme ich heute noch eine Mail von einem Windows-User, der die alte Version benutzt: Dies oder jenes ginge nicht. Ob ich helfen k�nne? Ich bedaure: Ich kann nicht. Es mag erschwerend hinzukommen, da� ich gar kein Windows mehr besitze, aber auch ohne das: Ich kann mich kaum noch an den Kram erinnern, wie er damals war. Weder habe ich �berhaupt noch die Sourcen auf der Platte, noch �berhaupt das grobe Konzept im Kopf. Seit damals hat sich so derma�en viel ver�ndert... das ist wie das Programm eines Fremden. Um zu deinem Text zur�ckzukommen: Was hat das mit "unter den Teppich kehren" zu tun? Oder "mit Features blenden"? Fast jeder Entwickler arbeitet naturgem�� mit dem "daily CVS" seiner eigenen Software und macht irgendwann einen Schnitt. Immerhin bezahlt ihn keiner f�r was anderes. Und es sind die Entwickler, die ihr Programm am Besten kennen und meist eine korrekte Entscheidung treffen, wenn sie eine Version f�r "stable" erkl�ren. Ob das dir nun gef�llt oder nicht. Die Welt dreht sich weiter. Um zu meiner Schriftenverwaltungssoftware zur�ckzukommen: Als ich angefangen habe, da� ganz auf Linux zu portieren, kam man kaum 100 Previews weit, bis irgend ein Teil des Ganzen gegen die Wand fuhr. Weil freetype damals nicht gut lief, ImageMagick nicht sehr stabil und ghostscript sehr zickig. Heutzutage kann ich, unter sid, �ber 300.000 Fonts in einem Rutsch durch mit Previews versehen ohne einen einzigen Crash. Die Entwickler der Tools haben �ber die Jahre sehr gute Arbeit geleistet, die in Woody einfach fehlt. Man k�nnte jahrelang nichts anderes tun als Bugreports zu schreiben, die in der Summe unl�sbar w�ren. Oder man nimmt die neueste Version. Eine Kritik sollte nach M�glichkeit einen L�sungsvorschlag beinhalten: Forkt Debian. Debian ist zu gro�. F�r die meisten Anwender besteht Debian aus Software, die sie zu 90% nicht brauchen. Nur eben sind es bei jedem Nutzer ANDERE 90%. Ubuntu ist ein tolles Debian f�r den Desktop. Allein von der Philosophie ist es aber kein sinnvolles Server-OS. Ich meine, hey, es fragt beim Aufspielen nicht mal, welchen MTA ich drauf haben will und nimmt erstmal postfix. Die Philosophie ist gar nicht so falsch: der lokale MTA ist dem Desktopuser ziemlich egal. Der braucht den sowieso nur, um Systemmails zuzustellen, die er nicht liest. Der Desktop-User will Gnome $BRANDNEW plus Zubeh�r, und darauf scheint Ubuntu sich sehr gut zu konzentrieren. Was mir fehlt, ist ein Server-Gegenst�ck zu Ubuntu. Ein Projekt, da� von sich aus klipp und klar sagt, da� es einmal im Jahr released. Mit Paketen wie Apache2, exim4-heavy, shorewall, php4 (wohlm�glich gar php5, aber das ist selbst mir zu neu) und definitiv OHNE Gnome, Mozilla, KDE, ... ich w�rde sogar so weit gehen: F�r einige Tools braucht man die x11-libs wegen der Grafikformate, aber abgesehen von denen: Auch kein X11. So eine Konstruktion k�nnte man dann gerne freezen und j�hrlich ein Feature-Update machen. Die Arbeit sollte nach sid zur�ckfliessen. Und dann d�rfte Debian das "Komplettpaket" so selten releasen, wie es will. Nat�rlich g�be es theoretisch das Problem der �berschneidungen: Wie gesagt br�uchte Debian-Server eine xlib, und Debian-Desktop nat�rlich ebenfalls (dort inklusive eines kompletten X11). Also m�sste man aufpassen, dass hier nicht zwei Projekte den gleichen Upstream in verschiedene Richtungen implementiert. Das ist aber m.E. ein theoretisches Problem, erfahrungsgem�� sind es sowieso die gleichen Personen, die in mehreren Projekten mitarbeiten. Oder Debian-Server kompiliert das X.org von Debian-Desktop mit 'nem kleineren "configure". Debian als ganzes ist einfach nicht mehr technisch handlebar. Ganz offensichtlich wird es bei jedem Release schwieriger, das gro�e Ganze zu konsolidieren. Dass dabei ganz, ganz wichtige Sachen unter den Tisch fallen wie X.org oder AMD64 halte ich dann f�r ein echtes Problem. Um das mal hochzurechnen: Woody ist vom Juli 2002. (http://www.debian.org/News/2002/20020719) Wir wissen nicht, wann Sarge kommt - das jetzige Alter von Woody ist �ber zweieinhalb Jahre, wenn wir mal sch�tzen, da� Woody knapp 3 Jahre alt werden wird und daraus hochrechnen - dann heisst das, bis zum Juli 2008 wird Debian kein X.org und kein AMD64 Support haben. Nicht in Sarge. Zu diesem Zeitpunk werde ich vermutlich meinen jetzigen AMD64 bereits durch ein Folge-Ger�t ersetzt haben und aufgrund der dann erh�ltlichen Grafikkarten auf eine Non-Stable Distri angewiesen sein (oder Backports). Gleichzeitig tut Debian ganz hervorragend seine Arbeit auf meinen mipsel-basierten Cobalt-Qube2 (vor Jahren eingestellt) und auf meinem PowerPC-basierten Apple Macintosh 7200 Router (schon fast gar nicht mehr bekannt, da� Apple mal graue K�sten gebaut hat...). Ist das nicht irgendwie irrwitzig? Gru�, Ratti -- -o) fontlinge | Fontmanagement for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
