Community-Firmware für den TXT

[ski7777]

Die Startskripte liegen schon immer in der CFW, bloß bekam ich dann die Fehlermeldung, dass ich zum Beispiel auf /rom/run/txtcontrol-service nicht schreiben kann, dass es ro ist. Siehe fstab: https://github.com/ftCommunity/ftcommun ... c/fstab#L8 Diese Statusdateien machen m.E. auf dem ROM auch keinen Sinn.

Raphael

[ski7777]

In letzter Zeit passiert leider nichts rund um die CFW. Ich bin gerade dabei die CFW tauglich für Buildroot 2018.11 zu machen, was leider etwas komplizierter ist, da der Kernel 4.1 einfach sehr alt ist.
Können wir nicht Mal wieder etwas Schwung in die Bude bringen?
Vielleicht schafft es ja jemand einen aktuellen Kernel in die CFW einzubauen. Am Sicherheitssystem müssten wir auch noch etwas arbeiten und die Update-App könnte man auch einpflegen.

Gruß
Raphael

[ski7777]

Nachdem wir jetzt die CFW auf einem sehr aktuellen Stand haben, werde ich in den nächsten Tagen/Wochen die Touchscreen-Kalibrierung angehen und später auch noch die Netzwerkkonfiguration des TXT komplett neu machen. Folgende Features möchte ich umsetzen:

