Bei portsnap nichts Neues...
- Ersteller Elwood
- Erstellt am
Auf freebsd-ports@ gibt es dazu einen Thread. Das ist schon ein globales Problem. Ein offizielles Statement habe ich aber noch nicht gefunden. Geraten würde ich sagen, dass es irgendwie mit dem Übergang der alten Server-Infrastruktur zum FreeBSD-SDN zusammenhängt.
Äh nicht SDN stattdessen CDN. Mist 
Derzeit wird die ganze Infrastruktur - inklusive Mirrors - auf ein Content Distribution Network umgebaut. Das FreeBSD-Projekt selbst wird weltweit Masterserver bereitstellen (jeweils einen Cluster an der US-Westküste, an der US-Ostküste, in UK und ab nächstem Jahr auch im asiatischen Raum), die von allen Nutzern benutzt werden sollen. Die Tools (freebsd-update, portmaster, pkgng, etc) werden in Standardeinstellung auf das CDN zeigen. Innerhalb des CDN erfolgt die Lastverteilung automatisch, d.h. jede Verbindung wird einem geeigneten Server zugewiesen, ohne das der Nutzer etwas machen muss. Der Nutzer merkt auch nicht, wenn Teile des System ausfallen, erweitert werden, etc.
Die bisher genutzten, gesponserten Server werden aus dem freebsd.org-Namensraum entfernt werden. Es wird niemand daran gehindert, weiter FreeBSD-Mirror zu spielen, allerdings bitte unter eigenen Domain und ohne Recht auf Verweise seitens der offiziellen Dokumentation (Das steht allerdings meines Wissens noch nicht endgültig fest!). Das ist bitter für die Sponsoren, nach Jahren des Ärgers mit kaputten Servern, ist der Schritt notwendig geworden. Außerdem ist Rechenleistung und Bandbreite heute so günstig, dass man auch große Projekte selbst hosten kann. Zu guter Letzt hat man damit die Kontrolle über alles, man kann zum Beispiel Releases von einer Minute auf die nächste global freischalten und muss nicht darauf vertrauen, dass Heise das Release ankündigt, bevor es sich über die Spiegel verteilt hat.
Derzeit wird die ganze Infrastruktur - inklusive Mirrors - auf ein Content Distribution Network umgebaut. Das FreeBSD-Projekt selbst wird weltweit Masterserver bereitstellen (jeweils einen Cluster an der US-Westküste, an der US-Ostküste, in UK und ab nächstem Jahr auch im asiatischen Raum), die von allen Nutzern benutzt werden sollen. Die Tools (freebsd-update, portmaster, pkgng, etc) werden in Standardeinstellung auf das CDN zeigen. Innerhalb des CDN erfolgt die Lastverteilung automatisch, d.h. jede Verbindung wird einem geeigneten Server zugewiesen, ohne das der Nutzer etwas machen muss. Der Nutzer merkt auch nicht, wenn Teile des System ausfallen, erweitert werden, etc. Die bisher genutzten, gesponserten Server werden aus dem freebsd.org-Namensraum entfernt werden. Es wird niemand daran gehindert, weiter FreeBSD-Mirror zu spielen, allerdings bitte unter eigenen Domain und ohne Recht auf Verweise seitens der offiziellen Dokumentation (Das steht allerdings meines Wissens noch nicht endgültig fest!). Das ist bitter für die Sponsoren, nach Jahren des Ärgers mit kaputten Servern, ist der Schritt notwendig geworden. Außerdem ist Rechenleistung und Bandbreite heute so günstig, dass man auch große Projekte selbst hosten kann. Zu guter Letzt hat man damit die Kontrolle über alles, man kann zum Beispiel Releases von einer Minute auf die nächste global freischalten und muss nicht darauf vertrauen, dass Heise das Release ankündigt, bevor es sich über die Spiegel verteilt hat.
cvsup / csup sollte doch sowieso beginnend mit FreeBSD 9.1 endgültig auslaufen. Zuerst das Basissystem, im Winter dann die Ports. Man war von dem Plan nur abgewichen, da zu viel geheult wurde und hat die Sache für das Basisystem erst einmal auf 10.0 verschoben. Das es nun schneller gekommen ist, werden die Verantwortlichen eher als Glücksfall denn als Katastrophe sehen.
Die Sache war schon recht eklig implementiert. Der SVN->CVS-Exporter griff jeden SVN-Commit auf und synthetisierte daraus einen CVS-Commit. Da aber CVS nicht alle SVN-Operationen abbilden kann, ergaben sich für die SVN-Nutzung Einschränkungen. Zum Beispiel durfte man nicht eine Datei über eine andere verschieben, außer man wollte sich unglücklich machen. Jedes Mal, wenn der Exporter sich verfummelte, musste man manuell eingreifen und Commits rauspulen. Das war unschön.
Aber um Mal etwas zum Thema beizutragen: portsnap läuft nun wieder und generiert neue Snapshots.
Die Sache war schon recht eklig implementiert. Der SVN->CVS-Exporter griff jeden SVN-Commit auf und synthetisierte daraus einen CVS-Commit. Da aber CVS nicht alle SVN-Operationen abbilden kann, ergaben sich für die SVN-Nutzung Einschränkungen. Zum Beispiel durfte man nicht eine Datei über eine andere verschieben, außer man wollte sich unglücklich machen. Jedes Mal, wenn der Exporter sich verfummelte, musste man manuell eingreifen und Commits rauspulen. Das war unschön.
Aber um Mal etwas zum Thema beizutragen: portsnap läuft nun wieder und generiert neue Snapshots.