Entwicklungsimage: LoxBerry 0.3.0 Saruman

[Prof.Mobilux]

Hallo zusammen,

ich habe in den letzten Tagen ein neues Image für den Entwicklungszweig 0.3.0 zusammengestellt. Das Image kann hier heruntergeladen werden:

https://download.loxberry.de/testing/images/rasppi/

Das Image basiert auf dem aktuellen Rasbian Stretch Lite vom 2017-09-07.

ACHTUNG! Dieses Image ist nicht für den produktiven Einsatz geeignet. Nicht einmal um es auszuprobieren. Vieles funktioniert noch nicht und vieles wird umgebaut werden. Es ist einzig und allein für LoxBerry-Entwickler gedacht, die am Basissystem arbeiten und den LoxBerry permanent per GIT aktuell halten.

Auch Plugin-Entwickler sollten aktuell das Image noch nicht verwenden, da auch die Pluginschnittstelle komplett überarbeitet wird (alte Plugins bleiben kompatibel), sodass es hier zu permanenten Änderungen kommen wird.

[jodelkoenig]

Top. Ich finde Loxberry ja eine extrem gelungene Kiste !!!

Das Thema Virtualisierung bekommt mit Hausautomationen ja eine neue, relevante Bedeutung für Heimanwender. Ich habe mich Anfang des Jahres von allen Raspberrys (5) verabschiedet und virtualisiere alles nur noch. Wäre schön, wenn es einen Standardweg gäbe, mit dem man Loxberry auch auf x86-Virtualisierungen laufen lassen kann.

Plant Ihr hier sowas wie Installationsscripts für Virtualisierer? Wäre super.

[Benjamin Jobst]

Hui, Saruman gleich =) Heb dir noch ein paar große Namen für die "erwachsenen" Versionen auf, sonst heißen die am Ende Peregrin ;-)
Ich liebäugle auch damit, Loxberry in naher Zukunft auf eine geplante NAS zu verschieben, ganz glücklich bin ich mit der Stabilität der SD-Karten im Raspi nicht...

[hismastersvoice]

Ich bin genau kein Freud von Visualisierung von Rechnern...
Warum?

Systeme
Es gibt x verschiede Systeme Docker / VM / Virtuozzo...
Dazu noch unterschiedliche Versionsstände, also 100derte Unbekannte.
Für jemanden wie uns die alle Projekte nebenbei machen kann der Aufwand nicht beziffert werden der daraus entsteht.

Ich sehe allein wie schwer es ist wenn jemand beim MusicServer4Lox eigene Hardware nutzt die ich nicht kenne oder testen kann.
Support wollen auch alle haben, das wird dann nahezu unmöglich da es zwar funktionieren müsste aber es eben nicht immer tut.

Ausfallsicherheit
Geht an dem Gerät etwas kaputt steht alles.

Preis / Stromverbrauch
Ich habe bei einigen hier schon gelesen was für Maschinen sie für xx Visualisierungen nuntzen
Erstens sind diese Kisten sehr teuer und zweitens keine Stromsparer.

Ich habe 1 Server für NAS/Video/Email / 1 für den MusikServer und 2 Raspis mit Loxberry
Energieverbrauch zusammen 9 + 7 + 4 = 20W / je Tag = 304W
Wobei die ersten beiden nur laufen wenn wirklich jemand zu im Haus ist bzw. wenn ich von außen per VPN drin bin. Also max. 12-13 Stunden.
Die Loxberrys müssen immer laufen da sie Aufgaben übernehmen die immer benötigt werden.
Die meisten von den Visu-Rechnern brauchen ähnlich viel und müssen 24/7 laufen, bzw. dürften nur 13W verbrauchen um mit meiner Konstellation gleich zu sein.


Erweiterungen
Im Augenblick werden Plugins für Homematic / 1Wire / ModBus usw. geschrieben, und es werden sicher auch noch welche folgen.
Diese benötigen die GPIO Pins des Raspis, spätestens dann braucht man eh einen Rasi.


