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.
Und die meisten Probleme mit Betriebsystemen entstehen wenn man unkonventionelle Wege geht. Eine reine Verwaltungsssoftware müsste das garnicht machen. Aber die Software ist halt auch schon 20 Jahr alt.
dann stecken wir alle gemeinsam den Kopf in den Sand. Geht alles leider nicht. Ja kann man nix machen. Trifft KNXA keine Schuld. Ist eben so.
Bei Loxone geht es... Die Historie interessiert am Ende den Anwender halt nicht....
auch das bezog sich auf den vorpost!!! bitte kontext beachten!!!
das die software so ist wie sie ist ist, ist nunmal so. wenn du was ändern möchtest, dann musst due auf andere sachen verzichten. man kann nicht immer alles haben. weder in der realen welt noch in der virtuellen welt die KNXA liegt halt die Prioritäten fest! damit wirst du nie alle erreichen.
Ja ich sag ja. Kopf in den Sand stecken und weinen. Kann man halt nix machen, geht einfach nicht.
Wie heißt es so schön: Wer nicht mit der Zeit geht, muss mit der Zeit gehen.. Auch bei der ETS dürfte es fraglich sein ob man das "Konzept" noch Jahrzehnte lang fahren kann während alle um einen herum moderner unterwegs sind...
auch das bezog sich auf den vorpost!!! bitte kontext beachten!!!
das die software so ist wie sie ist ist, ist nunmal so. wenn du was ändern möchtest, dann musst due auf andere sachen verzichten. man kann nicht immer alles haben. weder in der realen welt noch in der virtuellen welt die KNXA liegt halt die Prioritäten fest! damit wirst du nie alle erreichen.
Ja, wenn Du schon so fies zurückschreibst... Nur gerecht...
DiMa:
Das Thema der verschiedenen Umgebungen ist aber gerade für eine reine Frontend App wie die ETS problemlos über Flatpaks abzufrühstucken. Diese sind bauartbedingt auch extrem unabhängig vom Wartungszustand und Kernel des OS - damit sind etwaige Abhängigkeiten kein Problem mehr. Ebenso sind die derzeitigen Plugins eigentlich kein Problem in diesem Rahmen.
Alle halbwegs aktuellen Distributionen können mit Flatpaks umgehen,selbst Ubuntu das ja lieber seine eigenen Snapd vermarkten würde.
Man darf dahingehend die ETS auch nicht überbewerten - die ETS ist am Ende programmiertechnisch ja nur ein Desktop-Programm das IP-Paket basierte Kommandos versendet und empfängt und diese in einem Windows-Manager darstellt. Das ist jetzt erstmal im Bezug auf Abhängigkeiten kein hohes Vodoo.
Es sei übrigens angemerkt: Auf einem Debian hab ich mal testweise ETS6 mit Wine zum laufen gebracht, inkl. (Web) Lizenzabfrage und Plugins. Ist aber zugegebenermaßen ein Gefrickel gewesen und ganz ganz weit weg von produktiv, es geht aber. Meine ETS läuft daher (vollkommen problemlos) auf einer Windows VM in Proxmox - die einheitliche Umgebung einer VM ist dahingehend ja sogar vorteilhaft. Selbst das anfängliche Passtrough eines USB Dongles ging problemlos.
Bei Loxone geht es... Die Historie interessiert am Ende den Anwender halt nicht....
Ja der Erstanwender, und wenn er dann in 10 Jahren an seinem Loxone-Haus was ändern will. bähhh. Wieviel Support gibt es denn noch für die Loxone-Server der Generation1.
Ich will KNX weil ich eben nicht solche Wege in die Mülltonne wegen nicht mehr supporteter Systemverwaltungssoftware haben will.
----------------------------------------------------------------------------------
"Der Hauptgrund für Stress ist der tägliche Kontakt mit Idioten."
Albert Einstein
Ich finde die Performance der ets auf einem native Windows schon grausam. In einer vm finde ich sie aber nicht viel schlimmer. Ich hatte es fast 2 Jahr probiert aber dann entnervt aufgegeben.
Dieser Beitrag enthält keine Spuren von Sarkasmus... ich bin einfach so?!
Aus meiner Sicht wäre es wesentlich sinnvoller, die ETS als Web-Applikation bereitzustellen
Viele gehen ja stark in diese Richtung. Z.B. Microsoft mit den Ganzen Office-Produkten, Outlook, Teams etc.
Vorteil ist man muss nichts installieren, falls die vom Browser zur Verfügung gestellten Funktionen (die immer mehr werden) ausreichen, ansonsten installierst du quasi einen Wrapper für die Web-Applikation, die dann eben zusätzliche, native Features zur Verfügung stellt.
Aber natürlich ist das bei KNX aufgrund der geforderten Rückwärtskompatibilität nicht ganz einfach.
Wobei ich mir hier aber auch die Frage stelle, ob sich der Kompatibilitätsanspruch nicht nur auf die Kommunikation im System bezieht?
ISt in der Definition verankert, dass die Konfigurationssoftware (ETS) auch Kompatibel mit Geräten aller Generationen sein muss?
In einer vm finde ich sie aber nicht viel schlimmer
Warum dann aufgegeben, wenn es nicht schlimmer ist? Oder hast Du dich verschrieben?
Ja, man merkt ggfs. einen kleinen Unterschied - aber setzt voraus, dass die VM auch entsprechend aufgesetzt ist u. der Host(rechner) entsprechende Voraussetzung bietet. Mit einer schwachen Kiste macht's keinen Spaß - mit entsprechender HW kein Problem.
Nachteil ist halt, dass man W immer 2x startet, bis man zum arbeiten kommt - Vorteil natürlich, dass man gleichzeitig in versch. Systemen (mit VPN) verbunden sein u. arbeiten kann. Aber so isses halt - immer hat's was.
Das Thema der verschiedenen Umgebungen ist aber gerade für eine reine Frontend App wie die ETS problemlos über Flatpaks abzufrühstucken. Diese sind bauartbedingt auch extrem unabhängig vom Wartungszustand und Kernel des OS - damit sind etwaige Abhängigkeiten kein Problem mehr.
Aus dieser Aussage kann man nur eins ableiten: Du hast nichts mit flatpacks in einem kommerziellen produktiven Umfeld zu tun. Schon gar nicht in einem Umfeld, in dem ggf. zertifizierte Entwicklungsprozesse eingehalten und nachgewiesen werden müssen, um überhaupt eine Zertifikation zu erhalten... Das ist mit flatpacks (oder snaps oder auch allen anderen "dockerartigen" Konstrukten) ein fundamentales Problem. Richtig ist, dass das keine technischen Hürden sind. Richtig ist aber auch, dass das ansonsten für ein kommerzielles Produkt gewaltige Hürden sind, deren Bezwingung sehr viel Geld kostet.
Dazu kämen noch die erheblich steigenden Ressourcenanforderungen dieser Platform und natürlich das "Detail", dass das eine reine Linux-Baustelle (sorry: "Lösung") ist.
Ebenso sind die derzeitigen Plugins eigentlich kein Problem in diesem Rahmen.
Weil eine sandboxed ETS in einem flatpack problemlos mit einem plugin in seinem eigenen flatpack arbeiten würde? Und das plugin bringt dann seine eigene Laufzeitumgebung direkt mit, oder wie genau stellst du dir das vor?
Man darf dahingehend die ETS auch nicht überbewerten - die ETS ist am Ende programmiertechnisch ja nur ein Desktop-Programm das IP-Paket basierte Kommandos versendet und empfängt und diese in einem Windows-Manager darstellt.
Wow. Du hast aber in deinem Leben noch kein größeres Desktop-Programm geschrieben, oder? ich mein', Word ist dagegen ja dann kompletter Pipifax, dass muss ja nichtmal Netzwerkkommunikation beherrschen sondern nur ein paar Bytes auf FS schreiben... Ist natürlich kompletter Unsinn, denn es gibt wie gesagt nicht nur KNXIP und dann sind da neben dem Applikationsprotokoll noch die ganzen Service-Funktionen im Stack (z.B. FW-Updates, discovery, routing...). Aber klar, so einen KNX-Stack macht man auch "mal eben" OS unabhängig. Das "mit einem WIndows-Manager darstellen" ist das bereits ausgiebig diskutierte: Da haben blöderweise Windows, macOS und Linux grob unterschiedliche am Start. "Mal eben" plattformunabhängig machen - siehe die Beiträge dazu.
Das ist jetzt erstmal im Bezug auf Abhängigkeiten kein hohes Vodoo.
Dann mal los, mach' mal. Scheint für dich ja eher eine SW-Aufwärmübung zu sein. Ich mein', entweder das, oder du hast in deinem Leben noch keine 1000 Zeilen Code selbst geschrieben oder mal ein Programm in Produktion gebracht (also so mit Überlegungen zu Doku, rechtlichen Anforderungen, Zertifizierungen, Qualtätssicherung, Wartbarkeit und Wartung, Kundensupport, Gewährleistung...).
Ist aber zugegebenermaßen ein Gefrickel gewesen und ganz ganz weit weg von produktiv, es geht aber.
Damit bestätigst du dann letztlich doch die entsprechenden Beiträge und weisst, warum dass die Konnex nicht macht. Und überhaupt: Wenn das nach deiner Einlassung alles so einfach ist, warum machst du dann so ein Gefrickel? Und wieso wine, das ist ja nun technologisch das Gegenteil von snaps und flatpacks, von denen du doch scheinbar so ein Fan bist? Ach ja, da ist das "Detail" mit Laufzeitumgebung... siehe oben.
Wow. Du hast aber in deinem Leben noch kein größeres Desktop-Programm geschrieben, oder?
ich glaube er meint was anderes. ich hab selber die ganze zeit überlegt wie man was schreibt. was er sicher meint und da bin ich auch der geilecn aufwassung, dass die anwendung technisch nach extern recht simpel ist. es gibt keine komplexen abhängikeiten zum betriebsystem (ggf vom dongle mal abgesehen). wohl aber ist die ets selber für sich genommen extrem komplex. diese komplexität hat aber erstmal nichts mit dem betriebsystem zu tun.
was die software aber dennoch vom betriebsystem extrem abhängig macht ist, dass die software sehr nach en den funktionen von windows gebaut wurde. beispiel die script engine die von ms verwendet wurde. und sowas macht es fast unmöglich die anwendung zu portieren.
Warum gleich so aggressiv und auf eine persönliche EbeneDiMa ?
1. Ich war jahrelang in der Softwareentwicklung für Healthcare&Medizinprodukte tätig und bin weiterhin Auditor(wenn auch nicht für DIN EN 62304). Ich behaupte ich weiß halbwegs wie komplex die Thematik ist.
2. Ich habe nie behauptet,dass das "billig" sei - es handelt sich am Ende immer noch um eine Linux Anwendung, die abhängig von der Codebasis entstehen muss. Ich habe nur deine unrichtige Aussage korrigiert,dass es auf Linuxseite durch die Vielzahl an Distributionen,etc. einen enorm verzweigten Entwicklungsaufwand gäbe. Das ist so halt nicht richtig. Genauso ist es falsch,dass Plugins ihre eigene Flatpak benötigen.
3. Falls du mit Ressourcen die Hardware meinst: Durch den auf der anderen Seite stark reduzierten OS-Overhead wird das im Regelfall wieder Dahingehend sind Linuxsysteme stark im Vorteil (nicht ihr Verdient, sondern eher Schuld von MS). Sicherlich hat Flatpak einen minimalen Overhead selbst, der ist aber vergleichsweise gering-dazu gibt's ja auch genug Evidenz.
4. Wie von traxanos richtig angemerkt bezog ich mich auf die OS Abhängigkeiten - und da ist die ETS tatsächlich im Gegensatz zu anderer Software relativ genügsam (auch unter Windows).
5. Meine Gefrickel-Einlassung bezog auf Wine, einen Emulator - das eine Nutzung eines Windows Programmes mit komplexen Kopierschutz,etc. unter Linux nicht gerade einfach wird ist auch verständlich,oder?
Das ich die ETS nicht mal in der Theorie als Flatpaks erstellen kann ohne Zugriff auf die Codebase zu haben dürfte dir ja klar sein wenn du Erfahrungen mit Softwareprojekten hast,oder?
Zur Klarstellung:
Das heißt alles NICHT,dass die ETS nicht ein komplexes Programm ist. Ist sie.
Das heißt NICHT,dass eine Bereitstellung unter Linux nicht deutlichen,auch wirtschaftlichen, Aufwand auf ETS Seite bedeuten würde - wie groß dieser wirklich ist kann nur jemand beurteilen der die Codebasis kennt.
Das kann zwischen "12 Wochen Arbeit" und "kompletter Rewrite" alles sein - und ich befürchte eher letzteres wenn man sich die Historie so ansieht.
Aber dieses "alles unmöglich" und "per se unvertretbar" ist halt auch schon lange nicht mehr richtig,genauso wie Aussagen über die mangelnde Professionalität in der Linuxwelt - über 80% des Internets laufen mittlerweile auf Linux,Android ist übrigens auch Linux.
Am Ende ist es - wie immer - eine wirtschaftliche Frage. Wie hoch der Aufwand ist kann keiner von uns beurteilen. Man wird sich auf wirtschaftlicher Seite also fragen müssen,ob man den für gerechtfertigt hält und welche Zukunftsperspektiven man damit erhält - der Anteil an Linux-basierten OSen ist derzeit im Desktop Bereich relativ gering,aber regional stark unterschiedlich. In Indien hat Linux einen Marktanteil von 15%, in Deutschland pushen gerade div. Bundesländer in Richtung Linux in der öffentlichen Verwaltung. Dann ist nicht ausgeschlossen,dass Großprojekte entsprechende Anforderungen stellen.
Und auch dann wird man sehen müssen was billiger ist - eine gut umgesetzte Wine-Emulation mit Unterstützung des Herstellers die einige kommerzielle Anbieter mittlerweile ja ausdrücklich unterstützen, von der Gamingwelt mal ganz abgesehen, oder ein Flatpak. Oder eine ganz andere Lösung.
Man wird sehen - bis dahin ruhig durch die Hose atmen.
Man darf dahingehend die ETS auch nicht überbewerten - die ETS ist am Ende programmiertechnisch ja nur ein Desktop-Programm das IP-Paket basierte Kommandos versendet und empfängt und diese in einem Windows-Manager darstellt. Das ist jetzt erstmal im Bezug auf Abhängigkeiten kein hohes Vodoo.
zu tun? Da steht: "ETS ist simpel." Du stimmst ihm jetzt zu mit "ETS selber für sich genommen extrem komplex"?!
Aber vielleicht habt ihr beide auch irgendwie was ganz anderes gemeint? Also nicht "ETS multi-OS-fähig und kompatible für alles und überall", was ich aus euren Posts herauslese?
Dann verstehe ich euch wirklich falsch. Was an den ganzen unhaltbaren und unzulässig vereinfachenden Statements liegen könnte, die ihr mal nebenbei immer wieder einstreut und wenn man sie aufgreift gerne als "aus dem Zusammenhang gerissen" betrachtet haben möchtet. Den Zusammenhang stellt aber a) ihr erst mal her und b) ist der Kern der Diskussion nicht "technisch nicht machbar" sondern "(betriebs)wirtschaftlich völlig uninteressant" gewesen.
Den letzten Teil mit "ist doch eigentlich ganz einfach"-Nebelkerzen abhaken zu wollen ist das, was mir gegen den Strich geht! Ich hab' auch x Prototypen am Laufen, die alle coole Sachen machen und mit der wir auf Konferenzen und Messen brillieren. "Verkaufen" kann man die nicht, denn wenn ich die industrialisieren würde, hätten die Produkte eine negative Marge.
was die software aber dennoch vom betriebsystem extrem abhängig macht ist, dass die software sehr nach en den funktionen von windows gebaut wurde. beispiel die script engine die von ms verwendet wurde. und sowas macht es fast unmöglich die anwendung zu portieren.
Wir können uns darauf einigen, dass die ETS sicherlich eine SW Architektur hätte bekommen können, die portabler angelegt hätte sein können.
Die Frage ist allerdings:
War das je eine Anforderung, als die SW mal konzipiert wurde?
Welchen Marktanteil hatte macOS oder Linux damals? Für Linux ist die Schnittmenge für Desktop + KNX auch heute noch nahe bei Null, damals war sie vmtl. Null. macOS? Keine Ahnung. Von den 10 oder so KNX-Betreibern, die ich kenne, nutzt kein einziger macOS. Also vmtl. auch eher einstelliger Prozentbereich.
Was hätte es an Mehrkosten bedeutet und hätte sich da gerechnet? Wegen 1. vmtl. gar nicht erst bewertet worden, weil man wegen 2. die Antwort kannte.
Und ich glaube nicht, dass sich daran irgendwas geändert hat. Außerhalb dieses Forums wird das gar kein Thema sein. Es wird schlicht und einfach keinen Bedarf geben. Wieviele Lizenzen verkauft die Konnex im Jahr? Ein paar hundert? Ein paar tausend? In jedem Fall wird das gerade mal so die Entwicklungskosten decken. Wieviele Lizenzen würden sie mehr verkaufen? Keine einzige, denn es wird niemanden geben, der auf KNX verzichtet, weil es die ETS nur unter Windows gibt. Wieviel Prozent der Kundschaft wären bereit - ich rate mal, nach einschlägiger Erfahrung mit solchen Aufwandsschätzungen - 15-25% mehr für die ETS zu zahlen, damit sie für EINE weitere Platform angeboten wird? Da müsste die Konnex mal eine Markstudie machen - ich würde mir aber zutrauen, das Ergebnis vorherzusagen.
Und diese Gedanken werden sich die/der ETS Produktmanager gemacht haben.
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.
die KNXA liegt halt die Prioritäten fest! damit wirst du nie alle erreichen.
Kommentar