А вы не пробовали посмотреть на сравнения производительности xen и реального железа? что то мне говорит что на задачах, где требуются вычисления, виртуалка будет очень далеко… позади.
В случае с vds та же фигня. Порт то у виртуальной машины один (уж точно не на каждого пользователя).
И вообще перестаньте воспринимать сетевой порт как нечто выделенное и личное, давно все уже шейпится либо управляемым свичом либо дальше.
XP что, не может решать задачи, которые возлагаются на нетбуки? Какая нафиг разница, сколько лет назад было создано ПО, если оно решает текущие задачи хорошо и даже лучше.
Устанавливаемое оборудование обязательно должно быть одним из этих двух вариантов, или можно собрать что-то своё? При условии сохранения габаритов конечно же.
Если из вопроса убрать слова 'популярны/распространены' (не обладаю достаточными данными чтобы отвечать именно на это), то…
* Кеширование EAV?
Самое первое решение, что приходит обычно в голову, это возврат к модели преставления данных, проблемы которой оно и решает, т.е. создание таблиц с полями — соответствующих элементам из EAV. Само собой только для тех атрибутов, доступ к данным которых — узкое место.
EAV: prop(id,name)={1: это,2: то,3: тому,4: того,...}, object(id,...), values(id,object_id,prop_id,data)
Кэш: cache(object_id,prop1,prop2,prop3)
Плюсы: облегчает задание сложных ограничений целостности (constraint на кэш), увеличивает скорость доступа к значениям пропертей (индексы на propX у кэша)
Минусы: неполная транзакционность (изменение prop, да еще внутри тригеров — кошмар), вроде нет БД предоставляющих транзакции на команды DDL, меняет подход к построению SQL запросов и ограничивает/усложняет удаление элементов из prop.
* Соответствие кеша данным?
Что тут можно предложить, только тригеры или использование прослойки между БД и приложением (фактически свои собственные тригеры).
Прослойка между приложением и БД вообще полезная вещь не только для подобных задач, если использовать информацию о модели данных, на этапе проектирования в (полу)автоматическом режиме, то создание подобных кешей можно вообще практически полностью автоматизировать.
Ну по поводу пунктов про ORM, EAV и IDE я бы поспорил.
* ORM — нужно изобретать, в идеале, править имеющиеся. Так как то что есть далеки от идеала. На практике реально использовали практически полностью своё, первая версия конечно же больна всеми болезнями, что дают велосипедостроение и первооткрыватели, но идеи, особенно на вторую версию, очень даже здравые.
* EAV — отказываться от этой модели не просто глупо а преступление :) в некоторых случаях без нее просто не обойтись. Говорить что эта модель в чем то ограничивает как то глупо, я не согласен, изменение структуры данных без изменения структуры физического хранилища очень большой плюс. Проблемы с производительностью решаются, к примеру, 'кешем' в нормальных формах, для критичных для скорости данных.
* IDE — полностью отказываться конечно тяжело да и не нужно, практика показывает что в части задач разработки лучше использовать что 'то мышастое' (это шутка, имеется в виду готовые инфраструктуры сборки, отладки, тестирования, генерации установки и т.д.) чтобы не тратить на это время, за это же можно заплатить потерей производительности конечной программы (хотя выбор IDE и фреймворка должен быть обдуманным с оглядкой именно на производительность, а не только на возможности). но практика показывает что какие то задачи удобнее решать 'своими силами', в этом случае IDE, которое можно допилить до желаемого, предпочтительна.
Может быть 'каким критином надо быть, чтобы для несложных задач покупать дорогущее и мощнейшее железо?' А мизерные размеры вы не замечаете? а энергопотребление? а уровень шума?
А то получается, покупают супер комп от 3к$, а на нем 'секретарша' дальше пасьянса, ворда и вконтакте не вылезает.
Видео декодеры на сколько я знаю пока не cuda (офицально), но явно используют производные технологии.
Подскажите, кто имеет опыт работы с mini itx решениями со встроенными видео nvidia. интересует производительность cuda приложений, для тестов можно воспользоваться готовыми примерами, входящими в состав cuda sdk (например particles.exe -n=500000 -grid=200 у меня притормаживает на 9800gtx+)
Ну одно из первых заданий, которое бы я поручил роботу — это зарабатывание для меня… денег, мелко? ну расширьте это сложными примерами и возможностями, все равно это уже в сущности не важно. Робот должен работать для/на человека… + робот должен обслуживать себя сам.
Следующие задачи — развлечение.
Извините, но потребности человека в 'хлебе и зрелищах' никуда не исчезнут, так что их решение — это первое и, возможно, единственное.
С gentoo и кросс-компиляцией 'можно все', с оговоркой по поддержке железа. Как обычно в таких случаях могут быть проблемы, ну к примеру с проигрыванием видео с ускорением, это в лучшем случае. Про wifi, bluetooth и картридер тоже нужно не забывать.
P.S. если ubuntu пашет 'из коробки' то очень большие шансы что проблем не будет.
Ну да, операционка еще работает на 128мб, а вот программам уже мало остается!
Оперативка уже давно копеешная, когда же наконец производители/сборщики повернутся к пользователям лицом, а не другим местом как сейчас.
Жду ARM нетбук, потребности минимальные, но есть, пока терплю ущербные 2-3 часа от eee pc 901/ Куплю следующий, когда опративки будет минимум 1 гб, обязательный видео-ускоритель и время работы минимум 8ч (просмотра видео без wifi). Готов пожертвовать оперативкой, только за счет уменьшения размера до 9" тонкой таблетки (планшетника) и при условии, само собой, приемлемой цены, т.к. не cтоят задачи, возлагаемые на эти устройства, дороже 500$-600$.
И вообще перестаньте воспринимать сетевой порт как нечто выделенное и личное, давно все уже шейпится либо управляемым свичом либо дальше.
eeepc 901 при полной зарядке 3 часа 20 мин.
* Кеширование EAV?
Самое первое решение, что приходит обычно в голову, это возврат к модели преставления данных, проблемы которой оно и решает, т.е. создание таблиц с полями — соответствующих элементам из EAV. Само собой только для тех атрибутов, доступ к данным которых — узкое место.
EAV: prop(id,name)={1: это,2: то,3: тому,4: того,...}, object(id,...), values(id,object_id,prop_id,data)
Кэш: cache(object_id,prop1,prop2,prop3)
Плюсы: облегчает задание сложных ограничений целостности (constraint на кэш), увеличивает скорость доступа к значениям пропертей (индексы на propX у кэша)
Минусы: неполная транзакционность (изменение prop, да еще внутри тригеров — кошмар), вроде нет БД предоставляющих транзакции на команды DDL, меняет подход к построению SQL запросов и ограничивает/усложняет удаление элементов из prop.
* Соответствие кеша данным?
Что тут можно предложить, только тригеры или использование прослойки между БД и приложением (фактически свои собственные тригеры).
Прослойка между приложением и БД вообще полезная вещь не только для подобных задач, если использовать информацию о модели данных, на этапе проектирования в (полу)автоматическом режиме, то создание подобных кешей можно вообще практически полностью автоматизировать.
* ORM — нужно изобретать, в идеале, править имеющиеся. Так как то что есть далеки от идеала. На практике реально использовали практически полностью своё, первая версия конечно же больна всеми болезнями, что дают велосипедостроение и первооткрыватели, но идеи, особенно на вторую версию, очень даже здравые.
* EAV — отказываться от этой модели не просто глупо а преступление :) в некоторых случаях без нее просто не обойтись. Говорить что эта модель в чем то ограничивает как то глупо, я не согласен, изменение структуры данных без изменения структуры физического хранилища очень большой плюс. Проблемы с производительностью решаются, к примеру, 'кешем' в нормальных формах, для критичных для скорости данных.
* IDE — полностью отказываться конечно тяжело да и не нужно, практика показывает что в части задач разработки лучше использовать что 'то мышастое' (это шутка, имеется в виду готовые инфраструктуры сборки, отладки, тестирования, генерации установки и т.д.) чтобы не тратить на это время, за это же можно заплатить потерей производительности конечной программы (хотя выбор IDE и фреймворка должен быть обдуманным с оглядкой именно на производительность, а не только на возможности). но практика показывает что какие то задачи удобнее решать 'своими силами', в этом случае IDE, которое можно допилить до желаемого, предпочтительна.
А то получается, покупают супер комп от 3к$, а на нем 'секретарша' дальше пасьянса, ворда и вконтакте не вылезает.
P.S. картинка трафик кушает 8кб/сек
Подскажите, кто имеет опыт работы с mini itx решениями со встроенными видео nvidia. интересует производительность cuda приложений, для тестов можно воспользоваться готовыми примерами, входящими в состав cuda sdk (например particles.exe -n=500000 -grid=200 у меня притормаживает на 9800gtx+)
Следующие задачи — развлечение.
Извините, но потребности человека в 'хлебе и зрелищах' никуда не исчезнут, так что их решение — это первое и, возможно, единственное.
gentoo из-за своей специфики вещь очень капризная, но если все делать правильно то проблемы сильно минимизируются.
P.S. интересно, когда народ запомнит, что без бакапов ну просто никуда.
Кстати, кросскомпиляция в gentoo не такая уж и 'в один клик'.
P.S. если ubuntu пашет 'из коробки' то очень большие шансы что проблем не будет.
Оперативка уже давно копеешная, когда же наконец производители/сборщики повернутся к пользователям лицом, а не другим местом как сейчас.
Жду ARM нетбук, потребности минимальные, но есть, пока терплю ущербные 2-3 часа от eee pc 901/ Куплю следующий, когда опративки будет минимум 1 гб, обязательный видео-ускоритель и время работы минимум 8ч (просмотра видео без wifi). Готов пожертвовать оперативкой, только за счет уменьшения размера до 9" тонкой таблетки (планшетника) и при условии, само собой, приемлемой цены, т.к. не cтоят задачи, возлагаемые на эти устройства, дороже 500$-600$.