ETS für Linux gewünscht

[traxanos]

Und was hat das jetzt wieder mit

dann liest alles zusammen genommen.

die diskussion fing mit https://knx-user-forum.de/forum/öffentlicher-bereich/knx-eib-forum/1985185-ets-für-linux-gewünscht?p=1985196#post1985196 an wo behauptet wurde, das eine entwicklung für mac und linux unzumutbar wäre, weil die Systeme mit ihren tausend Oberflächen und/oder der häufigen Update nicht brauchbar sei.

darauf hin wurde mehrfach gesagt das die komplexität was die abhängikeit vom betriebsystem betrifft garnicht so komplex. die ets selber wäre von der art und weis was sie tun soll (nicht wie sie gebaut wurde) sogar recht simpel. eine einfache anwendung die nur etwas netzwerk macht - übertrieben gesprichen. diese aussage kann ich soweit unterschreiben.

Das die ETS intern recht komplexe Prozesse/Strukturen hat, hat also erstmal nicht mit der Diskussion als solches zu tun, dass man die ETS gerne MultiOS hätte bzw. das niemals gehen könnte weil Linux und Mac so doof sind.

Ich hab übrigens auch zu bedenken gegeben, dass leider doch recht viele Abhängikeiten exisieren, Plugins oder externe Libs die zumindest nach meinem Kenntnisstand Windows bezogen sind. Hätte die ETS diese Abhängigkeiten nicht, wäre sie vermutlich sogar recht einfach portierbar (wobei recht einfach jetzt sicher wiede rmit 5 gegen argumenten kommt).


der wunsch wäre natürlich keine plungins zu haben also auch keine dca. alles schön als webanwendung, so dass man diese per browser öffnen kann. aber das wird es so nicht geben zumindest nicht ohne deutliche einschnitte in der kompatibilität und dem einsatz von viel geld.

[TomasM]

dann liest alles zusammen genommen.
die diskussion fing mit https://knx-user-forum.de/forum/öffentlicher-bereich/knx-eib-forum/1985185-ets-für-linux-gewünscht?p=1985196#post1985196 an wo behauptet wurde, das eine entwicklung für mac und linux unzumutbar wäre, weil die Systeme mit ihren tausend Oberflächen und/oder der häufigen Update nicht brauchbar sei.

Ich habe lediglich meine "Meinung" dazu geschrieben wie ich das sehe, zu der ich immer noch stehe, was Du so aus den Sätzen dann interpretierst ist schon beachtlich. Du hast ja dann auch sehr nett drarauf reagiert..

<Copy>
>Aso wenn ich mir überlege das es jedes Jahr eine neue Mac OSX Version gibt und dann die vielen Linux Distris und Oberflächen etc. kann ich mir irgendwie nich >vorstellen das das jemand möchte :- Dann müsste Apple selbst schon ETS rausbringen :-))

>Ich sehe da viele viele Probleme die sich keine Firma antun wird für die übersichtliche Kundenanzahl die sowas möchte.
</Copy>

[traxanos]

Du darfst auch deine Meinung haben. Ich teile sie nicht und unterstelle dir Unwissenheit - was wiederum meine persönliche Meinung ist. Warum weil du nicht sauber differenzierst.

Die Häufigkeit eines Updates sagt nichts über die Zuverlässigkeit aus. Du hast dich auch darüber beschwert das Apple alte Zöpfe abschneidet. Witzig das die ETS den RS232 Support wegen einem Windowsupdate und das schlechte Timing aufgegeben hast.

> Ich sehe da viele viele Probleme die sich keine Firma antun wird für die übersichtliche Kundenanzahl die sowas möchte.
Ich sehe z.B. viel Firmen die von Window weggehen zu Apple um damit ihren Support aufwand erheblich zu reduzieren - und zwar erfolgreich. Natürlich geht das nicht in jeder Firma - Abhängikeiten etc.

Aber du schreibst ja "was Du so aus den Sätzen dann interpretierst ist schon beachtlich".
Was interpretiere ich den falsch. Hier ein Beispiel

Aso wenn ich mir überlege das es jedes Jahr eine neue Mac OSX Version

Ich habe das so interpretiert das du das als was schlechtes / problematisches verstehst. Aber vielleicht meintest du ja doch was andere.

[DiMa]

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.

