Linux за българи: Форуми

От доста време ползвам уиндоус на виртуалка през рдп и внс дистанционно и си ми върши перфектна работа, но въпроса ми е за истинската десктоп виртуализация с използването на големи графични ресурси за рендване в 3д и тем подобни.
За платените решения покрай рекламирането им има доста информация. Много се замислям да експериментирам с един истински сървър, но това за което намирам повече информация е за Citrix и Horizont платените версии за които, съвсем естествено се намират и варианти за безплатно ползване. 

Доколкото знам, първото което ти трябва е процесор с  vt-d, това е технология на  intel, нямам представа каква е алтернативата при amd.
https://software.intel.com/en-us/blogs/2009/06/25/understanding-vt-d-intel-virtualization-technology-for-directed-io

Аз не съм експирементирал, но тук https://www.youtube.com/watch?v=16dbAUrtMX4
показват как може да се виртуализира с достъп до видео картата (PCIe passthrough). Във видеото говорят за игра, но няма значение, можеш да дадеш на виртуална машина пълен достъп до видео карта.

Тук - https://teksyndicate.com/videos/gta-v-linux-skylake-build-hardware-vm-passthrough има написани инструкции, но са доста дълги и на английски. Предполагам може да се намерят и други източници на информация, но както казах аз не съм си играл толкова с виртуализация.

Доколкото виждам трябва доста добре да си подбереш хардуера, и не е лесна задача. За видео карти препоръчват АМД, понеже на Нвидиа софтуера засичал ако се опитваш да ги пуснеш на виртуална машина драйвера ги спирал.

Видео картите за десктоп виртуализация са от съвсем друг клас и това са Куадро серията на Нвидия и Фаер Про на Ати. Имат драйвери специално за ESXi и до колкото разбирам виртуалните машини имат директен достъп до тях, както с vt-d на процесорите.
Иначе сървъра ще е двупроцесорник с х5650 и поне 32ГБ рам. Една такава карта се продава тънко като втора употреба и смятам да я взема, поне за експериментите.
Масива ще е с истински райд контролер с ББУ в райд 5.
Това което ми даваш като линка е да се добави директно към виртуалката външно монтирана карта, а при истинската десктоп виртуализация, една мощна видео карта е споделена на всичките виртуални машини, като може да се настройва на коя колко ресурс да ползва.

Еми това ти давам защото искаш безплатни решения, а сега намесваш стари quadro и firex "мощни" карти на старо.

Това което ми даваш като линка е да се добави директно към виртуалката външно монтирана карта

Точно това и аз съм написал. Ей за това никой няма да ти помоге и ще се чудиш защо хората не те харесват, защото не им цениш времето и усилията.

Еми това ти давам защото искаш безплатни решения, а сега намесваш стари quadro и firex "мощни" карти на старо.

Цитат

Това което ми даваш като линка е да се добави директно към виртуалката външно монтирана карта

Точно това и аз съм написал. Ей за това никой няма да ти помоге и ще се чудиш защо хората не те харесват, защото не им цениш времето и усилията.

Чак да не ме харесват........ не съм останал с такова впечатление, а може и да греша!
Стара карта или карта на старо, не означава нещо допотопно! Същия модел все още се продава и като нова, но на цена няколко пъти по-висока(четири цифрена сума) и щом има официални драйвери от сайта на Нвидия за VMWare ESXi, трябва да е логично за какво е предназначена, а също така и няма нито VGA, нито HDMI, нито Displai Port  за включване на монитор към нея, па уж е видео карта!!!!

Ето ти примерно една статия, която прочетох за десктоп виртуализацията: http://www.lirex.bg/bg/infrastrukturni-resheniya/Virtualizatziya/Desktop-virtualizatziya

В темата питам за съвсем професионалните решения за десктоп виртуализация. Но, благодаря все пак, за желанието поне да си полезен.
Не, че ако няма безплатно решение няма да пробвам и платените, че даже и да ги ползвам, ако ми хареса и му намеря добро приложение, но бих желал да знам каква алтернатива на платените има.

