Diskussion:Thin Client

Könnte man den Artikelnamen nicht irgendwie deutsch formulieren? --Wikinator 19:56, 2. Apr 2004 (CEST)

Mir ist noch nie ein deutscher Begriff dafür über den Weg gelaufen. Ich halte den englischen Begriff durchaus für gerechtfertigt.

Naja, früher nannte man sowas "dummes Terminal". Aber das klingt halt nicht so schick. Davon mal abgesehen: Bei Benamsungen zählt im Zweifelsfall immer das, was üblich ist, nicht irgendwelche ideologischen Kleinkriege. Wenn jemand den Begriff "Thin Client" hört, dann möchte er halt diesen Begriff nachschlagen können und nicht erst lang und breit suchen, ob es einen deutschen Ersatzbegriff gibt. Wie ich schon in anderen Zusammenhängen mehrfach erwähnt habe: Wikipedia soll Informationen zugänglich machen, nicht verstecken. Davon mal abgesehen ist "Terminal" ja auch wieder englisch. --Duschgeldrache2 00:11, 22. Apr. 2009 (CEST)

Abgrenzung "Fat Client" - "Thin Client" - "Ultra Thin Client"

Im Artikel tauchen, vermutlich aufgrund von schwammigen oder unterschiedlichen Definition, Widersprüche auf. Diese führen dazu, dass keine einheitliche Definition der Client-Arten erkennbar ist.

Beispiel: Kann ein Thin-Client umfangreiche Datenverarbeitungen ausführen (Absehen von der Transformation zu Darstellung- bzw. Kommunikationszwecken)?

Entweder ist hier eine einheitliche Darstellung einzuführen, oder man muss die ungenaue bzw. widersprüchliche Definition(en) hervorheben.

Vermutlich ist auch eine Trennung zwischen einer hardwareorientierten und einer softwaremodellorientierten Sichtweise vorzunehmen.

217.146.152.250 12:47, 7. Nov. 2006 (CET) (Achim Hensel)

Textergänzungen

Ich sehe Klärungsbedarf bei den Ergänzungen vom 26.03.07 (letzter Absatz des Abschnitts "Nachteile"):

Lokal installierte Hardware ist nicht direkt angebunden. Dies führt zu Inkompatibilitäten bei speziellen Geräten, da ihr Protokoll nicht bei der Übertragung unterstützt wird.

Ich kann mir nicht so recht was unter Geräten vorstellen, die ihre eigenen Protokolle mitbringen. Gibt es Beispiele? "Nicht direkt angebunden" soll heißen "vom Server her nicht ansprechbar"?

Große Datenvolumina können von der Peripherie nicht direkt auf den Thin Client übertragen werden (z.B. DVD, Filmdaten per FireWire etc.), sondern müssen zuerst auf den Server geladen werden.

Wie verhält es sich damit, wenn man eine Umgebung hat, in der die DVD-Laufwerke des Servers vom Client her angesprochen werden können? Kann man dann auch sagen, dass die Daten zuerst auf den Server geladen werden, wenn sie vom Client her abgerufen werden? (Unter "auf den Server laden" dürften die meisten Leute "auf die Festplatte des Servers laden" verstehen.) -- Kerbel 23:47, 2. Apr. 2007 (CEST)

Ist PXES noch OpenSource?

In der Linkliste ist das Projekt PXES zu finden. Das Projekt ist von SourceForge weggezogen und ist nun unter http://www.2x.com/pxes/ zu finden. Den Source Code konnte ich dort nicht finden und es ist nur noch eine 30-Tage-Testversion downloadbar. Kann dies jemand bestätigen?

Die Tatsache, dass der Quellcode nicht öffentlich ist, spricht nicht gegen OpenSource. Es reicht laut GPL 2, wenn der Quellcode dem Nutzer vorliegt (nicht signierter Beitrag von Computerbauer (Diskussion | Beiträge) 14:54, 1. Jan. 2016 (CET))

Behauptung: Thin Clients wären geräuschlos

Halt ich für ein Gerücht, Prozessor und Netzteil z.B. müssen doch gekühlt werden. Gerade wenn kurz vorher die Rede von alten Rechnern ist, bezweifle ich, dass diese dann über passiv gekühlte CPUs verfügen! Irgendwie scheint der Autor dieses Abschnittes davon auszugehen, dass keiner sich selber einen TC zusammen bastelt. [Signatur?]

Klar muss ein alter PC mit Ventilatoren diese weiterhin auch als Thin Client benutzen. Aber moderne Thin Clients brauchen vielleicht 5 W und lassen sich leicht rein passiv kühlen. --Theosch 22:46, 4. Jul. 2009 (CEST)

Netzwerkboot (PXE,Etherboot) unterbewertet

In diesem Artikel wird zwar richtig zwischen Thick und Thin Client unterschieden (auch wenn das Lemma "Thin Client" heißt) - die Variante, ganz auf lokalen Speicher zu verzichten und per PXE oder Netboot zu starten wird m.E. aber ggü. anderen Protokollen zu knapp dargestellt.

Solche Mini-ITX-Geräte (z.B. Thin Can) sind auch unter Terminal (PC) zu finden, besitzen keine beweglichen Teile und ein externes lüfterloses Netzteil.

