стильно, модно, молодежно?
Вообще 64 бита имеет смысл если использовать его не для веба, а для кодирования видео/аудио/еще чего-нибудь с помощью встроенных DSP. Самим камнем тоже можно, но уже надо считать что выгоднее — кучка армов или числодробилка на базе ксеонов.
Лучше не надо. Я поставил на свой LG G540 сначала спорку AOSP — она вообще неюзабельна. Потом накатил CM9 — в принципе жить можно, особенно если отключить всю анимацию — тогда летает намного быстрее родной прошивки 2.1. Но кол-во глюков просто феноменальное :(
Ну тут весь вопрос в задаче — если надо поднять сервис предоставляющий клиентам всякие разные карты — то да, проще использовать готовый вариант и заплатить немножко денег.
Если же задача карт на сайте показать как доехать до, например, магазинов фирмы — то почему бы и нет — большой нагрузки на сервис это не создаст.
Но на данный момент, если душит жаба платить гуглу, проще сменить движек на яндекс.карты и не заморачиваться :)
У OSM есть один важный момент по сравнению с гуглосервисом — ты можешь слить карты на свой сервак, поднять там зеркало и работать с ним. Что в разы увеличит скорость работы карт на сайте за счет небольшого удорожания поддержки сайта.
Ну и разгрузит сервера OSM заодно :)
Это из серии организуй DDOS на свой сервер сам?
Это не говоря уже о том, что авторизация пользователя начнет занимать достаточно существенное время при n даже не доходящих до 10
Дык в этом и заключается разница между нормальным разработчиком и «Васей» — нормальный разработчик учится и улучшает качество кода/архитектуры, «Вася» же…
DropBox это вообще модифицированный SVN клиент. iDisk я думаю тоже что-то из этой серии.
Т.е. по большому счету все что они делают — автоматический коммит с пушем в удаленный репозиторий и автоматический чэкаут на других компьютерах. Естественно все это в окружении плюшек, рюшек и красивого интерфейса :)
Поднять такое не проблема совершенно, я полгода назад видел статьи на эту тему.
Ну вариантов как это сделать по большому счету тьма.
Просто все они слабо сочетаются с невозможностью правообладателю выяснить есть ли файл на сервисе или нет и всех прижать по результатам.
Ну как раз пользователю сервиса проблем передать ключь для расшифровки по идее нет. Другой вопрос что тогда все заявления про правообладателей являются чистейшей воды маркетингом и действительности соответствуют весьма слабо.
Да и собственно сейчас гадать то бессмысленно — в ролике на сайте и пресс-релизе на CNET только чистой воды реклама, без какой-либо конкретики.
Ну допустим посчитали мы хэш незашифрованного файла у клиента, нашли такой же в облаке.
И какие дальнейшие действия?
Можно сказать клиенту что файл загружен — тогда получается что он будет лежать в облаке зашифрованный чужим ключем и ключ этот надо передать пользователю, который скачивает этот файл, чтобы он смог его расшифровать.
Вобщем чувствуется какой-то подвох в их словах.
В каком формате список прокси лежит? Если в виде — каждый прокси на строку в файле, то цикл перебора можно упростить до: # Читаем список проксей
open FIL, 'proxy.lst';
my @proxy = ;
@proxy = grep { /(\d+\.\d+\.\d+\.\d+:\d+)/ } @proxy;
print "Proxies found: ".@proxy."\n";
выборка следующего прокси из массива тоже не особо ясная конструкция, ее можно привести к виду: # Получаем следующую проксю из списка
my $proxy=shift(@proxy);
# Если список кончился, заканчиваем
unless ($proxy) {
print "- Thread $num done.\n";
return;
}
И вообще лучше не использовать бесконечный цикл с тредами, а использовать AnyEvent.
А зачем закрывать через .htaccess папку .git когда можно использовать detached рабочий каталог и хранить сам репозиторий в недоступном для веб-сервера месте?
Опция --work-tree служит для этой цели. www.kernel.org/pub/software/scm/git/docs/
Вообще 64 бита имеет смысл если использовать его не для веба, а для кодирования видео/аудио/еще чего-нибудь с помощью встроенных DSP. Самим камнем тоже можно, но уже надо считать что выгоднее — кучка армов или числодробилка на базе ксеонов.
На это имеет смысл повесить фронтэнд, обрабатывающий кучи пользовательских запросов, а базу держать на ксеоне.
Если же задача карт на сайте показать как доехать до, например, магазинов фирмы — то почему бы и нет — большой нагрузки на сервис это не создаст.
Но на данный момент, если душит жаба платить гуглу, проще сменить движек на яндекс.карты и не заморачиваться :)
Ну и разгрузит сервера OSM заодно :)
Это не говоря уже о том, что авторизация пользователя начнет занимать достаточно существенное время при n даже не доходящих до 10
Т.е. по большому счету все что они делают — автоматический коммит с пушем в удаленный репозиторий и автоматический чэкаут на других компьютерах. Естественно все это в окружении плюшек, рюшек и красивого интерфейса :)
Поднять такое не проблема совершенно, я полгода назад видел статьи на эту тему.
@proxy = grep { /(\d+\.\d+\.\d+\.\d+:\d+)/ } @proxy;надо заменить на:
@proxy = map { /(\d+\.\d+\.\d+\.\d+:\d+)/g } @proxy;Берем первую попавшуюся статью по настройке, настраиваем и радуемся :)
Просто все они слабо сочетаются с невозможностью правообладателю выяснить есть ли файл на сервисе или нет и всех прижать по результатам.
Да и собственно сейчас гадать то бессмысленно — в ролике на сайте и пресс-релизе на CNET только чистой воды реклама, без какой-либо конкретики.
И какие дальнейшие действия?
Можно сказать клиенту что файл загружен — тогда получается что он будет лежать в облаке зашифрованный чужим ключем и ключ этот надо передать пользователю, который скачивает этот файл, чтобы он смог его расшифровать.
Вобщем чувствуется какой-то подвох в их словах.
my @proxy = <FIL>; должно быть
В каком формате список прокси лежит? Если в виде — каждый прокси на строку в файле, то цикл перебора можно упростить до:
# Читаем список проксей
open FIL, 'proxy.lst';
my @proxy = ;
@proxy = grep { /(\d+\.\d+\.\d+\.\d+:\d+)/ } @proxy;
print "Proxies found: ".@proxy."\n";
выборка следующего прокси из массива тоже не особо ясная конструкция, ее можно привести к виду:
# Получаем следующую проксю из списка
my $proxy=shift(@proxy);
# Если список кончился, заканчиваем
unless ($proxy) {
print "- Thread $num done.\n";
return;
}
И вообще лучше не использовать бесконечный цикл с тредами, а использовать AnyEvent.
Опция --work-tree служит для этой цели. www.kernel.org/pub/software/scm/git/docs/