Die Stärke des Loxberry...
...ist es das er auf einer Platform läuft die immer 100% kompatibel ist von Raspi 1-3. Hoffentlich auch 4,5,6...
Genau das macht das System so stabil und einfach zu nutzen.

Wenn jemand das ganze virtualisieren will, kann er das ja, aber das es fertige Images gibt halte ich für ein Projekt das in der Freizeit entsteht einfach für zu viel.
Ein paar User haben sich ja schon die Mühe gemacht und die Images online gestellt, vielleicht machen sie das ja auch in Zukunft.

Das ist aber nur meine bescheidene Meinung zu dem Thema.

[jodelkoenig]

Verständlich. So habe ich es auch gemacht, als ich mit 1 Raspberry ausgekommen bin. Zuletzt hatte ich 5 und bin nach 2x Netzteil und 3x SD-Karten Havarien auf eine zentrale Verwaltung umgestiegen. Am Ende ist beides möglich. Am Ende haben beide Vor- und Nachteile.

Ich würde mich freuen, wenn die Architektur von Loxberry zukünftig ggf. auch das Installieren auf ein Standard-Linux a la Debian/Ubuntu möglich macht

[Christian Fenzl]

Die Architektur für Debian auf x86 ist jetzt schon gegeben.
Wenn die (dokumentierten!) Prozeduren, die Michael jetzt schon für die Erstellung des Rasp-Images durchführt, weiterhin jemand auf x86/64 durchführt, wird alles passen.

[hismastersvoice]

Christian Fenzl
Ja aber ihr vergesst dabei eines...
...viele Plugins funktionieren dann nicht.
Sobald Pakete dabei sind die für Raspi compiled sind.
Das würde wieder bedeuten das man das Plugin für mehr als ein System bauen testen muss.

[ckerfurt]

Hallo zusammen,

ich habe in den letzten Tagen ein neues Image für den Entwicklungszweig 0.3.0 zusammengestellt. Das Image kann hier heruntergeladen werden:

https://download.loxberry.de/testing/images/rasppi/

Das Image basiert auf dem aktuellen Rasbian Stretch Lite vom 2017-09-07.

ACHTUNG! Dieses Image ist nicht für den produktiven Einsatz geeignet. Nicht einmal um es auszuprobieren. Vieles funktioniert noch nicht und vieles wird umgebaut werden. Es ist einzig und allein für LoxBerry-Entwickler gedacht, die am Basissystem arbeiten und den LoxBerry permanent per GIT aktuell halten.

Auch Plugin-Entwickler sollten aktuell das Image noch nicht verwenden, da auch die Pluginschnittstelle komplett überarbeitet wird (alte Plugins bleiben kompatibel), sodass es hier zu permanenten Änderungen kommen wird.

Top! Danke für die Arbeit.

[svethi]

Genauso ist es. Der LoxBERRY heißt nicht dur Zufall LoxBERRY er ist angelehnt an den RaspBERRY. Er ist auf dessen Hardware entwickelt und ist mit den für den Raspberry (ARM) compilierten Modulen etc. getestet. Wie hismastersvoice ebenso sagte, benutzen Plugins teilweise die Hardware (z.B. GPIO). Wird der Loxberry nun auch offiziell für als VM-Image angeboten, sehe ich schon die Diskussionen wie man entsprechende Plugins dort nutzt. Die Plugin-Programmierer müssten dann auch noch prüfen auf was für einem System das Plugin läuft. Es ist so schon schwer Programmierer zu finden. Die Wunschliste wird immer länger. Eigentlich wollten wir den Loxberry dahingehend verbessern, dass die Pluginentwicklung einfachere wird. Fängt man jetzt auch noch mit solchen Dingen an und der Entwickler sich auf nichts mehr verlassen kann, wird die Hemmschwelle für die Pluginprogrammierung viel zu groß.
@Prof.Mobilix hat einmal ganz klar gesagt, dass virtuelle Machinen nicht unterstützt werden und keinerlei Support darüber geleistet wird. Ich kann mir nicht vorstellen, dass er davon auf einmal abrücken möchte