Wenn sich "Thin Client" schon nicht als "Dummes Terminal" übersetzen lässt, sollte wenigstens benannt werden: Warum "dünn"/"dumm"?

-> geringe Ressourcen/schache Hardware

-> keine lokale Datenspeicherung/Installation

-> geringe Grüße/Verbrauch

-> geringe Kosten

(nicht signierter Beitrag von 88.77.85.32 (Diskussion) )

Mischformen

Habe den folgenden Satz erst mal entfernt:

Durch zunehmenden Einsatz von Opensource Software lassen sich Thin Clients jedoch in immer mehr Bereichen einsetzen, da hierdurch eine Mischform zwischen Thin und Fat Client entsteht, die erst durch effizientere Software ermöglicht wird.

Hier bleibt unklar: Welche Opensource Software? Welche Mischform? effizientere Software? Zum Thema Mischformen gehört auch eine Abgrenzung zu Smart Client und Java Web Start. Hier spielt auch Software jenseits der Opensourcewelt eine Rolle--Temporäres Interesse 10:48, 23. Okt. 2008 (CEST)

IGEL Technology Marktführer?

Gibt's dafür einen Nachweis? Wenn nicht: Den betreffenden Absatz löschen. (nicht signierter Beitrag von 217.83.73.139 (Diskussion | Beiträge) 11:04, 21. Mär. 2009 (CET))

Laut Geschäftsbereicht von Igel sind sie Marktführer in Deutschland. Sie verweisen dort auf eine Untersuchung der IDC aus dem Jahr 2008. Diese Untersuchung liegt mir nicht vor, daher lasse ich den Absatz draußen. --Temporäres Interesse 08:41, 12. Jun. 2009 (CEST)

Ersten beiden Absätze

Vor zwei Tagen wurden die ersten beiden Absätze hinzugefügt. Sie sind an vielen Stellen grammatikalisch falsch und gehören da vor die eigentliche Definition auch gar nicht hin. Ich wollte sie nicht direkt rauslöschen, sondern vorher lieber mal nachfragen. Wäre nett, wenn das mal jemand überprüfen könnte. --A1bi 20:14, 1. Dez. 2010 (CET)

Übersetzung Client

Ich finde es etwas merkwürdig in diesem Zusammenhang Client mit Kunde zu übersetzen. Am passensten finde ich hier Mandant, insbesondere wenn ich mir die Bedeutung von mandantenfähig ansehe. Die 1:1-Übersetzung Klient scheint mir auch noch schlüssig. --Ifm (Diskussion) 09:13, 15. Apr. 2014 (CEST)

Zweiter Absatz

Der Grund für den Einsatz von Thin Clients sind nahezu nie die niedrigeren Anschaffungskosten (auch die Betriebskosten sind kaum ein Argument), da das Backend mit Hardware, Software und Lizenzen in der Regel damit deutlich wächst und diesen Kostenvorteil wieder aufhebt. In der Regel sind die Anschaffungenskosten einer Thin Client Umgebung somit sogar höher. Da Hauptgrund für den Einsatz eines Thin Clients ist die Entsdcheidung zur Virtualisieren und somit ein zenrtales Management der Systeme zu ermöglichen. Somit liegen die Kostenvorteile zur TCO in den eingesparten Administrationskosten. Auch die erhöhte Sicherheit (Daten liegen sicher im Rechenzentrum) ist oft eine Grundlage für den Umstieg.--195.127.188.197 11:49, 21. Okt. 2014 (CEST) (IceT)

Ich sehe ebenfalls den "Kosteneinsparungseffekt" als in den meisten Fällen in der Propagandaabteilung der Anbieter geborene Behauptung. Natürlich gibt es spezielle Umgebungen, in der Regel Organisationen die in erster Linie um ein einziges zentrales Softwarepaket kreisen, in denen man die PCs durch Thin Clients ablösen kann, diese Sonderfälle werden auch gerne herumgezeigt. Reale Unternehmen wickeln eine Vielfalt von IT Aufgaben mit PCs ab, und die Anzahl der Arbeitsplätze, die man durch Thin Clients ersetzen könnte ist doch eher gering, da oft ein einziges K.O Kriterium genügt, um den Einsatz eines Thin Clients auszuschließen. Wenn ein Unternehmen nun seine PC Landschaft ohnehin behalten und supporten muss, würde sich durch das Hinzufügen von Thin Clients als "zweite Schiene" der Gesamtadministrationsaufwand nicht reduzieren, sondern erhöhen. Außerdem wurde bereits erwähnt, aber meiner Meinung nach nicht deutlich genug, dass der Ablösung der relativ leistungsfähigen PCs am Frontend eine Verlagerung der Belastung auf das Netzwerk und das Backend folgt. Dies wirft eine lange Reihe von Problemen auf, angefangen von der Bereitstellung von genügend geballter Rechenleistung über Fragen der Netzwerkinfrastruktur und der Ausfallsicherheit bis zur Problematik, dass die komplizierte Technik der Backend-Rechner von ausreichend qualifiziertem und entsprechend hoch bezahltem Personal verwaltet werden muss. (nicht signierter Beitrag von 2A02:810D:1940:934:314D:90BE:DCC3:ACB6 (Diskussion | Beiträge) 16:12, 6. Jul 2015 (CEST))