1. Лайтрум гораздо гибче позволяет работать с метками, с именами файлов, служебной информацией и т.п.
Да, сложной фильтрацией я называл именно это
Кисточки работают с дичайшими тормозами и очень слабой точностью, не пригодной для профи использования.
Про тормоза добавил, я думал это из-за того что у меня еще не все фотографии отрендерелись или много фотографий в одном альбоме (около 3-4 тысяч туда для пробы импортировал).
Но лайтрум, по большому счету, программа для фотографов-энтузиастов (т.е. непрофессионалов), которым нужно получать из одного софта сразу готовый результат. А фотошоп слишком сложен.
Тут не соглашусь — профессиональным фотографам тоже может потребоваться сначала массово обработать и/или отобрать фото из сессии снимков и только потом обработать отдельные в Photoshop уже детально.
Динамический диапазон? Чувствительность? Все это не важно? Завидую.
Вопрос светочувствительности я решил светосильным объективом — его мне хватает чтобы снимать в комнате в пасмурную погоду без вспышки и получать хорошие яркие фотографии на iso 100-400, выше приходится ставить очень редко. С недостатком динамический диапазона пока (последние 2-3 года съемки на зеркалку) не сталкивался. Цветопередача меня в большинстве случаев даже у iPhone устраивает.
Если вы храните XMP, то вы вообще не зависите от каталога LR.
Да, стараюсь не зависеть особенно теми способами которые не доставляют никаких неудобств.
Если он запустится.
А куда он денется? Я слабо представляю себе резкий скачек куда-нибудь с таким размахом что старый софт даже в виртуалке ради разовой операции нельзя будет запустить.
Вы еще обратите внимание на сценарий, при котором какой-нибудь 7-ой LR обладает нужной вам новой функциональностью, но не может импортировать каталоги из вашей версии (далеко не все ПО умеет импортировать данные через несколько версий).
Затем открыл этот каталог моей текущей версией 5.4 — каталог открылся с предложением конвертации, я согласился и тестовый каталог был успешно конвертирован.
Даже если конвертация в далекой версии окажется недоступной (в чем я сомневаюсь) — всегда можно скачать какую-то промежуточную версию и конвертировать каталог сначала в ней, а потом уже в новой.
Если и это будет невозможно — я обращусь в поддержку разработчика с вопросом как мне быть и скорее всего какой-то способ будет найден (или конвертер или мне вышлют таки промежуточную версию или что-то подобное).
Вероятность что все три пути окажутся невозможными я рассматриваю как пренебрежительно малую и буду использовать сценарий миграции как на другой программный продукт — через внешние xmp и теги (или что там будет поддерживаться в обеих версиях на тот момент).
Бывают — у меня были лампы с цоколем G9 с одним светодиодом — в бра и в люстре накухне, свет получается направленный и потому освещения нехватает.
Потом нашел-таки лампы G9 с большим количеством светодиодов в разные стороны. При том же потреблении электричества визуально освещение стало несоизмеримо лучше.
Вот когда ваша очередная камера внезапно не будет поддерживаться в LR 4 — тогда и вернемся к «ничего нужного не добавили». ...
Я вполне допускаю возможность что моя камера вообще никогда не поменяется или поменяется один раз — с кропнутой на полнокадровую. Я не профессиональный фотограф и все принципиальные возможности в моём аппарате уже есть, а их количественное повышение (например 15 кадров в секунду вместо 3х или фокус за 0.01 секунду вместо 0.5 секунды) для меня несущественны. Единственное что хочется добавить — это полноразмерную матрицу. В любом случае это происходит заметно реже, чем выход новых версий ПО.
Значит, не проблема и заплатить за годовую подписку и отложить сдачу на следующий год, а что делать через 5 лет? Финансовые проблемы это может быть не только потеря работы, но и что-то более неприятное (авария, несчастный случай и т.п.) когда финансы только следствие.
Единственный (подчеркиваю, единственный) способ этого гарантированного избежать — это использование исключительно открытых форматов файлов.
Я рассматривал вариант использования DNG, но пока склоняюсь к тому что его использовать еще рано и для меня неудобно. Если я захочу мигрировать на другую платформу или другую программу DNG может не поддерживаться или поддерживаться ограниченно. RAW-файлы от моего фотоаппарата читаются хорошо несколькими разными программами и проблем с миграцией не возникнет. DNG всё равно как-то изменяет и конвертирует данные, при этом неизбежно что-то теряется. С другой стороны DNG не дает мне никаких преимуществ. В обзорных статьях хранение метаданных внутри DNG рассматривается как преимущество, я для своего сценария использования считаю это недостатком.
При правке метаданных для RAW я сохраняю все изменения в xmp-файле и при создании резервных копий после изменений у меня заново копируются и хранятся изменения только маленьких xmp-файлов, а не всего DNG, у которых метаданные хранятся внутри.
Простой пример когда это имеет значение — я недавно перебрал все свои 13 тысяч фотографий и расставил на них теги людей, мест, мероприятий. Архив фотографий весит 165Гб — если метаданных хранить внутри, то размер архива при этом увеличивается на 165Гб (хранятся версии за последний год). Других открытых форматов для хранения исходников фотографий я не знаю.
Если вдруг новое ПО откажется читать старые фотографии — я всегда могу запустить старый Lightroom из резервной копии и провести конвертацию в тот момент когда это будет необходимо, откладывая корвертацию я ничего не теряю.
Я надеюсь, вы это делаете вместе с ОС и железом, на которых они работают? Или хотя бы с системой виртуализации?
Да. Тут меня смущает сервер лицензирования Adobe к которому может пропасть доступ. На данный момент я такую вероятность рассматриваю как очень низкую, поэтому альтернативы ищу неспешно.
Есть еще маленький ньюанс — у меня есть купленный Lightroom 4 и совершенно не факт что я буду покупать 5-й, в котором ничего нужного мне не добавили или 6-й или какой-то еще. Я его сейчас просто щупаю и решаю нужны ли мне эти градиентные фильтры или нет. Попутно ищу альтернативу. Так что если нет надобности постоянно обновляться до свежих версий это может оказаться дешевле. Например у меня есть знакомый профессиональный художник — он работает на Photoshop CS2 и не хочет ничего новее потому что там интерфейс другой и надо переучиваться. Аналогичная ситуация с MS Office — многие пользуются старой 2003 версией потому что все менюшки привычные.
Кроме обновлений есть еще одна сторона: никто не знает в какой финансовой ситуации он будет завтра. Например сейчас не проблема заплатить 6 тысяч за программу или 3 за обновление. Или 10 за программу или сколько там потребуется. А на другой день может случиться какая-то непредвиденность и доходы резко упадут, при этом может так получиться что подписка это не самый важный расход и человек останется без каталога фотографий за всю жизнь или ему еще год придется это всё перелопачивать чтобы перенести в бесплатную альтернативу (понятно что мы рассматриваем случаи легального ПО).
Или например Россия откажется работать с Visa или американские компании прекратят принимать платежи из России. С купленной версией человек просто остается с тем что был — обновиться не сможет, но старого не теряет. С подпиской будет упс.
Я положительно отношусь к подписке для рабочих инструментов на текущую работу и которые приносят деньги, которые желательно всегда иметь самыми свежими. Но программы долговременного использования, такие как архив фотографий которые я использую не только как хобби для съемки, но и как личный фотоархив который мне будет нужен пока я жив — предпочитаю всё же покупать на постоянной основе.
Тот факт, что вы за эту абонентскую плату можете получить еще и фотошоп (за весьма смешные деньги) и, что важнее, Lightroom Mobile, вы не учитываете?
А вот это уже дело вкуса. Например я Photoshop не пользуюсь. Lightroom mobile попробовал — мне тоже не понравилось, стер и тоже не пользуюсь.
Вообще-то, есть. Панель HSL/Color.
Это не то, посмотрите как это выглядит в Capture One
Диапазон понятное дело настраиваемый и пипетка чтобы взять нужный диапазон с фотографии. Коррекция идет не с каждым отдельным цветом как в Lightroom на HSL а с группой смежных цветов, что заметно удобнее. Если хочется работать с фиксированными цветами как в Lightroom — рядом есть вкладка Basic, с четко разделенными секторами, которые как раз аналог HSL.
Aperture пробовал, пользовался. Ушел с неё на Lightroom как раз из-за того что она не кроссплатформенна и слезть с Aperture и Mac будет очень проблемно если это вдруг потребуется. Так же проблемно делать резервные копии фотографий на случай если придется что-то восстанавливать частично — например восстановить несколько фотографий из прошлого. В aperture восстанавливать придется весь каталог (т.е. терять прошлые изменения) или долго вспоминать как же назывался тот файл во внутренней структуре каталога и где он лежал (а лежит он вроде в папке называемой по дате импорта, а не съемки.
Я когда переходил на Lightroom потерял почти все категории и всё пришлось сортировать вручную. Благо тогда архив был еще не таким большим — только несколько сессий с нового цифровика + она вроде как сложно взаимодействует с внешними редакторами, т.е. фотку из Aperture нельзя поправить в другом редакторе и оставить в общем каталоге + еще какие-то мелочи по редактированию фотографий оказались неудобны. Так что сейчас эту программу уже вообще не рассматриваю.
Да, таблица немного неуклюжа. Мне этот способ сравнения показался оптимальным — с комментариями прямо по месту в таблице (из-за чего она и расползается). Покажите образец примерно того же (сравнение с комментариями к отдельным пунктам) в более презентабельном виде — я с удовольствием поправлю.
Да, надо посмотреть, спасибо.
Там правда кроссплатформенность Mac/Linux/Solaris без Windows. Но шансы перехода на Linux я оцениваю выше чем на Windows.
curl так уж получился, вообще да — с wget удобнее: он и ошибки возвращает и сам умеет повторы попыток делать, но так уже исторически сложилось и менять что-то в уже созданных шаблонах никак. Так что живем с тем что есть и работаем тоже, потому что даже если применить что-то новое — всё равно придется поддерживать и всё старое, чтобы работало — проще жить со старым вариантом чтобы не поддерживать двойной объем кода.
Именно редиректы тут не нужны — их можно реализовать уже внутри первого загрузочного скрипта.
Тут зависит от степени доверия к каналам, источнику и степени риска. Есть много случаев когда это не нужно.
Например этот скрипт запускается внутри собственной сети с собственными DNS-серверами и http-сервером, автор и пользователь — одна организация, владеющая всем этим делом так что в доп. проверках смысла нет. Если кто-то заполучил наши DNS-сервера или контроль над локальной сетью — тут уже не до инициализации новых VDS.
Если бы это был скрипт установки условно Joomla, который запускается из-под непривелигерованного пользователя в пустом окружении чтобы всё ему там настроить — я бы тоже не стал заморачиваться с подписями — чтобы там ни запустилось особого вреда не будет, т.к. доступ есть только к пустому окружению.
С другой стороны — никто не мешает дополнить этот скрипт проверкой валидности. Например скрипты которые скачиваются и сохраняются я проверяю по md5. Можно добавить и pgp если это требуется исходя из задачи работы скрипта, но это усложнение которое придется поддерживать всегда в будущем, чтобы уже выданные скрипты продолжали работать. В частности придется делать вечные ключи для подписей чтобы не менять скрипт всем раз в год или тем более в 5-10 лет (он уже в кучу систем врастет и все забудут как его менять и что-то точно отвалится).
Совершенно несогласен что гарантированный канал всегда лучше
Это всегда дороже для клиента и проще в планировании для провайдера.
Нужен ли клиенту гарантированный канал? Далеко не факт.
Мне например подавляющую часть времени хватит 10Мбит, несколько раз в сутки к этому порогу могу приближаться и с запасом мне бы хватило 20-50Мбит. Раз в 1-2 месяца мне нужен гигабит чтобы быстро перелить между серверами несколько сотен гигабайтов данных.
В этом сценарии совершенно неразумно оплачивать гарантированный гигабит, используя его на 1-2%, равно как и гарантированные 10Мбит — тогда я бы свои сотни гигабайтов синхронизировал месяц вместо нескольких часов.
Я как юр. лицо работаю с Amazon, оплата с корпоративной карты, учет в рублях по инвойсам и отчетам из банка (не смотря на долларовые цены банк в итоге списывает рубли и учитываются рубли без всякой валютной канители).
На практике базовый саппорт иногда помогает и с проблемами тоже, если аргументировать что они на стороне амазона.
1 раз случилась проблема на стороне aws: виртуальная машина находилась в стадии выключения, но выключаться, перезагружаться, стартовать и т.п. — отказывалась.
Обратился в бесплатный саппорт, получил ответ что они не помогают с тех. проблемами. Позвонил, объяснил что проблема с их стороны и я её решить физически не могу. Сотрудник обещал передать в тех службу, передал. Машину выключили по почте отписались.
Более важная причина это заведомая полнота базы, на которых наши клиенты объявляют свои LeaseSet-ы, тем самым гарантируя, что если LeaseSet опубликован, то он будет найден другим клиентом всегда.
Если я правильно понял LeaseSet это условно информация через какие маршрутизаторы можно подключиться к тому или иному I2P-адресу.
Т.е. условно — вы предлагаете централизованная база маршрутов, чтобы быстрее находить путь подключения?
Мне кажется это стоит отдельно проверять на снижение уязвимостей — не зря же сделан путь в несколько хопов с намеренным сокрытием маршрута следования и невозможностью определить конечного получателя (т.е. кто этот узел — адресат или тоже промежуточный узел).
Если будет центральная база адресов может появиться соответствие — как найти конечный узел и возможно зная это можно понять на каком IP-адресе он работает.
Это общие соображения — I2P пробовал относительно давно и недолго, т.к. нормальное ПО не работает, а специализированным общаться не с кем. Поясните где неправ.
Тоннели работают только в одну сторону, потому вы должны пинговать пару тоннелей, а если пинг не вернулся, то непонятно какой из двух помер.
Ну и нормально если любой из туннелей упал — перестроить оба. Это же не происходит ежеминутно чтобы требовало каких-то больших оптимизаций по снижению накладных расходов трафика. А по времени — они могут перестраиваться параллельно и времени уйдет столько же сколько на перестройку одного туннеля.
Кроме того, введение одного заведомо надежного узла снижает вероятность отказа тоннеля на треть.
Ну и степень анонимности снижается настолько же — этого эффекта (даже лучше) можно добиться если в настройках туннеля поставить на 1 хоп меньше.
Да, сложной фильтрацией я называл именно это
Про тормоза добавил, я думал это из-за того что у меня еще не все фотографии отрендерелись или много фотографий в одном альбоме (около 3-4 тысяч туда для пробы импортировал).
Тут не соглашусь — профессиональным фотографам тоже может потребоваться сначала массово обработать и/или отобрать фото из сессии снимков и только потом обработать отдельные в Photoshop уже детально.
Вопрос светочувствительности я решил светосильным объективом — его мне хватает чтобы снимать в комнате в пасмурную погоду без вспышки и получать хорошие яркие фотографии на iso 100-400, выше приходится ставить очень редко. С недостатком динамический диапазона пока (последние 2-3 года съемки на зеркалку) не сталкивался. Цветопередача меня в большинстве случаев даже у iPhone устраивает.
Да, стараюсь не зависеть особенно теми способами которые не доставляют никаких неудобств.
А куда он денется? Я слабо представляю себе резкий скачек куда-нибудь с таким размахом что старый софт даже в виртуалке ради разовой операции нельзя будет запустить.
Да, вероятность этого я не рассматривал но проверил его сейчас. Со страницы www.adobe.com/support/downloads/product.jsp?product=113&platform=Windows я скачал lightroom 1 для windows. Программа запустилась в пробном режиме. Я создал в нем каталог, экспортировал.
Затем открыл этот каталог моей текущей версией 5.4 — каталог открылся с предложением конвертации, я согласился и тестовый каталог был успешно конвертирован.
Даже если конвертация в далекой версии окажется недоступной (в чем я сомневаюсь) — всегда можно скачать какую-то промежуточную версию и конвертировать каталог сначала в ней, а потом уже в новой.
Если и это будет невозможно — я обращусь в поддержку разработчика с вопросом как мне быть и скорее всего какой-то способ будет найден (или конвертер или мне вышлют таки промежуточную версию или что-то подобное).
Вероятность что все три пути окажутся невозможными я рассматриваю как пренебрежительно малую и буду использовать сценарий миграции как на другой программный продукт — через внешние xmp и теги (или что там будет поддерживаться в обеих версиях на тот момент).
Потом нашел-таки лампы G9 с большим количеством светодиодов в разные стороны. При том же потреблении электричества визуально освещение стало несоизмеримо лучше.
Я вполне допускаю возможность что моя камера вообще никогда не поменяется или поменяется один раз — с кропнутой на полнокадровую. Я не профессиональный фотограф и все принципиальные возможности в моём аппарате уже есть, а их количественное повышение (например 15 кадров в секунду вместо 3х или фокус за 0.01 секунду вместо 0.5 секунды) для меня несущественны. Единственное что хочется добавить — это полноразмерную матрицу. В любом случае это происходит заметно реже, чем выход новых версий ПО.
Единственный (подчеркиваю, единственный) способ этого гарантированного избежать — это использование исключительно открытых форматов файлов.
Я рассматривал вариант использования DNG, но пока склоняюсь к тому что его использовать еще рано и для меня неудобно. Если я захочу мигрировать на другую платформу или другую программу DNG может не поддерживаться или поддерживаться ограниченно. RAW-файлы от моего фотоаппарата читаются хорошо несколькими разными программами и проблем с миграцией не возникнет. DNG всё равно как-то изменяет и конвертирует данные, при этом неизбежно что-то теряется. С другой стороны DNG не дает мне никаких преимуществ. В обзорных статьях хранение метаданных внутри DNG рассматривается как преимущество, я для своего сценария использования считаю это недостатком.
При правке метаданных для RAW я сохраняю все изменения в xmp-файле и при создании резервных копий после изменений у меня заново копируются и хранятся изменения только маленьких xmp-файлов, а не всего DNG, у которых метаданные хранятся внутри.
Простой пример когда это имеет значение — я недавно перебрал все свои 13 тысяч фотографий и расставил на них теги людей, мест, мероприятий. Архив фотографий весит 165Гб — если метаданных хранить внутри, то размер архива при этом увеличивается на 165Гб (хранятся версии за последний год). Других открытых форматов для хранения исходников фотографий я не знаю.
Если вдруг новое ПО откажется читать старые фотографии — я всегда могу запустить старый Lightroom из резервной копии и провести конвертацию в тот момент когда это будет необходимо, откладывая корвертацию я ничего не теряю.
Да. Тут меня смущает сервер лицензирования Adobe к которому может пропасть доступ. На данный момент я такую вероятность рассматриваю как очень низкую, поэтому альтернативы ищу неспешно.
Попробовал — да, в Lightroom тоже есть.
Буду переделывать таблицу в более приглядную на днях, заодно и описание поправлю.
Кроме обновлений есть еще одна сторона: никто не знает в какой финансовой ситуации он будет завтра. Например сейчас не проблема заплатить 6 тысяч за программу или 3 за обновление. Или 10 за программу или сколько там потребуется. А на другой день может случиться какая-то непредвиденность и доходы резко упадут, при этом может так получиться что подписка это не самый важный расход и человек останется без каталога фотографий за всю жизнь или ему еще год придется это всё перелопачивать чтобы перенести в бесплатную альтернативу (понятно что мы рассматриваем случаи легального ПО).
Или например Россия откажется работать с Visa или американские компании прекратят принимать платежи из России. С купленной версией человек просто остается с тем что был — обновиться не сможет, но старого не теряет. С подпиской будет упс.
Я положительно отношусь к подписке для рабочих инструментов на текущую работу и которые приносят деньги, которые желательно всегда иметь самыми свежими. Но программы долговременного использования, такие как архив фотографий которые я использую не только как хобби для съемки, но и как личный фотоархив который мне будет нужен пока я жив — предпочитаю всё же покупать на постоянной основе.
Например Make Select при отборе фотографий habrastorage.org/files/a55/dbf/e55/a55dbfe557cc4252a787f38fa062b0d7.png
А вот это уже дело вкуса. Например я Photoshop не пользуюсь. Lightroom mobile попробовал — мне тоже не понравилось, стер и тоже не пользуюсь.
Это не то, посмотрите как это выглядит в Capture One
Диапазон понятное дело настраиваемый и пипетка чтобы взять нужный диапазон с фотографии. Коррекция идет не с каждым отдельным цветом как в Lightroom на HSL а с группой смежных цветов, что заметно удобнее. Если хочется работать с фиксированными цветами как в Lightroom — рядом есть вкладка Basic, с четко разделенными секторами, которые как раз аналог HSL.
Aperture пробовал, пользовался. Ушел с неё на Lightroom как раз из-за того что она не кроссплатформенна и слезть с Aperture и Mac будет очень проблемно если это вдруг потребуется. Так же проблемно делать резервные копии фотографий на случай если придется что-то восстанавливать частично — например восстановить несколько фотографий из прошлого. В aperture восстанавливать придется весь каталог (т.е. терять прошлые изменения) или долго вспоминать как же назывался тот файл во внутренней структуре каталога и где он лежал (а лежит он вроде в папке называемой по дате импорта, а не съемки.
Я когда переходил на Lightroom потерял почти все категории и всё пришлось сортировать вручную. Благо тогда архив был еще не таким большим — только несколько сессий с нового цифровика + она вроде как сложно взаимодействует с внешними редакторами, т.е. фотку из Aperture нельзя поправить в другом редакторе и оставить в общем каталоге + еще какие-то мелочи по редактированию фотографий оказались неудобны. Так что сейчас эту программу уже вообще не рассматриваю.
Там правда кроссплатформенность Mac/Linux/Solaris без Windows. Но шансы перехода на Linux я оцениваю выше чем на Windows.
Именно редиректы тут не нужны — их можно реализовать уже внутри первого загрузочного скрипта.
Например этот скрипт запускается внутри собственной сети с собственными DNS-серверами и http-сервером, автор и пользователь — одна организация, владеющая всем этим делом так что в доп. проверках смысла нет. Если кто-то заполучил наши DNS-сервера или контроль над локальной сетью — тут уже не до инициализации новых VDS.
Если бы это был скрипт установки условно Joomla, который запускается из-под непривелигерованного пользователя в пустом окружении чтобы всё ему там настроить — я бы тоже не стал заморачиваться с подписями — чтобы там ни запустилось особого вреда не будет, т.к. доступ есть только к пустому окружению.
С другой стороны — никто не мешает дополнить этот скрипт проверкой валидности. Например скрипты которые скачиваются и сохраняются я проверяю по md5. Можно добавить и pgp если это требуется исходя из задачи работы скрипта, но это усложнение которое придется поддерживать всегда в будущем, чтобы уже выданные скрипты продолжали работать. В частности придется делать вечные ключи для подписей чтобы не менять скрипт всем раз в год или тем более в 5-10 лет (он уже в кучу систем врастет и все забудут как его менять и что-то точно отвалится).
Это всегда дороже для клиента и проще в планировании для провайдера.
Нужен ли клиенту гарантированный канал? Далеко не факт.
Мне например подавляющую часть времени хватит 10Мбит, несколько раз в сутки к этому порогу могу приближаться и с запасом мне бы хватило 20-50Мбит. Раз в 1-2 месяца мне нужен гигабит чтобы быстро перелить между серверами несколько сотен гигабайтов данных.
В этом сценарии совершенно неразумно оплачивать гарантированный гигабит, используя его на 1-2%, равно как и гарантированные 10Мбит — тогда я бы свои сотни гигабайтов синхронизировал месяц вместо нескольких часов.
чтобы собственно включить интерфейс, без этого пинги не пойдут и сеть работать не будет.
1 раз случилась проблема на стороне aws: виртуальная машина находилась в стадии выключения, но выключаться, перезагружаться, стартовать и т.п. — отказывалась.
Обратился в бесплатный саппорт, получил ответ что они не помогают с тех. проблемами. Позвонил, объяснил что проблема с их стороны и я её решить физически не могу. Сотрудник обещал передать в тех службу, передал. Машину выключили по почте отписались.
Если я правильно понял LeaseSet это условно информация через какие маршрутизаторы можно подключиться к тому или иному I2P-адресу.
Т.е. условно — вы предлагаете централизованная база маршрутов, чтобы быстрее находить путь подключения?
Мне кажется это стоит отдельно проверять на снижение уязвимостей — не зря же сделан путь в несколько хопов с намеренным сокрытием маршрута следования и невозможностью определить конечного получателя (т.е. кто этот узел — адресат или тоже промежуточный узел).
Если будет центральная база адресов может появиться соответствие — как найти конечный узел и возможно зная это можно понять на каком IP-адресе он работает.
Это общие соображения — I2P пробовал относительно давно и недолго, т.к. нормальное ПО не работает, а специализированным общаться не с кем. Поясните где неправ.
Ну и нормально если любой из туннелей упал — перестроить оба. Это же не происходит ежеминутно чтобы требовало каких-то больших оптимизаций по снижению накладных расходов трафика. А по времени — они могут перестраиваться параллельно и времени уйдет столько же сколько на перестройку одного туннеля.
Ну и степень анонимности снижается настолько же — этого эффекта (даже лучше) можно добиться если в настройках туннеля поставить на 1 хоп меньше.
Т.е. по внутреннему IP-адресу можно узнать I2P адрес который ему соответствует, больше из него ничего узнать не получится.