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

jet

  • Участник
  • *****
  • Публикации: 1805
  • Distribution: debian sid
  • Window Manager: kde
    • Профил
HTML се мъчиха да го заменят с какво ли не, но безуспешно.
То не беше Gopher, HUL, Telnet, но HTML винаги оцеляваше.
С прикърпване му добавяха функционалност DHTML, HTML2, Java, Flash, но върха на сладоледа е Active-X и SilverLight - бизнеса още не може да се откачи от Интернет Експлодър 6
« Последна редакция: Фев 10, 2016, 16:56 от jet »
Активен

Linux: From WTF to OMG

gat3way

  • Участник
  • *****
  • Публикации: 6050
  • Relentless troll
    • Профил
    • WWW
Цитат
Точно след една седмица, като го позабравя, почвам пак да се чудя как точно работи собствения ми код :o. А ако имах едно просто sleep() на критичното място нещата се опростяваха 10 пъти.

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

Активен

"Knowledge is power" - France is Bacon

go_fire

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

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

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

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

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

***

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

***

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

gat3way

  • Участник
  • *****
  • Публикации: 6050
  • Relentless troll
    • Профил
    • WWW
Цитат
Гейт, без да претендирам дали е правилно или не, но разсинхронизираният В/И съвсем натрапчиво ни се бута в носовете последните години, като посланието е ясно — от тук нататък нищо друго. Трябва да свикваме, че забавяния и латентност, ще са част от живота ни.

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

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


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


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

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

Активен

"Knowledge is power" - France is Bacon