ETS für Linux gewünscht

[ITler]

Aus meiner Sicht wäre es wesentlich sinnvoller, die ETS als Web-Applikation bereitzustellen.

- Das würde die Frage nach dem Client-Betriebssystem erübrigen
- Das würde die Nutzung auf Mobilgeräten ermöglichen

Das kann ja dann trotzdem lokal in nem Container oder ner kleinen Runtime laufen.

Damit könnte man dann vielleicht in Kombination mit einer LAN-Schnittstelle ein schönes Embeded-System entwickeln welches in der Installation bleibt.
Somit ist auch die Diskussion mit dem Verbleib der Projekt-Datei oder unterschiedliche ETS-Versionen Geschichte.

Die ETS könnte verschiedene User haben, einmal für den Installateur, einmal für den Kunden. Änderungen an der Anlage könnten nachgehalten werden, vielleicht sogar die Telegramme der letzten X Tage/Wochen um bei Problemen direkt in die Fehlersuche einsteigen zu können...

Das wäre meiner Meinung nach deutlich zeitgemäßer also diesen Proprietären Dinosaurier auf verschiedene Plattformen zu portieren.
Vom Handling der Installation mal ganz zu schweigen...

Mit proprietär meine ich hier eher OS-spezifisch, proprietär ist hier nicht ganz korrekt
@Dima: Danke für die Richtigstellung

[tobiasr]

Du meinst die ETS-Inside nochmal neu auflegen? Wieso die in der Versenkung verschwunden ist, verstehe ich sowieso nicht.

[DiMa]

Die Ärgernisse mit der ETS ist die eine Seite der Medaille, Windows selbst aber die andere - und W11 ist kein Freudenquell u. wird es auch in einer VM nicht werden.

Das sind immer so Statements, die in einer Absolutheit kommen... Ich finde als jemand, der beruflich sein Geld u.a. mit der Entwicklung unter Windows und Linux verdient und zwar seit Jahrzehnten Win11 super und die aktuelle Entwicklung in immer weitere Zersplitterung der Linux Distros und der damit verbundenen Paketquellen/Repos gruselig.

Der intake an CVEs unter Linux kennt nur noch eine Richtung: Immer mehr, Monat für Monat, weil die Communities gar nicht mehr mit dem Schließen nachkommen, schließlich sind inzwischen x-backports notwendig. Das noch gepaart mit komplett unterschiedlichen Roadmaps für LTS-Versionen... Für professionelle Software (=SW, mit der Geld verdient wird, für die Support angeboten werden muss, Gewährleistung gewährt werden muss, regulatorische Bedingungen eingehalten werden müssen) wird das jenseits von RHEL als OS bald nicht mehr darstellbar. Gegen so viele verschiedene Versionen auf unterschiedlichen Patchleveln kann kein Mensch mehr testen.

Gibt sehr nachvollziehbare Gründe, warum es praktisch keine kommerzielle Desktop-SW für Linux gibt. Das ist betriebswirtschaftlich völlig uninteressant. Da ist es dann auch ziemlich egal, ob der technische Unterbau möglicherweise (ich teile diese Meinung seit Win10 nur noch sehr begrenzt, aber das ist ein anderes Thema) unter Linux "besser" ist. Was auch immer "besser" heisst - bzgl. Cyber Security sicherlich nicht, das dreht gerade in die komplett falsche Richtung.

Daher sollte man seine SW so gestalten, dass sie in allen Betriebssystemen (Win, Mac und Linux) funktioniert.

Das ist leider nicht so einfach, wenn die Software dann auch noch performant sein soll und eigene HW (z.B. KNX-USB oder -serielle Schnittstellen) unterstützen muss. Die Welt besteht schließlich nicht nur aus KNXIP. Vom Secure-Komplex mal ganz davon abgesehen, wo erst mal geklärt werden müsste, ob ein Linux überhaupt zertifizierbar ist (ich spreche da aus Erfahrung aus einem anderen Umfeld/Branche...!).

[DiMa]

Damit könnte man dann vielleicht in Kombination mit einer LAN-Schnittstelle ein schönes Embeded-System entwickeln welches in der Installation bleibt.

Das wäre meiner Meinung nach deutlich zeitgemäßer also diesen Proprietären Dinosaurier auf verschiedene Plattformen zu portieren.

Finde den Fehler.