Das ist absolut richtig, allein schon um die verschiedenen Repos und build Prozesse für die ganzen Paketmanager zu bedienen. Dir als erfahrenem Auditor wird doch die damit einhergehende Kostenvervielfachung allein schon durch die zusätzliche QA sofort ins Auge springen, oder? Und nein, ein RPM, flatpack und snap laufen nicht aus der gleichen pipeline, von der ebenfalls zu parallelisierende Schlüsselverwaltung mal ganz abgesehen.

Ist dir alles klar? Dann verstehe ich deine Einlassungen nicht. Noch nie was davon gehört? Dann rührt mein scharfer Tonfall daher, dass du hier mit "Ich habe nur deine unrichtige Aussage korrigiert," auftrittst.

Genauso ist es falsch,dass Plugins ihre eigene Flatpak benötigen.

Ich habe es schon einmal gefragt: Die ETS wird deinen Ideen nach als flatpack ausgeliefert. Plugins werden dann genau wie ausgeliefert, wenn nicht als flatpack? Als ausführbares Programm, welches im remanenten Speicherpool des ETS flatpacks abgelegt wird? Und die OS-Unabhängigkeit (die du mit "flatpack" ja postulierst, auch wenn es die Technologie bislang ausschließlich unter Linux gibt) pasiert dann wie? Wartbarkeit, Versionisierung mit der ETS löst du in diesem Konstrukt wie (kriegt da jedes plugin dann zusätzliche Funktionalität eingebaut, dass es mit OStree kommunizieren kann, oder wie stellst du dir das vor)?

Und wenn das auch alles deiner Meinung nach wieder falsch ist: Wie wird es denn dann deiner Meinung nach funktionieren? (Im Nachgang kannst du dich dann mal damit auseinandersetzen, wie diese selbst unter Linuxern - vorsichtig formuliert - heiß diskutierte Technologie das Problem "Multiplatform für ETS", um dass es hier eigentlich geht lösen soll. Da müsste ja nun zuerst mal jemand flatpack für macOS und Windows entwicklen...)

Falls du mit Ressourcen die Hardware meinst: Durch den auf der anderen Seite stark reduzierten OS-Overhead wird das im Regelfall wieder

Was soll dass jetzt schon wieder? Es gibt durch flatpacks nur zusätzlichen overhead, am darunter liegenden OS ändert sich ja nichts.

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.

Worüber reden wir hier eigentlich? Sind wir jetzt in einer komplett hypothetischen Welt angekommen, in der du eine ETS als flatpack unter Linux betreibst, in der (zumindest theoretisch, bei Desktop-Systemen würde ich da nicht darauf wetten) der schlankere OS-Kern den flatpack-overhead gegenüber einer ETS unter Windows kompensiert?

Das würde bedeuten, dass du deine Linux-Diskussion "mal eben" komplett von der Multiplattform-Diskussion dieses Threads abgekoppelt hast?! Ich mein', dann redest du von einer komplett anderen ETS unter Linux als unter Windows.

Das wird sich dann sicher eher rechnen, als eine Multiplatform-Version (die sich auch nicht rechnet - sonst gäbe es die).

Lest ihr eure Beiträge eigentlich auch mal im Zusammenhang:

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).

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.

Ich fasse mal zusammen: Ihr beide stimmt darin überein, dass die Software keine/kaum OS Abhängigkeit hat, bis auf die Nutzung vieler Windows-Funktionen, was die Software extrem abhängig vom OS macht. Echt jetzt?

Ansonsten stelle ich einfach nur noch mal Aussagen deiner letzten beiden Postings gegenüber:

Komplexität der ETS:

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.

Das heißt alles NICHT,dass die ETS nicht ein komplexes Programm ist. Ist sie.

Komplexität von flatpacks oder zumindest eine eigenartige Definition von "problemlos":

Das Thema der verschiedenen Umgebungen ist aber gerade für eine reine Frontend App wie die ETS problemlos über Flatpaks abzufrühstucken.

Das heißt NICHT,dass eine Bereitstellung unter Linux nicht deutlichen,auch wirtschaftlichen, Aufwand auf ETS Seite bedeuten würde (...)
Das kann zwischen "12 Wochen Arbeit" und "kompletter Rewrite" alles sein - und ich befürchte eher letzteres wenn man sich die Historie so ansieht.

Und abschliessend:

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.

An welcher Stelle habe ich oder irgendjemand der Linuxwelt "mangelnde Professionalität" vorgeworfen? Dein Frickel-Beispiel für ETS mit wine auf Linux (von hinten durch die Brust in den Kopf...) war von dir.

