Was ist die bessere Programmierunggebung? Thinclients + Server oder Einzelplatzworkstations?



  • Ich entwickele beruflich unter Unix. Wir haben aber nicht für jeden Entwickler eine Unix-Kiste, sondern entwickeln alle auf einer. Clientseitig haben wir Notebooks, weil wir diese auch für die Rufbereitschaft benötigen. Ansonsten wäre es so ziemlich egal, was wir hier lokal stehen haben. Hauptsache es ist ein X-Server drauf.

    So eine Technik wird hier bereits seit fast 20 Jahren eingesetzt. Das ist nichts neues. Es wird heutzutage halt als neueste Technik verkauft. Das ganze funktioniert auch einwandfrei.

    Bei uns wird auch nicht jeden Tag mal irgendwelche Software installiert und wieder deinstalliert, da wir doch in der Regel eher programmieren, als Software ausprobieren.



  • PC-Profi schrieb:

    Ganz klar Einzelplatzworkstations. Als Entwickler möchte man schließlich die Möglichkeit haben Software zu installieren, testen, etc.

    Warum sollte das bei einer Thin-Client Lösung nicht möglich sein (Ausnahmen wie Spiele mal ausgenommen)?

    PC-Profi schrieb:

    Wenn die Kosten für die Geräte die Gesamtkosten maßgeblich beeinflussen macht ihr sowieso etwas falsch.

    Die Anschaffungskosten dürften selten eine Rolle spielen. Aber es macht halt einen Unterschied ob man n Systeme up-to-data halten muss oder halt nur eines.



  • tntnet schrieb:

    So eine Technik wird hier bereits seit fast 20 Jahren eingesetzt

    [...]

    Bei uns wird auch nicht jeden Tag mal irgendwelche Software installiert und wieder deinstalliert, da wir doch in der Regel eher programmieren, als Software ausprobieren.

    Wenn Ihr mit der Technik programmiert, die irgendwer vor 20 Jahren mal eingerichtet hat, wundert mich das gar nicht.

    Es gibt aber auch modernere Technologien, die dann doch mal den Einsatz verschiedener Tools zusätzlich zur Entwicklungsumgebung erfordern, wie z.B. Datenbanktools (evtl. lokale Test-Datenbanken), Servertools (evtl. lokaler Testserver), Netzwerktools, Grafiktools, etwaige andere CASE-Tools (UML und Co.) usw.

    Im übrigen gibts auch Usecases, die viele Remote-Desktops an ihre Grenzen bringen (bsp. Multimedia, Videos).



  • volkard schrieb:

    als programmierumgebung sind thin clients meiner erfahrung nach einfach nur müll.
    das liegt daran, daß jeden tag einer der entwickler eine endlosschleife bastelt und den server totalauslastet. die anderen clients fangen an zu ruckeln und mit der zweiten endlosschleife bleibt das ganze system stehen.

    kommt drauf an. wenn du als programmierumgebung die zielplattform selber verwendest, mag das ungünstig sein. aber dann brauchste sowieso weitreichende rechte, die mit 'nem multiuser-thin-client system nicht vereinbar sind. ich kenne welche, die entwickeln in Java auf 'ner sun-box (mit netbeans) und benutzen sogenannte 'ray-clients' als terminals. das funzt problemlos. der server hat 'nur' 4 prozessoren, aber selbst bei endlosschleifen wird die rechenzeit intelligent verteilt, so dass noch alles geht. nur der 'superuser' kann alle rechenpower an sich ziehen und damit das gesamte system lahmlegen.
    🙂



  • Thin Client schrieb:

    hustbaer schrieb:

    Wenn eine der "grossen" IDEs zum Einsatz kommt (NetBeans, Eclipse, Visual Studio, ...), dann auf jeden Fall Workstations. Diese IDEs brauchen einfach viel zu viel Resourcen,

    Wenn du so denkst, dann hast du gar nicht verstanden wie ein Thin Client funktioniert.

    Ein Thin Client ist im Prinzip nur ein Terminal.
    Der rechnet gar nichts.

    Die Berechnungen passieren alle auf dem Server.

    Ich habe schon verstanden, du kannst deinen Frust wieder einpacken 🙂

    Bloss bezweifle ich, dass ein dicker Server, der es schafft 50 User zu hosten, die alle 1-N Instanzen einer IDE offen haben und gleichzeitig damit arbeiten, weniger kostet (TCO), also 50 Boxen. Vielleicht verschätze ich mich damit auch.

    Was noch ein Faktor ist: als Entwickler braucht man oft Admin-Rechte, muss diverse Tools installieren etc. Wie gut sich das mit einem Terminal-Server verträgt weiss ich nicht, habe aber zumindest Bedenken. Natürlich hängt das stark davon ab was entwickelt wird.

    Nochmal was die Kosten angeht, vielleicht weisst du ja was so Kisten inetwa kosten. Also. Für 50 Leute, sagen wir mal ein Server mit mindestens 16 Cores, mindestens 64GB RAM, und einem dicken dicken RAID Array. Ich schätze mal grob aus mindestens 10 Stück 15k SAS/Fibre Platten, mit 1GB+ Battery-Backed Cache.

    Nur damit du die Anforderungen einschätzen kannst. Bei uns läuft pro User...
    * 1-3 Instanzen von Visual Studio 2005
    * TortoiseSVN, mit Working-Copies die gesamt gerne mal 100.000+ Files haben
    * bei einigen VisualSVN/AnkhSVN
    * Visual Assist X
    Und entwickelt wird C++. Mit Libraries wie Boost, Xerces-C, Crypto++ etc.

    Was das alleine schon von der Festplatte fordert, kann man sich schwer vorstellen, wenn man es selbst nicht erlebt hat. Genauso RAM und CPU. Wobei die CPU Leistung das ist, wo ich mir noch die wenigsten Gedanken mache - schliesslich compiliert nicht jeder gleichzeitig, und die ganzen Tools ala Tortoise, VAX etc. fressen nicht so wahnsinning viel CPU Zeit (die sind eigentlich alle Disk-bound).

    ----

    Vielleicht könntest du mir ja sagen ob ich deiner Meinung nach die Anforderungen falsch einschätze, und eine Terminal-Server Lösung, die inetwa gleich schnell für die 50 Entwickler ist, im Endeffekt billiger wäre.



  • byto schrieb:

    Ich kann mir beim besten Willen nicht vorstellen, produktiv über so einen Remote Desktop zu arbeiten.

    Nun, Thin Clients sind in der Regel geräuschlos und der Server steht im Serverraum.
    Ergonomischer kann man nicht arbeiten.

    Wir setzen sowas ähnliches für einen Kunden ein und die Latenz ist gegenüber ner Workstation schon deutlich spürbar.

    Wenn dem so ist, dann ist der Server zu schwach ausgebaut.

    Außerdem brauche ich als Entwickler die Freiheit, auch nachträglich noch Tools und Programme zu installieren, ohne erst Antrag 29392 auszufüllen, damit das irgendein Admin für mich irgendwann mal auf dem Server einrichtet.

    Unter Linux kann man in der Regel seine eigenen Programme ins eigene Homeverzeichnis installieren, wenn es nicht vom Admin abgestellt ist.

    Verrate doch mal, wie Du das realisieren willst. Sagen wir, es kommt eine IDE wie Eclipse zum Einsatz. Jeder Entwickler checkt den Quellcode aus dem Versionskontrollsystem aus.
    Was und wie willst Du da nun gemeinsamen Speicher nutzen?

    Genau so wie du bei der Objektorientierten Programmierung Methoden für mehrere Objekte verwenden kannst, so kannst du das gleiche auch in einem Multiusersystem machen.



  • volkard schrieb:

    als programmierumgebung sind thin clients meiner erfahrung nach einfach nur müll.
    das liegt daran, daß jeden tag einer der entwickler eine endlosschleife bastelt und den server totalauslastet. die anderen clients fangen an zu ruckeln und mit der zweiten endlosschleife bleibt das ganze system stehen.

    Dann gibt es auf diesem Server kein Quote zwischen Prozessen.
    Das könnte man aber einrichten, so daß die Lastverteilung noch für jeden genug übrig läßt.



  • Thin Client schrieb:

    Wir setzen sowas ähnliches für einen Kunden ein und die Latenz ist gegenüber ner Workstation schon deutlich spürbar.

    Wenn dem so ist, dann ist der Server zu schwach ausgebaut.

    Außerdem brauche ich als Entwickler die Freiheit, auch nachträglich noch Tools und Programme zu installieren, ohne erst Antrag 29392 auszufüllen, damit das irgendein Admin für mich irgendwann mal auf dem Server einrichtet.

    Unter Linux kann man in der Regel seine eigenen Programme ins eigene Homeverzeichnis installieren, wenn es nicht vom Admin abgestellt ist.

    Und was wenn Windows verwendet wird?



  • Naja da dieser Ansatz eher fremd für viele ist. ist hier das Feedback für ThinClients natürlich auch dementsprechend. Ich selbst hab damit auch noch nicht gearbeitet, habs aber mal von anderen gehört die das mal ne Zeitlang hatten.
    In der Theorie hört sich das alle schon nicht so schlecht an, aber es kann eben doch immer mal wieder zu Ausfällen/Überlastungen des Servers kommen, wobei das tatsächlich eher die Ausnahme darstellen sollte. Ein anderes Problem ist hier ja dann auch noch das Netzwerk. Wenn das mal weg ist, dann geht halt echt gar nichts mehr wie schon jemand anmerkte. Sowas kommt defintiv vor und schlägt dann ziemlich drastisch zu Buche wenn du z.b. von 50 Entwicklern ausgehst.
    Wieteres Problem ist tatsächlich die Performance der Clients. Es ist ein Trugschluss zu glauben dass der Client absolut unbeeinflusst z.B. von einer schwergewichtigen IDE ist (ja auch wenns aufm Server läuft).



  • volkard schrieb:

    als programmierumgebung sind thin clients meiner erfahrung nach einfach nur müll.
    das liegt daran, daß jeden tag einer der entwickler eine endlosschleife bastelt und den server totalauslastet. die anderen clients fangen an zu ruckeln und mit der zweiten endlosschleife bleibt das ganze system stehen.

    also thinclients sind schonmal außerhalb jeder diskussion.

    kann ich nur zustimmen. Grad heute hab ich mich mit 2 Jungs an die alten Zeiten im Uni-Pool (wo ich damals Studentadmin war) erinnert, wo wir um die 40 Sunrays an einem (schon damals 6 Jahren alten) Server hatten. Manchmap kamen 20 Leute gleichzeitg auf die Idee, Eclipse zu starten ... ich könnte nicht einmal per ssh 'kill' ausführen. Als Entwickler will ich meine eigene Maschine und noch dazu meine eigene Maschine selbst verwalten.



  • hustbaer schrieb:

    Thin Client schrieb:

    Wir setzen sowas ähnliches für einen Kunden ein und die Latenz ist gegenüber ner Workstation schon deutlich spürbar.

    Wenn dem so ist, dann ist der Server zu schwach ausgebaut.

    Unter Linux kann man in der Regel seine eigenen Programme ins eigene Homeverzeichnis installieren, wenn es nicht vom Admin abgestellt ist.

    Und was wenn Windows verwendet wird?

    Siehe Annahme im 1. Posting.
    Windows wird nicht verwendet.



  • nep schrieb:

    Es ist ein Trugschluss zu glauben dass der Client absolut unbeeinflusst z.B. von einer schwergewichtigen IDE ist (ja auch wenns aufm Server läuft).

    Nein ist es nicht, da der Client nur ein dummes Anzeigegerät ist.



  • Thin Client schrieb:

    byto schrieb:

    Ich kann mir beim besten Willen nicht vorstellen, produktiv über so einen Remote Desktop zu arbeiten.

    Nun, Thin Clients sind in der Regel geräuschlos und der Server steht im Serverraum.
    Ergonomischer kann man nicht arbeiten.

    Meine Workstation hier ist auch geräuschlos. Ergonomischer kann man nicht arbeiten.

    🤡

    Wir setzen sowas ähnliches für einen Kunden ein und die Latenz ist gegenüber ner Workstation schon deutlich spürbar.

    Wenn dem so ist, dann ist der Server zu schwach ausgebaut.

    Hat mit dem Server herzlich wenig zu tun, sondern viel mehr mit der Leitung. Aber vielleicht investiert besagter Autobauer auch einfach nur zu wenig Geld in die IT Infrastruktur.

    Verrate doch mal, wie Du das realisieren willst. Sagen wir, es kommt eine IDE wie Eclipse zum Einsatz. Jeder Entwickler checkt den Quellcode aus dem Versionskontrollsystem aus.
    Was und wie willst Du da nun gemeinsamen Speicher nutzen?

    Genau so wie du bei der Objektorientierten Programmierung Methoden für mehrere Objekte verwenden kannst, so kannst du das gleiche auch in einem Multiusersystem machen.

    Wenn jeder Entwickler seinen eigenen Workspace auscheckt, dann kann man da auch nichts im Speicher sharen. Korrigiere mich, wenn ich mich irre.



  • nep schrieb:

    Ein anderes Problem ist hier ja dann auch noch das Netzwerk. Wenn das mal weg ist, dann geht halt echt gar nichts mehr wie schon jemand anmerkte.

    deshalb sollte man auch ein separates netz (z.b. mit eigenen leitungen) für das hausinterne thin-client system anlegen. und da sollte natürlich auch keiner seinen virenverseuchten wintel-pc anstöpseln, der permanent was ins netz senden will.

    nep schrieb:

    Wieteres Problem ist tatsächlich die Performance der Clients. Es ist ein Trugschluss zu glauben dass der Client absolut unbeeinflusst z.B. von einer schwergewichtigen IDE ist (ja auch wenns aufm Server läuft).

    warum? vielleicht wenn du von irgendwelchen basteleien wie 'windows terminal server' u.ä. remote-desktop 'lösungen' ausgehst, wobei auf den clients selbst oft schwergewichtige betriebssysteme laufen. bei den sun-rays ist es aber nicht so.
    🙂



  • +fricky schrieb:

    nep schrieb:

    Ein anderes Problem ist hier ja dann auch noch das Netzwerk. Wenn das mal weg ist, dann geht halt echt gar nichts mehr wie schon jemand anmerkte.

    deshalb sollte man auch ein separates netz (z.b. mit eigenen leitungen) für das hausinterne thin-client system anlegen. und da sollte natürlich auch keiner seinen virenverseuchten wintel-pc anstöpseln, der permanent was ins netz senden will.

    Blabla, wie schon gesagt, man kann da echt viel machen, aber du wirst es definitiv nie vermeiden können, dass das Netz mal weg ist.

    +fricky schrieb:

    nep schrieb:

    Wieteres Problem ist tatsächlich die Performance der Clients. Es ist ein Trugschluss zu glauben dass der Client absolut unbeeinflusst z.B. von einer schwergewichtigen IDE ist (ja auch wenns aufm Server läuft).

    warum? vielleicht wenn du von irgendwelchen basteleien wie 'windows terminal server' u.ä. remote-desktop 'lösungen' ausgehst, wobei auf den clients selbst oft schwergewichtige betriebssysteme laufen. bei den sun-rays ist es aber nicht so.
    🙂

    Mag schon sein, aber meistens kommst du eben um solche Dinge doch nicht wirklich rum. Gibt halt oft die verschiedensten Anforderungen die du nicht so einfach abdecken kannst, ohne dass der Client eine Rolle gibt. Für manche Fälle mag dies aber vielleicht anders sein.



  • nep schrieb:

    Blabla, wie schon gesagt, man kann da echt viel machen, aber du wirst es definitiv nie vermeiden können, dass das Netz mal weg ist.

    selber blah. das liegt leider in der natur der sache bei zentralisierten systemen: fällt was an der basis aus, dann ist alles tot. du kannst es dir aussuchen. übertriebene redundanz (= viele fette desktop-maschinen), dafür ausfallsicherheit (ok, nicht wirklich, wenn einer die hauptsicherung zieht), dafür hohe kosten, hoher energieverbrauch und hoher administrationsaufwand. oder stressfreiheit, geringe kosten, flexibilität (jeder kann sich einloggen wo er will und findet seinen desktop vor).
    🙂



  • Ich sage: Workstations. Heutzuitage ist es ja kein Problem 50 Workstations auf einmal zu installieren.
    Auch U2D zu halten nicht.
    Auch wenn man 2 Server da hinstellt können die Ausfallen.
    Siehe TMOBILE mit 3 Servern und 2 gehen nicht.
    Kostenfrage kann es nicht sein da der Server unmengen kosten muss.
    Ein ordentlicher Admin kommt mit 50 Workstations auch zurecht.



  • Ich habe zur Zeit das "Vergnügen" mit einer Sun Ray 1 zu arbeiten, wobei die Session selbst auf einem Solaris Server, Eclipse auf einem Linux Server läuft.
    Ich weiß nicht, ob es am Netz oder dem alten Client liegt, aber es ist einfach nur zäh, obwohl die Server schon ziemlich dick und auf jedem vielleicht höchstens ein Dutzend Leute unterwegs sind.



  • +fricky schrieb:

    nep schrieb:

    Blabla, wie schon gesagt, man kann da echt viel machen, aber du wirst es definitiv nie vermeiden können, dass das Netz mal weg ist.

    selber blah. das liegt leider in der natur der sache bei zentralisierten systemen: fällt was an der basis aus, dann ist alles tot. du kannst es dir aussuchen. übertriebene redundanz (= viele fette desktop-maschinen), dafür ausfallsicherheit (ok, nicht wirklich, wenn einer die hauptsicherung zieht), dafür hohe kosten, hoher energieverbrauch und hoher administrationsaufwand. oder stressfreiheit, geringe kosten, flexibilität (jeder kann sich einloggen wo er will und findet seinen desktop vor).
    🙂

    Desktop-Hardware ist mittlerweile eher billig und wenn man nicht gerade triple-sli Grafikkarten einsetzt ist der Stromverbrauch einer Workstation auch erträglich. Serverhardware dagegen ist nach wie vor teuer. Ich könnte mir shcon vorstellen das die Kosten von 50 Desktop-Systemen niedriger sind als die Kosten eines Server-Systems/Netzwerks das 50 Entwickler hosten soll.

    Nebenbei. Die teuerste Einzelkomponente meines Arbeitsplatzes ist immer noch der Bildschirm...

    +fricky schrieb:

    (ok, nicht wirklich, wenn einer die hauptsicherung zieht)

    Nicht wenn als Workstations Laptops eingesetzt werden. Da kann man zur Not auch mal einige Stunden ohne Strom arbeiten...

    +fricky schrieb:

    stressfreiheit

    Ich bezweifele schwer das der Admin eines Servers auf dem 50 Entwickler arbeiten ein stressfreies Leben hat, ich denke eher das Gegenteil ist der Fall. Jeder noch so kleine Ausfall bedeutet gleich 50 Entwickler die nicht arbeiten können. Eine Stunde Ausfall entsprechen da 50 Mannstunden, sowas geht mächtig ins Geld.



  • loks schrieb:

    +fricky schrieb:

    (ok, nicht wirklich, wenn einer die hauptsicherung zieht)

    Nicht wenn als Workstations Laptops eingesetzt werden. Da kann man zur Not auch mal einige Stunden ohne Strom arbeiten...

    dann aber nur mit externer tastatur und extra mäuschen. ausserdem stell ich mir lieber 'nen flachbildschirm auf den tisch, als einen tief auslagerden schlepptop.

    loks schrieb:

    Ich bezweifele schwer das der Admin eines Servers auf dem 50 Entwickler arbeiten ein stressfreies Leben hat, ich denke eher das Gegenteil ist der Fall. Jeder noch so kleine Ausfall bedeutet gleich 50 Entwickler die nicht arbeiten können. Eine Stunde Ausfall entsprechen da 50 Mannstunden, sowas geht mächtig ins Geld.

    der witz ist ja, dass solche serversysteme so gut wie nie ausfallen. die kannste nicht vergleichen mit irgendwelchen wackeligen windows-pcs, die wegen virenbefall, bugs und qualitativ minderwertiger hardware, öfter mal zuwendung brauchen.
    🙂


Anmelden zum Antworten