Говорех по форумите, че не те харесват, все пак си известен с това, че си "ходиш".
Гледам, че продължаваш с подигравателния тон, и ми обясняваш за портове на карти, и професионални такива. http://videocardz.com/40218/nvidia-geforce-gtx-690-modified-into-quadro-k5000-and-tesla-k10

Успех с "истинската" виртуализация и "рендването в 3д" както и да го разбираш това.

Не съм сигурен дали разбирам въпроса правилно но AMD пуснаха съвсем скоро хардуерно-базирана виртуализираща видекарта за сървъри.

Говорех по форумите, че не те харесват, все пак си известен с това, че си "ходиш".
Гледам, че продължаваш с подигравателния тон, и ми обясняваш за портове на карти, и професионални такива. http://videocardz.com/40218/nvidia-geforce-gtx-690-modified-into-quadro-k5000-and-tesla-k10

Успех с "истинската" виртуализация и "рендването в 3д" както и да го разбираш това.

Съжалявам, че си го разбрал подигравателно! Десктоп виртуализацията се разработва от доста години. Мисля, че Цитрикс го започнаха. Като всяка нова технология е скъпа, но с времето се усъвършенства, поевтинява, става по-позната на повече хора и започва да навлиза и в по-ниски таргет групи.
За фирмите този технология е много полезна, защото им спестява пари за инвестиране в работно място, като работника би могъл да работи и от дома си. За работника пък е перфектно, че няма да губи време и разходи да пътува до работното си място, а и друг много хубав момент има за фирмите, че локацията на кадрите става без значение. От известно време усилено се ленсира и излизат доста новости предназначени за тази цел, а нещо, което не се ползва спира и да се развива.
Не знам до колко си запознат с виртуализацията по принцип, но тази технология позволява да се използва много по-пълноценно хардуера. По принцип, когато работиш на един компютър, за да ти работи оптимално бързо, ти използваш постоянно не повече от 30% от мощността му, а на моменти само вдигаш до 100%. Когато това са виртуални компютри в един сървър, тази излишна мощност която трябва се ползва от другите виртуалки и така сървъра работи постоянно на голямо натоварване, като има достатъчен пиков ресурс за отделните виртуалки.
С десктоп виртуализацията, всички работни места на една средно голяма българска фирма могат да се качат на един сървър само и да се свързват към тях с тънки клиенти.
Технологията е с голямо бъдеще и вече навлиза и на по-масово ниво. Не се гъбаркам, а просто няма кой знае колко информация и за това и питам, а също така се опитвам да разсъждавам логично като гледам разни чаркалъци, които се продават. 

Не съм сигурен дали разбирам въпроса правилно но AMD пуснаха съвсем скоро хардуерно-базирана виртуализираща видекарта за сървъри.

Точно за това става въпрос.  И аз покрай тази новина се разрових малко повече да видя до къде е стигнала технологията.
Един сървър с много процесорна и графична мощ от който се отделят много вируалки и към тях се свързват тънки клиенти. Има и клиент за Андроид, Епъл, Линукс и Уиндоус компютри и таблети, вчера четох, че и Убунту са изкарали вече таблет, но с праметри за пълноценен компютър. Мен ме интересува не за някакви големи структури, а за 10-20 работни места на един сървър. Този който имам и смятам да експериментирам е тъкмо да ги понесе без проблем, но въпроса ми беше с какво да експериментирам? За Хоризон на ВМУаре има най-много информация, но е платен, а Безплатен вариант с Линукс си мисля, че трябва да има, но няма информация.

