Именно это и требуется. Но зачем в каждый пакет совать инструмент для работы с ресурсами, когда его можно вынести в отдельный пакет, который просто будет прописан в зависимостях нашего пакета? Для того и нужны пакетные системы. И получится всё удобно и красиво — есть наш пакет с ресурсами. Если сторонний пакет, позволяющий унифицировано работать с нашими ресурсами.
>Управление ресурсами — задача самих пакетов, они должны публиковать ресурсы через api фреймворка, а не сторонний пакет который лазит в чужие внутренности.
Ну, например, composer из коробки сам не умеет работать с assets. И при создании своего проекта, использующего composer, приходится или обращаться к сторонним решениям (bower/node со всей монстроидальностью), или разруливать всё руками, в т.ч. следя за корректностью путей, или пользоваться пакетами третьих сторон под composer, управляющими assets. Идеальных среди них пока не встречал, но, возможно (только сегодня узнал и ещё не оценивал) puli может быть приличной альтернативой. А, может, очередным кривым менеджером ресурсов. В любом случае, менеджеры ресурсов под composer явно востребованы.
Если быть совсем точным, то задержки _холодных_ данных в ipfs сравнимы с задержкой _горячих_ данных в tor. Горячие же данные в ipfs отдаются с обычной для web'а скорость. Ну, вот, чтобы не быть голословным, залитая мной картиночка в ipfs: gateway.ipfs.io/ipfs/QmTUeRKutKfbTRmoXsgRTv4r9zKJyFVrX3NVLQctRmoa1v
Нет. Tahoe — это хранилище. IPFS — транспорт (хотя и с локальным кеш-хранилищем, но не распределённым, как tahoe). В принципе, они могут быть хоть совмещены. tahoe как средство распределённого хранения, а ipfs — транспорт для передачи клиенту (не требующий, в отличие от tahoe установки клиента)
Потому что идентификатор файла в IPFS — его содержимое. Это, кстати, позволяет более эффективно использовать популярные файлы, они хранятся только один раз в кеше.
ipfs — это не распределённое хранилище. Это распределённый транспортный протокол с попутным кешированием. p2p-транспорты не менее, а скорее более востребованы, чем [анонимные] p2p-хранилища.
Там очень большие хеши. Боюсь, что вероятность коллизии будет много ниже вероятности того, что, например, упомянутого крупного диктора просто собьет машина на улице…
Присматривался к ipfs для раздачи статики на своем сайте. Остановило неумение раздавать целые каталоги прямо с диска. Т.е. мне для раздачи нужно каждый файл залить в локальное хранилище ipfs и по факту имеет две копии: одна копия в обычной fs (ибо ipfs не обеспечивает весь локальный функционал), вторая — в ipfs. Когда файлов — сотни гигабайт, такое дублирование становится расточительным и бессмысленным :—/
А в остальном система очень понравилась. Ещё бы чисто браузерную реализацию (js, webrtc), чтобы простой юзер мог бы качать минуя гейт, но при этом не устанавливая дополнительный софт, цены б ей не было :)
Не могу говорить за всех, но я и некоторые знакомые перестали ходить на blogs.yandex.ru по прозаичной причине — там стало нечего смотреть. Раньше были рейтинги социальных сетей, топовые записи и т.п. Можно было ходить просто за интересным. Сейчас осталась только поисковая строчка. Не удивительно, что многие оттуда ушли.
У меня 1.3 и 1.4 периодически вешали насмерть Android-коммуникатор. Как с этим в 2.0 и 2.1 не знаю, ибо слинял на Syncthing. На 2.2 посмотрел бы, но… в нём нет версионного бэкапа, а я уже привык к нему на Syncthing. Так что буду думать, что выбрать :) Ибо на BTSync уже терял уникальные данные из-за отсутствия версионного бэкапа проблем в алгоритме синхронизации — синхронизировался видеоархив с летнего отдыха, на одной из машин кончилось место, получились файлы нулевой длины. Которые потом засинхронизировались обратно на все машины. Весь видеоархив пропал :-/ С Syncthing и включенным версионным бэкапом такое невозможно в принципе.
У меня за NAT сидит копий 10 SyncThing на двух десктопах, двух ноутах и трёх гаджетах. «Снаружи» — копий 7 на четырёх серверах. Все со всеми взаимодействуют без проблем.
Главные проблемы Syncthing — сканирование, а не мониторинг файлов (это вообще жесть, постыдная для XXI века) и невозможность простого подключения всех желающих по ключу (хотя это и в BTSync 2 убрали, но там хоть по ссылке можно раздавать доступ без ручного подключения чужих машин).
Ну и на Android Syncthing очень уж быстро аккумулятор сажает. Хотя, с другой стороны, BTSync 1.4 мне часто вообще просто насмерть завешивал коммуникатор :)
У хабракармы есть генетический недостаток — в ней не учитывается карма самого голосующего и разрешено голосовать пассивным анонимным потребителям.
Как только голосование разрешается лишь персонифицированным пользователям и начинает учитываться вес их голоса, зависящий от собственной репутации, механизм начинает работать очень хорошо. И тролли быстро теряют вес, и культурные пользователи растут, и демагоги набирают силу не надолго.
Уйма компаний сегодня использует Composer в продакшне под большими нагрузками. Просто нужно отдавать себе отчёт и иметь определённый навык решения проблем, если таковые возникнут.
7 лет назад — это уже дешёвые и массовые WM5 телефоны. Я до последнего держался за «кнопочную» Nokia 6310i, но как раз ровно 7 лет назад, в июле 2008-го сдался и купил первый коммуникатор :) Надо отметить, что от своих коллег на работе и знакомых я с этим переходом припозднился.
> Управление ресурсами — задача самих пакетов,
Именно это и требуется. Но зачем в каждый пакет совать инструмент для работы с ресурсами, когда его можно вынести в отдельный пакет, который просто будет прописан в зависимостях нашего пакета? Для того и нужны пакетные системы. И получится всё удобно и красиво — есть наш пакет с ресурсами. Если сторонний пакет, позволяющий унифицировано работать с нашими ресурсами.
Ну, например, composer из коробки сам не умеет работать с assets. И при создании своего проекта, использующего composer, приходится или обращаться к сторонним решениям (bower/node со всей монстроидальностью), или разруливать всё руками, в т.ч. следя за корректностью путей, или пользоваться пакетами третьих сторон под composer, управляющими assets. Идеальных среди них пока не встречал, но, возможно (только сегодня узнал и ещё не оценивал) puli может быть приличной альтернативой. А, может, очередным кривым менеджером ресурсов. В любом случае, менеджеры ресурсов под composer явно востребованы.
И речь именно о холодном ожидании. Как закачалось в кеш — отдаётся мгновенно.
Чтобы получить p2p, нужно ставить локальный софт. Очевидно, что настройки объема локального хранилища там должны быть.
А в остальном система очень понравилась. Ещё бы чисто браузерную реализацию (js, webrtc), чтобы простой юзер мог бы качать минуя гейт, но при этом не устанавливая дополнительный софт, цены б ей не было :)
У меня 1.3 и 1.4 периодически вешали насмерть Android-коммуникатор. Как с этим в 2.0 и 2.1 не знаю, ибо слинял на Syncthing. На 2.2 посмотрел бы, но… в нём нет версионного бэкапа, а я уже привык к нему на Syncthing. Так что буду думать, что выбрать :) Ибо на BTSync уже терял уникальные данные из-за отсутствия версионного бэкапа проблем в алгоритме синхронизации — синхронизировался видеоархив с летнего отдыха, на одной из машин кончилось место, получились файлы нулевой длины. Которые потом засинхронизировались обратно на все машины. Весь видеоархив пропал :-/ С Syncthing и включенным версионным бэкапом такое невозможно в принципе.
Главные проблемы Syncthing — сканирование, а не мониторинг файлов (это вообще жесть, постыдная для XXI века) и невозможность простого подключения всех желающих по ключу (хотя это и в BTSync 2 убрали, но там хоть по ссылке можно раздавать доступ без ручного подключения чужих машин).
Ну и на Android Syncthing очень уж быстро аккумулятор сажает. Хотя, с другой стороны, BTSync 1.4 мне часто вообще просто насмерть завешивал коммуникатор :)
Как только голосование разрешается лишь персонифицированным пользователям и начинает учитываться вес их голоса, зависящий от собственной репутации, механизм начинает работать очень хорошо. И тролли быстро теряют вес, и культурные пользователи растут, и демагоги набирают силу не надолго.