Было бы меньше 100 баксов, можно было бы использовать вместо медиаконверторов для передачи изображений на ТВ по сети (например, полноэкранный браузер, а в нем уже нужная картинка формируется). А так пока что дорого, нужно сокращение цены еще в 2-4 раза хотя бы.
В статье же написано: на винчестеры — это затраты на содержание, а VmWare была куплена под целевую программу (разовый проект, может быть и финансировался областью или федерацией, а не городом).
что плохого в том, что хорошую идею реализовали? идея лежит на поверхности, ничего оригинального в ней нет. отдельный вопрос как реализовали, но это уже совсем другая история…
это «подкапотная» технология, которая видна пользователю и веб-разработчику как «стал быстрее работать яваскрипт». тут особо обсуждать нечего, а вот отвалившийся используемый плагин — вполне реальная «зубная» боль.
это проблема пользователей и сообщества Firefox в целом. Естественно, технически это проблема плагина, а не браузера, но от этого пользователю, которому по большому счету непонятны новшества 9ой версии с отвалившимися плагинами не легче.
И что в этом странного для обычного open source плагина без community разработчиков и способа монетизации? Почему если я, как автор, выложил какой-то плагин, то должен где-то скачивать бету браузера, тестировать, исправлять и т.п.? Вполне адекватная логика разработчика подобного типа плагинов: у меня работает, как обновится исправлю и даже выложу новую версию бесплатно, не жалко; никому ничего не обещалось, не хотите — не пользуйтесь, вы же за это ничего не платите.
При чем здесь «хомячки»? Удобно иметь возможность просмотреть разноплановые статьи и читать что заинтересовало. Остальное можно прокрутить. А следить за сотней сайтов неудобно и слишком много времени отнимает.
Дополнительно, уже по статье, подход «vm.send_desired_mem» не отличается от ввода нового параметра desired_mem в REST.
Главное, что нужно понять, это то, что REST — это способ доступа к некоторому пассивному ресурсу (БД по сути), который клиенты (не только люди, но и приложения) могут менять. И он может становится в приложении похожим на активный ресурс в простых случаях, но это не должно смущать при работе с более сложными (то же уменьшение памяти). Какие именно поля должны быть представлены в ресурсе (память или актуальная память с желаемой памятью) зависит от потребностей алгоритмов и данных на вход/выход.
В принципе, нарушения парадигмы нет. 1ый клиент (пользователь) записал to-reboot, 2ой клиент (агент виртуальной машины) каким-либо образом (полинг в простейшем случае, но можно и оптимизировать по разному) узнал, что состояние стало to-reboot и изменил его на rebooting. Т.о., при состоянии to-reboot повторные to-reboot ничего не изменят, а при состоянии rebooting повторные вызовы могут что-то поменять, а могут и ничего не поменять (агент восстановит значение ресурса в rebooting на основе своего внутреннего состояния после получения информации о том, что поле изменилось или запустит еще один ребут — в зависимости от того что требуется).
Могут ли идеологически два клиента что-то менять на основе изменений друг друга? Думаю, что могут. Например, легко можно представить двух человек правящих статью в вики подобным образом.
Является ли объединение агента виртуальной машины и обработчика REST-запросов идеологически некорректным действием? Т.к. схема изменения состояний ресурса остается и внешне REST работает так же (по сути для целей оптимизации исключается информирование агента о событии через http и ожидание ответа от него), то с точки зрения REST подобный подход чист.
EM справляется, но тот же rails не больно-то. Уже есть экспериментальное асинхронное приложение на rails, но нужно вручную следить как бы синхронный ввод/вывод где-нить не вылез. Пока что сложно сказать, что ruby/EM такой уж серьезный конкурент для node.js.
Проблема — да, но изначально тот же Rubinius ставил это как одной из главных бизнес-целей. До приемлемого уровня можно довести защиту шаревар.
— нет экономии памяти, как у REE
— 'а'..'я' не включает 'ё'
— вроде бы еще какие-то проблемы с кодировками были
— есть еще много всяких мелочей, связанных с метамоделями (как например описанные в статье выше)
— проблемы работы в асинхронном режиме, чтобы как node.js работать (больше к стандартным библиотекам вопрос, а не к самому языку)
— можно было бы еще как-нибудь над скоростью поколдовать, движки же яваскрипта постоянно ускоряют
— встроенная поддержка shareware-программ, а то сейчас только практически исключительно в saas используется (широко известно только о mingle и github:fi, оба через jruby).
Для таких случаев нужно еще авторизацию по токену использовать (хард или софт на сотовом). Пароль + токен — уже совсем хорошая защита, если думаете, что вас будут ломать с использованием видеокамер и прочего.
Главное, что нужно понять, это то, что REST — это способ доступа к некоторому пассивному ресурсу (БД по сути), который клиенты (не только люди, но и приложения) могут менять. И он может становится в приложении похожим на активный ресурс в простых случаях, но это не должно смущать при работе с более сложными (то же уменьшение памяти). Какие именно поля должны быть представлены в ресурсе (память или актуальная память с желаемой памятью) зависит от потребностей алгоритмов и данных на вход/выход.
Могут ли идеологически два клиента что-то менять на основе изменений друг друга? Думаю, что могут. Например, легко можно представить двух человек правящих статью в вики подобным образом.
Является ли объединение агента виртуальной машины и обработчика REST-запросов идеологически некорректным действием? Т.к. схема изменения состояний ресурса остается и внешне REST работает так же (по сути для целей оптимизации исключается информирование агента о событии через http и ожидание ответа от него), то с точки зрения REST подобный подход чист.
Про «best of value»: стоит посмотреть на сделанный для России ZyXEL X8004 (по крайней мере дешевле AA65 и AA305).
Проблема — да, но изначально тот же Rubinius ставил это как одной из главных бизнес-целей. До приемлемого уровня можно довести защиту шаревар.
— 'а'..'я' не включает 'ё'
— вроде бы еще какие-то проблемы с кодировками были
— есть еще много всяких мелочей, связанных с метамоделями (как например описанные в статье выше)
— проблемы работы в асинхронном режиме, чтобы как node.js работать (больше к стандартным библиотекам вопрос, а не к самому языку)
— можно было бы еще как-нибудь над скоростью поколдовать, движки же яваскрипта постоянно ускоряют
— встроенная поддержка shareware-программ, а то сейчас только практически исключительно в saas используется (широко известно только о mingle и github:fi, оба через jruby).