Trophy и Mozart на картинках выглядят просто великолепно, на мой вкус. Да и характеристики хороши. Так что в цену 199$, не верится абсолютно. Посмотрим что получится в итоге. :)
А вообще не гугл деньги печатает (ну я пока искренне надеюсь на это), поэтому инфляция совершенно одинаковая в не зависимости от того скопилась наличка у гугла, или у десятка других компаний. Важно сколько денег выпущено на рынок и чем они обеспечены, а не у кого они скопились.
Ну я-то уже ваш RSS себе в reader добавил уже, а вообще тут, на хабре, самое место, не слушайте троллей. Возможно, даже, в блоге про пользовательские интерфейсы.
И, да, про мультибар в целом.
Для winXP — отличная замена таксбара из win7! А вот в самой win7, я бы его не ставил, хотя, возможно, следующие версии меня переубедят. :)
Фичреквест: хорошо было бы добавить поддержку двух мониторов.
— Возможность выбирать монитор для отображения бара.
— Возможность растягивать бар на два монитора с возможностью раскидывания иконок по двум мониторам.
— Простое дублирование: один и тот же бар, с одним и тем же набором иконок, на обоих мониторах.
Нет скорость, разумеется, имелась ввиду не скорость единичного клиента, как раз под большой нагрузкой преимущества и проявляются. И да, мы тоже любим nginx как и вы. :)
В целом, я с вами согласен, до продакшна ещё очень далеко, какое бы решение выбрано не было, и пока работаем с тем, что хорошо умеем готовить. Но при этом интересуют и другие success stories, нельзя зацикливаться не используемых технологиях. Скажем, MongoDB нам не очень подходит из-за того, что по-умолчанию очень не стабильно работает с виртуализацией, это не удобно для поддержки.
На самом деле в вашем варианте главный плюс — скорость, как мне кажется. Всё-таки по чистой скорости отдачи статики с nginx мало что может сравниться, а с хорошо затюненным nginx и правильно-приготовленным дисковым кэшем — тем более. CouchDB пока не пришлось протестировать на скорость, но он будет медленнее, точно.
Однако, основной минус вашего варианта, на мой взгляд, в том что всю логику для масштабируемости системы, для балансировки, для обеспечения должной отказоустойчивости и т.д. придется реализовывать самостоятельно, на уровне бизнес-логики системы. Это не удобно, не гибко, не прозрачно для поддержки. С NoSQL же мы работаем с одним-единственным хранилищем (почти как с одной-единственной локальной файловой системой… ну может чуть сложнее :)), и наша система ничего не знает о том, где хранятся файлы, и как именно они будут отдаваться, это разруливается на уровне самого хранилища. Этот подход очень импонирует.
Ну и плюс, не надо забывать, что система не просто картинки раздаёт, а некоторым образом использует их в приложении, а значит для них неплохо было бы и где-то хранить мета-информацию (размеры, например), уметь объединять их в коллекции, и манипулировать целыми группами файлов. Тут NoSQL тоже даст дополнительные плюсы.
А для чего лично вы используете CouchDB, если не секрет? Теория это хорошо, но уж очень бы хотелось почитать побольше реальных «success stories» использования CouchDB в живых приложениях, чтобы оценить преимущества относительно альтернативных решений.
Мы сами сейчас присматриваемся к CouchDB как к варианту для создания кластеризуемого хранилища изображений (фотографии, иллюстрации к контенту, многочисленные превьюшки и т.д.). В таком контексте не приходилось её использовать?
Это значит, что про официальный update для «Desire и ко» выше версии 2.2 можно если не забыть, то не ждать в течении долгого, очень, очень долго времени после появления его на вот этой прелести. Хорошо хоть 2.2 уже обещать успели.
А аппарат неплохой. Только великоват на мой взгляд, и прожорливый видимо.
Если цель сообщения перечислить контакт-листы, подчеркнув их большое количество, то да, конечно. Хотя правильнее было бы написать «icq, 2 jabber'а, msn и т.д.», чтобы избежать употребления двух одинаковых слов подряд.
Но какая нам с вами разница, что и как захотел написать автор, в самом деле? :) Не будем продолжать дискуссию.
> А как это относится к тому, что я сказал?
> Я лишь сказал, что один из них является подмножеством второго.
В контексте коммента на который вы отвечали — не обязательно. Так как контакт-листы в gtalk и jabber у автора могут быть совершенно не пересекающиеся, с абсолютно разными наборами контактов. Вы же заметили, что речь вообще говоря, про контакт-листы, а не протоколы? Автор перечислял свои контакт-листы в клиенте, и тут совершенно не важно, что два из них используют один и тот же протокол.
А вообще не гугл деньги печатает (ну я пока искренне надеюсь на это), поэтому инфляция совершенно одинаковая в не зависимости от того скопилась наличка у гугла, или у десятка других компаний. Важно сколько денег выпущено на рынок и чем они обеспечены, а не у кого они скопились.
Для winXP — отличная замена таксбара из win7! А вот в самой win7, я бы его не ставил, хотя, возможно, следующие версии меня переубедят. :)
— Возможность выбирать монитор для отображения бара.
— Возможность растягивать бар на два монитора с возможностью раскидывания иконок по двум мониторам.
— Простое дублирование: один и тот же бар, с одним и тем же набором иконок, на обоих мониторах.
В целом, я с вами согласен, до продакшна ещё очень далеко, какое бы решение выбрано не было, и пока работаем с тем, что хорошо умеем готовить. Но при этом интересуют и другие success stories, нельзя зацикливаться не используемых технологиях. Скажем, MongoDB нам не очень подходит из-за того, что по-умолчанию очень не стабильно работает с виртуализацией, это не удобно для поддержки.
Однако, основной минус вашего варианта, на мой взгляд, в том что всю логику для масштабируемости системы, для балансировки, для обеспечения должной отказоустойчивости и т.д. придется реализовывать самостоятельно, на уровне бизнес-логики системы. Это не удобно, не гибко, не прозрачно для поддержки. С NoSQL же мы работаем с одним-единственным хранилищем (почти как с одной-единственной локальной файловой системой… ну может чуть сложнее :)), и наша система ничего не знает о том, где хранятся файлы, и как именно они будут отдаваться, это разруливается на уровне самого хранилища. Этот подход очень импонирует.
Ну и плюс, не надо забывать, что система не просто картинки раздаёт, а некоторым образом использует их в приложении, а значит для них неплохо было бы и где-то хранить мета-информацию (размеры, например), уметь объединять их в коллекции, и манипулировать целыми группами файлов. Тут NoSQL тоже даст дополнительные плюсы.
Мы сами сейчас присматриваемся к CouchDB как к варианту для создания кластеризуемого хранилища изображений (фотографии, иллюстрации к контенту, многочисленные превьюшки и т.д.). В таком контексте не приходилось её использовать?
А прошивка неплоха, но с всё же с некоторыми багами пока. Хотя я и думаю её поставить.
А аппарат неплохой. Только великоват на мой взгляд, и прожорливый видимо.
Но какая нам с вами разница, что и как захотел написать автор, в самом деле? :) Не будем продолжать дискуссию.
> Я лишь сказал, что один из них является подмножеством второго.
В контексте коммента на который вы отвечали — не обязательно. Так как контакт-листы в gtalk и jabber у автора могут быть совершенно не пересекающиеся, с абсолютно разными наборами контактов. Вы же заметили, что речь вообще говоря, про контакт-листы, а не протоколы? Автор перечислял свои контакт-листы в клиенте, и тут совершенно не важно, что два из них используют один и тот же протокол.
Да, тоже xmpp, но у многих перешедших на gtalk остаются активными и старые jabber-аккаунты по разным причинам. Да и корпоративные…