Von Arbeitnehmer am Mi, 3. Februar 2016 um 14:45 #
Als Arbeitnehmer der DRV BUnd kann ich aber sagen das ist nur auf dem Server so. Auf den Clients sieht man davon nichts, hier gibt es nur Windows XP oder Windows 7 mit MS Office und Lotus Notes, Naja und die spezifische Software in Java und oder oder Cobol.
das ist ja gerade das Drama .. auf dem Server keine Problem aber auf dem Client läuft nix. Dabei wäre es in diesem Fall soo einfach. Java-Software ist ja prinzipbedingt sehr einfach zu migrieren oder läuft einfach so .. . Und da es mit Sicherheit eine hausinterne Software ist kann auch keiner sagen: 'besonderer Aufwand .. alle anderen Kunden wollen Windows'.
Wo ist der Grund? Wie in Niedersachsen bei der Polizei? Die Entwickler arbeiten mit Windows-Umgebungen -Tools und da ist der Testaufwand erheblich ... ??
Ich denke der Grund liegt in der ungewohnten UI. Setze mal jemanden der Windows gewohnt ist vor GNOME 3. Ich würde das meinen Mitarbeitern auch nicht antun wollen. Ja es gibt andere Oberflächen, aber das ist den meisten denke ich zu riskant, auf eine DE zu setzen, die evtl. in 5 Jahren nicht mehr supportet wird.
Auch haben gerade GUI-Anwendungen in Java Bugs auf verschiedenen DEs (z. B. das Global Menu in Unity, Tray-Icons in GNOME, ...).
Ich glaube, das ist nicht nur die ungewohnte UI, sondern dass an ihr vergleichsweise häufig rumgeschraubt wird. Linux ist halt eine Dauerbaustelle.
Firmen und Behörden sind von der extrem langen Lebensdauer der Windows-XP-Umgebung verwöhnt.
Keine Umschulungen, kaum API-Änderungen, die Änderungen an den Fachanwendungen erfordern - da hat man die Lizenzgebühren und die schlechtere Sicherheit von Windows in Kauf genommen.
Mit Windows 10 werden die Grosskunden aber vermutlich das Umdenken beginnen müssen. Mit Windows 10 hat Microsoft die bewährte Taktik, alles möglichst lange stabil zu halten, über Bord geworfen, Vielleicht gewinnt der Linux-Desktop in Firmenumfeld dadurch an Attraktivität.
Lizenzgebühren von 1000EUR je Arbeitsplatz spielen bei einer Laufzeit von 5-10Jahren im Vergleich zu Personalkosten auch nur eine untergeordnete Rolle.
>> Keine Umschulungen, kaum API-Änderungen, die Änderungen an den Fachanwendungen erfordern
Durch die ständigen Neuentwicklungen und Änderungen in den KDE/Gnome Desktops kams auch immer wieder zu Problemen/Bugs. Solche Probleme gibt es bei Windows praktisch ab dem SP1 bis zum Ende des 10Jahre Supports nicht mehr. Dabei können unter Windows auch nach 6Jahren trotzdem aktuelle Apps ohne Probleme installiert werden. Dies ist unter GNU/Linux so auch kaum ohne größere Systemupdates an Libs/etc machbar. Solche Systemupdates führen dann oftmals zu unbekannten Seiteneffekten/PÜroblemen in der Distro die dann für eine IT-Administration nur noch aufwendig händelbar sind. Das ist dann einfach mistig. Zusätzlich kommen Bugs/Probleme die zumindestens in Openoffice1/2/3 zweifelslos da waren, und im Firmenumfeld auch gestört haben.
Ich glaube, das ist nicht nur die ungewohnte UI, sondern dass an ihr vergleichsweise häufig rumgeschraubt wird. Linux ist halt eine Dauerbaustelle.
Nur weil man bei freie Software und speziell bei Linuxdistributionen so nahe an der Entwicklung dran sein kan wie man möchte, heißt das noch lange nicht, dass man das auch tun sollten.
Diese Firmen würden ja auch keinen Internen Windows Build installieren wenn sie drauf Zugriff hätten.
Wenn man also lieber Änderungssprünge mit relativer Ruher dazwischen haben will, dann sollte man vielleicht kein SUSE Tumbleweed einsetzen.
Wer im professionellen Umfeld Gnome 3, KDE oder Unity einsetzt, braucht sich wegen Abneigungen nicht zu wundern. Ich setze bei meinen Firmenkunden ausschließlich Cinnamon - und zwar mit sehr großem Zuspruch - ein. Bedienung ist schnell zu lernen, übersichtlich und logisch.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 03. Feb 2016 um 19:17.
Aus Neugierde, auf welcher Distribution setzt du Cinnamon ein, und wie stabil ist das ganze? Ich selbst nutze Gnome3 im Classicmodus und arbeite damit professionell und es gibt von niemanden da irgend ein Spruch. Mate setze ich auch ab und zu ein, aber es ist an vielen Stellen nicht ganz fertig - also muss ich schauen in wie fern es vertretbar ist.
Von Arbeitnehmer am Mi, 3. Februar 2016 um 15:01 #
ja auch und du das das alte Cobolzeug, Lihenzen die nur für Windows gelten und nätürlich den Punkt das die DRV Bund nur einer von mehreren Trägern ist und sich die Software teilweise überschneiden oder auch nicht (sogar beim Kernsystem).
Von Ich genauso mal am Do, 4. Februar 2016 um 08:20 #
>>Java-Software ist ja prinzipbedingt sehr einfach zu migrieren oder läuft einfach so .. . Kann nur jemand sagen, der mit Java-basierter Software noch nie viel zu tun hatte...
Die viel gerühmte (theoretische) Plattformunabhängigkeit von Java zeichnet sich in der bösen Realität immer wieder durch zig Ausnahmen aus. Deshalb liefert auch fast jeder Hersteller seine eigene JRE mit auf der getestet wurde
Natürlich kann man auch auf einer Multiplattformbasis eine Singleplattformlösung schaffen, aber man ist meistens näher an einer Multiplattformlösung als wenn man mit einer plattformspezifischen Basis startet.
Was noch dazu kommt ist, dass eine Multiplattformbasis es erlaubt, in den heute sehr verbreiteten Server/Client Anwendungen Codeteile zwischen Server und Client zu teilen.
Oft haben die unterschiedlichen Plattformen auch unterschiedliche Werkzeuge zur Verfügung, deren Funktionsumfang ergängend ist und somit z.B. die Qualität der Software verbessern auch wenn sie vielleicht nur auf einer Plattform ausgeliefert wird.
Als Arbeitnehmer der DRV BUnd kann ich aber sagen das ist nur auf dem Server so. Auf den Clients sieht man davon nichts, hier gibt es nur Windows XP oder Windows 7 mit MS Office und Lotus Notes, Naja und die spezifische Software in Java und oder oder Cobol.
das ist ja gerade das Drama .. auf dem Server keine Problem aber auf dem Client läuft nix. Dabei wäre es in diesem Fall soo einfach.
Java-Software ist ja prinzipbedingt sehr einfach zu migrieren oder läuft einfach so .. . Und da es mit Sicherheit eine hausinterne Software ist kann auch keiner sagen: 'besonderer Aufwand .. alle anderen Kunden wollen Windows'.
Wo ist der Grund? Wie in Niedersachsen bei der Polizei? Die Entwickler arbeiten mit Windows-Umgebungen -Tools und da ist der Testaufwand erheblich ... ??
Ich denke der Grund liegt in der ungewohnten UI. Setze mal jemanden der Windows gewohnt ist vor GNOME 3. Ich würde das meinen Mitarbeitern auch nicht antun wollen.
Ja es gibt andere Oberflächen, aber das ist den meisten denke ich zu riskant, auf eine DE zu setzen, die evtl. in 5 Jahren nicht mehr supportet wird.
Auch haben gerade GUI-Anwendungen in Java Bugs auf verschiedenen DEs (z. B. das Global Menu in Unity, Tray-Icons in GNOME, ...).
Als Programmierer ist es mir (auch von meinem Aufgabengebiet her) egal, aber wir kriegen halt nur Windows.
Ich würde auch keinen, welcher KDE gewöhnt ist, Gnome zumuten.
Das Flehen der Entwickler: Bitte gebt mir wenigstens eine Konsole statt ein Gnome-Terminal
Entwickler sind eben faul ...
Ich glaube, das ist nicht nur die ungewohnte UI, sondern dass an ihr vergleichsweise häufig rumgeschraubt wird. Linux ist halt eine Dauerbaustelle.
Firmen und Behörden sind von der extrem langen Lebensdauer der Windows-XP-Umgebung verwöhnt.
Keine Umschulungen, kaum API-Änderungen, die Änderungen an den Fachanwendungen erfordern - da hat man die Lizenzgebühren und die schlechtere Sicherheit von Windows in Kauf genommen.
Mit Windows 10 werden die Grosskunden aber vermutlich das Umdenken beginnen müssen. Mit Windows 10 hat Microsoft die bewährte Taktik, alles möglichst lange stabil zu halten, über Bord geworfen, Vielleicht gewinnt der Linux-Desktop in Firmenumfeld dadurch an Attraktivität.
Lizenzgebühren von 1000EUR je Arbeitsplatz spielen bei einer Laufzeit von 5-10Jahren im Vergleich zu Personalkosten auch nur eine untergeordnete Rolle.
>> Keine Umschulungen, kaum API-Änderungen, die Änderungen an den Fachanwendungen erfordern
Durch die ständigen Neuentwicklungen und Änderungen in den KDE/Gnome Desktops kams auch immer wieder zu Problemen/Bugs. Solche Probleme gibt es bei Windows praktisch ab dem SP1 bis zum Ende des 10Jahre Supports nicht mehr. Dabei können unter Windows auch nach 6Jahren trotzdem aktuelle Apps ohne Probleme installiert werden. Dies ist unter GNU/Linux so auch kaum ohne größere Systemupdates an Libs/etc machbar. Solche Systemupdates führen dann oftmals zu unbekannten Seiteneffekten/PÜroblemen in der Distro die dann für eine IT-Administration nur noch aufwendig händelbar sind. Das ist dann einfach mistig.
Zusätzlich kommen Bugs/Probleme die zumindestens in Openoffice1/2/3 zweifelslos da waren, und im Firmenumfeld auch gestört haben.
Nur weil man bei freie Software und speziell bei Linuxdistributionen so nahe an der Entwicklung dran sein kan wie man möchte, heißt das noch lange nicht, dass man das auch tun sollten.
Diese Firmen würden ja auch keinen Internen Windows Build installieren wenn sie drauf Zugriff hätten.
Wenn man also lieber Änderungssprünge mit relativer Ruher dazwischen haben will, dann sollte man vielleicht kein SUSE Tumbleweed einsetzen.
Wer im professionellen Umfeld Gnome 3, KDE oder Unity einsetzt, braucht sich wegen Abneigungen nicht zu wundern. Ich setze bei meinen Firmenkunden ausschließlich Cinnamon - und zwar mit sehr großem Zuspruch - ein. Bedienung ist schnell zu lernen, übersichtlich und logisch.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 03. Feb 2016 um 19:17.Aus Neugierde, auf welcher Distribution setzt du Cinnamon ein, und wie stabil ist das ganze? Ich selbst nutze Gnome3 im Classicmodus und arbeite damit professionell und es gibt von niemanden da irgend ein Spruch. Mate setze ich auch ab und zu ein, aber es ist an vielen Stellen nicht ganz fertig - also muss ich schauen in wie fern es vertretbar ist.
ja auch und du das das alte Cobolzeug, Lihenzen die nur für Windows gelten und nätürlich den Punkt das die DRV Bund nur einer von mehreren Trägern ist und sich die Software teilweise überschneiden oder auch nicht (sogar beim Kernsystem).
>>Java-Software ist ja prinzipbedingt sehr einfach zu migrieren oder läuft einfach so .. .
Kann nur jemand sagen, der mit Java-basierter Software noch nie viel zu tun hatte...
Die viel gerühmte (theoretische) Plattformunabhängigkeit von Java zeichnet sich in der bösen Realität immer wieder durch zig Ausnahmen aus.
Deshalb liefert auch fast jeder Hersteller seine eigene JRE mit auf der getestet wurde
Natürlich kann man auch auf einer Multiplattformbasis eine Singleplattformlösung schaffen, aber man ist meistens näher an einer Multiplattformlösung als wenn man mit einer plattformspezifischen Basis startet.
Was noch dazu kommt ist, dass eine Multiplattformbasis es erlaubt, in den heute sehr verbreiteten Server/Client Anwendungen Codeteile zwischen Server und Client zu teilen.
Oft haben die unterschiedlichen Plattformen auch unterschiedliche Werkzeuge zur Verfügung, deren Funktionsumfang ergängend ist und somit z.B. die Qualität der Software verbessern auch wenn sie vielleicht nur auf einer Plattform ausgeliefert wird.
"Das Projekt ist auf vier Jahre und 960 Personentage [...] ausgelegt."
960:4=240 Personentage/Jahr = 1 Mitarbeiter
Hmmm.....