На хартия всичко е много хубаво, но в реалността е много скъпа и чуплива технология. Сложи и към картинката и Уиндоус - щото това е ОС-а дето се използва в  фирмите (даже и в на backinblack фирмата) и положението става плачевно. Цитрикс иска постоянна поддръжка от ИТ щото все нещо се успива и си иска рестарт. През Цитрикс програмите са бааааавни без значение колко големи ферми сървъри слагаш. Това нещо е и single point of failure - не знам българския вариант на този израз, но като умре Цитрикса и цялата фирма бездейства. Затова хората си искат да си имат отделни ПЦ-та. Не печелиш и от към лицензи, щото освен клиентски плащаш и сървърни лицензи. Ако се принти на хартия във фирмата и печата също е проблематичен. Та затова и не чуваш много по темата. А компютрите май само в БГ са скъпи та се чудят как да ги "виртуализират". Ха накарай някой дизайнер или някой КАД специалист да работи през такова чудо и да видиш къде ще те навре, пък ти си обяснявай колко ти били мощни железата.
Към всичките ограничения за производителност идва и дебелината на тръбата с която сървъра и клиентите са свързани към интернет.

Jet, от към мощност на хардуер, нещата би трябвало да са много добри. Голямото предимство е не толкоз цената на лицензите, а по-добрия избор на от кадри.
Във всяка работа има доза интелектуален труд и доза хамалогия в някакво съотношение. Примерно, за копане с мотиката се изисква много малко интелектуален труд и много хамалогия, а почти обратното съотношение е другата крайност, при разработката на софтуер примерно!
Та, в този ред на мисли, в малките населени места, трудно можеш да си позволиш добри технологии, защото хората с нужната доза интелигентност бягат в големия град да търсят по-добра реализация и условия. Само по-добро заплащане не е достатъчно, за да се върне. В големия град пък може да се пести от време за пътуване, а и от разходи за офис. Много често по-скъпите неща се избиват от други икономии.
Всяка технология, вземе ли да се ползва и да навлиза повече, тя се доработва и изчиства, а тази технология се разработва и навлиза от доста време. Аз лично, за нашия бранш виждам много периспективи в нея. Интернета и по селата вече е достатъчно добър и надежден.
За десктоп, то освен Уиндоус друго няма какво да се виртуализира и дали е във виртуалка или директно на желязо си е все платен, а който си го ползва безплатно все ще му е безплатен. Коментирал съм в друга тема, че проблема с пиратстването на Уиндоуса не в цената, а в политиката на МС, която е такава, че сервизите които асемблират компютри нямат интерес да го предлагат, дори те самите убеждават клиентите, че е по-добре да ползват пиратски Уиндоус. Аз самия също не бих препоръчал на никой да си го купи, но това е за съвсем отделна тема.
Та, големите фирми се обслужват от МС партньори и цената за тях не е проблем, а малките фирми се обслужват от малки фирми, които не са МС партньори и точно те нямат интерес да продават лицензирани компютри, а не клиента да не иска да плаща и в интерес на истината масово се работи с не лицензиран софтуер. По принуда от почти 2 години и моя десктоп се върна на Уиндоус, защото инструментите ми за управление на сървъра работят само под Уиндоус.
За сървърна виртуализация и аз от известно време смятам да заебавам ESXi-то, ама за десктоп виртуализацията, ако няма добри алтернативи, ще трябва да отложа.

Твърде вероятно нищо, от това, което ще кажа, няма да ти е полезно. И все пак…

Точно наскоро на едно място говорех, че съвременният език е твърде абстрактен и стават грешки, неразбиране.

Когато говориш за „хамалогия“ съотношението ѝ в ИКТ не е по-малко, отколкото ръчният труд. Това само в смисъла на протяжни, елементарни действия. Обаче, това не е вярно, когато сравняваш директно интелектуална дейност и работа, защото публиката остава с грешното впечатление, че първото е работа също, както не е. Единствената допирна точка в такъв случай е, че е нещо, което правиш и евентуално е заплатено. Но така понятието става прекалено широко и почти безполезно.

Като ти гледам разсъжденията по темата и не те познавах, щях да кажа, че си гледал рекламните доклади на Vmware. Но знам, че си стигнал сам до тези заключения — от практиката. И действително, в този случай Джет греши. Цената на машините има значение. Разковничето в случая е „обем“. Не е едно и също да закупиш 10 хил. машини с договори за разпространение на програмно обезпечение към тях и 5 000. А в сметката още не сме сложили тока.