• Netwerk:
  • WLAN:
    • Mehrere WLAN-Netzwerke verwalten
    • versteckte SSIDs
    • 802.1X, vielleicht sogar mit Zertifikaten. Dafür brauche ich aber noch eine Testumgebung, da ich hier zu Hause nur mit 802.1X/PEAP arbeite
    • IP-Konfiguration pro Netzwerk
  • USB-Netzwerk:
    • Konfiguration der IP für eine USB-Netzwerkkarte (muss ich auch noch besorgen. Hier könnte ich vielleicht einfach die Grundumgebung bereitstellen und jemand von euch hilft mir das fertig umzusetzen.
    • Konfiguration des RNDIS. Vielleicht will man für zwei TXTs die Range ändern. Können wir vielleicht die Knobloch IDs nutzen? Das wäre für die Windows-Anwender einfacher.
      (insgesamt möchte ich hier etwa die gleichen Funktionen wie Android unterstützen)
    • Ein Daisy-Chain Mode. Hier würde ich den eingehenden und ausgehenden RNDIS einfach bridgen. Für die Adressierung lasse ich mir noch etwas einfallen. Aber das wird wohl mit einem DHCP Server und n DHCP-Clients funktionieren. Zusätzlich wird der "abgehende Ast" erst freigeschaltet, wenn man selbst eine IP hat. So hat man dann fortlaufende IPs. Das sollte gehen. @Torsten: Du hast doch so viele TXTs. Vielleicht kannst du mir dann beim Testen helfen oder falls verfügbar ca. 2 TXTs bereitstellen.
• Ein shutdown Menü. Beim Drücken des Power-Buttons für mehr als 2 Sekunden soll sich ein Popup öffnen und die App soll sich nicht schließen. Hier kann man verschiedene Funktionen abrufen:
  • Herunterfahren
  • Reboot
  • Screenshot und Protokoll der App speichern (kann man dann irgendwie laden und an den Entwickler schicken)
  • Einstellungen öffnen
  • Vielleicht etwas mit Multitasking. Vielleicht könnte man eine App in den Hintergrund verschieben und von dort aus wieder öffnen. (Ich weiß, der TXT ist lahm, aber ein Versuch wäre es wert und notfalls kann man das für die Masse auch wieder deaktivieren und erst auf den TXTX bringen)
    Aktuell kann man doch theoretisch schon mehrere Apps parallel ausführen? Die Fenster werden doch einfach nur gestapelt? Wir bräuchten einen Weg dieses Stapeln aktiv beeinflussen zu könenn.
• Allgemein bin ich mit dem aktuellen Design unzufrieden. Ein modernes Layout mit Material Design wäre schön. Zusätzlich würde ich gerne diese ganzen EInstellungsmöglichkeiten in einer App zusammenfassen.
• Eine API für Wake-On-RTC
• Eine API für den Autostart von Apps
• Plugins für alle Apps. Hier müssen wir auf Sandboxing achten. Am besten mit entsprechenden Rechten ausführen und die Daten z.B. per stdout auslesen.
• Ein funktionierendes Sicherheitssystem! Unser Schutz mit PAM ist sehr unsicher! (näheres dazu schicke ich später per Mail) Ich würde gerne die Apps sandboxen. hierfür am besten für jede App einen eigenen Nutzer und Gruppe. Wenn eine App trotzdem auf eine andere App zugreifen will, muss sie das anfragen und der Nutzer muss dem aktiv zustimmen.

Diese Liste darf gerne, eher soll, weiter ergänz werden. Vielleicht könnten wir auch eine kleine Roadmap draus machen und auf GitHub stellen. Hier würde sich das Projects Feature anbieten.
Ich weiß, das ist sehr viel. Einiges ist vielleicht auch einfach Müll, bei anderen Sachen besteht sicher noch deutlich Verbesserungspotential. Hier bin ich für objektive Kritik sehr dankbar.

Gruß
Rapahel

[richard.kunze]

Hallo Raphael,

das sind fast alles generell gute Ideen, und ich finde es sehr schön dass Du so aktiv an der CFW weitermachst.

Allerdings denke ich, wir sollten als ersten (und auch gar nicht mal so kleinen) Schritt das einzige noch offene Ticket abschließen (z.B. indem Du den PR hier auf den aktuellen Stand anpasst) und dann eine Version 1.0 herausbringen.

Vielleicht kriegen wir das ja sogar bis Weihnachten hin - das wäre denke ich ein passender Abschluss für die ersten drei Jahre CFW-Entwicklung (ja, so lange machen wir das tatsächlich schon).

Parallel dazu können wir ja anfangen, die Wunschliste für weitere Versionen aufzustellen (und ja, das mit den "Projects" von Github zu organisieren finde ich eine gute Idee).

Ich pack auch noch schon mal was drauf, wenn auch eher etwas Organisatorisches:

• Umzug nach oder mindestens Spiegelung des Projekts auf Gitlab, um nicht von einem Anbieter abhängig zu sein
• Automatisierte Erstellung von Releases. Und zwar sowohl von Snapshots (bei jeder Änderung, die durch die - ebenfalls zu automatsierenden - minimalen Tests durchkommt), als auch "echte" Releases (wenn von einem Entwickler ein neues Versionstag eingespielt wird).

[richard.kunze]

Hallo Raphael,

das sind fast alles generell gute Ideen, und ich finde es sehr schön dass Du so aktiv an der CFW weitermachst.

Allerdings denke ich, wir sollten als ersten (und auch gar nicht mal so kleinen) Schritt das einzige noch offene Ticket abschließen (z.B. indem Du den PR hier auf den aktuellen Stand anpasst) und dann eine Version 1.0 herausbringen.

Vielleicht kriegen wir das ja sogar bis Weihnachten hin - das wäre denke ich ein passender Abschluss für die ersten drei Jahre CFW-Entwicklung (ja, so lange machen wir das tatsächlich schon).

Parallel dazu können wir ja anfangen, die Wunschliste für weitere Versionen aufzustellen (und ja, das mit den "Projects" von Github zu organisieren finde ich eine gute Idee).

Ich pack auch noch schon mal was drauf, wenn auch eher etwas Organisatorisches:

• Umzug nach oder mindestens Spiegelung des Projekts auf Gitlab, um nicht von einem Anbieter abhängig zu sein
• Automatisierte Erstellung von Releases. Und zwar sowohl von Snapshots (bei jeder Änderung, die durch die - ebenfalls zu automatsierenden - minimalen Tests durchkommt), als auch "echte" Releases (wenn von einem Entwickler ein neues Versionstag eingespielt wird).

PS: Das Shutdown-Menü ist keine gute Idee. Der Mechanismus für "Langer Knopfdruck fährt den TXT sauber runter" ist ziemlich tief unten im System eingehängt, d.h. der funktioniert auch, wenn irgendeine Anwendung das Display und/oder den Touchscreen so verwurstelt, dass da gar nichts mehr tut (das wäre für das Shutdown-Menü fatal). Und zu lange Zeit lassen können wir uns auch nicht: Wenn man mit dem Finger länger als etwa 20 Sekunden auf dem Ausschaltknopf bleibt, dann dreht der kleine Steuercontroller im TXT hart den Strom ab. D.h. wir müssen bis zu dem Zeitpunkt dann alles sauber runtergefahren und selbst den Strom abgeschaltet haben, sonst riskieren wir dass durch den harten Shutdown was kaputtgeht (ist zwar nicht sehr wahrscheinlich, kann aber unter blöden Umständen - z.B. wenn ein durchdrehender Prozess gerade wie wild auf de SD-Karte schreibt - durchaus passieren).

[ski7777]

Für das Projektmanagement auf github bräuchte ich Schreibrechte. Vielleicht könne wir uns generell darauf einigen, dass Änderungen (außer an der Doku) nur über PRs und dann Zustimmung von anderen übernommen werden.

https://github.com/ftCommunity/ftcommunity-TXT/pull/138 ist soweit aktuell und kann direkt gemergt werden. Wenn du den testen willst empfehle ich dir an der Systemversion etwas rumzuspielen, da sich die App auf snapshots anders verhält https://github.com/ftCommunity/ftcommun ... te.py#L454

PS: Das Shutdown-Menü ist keine gute Idee. Der Mechanismus für "Langer Knopfdruck fährt den TXT sauber runter" ist ziemlich tief unten im System eingehängt, d.h. der funktioniert auch, wenn irgendeine Anwendung das Display und/oder den Touchscreen so verwurstelt, dass da gar nichts mehr tut (das wäre für das Shutdown-Menü fatal). Und zu lange Zeit lassen können wir uns auch nicht: Wenn man mit dem Finger länger als etwa 20 Sekunden auf dem Ausschaltknopf bleibt, dann dreht der kleine Steuercontroller im TXT hart den Strom ab. D.h. wir müssen bis zu dem Zeitpunkt dann alles sauber runtergefahren und selbst den Strom abgeschaltet haben, sonst riskieren wir dass durch den harten Shutdown was kaputtgeht (ist zwar nicht sehr wahrscheinlich, kann aber unter blöden Umständen - z.B. wenn ein durchdrehender Prozess gerade wie wild auf de SD-Karte schreibt - durchaus passieren).

Ich kenne die Integration genau. Deshalb folgender Vorschlag:

• Drücken unter 2s: App schließen oder halt anderes verhalten definiert in der App
• 2s-5s: Popup
• >5s: Holzhammer: Herunterfahren

Gruß
Rapahel

[richard.kunze]

Für das Projektmanagement auf github bräuchte ich Schreibrechte.

Hast Du jetzt (geh bitte sorgsam damit um).

Vielleicht könne wir uns generell darauf einigen, dass Änderungen (außer an der Doku) nur über PRs und dann Zustimmung von anderen übernommen werden.

Ja, das ist eine gute Idee. Sowas in der Art kann man per "protected branches" sogar erzwingen, eventuell wäre das auch keine schlechte Idee.

https://github.com/ftCommunity/ftcommunity-TXT/pull/138 ist soweit aktuell und kann direkt gemergt werden.

Technisch gesehen ja, aber als ich den vor einer Weile mal überflogen habe sind mir da noch ein paar Punkte aufgefallen die mir nicht so gut gefallen haben. Und für einen ordentlichen Code-Review besteht der PR aus zu vielen Commits, die Inhaltlich zum Teil auch etwas Kraut und Rüben sind. Vorschlag: Du machst den PR 138 zu, übernimmst die Inhalte des Branchs in einen einzelnen Commit auf Basis des aktuellen "master", und macht dafür einen neuen PR auf. OK?

PS: Das Shutdown-Menü ist keine gute Idee.
(...)

Ich kenne die Integration genau. Deshalb folgender Vorschlag:

• Drücken unter 2s: App schließen oder halt anderes verhalten definiert in der App
• 2s-5s: Popup
• >5s: Holzhammer: Herunterfahren

Ja, so könnte das funktionieren. Ist aber definitiv ein Thema für nach 1.0

[ski7777]

Das mit dem PR: du kannst auf github direkt squashen. Das löst diese Probleme.

popup: logisch

[richard.kunze]

Das mit dem PR: du kannst auf github direkt squashen. Das löst diese Probleme.

Das kann ich aber nur, wenn ich den PR merge - und den Review will ich vorher machen.

Oder hab ich da irgendein Github-"Feature" übersehen, mit dem ich in deinem Branch rumwursteln darf?

PS: Aber ich schau mal ob ich den aktuellen PR reviewen kann. OK?

[ski7777]

Ja, du hast Schreibrechte auf mein Branch "Allow edits from maintainers"

[richard.kunze]

Ja, du hast Schreibrechte auf mein Branch "Allow edits from maintainers"

Ach so, OK. Aber das müsste ich dann per Force-Push da reinhauen, oder? Ist auch wieder nicht so toll...

[ski7777]

Stimmt auch wieder. Ich mache das entweder heute Abend spät oder morgen

[ski7777]

Ich habe meine Vorschläge jetzt Mal in issues umgesetzt.
Ich fordere euch wirklich ausdrücklich auf all diese Punkte kritisch zu begutachten, weitere Punkte vorzuschlagen, ...

Gruß
Raphael

[PHabermehl]

*Kopfschütteln*

Ich finde da jetzt nicht viel von dem wieder, was wir in Dreieich beschlossen haben. Im Gegenteil, das Thema "Powerbutton" war eigentlich schon abgelehnt, und die Roadmap to v1.0 hatten wir doch gefixt, ich erinnere mich, dass da jemand als allererstes mal das Thema "Audio" in trockene Tücher bringen wollte, wo bleibt das?

Dann sollten mal die Apps, die im Appstore verfügbar sind, auch wirklich funktionieren. Die ftdb-App tut bei mir gar nix, das ist kein Renomee für die cfw, wenn da Leichen im Appstore liegen.

Jetzt am Design der Oberfläche rumfummeln, halte ich für unsinnig.Auch möge man bei allen Änderungen Rückwirken auf das gesamte ft-Ökosystem berücksichtigen, dazu gehört auch der TX-Pi. Die Oberfläche ist funktional und zweckmäßig und immer noch dem Original weit überlegen.

Ich weiß nicht, wie groß der Benutzerkreis ist. Malware-Apps sehe ich nur als theoretisches Problem. Die müssten erstmal in den Appstore kommen, und dann kann man ggf. eine EINSTELLIGE Anzahl von Geräten infizieren, nun ja, man muss schon ein Superschurke sein, um sich dieser Aufgabe zu stellen und einen Sinn darin zu sehen.

Weiters bin ich doch immer sehr dafür, Aufgaben mit dem notwendigen Augenmaß anzugehen und zu schauen, was man jetzt braucht, was man gern hätte und was absoluter Unsinn ist. Die Ressourcen, insbesondere an Mitstreitern, sind doch begrenzt.

Sorry, da ich im Moment wenig Zeit habe, überhaupt etwas sinnvolles beizutragen, sollte ich mir Kritik lieber verkneifen, mein Gedanke ist aber, dass momentan eher behutsam geändert werden sollte, um nicht die wenigen existierenden Apps auch noch zu zertrümmern...

Aber immerhin tut sich ja 'was, das ist auch ganz schön!

Gruß
Peter

[ski7777]

Zu Audio hatte ich bereits auf der Convention bereits gesagt, dass ich keinen blassen Schimmer von C hab. Wenn mir jemand den Grundstein legt für eine ordentliche Lösung bin ich gerne bereit mitzuhelfen, aber alleine bekomme ich das nicht hin.
Das Thema Touchscreen habe ich hier gerade gelöst: https://github.com/ftCommunity/ftcommunity-TXT/pull/151

Gruß
Raphael

P.S.: @Esther: Ich hoffe, du liest hier und auf GitHub mit und verfolgst die Änderungen. Vielleicht kannst du das mit der Touchscreen-Kalibrierung entsprechend dokumentieren?

[EstherM]

Ich dokumentiere das gerne, aber dieses Jahr schaffe ich das nicht mehr.

[Bjoern]

Hallo,

ich nutze zwar die CFW (noch) nicht aber erfreue mich dennoch das hier gerade wieder sehr lebhaft diskutiert wird.

Nur scheint es mir hier ein Problem im Projekt Management bzw. dessen Umsetzung zu geben.

Ich gebe einfach mal wieder wie das auf mich wirkt.

Einer schreibt neue Ideen/Feature ins Forum für die Zukunft. Ein anderer erwähnt das man doch mal das bisherige endlich abschliessen sollte um zu einem Release zu kommen. Ein dritter sagt das manche Features der letzten Planung widersprechen.

Dazu kommen dann noch inhaltliche Diskussionen zu den in den Raum geworfenen Features. Ich halte Sicherheit auch für wichtig und die sollte von Anfang an drin sein. Andererseits ist die Frage was man hier anrichten kann und ob nicht ein dezenter Hinweis auf mögliche Probleme aktuell ausreichend sind. Ich gehe nicht davon aus das es tausende von Nutzern der cfw gibt.

Ich möchte hier jetzt nichts zerreden denn alleine so etwas wie die cfw auf die Beine zu stellen ist schon eine Leistung. Und bei der Realisierung kann man sicherlich viel lernen. Meine Linux Kenntnisse sind mehr oder weniger gleich Null.Ich verdiene meine Brötchen damit die Integration einer SW sicher zu stellen. Und deren Entwickler sind über mehrere Länder verteilt.
Hier nutzen wir Git und Jira.

Ihr scheint eine Roadmap in Git zu nutzen, nur sehe ich hier auf den ersten Blick keine geplanten Versionen. Gibt es so etwas dort nicht?
Mir ist auch noch so ganz klar wie diese Issues in Git funktionieren. Kann ich da immer nur comments abgeben?

Aus meinem Blickwinkel bedarf es einer Releaseplanung. Dort wird festgehalten welche Issues integriert werden. Die Issues selber werden diskutiert um was es geht, wie man es machen könnte und dann wird entschieden wie es gemacht wird. Und das wird dann so umgesetzt. Und während der Entscheidungsphase werden evtl. Probleme schon im Vorfeld diskutiert, wie z.B. ich brauche Support weil mein eigenes Wissen für dieses/jenes/welches nicht ausreicht.

Das ist dann alles für mich strukturiert und wird zum Ziel führen. Vielleicht aus eurem Blickwinkel etwas "oversized". Aber es hat strikte Prozesse und nur die Beachtung dieser Prozesse wird zum Ziel führen. Agile Entwicklung ist das Eine, aber die darf nicht im Chaos versinken. Und aus den Beiträgen lese ich ein wenig Chaos heraus. Auch aus so einer Projektarbeit heraus kann man viel mitnehmen.

Wie gesagt vielleicht sehe ich das auch alles falsch, vielleicht passt der eine oder andere Kommentar von mir auch sehr gut.

Ziel sollte es doch sein die jeweiligen Fähigkeiten der User zusammenzuführen. Das ist dann für mich gelebte Community. Und hier hat sicherlich jeder andere Fähigkeiten die sich nachhher sehr gut ergänzen.
Habe ich jetzt schon mal bei 2 Hardware Projekten erlebt und es macht durchaus Spaß so zusammen zu arbeiten.

Björn

[ski7777]

ich nutze zwar die CFW (noch) nicht aber erfreue mich dennoch das hier gerade wieder sehr lebhaft diskutiert wird.

Na dann, nichts wie ran

Nur scheint es mir hier ein Problem im Projekt Management bzw. dessen Umsetzung zu geben.

Die Ursachen dafür sind vielfältig. Ich hoffe, dass Mal alles geregelt bekommen.

Ein anderer erwähnt das man doch mal das bisherige endlich abschliessen sollte um zu einem Release zu kommen

Dass wie einige Baustellen haben, die Mal noch gefixt werden sollen ist klar. Meine Ideensammlung dient Mal wieder etwas Bewegung in die CFW zu bringen. Eine Altlast, die Touchscreen Kalibrierung habe ich gestern Abend umgesetzt.

Ein dritter sagt das manche Features der letzten Planung widersprechen.

Tatsächlich habe ich diese Ablehnung so nicht in Erinnerung, gleichzeitig spreche ich hier jeden an und nicht nur eine Kerntruppe von ein paar Leuten.

Dazu kommen dann noch inhaltliche Diskussionen zu den in den Raum geworfenen Features

Das ist genau das, was ich hier erwarte. Ohne Diskussion kann man ja die Themen gar nicht genau ausarbeiten.

Ich halte Sicherheit auch für wichtig und die sollte von Anfang an drin sein. Andererseits ist die Frage was man hier anrichten kann und ob nicht ein dezenter Hinweis auf mögliche Probleme aktuell ausreichend sind. Ich gehe nicht davon aus das es tausende von Nutzern der cfw gibt.

In einer internen Mail würde ich auch auf die geringe Nutzerzahl hingewiesen. Trotzdem ließe sich dieses Risiko stark minimieren, wenn wir allgemein die Sicherheitsarchitektur etwas überdenken. Dazu steht meine Idee schon hier in Thread und auf GitHub.

Ihr scheint eine Roadmap in Git zu nutzen, nur sehe ich hier auf den ersten Blick keine geplanten Versionen. Gibt es so etwas dort nicht?

Das ist etwas tricky. Es gibt aktuell eine Roadmap. Die dient der Visualisierung der aktuellen Aufgaben, Ideen, usw: https://github.com/ftCommunity/ftcommun ... projects/1
Dann kann man noch Milestones anlegen. Diese dienen der Release-Planung: https://github.com/ftCommunity/ftcommun ... milestones
Hier kann man festlegen, was bis zu welcher Version fertig sein soll.

Mir ist auch noch so ganz klar wie diese Issues in Git funktionieren. Kann ich da immer nur comments abgeben?

Die issues sind rein zum Kommentieren. Man kann die noch labeln und in der Roadmap in den Spalten einordnen, aber das kann man als normal Nutzer nicht.

Aus meinem Blickwinkel bedarf es einer Releaseplanung. Dort wird festgehalten welche Issues integriert werden. Die Issues selber werden diskutiert um was es geht, wie man es machen könnte und dann wird entschieden wie es gemacht wird. Und das wird dann so umgesetzt. Und während der Entscheidungsphase werden evtl. Probleme schon im Vorfeld diskutiert, wie z.B. ich brauche Support weil mein eigenes Wissen für dieses/jenes/welches nicht ausreicht.

Es wäre wirklich schön, wenn es so laufen würde. Ich habe jetzt sehr viele Denkanstöße gemacht. Einige davon kann ich umsetzen, andere nicht. Sei das wegen zu wenig Ressourcen (TXTs, Zeit, ...)

Das ist dann alles für mich strukturiert und wird zum Ziel führen. Vielleicht aus eurem Blickwinkel etwas "oversized". Aber es hat strikte Prozesse und nur die Beachtung dieser Prozesse wird zum Ziel führen. Agile Entwicklung ist das Eine, aber die darf nicht im Chaos versinken. Und aus den Beiträgen lese ich ein wenig Chaos heraus. Auch aus so einer Projektarbeit heraus kann man viel mitnehmen.

Ziel sollte es doch sein die jeweiligen Fähigkeiten der User zusammenzuführen. Das ist dann für mich gelebte Community. Und hier hat sicherlich jeder andere Fähigkeiten die sich nachhher sehr gut ergänzen.

Das mit dem Ergänzen müssen wir sicher teilweise noch üben. In der letzten Woche haben Richard und ich buildroot und den Kernel aktualisiert. Ich hätte das alleine nicht hinbekommen, da ich mich überhaupt nicht mit device trees auskenne, Richard da aber sehr gut drin ist. Helfen ist hier das a und o.

Gruß
Raphael

P.S. wir machen dass ja alle nur zum Spaß und in unserer Freizeit, aber trotzdem können wir sehr viel davon lernen. Manche der Features, die integriere, haben vielleicht für mich weniger Sinn, als für andere, aber ich versuche sie dennoch umzusetzen, um etwas dabei zu lernen. Beispielsweise werde ich bald Mal etwas an dem USB Daisy-Chain anfangen. Da lernt man sicher einiges zu Routing, UDP und protobuf (vielleicht etwas Overkill, aber Mal etwas neues)

[ski7777]

Alles weitere zum USB Problem hier: https://github.com/ftCommunity/ftcommun ... issues/152

[ski7777]

Frohes neues Jahr

Auf github sind einige ausstehende PRs.

Auf der Convention hatte ich mit Richard über eine Alternative für das I/O Management gesprochen. Konkret wäre ein publish/subscribe system interessant. Ich glaube, dass wen wir das in python und MQTT umsetzen, der overhead viel zu groß ist. Ich würde vorschlagen, dass in go umzusetzen. Alle Bibliotheken zur I/O Ansteuerung liegen aktuell in Python vor und können somit in go eingebunden werden. Nach und nach kann man die dann vielleicht in go umschreiben. Ich werde da Mal eine konkrete Idee ausarbeiten und im Laufe der nächsten Woche hier vorstellen. Schön wäre es, wenn wir in der 1.2 keinen direkten ftrobopy,.. Zugriff mehr haben.

Gruß
Raphael