Автор Тема: Десктоп виртуализация!!!? Какви са възможностите за безплатни решения!!!!?  (Прочетена 11835 пъти)

jet

  • Напреднали
  • *****
  • Публикации: 3472
  • Distribution: debian
  • Window Manager: kde
    • Профил
Имаше един продукт LTSP - боотва по мрежата (PXE) имидж на линукс - но и това е за локална мрежа.
naka - и ти говориш за локална мрежа.
А опитай да се свържеш от Русе към сървър в София - няма значение за копане или за .бане (за връзка от с. Горно Нанадолнище въобще няма да коментирам) - какви 100МБ какви 1ГБ/сек
Ако ще виртуализираш Уиндоус декстоп ти трябва Уиндоус машина при клиента (на село), Уиндоус лиценз за виртуалната дексктоп ОС (напр. Уиндоус 7) и лиценз за сървъра (напр. Уиндоус 2012) който ще ти търкаля виртуализацията. Не знам за какви безплатни работи говорите тука.
go_fire - за тези 5000 и 10000 машини знаеш ли каква ферма сървъри ще ти трябва?! Там цената на лицензите ще ти най-малкия проблем.

Дори през VNC е доста тегаво да се работи и то не толкова заради скоростта на връзка а поради латентността.

Затова мало и голямо разработва софтуера като уеб сервиз - не точиш дектопи наляво и на дясно, и никой не набляга на разработката на виртуални десктопи. Не че никой не го прави но е някакво много рядко изключение.
« Последна редакция: Feb 08, 2016, 15:19 от jet »
Активен

..⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋
  ⠈⠳⣄⠀⠀⠀⠀  Debian, the universal operating system.

10101

  • Напреднали
  • *****
  • Публикации: 384
  • Distribution: GNU LINUX
    • Профил
Поредното копане в търсене на злато в планината от Хималайска мъгла.
Активен

А печат ?

gat3way

  • Напреднали
  • *****
  • Публикации: 6050
  • Relentless troll
    • Профил
    • WWW
Цитат
А опитай да се свържеш от Русе към сървър в София - няма значение за копане или за .бане (за връзка от с. Горно Нанадолнище въобще няма да коментирам) - какви 100МБ какви 1ГБ/сек

Уффф, което ми напомня навремето точно по същия казус се опитвах да му обясня що е то латентност и как като иска дизайнерите в Русе да му чертаят на CAD програмата му на домашния сървър без да ореват орталъка, трябва за начало да се бръкне прилично за MPLS и гарантиран канал, а той човекът ми обясняваше колко скапани били доставчиците в Русе и как нямало да се дава на тарикати да му дерат кожата.

Оттогава предпочитам да гледам сеир пред това да се опитвам да давам съвети.
Активен

"Knowledge is power" - France is Bacon

go_fire

  • Global Moderator
  • Напреднали
  • *****
  • Публикации: 8780
  • Distribution: Дебиан Сид
  • Window Manager: ROX-Desktop / е17
  • кашик с гранатомет в танково поделение
    • Профил
    • WWW
Ами Джет, не знам, какви са парите за такива неща, защото дори не съм ги сънувал, камо ли виждал. Просто вадех твърдения от рекламите на Въмъваре, как по този начин всички компании от първата стотица били спестили половината си бюджет за ИКТ. И на мен ми е леко съмнително, но нали не съм Top 100, няма как да знам.

Проблема на HTML е, че е правен за описание на документи, а не за ГПИ. Сега ще кажеш, че то и postscript/pdf е правен за документи, пък нахапаните си направиха от него най-доброто (уж) ГПИ. Но преди tab index, z index, преливки, трансформации, нещата бяха безкрайно зле. Сега има и някакви негодни неща като платно и компоненти, дето все пак са полезни. Но, каквото и да се направи са просто едни кръпки на овехтяло палто, от което няма да стане бански костюм. А, за да е пълен ужаса, добавяме негодният за каквото и да било js. Скоро нещата ще станат съвсем неконтрилируеми.
Активен

В $por4e2 e истината  ;)

***

Aко даваха стипендия за най-глупави, щях да съм човека с най-много Mини Kупъри

***

