VMware-Forum

Hallo,


als Vetreter der Windows-Gemeinde hier im Forum lese ich mit ziemlichen Unverständnis die Probleme der Linux-Gemeinde hinsichtlich der Grafikprobleme.
Ich bin nun mal kein Linux-Crack, das ist bekannt, aber ich weisss, dass VMware empfiehlt, Linux im Textmodus zu installieren, dann die VMware-Tools drauf und dann den X-Server starten.
Ich hab´s ja auch schon ohne Probleme geschafft, 3 Linux Installationen und eine Solaris-Installation mit den Beschreibunegne von VMware zum laufen zu kriegen. (Da bin ich echt stolz drauf)

Kann mir mal bitte jemand erklären, wenns geht, kurz und knapp,
was das für Probleme sind, die die haben?

Ich bin nämlich auf der Suche nach einer Antwort gewesen und habe nichts abschliessendes gefunden.

Allerdings diese Links hier:
http://www.gwdg.de/service/software/sof ... win32.html
http://www.nus.de/x_win.html

Wäre das denn nicht eine Möglichkeit für die, die Windows als Host einsetzen um darauf die unterschedlichsten Linux Varianten laufen zu lassen, das Thema mit den Grafikproblemen in den Griff zu kriegen?


Hartmut Schaumburg

es gibt da unterschiedliche probleme.

1. die mainstream-distributionen (suse, mandrake, fedora/rh) haben standardmäßig einen vollgrafischen installer. die meisten linux-neu-user haben keine lust und keine ahnung und werden linux deswegen natürlich nicht im textmodus installieren (egal wie ausdrücklich das in einem usermanual steht das diese kunden sowieso nicht lesen).

1.a dieser (der graphische installer) läuft in einem kompatibilitätsmodus (meistens im vesa-modus), stellt also für die hardware keine besondere anstrengung dar. nach erfolgter installation muss nun aber der echte x-server aufgesetzt und konfiguriert werden - und da liegen die schwierigkeiten da sich die distributionen ständig weiterentwickeln. im moment schwenken grad alle von xfree auf x.org um, vmware rechnet aber (noch?) mit einer xfree-variante.

2. unterschiedliche distributionen sind aufgrund des wechsels der x-server (auch schon aufgrund des wechsels von z.b. xfree-3.6 auf xfree 4.x) nicht sehr zuverlässig was die systemvariablen angeht (deswegen gibt es für z.b. red hat unterschiedliche x-server-konfigurationen in den tools).

3. einige wenige distributionen sind nicht unbedingt verlässlich was ihre sourcen angeht (suse hat häufiger mal veraltete sourcen mit dabei, weil die binären programme in letzter sekunde auf den neuesten stand gebracht werden, die sourcen dabei aber gelegendlich - sagen wir mal für nicht so wichtig genommen werden).

x-win32, cygwin und hummingbird exceed sind x-server für windows. hat man zwei maschinen mit x-servern, kann man die graphische ausgabe von programmen auf die entfernte maschine umleiten. damit das auch klappt wenn eine maschine eine win-box ist, gibt es diese programmpakete, die zum teil (je nach vollständigkeit der installation) sehr groß sind (zwischen ~40 und ~300 mb). x-win32 und hummingbird exceed sind proprietärer natur und kosten richtig geld - cygwin ist opensource und umsonst.
man benötigt aber auf beiden rechnern einen voll funktionsfähigen x-server - diese tools bringen uns hier also nicht die lösung.

es gibt eine lösung die ich gerne nehme - ich verzichte komplett auf einen x-server und steuere den gast mit putty von meinem windows-host. es gäbe auch noch die möglichkeit nicht die allerneueste distribution mit dem allerneuesten x-server zu fahren - aber das wollen die kiddies ja nicht, es muß bitteschön suse 17.4 sein und zwar am besten noch heute abend :wink: .

