Не помогает. Видел софт, который в наглую ставит яндекс бар, даже если убрать галочку. При этом не детектируется вирусами, как malware.
Даже если всё законно и галочка работает — зачем подменять домашние страницы у браузеров? Это разве этично?
Да вообще неприятно, когда каждый раз при установки программы вас пытаются обмануть всеми «почти законными» способами, при молчаливом содействии яндекса.
Если с вашего IP кто-то совершил преступление, то то что у вас установлен Tor больше не является оправданием (по аналогии с преступлением в пьянном виде — человек пьянный, себя не контролировал, но всё равно виноват, ибо не нужно было пить).
После этого мало кто из законопослушных людей захочет им пользоваться, соответственно для остальных он просто будет не интересн.
Удалось связаться с автором. В общем договорились что он меня немного подождёт и потом как-то вместе реализуем модули, т.к. сам их реализовывать он пока не планирует.
Ха! Час назад этого модуля ещё не было по поиску «Glacier». Только что опубликован. Так же появился Net::Amazon::Signature::V4
Операции с архивами не реализованы пока что.
Свяжусь с автором. Подумаем чем помочь друг-другу.
в S3 используется другой «протокол» подписи запроса. В Glacier он гораздо сложнее docs.amazonwebservices.com/general/latest/gr/signature-version-4.html
Что подтверждается в исходном тексте — во всех этих модулях требуется hmac_sha1, а для glacier нужен sha256
А без Signature Version 4 — общее у S3 и Glacier — только HTTP (модуль LWP::UserAgent)
или вот, модуль для S3:
в нём до сих пор нет поддержки multipart upload. а если и будет, то где гарантия, что получится всё сделать многопоточно? Читая данные с диска только один раз, и не расчитывая TreeHash дважды для одних и тех же данных? Читать данные со STDIN?
Вообще, универсальные, CPAN модули — это здорово. Но за универсальность нужно платить. Как-то раз писал прокси на perl, где, помимо самого проксирования, child процессы общаются с main процессом и делают какие-то вычисления, статистику. После бенчмарков и оптимизации, прокси вышел быстрее сквида (в процессе бенчмарка он обращался с каждым запросом к squid. Squid потреблял 60% CPU, он 20%). Так вот, самое интересное, что самая медленная часть этого прокси — LWP::UserAgent.
Java — не моя стихия, но думаю для многопоточных серверных приложений — самое то. Хотя иногда у администраторов есть проблемы с деплоем Java приложений на сервер, т.к. они немного отличаются от unix-way.
Кстати кое какой код Glacier на Java выложил сам Amazon.
Ruby — моё личное мнение, что Ruby чаще всего используется с Rails, а без Rails, в системном программирование, с сокетами, с fork — гораздо реже.
Плюс у ruby плохо совместимы версии 1.8 и 1.9, RVM на production не был признан stable, когда я последний раз проверял — а это, опять же, проблемы с деплоем.
Даже если всё законно и галочка работает — зачем подменять домашние страницы у браузеров? Это разве этично?
Да вообще неприятно, когда каждый раз при установки программы вас пытаются обмануть всеми «почти законными» способами, при молчаливом содействии яндекса.
Если с вашего IP кто-то совершил преступление, то то что у вас установлен Tor больше не является оправданием (по аналогии с преступлением в пьянном виде — человек пьянный, себя не контролировал, но всё равно виноват, ибо не нужно было пить).
После этого мало кто из законопослушных людей захочет им пользоваться, соответственно для остальных он просто будет не интересн.
Операции с архивами не реализованы пока что.
Свяжусь с автором. Подумаем чем помочь друг-другу.
в S3 используется другой «протокол» подписи запроса. В Glacier он гораздо сложнее docs.amazonwebservices.com/general/latest/gr/signature-version-4.html
Что подтверждается в исходном тексте — во всех этих модулях требуется hmac_sha1, а для glacier нужен sha256
А без Signature Version 4 — общее у S3 и Glacier — только HTTP (модуль LWP::UserAgent)
или вот, модуль для S3:
в нём до сих пор нет поддержки multipart upload. а если и будет, то где гарантия, что получится всё сделать многопоточно? Читая данные с диска только один раз, и не расчитывая TreeHash дважды для одних и тех же данных? Читать данные со STDIN?
Вообще, универсальные, CPAN модули — это здорово. Но за универсальность нужно платить. Как-то раз писал прокси на perl, где, помимо самого проксирования, child процессы общаются с main процессом и делают какие-то вычисления, статистику. После бенчмарков и оптимизации, прокси вышел быстрее сквида (в процессе бенчмарка он обращался с каждым запросом к squid. Squid потреблял 60% CPU, он 20%). Так вот, самое интересное, что самая медленная часть этого прокси — LWP::UserAgent.
Тот же модуль LWP::UserAgent — стандарт де-факто, можно сказать. Но если что-то серьёзное нунжно на нём сделать, всплывают грабли, и не одни:
stackoverflow.com/questions/73308/true-timeout-on-lwpuseragent-request-method
http://search.cpan.org/~bradfitz/LWPx-ParanoidAgent-1.02/lib/LWPx/ParanoidAgent.pm
В общем, я не особо переживал, когда делал собственные модули вместо поиска/интеграции существующих.
Кстати кое какой код Glacier на Java выложил сам Amazon.
Ruby — моё личное мнение, что Ruby чаще всего используется с Rails, а без Rails, в системном программирование, с сокетами, с fork — гораздо реже.
Плюс у ruby плохо совместимы версии 1.8 и 1.9, RVM на production не был признан stable, когда я последний раз проверял — а это, опять же, проблемы с деплоем.
Поэтому выбрал Perl.