Názory k článku X window a terminálový server na FreeBSD
-
ddd (neregistrovaný)Komunikace v XDM sessions neni kryptovana. To se da pouzit v ucebne, nebo v podnikove LAN, kde na bezpecnosti prilis nezalezi. Zajimavejsi by bylo, kdyby se ty X-y napojovaly pres VPN mezi klientem a serverem. Rad bych to zprovoznil na svem Linuxu, ale zatim jsem nenasel cas se tomu venovat.
-
prema (neregistrovaný)jj, ssh -X user@host. -X zapina tunelovani X protokolu na cilovem stroji ti to nastavi promennou DISPLAY takze tam muzes rovnou spoustet X aplikace. Ale aby to fungovalo, tak sshd musi byt zapnutou volbu XForwarding na yes. Problem ale bude s prenosovou rychloti. Na lokalni siti je to ok, ale pres internet? Zalezi na konektivite, ale obecne je to straaasneeee pooommallleee.
-
anonymní"Problem ale bude s prenosovou rychloti. Na lokalni siti je to ok, ale pres internet? Zalezi na konektivite, ale obecne je to straaasneeee pooommallleee."
Jak se to vezme. Dnesni internet je uz relativne rychlej, vetsinou ale z Inetu k userovi (download). Pokud bys tak chtel neco z Internetu spravovat nekomu doma, tak s tim budes mit problemy s rychlosti.
Jedna moznost je nastavit vysokou komprimaci u SSH (-o Compress=yes,CompressLevel=9). Druha moznost je nespoustet ty aplikace primo, ale spustit si na cilovym servery spis VNCserver, pripojit se pres vncviewer a pracovat takhle.
Jednak jde nastavit opet kompresi, take (napr. u tightvnc) jde vybrat urcity druh kodovani (osobne mam dobre zkusenosti s kodovanim tight:)) a tightvncviewer umoznuje taky zadavat kvalitu obrazu (JPG). Takze pokud ti nejde o kvalitu, tak se da nastavit treba "2" - obraz je pak mirne rozmazany a detaily se zaostrujou az pri pouziti, ale jede to i na pomalejsich linkach.
Druha vyhoda je, ze pokud ti spadne spojeni, tak se ti rozdelana prace neztrati padem aplikace, ale bezi v pohode ve vncserveru dal.
Mimochodem, mozna to taky stoji za uvahu, aby se na tenkym klientu nespoustel primo WindowManager, ale vncviewer, ktery se pripoji na server na VNCserver. Uzivatele tak mohou nechat rozdelanou praci, aniz by museli ukoncovat vsechny programy a window manager, a pouze ukonci viewer a jdou. Pokud se nepletu, tak vncserver umi take XDMCP, takze by to taky bylo reseni a mozna by odpadl problem s rychlosti napr. OpenVPN tunelu. -
Marek Chlup (neregistrovaný)Máte s tím nějaké zkušenosti? Jak byste to udělal?
Já to v tuto chvíli řeším tak, že po klasickém přihlášení v textové konzoli se spustí X pak ssh s tunelováním X a pak se nastartuje nějaké desktopové prostředí. Co mi však zde chybí je grafické přihlašování.
Plánuji si více pohrát s:
Xnest :1 -query localhost
či:
gdmXnest -o "-query localhost"
Má s tím někdo zkušenosti?
Taky jsem zatím nedošek k žádnému řešení kolem zvuku (respektive i videa) abych s ním byl spokojen. Pokud někdo u vzdáleného Firefoxe klepne na soubor se zvukem... Zatím se mi prostě nepodařilo najít nějaké transparentní řešení k mé spokojenosti. Máte někdo s něčím dobré zkušenosti? -
anonymníPokud vim, tak XDMCP bezi na UDP, cili na SSH tunnel nebo stunnel zapomenme.
Osobne jsem taky premyslel, jak sifrovat komunikaci mezi bezdiskovou stanici a server nejen na XDMCP, ale take na NFS, a porad mi v hlave lezi myslenka, ze stanice si ze serveru stahne kernel a svuj initrd, ktery je pote nahraje a spusti. V tomhle initrd bude samozrejme startovani nejake VPN (osobne mam rad OpenVPN, ale mam dojem, ze tun umi pouze 10Mbps, coz by mozna mohlo byt poznat pri praci). Pres ten VPN by pak probihala veskera komunikace se serverem. VPN certifikat a klic pro stanici by byl ulozen v tom initrd, klic by byl zasifrovany nejakym udajem unikatnim pro stanici a zjistitelnych pouze lokalne (netusim, co by se dalo pouzit, neco jako ID procesoru, desky nebo tak). Samozrejme by byl zakaz bootovani z cehokoliv jineho, takze pripadny utocnik by nemohl ziskat klic, aby si nahodil vlastni VPNku z vlastniho stroje.
Slo by to takhle? Da se donutit OpenVPN aby pouzival nejaky rychlejsi virtualni interface? Bylo by to dostatecne rychle s OpenVPN nebo by bylo lepsi IPsec (nebo neco jineho)? -
Marek Chlup (neregistrovaný)Mé příklady výše naznačují jak "tunelovat" XDMCP. Zatím jsem si s tím, ale nehrál pořádně.
Viz třeba také zde:
http://www.macosxhints.com/article.php?story=20041117115414383 -
petr_p (neregistrovaný)Nechci vas strasit, ale v principu to je nesmysl, protoze musite prenest klic bezpecnym zpusobem na terminal. Dale musite zabezpecit, ze se k tomu klici nikdo nedostane (napr. nepodvrhne jadro nebo root FS) atd.
Teoreticky vzato neni mozne mit bezstavove terminaly a ocekavat od nichm ze dokazi autentizovat server.
Nejrozumnejsi je do terminalu zapsat jadro a klic treba na disk, z toho nabootovat, vypnout disk a bezpenost resit IPsecem. Pokud byste chtel i aktualni jadro, je mozne jej poustet pres kexec.
Technicky ciste reseni by bylo rozsirit PXE interpret v sitove karte o overovani digitalne podepsanych PXE zavadecu (syslinux) a jader. Jadro by si pak ze sitovky nacetlo klic a pouzilo jej na IPsec. -
anonymní"Nechci vas strasit, ale v principu to je nesmysl, protoze musite prenest klic bezpecnym zpusobem na terminal. Dale musite zabezpecit, ze se k tomu klici nikdo nedostane (napr. nepodvrhne jadro nebo root FS) atd."
Ted mi nejak nedochazi, jak to myslis.
ad prenos klice nesifrovanym kanalem) nejsem zase tak velkej prebornik na bezpecnost a sifrovani, takze nevim, jestli je hodne velkej problem, kdyz poslu klic zasifrovanej dostatecne silnym heslem pres nechranenej kanal. Mozna posilat klic od el.bankovnictvi zasifrovany slabym heslem (rozumnej 5-7 pismen a-z, max. jedno velky) emailem je asi dost velke riziko, ale poslat klic zasifrovany dostatecne dlouhym heslem (coz muzou byt kombinovane najeke ID dilu pocitace) pres lokalni LAN, navic klic ktery ma slouzit pouze k pripojeni pro lokalni VPN, to snad nebude tak velke riziko, ne? Prakticky je jedno, jestli se klic prenasi nesifrovanym kanalem, protoze ve realu bude initrd ulozene na tftp, takze by zrejme utocnik mohl mit moznost si ho stahnout sam.
ad ze se k tomu klici nikdo nedostane) teoreticky pokud na tom stroji nedokaze spustit jiny system (to je asi myslene tim "nepodvrhne jadro nebo root FS") tak by nemel mit pristup k tomu klici, navic i kdyby, tak by klic mel byt pouze v sifrovane podobe.
Jedina hrozba, kterou bych ja videl by byla v pripade, ze by utocnik mohl do site zapojit vlastni stroj s DHCP serverem. -
petr_p (neregistrovaný)Lze podvrhnout DHCP odpovedi, TFTP je taky jen nad UDP, unest linkovou adresu, zmenit smerovaci tabulky, lze odposlouhavat, cokoliv.
Pokud tyto problemy mate vyresene, pak asi utocnik nema pristup k siti a tudiz nepotrebujete jine zabezpeceni.
Jednoduse receno klic, kterym chcete zabezpecit spojeni mezi terminalem a serverem musi znat jen tito dva. Pokud tento klic zasilate terminalu takovym zpusobem, ze nelze zjistit, ze klic ziskal i utocnik, neni mozne komunikaci mezi serverem a terminalem zabezpecit. -
anonymníNo, me osobne trapila hlavne myslenka, ze v pripade nasdileni systemu pres NFS muze kdokoliv nabootovat treba z LiveCD a jako root pak udelat na tohle NFS bordel. Samozrejme, ze jde hackovat hodne do hloubky, ale me spis slo o zabezpeceni NFS stromu proti tento uplne jednoduche metode.
jelikoz se tady bavime spise u uzivatelske siti nez o siti v bance, kterou protekaji skutecne citliva data, mohlo by tohle resit. Predpokladem bude:
- na siti je muj DHCP server
- zadny cizi (neprovereny, neduveryhodny) pocitac se do teto casti site nepripoji
- stanice nepujde nabootovat z jineho media -
ZiGi (neregistrovaný)riesenim je kryptovana komunikacia podporovana v NFS - treba pouzit RPCSEC_GSS
implementacia NFSv4 do linuxu prinasa zvysenie bezpecnosti aj pre NFSv2 a v3. podmienkou je pouzit novy kernel a samozrejme kerberos alebo podobna autentifikacia :-)
http://www.citi.umich.edu/projects/nfsv4/
www.nfsv4.org
alebo sa na NFS vykaslat a pouzit OpenAFS
samozrejme to neriesi problem tenkych bezdiskovych klientov, a aj hrubi klienti musia byt zabezpeceni proti bootu z CD/USB .... -
ppp (neregistrovaný)Obavam se, ze resite problem, ktery je vic teoreticky nez prakticky. Vetsine podniku v soucasne dobe staci, pokud po jejich siti nebehaji plain hesla (samozrejme je spousta vyjimek). Pripojeni vlastniho DHCP, ... serveru je velmi zavazne poruseni pracovni kazne a to si hned tak nekdo netroufne. Ale ethernetova karta "omylem" prepnuta do promiskuitniho modu, ... se objevit muze. (Kdyby se za to vyhazovalo, tak uz jsem davno na ulici, protoze to pouzivam pro diagnostiku sitovych problemu.)
-
ppp (neregistrovaný)Komercni tenci klienti obvykle maji podporu VPN zabudovanou. Napr. Igel (http://www.igel.com/igel_rubrik/powerslave,id,52,nodeid,52,p,0,_language,en.html) ma podporu pro Cisco VPN a microsofti PPTP. Proto se mi zda vyhodnejsi zprovoznit na serveru podporu VPN nez bastlit workaround pres SSH tunel.
Koncepcne to neni problem, akorat se clovek musi prokousat velkym mnozstvim spatne dokumentovanych parametru. Jak se tu uz psalo minule: v naproste vetsine je to navrzeno pro praci v sitich s MS-Windows.
Mimochodem: dalsi duvod pro VPN je ten, ze pak muzete mit kryptovane i NFS spojeni mezi klientem a serverem. -
Dobry den,
chtel jsem se zeptat - co je podle vaseho nazoru lepsi?
nainstalovat si FreeBSD 7 a postvat na to DesktopBSD skripty, nebo si rovnou nainstalovat DesktopBSD, ktere ma ale v sobe FreeBSD verze 6.
Jak se to dela, to si najdu na netu, na to se neptam. Zajimaji me nazory.
jinak dik za clanek, sice mu zatim nerozumim, ale tesim se, az jednou porozumim :-) -
anonymníFreeBSD ani DesktopBSD neznam, ale z linuxu bych ti asi rekl, ze muzes do verze FreeBSD 7 nacpat desktopBSD skripty (zalozene na FreeBSD 6) a muze to jit, ale take nemusi. Zalezi na tom, co se hodne zmenilo. Asi bych sel spis do DesktopBSD, pripadne bych si pockal na dalsi verzi zalozenou na FreeBSD7. Ale fakt zalezi na tom, co ty skripty delaji. Pokud je to nejaky drsny hackovani vnitrku FreeBSD, tak by to mohlo crashnout, pokud jsou to jenom skripty s nejakyma rozsirenyma funkcema pouzivajici standardni BSD utility a konfiguraky, tak by to snad melo jit. BTW: VMware server je zadarmo, tak muzes zaexperimentovat:))
-
anonymní"Za sebe dodám - kvalitka."
No vidis, ale ten muj prizpevek byl aspon k veci:)) Ono totiz Xaint psal "Zajimaji me nazory." a tak jsem vyjadril muj nazor.
Je to tezky rict (a nejakym zpusobem se zarucit), ze to skutecne pujde. Nekdo muze pouzit vic ruznych skriptu a nektere mu nepujdou, jinej muze pouzit jenom urcity skript a pujdou mu vsechny. -
anonymníNa audio by sel NAS - zkousel jsem s mplayerem, sice reakcni doba par sekund, ale bylo to dobry.
Ale ty prenosny media by me taky zajimaly - to abych pak na tenkym klientu rozjel i sambu nebo NFS a nasdilel device zpatky na server:)
Dalsi otazka pak je, co vsechno takovej klient bude mit. Kdyz nebudu mit HD, tak tam asi rovnou nehodim ani CD (na co taky, ze jo?), takze leda USB porty a mozna jeste floppy. Ale myslim, ze komercni tenci klienti budou asi neco jako LCD panel a klavesnice:)
Ale urcite zkuste navrhnout reseni, zajimalo by me to. -
ppp (neregistrovaný)Samozrejme zalezi na modelu komercniho tenkeho klienta, ale tendence je davat tam jak audio (v podnicich je to vyuzitelne pro internetovou telefonii), USB (prenos dat z klicenek, CD-ROM, ...) , tak i treba porty pro lokalni tiskarnu. Ostatne staci se podivat, co nabizi vyrobci (HP, Wyse, Igel, ...). Typ "LCD panel a klavesnice" se uz moc nepropaguje, driv se mu rikalo X-terminal.
Jinak hlavni ideou tenkych klientu neni usetrit na HD nebo HW obecne, ale minimalizovat naklady na administraci. Proto je jejich cena ve srovnani s cenou levnych PC pomerne vysoka (napriklad Premium klient od Igelu se cteckou smart card je dvakrat drazsi nez levne PC). -
ppp (neregistrovaný)Audio: Na serveru si pustite esound server a audio aplikace (pouzivam xmms) na tento server presmerujete (xmms to ma v menu). V mem pripade klient uz podporu pro ESD obsahoval, a tak jsem ho jen nasmeroval na server. Funguje to OK, ale prenasi se mi skoro 1 MB/s, coz muze byt problem pri vetsim poctu tenkych klientu.
USB: to se v praxi resi pres NFS, ale neni to flexibilni. Napr. pokud tenky klient neumi exportovat pres NFS (jen importovat), pak nezbyva nez data napred nakopirovat do adresare namontovaneho ze serveru a odtud je potom presunout na konecne misto.
Pokud vim, tak Microsoft ma tyhle veci uz davno vyresene v ramci RDP. RDP server pro Linux je ale zatim jen v prvnich fazich vyvoje.
Az budu mit chvili casu, tak se podivam, jak je Audio a USB resene v NX od NoMachine. Ten projekt je sice hodne komercni, ale na druhou stranu ma tolik dobrych myslenek, ze by se na nej nemelo zapominat. -
tomba (neregistrovaný)1) Pokial viem neexistuje nativny flash player pod freebsd, len emulacia + linuxovy player. Dnesny web je bez neho pre drvivu vacsinu uzivatelov nezaujimavy. Čo java?? Bez funkčného videa (qt, wmv, mov...) a zvuku(mp3, wav, ...) je to o ničom.....
2) Ked som to naposledy skusal (cca. 2 roky) pripadal mi protokol ktorý používajú xwindows veľmi neefektívny v porovnaní s ICA alebo RDP. Asi by som to tlačil do smeru nomachine...
3) Bez "rozumneho" window manageru (Gnome alebo KDE) to cele nema v praxi vyznam. Ludia s tým nebudú vedieť pacovať. Pre jedno icafe v starom meste som to raz konfiguroval a prijemne bolo ze sa turisti mohli prihlasit a pracovat v 9 reciach aj s office....
4) Okrem USB klucov by bolo príjemné aj napalovanie na klientoch (napriklad K3B, Gnome Baker). Turista si pripoji svoj plný fotoaparat a napali si obrazky....
5) Musi tam bezat aplikacia pre audio/video komunikaciu. Ludia chcu komunikovat, ocakavaju skype. Neviem ci je verzia pre freebsd....
Celkovo by som povedal (napriek tomu že uprednostňujem u mňa vo firme na serveroch bsd) že na klientoch by mal byť linux kvôli niektorým kľučovým aplikáciám. -
anonymníZe stejnych duvodu jake jste uvedl uzivam GNU/Linux i prestoze mam nainstalovane FreeBSD. Ve FreeBSD jsem narazil mj. take na zasadni problem s ports, jeden z bezpecnostnich updatu mi pri kompilaci vypise vzdy chybu a ja neumim deprecated zdrojovy kod upravit na standardni.
Co se tyce flash playeru, skype, gnome ci kde, apod. -> vse vyresi vstva pro podporu Linuxovych binarek -
mato (neregistrovaný)1) flash funguje, prave cez linuxolator. (alternativne open source flash projekty sa tiez pomaly zlepsuju.) java funguje bez problemov. rovnako video a zvuk (napr. cez mplayer plugin do mozilla produktov).
2) X11 protokol je trosku o inom ako RDP myslim. ale rozhodne NX je spicka a asi najlepsia cesta. treba sledovat / podporovat free NX implementacie.
3) nie je to celkom tak. hodne zalezi na ake ucely to staviate. videl som uz viacero inet kafe kde boli velmi exoticke prostredia a ludom to nevadilo. stacilo, ze mali na ploche/liste ikonku firefoxu apod. a nejaky WM skoro nikoho nezaujima.
5) skype na fbsd funguje cez linuxolator. su aj ine moznosti, ako napr ekiga ci SIP klienti, ktore su nativne. -
LO (neregistrovaný)Aby osazenstvo mělo představu o situaci na Windows, uvedu pár věcí ohledně Windows terminálového serveru. Odpovídá to totiž na spoustu otázek, které se tu diskutují.
Windows používají RDP protokol. Ten podobně jako X11 přenáší instrukce, co má klientský stroj (Xserver) kreslit. Různí RDP klienti mohou umět různé věci - neoficiální klient pro DOS umí jen zobrazit bitmapu a nakreslit obdélník vyplněný jednou barvou; jiní klienti umí i rastrovat písmo atp. RDP je daleko úspornější, než X11. Lze v grafice administrovat server po dial-up modemu 33.6kbps, byť to není úplně jako lokální práce. Na stejném spojení byl ovšem AIX i Solaris s X11 naprosto nepoužitelný (odezva na stisk klávesy ve vteřinách).
RDP umí kompresi, šifrování přenosu, od session je možné se odpojit a později se znovu připojit. Klient umí cachovat bitmapy, což dále zrychluje komunikaci. Mimo jiné je možné na klientu vypnout některé features desktopu - třeba animace menu apod. Dále je tu sdílení clipboardu, a to i objektového (list Excelu, bitmapa), přesměrování zvuku na klientský počítač, přesměrování tisku, sdílení smart card pro autentizaci, a případně i klientských lokálních souborů, USB klíčenek apod. se serverem.
Terminal Server je obsažen ve Windows 2000 Serveru a vyšších (NT 4 měly speciální Terminal Server Edition). Administrace je grafická a celkem jednoduchá. Klient je součástí minimálně Windows 2000 a pozdějších, opět je "bezúdržbový", a zvládne ho používat i idiot.
Samozřejmě vše má omezení a nevýhody. K "serveru" Windows XP je možné přistupovat pouze v jedné session, a ještě se při tom zamkne uživatelský interface. Jde o marketingové omezení - je třeba lidi přinutit ke kupování serverové edice :). Dále přes RemoteDesktop/RDP se spouští celé desktopové prostředí. Lze spustit i jednotlivou aplikaci (třeba Notepad), ale vždy to bude full-screen session (resp. může být v okně, ve kterém je okno Notepadu). Jde o marketingový limit, aby firma Citrix měla co prodávat (k tomu dále).
Tyto a další limity řeší Citrix Metaframe. Ten umí věci typu terminálová farma, kde se nově připojený uživatel hodí na nejméně využitý terminálový server. Stejně tak umí spouštět jednotlivé aplikace ze serveru v kombinaci s lokálními (tedy tam není nutnost běhu programu ve fullscreen/full-window session). Citrix a MS jsou "přátelé", a proto Metaframe vždy umí o něco více, než Terminal Services. -
LO (neregistrovaný)K minulému bych ještě dodal, že RDP je rozšiřitelný protokol, přes který aplikace může posílat vlastní datový stream. Navíc existuje ActiveX komponenta (ne, ActiveX nekouše - Flash je také ActiveX komponenta), která umožňuje přístup k Terminal Srrveru z browseru. A ještě jedna: Citrix používá místo protokolu RDP svůj vlastní, zvaný ICA. Citrix mimo jiné dělá oficiálně klienty pro řadu platforem.
Otázkou je, jestli ve světle všech omezení X11 a FreeBSD stojí za to stavět na této technologii terminálový server. Aby byl komfort srovnatelný s řešením na TS nebo s Citrixem, stálo by to opravdu hodně práce. A na konci bude potřeba, aby uživatelé spustili nějaký Office. OpenOffice je na zdroje daleko náročnější, než MS Office. Navíc MS Office je do značné míry komponentový, takže nová session spustí pouze malý executable (pro ilustraci Winword.exe má 11MB), a zbytek jsou knihovny, které se sdílejí napříč sessions. Pochopitelně terminálová licence Windows a Office (v produkčním prostředí zpravidla také Citrix) něco stojí, ale za srandu se holt platí...
Výše zmíněné berte jako popis fungujícího řešení, které má již vyřešenou spoustu věcí, které se tu diskutovaly. Je mi samotnému záhadou, proč v je unixech ještě pořád ono neefektivní X11 (které navíc nemá jasnou specifikaci, viz hromada extensions), proč se tak hrozivě používá (MIT-MAGIC-COOKIE, ssh tunneling etc), a proč je připojení k X11 serveru pro běžného uživatele pořád příliš obtížné. -
ppp (neregistrovaný)Co se druheho paragrafu tyce (vhodnost X11 pro TS): Uz se zde zminovalo, ze Unix zaspal. Dlouhodobe perspektivni komercni reseni nema smysl budovat na stavajicich X11. Z toho ostatne vysli i tvurci NX. Nicmene jako levne reseni (napr. pro jiz existujici prostredi s "legacy" X11 aplikacemi) se to muze hodit.
Co se tretiho paragrafu tyce (proc Unix zaspal): Kolem tenkych klientu a MS-Serveru se toci velke penize. Kolem ekvivalentnich konfiguraci s Unixovym serverem se tech penez moc netoci. (Pochybuji, ze Sun Ray se prodava ve velkem). Duvody a dusledky jsou jasne a neni treba je rovadet. Osobne se domnivam, ze kdyby ty zatuchle vody komercniho Unixu nerozhybal Linux, tak se jeste dnes ve standardizacnich komisich diskutuje o tom, jesti radek v editoru vi ma mit omezeni na 128 nebo 256 znaku, nebo jestli by nebylo rozumne v aktualnim ksh (z roku 1988) zprovoznit kurzorove klavesy. -
marvin (neregistrovaný)No ono to je take o tom, ze X11 jsou o necem dost jinem nez RDP a to o distibuci vypocetniho vykonu. Podivejte se co Vam sezere 1 uzivatel pripojeny pres RDP na serveru a na klientovi pameti a CPU a co na X-terminalu. U X-terminalu neplati, ze muze mit libovolne pomaly CPU cim je CPU rychlejsi tim lepe se pracuje. U RDP je to podle me fuk. Tam vse pocita server. Je to IMHO jiny pristup. Jinak co se tyka audia tak me to chodilo pres NAS, ale neni to ono. Nikdo to takhle nepouziva proto to moc nefunguje.
-
ppp (neregistrovaný)Ja jen dodam, ze RDP ve verzi 6.0 umoznuje pristup k jednotlivym aplikacim (neni nutne otevirat celou session). Na serveru musi byt Windows Vista nebo Windows Server 2008, vice viz odkazy na http://en.wikipedia.org/wiki/Remote_Desktop_Protocol. Osobne jsem to ale nezkousel.
Ohledne pratelstvi Citrixu a Microsoftu mam jiste pochybnosti. Osobne bych spis tipoval, ze Microsoft Citrix behem nekolika let "prevalcuje", ale treba se pletu. Ja se o deni v techto firmach prilis nezajimam. -
LO (neregistrovaný)Citrix vyráběl Metaframe (tehdy WinFrame) už pro NT 3.51. Měl licenci na kód NT 3.51, a MS měl i kapitálový podíl. V roce 1997 MS zakoupil část technologie, a po dalším vývoji jí integroval do NT4. Firmy se dohodly, že MS nechá Citrixu místo na trhu. RDP bylo použito v NT4 Terminal Server Edition (tedy separátní edice), poté v každé instalaci Windows 2000 Serveru (ale bez přístupu ke konzoli), poté ve Windows 2003 (s přístupem ke konzoli, a tuším i se základním vyvažováním výkonu mezi více terminal servery) a Windows XP (pro jediného uživatele), a nyní ve Vistě a Windows 2008 (přístup i k jednotlivé aplikaci). Zjevně to nejsou limity technické, ale marketingové. Kdyby dohoda neexistovala, MS by vrhnul na trh jednoduchý produkt, který by stál v porovnání s konkurencí polovic a méně, a s druhou či třetí verzí by obsadil velkou většinu trhu (viz MS SQL, Exchange, Office). Citrix se za ta léta snažil najít nový business v oblasti vzdáleného přístupu k aplikacím všeho druhu (včetně remote control SW pro support atp). Samozřejmě je otázka, jestli za ta léta našli něco zajímavého, co je do budoucna uživí...
ČLÁNKY DO MAILU