[gbglace]

Weil ja da auch keine Plugins funktionierten und man damit eine KNX2.0 Variante hatte.

Und man müsste zwei Sorten SAw pflegen. Und wie schnell Bugfixes bei der einen kommen sieht man ja, warum da also noch ne zweite SW bauen und pflegen?

[ITler]

Finde den Fehler.

Ich finde keinen Fehler, kannst Du mir auf die Sprünge helfen?

[ITler]

Wenn Du Dich an dem Wort proprietär aufhängen möchtest ist das so freigestellt widersprüchlich, das ist korrekt.

Gemeint ist eher "OS-Spezifisch"

[ewfwd]

Naja Linux nutzen nicht viele. Aber dass sie es nicht für MacOS anbieten ist schon ziemlich arm. Ja ist Aufwand, aber dafür kostet die Software ja auch 3stellig, da kann darf man schon erwarten dass bisschen mehr als das absolute Minimum gemacht wird....

[traxanos]

Also wenn ich mir überlege das es jedes Jahr eine neue Mac OSX Version gibt und dann die vielen Linux Distris und Oberflächen etc

Die Aussage ist halt total sinnfrei. Ob Apple jedes Jahr eine neue Version raus bringt spielt keine Rolle. Und ob Bei Linux nun der Fensterrahmen Grau/Blau/Grün oder was auch immer ist, spielt auch keine Rolle. Programme wie die ETS könnte man problemlos so bauen, dass sie auf fast allen Betriebsysteme funktioniert. Dafür muss man nur ein UI Toolkit verwenden was auf allen Systemen läuft. Das kleinwenig Netzwerk stelle ebenfalls kein Problem heutzutage da.

Warum sich die ETS nicht so ohne weitere portieren lässt, liegt an ihrer Historie. Ziel ist es, dass alle alten Produkte weiter mit Ihr verwaltbar zu halten. Und da kann man nicht mal einfach was ändern. Wenn ich da anfange eine andere Library zu verwenden, das nur arginal sich anders verhält, wäre ggf. alle Produkt die darauf aufbauen kaputt. Und da spreche ich nichtmal von Plugins.

Man schaue sich nur mal an, dass die ETS JavaScript erlaubt. Das ist eine ganze alte Lib von Microsoft. Wenn du da auf was moderne wie NodeJS wechselt ist die Chance extrem das ein Haufen von knxprods danach nicht mehr funktionieren. Alle Probleme die die ETS hat, haben meiner Meinung nach nichts mit dem Betriebsystem als solches zu tun.

Ich habe sogar extrem viel Hochachtung davor was die Entwickler dort schaffen. Immerhin kann ich uralte KNX Installation noch heute verwalten (mit wenigen Ausnahmen).

Aber dass sie es nicht für MacOS anbieten ist schon ziemlich arm.

Dann muss man mit der kompatiblität brechen oder zumindest inkompatiblitäten in kauf nehmen. in der software steckt soviel alte software bausteine drinne... wenn sie das ohne probleme könnten würde sie es vermutlich sogar machen. aber das zu bauen würde unfassbar viel ressourcen verbrennen.

versteht mich nicht falsch ich hätte auch gerne eine Mac/Linux Variante.

[ewfwd]

Aber den Ballast bis zum Sankt Nimmerleins Tag herumschleppen kanns am Ende doch auch nicht sein... Die Frage ist auch wieviel davon stimmt tatsächlich und was ist nur ein Vorwand...

Eine MacOS müsste ja auch nicht alles können... würde ja reichen wenn diese ETS5 und 6 Projekte öffnen könnte und wer richtig altes Zeug hat muss dann vorerst bei Windows bleiben. Aber so könnten zumindest diejenigen die halbwegs modern unterwegs sind MacOS nutzen...

[traxanos]

wie immer eine frage der prio. so eine teils/teils ding ist halt auch mist und verwirrt und verunsichert user. außerdem bringt das nen haufen probleme mit sich.

das ist die gleiche diskussion warum apple keine mmc slots in seinen iphone hat. die einen sagen weil sie den speicher teuer verkaufen wollen. aber die ganzen probleme die man nicht lösen muss sieht niemand.

[TomasM]