[Christian Fenzl]

Eine Kleinigkeit werden wir machen:
Wir nehmen ins Image ein einfaches File auf, sowas wie is_raspbian.cfg (leere Datei).
Dieses File darf nur ins Original-Image und kann vom Plugin-Setup abgeprüft werden.
So kann man gleich vorweg die Plugin-Installation abfangen oder im Setup entscheiden, was zu tun ist.
Dann ist es dem Plugin-Entwickler überlassen, ob und was er damit macht.

[hismastersvoice]

Eine Kleinigkeit werden wir machen:
Wir nehmen ins Image ein einfaches File auf, sowas wie is_raspbian.cfg (leere Datei).
Dieses File darf nur ins Original-Image und kann vom Plugin-Setup abgeprüft werden.
So kann man gleich vorweg die Plugin-Installation abfangen oder im Setup entscheiden, was zu tun ist.
Dann ist es dem Plugin-Entwickler überlassen, ob und was er damit macht.

Halte das ganze für überflüssig...
Warum muss ein Raspberry visualisiert oder auf X86 laufen gelassen werden?
Stromverbrauch... Nein, ganz im Gegenteil
Leitung... Nein (zumindest Raspi 3)
Platz... Nein

Wenn jemand die 1,5W zu viel sind dann sollte er lieber ganz auf ein Smarthome verzichten

Bin da ganz bei svethi, der Name sagt es schon.

Wenn dann ein Plugin nicht dafür gemacht ist, kommen trotzdem die (An)Fragen das kann ich schon garantieren.
Apple wird auch keine Visu anbieten damit man iOS auf einem Samsung Galaxy laufen lassen kann, und das hat seine Gründe.

Warum hier eine "Wir wollen es allen recht machen" Mentalität herrscht kann ich nicht nachvollzeihen.
Je größer der Aufwand wird Software zu schreiben und zu Pflegen je größer die Barriere das jemand überhaupt damit anfängt.

[Christian Fenzl]

Eine Wir-wollen...-Mentalität ist das nicht. Der Aufwand meines Vorschlags sind 2 Minuten. Mehr würde ich für den Core nicht machen.

Fürs VM-Image erstellen gibt‘s schon welche, die sich die Zeit genommen haben und hoffentlich wieder nehmen, Test und Unterstützung sehe ich nicht bei den Core-Entwicklern.
Im Forum müssen sich Fragende öfter die erste Antwort, „Bist du auf Raspberry?“, gefallen lassen, wenn sie‘s nicht gleich mitgeben.
Wenn ein Plugin-Entwickler explizit auch für andere Plattformen unterstützt, ist das ok, aber den Core würde ich dafür jetzt nicht anpassen.

[Prof.Mobilux]

Hallo zusammen,

von mir wird es kein Image für eine Virtualisierung geben. Und auch nicht für andere Einplatinenrechner. Der Original-LoxBerry bleibt ein Raspberry.

Wir versuchen aber bei der Programmierung des Basissystems möglichst keine RaspBerry spezifischen Dinge einzubauen, sodass der LoxBerry durch andere Freiwillige problemlos auf andere Hardware portiert werden kann. Die zahlreichen existierenden x86 Images zeigen, dass das Konzept sehr gut funktioniert.

Naturlich werden Plugins, die die spezielle Hardware des RaspBerry nutzen, dann auf anderer Hardware nicht laufen. Ich werde dazu in der neuen Pluginschnittstelle V2 einen entsprechenden Schalter einbauen: needsraspi Damit kann die Installation auf einem Nicht-Raspi-System verweigert werden.

Ich denke es bleiben genug coole Plugins übrig, die keine Raspi Hardware brauchen.