Ansonsten reden wir hier immer noch Desktop-Anwendungen für Endkunden, die typischerweise und regelmäßig keine SW Entwickler oder IT-Profis sind. In diesem Bereich hat Linux nach wie vor einen niedrigen einstelligen Prozentwert an Marktanteil. Was also im Backend für SW Sinn macht, macht noch lange keinen Sinn auf dem Desktop.

[DiMa]

darauf hin wurde mehrfach gesagt das die komplexität was die abhängikeit vom betriebsystem betrifft garnicht so komplex. die ets selber wäre von der art und weis was sie tun soll (nicht wie sie gebaut wurde) sogar recht simpel. eine einfache anwendung die nur etwas netzwerk macht - übertrieben gesprichen. diese aussage kann ich soweit unterschreiben.

Also ich habe da sicher nur alle möglichen Beiträge überlesen, aber ich kann mich an diesbzgl. Statements nur von dir und hater erinnern. Und denen habe ich widersprochen. Als Windows-, macOS-, Linux-, Android-, iOS- und noch ein paar echte Exoten -Entwickler.

[ewfwd]

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

In den meisten Fällen ist das erstmal ne Ausrede, ein Vorwand dass man nicht will. Die KNXA ist mitunter ja auch sehr erfinderisch "Begründungen" für alles Mögliche zu liefern, ich erinnere da nur noch mal an den unterschiedlichen "Verwaltungsaufwand" für das Übertragen einer ETS Lite und Pro Lizenz...

Egal um was es geht die KNXA "erklärt" immer erstmal wieso und was alles nicht geht...oftmals würde man sich hier mehr Ehrlichkeit wünschen und das würde ihnen auch keinen Zacken aus der Krone brechen...

Wieviel Support gibt es denn noch für die Loxone-Server der Generation1.

Was vergleichen wir jetzt hier? Wieviel Support gibt es noch für Gira und MDT Produkte die vor 10Jahren eingestellt worden sind?

Wie sieht der Support aus für eine ETS4 ?

Also MDT erklärt dir dass deren LED Controller der seit Einführung paar Revisionen (kein Nachfolgeprodukt!) erfahren hat zu alt sei wenn du gewisse Bugs dort feststellst...

Also man sollte jetzt nicht so tun dass für 10Jahre alte Hardware du einfach nur beim Hersteller anrufen musst und dann groß Support bekommst. Der "Support" besteht in der Regel dann auch nur aus einem "Produkt ist zu alt, bitte kaufen sie das Nachfolgeprodukt von uns"

Apropos Support. Kennt jemand den Hersteller GIRA ? Deren Support für den Endkunden besteht auch nur aus "nerv uns nicht, geh zu deinem Elektriker!"

Ich persönlich hatte selber noch keine Erfahrung mit dem Support von Loxone, vielleicht hattest du den als KNX Nutzer schon und kannst von persönlicher Erfahrung sprechen.

Man malt sich da in der KNX Welt halt einiges auch wirklich schön, auch wenn ich es selber nutze sollte man soviel Selbstreflektion besitzen anzuerkennen dass "hier" auch net alles toll ist...

Halten wir fest dass in BEIDEN Welten der "Support" einfach nur aus "ist zu alt, kauf was aktuelles" besteht bei alten Produkten..
Ich würde wetten bei Problemen mit der ETS4 würde der "Support" mir auch recht schnell dazu raten Geld in die Hand zu nehmen und upzudaten am besten gleich auf die ETS6 und weniger dass sich da sobald ich aufgelegt habe paar Programmierer ans Werk machen um ein Update für die ETS4 zu bringen...

[TomasM]

Du darfst auch deine Meinung haben. Ich teile sie nicht und unterstelle dir Unwissenheit

Oh vielen Dank, ich lass mich durchaus gerne belehren.

Verstehe ich dich aber richtig, das wenn ich jedes Jahr mein OSX Update auf ein neues Major Release (Mojave/Catalina/BigSur/Monte...usw..) durchführe, das die bestehende SW weiter reinbungslos funktioniert und es keinerlei Aufwand bedeuet diese zu erneuern bzw. zu testen ?

<Schon komisch das es bei mir nicht so ist..>

Warum gibt es dann fast jedes Jahr viele SW Produkte (z.B. VIrtuallisierungen etc.) (Foto/Video Produkte) die man Kostenpflichtig updaten muss damit sie auf der neuen OSX einwandfrei funktionieren ?