Die Aussage ist halt total sinnfrei. Ob Apple jedes Jahr eine neue Version raus bringt spielt keine Rolle. Und ob Bei Linux nun der Fensterrahmen Grau/Blau/Grün oder was auch immer ist, spielt auch keine Rolle. Programme wie die ETS könnte man problemlos so bauen, dass sie auf fast allen Betriebsysteme funktioniert. Dafür muss man nur ein UI Toolkit verwenden was auf allen Systemen läuft. Das kleinwenig Netzwerk stelle ebenfalls kein Problem heutzutage da.

Sorry, aber ich sehe das durchaus anders, vieles bei Apple im OSX hat sich in den letzten Jahren verändert.
- Sehr viel Security Themen für Anwendungen und Zugriffe auf System (Apps, die sich auf diese Erweiterungen verlassen, funktionieren möglicherweise nicht mehr.)
- Arm Support
- Rosetta 2
- API Änderungen (Big Sur)
- Entfernung vom 32 Bit Support

Die Unix Tools mussten für die Entwickler teilweise alle neu kompiliert werden, viele Programme oder Installer funktionierten nicht mehr.

Für die Entwickler meiner Meinung schon ein GRAUS, je nachdem was die Anwendung macht und welche Systemressourcen sie benötigt waren die Umbauearbeiten auch durchaus erheblich.

Das hast Du mit Windows ggf. nicht unbedigt z.B. Kompatibitätsmodus möglich etc.

Das es für dich sinnfrei ist ok, das ist deine Meinung, die ich dir gerne lasse. Aber ich hab da doch eine andere Sichtweise die ggf. etwas Detailierter auf einzelpunkte geht. Das mache ich sicher auch nicht weil ich Apple oder MS nicht mag, ich nutze OSX seit vielen Jahren, genauso wie Windows und auch Linux.

Jedanfalls das ganze hat leider nix mit irgendwelchen Farben der Fenster zu tun. Wenn es das nur wäre , wäre ich sicher eher deiner Richtung unterwegs..

Zumindest meine nicht sinnfreie Sichtweise, kommen wir zurück zum Thema...

Tomas

[traxanos]

Sorry aber natürlich entwickeln sich Systeme weiter. Aber eine neue CPU Architektur ist jetzt nichts Apple spezifisches. Rosetta 2 ist doch genau das, damit man abwärtskompatibel bleiben kann - worüber du dich gerade beschwerst. Hat MS übrigens auch im Programm. Und API Änderungen bzw. Verhaltenänderungen gibt es bei MS und Linux genauso. Übrigens hat MS gerade viele alte Rechner zu Müll erklärt und Rechner müssen neu gekauft werden. Das nur weil man meint Windows 10 (was übrigens die letzte Version sein sollte) auslaufen zu lassen und sich nur noch auf Windows 11 zu konzentrieren. (Ja kann Apple auch)

Ich kann dich aber auch gerne mal mit paar Firmen zusammen bringen, die Probleme haben ihr CallCenter Software auf neueren Windows-Systemen laufen zu lassen.

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.

[DiMa]

Ich finde keinen Fehler, kannst Du mir auf die Sprünge helfen?

"Anstatt (...) auf verschiedene Plattformen zu portieren." In meiner Welt besteht so ziemlich jede embedded Platform aus einer mehr oder weniger dedizierten Kombination von MCU und Basissoftware. Also das exakte Gegenteil zu deiner Aussage / signifikant höherer Portierungsaufwand.

Ob Apple jedes Jahr eine neue Version raus bringt spielt keine Rolle.

Da wird dir so ziemlich jeder SW-Hersteller, der Treiber für macOS liefern/bereitstellen muss aber energisch widersprechen.

Dafür muss man nur ein UI Toolkit verwenden was auf allen Systemen läuft.

Ach, das ist ja einfach. Kaum vorstellbar, dass da die Leute nicht von selbst 'drauf kommen. Nehmen wir doch einfach node.js, wollte ja eh' jemand eine WebApp (den Zugriff über nicht-KNXIP ignorieren wir einfach mal).
Das bisschen Applikation nach JS portieren ist ja nun Kinderkram und alle drei Jahre die Designbase auf die neueste node.js LTS (üblicherweise mit legacy-breaking Änderungen) portieren macht man doch mit links. Dann halt Angular, das bisschen TypeScript und Framework macht man doch ebenfalls mit links. Habe nie verstanden, warum Leute eigene Kurse nur für Angular brauchen/wollen. Ach Mist, da kommt sogar alle 6 Monate eine neue Major, auch irgendwie blöd. Chromium wäre dann noch 'ne Alternative, aber der eine oder andere traut der Platform nicht - warum auch immer 😀 GTK oder Qt - OK, da hast du mich. Aber dann die nächste Frage: Schon mal darunter programmiert? Und würdest du es freiwillig wiederholen 😉? Und so weiter und so fort - und wenn man das nicht will oder kann, landet man z.B. bei .NET. oder AppKit, zumindest für Desktop-Anwendungen.