Това е от гледна точка на юридическите лица. Джет в случая говори като физическо. Защото  дори у нас заплатите на информатиците, не са чак толкова ниски, че за него решението  дали да си купи Мак про¹   или нещо  друго е подобно на решение на нормален човек дали да си купи Милде, Цева, Емека. Кое ще избере, не е водещ критерии цената, а други фактори. И не е въпрос на продължително обмисляне, а моментно решение.

Оставяйки това на страна, не съм убеден, че знам, какво означава „виртуализация на работен плот“, но все пак си мисля, че съм схванал въпроса  ти. И да има нейна, „безплатна“ алтернатива. И не мисля, че няма да ти свърши  никаква работа.

Алтернативата се казва Затвор². Има я от около 40 год. на кажи-речи всеки Юникс. Обаче проблема е, че ОС „виртуализира“ самата себе си. Сиреч върху Соларис не можеш да сложиш БСД, а за друг тип ОС и дума не може да става.

Джет те поряза (правдиво!) по още един въпрос, без сам да разбере. Ти в действителност питаш за пренос по мрежа на САПР³, макар и специализирани. И пак мога да отговоря утвърдително,  и отново няма да ти върши работа. За XWindows отдавна се разработват решения, които в общи линии представляват пренос на видео (а не команди, както е по принцип). Решение за Х12 на проблема с огромният трафик, забавянето и така нататък за приложения с 3И на Debconf'13 представи дори самият баща на XWindows.

Но на теб това не ти върши работа. И с право ще запиташ, добре, след като има „безплатни“ решения, няма ли и платени? Аз за трети път ще отговоря утвърдително и за трети път, няма да ти върши работа. Защото да има и то доста развити. Но те например служат за пренос от видеоигра на компютър или от „облак“ на видеоигра. Но няма такива например за Solidworks⁴.

И така обобщението е, че — към момента технологията не е там, където ти е необходимо да бъде. Има някакви неща, които сам си изброил и от които може да се сглоби нещо, но то ще е далеч от оптимално, ако изобщо проработи. Лошите новини са си лоши. Но евентуално в не далечно бъдеще, може би ще има и добри. Може би знаеш, че вече Пхотосхоп работи от „облака“. Щом това е постигнато, то в недалечно бъдеще гамата „тежки“ приложения ще е още по-широка. И вероятно там ще се включат и ползваните от теб. Модата е такава и има безкрайно много предимства за компаниите производителки, че да не се случи.



----
¹  Май така се казваше онова скъпо „кошче за биологични отпадъци“;
²  На теб ти е по-позната под името „контейнери“;
³  У нас по-познати с английското название CAD/CAM;
⁴ Знам, че в твоя случай не се говори за Solidworks. Просто го давам за пример.

И не мисля, че няма да ти свърши  никаква работа.

Да се чете, както следва:

И не, мисля, че няма да ти свърши  никаква работа.

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

Тя тази технология с терминали, съществува откак се е пръкнал UNIX-a и X-a.
X-a натурално си е мрежов и позволявя отдалечено логване.


Как става на практика: Терминала може и да е бездисков. Натискаш му копчето, на мрежовата карта биоса и е така направен, че да може да бутва по лан. Бутва един малък кърнел и X. Кърнела който се бутва е така направен, че да си монтира root-а по NFS. На екрана на терминала излиза стандартният X логин. Може да е KDM или GDM. юзера си влиза с име и парола обаче се избира от падащо меню и сървера където ще се логне. Влиза и си работи на терминала като без да забелязва че всичко което работи се намира на сървера.

Това съм го пробвал много пъти, изобщо няма забавяне. Даже съм го пробвал и на старите коаксиални мрежи, дето трансфера беше само 1MB/sec. И там работеше доста прилично с много малко незабележимо накъсване. Какво остава за 100MB или за 1GB/sec мрежите.

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

Споед мен такова решение с централен сървър има смисъл ако всички трябва да работят на терминалите само с една и съща специализирана програма (а не пълноценен десктоп). Натиска копчето на клиента, бутва му се програмата отдалечено и почва да работи. Много ми е интересно дали има фирми в бг дето работят така. Едно време бтк работеше с нещо подобно.

 