Natürlich kann ich mein OSX auch 4 Jahre oder länger laufen lassen, aber wenn die KNX.ORG ein ETS für OSX rausbringt und ich die Version aktuell halten möchte muss ich "sehr wahrscheinlich jedenfalls" auch immer auf die neuste Apple BS Version gehen. Die aktuellste ETS Version wird sicherlich nicht in der aktuellsten Version alle OSX Versionen gleichzeitig unterstützen können. Oder vielleicht ja doch weil es ja deiner Meinung nach kein Aufwand bedeutet.

Meine Prognose wäre das das ganze durchaus mit mehr Aufwand verbunden ist als wenn Du die ETS Version "nur" unter Windows rausbringst. Ausserdem wird sich der Aufwand dafür überhaupt nicht rechnen, da die Anzahl der Leute die sich für OSX ein ETS kaufen doch sehr übersichtlich sein wird.

[henfri]

es gab doch schon eine ETS unter Linux.

[traxanos]

es gab doch schon eine ETS unter Linux.

Ja die Inside und das war ein Flopp. U.a. konnte man nur ausgewälte Geräte nutzen (Online-Katalog und keine Plugins o.ä.)

[ewfwd]

da die Anzahl der Leute die sich für OSX ein ETS kaufen doch sehr übersichtlich sein wird.

Nochmal extra abkassieren wenn man schon eine Lizenz für Windows hat, dass man auch eine für MacOS hat? Ja das würde nach KNXA klingen

"Normal" wäre dass es für den Endanwender gar keine Rolle spielt ob er Windows oder MacOS nutzt und seine Lizenz einfach mitnehmen könnte...Man könnte es dem SI auch einfach vereinfachen wenn dieser auf Mac unterwegs ist und sich nicht mit VMs rumschlagen muss oder extra noch ein Windows Laptop anschaffen und mitschleppen muss...

[henfri]

Ja die Inside und das war ein Flopp. U.a. konnte man nur ausgewälte Geräte nutzen (Online-Katalog und keine Plugins o.ä.)

beantwortet aber doch einige hier heiss diskutierte punkte

[ewfwd]

Die ETS Inside sollte aber nie eine normale ETS sein die halt auch unter Linux läuft. Der Ansatz/Idee war ja eher eine andere das ganze war ja auch eine Server/Client Lösung...

[Thorsten1970]

Hey Leute,

ich hatte nicht vor hier eine Grundsatzdiskussion über Vor- und Nachteilen von Betriebssystemen haben, sondern nur eine einfache Abstimmung ob ihr auch ausser Windows ein anderes Betriebssystem für die ETS haben wollt. Mehr nicht.

Aus meiner Sicht gibt es so viele verschieden SWen (z.B. VisualStudioCode, ObenOffice, LibreOffice, Gimp, Firefox, Thunderbird, Calibre, Dataexplorer, uvm.), die auf diversen Betriebssystemen laufen - und das ohne Probleme. DataExplorer ist ein gutes Beispiel. Hier hat eine Person alleine die SW für Windows, Mac und Linux geschrieben. Schwierigkeit hier sind eben auch die diversen benötigten Treiber für USB und serielle Schnittstellen sowie die passenden HW Treiber für die diversen Ladegeräte. Man (KNXA) muss nur wollen!

Wenn genügend Personen mit dem Wunsch ETS für Mac und Linux auf die KNXA zugehen, dann bewegt sich was. Ansonsten passiert nichts.

Viele Grüße
Thorsten

[CaptainFuture]

Also ich persönlich habe ausschliesslich wegen der ETS ein laufendes Windows. Heutzutage ist doch für 99% der Menschen der Browser das Betriebssystem. Außer man hat sehr spezielle Software, die ein konkretes OS benötigt (aus technischen, historischen oder betriebswirtschaftlichen Gründen), ist doch vollkommen egal, ob man Mac, Linux oder Windows laufen hat. Von daher ist es für viele Menschen befremdlich, dass es solche Spezialsoftware gibt. Und bei der ETS hat es eben noch nicht mal technische Gründe.

[thengsty]

Ja verschrieben.. Sollte ein "noch" sein.

same here. Ich ärgere mich auch wöchentlich über das Gefrickel mit meinem Windows Notebook NUR damit die ETS etwas performanter läuft. In einer VM auf Ubuntu habe ich ETS nie so ans Laufen bekommen, dass es annehmbar wäre.