Ziel ist es, dass alle alten Produkte weiter mit Ihr verwaltbar zu halten. Und da kann man nicht mal einfach was ändern.

Ja, Das ist irgendwie auch der Windows-Fluch. Schon blöd, dass Häuselbauer (oder ab sofort z.B. auch Autofahrer) davon ausgehen können wollen, dass sie ihre Software auch in 20 Jahren noch warten, konfigurieren und patchen können. Die sind irgendwie anders 'drauf, als der durchschnittliche Apple Fanboy, der alle zwei Jahre neue Geräte kauft, sich begeistert als Betatester zur Verfügung stellt und jubiliert, wenn Apple mal wieder einseitig definierte "alte Zöpfe" abschneidet.

Wenn du da auf was moderne wie NodeJS wechselt ist die Chance extrem das ein Haufen von knxprods danach nicht mehr funktionieren.

Wenn du auf NodeJS setzt, ist die Chance sehr hoch, dass du spätestens alle drei Jahre dann ETS und deine knxprods neu releasen "darfst". Siehe oben. Und das ohne funktionale Änderungen.

Ich habe sogar extrem viel Hochachtung davor was die Entwickler dort schaffen. Immerhin kann ich uralte KNX Installation noch heute verwalten (mit wenigen Ausnahmen).

Und das kostet halt Geld.

Aber den Ballast bis zum Sankt Nimmerleins Tag herumschleppen kanns am Ende doch auch nicht sein...

Siehe oben und lest euch mal nur den ETS 6 thread hier durch. Was glaubt ihr denn, was los wäre, wenn die ETS mal von Grund auf neu gebaut würde, wenn schon die Reihenfolge von ein paar Mausklicks oder das Umverpacken von Funktionen in eine andere Ecke der Software für den einen oder anderen hier ein Dealbreaker ist.

Aber so könnten zumindest diejenigen die halbwegs modern unterwegs sind MacOS nutzen...

Bei all der Liebe zu Macs ist aber schon iregendwo noch im Bewusstsein verankert, dass trotz deren gestiegener Marktanteile immer noch gerade mal 15% macOS benutzen? Und das dürfte für SIs und Installateure noch nicht mal repräsentativ sein - da wird der Mac-Nutzer Anteil signifikant kleiner sein, denn die haben ja auch noch andere IBN-Software auf ihren Laptops, die nur unter Windows läuft.

Und API Änderungen bzw. Verhaltenänderungen gibt es bei MS und Linux genauso.

Die sind bei Mircosoft aber signifikant besser planbar, deutlich länger im voraus bekannt und der Laden gibt sich ganz erhebliche Mühe, legacy breaking changes zu vermeiden. Was Fluch und Segen zugleich ist (für das OS).

Übrigens hat MS gerade viele alte Rechner zu Müll erklärt und Rechner müssen neu gekauft werden.

Weil sie doch tatsächlich nach 20 Jahren mal das gemacht haben, was jeder Apple-Fanboy als "Abschneiden alter Zöpfe" feiert. TPM 2.0? Wie kann man nur! (Teilewechsel ohne passendes HSM nicht mehr möglich? Gottlob denkt Apple an unsere Sicherheit!) SecureBoot läuft nur noch mit aktuellen, signierten Treibern? Wie kann man nur, das machen die extra, um Linux-Nutzer zu ärgern! (Ohne Hacks gar nicht erst in der Lage zu sein, von Apple nicht gewünschte OS inkl. unerwpnschten macOS-Versionen (!) auf seiner (!) HW zu installieren? Was ist das toll, dass Apple diesen OS-Wildwuchs unterbindet, kommt der Usability nur zu Gute und macht das OS sicher!) Und das kann man mühelos so weiter treiben.

