Hlavní navigace

Vlákno názorů k článku Světem OS skrz na skrz: ovládání různých systémů od Nenik - Zkousel jsem VNC v ruznych podminkach. Relativne drsneho...

  • Článek je starý, nové názory již nelze přidávat.
  • 10. 5. 2001 8:40

    Nenik (neregistrovaný)

    Zkousel jsem VNC v ruznych podminkach. Relativne drsneho nasazeni se mu dostalo, kdyz nam na Strahove na InstallFestu druhy den vysvitlo slunicko a nebylo nic videt na promitacim platne: Byl jsem pozadan o rozdistribuovani pracovni plochy prednasejiciho na monitory navstevniku a musim uznat, po lokalni 10Mbit siti ten jeden Celeron/333MHz docela bez potizi uzivil 10 klientu a vse bylo up'n'running behem asi 10 minut.

    Naopak velmi spatnou zkusenost mam s VNC serverem na platforme Windows:
    Problem je ten, ze zatimco v Linuxu/libovolnem jinem UNIXu ze pouzije virtualni Xserver, kteremu aplikace sami rikaji, co chteji prekreslit, tak na windows VNC server pracuje tak, ze snima obrazovku a dohledava co se zmenilo od posledniho snimku, coz server dost zpomaluje.
    Porovnani: Pocitac ve skole, W2k, PIII/800MHz 1280x1024 vs pocitac na koleji Celeron/566MHz, Linux, 1024x768.

    W2k server, Linux client, pres vikend:
    volne pasmo cca 600KB/s, 5ms ping, 1280x1024 velky desktop. System na dalku pro narocnejsi aplikace (CAD) temer nepouzitelny, problemy s prekreslovanim.

    Linux server, W2k client, pres normalni pracovni dny volne pasmo klesa az k 50KB/s, ping stale 5ms, 1024x768 velky desktop vpodstate vsechny aplikace bez problemu, slo dokonce i prehravat video v mensim rozliseni.

    Ve clanku se take nikdo nezminoval o bezpecnosti VNC:
    VNC spojeni samo neni nijak sifrovane (da se tunelovat pres ssh), session password je spis vtip nez zabezpeceni. Pokud tedy nekdo chcete provozovat VNC bezpecne, doporucuji povolit pristup na vnc server jen z localhostu, a tunelovat skrz ssh.

    BTW: Existuje mnoho ruzne upravenych VNC systemu, nektere pridavaji do streamu kompresi, nektere rozsiruji encodingy (zpusoby predavani zmen obrazu), nektere umi prenaset i audio.

  • 10. 5. 2001 9:06

    Petr Maškarinec (neregistrovaný)

    Mám osobní zkušenost s "provozem" v učebně s Windows 98, Duron 650, 64 MB RAM, síť 100 Mb, rozlišení 1024x768. Chtěl jsem žákům promítat svoji obrazovku. Bláhově jsem si myslel, že to poběží všem. Na této konfiguraci to fungovalo bezvadně se třemi připojenými počítači. S pěti už to bylo jen čekání a když se připojil šestý, systém odešel do věčných lovišt...

  • 10. 5. 2001 11:25

    klak (neregistrovaný)

    Jestli tomu dobre rozumim, tak v prvnim pripade zobrazoval Linuxovy klient s rozlisenim 1024x768 plochu na Win serveru, ktera mela rozliseni 1280x1024. Kde probiha prislusny resize nevim, ale zpomaleni to urcite bude (zvlast pokud se resize provadi az na klientovi, protoze pak toho jde pres sit zbytecne moc). A o barevne hloubce obou desktopu se nezminujete uz vubec, tim by to taky mohlo byt.

    Na druhou stranu ale autori primo doporucuji pouzivat Win jako klienta, je-li moznost volby.

  • 10. 5. 2001 20:00

    Nenik (neregistrovaný)

    Win server -> Linux client:
    Na linuxu jsem si na to nastavil 1280x1024, abych nemusel scrollovat. VNC system totiz nijak neresizuje (samozrejme).
    Server:1280x1024x24bit, client 1280x1024x16bit full screen

    Linux -> Win:
    Mel jsem mensi okno na vetsi plose.
    Server: 1024x768x16bit, client 1280x1024x24bit - okno 1024x768

    Co se konverzi bitove hloubky tyce, deje se na strane serveru - klient si rekne o pozadovanou hloubku a tu dostane.
    Vzhledem k tomu, ze 24bit i 16bit jsou DirectColor barevna schemata, je cena konverze obema smery stejna.

    Jeste bych doplnil neco o tom zjistovani zmen na strane windows serveru: Da se nastavit, jestli ma na zmeny testovat cely desktop, nebo aktivni okno, nebo okno pod kurzorem, ale u Full-screen aplikace je to stejne jedno.