Ja das geht schon in die Richtung aber das dann offline und entsprechend optimiert. Sicherlich könnte man dann auf Basis von Containern oder VMs die Systeme vorhalten. Sicherlich ein nicht unerheblicher Aufwand was die Entwicklung so einer Anwendung angeht, aber ganz sicher würden viele Entwickler das nutzen. Wäre der Bedarf nicht da, wäre ja der OpenSUSE Build Service ein Trauerspiel, die Praxis zeigt aber das Gegenteil.
Das OpenSUSE Build System ist OSS wie Suse selbst, also einem Betrieb auf dem eigenen Rechner steht nichts entgegen. Aber ich persönlich hätte aber keine Lust ne ganze Build-Farm auf meinem Rechner zu betreiben, zum einen wegen des Platzes den es unnötig nimmt und zum anderen weils langsam ist. Letztendlich baut man damit dann auch nur die Pakete, das Repository muss man dann noch gesondert betreiben… das kann ich entspannter bei OpenSUSE Build direkt haben.
Snappy löst übrigens aber auch noch ein paar andere Probleme für 3th Party Entwickler wie z.b. die Integration von Apparmor, Cgroups, Kernel Namespaces und damit einen Shift des Vertrauens bis zu einem gewissen Grad vom Entwickler zum Betriebssystemhersteller.
Ja das geht schon in die Richtung aber das dann offline und entsprechend optimiert. Sicherlich könnte man dann auf Basis von Containern oder VMs die Systeme vorhalten. Sicherlich ein nicht unerheblicher Aufwand was die Entwicklung so einer Anwendung angeht, aber ganz sicher würden viele Entwickler das nutzen. Wäre der Bedarf nicht da, wäre ja der OpenSUSE Build Service ein Trauerspiel, die Praxis zeigt aber das Gegenteil.
Das OpenSUSE Build System ist OSS wie Suse selbst, also einem Betrieb auf dem eigenen Rechner steht nichts entgegen. Aber ich persönlich hätte aber keine Lust ne ganze Build-Farm auf meinem Rechner zu betreiben, zum einen wegen des Platzes den es unnötig nimmt und zum anderen weils langsam ist. Letztendlich baut man damit dann auch nur die Pakete, das Repository muss man dann noch gesondert betreiben… das kann ich entspannter bei OpenSUSE Build direkt haben.
Snappy löst übrigens aber auch noch ein paar andere Probleme für 3th Party Entwickler wie z.b. die Integration von Apparmor, Cgroups, Kernel Namespaces und damit einen Shift des Vertrauens bis zu einem gewissen Grad vom Entwickler zum Betriebssystemhersteller.