Reborn since 1998 || 15.09.2007 totally М$ free && conscience clear

gat3way

  • Напреднали
  • *****
  • Публикации: 6050
  • Relentless troll
    • Профил
    • WWW
Потребителските интерфейси много удобно се описват с такива "недъгави" средства катo markup езици, HTML е просто пример - потребителския интерфейс в андроид приложенията също се описва като XML (или динамично се инстанцират обекти, но ти същото го правиш и с js де). XAML-а на майкрософт, QML-а на Qt, на JavaFX-а дивотиите доколкото знам са същата история, макар че там някой по-запознат трябва да се изкаже, та нищо странно. Та не е глупав подхода и вебаджийницата няма да умре скоро, дори напротив.
Активен

"Knowledge is power" - France is Bacon

growchie

  • Напреднали
  • *****
  • Публикации: 623
    • Профил
То е правилно да се започне с това коя КАД програма смяташ да виртуализираш. Да не се окаже, че лицензите, процесът за активация да блокира ползването и по терминален сървър.
Активен

backinblack

  • Напреднали
  • *****
  • Публикации: 3201
    • Профил
В момента без проблем се ползват 3 виртуалки на сървъра ми през рдп и внс и се работи абсолютно перфектно. Интернета ми е достатъчно добър за целта, но се ползват с приложения, които не изискват ресурс от видео картата. Без проблем се прикача отдалечения принтер и се разпечатва. Без проблем се трансферират и файлове.
Но при тази десктоп виртуализация  за която се говори вече идеята да се виртуализират приложения изискващи големи хардуерни ресурси като например тежки игри или рендване в 3Д и директно използване на графичните процесори и тем подобни.
Активен

growchie

  • Напреднали
  • *****
  • Публикации: 623
    • Профил
За игрите не смятам, че ще се скалира добре. То някои на желязото вървят бавно, камоли да пуснеш 2 едновременно, че и през виртуализация. Не знам идеята колко ще е практична. Какво целиш - някаква производителност като да разтоварваш клиентските машини или оптимизиране на лицензи.
Активен

gat3way

  • Напреднали
  • *****
  • Публикации: 6050
  • Relentless troll
    • Профил
    • WWW
backinblack, проблемът е че имаш грешни очаквания, които почиват на грешни хрумвания, понеже нещата не работят така. Видеокартата не чертае линии, квадратчета и кръгчета с порядъци по-бързо, причината да изнесат тази функционалност натам е за да се спести прехвърляне на огромни количества памет през "бавни" за целта шини. Това което виждаш на монитора е съдържанието на видеопаметта, "класическият" случай в който нямаме никакво видеоускорение, "рисуването" се изчерпва с мазане по един буфер в RАМ-та и последвало копиране на този буфер върху видеопаметта (съответно с ограниченията за bandwidth и латентност на шината). Когато резолюциите са започнали да нарастват далеч по-бързо от способностите на шината да пренася данни, хората са ударили греда. Тогава някой се сетил "абе що не направим видеокартите по-умни и да ги караме директно да си чертаят върху видеопаметта вместо да копираме огромни буфери памет" и така в общи линии са се пръкнали нещата. Ето примерно при OpenGL, там няма нужда да прехвърляш абсурдни обеми памет, а казваш "нарисувай ми тези линии и квадратчета с тези и тези координати" и вместо да хвърчат мегабайтите по шината, отиват някакви килобайти шейдърен код.

Сега в последните години нещата се промениха с 3D сметките, но това не касае CAD програмите ти.

Поради същата причина няма да намериш VDPAU-ускорено транскодиране на MPEG4 видеа, щото няма смисъл - усилието да копираш компресираното видео във видеопаметта, да накараш картата да ти го разкомпресира, само за да го копираш обратно на хост паметта където да го обърнеш в друг формат обезсмисля нещата.

Та твоят проблем е съвсем различен - тебе изобщо не те касае визуализацията на нещата на хост машината и поради тази причина видеоускорението вместо да ти помага, ти пречи, просто защото включва ненужни трансфери на памет до графичната карта и обратно. Това е и причината ESX-а да не ti "виртуализира" хардуерното видеоускорение, понеже в случая резултатът е че вместо да помогне, пречи. Това не е защото технологията не била разбираш ли достатъчно напреднала.

