wulfman hat geschrieben:erm solo, warum genau hast du etwas an debian "vorbeikompiliert"? normalerweise schwören admins auf die woody-pakete: nur weil die versionsnummer niedrig ist, heißt das noch lange nicht, dass die pakete auf altem stand sind: patches werden immer eingespielt!
Ups, da liegt aber ein ziemliches Missverständnis vor: Ausschließlich sicherheitsrelevante Patches werden in Stable integriert. Tatsache ist denn auch, dass woody Mysql-3.23 enthält, Apache in irgendeiner 1.3er Version, PHP als 4.1.2 und Cyrus in in einer 1er Version.
und für was braucht man topaktuelle php/apache-pakete?
altes mysql? wo liegt das problem?
Gegenfrage: Du behauptest ernsthaft, 3 Jahre Entwicklung an MySQL, Apache und PHP hätten keine wesentlichen Fortschritte gebracht, weswegen es sich lohnen könnte, aktuelle Versonen einzusetzen? Wohl kaum, oder?
Trotzdem mal ein paar Beispiele aus meiner "PCPf-Admin-Praxis":
ApacheDa Apache 1.3 nicht mehr weiterentwickelt wird, WebDAV dafür nur als externes Modul erhältlich ist, die Konfiguration von Apache2 etwas anders ist, und ich mich eh neu eingearbeitet habe, habe ich mich entschlossen, gleich Apache2 einzusetzen. Das erspart uns einen späteren Umstieg und doppelten Einarbeitungsaufwand meinerseits.
PHPHast du mal ein Changelog auch nur eines kleinen php-Updates auf der zweiten Nachkommastelle gelesen? Da werden jedesmal dutzende Fehler behoben. Das woody-PHP enthält mindestens einige hundert Fehler (wenn nicht gar tausende), die das aktuelle 4.3.4 nicht mehr enthält. Ganz konkret zeigte sich das z.B bei uns in den gzip-Problemen des Forums, die nach einem PHP-Update einfach verschwanden. Ich kenne mich mit den Details von PHP allerdings überhaupt nicht aus. Chellie würde da wahrscheinlich noch mehr einfallen, weshalb es sich bei PHP auf alle Fälle lohnt, die aktuelle Stable-Version einzusetzen.
MySQLDie 3er Serie wird ebenfalls nicht mehr weiterentwickelt. Da MySQL-AB selbst empfiehlt, bei allen Neuinstallationen die 4er Reihe zu verwenden, die 4er Version viele neue Funktionen enthält (es braucht z.B. nur das nächste phpBB oder auch nur irgendein Mod desselben diese Funktionen zu benutzen, schon wären wir zum update gezwungen) und der Hersteller sogar selbst optimierte Binaries bereitstellt, seh ich keinen Grund, die nicht zu nehmen. Dagegen spricht ja nur der lahme Releasezyklus von Debian. Das allein kanns ja wohl nicht sein. Würde mich ja auch nicht weiter stören, wenn ich mit einem einfachen Befehl die mysql-Dependencies auf "erfüllt" setzen könnte, damit sich die ganzen mysql-abhängigen Debian-Pakete nicht beschweren - aber nein, apt-get weiß ja alles besser als ich.
Cyrus IMAPDa die 1er Reihe noch nicht die komplette ACL-Funktionalität beherrscht, wäre der PCPf-Mail-Server mit seinen Shared Folders, so wie er jetzt läuft, nicht machbar gewesen. Auch das sichere Authentifizieren der SMTP-Zugriffe via SASL ist mit den Woody-Paketen noch nicht möglich. Für libSASL und Cyrus-2.x gabs ausnahmsweise sogar mal Backports. Bis ich die aber mal gefunden hatte, die liegen nämlich im privaten Homebereich des Cyrus-Maintainers ...und selbst dann kam noch der schon beschriebene Mist mit MySQL. Die Mailaccounts werden nämlich jetzt per Webfrontend in einer Datenbank verwaltet, was sehr komfortabel funktioniert und auch die richtige Entscheidung war angesichts des Kuddelmuddel bei der Einrichtung der Passwörter usw. Allerdings musste Postfix und PAM (das benutzt Cyrus zum Authentifizieren) auch erstmal dazu gebracht werden, die DB zu benutzen.
Freetype, ImagemagickDamit Typo3 bestmöglich funktioniert, müssen die in einer ganz bestimmten Version installiert sein.
duplicityDas Backup-Tool, das täglich unser Hab und Gut auf den Server unseres Backup-Kumpels sichert, erschien erst nach woody. Ein anderes (erprobteres) Tool, das direkt von einem gpg-verschlüsselten Backup-Datenstand aus, inkrementell die neuen täglichen Backups erstellen kann, hab ich nicht gefunden. Es war als testing-Paket bereits in Debian drin, aber wegen diesem kleinen Tool wollte ich nicht komplett auf Testing umsteigen - daher meine Erfahrungen mit der Integration eines einzigen Testing-Pakets in ein...s.o. Leider enthielt es dann noch einen Bug, der gemeinsam mit dem sehr netten Autor des Tools aber schnell gefunden war. Die darauffolgende Version kam nicht mehr als Debian-Paket, also wieder handkompilieren.
rsshDie eingeschränkte Shell, mit der normale User auf ihre Accounts zugreifen (sie erlaubt nur sftp-Transfers, aber keine Kommandozeile) funktionierte aus dem Debian-Paket herausinstalliert nicht im chroot-Modus. Der ist aber wichtig, damit nicht jeder, der einen Account auf dem Server hat, im gesamten Filetree rumspazieren kann. Also das Source-Paket geholt, kompiliert und es funktionierte. Interessehalber hab ich noch nach dem Fehler gesucht: Es lag an einem fehlende suid-Bit an einer der Dateien, die das Debian-Paket installierte, das Makefile des Source-Pakets setzte dieses korrekt.
Mehr fällt mir erstmal nicht ein. Einige Punkte mögen meinetwegen auch ungerechtfertigt sein, es ändert aber nichts daran, dass mir Debian ständig in die Quere kam, wenn ich etwas anderes als seine Pakete benutzen wollte. Das kann in einer "Profi-Distri" einfach nicht sein. Und anstatt dieses Problem endlich anzuerkennen, reagieren die Debian-Typen immer nur mit diesem "Ja, warum willst du denn auch nicht unser großartiges [3 Jahre altes] Paket benutzen?" Das nenne ich Ignoranz.
ich habe die live-cds, nur starte ich mit stage 1.
Kannst du gerne tun, nur dann beschwer dich nicht bei Gentoo für die lange Zeit bis dein System mal drauf ist.
wenn du mit fertigen gentoo-paketen startest, kann nicht viel optimiert sein. ok, vielleicht 686 statt 386 & mmx enabled.
Also, das ist ja wohl völlig aus der Luft gegriffen. Mehr als auf einen Pentium3, einen Pentium4, einen AthlonXP und ein paar ältere Prozessoren optimieren kann gcc nunmal nicht. Und rate mal, wieviele LiveCDs es gibt: Richtig, eine für Pentium3, eine für ...! Was soll da schlecht optimiert sein? Wenn der eigene Prozessor nicht dabei ist, wie z.B. mein oller Athlon-TBird, dann muss man halt die 686er nehmen und auf den zweifelhaften Performance-Vorteil verzichten oder aber selbst kompilieren. Was ist daran falsch?
wie viel schneller soll gentoo sein? 5%, 10%? und wieviele stunden muss man dafür ins kompilieren investieren? imho lohnt es ohnehin nicht...
Stimmt, deswegen habe ich z.B. auch stage3 installiert. Überhaupt hab ich gentoo nicht aus Performance-Gründen gewählt. Du bist doch der, der unbedingt stage1 nehmen muss und sich dann über die Zeiten beschwert.
und für einen normalen desktop kannst du ja mandrake (red carpet?) nehmen.
Oder Fedora, oder Suse, so wie tafkag - völlig richtig! Für den Desktop muss es möglichst aktuell sein, wenns dann auch noch einfach zu installieren sein soll, fällt gentoo raus.
wenn du dir aber anschaust, was aus debian alles gemacht wird (knoppix, gnoppix) bzw. welche distributionen alle auf debian basieren - irgendwelche qualitäten müssen doch da sein?
Ja, dass es absolut frei ist - auch das Package-System. Und dass man auf das Package-System (als "Low-Level-System") von Debian alles mögliche aufsetzen kann, z.B ein Knoppix.
wenn du software als .deb paket kompilierst und per dpkg einbindest, wird dann die abhängigkeit erfüllt oder nicht?
Nein, ich glaube nicht. Das ist schließlich auch der normale Weg, einen eigenen Kernel einzubinden ohne dass das Einfluss auf irgendwelche Abhängigkeiten hätte. Man müsste das .deb dann schon so gestalten, dass es sich genau wie das originale Paket verhält. Unabhängig davon kann das ja nicht Sinn und Zweck einer Distribution sein. Genau dann erschwert sie ja etwas, anstatt es zu vereinfachen.
diese frage kommt von jemandem, der oss in einem anderen thread eine gesellschaftliche bedeutung zugestanden hat...
Kommt drauf an, was man als frei definiert. Die OS-Szene definiert alles als frei, was der GPL unterliegt - ich definiere alles als frei, was ich mir kopieren kann, ohne in den Knast zu kommen.
Ob der Hersteller nun nicht nur das Programm/den Treiber, sondern auch den Source-Code freigegeben hat ist mir dabei egal - solange es funktioniert.
Ciao,
Doc SoLo
PS: @Mod: Hallo?
Bei meinen 2GB war es aber von vornherein klar, dass da eine andere Lösung her muss. Gottseidank ist es ein Kinderspiel, größere Sourcen von Hand einzuspielen: im ebuild nachgesehen, was genau gebraucht wird und wo das liegt, fix notiert, an der Uni alles auf den Mem-Stick gezogen, zu Hause unter /usr/portage/distfiles kopiert - fertig.
:wink: