[Fli4l_dev] Informationen zum Weekly-Tarball vom 13.6.2013 (r31115)

[Christoph Schulz]

Hallo!

Hans Bachner schrieb:

>> 64-Bit ist attraktiv, weil, nun ja, 64-Bit des Adressraums (und
>> diverser
>> Prozessorregister) genutzt werden können ;-) Wenn die OPT-Programme
>> nicht
>> rekompiliert werden, dann bleiben es 32-Bit-Programme. Wo ist da der
>> Nutzen?
> 
> Der Nutzen ist, dass bestehende Opt-Pakete weitergenutzt werden können.
> Es ist ja nicht so, dass alle aktiv betreut (und weiter entwickelt)
> werden.

Also dazu muss ich nun etwas anmerken: Wenn ein Paket nicht mehr aktiv 
betreut und nicht mehr weiter entwickelt wird, dann ist das (leider, leider) 
Pech, das kann aber nicht mittel- und langfristig die Weiterentwicklung der 
fli4l-Basis behindern. Wenn es demnächst (und ich nenne jetzt bewusst kein 
Datum, weil ich auch keines kenne!) mal fli4l für ARM-Plattformen gibt (z.B. 
Raspberry Pi oder BeagleBone oder was auch immer), dann kann man die nicht 
mehr gepflegten x86-OPTs mit Binärprogrammen auch alle vergessen. So ist das 
nun mal! Die *einzige* nachhaltige Möglichkeit ist dafür zu sorgen, dass 
irgendjemand das betreffende Paket pflegt und für neue Architekturen 
anpasst.

Oder anders (und drastischer) ausgedrückt: Nur weil die fli4l-Community zu 
faul ist, ein paar Programme durchs FBR zu jagen, wird fli4l doch nicht auf 
immer und ewig x86/32-only bleiben. Das Know-How ist in der Community da, 
sonst würde ich nicht regelmäßig z.B. mit Bernd Kuhls über das FBR 
diskutieren. Es ist auch von jeher immer möglich gewesen, hier in der NG 
oder in unserem #fli4l-IRC-Channel Fragen zu stellen, wenn man mit 
irgendetwas bei fli4l nicht weiterkommt.

Also: Wenn es irgendwo ein wichtiges, aber nicht mehr aktiv gepflegtes Paket 
gibt, dann kümmert euch als Community drum! Ihr schafft das schon! Und wir 
helfen entsprechend, falls es Probleme gibt.

Ich bin bei fli4l u.a. dazu angetreten, alte Zöpfe abzuschneiden und 
vorhandene Funktionalität zu vereinheitlichen. Deshalb bin ich auch ein 
Feind jeglicher Sonderlocken und überflüssiger Kompatibilitätsmaßnahmen. Das 
heißt nicht, dass so etwas nie in Frage kommt, aber wie ich in einem anderen 
Post schrieb: Ich könnte mir ein Kompatibilitäts-Paket mit 32-Bit-
Bibliotheken vorstellen. Das hat nur noch niemand zusammengestellt. Also: Es 
gibt viel zu tun, fangt schon mal an ;-)


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