Активен

"Knowledge is power" - France is Bacon

lunarvalley

  • Гост
Цитат
Оттогава предпочитам да гледам сеир пред това да се опитвам да давам съвети.

требе и да се троли
Активен

go_fire

  • Global Moderator
  • Напреднали
  • *****
  • Публикации: 8780
  • Distribution: Дебиан Сид
  • Window Manager: ROX-Desktop / е17
  • кашик с гранатомет в танково поделение
    • Профил
    • WWW
Граучи, на теб може да не ти се вярва, ама на Сони им се получава повече от добре. Това са същите Сони, които въпреки, че са японци пишат софтуер по-зле от индийци. И  въпреки това успяват.

Потребителските интерфейси много удобно се описват с такива "недъгави" средства катo markup езици, HTML е просто пример - потребителския интерфейс в андроид приложенията също се описва като XML (или динамично се инстанцират обекти, но ти същото го правиш и с js де). XAML-а на майкрософт, QML-а на Qt, на JavaFX-а дивотиите доколкото знам са същата история, макар че там някой по-запознат трябва да се изкаже, та нищо странно. Та не е глупав подхода и вебаджийницата няма да умре скоро, дори напротив.

Това е така, но е следствие, че има много „творчески натури“, а не причина. Освен това декларативното описание е нещо хубаво, за нещо, което не се променя много, но html/xml  е абсурдно обстоятелствен. Има къде по-добри решения. А js нито е обектен с обектните езици, нито функционален с функционалните, нито процедурен с процедурните. Пълна мешавица. Виж css не е лошо нещо, малко ми прилича на заглавките в C++, но не ти се налага ти да пишеш логиката, идва си готова.
Активен

В $por4e2 e истината  ;)

***

Aко даваха стипендия за най-глупави, щях да съм човека с най-много Mини Kупъри

***

Reborn since 1998 || 15.09.2007 totally М$ free && conscience clear

Naka

  • Напреднали
  • *****
  • Публикации: 3395
    • Профил
Веб интерфейса е много хубаво нещо. Да не говорим че понеже има браузери за всяка ос той си е природно платформо независим. Кеф ти Мак, кеф ти виндовс, кеф ти линух, кеф ти телефон.

Да и това е начин за работа на много клиенти разпръснати навсякъде през бавния и с голяма латенция Internet. Обаче само когато програмата (проблема) изисква малък обем данни - например попълване на база данни, формуляри и т.н. Т.е. той е изключително удобен за фирмена работа. Обаче категорично не става за неща като чертаене или кад програми.

Сега проблема при HTML/css че не е много интерактивен. Формите не са развити много, например липсва combo box форма. Не може ако има движение по някой елемент (например hover или фокус) да маниполираш друг елемент в хтмл дървото, който не е child на текущият - (например да се намира в противоположния ъгъл на страницата), не може да разместваш елементи, все още липсва parent selector, не може да изпратиш хтмл заявка от текущата страница и да останеш в нея без да се зареди.(по подобие на XMLHttpRequest).

Абе има си много несъвършенства по отношение на итерактивността. И тук се намесва JS с която може да правиш всички тези 'Хубави' неща.