das problem ist auch nicht ganz neu - das erstemal hab ich das an einem mandrake-9.2-gast gesehen - allerdings lief x da sauber mit voller unterstützung für die vm-hardware, dafür waren die konsolen aber unbrauchbar. bei mandrake hatten sie damals grad auf XFree86-4.3-23mdk gewechselt (der zusatz mdk zeigt dir ein zusätzliches problem auf: suse und mandrake benutzen eigene, "optimierte" pakete, die oft mit dem original nichtmehr viel zu tun haben).

mein problem ist, das ich bei solchen threads ehrlichgesagt meistens schon keine lust mehr habe die selbe alte gebetsmühle wieder anzuschmeißen - zumal ich ja auch keine reproduzierbare lösung für das problem kenne und selbst wenn man sich da jetzt reinhängen würde und die nuss knackt - warte, in 2 monaten ist das alles wieder anders.

was meinst du wie schlimm das in vielen linux-foren ist: "quabääh, ich krig meine turbo-3d-nvida-supa-baller graka nie am rennen! hilft mir sonzt sterbe ich sofort!!!"

bleibt mir nur ein :wink: :wink:

mfg

looping

Hallo Looping,

danke für die Info.
Da haben wirs im Windows-Land doch wirklich einfacher.


Hartmut Schaumburg

Looping -du sagst man brauche auf beiden Rechnern einen voll funktionsfaehigen Xserver um mit exceed oder xwin was anfangen zu koennen.
Das habe ich bei mir selber aber etwas anders erlebt. Neulich habe ich mal eine Weile mit SCO experimentiert - unter VMware war die Maus unbrauchbar und X war auch eher x aber mit xwin - das gibt ess uebrigens umsonst ist aber dann nur 30 min am Stueck lauffaehig - also ueber xwin war durchaus mit SCO zu arbeiten.
Genauso bei Solaris - selbst wenn man in der VM nur 600x480x8 hat kann man mit den Xservern fuer Win32 schon richtig mit Solaris arbeiten. Damals wusste ich noch nicht wo es Treiber gibt.

AEhnlich war das bei 2003 auf dem GSX 2.5 - selbst ohne VMwaretools konnte man ueber RDP eine gute Grafik erzielen waehrend in der VM das Bild zum weglaufen war.

Hartmut - das Einrichten von Xwin oder Exceed ist wahrscheinlich fuer viele noch schwieriger als die VM ordentlich zu installieren. Cygwin ist noch schwieriger.

Ulli

hmmm - soweit ich weiß benötigt man auf der client wie auf der server seite einen x-server. bei vnc ist das ja z.b. auch so: der server benötigt neben dem vnc-server wenigstens einen abgespeckten x-server um die die graphische ausgabe zu erzeugen. ich will aber nicht behaupten, dass ich da wirklich ahnung von hätte - xwin32 oder exceed kann ich mir nicht leisten und so stark ist der leidensdruck nicht, dass ich cygwin einsetzen müsste :wink: .

ja, in der windowswelt ist durch die monokultur vieles einfacher - dort gibt es einen hersteller der eine verlässliche strategie verfolgt, definierte schnittstellen bietet und es sich leisten kann nicht certifizierte treiber abzulehnen. linux ist da wirklich komlett anders - es gibt eine reihe unterschiedlicher lösungen für das gleiche problem die wiederum mit ganz eigenen schwierigkeiten kämpfen und oft dazu noch von den hardwarehersteller recht stiefmütterlich behandelt werden. dafür ist die linux-welt unglaublich vielfältig und wer sich etwas mühe gibt kann sich ein system aufsetzen, dass wie ein guter handschuh passt. selbstverständlich müssen dafür dann die entsprechenden hardware-gegebenheiten vorhanden sein und das ist (trotz guter linux-unterstützung seitens vmware) in einer so veränderlichen welt halt nicht immer gegeben. kompromisslösungen sind da also angesagt.

aber: echte edv, echte server laufen sowieso auf der konsole ... :wink:

mfg

looping