Ами където има някаква специализирана програма, има два варианта. Единият е да се свързват по VNC. Вторият е да има специализирано приложение за работен плот, което да се свързва по мрежата с централно съхранение на данни и изчисления. Един вид само показва резултата.

Обаче тези и двете са вече история, макар да се прилагат унаследено все още. Вече се прави най-просташкото нещо. Нацвъква се html/css/js и връзката става през интернет-навигатор. Така е включително за питаното от теб БТК. До неотдавна им бях клиент и съм го виждал в центровете им. Но да беше така преди.

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

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

Затова мало и голямо разработва софтуера като уеб сервиз - не точиш дектопи наляво и на дясно, и никой не набляга на разработката на виртуални десктопи. Не че никой не го прави но е някакво много рядко изключение.

Поредното копане в търсене на злато в планината от Хималайска мъгла.

А опитай да се свържеш от Русе към сървър в София - няма значение за копане или за .бане (за връзка от с. Горно Нанадолнище въобще няма да коментирам) - какви 100МБ какви 1ГБ/сек

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

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

Ами Джет, не знам, какви са парите за такива неща, защото дори не съм ги сънувал, камо ли виждал. Просто вадех твърдения от рекламите на Въмъваре, как по този начин всички компании от първата стотица били спестили половината си бюджет за ИКТ. И на мен ми е леко съмнително, но нали не съм Top 100, няма как да знам.

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

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

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

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

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

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

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

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

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

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

требе и да се троли

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

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

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

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

Да и това е начин за работа на много клиенти разпръснати навсякъде през бавния и с голяма латенция 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.

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

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

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

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

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

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

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

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

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

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

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

HTML се мъчиха да го заменят с какво ли не, но безуспешно.
То не беше Gopher, HUL, Telnet, но HTML винаги оцеляваше.
С прикърпване му добавяха функционалност DHTML, HTML2, Java, Flash, но върха на сладоледа е Active-X и SilverLight - бизнеса още не може да се откачи от Интернет Експлодър 6

Точно след една седмица, като го позабравя, почвам пак да се чудя как точно работи собствения ми код :o. А ако имах едно просто sleep() на критичното място нещата се опростяваха 10 пъти.

Хахаха да, изисква леко извратено мислене, не мисля че човешкият мозък (поне моя де) функционира така. Това не е върха на извращението в това отношение, моят фаворит засега е един питонски framework, tornado, който е специално правен с идеята да реализираш асинхронни event-базирани уеб услуги. Там извращението е докарано до принципно ново ниво и "нормалното последователно" изпълнение (т.е примерно да викнеш sleep() без да даваш callback функция дето да се вика след като се "наспи") може все пак да се "емулира" - което обаче не е толкова хубаво - аз сериозно предпочитам варианта с колбеците. Всъщност, може би самата постановка, сървърно приложение вместо клиентско такова, предизвиква сама по себе си извращенията, заради различните изисквания. Там върховната ценност е да не блокираш никъде ioloop-а - при което стигаш до абсурдни ситуации понеже като ти трябва нещо извън tornado-то, почти всички налични средства и библиотеки не са мислени да работят асинхронно (т.е най-малкото да ти дават един сокет дето да можеш да го добавяш към set-а който се poll-ва от ioloop-а). Та сега стигаме до простия пример в който искаш приложението ти да изпрати мейл. И понеже всички възможни библиотеки за целта не са мислени така, съществуват два варианта: да хванеш и сам да си напишеш smtp библиотека, която да работи асинхронно (успех предвид че протоколът не е чак толкова прост и има вариации за автентикация, TLS и т.н) или по-простото....хващаш и пращаш поща както си знаеш, само че в отделна нишка. Сега обаче отворен става въпроса какво става ако нещо в нишката гръмне и ти трябва резултата от изпращането на пощата, ами настава забава.

Гейт, без да претендирам дали е правилно или не, но разсинхронизираният В/И съвсем натрапчиво ни се бута в носовете последните години, като посланието е ясно — от тук нататък нищо друго. Трябва да свикваме, че забавяния и латентност, ще са част от живота ни.