Обаче и тук почват и простотиите. >:( >:( >:( Понеже народа не разбира какво може и неможе да направи с чистият HTML/css блъска JS код като за умряло. Блъскат огромни jquery подобни библиотеки даже и да не са необходими - ей така да има??? (пример: чисто html/css меню без JS http://line25.com/wp-content/uploads/2012/css-menu/demo/index.html ). Като резултат страниците почват да работят много бавно и стават изключително тежки. Това е някаква мода дето не я разбирам. Ами то не успях да намеря една ЦМС ситема в която да не включено jquery по дефоулт. А ако не може да се мине без JS, може просто да се напишат 10 реда JS код и това е. Но и в самият JS има много простотии. Например липсва sleep() ??? ??? ???. Чудя се дали не е това причината много често да заспиват страниците и коклко ли пишман веб програмисти въртят празни цикли :o за да емулират sleep() :o

Като цяло и аз мисля че HTML/css/JS е бъдещето, но трябва да се върви повече към HTML/css и по малко към JS.



« Последна редакция: Feb 10, 2016, 12:08 от Naka »
Активен

Perl - the only language that looks the same before and after encryption.

gat3way

  • Напреднали
  • *****
  • Публикации: 6050
  • Relentless troll
    • Профил
    • WWW
sleep-а не мисля че е голяма драма да го реализираш с нещо от сорта на setTimeout() обаче мен цялата тази event-базирана "парадигма" с асинхронни заявки, събития и callback функции ми идва на моменти в повече.
Активен

"Knowledge is power" - France is Bacon

Naka

  • Напреднали
  • *****
  • Публикации: 3395
    • Профил
sleep-а не мисля че е голяма драма да го реализираш с нещо от сорта на setTimeout() обаче мен цялата тази event-базирана "парадигма" с асинхронни заявки, събития и callback функции ми идва на моменти в повече.

Аз така и го правих с setTimeout(). Обаче това което го правих се получаваха  setTimeout() върху setTimeout() и разни асинхронни работи (вече не помня) и кодът стана отвратително заплетен и труден за вдяване. Точно след една седмица, като го позабравя, почвам пак да се чудя как точно работи собствения ми код :o. А ако имах едно просто sleep() на критичното място нещата се опростяваха 10 пъти.
« Последна редакция: Feb 10, 2016, 12:44 от Naka »
Активен

Perl - the only language that looks the same before and after encryption.

go_fire

  • Global Moderator
  • Напреднали
  • *****
  • Публикации: 8780
  • Distribution: Дебиан Сид
  • Window Manager: ROX-Desktop / е17
  • кашик с гранатомет в танково поделение
    • Профил
    • WWW
Аз също мисля, че е бъдещето. По-скоро мисля, че е настоящето. Но това не го прави добър, а че просто е група технологии, която е владяна от много творчески натури и на компаниите им излиза изгодно.

HTML по начало е напълно сбъркан. Днес обаче и малкото, което можеше, е отнето. Отнето е в полза на css, което можеше и да е добра новина, ако не се преяждаше. То не е less, sass, compass, вчера Google обяви, че ще вкарва var.

Но незнайно защо HTML е още жив. Незнайно е въобще, за какво е съществувал.

Менюто, което показваш, е симпатично. Симпатично е, защото css вече умее неща като извити ъгли. Но си е дървено. Липсва му анимация. Оказва се, че анимация да пишеш на css е невъзможно. А подводните камъни, дори да го правиш с инструмент, са хиляди.

Проблемите, които решава js, ги решава чрез DOM. Никога не съм виждал нищо по-гнусно от DOM. Не е изненада, щом диванетата от Мозила са го измислили. Ако изобщо има нещо хубаво в js, това е само json. Но него май не са го мислили Мозила.

По между другото, не знам, какво искаш да кажеш за събитията. Точно конкретно има псевдо елемент, който отговаря на преминаване (hover). Имало си е hover още в първите реализации на css. Да множество събития ги няма, но пък наличните са използваеми. Няма и достъп до множество ресурси в самата ОС. Сега правят някакви измъчени и калпави интерфейси за js.

И все пак всичко това е нещо външно за системата. Някак просто го прикачаш. И не изглежда родно и не се държи като родно. Имаш само един процес, който върви изолиран в границите на интернет-навигатора. Каквото ти е дадено там, това. Някаква клетка. Разбираемо е защо е така. Сигурността би отишла на кино, ако интернет-навигатора има достъп до всичко. Той е една отворена врата.

Това, с което няма да се примиря, е, че той трябва да ми е ГПИ. Не е родно, не прилича на родно, не се държи като родно. И е неудобно. И има по-малко възможности от всяко друго ГПИ. А ако реша да правя нещо, което доставчика на решението ми, не е предоставил наготово, трябва да ползвам js. Например, ако реша, че искам платно, по което да драскам, това мога да направя само с js. Ако реша да направя собствен компонент, в него пак трябва да поставя js.
Активен

В $por4e2 e истината  ;)

***

Aко даваха стипендия за най-глупави, щях да съм човека с най-много Mини Kупъри

***

Reborn since 1998 || 15.09.2007 totally М$ free && conscience clear