[Eisfair] NUT?

[Christoph Schulz]

X-Post & F'up to: spline.eisfair

Hallo!

Am Mon, 20 Jun 2016 07:54:36 +0200 schrieb Alexander Dahl:

> In buildroot ist nut ja enthalten und man könnte es für die nötigen
> binaries einfach aktivieren. Es hängt vermutlich hier daran, dass
> niemand bisher ein darauf basierendes opt gestrickt hat.

So ist es. Es gibt allerdings ein nut-Paket für eisfair-1, siehe http://
www.pack-eis.de/?p=nut.

Und das ist irgendwie eines der größeren Probleme: Es gibt manchmal für 
eine Funktion ein Paket für fli4l, manchmal ein Paket für eisfair(-1/-2/-
ng) und manchmal für beide (drei, vier) Systeme. Das ist aber weder 
konsistent noch logisch. Es hängt wohl hauptsächlich davon ab, ob der 
jeweilige Entwickler einen fli4l oder ein eisfair-System nutzt (oder 
beides).

Ich verstehe beispielsweise bis heute nicht, warum es so viele Low-Level-
Netzwerk-Pakete (etwa bridge, rp_pppoe, openvpn2, nur um einige zu 
nennen) für eisfair gibt (http://www.pack-eis.de/index.php?cat=net). 
Natürlich sind solche Funktionen langfristig viel besser beim fli4l 
aufgehoben, da dieser dafür spezialisiert ist. Und man würde voneinander 
profitieren: So würde man vielleicht endlich eine Zertifikatsverwaltung 
für den fli4l implementieren. Umgekehrt gibt es für den fli4l Pakete wie 
samba_lpd, die viel besser bei eisfair aufgehoben sind, weil dieser eben 
dafür spezialisiert ist. Das fli4l-Team aktualisiert samba etwa nur bei 
jedem Buildroot-Update (also ca. alle drei Monate) und nicht bei jeder 
bekannt gewordenen CVE.

Idealerweise wären die Paketsysteme so ausgelegt, dass der Entwickler nur 
einmal Arbeit hineinstecken müsste und gleich Pakete für fli4l _und_ 
eisfair herauspurzeln würden. Das wäre technisch sicherlich machbar, da 
wir inzwischen einen Haufen Werkzeuge haben, die dabei unterstützen 
könnten (allen voran unser CI-System Jenkins). Die Frage ist, ob das auch 
gewollt ist. Ich persönlich favorisiere eine Aufteilung der Kompetenzen 
in zwei Projekte, höre aber immer wieder Totschlagargumente in Hinblick 
auf höheren Stromverbrauch und somit höhere Stromkosten bei der Nutzung 
von zwei Systemen. Dagegen kann man kaum argumentieren. Außerdem kann es 
ja nützlich sein, ein "vollwertiges" Paket bei dem jeweils besser 
passenden Projekt zu haben und ein "abgespecktes" bei dem anderen 
Projekt, weil das dem jeweiligen Nutzerkreis ausreicht. Typischerweise 
sammeln sich jedoch nach und nach die Feature-Anfragen ("beim anderen 
Projekt geht das doch auch"), so dass der Unterschied irgendwann nicht 
mehr so groß ist, falls man den Feature-Wildwuchs nicht von Anfang an 
rigoros und konsequent eindämmt.

Meinungen?


Viele Grüße,
-- 
Christoph Schulz
[fli4l-Team]