Аз още  не съм опитал болката от един такъв свят и твоите писания не са ми ясни. Уж ни обещават, че с разни техники, като актьори (от erlang), linq (от ©♯) и още някакви хави ще можем да пишем многонишково, както пишем мононишково и в бъдеще ще получим и допълнителни улеснения, които да ни позволяват да свързваме „повикване“ с „отговор“ по лесен начин. Малко ми е много мътна материята.

Та питането ми е всъщност такова. В този прочут Торнадо, дето ни го тикат (имам щастието вече да не пиша на Питон) и дето не се спогажда с никоя библиотека за изпращане на поща, не може ли да се направи нещо. Съгласен съм, че протокола е стар и академичен, което го прави неприятен. Но след като тази работа е свършена отдавна, не може ли за целите си на проекта да направите изменение само във входа и изхода на библиотеката, като основната функционалност да си остане? Аз се чудя, как така никой не се е блъскал над този въпрос.

Освен това аз като по-прост, май не бих правил тази задача с библиотеки, а бих я оставил на един външен server да се оправя. И като си получа обратно писмото да си го извадя от опашката и пратя там натам, дето ми трябва. Много по-просто ми се струва, отколкото да се занимавам с нишки. А както казах, аз досега с нишки не съм се занимавал и всяват в мен ужас. Откъде да знам машината, на която ще се изпълнява, колко нишки може да понесе, че да знам, колко да пусна.

Гейт, без да претендирам дали е правилно или не, но разсинхронизираният В/И съвсем натрапчиво ни се бута в носовете последните години, като посланието е ясно — от тук нататък нищо друго. Трябва да свикваме, че забавяния и латентност, ще са част от живота ни.

Всъщност не е така, асинхронния и неблокиращ вход/изход е начина да се реализира услуга, която да държи висок брой паралелни връзки, хората са стигнали до този извод много отдавна, справка знаменития c10k проблем. Никой не е казал "оттук нататък нищо друго".

Та питането ми е всъщност такова. В този прочут Торнадо, дето ни го тикат (имам щастието вече да не пиша на Питон) и дето не се спогажда с никоя библиотека за изпращане на поща, не може ли да се направи нещо. Съгласен съм, че протокола е стар и академичен, което го прави неприятен. Но след като тази работа е свършена отдавна, не може ли за целите си на проекта да направите изменение само във входа и изхода на библиотеката, като основната функционалност да си остане? Аз се чудя, как така никой не се е блъскал над този въпрос.

Кое е входа и кое е изхода?

Освен това аз като по-прост, май не бих правил тази задача с библиотеки, а бих я оставил на един външен server да се оправя. И като си получа обратно писмото да си го извадя от опашката и пратя там натам, дето ми трябва. Много по-просто ми се струва, отколкото да се занимавам с нишки. А както казах, аз досега с нишки не съм се занимавал и всяват в мен ужас. Откъде да знам машината, на която ще се изпълнява, колко нишки може да понесе, че да знам, колко да пусна.

Разбира се, може някакъв демон да разпраща пощи (с някакъв IPC механизъм) - това всъщност има доста предимства - обаче проблемът с вземането на статуса от операцията става още по-оплетен. Алтернативно решение (което някои хора много обичат) е да хванат да си напишат друг уеб сървис, чиято идея е да праща пощи. Което е друга идея - няма да блокираш цикъла дето poll-ва сокети в уеб приложението наистина, просто ще заметеш боклука в посока друго уеб приложение и ще създадеш същия проблем там (поне ще е ограничен в рамките на частта с "пращането на поща", няма да е проблем на цялото уеб приложение дето го гледат потребителите). Резултатът от цялата тази история обаче не ми допада - цялата тази фантасмагория с микросървисите дето размотават по http форматирани и опаковани по всякакъв начин бози, накрая това има склонността да му забравиш откъде почва и къде свършва и става като теория на сложния процес. Предполагам и от чисто административна гледна точка, менажирането на този контролиран хаос не е много приятно, не знам. Обаче това също е и модерна работа и за мой ужас става все по-модерна и по-модерна.