Ich kann dich aber auch gerne mal mit paar Firmen zusammen bringen, die Probleme haben ihr CallCenter Software auf neueren Windows-Systemen laufen zu lassen.

Und das liegt natürlich an Win11 und nicht etwa daran, dass diese CallCenter bzw. deren SW-Lieferanten deine Weisheiten

Und ob Bei Linux nun der Fensterrahmen Grau/Blau/Grün oder was auch immer ist, spielt auch keine Rolle. Programme wie die ETS könnte man problemlos so bauen, dass sie auf fast allen Betriebsysteme funktioniert. Dafür muss man nur ein UI Toolkit verwenden was auf allen Systemen läuft. Das kleinwenig Netzwerk stelle ebenfalls kein Problem heutzutage da.

einfach nicht beherzigen?!

[traxanos]

Da wird dir so ziemlich jeder SW-Hersteller, der Treiber für macOS liefern/bereitstellen muss aber energisch widersprechen.

Da wieder spreche ich auch nicht. Aber wenn man das auf sowas wie eine ETS übertragen würde, sehe ich keinen Grund warum man einen Treiber bauen müsste? Einfaches Netzwerk geht auf jeden fall Problem los. Und auch in der Windowswelt braucht es auch regelmäßig neue Treiber weil windows wieder das umgebaut hat. Das ist kein Alleinstellungmerkmal.

Ach, das ist ja einfach. Kaum vorstellbar, dass da die Leute nicht von selbst 'drauf kommen.

Ich glaube hier hast du was falsch verstanden. Diese Aussage bezog sich darauf das die eine Anwendung nicht mit jedem Betriebsystemupdate neu angepasst werden muss. Wenn ich eine normale Anwendung programmiere, ist das Betriebsystem(-version) in der Regel egal. Es wird erst spannend wenn man mein specials zu machen. Treiber bauen. Integrationen ind Betriebsystem (z.B. Dropbox in MacOS Finmder per kext etc)

landet man z.B. bei .NET. oder AppKit, zumindest für Desktop-Anwendungen

Auch das bezog sich auf auf die Abhängigkeit zur Betriebsystemversion. Ich muss jetzt nicht dauernd die Oberflächen neu bauen nur weil Apple ein Update rausgebracht hat.

Wenn du auf NodeJS setzt

dann geb ich mir die Kugel ... ich hasse nodejs. das ist keine technik mit der ich langfrisitg arbeiten möchte auch wenn ich es beruflich viel muss.

Siehe oben und lest euch mal nur den ETS 6 thread hier durch.

so sieht es aus. die meisten wollen auch keine veränderung.

da wird der Mac-Nutzer Anteil signifikant kleiner sein

denke ich auch. das betrifft viel mehr Heimuser. Leute die sich ein KNX Heim leisten können sind oft auch auf MacOS unterwegs. Die ETS zielt aber auch SI & Elektriker habt.

Die sind bei Mircosoft aber signifikant besser planbar, deutlich länger im voraus bekannt und der Laden gibt sich ganz erhebliche Mühe, legacy breaking changes zu vermeiden. Was Fluch und Segen zugleich ist (für das OS).

kommt auf den bereich an, aber ja. aber bei linux würde ich das weniger unterschreiben. wie immer hat beides vor und nachteile.

Weil sie doch tatsächlich nach 20 Jahren mal das gemacht haben, was jeder Apple-Fanboy als "Abschneiden alter Zöpfe" feiert. TPM 2.0?

wir reden hier nicht von 20 jahre alten rechnern. wir reden hier von 5 jahre alten rechner die übrigens windows 11 tauglich gemacht wurde per bios update. windows das die grenze künstlich gesetzt. aber auch diese aussage bezog sich auf einen anderen thread wo man das windows so hoch gelobt hat und alles so lange nutzbar etc.

Und das liegt natürlich an Win11 und nicht etwa daran

ich spreche nicht von windows 11. auch hier spreche ich davon das windows früher mal komplette stacks im bereich audio verworfen hat und damit alle anwendungen die gegen diesen stack gelinkt wurden sind, nicht mehr funktionierten. also auch nur ein beispiel das auch windows alte zöpfe abschneidet.



nochmal meine aussagen bezogen sich auf einen vorpost den man schon im kontext beachten muss. ich komme aus der software entwicklung ich kenne die ganze problem und du scheinst nach deinen aussagen auch nicht so weit weg zu sein