LG

[jodelkoenig]

Na ... da habe ich was losgetreten

Ich denke die Diskussion Raspi vs. Virtualisierung können wir uns schenken. Beide Varianten haben aus Hardwaresicht Vor- und Nachteile. Da braucht es für keine der Varianten weitere Argumente. Es gibt schlicht kein richtig oder falsch.

Was loxberry angeht, formulierte ich eine Frage und einen Wunsch. Habe allerdings NULL Ansprüche. Ich kann keine Programmier-Eigenleistung einbringen. Bin, was das angeht, planlos. Wenn loxberry loxberry bleibt und nicht zu loxx86 mutiert ... null Problem. Ich werde es auch dann weiter nutzen.

ENTWEDER, wie bisher, als x86-VM, die aus der Community kommt - Danke insoweit für das klärende Update, Prof.Mobilux - ODER ich emuliere den Raspberry PI im virtuellen Linux ... hehe (bzw. lasse den einen noch verbliebenen weiterhin laufen, dann auch mit loxberry).

Wie gesagt ... loxberry ist ein Top-Projekt und ich ziehe den Hut voller Dankbarkeit vor ALLEN Contributoren ... Super Sache !!!

[svethi]

Ich weiß eigentlich gar nicht wieso Du Dich so auf die Virtualisierung festlegst. Der Loxberry ist nichts weiter als „etwas“ Software. Und wenn es danach geht, müsste er sogar in der bash-shell von Windows laufen. IMMER natürlich mit den Einschränkungen die das Hostsystem auferlegt. Der Loxberry an sich sollte eigentlich mindestens auf jedem Linux laufen. Mit gewissen Geringfügigen Anpassungen. Da der Loxberry ja auch den Systemkonfiguration vornimmt. Diese ist auf den diversen Distributionen etwas unterschiedlich. Ordnerstruktur etc. Nicht zuletzt ist es aber so, dass ein Debian Jessie auf dem Raspberry (Raspbian) eben kein hundertprozentig gleiches Debian Jessie auf einem X86 ist. Dies habe ich persönlich schon feststellen müssen. Das komplette System ist halt auch komplett anders kompiliert. Wenn ich mich recht erinnere ging es dabei um das Perl Modul zum Auslesen der Konfigdateien. Während beim Raspberry fehlende Variablen (oder leere, ich weiß es nicht mehr genau) als leer/nichts zurückgeliefert wurden, standen in den Variablen auf dem X86 Gegenspieler undefined oder so in den Variablen, was im Plugin dann für „Verwirrung“ stiftete. Es kann halt NIE wirklich ausgeschlossen werden, dass irgendwelche Funktionen dann doch etwas anders reagieren.
Daher bin ich genau bei Prof.Mobilux und sage, dass offiziell Loxberry nur auf dem Raspberry mit dem offiziellen Image unterstützt werden sollten. Es sagt ja keiner dass es nicht geht. Es sagt auch keiner mach es nicht. Und wenn Funktionen eingebaut werden, die eine Abfrage nach dem System ermöglichen oder die Plugin Installation nur auf Raspberry erlauben ist das auch gut. Es geht ja nur darum, dass man im Supportfall der Entwickler entscheiden kann ob es ein Bug ist oder am System liegt und sich eventuell der Entwickler des System darum kümmern sollte.
Außerdem geht es beim Loxberry auch darum für die Entwickler ein genau definiertes System mit einem genau definierten Paketset darzustellen um eben auf allen Systemen gleiche Grundbedingungen zu haben. Und hier geht es halt auch schon los. Ich selbst habe schon oft den Loxberry manuell auf ein System gebracht und kann daher ganz genau sagen, dass es absolut unmöglich ist einen Loxberry mit genau diesen Bedingungen auf einem anderen System aufzubauen. Aus diesem Grund kann es halt lt. Definition nie ein Loxberry sein.

Gruß Sven