Was ist die bessere Programmierunggebung? Thinclients + Server oder Einzelplatzworkstations?
-
Thin Client schrieb:
Die Berechnungen passieren alle auf dem Server.
Der Server hat aber auch nicht endlos Ressourcen - da ist irgendwann auch mal Feierabend.
-
Knuddlbaer schrieb:
Thin Client schrieb:
Die Berechnungen passieren alle auf dem Server.
Der Server hat aber auch nicht endlos Ressourcen - da ist irgendwann auch mal Feierabend.
Richtig, deswegen legt man ihn so leistungsfähig aus, daß die Thin-Client Benutzer nicht merken, daß die ganzen Berechnungen der Server macht.
Und zukünftig hat man mit dieser Infrastruktur nur noch Vorteile, da man nur noch den Server updaten muß, während für die Thin Clients keine weiteren kosten anfallen, solange sie funktionstüchtig sind.
Und wenn mal ein Thin Client ausfallen sollte, dann stellt man ein Ersatzthinclient schnell hin und kann ohne viel Arbeit gleich weiterarbeiten.
-
Ich hab davon leider wenig Ahnung, eventuell magst Du mir dennoch die Frage beantworten:
Gehe ich recht der Annahme, das für jeden ThinClient eine Instanz der Software auf dem Server laufen muss ? Wenn ja würde ich die Aussage von Hustbaer unterstützen. Wenn nein stellt sich die Frage, wie jeder für sich Vernünftig arbeiten kann (und ich muss mich dringend mal mit dem Thema näher beschäftigen.)
-
Thin Client schrieb:
Und wenn mal ein Thin Client ausfallen sollte, dann stellt man ein Ersatzthinclient schnell hin und kann ohne viel Arbeit gleich weiterarbeiten.
Natürlich unterschlägst Du mal eben den worst case fall: Wenn der Server ausfällt können 50 Leute nicht mehr arbeiten. Nennt sich Single Point of Failure. Wenn dagegen ein Desktop ausfällt kann genau ein Entwickler nicht mehr arbeiten. Dabei reicht es schon wenn das Netzwerk ausfällt.
-
loks schrieb:
Thin Client schrieb:
Und wenn mal ein Thin Client ausfallen sollte, dann stellt man ein Ersatzthinclient schnell hin und kann ohne viel Arbeit gleich weiterarbeiten.
Natürlich unterschlägst Du mal eben den worst case fall: Wenn der Server ausfällt können 50 Leute nicht mehr arbeiten. Nennt sich Single Point of Failure. Wenn dagegen ein Desktop ausfällt kann genau ein Entwickler nicht mehr arbeiten. Dabei reicht es schon wenn das Netzwerk ausfällt.
Es wurde schon geschrieben das der Server insofern redunant ist, daß eine Hälfte des Servers ausfallen darf ohne das dabei die Arbeit der User verhindert wird.
Im Prinzip kannst du dir das also als 2 Server vorstellen, die redunant arbeiten.
-
Knuddlbaer schrieb:
Ich hab davon leider wenig Ahnung, eventuell magst Du mir dennoch die Frage beantworten:
Gehe ich recht der Annahme, das für jeden ThinClient eine Instanz der Software auf dem Server laufen muss ? Wenn ja würde ich die Aussage von Hustbaer unterstützen.
Gleiche Bibliotheken und Programmcode werden natürlich nicht mehrfach in den Speicher geladen.
Aber jeder Nutzer hat seinen eigenen Prozess.Wenn nein stellt sich die Frage, wie jeder für sich Vernünftig arbeiten kann (und ich muss mich dringend mal mit dem Thema näher beschäftigen.)
Siehe oben.
Für jeden Nutzer wirkt der Thin Client so, als säße er vor seinem eigenen Desktoprechner.
-
hustbaer schrieb:
Aber weil es "in" ist, muss man es natürlich trotzdem so machen
'in' ist es seit 10 jahren. wenn nicht länger.
-
Ich kann mir beim besten Willen nicht vorstellen, produktiv über so einen Remote Desktop zu arbeiten. Wir setzen sowas ähnliches für einen Kunden ein und die Latenz ist gegenüber ner Workstation schon deutlich spürbar.
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.Gleiche Bibliotheken und Programmcode werden natürlich nicht mehrfach in den Speicher geladen.
Aber jeder Nutzer hat seinen eigenen Prozess.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?
-
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.
und was ist das überhaupt für ein gegensatz, entweder thin clients oder fat workstations zu nehmen?
nimm doch einfach thin workstations und verteile, was geht. anscheinend ist das kein spieleentwicklungsbüro. also reichen rechner mit onboard-grafik. schonmal 100 watt gespart.die compilefarm bringt nur so viel, wie sie bestückt werden kann. ich hab hier nen sehr lahmen viac7@400MhZ und einen neuen atom dualcore mit hyperthreading. der sehr lahme schafft es einfach nicht, den atom mit verteiltem compilieren auszulasten. daran würden wohl auch 50 weitere rechner in der compilefarm nichts ändern.
der atom mit vier virtuellen cpus compiliert langsamer als mein alter singlecore amd mit 1800MhZ.
leider zu langsam, um bezahlte mitarbeiter darauf warten zu lassen.also denke ich an normale office-pcs.
-
Ganz klar Einzelplatzworkstations. Als Entwickler möchte man schließlich die Möglichkeit haben Software zu installieren, testen, etc.
Da ist ein gemeinsam genutzter Server einfach ungeeignet. Wenn die Kosten für die Geräte die Gesamtkosten maßgeblich beeinflussen macht ihr sowieso etwas falsch.
-
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.