Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Nur am Rande: Meine Busteilnehmer sind allesamt auf "dumm" programmiert, d.h. untereinander kommunizieren die Gerätschaften rein gar nicht. Die gesamte "Logik" übernimmt EDOMI - selbst ein noch so trivialer "Lichtschalter" sendet nur seine GA, aber niemand außer EDOMI lauscht auf diese GA.
Ist die „dumme“ Programmierung eine Voraussetzung oder funktioniert es auch „parallel“ ?
Alles in einer Box hat schon einen gewissen Charme, wenn mann eine zweite Box up-to-date hat ;-)
Kann man hier auch zwei „Boxen“ redundant betreiben die sich in Zeitabstand „x“ synchronisieren ?
So ist es... Andererseits: Was soll's Ich will mit EDOMI nicht reich werden - ich würde mich aber freuen, wenn das Progrämmchen in Zukunft viele KNX-Hütten steuert.
Dann lizensiere alles mit GPL und mach den Source komplett öffentlich. Damit verbleiben die Rechte beim Source selbst. Somit hat jeder immer freien Zugriff für auf die Quellen/das Programm und zwar für alle Zeit.
Das schließt aber nicht aus, dass eine Firma daherkommt, EDOMI auf eigene Hardware packt und ein Gesamtpaket verkauft. Nur muss diese Firma dann den Source ebenfalls offenlegen und auch bekannt geben dass sie EDOMI drauf haben.
Nur am Rande: Meine Busteilnehmer sind allesamt auf "dumm" programmiert, d.h. untereinander kommunizieren die Gerätschaften rein gar nicht. Die gesamte "Logik" übernimmt EDOMI - selbst ein noch so trivialer "Lichtschalter" sendet nur seine GA, aber niemand außer EDOMI lauscht auf diese GA.
Das ist ein interessanter Ansatz. Da würde mich deine GA-Struktur interessieren.
Wenn EDOMI mal streikt, ist's dunkel - schon klar. Aber gerade hier lag ja meine Motivation in Richtung möglichst robuster Programmierung und Absicherung. Wenn die Hardware in Flammen aufgeht habe ich allerdings Pech gehabt... Übrigens habe ich ein zweites identisches System im Schrank - für den Fall der Fälle Plug and Play...
Klassicher Single-Point-of-Failure. Aber dafür hat man die gesamte Logik auch zentral und übersichtlich und muss nicht mehrere Geräteeinstellungen gleichzeitig betrachten um das daraus resultierende Logik-Ergebnis zu verstehen.
Was du offenbar versuchst ist die Vermeidung von "Raubkopien". Aber auch dagegen ist kein Kraut gewachsen.
So ist es... Andererseits: Was soll's Ich will mit EDOMI nicht reich werden - ich würde mich aber freuen, wenn das Progrämmchen in Zukunft viele KNX-Hütten steuert.
Nur am Rande: Meine Busteilnehmer sind allesamt auf "dumm" programmiert, d.h. untereinander kommunizieren die Gerätschaften rein gar nicht. Die gesamte "Logik" übernimmt EDOMI - selbst ein noch so trivialer "Lichtschalter" sendet nur seine GA, aber niemand außer EDOMI lauscht auf diese GA.
Wenn EDOMI mal streikt, ist's dunkel - schon klar. Aber gerade hier lag ja meine Motivation in Richtung möglichst robuster Programmierung und Absicherung. Wenn die Hardware in Flammen aufgeht habe ich allerdings Pech gehabt... Übrigens habe ich ein zweites identisches System im Schrank - für den Fall der Fälle Plug and Play...
Für den produktiven Einsatz (später) würde ich allerdings eine dedizierte Hardware empfehlen - muss nichts großartiges sein, aber zuverlässig. EDOMI braucht wenig Ressourcen und könnte prinzipiell auch auf einem Raspi laufen (ungetestet). Ich habe als OS CentOS 6.5 in der Minimalinstallation gewählt und alle überflüssigen Dienste entfernt. Demnächst werde ich noch mit ArchLinux experimentieren - der Grundgedanke bei der Entwicklung war nämlich, dass EDOMI später quasi "embedded" laufen soll - ähnlich wie der HS. Sprich: Kleine schwarze Schachtel mit 2 Anschlüssen (LAN und Strom)
Im OS werden sämtliche Logs deaktiviert usw., EDOMI verwaltet sich selbst, räumt auf, macht Backups etc.
Meine Überlegung (zunächst) ist eher in Richtung VM, d.h. ich erstelle eine komplette VM einschl. Betriebssystem, die dann problemlos verteilt werden kann. Hier muss ich mich allerdings noch schlau machen, wie die VM entsprechend geschützt werden kann, damit man den Quelltext nicht "rausziehen" kann. Da wird es sicher Möglichkeiten geben.
Wie gut das "verschleiern" selbst in einem "abgeschlossenen Betriebssystem" funktioniert, sieht man am Beispiel HS.
Nur wer weiß schon, in welchen Foren und Märkten mein geistiges Eigentum dann landen würde...
Für genau sowas gibt es Lizenzen (GPL, LGPL, BSD, CC, ....). Damit hat man dann das recht auf seiner Seite. Aber mal davon abgesehen: Geistiges Eigentum ist sowieso per deutschen Urheberrecht geschützt (das sollte als deutscher Stattasbürger auch auf Lanzarote greifen, und falls nixcht: Urheberrecht in diversen Formen gibt's in beinahe jedem Staat).
Was du offenbar versuchst ist die Vermeidung von "Raubkopien". Aber auch dagegen ist kein Kraut gewachsen.
OK, danke, werde mal die 117 Seite bei Gelegenheit lesen (müssen), da ich eine zweite NAS als Backup bekommen soll, wir die Neue sicher ausreichen ;-)
Ansonsten am MacMini in der VM oder ...
Virtualbox ist für Windows und Mac "kostenlos", performance sollte ja für das EDOMI eine untergeordnete Rolle spielen
Für z.b. Synology gibt es php Virtualbox, das kann die Container auch laden und läuft bei mir bis zum letzten DSM Update auch sehr gut. Kann man dort also auch verwenden. Wobei man das ja eigentlich nicht bräuchte, weil Apache und Php so wie mysql läuft auch direkt auf dem Syno..
Auch denke ich dass es hier viele gibt die diese VM nutzen … Wäre prima wenn man das Format der VM-Disk so hinkriegt, dass die VirtualBox damit zurecht kommt :-)
Kurzes Update:
Kompilieren ist kein Problem, ich werde mich dabei aber auf die wesentlichen "Kernroutinen" beschränken - der Quelltext bleibt also in den meisten Bereichen sichtbar. Wie gesagt ist das meiner Meinung nach besser so, damit sich der ein oder andere sein individuelles EDOMI bauen kann (z.B. verrückte Visu-Elemente erstellen o.d.G.).
Bleibt allerdings noch die Frage des Schutzes offen... Von irgendwelchen Software-Gedöhns halte ich nicht viel - ist ohnehin alles nur eine Frage der Zeit, bis ein findiger Cracker einen Weg findet (siehe HS...). Bleibt also nur das Prinzip "Ehrlichkeit" - oder Rechtsabteilung
Die Tage werde ich mal versuchen, eine Visu auf meinem iPad abzufilmen. Das iPad ist uralt (Version 2), die Visu trotzdem fix. Und die Anmutung steht einer "echten" App in nichts nach, da ich sämtliche Register gezogen habe um das App-Feeling zu bekommen. Die Visu steht "bretthart" auf dem Screen
Demnächst werde ich mal eine VM basteln, damit Ihr ein wenig experimentieren könnt. Ich habe allerdings nur "Fusion" (Mac) - vielleicht lassen sich diese VMs aber irgendwie in andere Formate konvertieren.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Einen Kommentar schreiben: